Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1431494

Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

From Neil Armstrong <narmstrong@baylibre.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey
Date 2016-06-26 15:10 +0200
Message-ID <rOhYZ-3lo-5@gated-at.bofh.it> (permalink)
References <rNvrk-6dp-17@gated-at.bofh.it> <rNvB0-6gB-13@gated-at.bofh.it> <rNHst-5xO-5@gated-at.bofh.it> <rNRi9-3cb-19@gated-at.bofh.it> <rNY9Y-7iR-15@gated-at.bofh.it>
Organization Baylibre

Show all headers | View raw


On 06/25/2016 05:53 PM, Dmitry Torokhov wrote:
> On Sat, Jun 25, 2016 at 10:34:04AM +0200, Neil Armstrong wrote:
>> On 06/25/2016 12:07 AM, Dmitry Torokhov wrote:
>>> On Fri, Jun 24, 2016 at 11:18:04AM +0200, Neil Armstrong wrote:
>>>> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
>>>> for the pm8018 pwrkey in pmic8xxx-pwrkey.
>>>>
>>>> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> NAK.
>>
>> Hi Dmitry,
>>
>> Actually, the new compatible string make sense, because the driver is compatible with the
>> "pm8018" pwrkey but from a system point of view, it's not a pm8921 pwrkey, hence the new
>> compatible string.
> 
> A lot of systems note this fact in DTS, but not require driver changes,
> by specifying several compatible strings:
> 
> 	compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
> 	compatible = "fsl,imx6q-i2c", "fsl,imx21-i2c";
> 	compatible = "rockchip,rk3036-timer", "rockchip,rk3288-timer";

Sure, your point is valid.
But here, the situation is quite different, the question is about confidence.
From the system point of view, I'm 100% sure there is a pm8010-pwrkey variant here, but
I`m not convinced at all how it is similar from the 8921 version.
From the software point of view, I'm 80% sure the *actual* driver in it current form
somehow works for the pm8018-pwrkey, not more.
If somehow the driver is updated to support a 8921 feature that is not supported by the
8018 version, it will rely on the compatible string to make this a smart move.
Since I do not have the pm8018 datasheet and the 8921 either, I cannot statue on this,
So the smartest move from my side is to actually have a different compatible string
to avoid future blocking situations.

>>
>> Rob Herring was very clear with me with this policy, and it will simplify further driver
> 
> Could I get a pointer to this discussion so I can educate myself better
> about DT policies?

I had quite a lot of comments on the OXNAS support push (started here https://lkml.org/lkml/2016/3/3/495) were
the policy was to narrow the new compatible strings to a SoC specific naming.
For the qcom driver, the strings the already compliant and why not continue with the pm8018 ?

>> architecture change since it will not imply devicetree changes anymore.
> 
> Would we need the driver changes? What are the differences in power key
> functionality between 8018 and 8921?

You raise the biggest question, I do not know, so why should we say the pm8018-pwrkey /is/ compatible with pm8921-pwronly only by looking existing driver ?

>>
>> My point of view is that the devicetree describes the hardware and need to have SoC specific
>> compatible string since it describes the actual silicon, and drivers must make sure to handle
>> all the SoC or family variants using the compatible string and the match data.
> 
> No, the compatible string means that the hardware is *compatible* with
> something. It does not mean that we need to adjust driver every time a
> company pumps out a new package including said hardware.

It was something that I questionned myself about, but it seems the maintainers agrees quite easily to accept these compatible adding patches
like the USB Ids or PCI ids patches.

Regards,
Neil

> Thanks.
> 

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v2 0/5] Add support for the Qualcomm PM8018 PMIC Neil Armstrong <narmstrong@baylibre.com> - 2016-06-24 11:30 +0200
  [PATCH v2 4/5] mfd: qcom-rpm: Add support for pm8018 RPM Regulator Neil Armstrong <narmstrong@baylibre.com> - 2016-06-24 11:30 +0200
    Re: [PATCH v2 4/5] mfd: qcom-rpm: Add support for pm8018 RPM  Regulator Lee Jones <lee.jones@linaro.org> - 2016-06-28 17:10 +0200
  [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey Neil Armstrong <narmstrong@baylibre.com> - 2016-06-24 11:30 +0200
    Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018  pwrkey Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-06-25 00:10 +0200
      Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018  pwrkey Neil Armstrong <narmstrong@baylibre.com> - 2016-06-25 10:40 +0200
        Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018  pwrkey Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-06-25 18:00 +0200
          Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018  pwrkey Neil Armstrong <narmstrong@baylibre.com> - 2016-06-26 15:10 +0200
  [PATCH v2 3/5] rtc: rtc-pm8xxx: Add support for pm8018 rtc Neil Armstrong <narmstrong@baylibre.com> - 2016-06-24 11:30 +0200
  [PATCH v2 5/5] regulator: qcom_rpm-regulator: Add support for pm8018 rpm regulator Neil Armstrong <narmstrong@baylibre.com> - 2016-06-24 11:30 +0200
    Re: [PATCH v2 5/5] regulator: qcom_rpm-regulator: Add support for  pm8018 rpm regulator Mark Brown <broonie@kernel.org> - 2016-06-24 12:40 +0200

csiph-web