| Message ID | 20220928-mdm9615-dt-schema-fixes-v1-5-b6e63a7df1e8@linaro.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm: qcom: mdm9615: first round of bindings and DT fixes | expand |
On 28/09/2022 11:14, Neil Armstrong wrote: > The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles > was left but it makes no sense anymore the leave both. Why? It makes sense for backwards compatibility. If you think it does not make sense, please say why. > > The pwrkey compatible is left to PM8921, unlike the others because > the interface is stricly compatible with the PM9821 pwrkey. typo: strictly typo: PM8921 Again, why? The old code looked correct. In all three places. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > Best regards, Krzysztof
Hi, On 28/09/2022 20:03, Krzysztof Kozlowski wrote: > On 28/09/2022 11:14, Neil Armstrong wrote: >> The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles >> was left but it makes no sense anymore the leave both. > > Why? It makes sense for backwards compatibility. If you think it does > not make sense, please say why. We had the same debate at submission 7y ago, some of the pm8018 new compatible were rejected in bindings & drivers so I left both... As of today only the pwrkey bindings is missing, so should I resubmit the pm8018-pwrkey bidings and drop the pm8921-pwrkey compatible ? > >> >> The pwrkey compatible is left to PM8921, unlike the others because >> the interface is stricly compatible with the PM9821 pwrkey. > > typo: strictly > typo: PM8921 > > Again, why? The old code looked correct. In all three places. The qcom,pm8018-rtc require a single compatible, same for qcom,pm8018, so what's the way to fix it ? > >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> > > Best regards, > Krzysztof > Thanks, Neil
On 29/09/2022 10:29, Neil Armstrong wrote: > Hi, > > On 28/09/2022 20:03, Krzysztof Kozlowski wrote: >> On 28/09/2022 11:14, Neil Armstrong wrote: >>> The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles >>> was left but it makes no sense anymore the leave both. >> >> Why? It makes sense for backwards compatibility. If you think it does >> not make sense, please say why. > > We had the same debate at submission 7y ago, some of the pm8018 new compatible > were rejected in bindings & drivers so I left both... > > As of today only the pwrkey bindings is missing, so should I resubmit the pm8018-pwrkey bidings and > drop the pm8921-pwrkey compatible ? ~7 years ago here: https://lore.kernel.org/all/20160624220748.GB11719@dtor-ws/ you proposed to add something entirely different than we have here now and than we talk about. In that thread you correctly wrote: "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." but implemented it entirely different. Maybe you refer to different mail thread, I don't know, but that one is indeed wrong. The DTS looks correct unless you have some real argument that it is not. How this should be fixed? First, drop bogus entries from drivers, then document proper compatibles. Best regards, Krzysztof
On 29/09/2022 11:12, Krzysztof Kozlowski wrote: > On 29/09/2022 10:29, Neil Armstrong wrote: >> Hi, >> >> On 28/09/2022 20:03, Krzysztof Kozlowski wrote: >>> On 28/09/2022 11:14, Neil Armstrong wrote: >>>> The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles >>>> was left but it makes no sense anymore the leave both. >>> >>> Why? It makes sense for backwards compatibility. If you think it does >>> not make sense, please say why. >> >> We had the same debate at submission 7y ago, some of the pm8018 new compatible >> were rejected in bindings & drivers so I left both... >> >> As of today only the pwrkey bindings is missing, so should I resubmit the pm8018-pwrkey bidings and >> drop the pm8921-pwrkey compatible ? > > ~7 years ago here: > https://lore.kernel.org/all/20160624220748.GB11719@dtor-ws/ > you proposed to add something entirely different than we have here now > and than we talk about. > > In that thread you correctly wrote: > "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." And I'm happy this is still the policy! And I'm tried my best to follow this in all my DT & bindings submissions, while DT-Schema helped a lot here. > > but implemented it entirely different. Maybe you refer to different mail > thread, I don't know, but that one is indeed wrong. In the meantime things got much better, but at that time pushing a SoC bringup was a pain (I did 2 at the time, the other one is the OX810SE) and I even mentioned it in a talk ([1] slides 27 to 30). So I added both to be sure that at some point a driver would probe against one of the compatible entries... > > The DTS looks correct unless you have some real argument that it is not. > > How this should be fixed? First, drop bogus entries from drivers, then > document proper compatibles. What do you mean ? There's no point to keep the PM8921 compatibles, the gpio and PMIC bindings already enforces to only have the PM8018 compatible. The only issue is about the PM8018 pwrkey, where the solution would be to actually re-submit [1] by documenting qcom,pm8018-pwrkey and adding the entry in the drivers/input/misc/pmic8xxx-pwrkey.c driver. Or maybe I missed something. [1] https://www.slideshare.net/superna/elce-2016-neil-armstrong-no-its-never-too-late-to-upstream-your-legacy-linux-based-platform [2] https://lore.kernel.org/all/1466759887-25394-3-git-send-email-narmstrong@baylibre.com/ > > Best regards, > Krzysztof > Thanks, Neil
On 29/09/2022 12:56, Neil Armstrong wrote: > On 29/09/2022 11:12, Krzysztof Kozlowski wrote: >> On 29/09/2022 10:29, Neil Armstrong wrote: >>> Hi, >>> >>> On 28/09/2022 20:03, Krzysztof Kozlowski wrote: >>>> On 28/09/2022 11:14, Neil Armstrong wrote: >>>>> The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles >>>>> was left but it makes no sense anymore the leave both. >>>> >>>> Why? It makes sense for backwards compatibility. If you think it does >>>> not make sense, please say why. >>> >>> We had the same debate at submission 7y ago, some of the pm8018 new compatible >>> were rejected in bindings & drivers so I left both... >>> >>> As of today only the pwrkey bindings is missing, so should I resubmit the pm8018-pwrkey bidings and >>> drop the pm8921-pwrkey compatible ? >> >> ~7 years ago here: >> https://lore.kernel.org/all/20160624220748.GB11719@dtor-ws/ >> you proposed to add something entirely different than we have here now >> and than we talk about. >> >> In that thread you correctly wrote: >> "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." > > And I'm happy this is still the policy! And I'm tried my best to follow this > in all my DT & bindings submissions, while DT-Schema helped a lot here. > >> >> but implemented it entirely different. Maybe you refer to different mail >> thread, I don't know, but that one is indeed wrong. > > In the meantime things got much better, but at that time pushing a SoC bringup > was a pain (I did 2 at the time, the other one is the OX810SE) and I even > mentioned it in a talk ([1] slides 27 to 30). > > So I added both to be sure that at some point a driver would probe against > one of the compatible entries... > >> >> The DTS looks correct unless you have some real argument that it is not. >> >> How this should be fixed? First, drop bogus entries from drivers, then >> document proper compatibles. > > What do you mean ? There's no point to keep the PM8921 compatibles, the gpio I asked at beginning - why? Why there is no point to keep them? > and PMIC bindings already enforces to only have the PM8018 compatible. That is just partial argument because binding does not match DTS. So something is not correct. Why do you assume bindings are correct? > > The only issue is about the PM8018 pwrkey, where the solution would be > to actually re-submit [1] by documenting qcom,pm8018-pwrkey and adding the entry > in the drivers/input/misc/pmic8xxx-pwrkey.c driver. > > Or maybe I missed something. > > [1] https://www.slideshare.net/superna/elce-2016-neil-armstrong-no-its-never-too-late-to-upstream-your-legacy-linux-based-platform > [2] https://lore.kernel.org/all/1466759887-25394-3-git-send-email-narmstrong@baylibre.com/ So let's repeat again: the patch [2] looks wrong. The qcom,pm8018-pwrkey and qcom,pm8921-pwrkey are compatible. Best regards, Krzysztof
On 29/09/2022 13:12, Krzysztof Kozlowski wrote: > On 29/09/2022 12:56, Neil Armstrong wrote: >> On 29/09/2022 11:12, Krzysztof Kozlowski wrote: >>> On 29/09/2022 10:29, Neil Armstrong wrote: >>>> Hi, >>>> >>>> On 28/09/2022 20:03, Krzysztof Kozlowski wrote: >>>>> On 28/09/2022 11:14, Neil Armstrong wrote: >>>>>> The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles >>>>>> was left but it makes no sense anymore the leave both. >>>>> >>>>> Why? It makes sense for backwards compatibility. If you think it does >>>>> not make sense, please say why. >>>> >>>> We had the same debate at submission 7y ago, some of the pm8018 new compatible >>>> were rejected in bindings & drivers so I left both... >>>> >>>> As of today only the pwrkey bindings is missing, so should I resubmit the pm8018-pwrkey bidings and >>>> drop the pm8921-pwrkey compatible ? >>> >>> ~7 years ago here: >>> https://lore.kernel.org/all/20160624220748.GB11719@dtor-ws/ >>> you proposed to add something entirely different than we have here now >>> and than we talk about. >>> >>> In that thread you correctly wrote: >>> "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." >> >> And I'm happy this is still the policy! And I'm tried my best to follow this >> in all my DT & bindings submissions, while DT-Schema helped a lot here. >> >>> >>> but implemented it entirely different. Maybe you refer to different mail >>> thread, I don't know, but that one is indeed wrong. >> >> In the meantime things got much better, but at that time pushing a SoC bringup >> was a pain (I did 2 at the time, the other one is the OX810SE) and I even >> mentioned it in a talk ([1] slides 27 to 30). >> >> So I added both to be sure that at some point a driver would probe against >> one of the compatible entries... >> >>> >>> The DTS looks correct unless you have some real argument that it is not. >>> >>> How this should be fixed? First, drop bogus entries from drivers, then >>> document proper compatibles. >> >> What do you mean ? There's no point to keep the PM8921 compatibles, the gpio > > I asked at beginning - why? Why there is no point to keep them? Because the HW is an PM8018 and the addition of the PM8921 was for policy/organization/struggling-to-make-dt-merged-before-clear-dt-policy/... so you say I should modify the Bindings to reflect the actual "pm8018", "pm8921" situation instead of changing the DT even if incorrect ? > >> and PMIC bindings already enforces to only have the PM8018 compatible. > > That is just partial argument because binding does not match DTS. So > something is not correct. Why do you assume bindings are correct? Because bindings accurately reflects HW and DT doesn't. > >> >> The only issue is about the PM8018 pwrkey, where the solution would be >> to actually re-submit [1] by documenting qcom,pm8018-pwrkey and adding the entry >> in the drivers/input/misc/pmic8xxx-pwrkey.c driver. >> >> Or maybe I missed something. >> >> [1] https://www.slideshare.net/superna/elce-2016-neil-armstrong-no-its-never-too-late-to-upstream-your-legacy-linux-based-platform >> [2] https://lore.kernel.org/all/1466759887-25394-3-git-send-email-narmstrong@baylibre.com/ > > So let's repeat again: the patch [2] looks wrong. The qcom,pm8018-pwrkey > and qcom,pm8921-pwrkey are compatible. Ok, I need time to understand, I'm highly confused now. > > Best regards, > Krzysztof >
On 29/09/2022 13:39, Neil Armstrong wrote: >>>> The DTS looks correct unless you have some real argument that it is not. >>>> >>>> How this should be fixed? First, drop bogus entries from drivers, then >>>> document proper compatibles. >>> >>> What do you mean ? There's no point to keep the PM8921 compatibles, the gpio >> >> I asked at beginning - why? Why there is no point to keep them? > > Because the HW is an PM8018 and the addition of the PM8921 was for policy/organization/struggling-to-make-dt-merged-before-clear-dt-policy/... > so you say I should modify the Bindings to reflect the actual "pm8018", "pm8921" situation instead of changing the DT even if incorrect ? Yes, this is what I already wrote: "How this should be fixed? First, drop bogus entries from drivers, then document proper compatibles." >>> and PMIC bindings already enforces to only have the PM8018 compatible. >> >> That is just partial argument because binding does not match DTS. So >> something is not correct. Why do you assume bindings are correct? > > Because bindings accurately reflects HW and DT doesn't. That's not really an answer... Bindings are correct because they are correct? What is exactly correct in the bindings? How they reflect the HW in a proper way, while DTS does not? Or let's focus on actual hardware - what are the properties of the hardware which indicate that DTS is wrong? Best regards, Krzysztof
On 29/09/2022 13:47, Krzysztof Kozlowski wrote: > On 29/09/2022 13:39, Neil Armstrong wrote: >>>>> The DTS looks correct unless you have some real argument that it is not. >>>>> >>>>> How this should be fixed? First, drop bogus entries from drivers, then >>>>> document proper compatibles. >>>> >>>> What do you mean ? There's no point to keep the PM8921 compatibles, the gpio >>> >>> I asked at beginning - why? Why there is no point to keep them? >> >> Because the HW is an PM8018 and the addition of the PM8921 was for policy/organization/struggling-to-make-dt-merged-before-clear-dt-policy/... >> so you say I should modify the Bindings to reflect the actual "pm8018", "pm8921" situation instead of changing the DT even if incorrect ? > > Yes, this is what I already wrote: > > "How this should be fixed? First, drop bogus entries from drivers, then > document proper compatibles." > >>>> and PMIC bindings already enforces to only have the PM8018 compatible. >>> >>> That is just partial argument because binding does not match DTS. So >>> something is not correct. Why do you assume bindings are correct? >> >> Because bindings accurately reflects HW and DT doesn't. > > That's not really an answer... Bindings are correct because they are > correct? What is exactly correct in the bindings? How they reflect the > HW in a proper way, while DTS does not? > > Or let's focus on actual hardware - what are the properties of the > hardware which indicate that DTS is wrong? The actual PMIC is an PM8018 > > Best regards, > Krzysztof > Neil
On 29/09/2022 13:59, Neil Armstrong wrote: >> That's not really an answer... Bindings are correct because they are >> correct? What is exactly correct in the bindings? How they reflect the >> HW in a proper way, while DTS does not? >> >> Or let's focus on actual hardware - what are the properties of the >> hardware which indicate that DTS is wrong? > > The actual PMIC is an PM8018 And DTS is saying PMIC is PM8018, isn't it? I see clearly in DTS: qcom,pm8018 qcom,pm8018-rtc qcom,pm8018-pwrkey qcom,pm8018-gpio Best regards, Krzysztof
On 29/09/2022 14:02, Krzysztof Kozlowski wrote: > On 29/09/2022 13:59, Neil Armstrong wrote: >>> That's not really an answer... Bindings are correct because they are >>> correct? What is exactly correct in the bindings? How they reflect the >>> HW in a proper way, while DTS does not? >>> >>> Or let's focus on actual hardware - what are the properties of the >>> hardware which indicate that DTS is wrong? >> >> The actual PMIC is an PM8018 > > And DTS is saying PMIC is PM8018, isn't it? I see clearly in DTS: > qcom,pm8018 > qcom,pm8018-rtc > qcom,pm8018-pwrkey > qcom,pm8018-gpio And this is why I pushed the removal of qcom,pm8921* fallback compatibles, except for qcom,pm8018-pwrkey because I didn't managed to get it documented at the time. > > Best regards, > Krzysztof >
On 29/09/2022 14:21, Neil Armstrong wrote: > On 29/09/2022 14:02, Krzysztof Kozlowski wrote: >> On 29/09/2022 13:59, Neil Armstrong wrote: >>>> That's not really an answer... Bindings are correct because they are >>>> correct? What is exactly correct in the bindings? How they reflect the >>>> HW in a proper way, while DTS does not? >>>> >>>> Or let's focus on actual hardware - what are the properties of the >>>> hardware which indicate that DTS is wrong? >>> >>> The actual PMIC is an PM8018 >> >> And DTS is saying PMIC is PM8018, isn't it? I see clearly in DTS: >> qcom,pm8018 >> qcom,pm8018-rtc >> qcom,pm8018-pwrkey >> qcom,pm8018-gpio > > And this is why I pushed the removal of qcom,pm8921* fallback compatibles, > except for qcom,pm8018-pwrkey because I didn't managed to get it documented at the time. This does not explain at all why you wanted to remove any other compatibles. There is no connection, relation between these. We are making circles and discussion takes too much. I asked to bring the arguments about hardware that point devices are not compatible. You just said "PMIC is an PM8018", and that's it. Nothing more, nothing about hardware. Based on that you want to remove compatibility. This is not valid argument. It's unrelated. You could as well say "The actual PMIC is Qualcomm PMIC" and you would be right. Still not an argument. Based on lack of arguments in this entire discussion, the patch itself is not correct. Use the approach I wrote some time ago and quoted one more time. Best regards, Krzysztof
Hi, On 29/09/2022 14:27, Krzysztof Kozlowski wrote: > > We are making circles and discussion takes too much. I'm sorry this happens, but I really want solve this stuff which in suspend since 2015. So let me recall the original issue: DTBS check reports: arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb: pmic@0: compatible: ['qcom,pm8018', 'qcom,pm8921'] is too long From schema: Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb: pmic@0: rtc@11d:compatible: ['qcom,pm8018-rtc', 'qcom,pm8921-rtc'] is too long From schema: Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb:0:0: /soc/qcom,ssbi@500000/pmic@0/pwrkey@1c: failed to match any schema with compatible: ['qcom,pm8018-pwrkey', 'qcom,pm8921-pwrkey'] arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb:0:0: /soc/qcom,ssbi@500000/pmic@0/pwrkey@1c: failed to match any schema with compatible: ['qcom,pm8018-pwrkey', 'qcom,pm8921-pwrkey'] arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb: rtc@11d: compatible: ['qcom,pm8018-rtc', 'qcom,pm8921-rtc'] is too long From schema: Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml So trying to solve those, and since the PMIC in the wp8548 module is a PM8018, and it happens to be (partially ?? potentially ??) compatible with the PM8921, and I had issues adding per-HW compatible for the pwrkey, the obvious solution would be to drop the PM8921 compatibility since it's only probable and nothing proves it's right. But what's sure: it's a PM8018 PMIC. But since the PM8018 PWRKEY interface is compatible with the PM8921 PWRKEY interface, it's perfectly ok to the the MP8921 compatible here. OK, so as you quoted multiple times: "How this should be fixed? First, drop bogus entries from drivers, then document proper compatibles." OK so there's no bogus entries to remove here, and the only compatible to potentially document is the pm8018-pwrkey but it seems to be wrong. I'll be happy to have an hint on how to handle that to I can go forward and stop the noise, there's still plenty of stuff to fix in the MDM9615 DT. > > Best regards, > Krzysztof > Thanks, Neil
On 29/09/2022 14:48, Neil Armstrong wrote: > Hi, > > On 29/09/2022 14:27, Krzysztof Kozlowski wrote: >> >> We are making circles and discussion takes too much. > > I'm sorry this happens, but I really want solve this stuff which in suspend since 2015. > > So let me recall the original issue: > > DTBS check reports: > > arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb: pmic@0: compatible: ['qcom,pm8018', 'qcom,pm8921'] is too long > From schema: Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml > > arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb: pmic@0: rtc@11d:compatible: ['qcom,pm8018-rtc', 'qcom,pm8921-rtc'] is too long > From schema: Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml > > arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb:0:0: /soc/qcom,ssbi@500000/pmic@0/pwrkey@1c: failed to match any schema with compatible: ['qcom,pm8018-pwrkey', 'qcom,pm8921-pwrkey'] > > arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb:0:0: /soc/qcom,ssbi@500000/pmic@0/pwrkey@1c: failed to match any schema with compatible: ['qcom,pm8018-pwrkey', 'qcom,pm8921-pwrkey'] > > arch/arm/boot/dts/qcom-mdm9615-wp8548-mangoh-green.dtb: rtc@11d: compatible: ['qcom,pm8018-rtc', 'qcom,pm8921-rtc'] is too long > From schema: Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml > > So trying to solve those, and since the PMIC in the wp8548 module is a PM8018, and it happens to be (partially ?? potentially ??) compatible > with the PM8921, and I had issues adding per-HW compatible for the pwrkey, the obvious solution would be to > drop the PM8921 compatibility since it's only probable and nothing proves it's right. Although it is obvious solution it is also affecting all out-of-tree users of DTS. > > But what's sure: it's a PM8018 PMIC. I could not find the spec for both of these, but similar numbers have for example exactly the same RTC. I guess other blocks are also the same. > > But since the PM8018 PWRKEY interface is compatible with the PM8921 PWRKEY interface, > it's perfectly ok to the the MP8921 compatible here. > > OK, so as you quoted multiple times: > "How this should be fixed? First, drop bogus entries from drivers, then > document proper compatibles." > > OK so there's no bogus entries to remove here, and the only compatible to > potentially document is the pm8018-pwrkey but it seems to be wrong. All the entries in drivers which are duplicating the fallback are not needed. I called them bogus because adding them brought no meaning. > I'll be happy to have an hint on how to handle that to I can go forward and > stop the noise, there's still plenty of stuff to fix in the MDM9615 DT. Drop the unneeded entries from the driver, document (properly) the compatible how it is used in DTS (so not in some other way than DTS expresses it). Best regards, Krzysztof
diff --git a/arch/arm/boot/dts/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom-mdm9615.dtsi index 792aa98cc136..935f7b222200 100644 --- a/arch/arm/boot/dts/qcom-mdm9615.dtsi +++ b/arch/arm/boot/dts/qcom-mdm9615.dtsi @@ -247,7 +247,7 @@ qcom,ssbi@500000 { qcom,controller-type = "pmic-arbiter"; pmicintc: pmic@0 { - compatible = "qcom,pm8018", "qcom,pm8921"; + compatible = "qcom,pm8018"; interrupts = <GIC_PPI 226 IRQ_TYPE_LEVEL_HIGH>; #interrupt-cells = <2>; interrupt-controller; @@ -255,7 +255,7 @@ pmicintc: pmic@0 { #size-cells = <0>; pwrkey@1c { - compatible = "qcom,pm8018-pwrkey", "qcom,pm8921-pwrkey"; + compatible = "qcom,pm8921-pwrkey"; reg = <0x1c>; interrupt-parent = <&pmicintc>; interrupts = <50 IRQ_TYPE_EDGE_RISING>, @@ -275,7 +275,7 @@ pmicmpp: mpps@50 { }; rtc@11d { - compatible = "qcom,pm8018-rtc", "qcom,pm8921-rtc"; + compatible = "qcom,pm8018-rtc"; interrupt-parent = <&pmicintc>; interrupts = <39 IRQ_TYPE_EDGE_RISING>; reg = <0x11d>;
The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles was left but it makes no sense anymore the leave both. The pwrkey compatible is left to PM8921, unlike the others because the interface is stricly compatible with the PM9821 pwrkey. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>