* [PATCH 0/6] Add Apple Mac System Management Controller GPIOs @ 2022-09-01 13:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, devicetree, Hector Martin, Krzysztof Kozlowski, linux-arm-kernel, linux-gpio, Rob Herring, Sven Peter Hi, This series adds support for the Apple Mac GPIO driver. These GPIOs are hadled via the System Management Controller. The first two patches add the DT binding documentation for the new drivers. The second two patches add the core System Management Controller support. The last two patches add the GPIO support. DT updates will follow once the bindings have been reviewed. Patches taken from the Asahi project. .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 ++ .../devicetree/bindings/mfd/apple,smc.yaml | 57 +++ drivers/gpio/Kconfig | 11 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 394 ++++++++++++++++++ drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 49 +++ drivers/platform/apple/Makefile | 11 + drivers/platform/apple/smc.h | 28 ++ drivers/platform/apple/smc_core.c | 249 ++++++++++++ drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++ drivers/soc/apple/rtkit.c | 6 + include/linux/mfd/macsmc.h | 86 ++++ include/linux/soc/apple/rtkit.h | 12 + 15 files changed, 1386 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml create mode 100644 drivers/gpio/gpio-macsmc.c create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/smc.h create mode 100644 drivers/platform/apple/smc_core.c create mode 100644 drivers/platform/apple/smc_rtkit.c create mode 100644 include/linux/mfd/macsmc.h -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH 0/6] Add Apple Mac System Management Controller GPIOs @ 2022-09-01 13:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, devicetree, Hector Martin, Krzysztof Kozlowski, linux-arm-kernel, linux-gpio, Rob Herring, Sven Peter Hi, This series adds support for the Apple Mac GPIO driver. These GPIOs are hadled via the System Management Controller. The first two patches add the DT binding documentation for the new drivers. The second two patches add the core System Management Controller support. The last two patches add the GPIO support. DT updates will follow once the bindings have been reviewed. Patches taken from the Asahi project. .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 ++ .../devicetree/bindings/mfd/apple,smc.yaml | 57 +++ drivers/gpio/Kconfig | 11 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 394 ++++++++++++++++++ drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 49 +++ drivers/platform/apple/Makefile | 11 + drivers/platform/apple/smc.h | 28 ++ drivers/platform/apple/smc_core.c | 249 ++++++++++++ drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++ drivers/soc/apple/rtkit.c | 6 + include/linux/mfd/macsmc.h | 86 ++++ include/linux/soc/apple/rtkit.h | 12 + 15 files changed, 1386 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml create mode 100644 drivers/gpio/gpio-macsmc.c create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/smc.h create mode 100644 drivers/platform/apple/smc_core.c create mode 100644 drivers/platform/apple/smc_rtkit.c create mode 100644 include/linux/mfd/macsmc.h -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 13:54 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree Add a DT binding for the Apple Mac System Management Controller. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/mfd/apple,smc.yaml | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml new file mode 100644 index 000000000000..794d3a6eb04a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller implements various functions + such as GPIO, RTC, power, reboot. + +properties: + compatible: + items: + - enum: + - apple,t8103-smc + - apple,t8112-smc + - apple,t6000-smc + - const: apple,smc + + reg: + description: Two regions, one for the SMC area and one for the SRAM area. + + reg-names: + items: + - const: smc + - const: sram + + mboxes: + description: + A phandle to the mailbox channel + +additionalProperties: false + +required: + - compatible + - reg + - reg-names + - mboxes + +examples: + - | + smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + }; -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 13:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree Add a DT binding for the Apple Mac System Management Controller. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/mfd/apple,smc.yaml | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml new file mode 100644 index 000000000000..794d3a6eb04a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller implements various functions + such as GPIO, RTC, power, reboot. + +properties: + compatible: + items: + - enum: + - apple,t8103-smc + - apple,t8112-smc + - apple,t6000-smc + - const: apple,smc + + reg: + description: Two regions, one for the SMC area and one for the SRAM area. + + reg-names: + items: + - const: smc + - const: sram + + mboxes: + description: + A phandle to the mailbox channel + +additionalProperties: false + +required: + - compatible + - reg + - reg-names + - mboxes + +examples: + - | + smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + }; -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 15:06 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:06 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 16:54, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Thank you for your patch. There is something to discuss/improve. > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller implements various functions > + such as GPIO, RTC, power, reboot. > + > +properties: > + compatible: > + items: > + - enum: > + - apple,t8103-smc You miss two spaces of indentation on this level. > + - apple,t8112-smc > + - apple,t6000-smc Bring some order here - either alphabetical or by date of release (as in other Apple schemas). I think t6000 was before t8112, so it's none of that orders. > + - const: apple,smc > + > + reg: > + description: Two regions, one for the SMC area and one for the SRAM area. You need constraints for size/order, so in this context list with described items. > + > + reg-names: > + items: > + - const: smc > + - const: sram > + > + mboxes: > + description: > + A phandle to the mailbox channel Missing maxItems > + > +additionalProperties: false > + Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 15:06 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:06 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 16:54, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Thank you for your patch. There is something to discuss/improve. > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller implements various functions > + such as GPIO, RTC, power, reboot. > + > +properties: > + compatible: > + items: > + - enum: > + - apple,t8103-smc You miss two spaces of indentation on this level. > + - apple,t8112-smc > + - apple,t6000-smc Bring some order here - either alphabetical or by date of release (as in other Apple schemas). I think t6000 was before t8112, so it's none of that orders. > + - const: apple,smc > + > + reg: > + description: Two regions, one for the SMC area and one for the SRAM area. You need constraints for size/order, so in this context list with described items. > + > + reg-names: > + items: > + - const: smc > + - const: sram > + > + mboxes: > + description: > + A phandle to the mailbox channel Missing maxItems > + > +additionalProperties: false > + Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:06 ` Krzysztof Kozlowski @ 2022-09-01 15:12 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:12 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:06:17PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 16:54, Russell King (Oracle) wrote: > > Add a DT binding for the Apple Mac System Management Controller. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Thank you for your patch. There is something to discuss/improve. > > > + > > +maintainers: > > + - Hector Martin <marcan@marcan.st> > > + > > +description: > > + Apple Mac System Management Controller implements various functions > > + such as GPIO, RTC, power, reboot. > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - apple,t8103-smc > > You miss two spaces of indentation on this level. Should that be picked up by the dt checker? > > + - apple,t8112-smc > > + - apple,t6000-smc > > Bring some order here - either alphabetical or by date of release (as in > other Apple schemas). I think t6000 was before t8112, so it's none of > that orders. Ok. > > + - const: apple,smc > > + > > + reg: > > + description: Two regions, one for the SMC area and one for the SRAM area. > > You need constraints for size/order, so in this context list with > described items. How do I do that? I tried maxItems/minItems set to 2, but the dt checker objected to it. > > + reg-names: > > + items: > > + - const: smc > > + - const: sram > > + > > + mboxes: > > + description: > > + A phandle to the mailbox channel > > Missing maxItems Ok. Would be helpful if the dt checker identified that. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 15:12 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:12 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:06:17PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 16:54, Russell King (Oracle) wrote: > > Add a DT binding for the Apple Mac System Management Controller. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Thank you for your patch. There is something to discuss/improve. > > > + > > +maintainers: > > + - Hector Martin <marcan@marcan.st> > > + > > +description: > > + Apple Mac System Management Controller implements various functions > > + such as GPIO, RTC, power, reboot. > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - apple,t8103-smc > > You miss two spaces of indentation on this level. Should that be picked up by the dt checker? > > + - apple,t8112-smc > > + - apple,t6000-smc > > Bring some order here - either alphabetical or by date of release (as in > other Apple schemas). I think t6000 was before t8112, so it's none of > that orders. Ok. > > + - const: apple,smc > > + > > + reg: > > + description: Two regions, one for the SMC area and one for the SRAM area. > > You need constraints for size/order, so in this context list with > described items. How do I do that? I tried maxItems/minItems set to 2, but the dt checker objected to it. > > + reg-names: > > + items: > > + - const: smc > > + - const: sram > > + > > + mboxes: > > + description: > > + A phandle to the mailbox channel > > Missing maxItems Ok. Would be helpful if the dt checker identified that. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:12 ` Russell King (Oracle) @ 2022-09-01 15:15 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:15 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 18:12, Russell King (Oracle) wrote: >>> + compatible: >>> + items: >>> + - enum: >>> + - apple,t8103-smc >> >> You miss two spaces of indentation on this level. > > Should that be picked up by the dt checker? I think yamllint complains about it. It is not a hard-dependency, so maybe you don't have it installed. > >>> + - apple,t8112-smc >>> + - apple,t6000-smc >> >> Bring some order here - either alphabetical or by date of release (as in >> other Apple schemas). I think t6000 was before t8112, so it's none of >> that orders. > > Ok. > >>> + - const: apple,smc >>> + >>> + reg: >>> + description: Two regions, one for the SMC area and one for the SRAM area. >> >> You need constraints for size/order, so in this context list with >> described items. > > How do I do that? I tried maxItems/minItems set to 2, but the dt checker > objected to it. One way: reg: items: - description: SMC area - description: SRAM area but actually this is very similar what you wrote for reg-names - kind of obvious, so easier way: reg: maxItems: 2 > >>> + reg-names: >>> + items: >>> + - const: smc >>> + - const: sram >>> + >>> + mboxes: >>> + description: >>> + A phandle to the mailbox channel >> >> Missing maxItems > > Ok. Would be helpful if the dt checker identified that. Patches are welcomed :) Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 15:15 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:15 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 18:12, Russell King (Oracle) wrote: >>> + compatible: >>> + items: >>> + - enum: >>> + - apple,t8103-smc >> >> You miss two spaces of indentation on this level. > > Should that be picked up by the dt checker? I think yamllint complains about it. It is not a hard-dependency, so maybe you don't have it installed. > >>> + - apple,t8112-smc >>> + - apple,t6000-smc >> >> Bring some order here - either alphabetical or by date of release (as in >> other Apple schemas). I think t6000 was before t8112, so it's none of >> that orders. > > Ok. > >>> + - const: apple,smc >>> + >>> + reg: >>> + description: Two regions, one for the SMC area and one for the SRAM area. >> >> You need constraints for size/order, so in this context list with >> described items. > > How do I do that? I tried maxItems/minItems set to 2, but the dt checker > objected to it. One way: reg: items: - description: SMC area - description: SRAM area but actually this is very similar what you wrote for reg-names - kind of obvious, so easier way: reg: maxItems: 2 > >>> + reg-names: >>> + items: >>> + - const: smc >>> + - const: sram >>> + >>> + mboxes: >>> + description: >>> + A phandle to the mailbox channel >> >> Missing maxItems > > Ok. Would be helpful if the dt checker identified that. Patches are welcomed :) Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:15 ` Krzysztof Kozlowski @ 2022-09-01 15:24 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:24 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 18:12, Russell King (Oracle) wrote: > >>> + compatible: > >>> + items: > >>> + - enum: > >>> + - apple,t8103-smc > >> > >> You miss two spaces of indentation on this level. > > > > Should that be picked up by the dt checker? > > I think yamllint complains about it. It is not a hard-dependency, so > maybe you don't have it installed. > > > > >>> + - apple,t8112-smc > >>> + - apple,t6000-smc > >> > >> Bring some order here - either alphabetical or by date of release (as in > >> other Apple schemas). I think t6000 was before t8112, so it's none of > >> that orders. > > > > Ok. > > > >>> + - const: apple,smc > >>> + > >>> + reg: > >>> + description: Two regions, one for the SMC area and one for the SRAM area. > >> > >> You need constraints for size/order, so in this context list with > >> described items. > > > > How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > objected to it. > > One way: > reg: > items: > - description: SMC area > - description: SRAM area > > but actually this is very similar what you wrote for reg-names - kind of > obvious, so easier way: > > reg: > maxItems: 2 Doesn't work. With maxItems: 2, the example fails, yet it correctly lists two regs which are 64-bit address and 64-bit size - so in total 8 32-bit ints. Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml Hence, I originally had maxItems: 2, and ended up deleting it because of the dt checker. With the two descriptions, it's the same failure. I think the problem is that the checker has no knowledge in the example of how big each address and size element of the reg property is. So, it's interpreting it as four entries of 32-bit address,size pairs instead of two entries of 64-bit address,size pairs. Yep, that's it, if I increase the number of "- description" entries to four then it's happy. So, what's the solution? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 15:24 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:24 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 18:12, Russell King (Oracle) wrote: > >>> + compatible: > >>> + items: > >>> + - enum: > >>> + - apple,t8103-smc > >> > >> You miss two spaces of indentation on this level. > > > > Should that be picked up by the dt checker? > > I think yamllint complains about it. It is not a hard-dependency, so > maybe you don't have it installed. > > > > >>> + - apple,t8112-smc > >>> + - apple,t6000-smc > >> > >> Bring some order here - either alphabetical or by date of release (as in > >> other Apple schemas). I think t6000 was before t8112, so it's none of > >> that orders. > > > > Ok. > > > >>> + - const: apple,smc > >>> + > >>> + reg: > >>> + description: Two regions, one for the SMC area and one for the SRAM area. > >> > >> You need constraints for size/order, so in this context list with > >> described items. > > > > How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > objected to it. > > One way: > reg: > items: > - description: SMC area > - description: SRAM area > > but actually this is very similar what you wrote for reg-names - kind of > obvious, so easier way: > > reg: > maxItems: 2 Doesn't work. With maxItems: 2, the example fails, yet it correctly lists two regs which are 64-bit address and 64-bit size - so in total 8 32-bit ints. Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml Hence, I originally had maxItems: 2, and ended up deleting it because of the dt checker. With the two descriptions, it's the same failure. I think the problem is that the checker has no knowledge in the example of how big each address and size element of the reg property is. So, it's interpreting it as four entries of 32-bit address,size pairs instead of two entries of 64-bit address,size pairs. Yep, that's it, if I increase the number of "- description" entries to four then it's happy. So, what's the solution? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:24 ` Russell King (Oracle) @ 2022-09-01 15:45 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:45 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 18:24, Russell King (Oracle) wrote: > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: >> On 01/09/2022 18:12, Russell King (Oracle) wrote: >>>>> + compatible: >>>>> + items: >>>>> + - enum: >>>>> + - apple,t8103-smc >>>> >>>> You miss two spaces of indentation on this level. >>> >>> Should that be picked up by the dt checker? >> >> I think yamllint complains about it. It is not a hard-dependency, so >> maybe you don't have it installed. >> >>> >>>>> + - apple,t8112-smc >>>>> + - apple,t6000-smc >>>> >>>> Bring some order here - either alphabetical or by date of release (as in >>>> other Apple schemas). I think t6000 was before t8112, so it's none of >>>> that orders. >>> >>> Ok. >>> >>>>> + - const: apple,smc >>>>> + >>>>> + reg: >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. >>>> >>>> You need constraints for size/order, so in this context list with >>>> described items. >>> >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker >>> objected to it. >> >> One way: >> reg: >> items: >> - description: SMC area >> - description: SRAM area >> >> but actually this is very similar what you wrote for reg-names - kind of >> obvious, so easier way: >> >> reg: >> maxItems: 2 > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > ints. > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > Hence, I originally had maxItems: 2, and ended up deleting it because of > the dt checker. > > With the two descriptions, it's the same failure. Yeah, they should create same result. > > I think the problem is that the checker has no knowledge in the example > of how big each address and size element of the reg property is. So, > it's interpreting it as four entries of 32-bit address,size pairs > instead of two entries of 64-bit address,size pairs. Yep, that's it, > if I increase the number of "- description" entries to four then it's > happy. > > So, what's the solution? > If you open generated DTS examples (in your kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which address/size cells are expected. By default it is I think address/size cells=1, so you need a bus node setting it to 2. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 15:45 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:45 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 18:24, Russell King (Oracle) wrote: > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: >> On 01/09/2022 18:12, Russell King (Oracle) wrote: >>>>> + compatible: >>>>> + items: >>>>> + - enum: >>>>> + - apple,t8103-smc >>>> >>>> You miss two spaces of indentation on this level. >>> >>> Should that be picked up by the dt checker? >> >> I think yamllint complains about it. It is not a hard-dependency, so >> maybe you don't have it installed. >> >>> >>>>> + - apple,t8112-smc >>>>> + - apple,t6000-smc >>>> >>>> Bring some order here - either alphabetical or by date of release (as in >>>> other Apple schemas). I think t6000 was before t8112, so it's none of >>>> that orders. >>> >>> Ok. >>> >>>>> + - const: apple,smc >>>>> + >>>>> + reg: >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. >>>> >>>> You need constraints for size/order, so in this context list with >>>> described items. >>> >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker >>> objected to it. >> >> One way: >> reg: >> items: >> - description: SMC area >> - description: SRAM area >> >> but actually this is very similar what you wrote for reg-names - kind of >> obvious, so easier way: >> >> reg: >> maxItems: 2 > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > ints. > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > Hence, I originally had maxItems: 2, and ended up deleting it because of > the dt checker. > > With the two descriptions, it's the same failure. Yeah, they should create same result. > > I think the problem is that the checker has no knowledge in the example > of how big each address and size element of the reg property is. So, > it's interpreting it as four entries of 32-bit address,size pairs > instead of two entries of 64-bit address,size pairs. Yep, that's it, > if I increase the number of "- description" entries to four then it's > happy. > > So, what's the solution? > If you open generated DTS examples (in your kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which address/size cells are expected. By default it is I think address/size cells=1, so you need a bus node setting it to 2. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:45 ` Krzysztof Kozlowski @ 2022-09-01 15:56 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:56 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > >>>>> + compatible: > >>>>> + items: > >>>>> + - enum: > >>>>> + - apple,t8103-smc > >>>> > >>>> You miss two spaces of indentation on this level. > >>> > >>> Should that be picked up by the dt checker? > >> > >> I think yamllint complains about it. It is not a hard-dependency, so > >> maybe you don't have it installed. > >> > >>> > >>>>> + - apple,t8112-smc > >>>>> + - apple,t6000-smc > >>>> > >>>> Bring some order here - either alphabetical or by date of release (as in > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > >>>> that orders. > >>> > >>> Ok. > >>> > >>>>> + - const: apple,smc > >>>>> + > >>>>> + reg: > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > >>>> > >>>> You need constraints for size/order, so in this context list with > >>>> described items. > >>> > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > >>> objected to it. > >> > >> One way: > >> reg: > >> items: > >> - description: SMC area > >> - description: SRAM area > >> > >> but actually this is very similar what you wrote for reg-names - kind of > >> obvious, so easier way: > >> > >> reg: > >> maxItems: 2 > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > ints. > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > the dt checker. > > > > With the two descriptions, it's the same failure. > > Yeah, they should create same result. > > > > > I think the problem is that the checker has no knowledge in the example > > of how big each address and size element of the reg property is. So, > > it's interpreting it as four entries of 32-bit address,size pairs > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > if I increase the number of "- description" entries to four then it's > > happy. > > > > So, what's the solution? > > > > If you open generated DTS examples (in your > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > address/size cells are expected. By default it is I think address/size > cells=1, so you need a bus node setting it to 2. Thanks, that works. The patch with all those points addressed now looks like: 8<=== From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management Controller Add a DT binding for the Apple Mac System Management Controller. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml new file mode 100644 index 000000000000..168f237c2962 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller implements various functions + such as GPIO, RTC, power, reboot. + +properties: + compatible: + items: + - enum: + - apple,t6000-smc + - apple,t8103-smc + - apple,t8112-smc + - const: apple,smc + + reg: + items: + - description: SMC area + - description: SRAM area + + reg-names: + items: + - const: smc + - const: sram + + mboxes: + maxItems: 1 + description: + A phandle to the mailbox channel + +additionalProperties: false + +required: + - compatible + - reg + - reg-names + - mboxes + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + }; + }; -- 2.30.2 -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 15:56 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:56 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > >>>>> + compatible: > >>>>> + items: > >>>>> + - enum: > >>>>> + - apple,t8103-smc > >>>> > >>>> You miss two spaces of indentation on this level. > >>> > >>> Should that be picked up by the dt checker? > >> > >> I think yamllint complains about it. It is not a hard-dependency, so > >> maybe you don't have it installed. > >> > >>> > >>>>> + - apple,t8112-smc > >>>>> + - apple,t6000-smc > >>>> > >>>> Bring some order here - either alphabetical or by date of release (as in > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > >>>> that orders. > >>> > >>> Ok. > >>> > >>>>> + - const: apple,smc > >>>>> + > >>>>> + reg: > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > >>>> > >>>> You need constraints for size/order, so in this context list with > >>>> described items. > >>> > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > >>> objected to it. > >> > >> One way: > >> reg: > >> items: > >> - description: SMC area > >> - description: SRAM area > >> > >> but actually this is very similar what you wrote for reg-names - kind of > >> obvious, so easier way: > >> > >> reg: > >> maxItems: 2 > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > ints. > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > the dt checker. > > > > With the two descriptions, it's the same failure. > > Yeah, they should create same result. > > > > > I think the problem is that the checker has no knowledge in the example > > of how big each address and size element of the reg property is. So, > > it's interpreting it as four entries of 32-bit address,size pairs > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > if I increase the number of "- description" entries to four then it's > > happy. > > > > So, what's the solution? > > > > If you open generated DTS examples (in your > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > address/size cells are expected. By default it is I think address/size > cells=1, so you need a bus node setting it to 2. Thanks, that works. The patch with all those points addressed now looks like: 8<=== From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management Controller Add a DT binding for the Apple Mac System Management Controller. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml new file mode 100644 index 000000000000..168f237c2962 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller implements various functions + such as GPIO, RTC, power, reboot. + +properties: + compatible: + items: + - enum: + - apple,t6000-smc + - apple,t8103-smc + - apple,t8112-smc + - const: apple,smc + + reg: + items: + - description: SMC area + - description: SRAM area + + reg-names: + items: + - const: smc + - const: sram + + mboxes: + maxItems: 1 + description: + A phandle to the mailbox channel + +additionalProperties: false + +required: + - compatible + - reg + - reg-names + - mboxes + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + }; + }; -- 2.30.2 -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:56 ` Russell King (Oracle) @ 2022-09-01 16:25 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 16:25 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 18:56, Russell King (Oracle) wrote: > > 8<=== > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > Controller > > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Yes, looks good. I won't add Reviewed-by tag, because I think it would confuse Patchwork, so please send a v2 at some point. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 16:25 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 16:25 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 18:56, Russell King (Oracle) wrote: > > 8<=== > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > Controller > > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Yes, looks good. I won't add Reviewed-by tag, because I think it would confuse Patchwork, so please send a v2 at some point. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 16:25 ` Krzysztof Kozlowski @ 2022-09-01 16:47 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 16:47 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > 8<=== > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > Controller > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Yes, looks good. > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > so please send a v2 at some point. Thanks. Do you have any suggestions for patch 2? Should I merge the description in patch 2 into this file? The full dts for this series looks like this: smc: smc@23e400000 { compatible = "apple,t8103-smc", "apple,smc"; reg = <0x2 0x3e400000 0x0 0x4000>, <0x2 0x3fe00000 0x0 0x100000>; reg-names = "smc", "sram"; mboxes = <&smc_mbox>; smc_gpio: gpio { gpio-controller; #gpio-cells = <2>; }; }; but the fuller version in the asahi linux tree looks like: smc: smc@23e400000 { compatible = "apple,t8103-smc", "apple,smc"; reg = <0x2 0x3e400000 0x0 0x4000>, <0x2 0x3fe00000 0x0 0x100000>; reg-names = "smc", "sram"; mboxes = <&smc_mbox>; smc_gpio: gpio { gpio-controller; #gpio-cells = <2>; }; smc_rtc: rtc { nvmem-cells = <&rtc_offset>; nvmem-cell-names = "rtc_offset"; }; smc_reboot: reboot { nvmem-cells = <&shutdown_flag>, <&boot_stage>, <&boot_error_count>, <&panic_count>, <&pm_setting>; nvmem-cell-names = "shutdown_flag", "boot_stage", "boot_error_count", "panic_count", "pm_setting"; }; }; So whatever is decided for the gpio node would eventually also apply to the other nodes too. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 16:47 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 16:47 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > 8<=== > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > Controller > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Yes, looks good. > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > so please send a v2 at some point. Thanks. Do you have any suggestions for patch 2? Should I merge the description in patch 2 into this file? The full dts for this series looks like this: smc: smc@23e400000 { compatible = "apple,t8103-smc", "apple,smc"; reg = <0x2 0x3e400000 0x0 0x4000>, <0x2 0x3fe00000 0x0 0x100000>; reg-names = "smc", "sram"; mboxes = <&smc_mbox>; smc_gpio: gpio { gpio-controller; #gpio-cells = <2>; }; }; but the fuller version in the asahi linux tree looks like: smc: smc@23e400000 { compatible = "apple,t8103-smc", "apple,smc"; reg = <0x2 0x3e400000 0x0 0x4000>, <0x2 0x3fe00000 0x0 0x100000>; reg-names = "smc", "sram"; mboxes = <&smc_mbox>; smc_gpio: gpio { gpio-controller; #gpio-cells = <2>; }; smc_rtc: rtc { nvmem-cells = <&rtc_offset>; nvmem-cell-names = "rtc_offset"; }; smc_reboot: reboot { nvmem-cells = <&shutdown_flag>, <&boot_stage>, <&boot_error_count>, <&panic_count>, <&pm_setting>; nvmem-cell-names = "shutdown_flag", "boot_stage", "boot_error_count", "panic_count", "pm_setting"; }; }; So whatever is decided for the gpio node would eventually also apply to the other nodes too. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 16:47 ` Russell King (Oracle) @ 2022-09-01 22:33 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-01 22:33 UTC (permalink / raw) To: Russell King (Oracle) Cc: Krzysztof Kozlowski, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter, Krzysztof Kozlowski, devicetree On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > 8<=== > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > Controller > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > Yes, looks good. > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > so please send a v2 at some point. > > Thanks. Do you have any suggestions for patch 2? Should I merge the > description in patch 2 into this file? > > The full dts for this series looks like this: > > smc: smc@23e400000 { > compatible = "apple,t8103-smc", "apple,smc"; > reg = <0x2 0x3e400000 0x0 0x4000>, > <0x2 0x3fe00000 0x0 0x100000>; > reg-names = "smc", "sram"; > mboxes = <&smc_mbox>; > > smc_gpio: gpio { > gpio-controller; > #gpio-cells = <2>; > }; > }; > > but the fuller version in the asahi linux tree looks like: > > smc: smc@23e400000 { > compatible = "apple,t8103-smc", "apple,smc"; > reg = <0x2 0x3e400000 0x0 0x4000>, > <0x2 0x3fe00000 0x0 0x100000>; > reg-names = "smc", "sram"; > mboxes = <&smc_mbox>; > > smc_gpio: gpio { > gpio-controller; > #gpio-cells = <2>; Only 2 properties doesn't really need its own schema doc. However, I would just move these to the parent node. > }; > > smc_rtc: rtc { > nvmem-cells = <&rtc_offset>; > nvmem-cell-names = "rtc_offset"; > }; > > smc_reboot: reboot { > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > <&boot_error_count>, <&panic_count>, <&pm_setting>; > nvmem-cell-names = "shutdown_flag", "boot_stage", > "boot_error_count", "panic_count", "pm_setting"; Not really much reason to split these up either because you can just fetch the entry you want by name. How confident are the asahi folks that this is a complete binding? Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 22:33 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-01 22:33 UTC (permalink / raw) To: Russell King (Oracle) Cc: Krzysztof Kozlowski, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter, Krzysztof Kozlowski, devicetree On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > 8<=== > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > Controller > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > Yes, looks good. > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > so please send a v2 at some point. > > Thanks. Do you have any suggestions for patch 2? Should I merge the > description in patch 2 into this file? > > The full dts for this series looks like this: > > smc: smc@23e400000 { > compatible = "apple,t8103-smc", "apple,smc"; > reg = <0x2 0x3e400000 0x0 0x4000>, > <0x2 0x3fe00000 0x0 0x100000>; > reg-names = "smc", "sram"; > mboxes = <&smc_mbox>; > > smc_gpio: gpio { > gpio-controller; > #gpio-cells = <2>; > }; > }; > > but the fuller version in the asahi linux tree looks like: > > smc: smc@23e400000 { > compatible = "apple,t8103-smc", "apple,smc"; > reg = <0x2 0x3e400000 0x0 0x4000>, > <0x2 0x3fe00000 0x0 0x100000>; > reg-names = "smc", "sram"; > mboxes = <&smc_mbox>; > > smc_gpio: gpio { > gpio-controller; > #gpio-cells = <2>; Only 2 properties doesn't really need its own schema doc. However, I would just move these to the parent node. > }; > > smc_rtc: rtc { > nvmem-cells = <&rtc_offset>; > nvmem-cell-names = "rtc_offset"; > }; > > smc_reboot: reboot { > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > <&boot_error_count>, <&panic_count>, <&pm_setting>; > nvmem-cell-names = "shutdown_flag", "boot_stage", > "boot_error_count", "panic_count", "pm_setting"; Not really much reason to split these up either because you can just fetch the entry you want by name. How confident are the asahi folks that this is a complete binding? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 22:33 ` Rob Herring @ 2022-09-02 15:06 ` Mark Kettenis -1 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-02 15:06 UTC (permalink / raw) To: Rob Herring Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > From: Rob Herring <robh+dt@kernel.org> > Date: Thu, 1 Sep 2022 17:33:31 -0500 > > On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > > > 8<=== > > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > > Controller > > > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > > Yes, looks good. > > > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > > so please send a v2 at some point. > > > > Thanks. Do you have any suggestions for patch 2? Should I merge the > > description in patch 2 into this file? > > > > The full dts for this series looks like this: > > > > smc: smc@23e400000 { > > compatible = "apple,t8103-smc", "apple,smc"; > > reg = <0x2 0x3e400000 0x0 0x4000>, > > <0x2 0x3fe00000 0x0 0x100000>; > > reg-names = "smc", "sram"; > > mboxes = <&smc_mbox>; > > > > smc_gpio: gpio { > > gpio-controller; > > #gpio-cells = <2>; > > }; > > }; > > > > but the fuller version in the asahi linux tree looks like: > > > > smc: smc@23e400000 { > > compatible = "apple,t8103-smc", "apple,smc"; > > reg = <0x2 0x3e400000 0x0 0x4000>, > > <0x2 0x3fe00000 0x0 0x100000>; > > reg-names = "smc", "sram"; > > mboxes = <&smc_mbox>; > > > > smc_gpio: gpio { > > gpio-controller; > > #gpio-cells = <2>; > > Only 2 properties doesn't really need its own schema doc. However, I > would just move these to the parent node. When we designed the bindings, it was our understanding that having separate nodes better matches Linux's MFD driver model. Please be aware that OpenBSD is already using these bindings. If there are good reasons for moving things, we can probably deal with that. But this sounds a bit like a toss up. > > > }; > > > > smc_rtc: rtc { > > nvmem-cells = <&rtc_offset>; > > nvmem-cell-names = "rtc_offset"; > > }; > > > > smc_reboot: reboot { > > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > > <&boot_error_count>, <&panic_count>, <&pm_setting>; > > nvmem-cell-names = "shutdown_flag", "boot_stage", > > "boot_error_count", "panic_count", "pm_setting"; > > Not really much reason to split these up either because you can just > fetch the entry you want by name. Again the separate nodes are there because the RTC and the reboot functionality are logically separate and handled by different MFD sub-drivers in Linux. > How confident are the asahi folks that this is a complete binding? There is a lot of functionality in the SMC that is still largely unexplored. The idea of the design of the binding is that additional functionality may be added by adding more subnodes to the smc node. But we expect that the main SMC node itself should be complete with the "smc" and "sram" regions and the reference to the mailbox. Cheers, Mark ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-02 15:06 ` Mark Kettenis 0 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-02 15:06 UTC (permalink / raw) To: Rob Herring Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > From: Rob Herring <robh+dt@kernel.org> > Date: Thu, 1 Sep 2022 17:33:31 -0500 > > On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > > > 8<=== > > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > > Controller > > > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > > Yes, looks good. > > > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > > so please send a v2 at some point. > > > > Thanks. Do you have any suggestions for patch 2? Should I merge the > > description in patch 2 into this file? > > > > The full dts for this series looks like this: > > > > smc: smc@23e400000 { > > compatible = "apple,t8103-smc", "apple,smc"; > > reg = <0x2 0x3e400000 0x0 0x4000>, > > <0x2 0x3fe00000 0x0 0x100000>; > > reg-names = "smc", "sram"; > > mboxes = <&smc_mbox>; > > > > smc_gpio: gpio { > > gpio-controller; > > #gpio-cells = <2>; > > }; > > }; > > > > but the fuller version in the asahi linux tree looks like: > > > > smc: smc@23e400000 { > > compatible = "apple,t8103-smc", "apple,smc"; > > reg = <0x2 0x3e400000 0x0 0x4000>, > > <0x2 0x3fe00000 0x0 0x100000>; > > reg-names = "smc", "sram"; > > mboxes = <&smc_mbox>; > > > > smc_gpio: gpio { > > gpio-controller; > > #gpio-cells = <2>; > > Only 2 properties doesn't really need its own schema doc. However, I > would just move these to the parent node. When we designed the bindings, it was our understanding that having separate nodes better matches Linux's MFD driver model. Please be aware that OpenBSD is already using these bindings. If there are good reasons for moving things, we can probably deal with that. But this sounds a bit like a toss up. > > > }; > > > > smc_rtc: rtc { > > nvmem-cells = <&rtc_offset>; > > nvmem-cell-names = "rtc_offset"; > > }; > > > > smc_reboot: reboot { > > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > > <&boot_error_count>, <&panic_count>, <&pm_setting>; > > nvmem-cell-names = "shutdown_flag", "boot_stage", > > "boot_error_count", "panic_count", "pm_setting"; > > Not really much reason to split these up either because you can just > fetch the entry you want by name. Again the separate nodes are there because the RTC and the reboot functionality are logically separate and handled by different MFD sub-drivers in Linux. > How confident are the asahi folks that this is a complete binding? There is a lot of functionality in the SMC that is still largely unexplored. The idea of the design of the binding is that additional functionality may be added by adding more subnodes to the smc node. But we expect that the main SMC node itself should be complete with the "smc" and "sram" regions and the reference to the mailbox. Cheers, Mark _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-02 15:06 ` Mark Kettenis @ 2022-09-02 17:28 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-02 17:28 UTC (permalink / raw) To: Mark Kettenis Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 05:06:43PM +0200, Mark Kettenis wrote: > > From: Rob Herring <robh+dt@kernel.org> > > Date: Thu, 1 Sep 2022 17:33:31 -0500 > > > > On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > > > > > 8<=== > > > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > > > Controller > > > > > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > > > > Yes, looks good. > > > > > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > > > so please send a v2 at some point. > > > > > > Thanks. Do you have any suggestions for patch 2? Should I merge the > > > description in patch 2 into this file? > > > > > > The full dts for this series looks like this: > > > > > > smc: smc@23e400000 { > > > compatible = "apple,t8103-smc", "apple,smc"; > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > <0x2 0x3fe00000 0x0 0x100000>; > > > reg-names = "smc", "sram"; > > > mboxes = <&smc_mbox>; > > > > > > smc_gpio: gpio { > > > gpio-controller; > > > #gpio-cells = <2>; > > > }; > > > }; > > > > > > but the fuller version in the asahi linux tree looks like: > > > > > > smc: smc@23e400000 { > > > compatible = "apple,t8103-smc", "apple,smc"; > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > <0x2 0x3fe00000 0x0 0x100000>; > > > reg-names = "smc", "sram"; > > > mboxes = <&smc_mbox>; > > > > > > smc_gpio: gpio { > > > gpio-controller; > > > #gpio-cells = <2>; > > > > Only 2 properties doesn't really need its own schema doc. However, I > > would just move these to the parent node. > > When we designed the bindings, it was our understanding that having > separate nodes better matches Linux's MFD driver model. Well, it is convenient to have subnodes with compatibles so that your drivers automagically probe. So yes, a 1:1 relationship of nodes to drivers is nice and tidy. But h/w is not always packaged up neatly and it's not DT's job to try to abstract it such that it is. Also, we shouldn't design bindings around the *current* driver partitioning of some OS. This one is actually pretty odd in that the child nodes don't have a compatible string which breaks the automagical probing. > Please be aware that OpenBSD is already using these bindings. If > there are good reasons for moving things, we can probably deal with > that. But this sounds a bit like a toss up. Sigh. If there are other bindings in use, please submit them even if the Linux driver isn't ready. If a Linux subsystem maintainer doesn't want to take it, then I will. It is a toss up though... > > > }; > > > > > > smc_rtc: rtc { > > > nvmem-cells = <&rtc_offset>; > > > nvmem-cell-names = "rtc_offset"; > > > }; > > > > > > smc_reboot: reboot { > > > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > > > <&boot_error_count>, <&panic_count>, <&pm_setting>; > > > nvmem-cell-names = "shutdown_flag", "boot_stage", > > > "boot_error_count", "panic_count", "pm_setting"; > > > > Not really much reason to split these up either because you can just > > fetch the entry you want by name. > > Again the separate nodes are there because the RTC and the reboot > functionality are logically separate and handled by different MFD > sub-drivers in Linux. It's really a question of whether the subset of functionality is going to get reused on its own or has its own resources in DT. MFD bindings are done both ways. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-02 17:28 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-02 17:28 UTC (permalink / raw) To: Mark Kettenis Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 05:06:43PM +0200, Mark Kettenis wrote: > > From: Rob Herring <robh+dt@kernel.org> > > Date: Thu, 1 Sep 2022 17:33:31 -0500 > > > > On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > > > > > 8<=== > > > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > > > Controller > > > > > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > > > > Yes, looks good. > > > > > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > > > so please send a v2 at some point. > > > > > > Thanks. Do you have any suggestions for patch 2? Should I merge the > > > description in patch 2 into this file? > > > > > > The full dts for this series looks like this: > > > > > > smc: smc@23e400000 { > > > compatible = "apple,t8103-smc", "apple,smc"; > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > <0x2 0x3fe00000 0x0 0x100000>; > > > reg-names = "smc", "sram"; > > > mboxes = <&smc_mbox>; > > > > > > smc_gpio: gpio { > > > gpio-controller; > > > #gpio-cells = <2>; > > > }; > > > }; > > > > > > but the fuller version in the asahi linux tree looks like: > > > > > > smc: smc@23e400000 { > > > compatible = "apple,t8103-smc", "apple,smc"; > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > <0x2 0x3fe00000 0x0 0x100000>; > > > reg-names = "smc", "sram"; > > > mboxes = <&smc_mbox>; > > > > > > smc_gpio: gpio { > > > gpio-controller; > > > #gpio-cells = <2>; > > > > Only 2 properties doesn't really need its own schema doc. However, I > > would just move these to the parent node. > > When we designed the bindings, it was our understanding that having > separate nodes better matches Linux's MFD driver model. Well, it is convenient to have subnodes with compatibles so that your drivers automagically probe. So yes, a 1:1 relationship of nodes to drivers is nice and tidy. But h/w is not always packaged up neatly and it's not DT's job to try to abstract it such that it is. Also, we shouldn't design bindings around the *current* driver partitioning of some OS. This one is actually pretty odd in that the child nodes don't have a compatible string which breaks the automagical probing. > Please be aware that OpenBSD is already using these bindings. If > there are good reasons for moving things, we can probably deal with > that. But this sounds a bit like a toss up. Sigh. If there are other bindings in use, please submit them even if the Linux driver isn't ready. If a Linux subsystem maintainer doesn't want to take it, then I will. It is a toss up though... > > > }; > > > > > > smc_rtc: rtc { > > > nvmem-cells = <&rtc_offset>; > > > nvmem-cell-names = "rtc_offset"; > > > }; > > > > > > smc_reboot: reboot { > > > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > > > <&boot_error_count>, <&panic_count>, <&pm_setting>; > > > nvmem-cell-names = "shutdown_flag", "boot_stage", > > > "boot_error_count", "panic_count", "pm_setting"; > > > > Not really much reason to split these up either because you can just > > fetch the entry you want by name. > > Again the separate nodes are there because the RTC and the reboot > functionality are logically separate and handled by different MFD > sub-drivers in Linux. It's really a question of whether the subset of functionality is going to get reused on its own or has its own resources in DT. MFD bindings are done both ways. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-02 17:28 ` Rob Herring @ 2022-09-05 10:24 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 10:24 UTC (permalink / raw) To: Rob Herring Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > On Fri, Sep 02, 2022 at 05:06:43PM +0200, Mark Kettenis wrote: > > > From: Rob Herring <robh+dt@kernel.org> > > > Date: Thu, 1 Sep 2022 17:33:31 -0500 > > > > > > On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > > > > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > > > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > > > > > > > 8<=== > > > > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > > > > Controller > > > > > > > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > > > > > > Yes, looks good. > > > > > > > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > > > > so please send a v2 at some point. > > > > > > > > Thanks. Do you have any suggestions for patch 2? Should I merge the > > > > description in patch 2 into this file? > > > > > > > > The full dts for this series looks like this: > > > > > > > > smc: smc@23e400000 { > > > > compatible = "apple,t8103-smc", "apple,smc"; > > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > > <0x2 0x3fe00000 0x0 0x100000>; > > > > reg-names = "smc", "sram"; > > > > mboxes = <&smc_mbox>; > > > > > > > > smc_gpio: gpio { > > > > gpio-controller; > > > > #gpio-cells = <2>; > > > > }; > > > > }; > > > > > > > > but the fuller version in the asahi linux tree looks like: > > > > > > > > smc: smc@23e400000 { > > > > compatible = "apple,t8103-smc", "apple,smc"; > > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > > <0x2 0x3fe00000 0x0 0x100000>; > > > > reg-names = "smc", "sram"; > > > > mboxes = <&smc_mbox>; > > > > > > > > smc_gpio: gpio { > > > > gpio-controller; > > > > #gpio-cells = <2>; > > > > > > Only 2 properties doesn't really need its own schema doc. However, I > > > would just move these to the parent node. > > > > When we designed the bindings, it was our understanding that having > > separate nodes better matches Linux's MFD driver model. > > Well, it is convenient to have subnodes with compatibles so that your > drivers automagically probe. So yes, a 1:1 relationship of nodes to > drivers is nice and tidy. But h/w is not always packaged up neatly and > it's not DT's job to try to abstract it such that it is. Also, we > shouldn't design bindings around the *current* driver partitioning of > some OS. > > This one is actually pretty odd in that the child nodes don't have a > compatible string which breaks the automagical probing. > > > Please be aware that OpenBSD is already using these bindings. If > > there are good reasons for moving things, we can probably deal with > > that. But this sounds a bit like a toss up. > > Sigh. If there are other bindings in use, please submit them even if the > Linux driver isn't ready. If a Linux subsystem maintainer doesn't want > to take it, then I will. > > It is a toss up though... > > > > > }; > > > > > > > > smc_rtc: rtc { > > > > nvmem-cells = <&rtc_offset>; > > > > nvmem-cell-names = "rtc_offset"; > > > > }; > > > > > > > > smc_reboot: reboot { > > > > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > > > > <&boot_error_count>, <&panic_count>, <&pm_setting>; > > > > nvmem-cell-names = "shutdown_flag", "boot_stage", > > > > "boot_error_count", "panic_count", "pm_setting"; > > > > > > Not really much reason to split these up either because you can just > > > fetch the entry you want by name. > > > > Again the separate nodes are there because the RTC and the reboot > > functionality are logically separate and handled by different MFD > > sub-drivers in Linux. > > It's really a question of whether the subset of functionality is going > to get reused on its own or has its own resources in DT. MFD bindings > are done both ways. I'm guessing this series is blocked until a resolution is found for the DT binding description. Please can the Asahi folk and the DT maintainers sort this out and let me know when I can proceed with this patch set. I'm just the man in the middle here. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-05 10:24 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 10:24 UTC (permalink / raw) To: Rob Herring Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > On Fri, Sep 02, 2022 at 05:06:43PM +0200, Mark Kettenis wrote: > > > From: Rob Herring <robh+dt@kernel.org> > > > Date: Thu, 1 Sep 2022 17:33:31 -0500 > > > > > > On Thu, Sep 1, 2022 at 11:47 AM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > > > > > On Thu, Sep 01, 2022 at 07:25:03PM +0300, Krzysztof Kozlowski wrote: > > > > > On 01/09/2022 18:56, Russell King (Oracle) wrote: > > > > > > > > > > > > 8<=== > > > > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > > > > Controller > > > > > > > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > > > > > > > Yes, looks good. > > > > > > > > > > I won't add Reviewed-by tag, because I think it would confuse Patchwork, > > > > > so please send a v2 at some point. > > > > > > > > Thanks. Do you have any suggestions for patch 2? Should I merge the > > > > description in patch 2 into this file? > > > > > > > > The full dts for this series looks like this: > > > > > > > > smc: smc@23e400000 { > > > > compatible = "apple,t8103-smc", "apple,smc"; > > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > > <0x2 0x3fe00000 0x0 0x100000>; > > > > reg-names = "smc", "sram"; > > > > mboxes = <&smc_mbox>; > > > > > > > > smc_gpio: gpio { > > > > gpio-controller; > > > > #gpio-cells = <2>; > > > > }; > > > > }; > > > > > > > > but the fuller version in the asahi linux tree looks like: > > > > > > > > smc: smc@23e400000 { > > > > compatible = "apple,t8103-smc", "apple,smc"; > > > > reg = <0x2 0x3e400000 0x0 0x4000>, > > > > <0x2 0x3fe00000 0x0 0x100000>; > > > > reg-names = "smc", "sram"; > > > > mboxes = <&smc_mbox>; > > > > > > > > smc_gpio: gpio { > > > > gpio-controller; > > > > #gpio-cells = <2>; > > > > > > Only 2 properties doesn't really need its own schema doc. However, I > > > would just move these to the parent node. > > > > When we designed the bindings, it was our understanding that having > > separate nodes better matches Linux's MFD driver model. > > Well, it is convenient to have subnodes with compatibles so that your > drivers automagically probe. So yes, a 1:1 relationship of nodes to > drivers is nice and tidy. But h/w is not always packaged up neatly and > it's not DT's job to try to abstract it such that it is. Also, we > shouldn't design bindings around the *current* driver partitioning of > some OS. > > This one is actually pretty odd in that the child nodes don't have a > compatible string which breaks the automagical probing. > > > Please be aware that OpenBSD is already using these bindings. If > > there are good reasons for moving things, we can probably deal with > > that. But this sounds a bit like a toss up. > > Sigh. If there are other bindings in use, please submit them even if the > Linux driver isn't ready. If a Linux subsystem maintainer doesn't want > to take it, then I will. > > It is a toss up though... > > > > > }; > > > > > > > > smc_rtc: rtc { > > > > nvmem-cells = <&rtc_offset>; > > > > nvmem-cell-names = "rtc_offset"; > > > > }; > > > > > > > > smc_reboot: reboot { > > > > nvmem-cells = <&shutdown_flag>, <&boot_stage>, > > > > <&boot_error_count>, <&panic_count>, <&pm_setting>; > > > > nvmem-cell-names = "shutdown_flag", "boot_stage", > > > > "boot_error_count", "panic_count", "pm_setting"; > > > > > > Not really much reason to split these up either because you can just > > > fetch the entry you want by name. > > > > Again the separate nodes are there because the RTC and the reboot > > functionality are logically separate and handled by different MFD > > sub-drivers in Linux. > > It's really a question of whether the subset of functionality is going > to get reused on its own or has its own resources in DT. MFD bindings > are done both ways. I'm guessing this series is blocked until a resolution is found for the DT binding description. Please can the Asahi folk and the DT maintainers sort this out and let me know when I can proceed with this patch set. I'm just the man in the middle here. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-02 17:28 ` Rob Herring @ 2022-09-06 9:04 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 9:04 UTC (permalink / raw) To: Rob Herring Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > This one is actually pretty odd in that the child nodes don't have a > compatible string which breaks the automagical probing. I don't think that is necessarily true, and I don't think it's true in this case. The SMC core driver instructs the MFD core to create devices for the individual functional items: static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", }, { .name = "macsmc-hid", }, { .name = "macsmc-power", }, { .name = "macsmc-reboot", }, { .name = "macsmc-rtc", }, }; Since MFD uses platform devices for these, they get all the normal functionality that these devices have, which include matching by device name ot the driver name, and udev events being appropriately triggered. As long as the platform drivers for these devices have the correct modalias lines, autoloading of the modules will work and the drivers will be correctly matched and probed. The Asahi kernel builds most of the platform support as modules, including these, so we know it works (if it didn't, then lots of module autoloading would be broken on non-DT platforms.) > > Again the separate nodes are there because the RTC and the reboot > > functionality are logically separate and handled by different MFD > > sub-drivers in Linux. > > It's really a question of whether the subset of functionality is going > to get reused on its own or has its own resources in DT. MFD bindings > are done both ways. I think the current position on what to do about these is that everyone is looking for someone else to make a decision, and no one wants to! Firstly, I don't think that the number of properties in a node should have a bearing on the design of the DT binding - what should have a bearing is the logical partitioning of functionality. Mark suggests that it would take six months for OpenBSD to transition to some other description - for example, if we merged the nodes. Hector says that MacOS's firmware description has the nodes merged, but their description is a mess. The overall preference seems to be to keep the sub-nodes unless there is a strong technical reason not to. The feeling I am getting from the review is that there doesn't seem to be a strong technical reason to merge the nodes - there are desires and preferences, but nothing concrete. So at this point, I think it would make sense if I post a v2 with all the updates so far (sorry, given the long drawn out discussions on this, I've lost track of what changes have been made to the code, so I won't include a detailed change log.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 9:04 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 9:04 UTC (permalink / raw) To: Rob Herring Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > This one is actually pretty odd in that the child nodes don't have a > compatible string which breaks the automagical probing. I don't think that is necessarily true, and I don't think it's true in this case. The SMC core driver instructs the MFD core to create devices for the individual functional items: static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", }, { .name = "macsmc-hid", }, { .name = "macsmc-power", }, { .name = "macsmc-reboot", }, { .name = "macsmc-rtc", }, }; Since MFD uses platform devices for these, they get all the normal functionality that these devices have, which include matching by device name ot the driver name, and udev events being appropriately triggered. As long as the platform drivers for these devices have the correct modalias lines, autoloading of the modules will work and the drivers will be correctly matched and probed. The Asahi kernel builds most of the platform support as modules, including these, so we know it works (if it didn't, then lots of module autoloading would be broken on non-DT platforms.) > > Again the separate nodes are there because the RTC and the reboot > > functionality are logically separate and handled by different MFD > > sub-drivers in Linux. > > It's really a question of whether the subset of functionality is going > to get reused on its own or has its own resources in DT. MFD bindings > are done both ways. I think the current position on what to do about these is that everyone is looking for someone else to make a decision, and no one wants to! Firstly, I don't think that the number of properties in a node should have a bearing on the design of the DT binding - what should have a bearing is the logical partitioning of functionality. Mark suggests that it would take six months for OpenBSD to transition to some other description - for example, if we merged the nodes. Hector says that MacOS's firmware description has the nodes merged, but their description is a mess. The overall preference seems to be to keep the sub-nodes unless there is a strong technical reason not to. The feeling I am getting from the review is that there doesn't seem to be a strong technical reason to merge the nodes - there are desires and preferences, but nothing concrete. So at this point, I think it would make sense if I post a v2 with all the updates so far (sorry, given the long drawn out discussions on this, I've lost track of what changes have been made to the code, so I won't include a detailed change log.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 9:04 ` Russell King (Oracle) @ 2022-09-06 9:31 ` Mark Kettenis -1 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-06 9:31 UTC (permalink / raw) To: Russell King (Oracle) Cc: robh, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Tue, 6 Sep 2022 10:04:45 +0100 > From: "Russell King (Oracle)" <linux@armlinux.org.uk> > > On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > > This one is actually pretty odd in that the child nodes don't have a > > compatible string which breaks the automagical probing. > > I don't think that is necessarily true, and I don't think it's true in > this case. > > The SMC core driver instructs the MFD core to create devices for the > individual functional items: > > static const struct mfd_cell apple_smc_devs[] = { > { > .name = "macsmc-gpio", > }, > { > .name = "macsmc-hid", > }, > { > .name = "macsmc-power", > }, > { > .name = "macsmc-reboot", > }, > { > .name = "macsmc-rtc", > }, > }; > > Since MFD uses platform devices for these, they get all the normal > functionality that these devices have, which include matching by > device name ot the driver name, and udev events being appropriately > triggered. As long as the platform drivers for these devices have the > correct modalias lines, autoloading of the modules will work and the > drivers will be correctly matched and probed. > > The Asahi kernel builds most of the platform support as modules, > including these, so we know it works (if it didn't, then lots of > module autoloading would be broken on non-DT platforms.) > > > > Again the separate nodes are there because the RTC and the reboot > > > functionality are logically separate and handled by different MFD > > > sub-drivers in Linux. > > > > It's really a question of whether the subset of functionality is going > > to get reused on its own or has its own resources in DT. MFD bindings > > are done both ways. > > I think the current position on what to do about these is that everyone > is looking for someone else to make a decision, and no one wants to! > > Firstly, I don't think that the number of properties in a node should > have a bearing on the design of the DT binding - what should have a > bearing is the logical partitioning of functionality. > > Mark suggests that it would take six months for OpenBSD to transition to > some other description - for example, if we merged the nodes. Note that we're totally willing to do that if there is a good technical reason for changes to the binding. We just have to find a way to upgrade existing installations of OpenBSD 7.1 which is a bit of a challenge as the SMC GPIOs are essential for wifi which on the laptops is the only network connection available. > Hector says that MacOS's firmware description has the nodes merged, but > their description is a mess. To elaborate on that a bit more, the use of sub-nodes provides a nice separation between the SMC hardware interface (the main node) and the functionality offered by the firmware running on the SMC (the sub-nodes). Another argument for having sub-nodes is that the firmware actually exposes *two* GPIO controllers. For now we only support the "master" PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a separate set of SMC "keys". We currently don't need any of the pins on the "slave", so we don't expose it in the DT yet. > The overall preference seems to be to keep the sub-nodes unless there > is a strong technical reason not to. > > The feeling I am getting from the review is that there doesn't seem to > be a strong technical reason to merge the nodes - there are desires and > preferences, but nothing concrete. > > So at this point, I think it would make sense if I post a v2 with all > the updates so far (sorry, given the long drawn out discussions on > this, I've lost track of what changes have been made to the code, so > I won't include a detailed change log.) > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! > > ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 9:31 ` Mark Kettenis 0 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-06 9:31 UTC (permalink / raw) To: Russell King (Oracle) Cc: robh, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Tue, 6 Sep 2022 10:04:45 +0100 > From: "Russell King (Oracle)" <linux@armlinux.org.uk> > > On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > > This one is actually pretty odd in that the child nodes don't have a > > compatible string which breaks the automagical probing. > > I don't think that is necessarily true, and I don't think it's true in > this case. > > The SMC core driver instructs the MFD core to create devices for the > individual functional items: > > static const struct mfd_cell apple_smc_devs[] = { > { > .name = "macsmc-gpio", > }, > { > .name = "macsmc-hid", > }, > { > .name = "macsmc-power", > }, > { > .name = "macsmc-reboot", > }, > { > .name = "macsmc-rtc", > }, > }; > > Since MFD uses platform devices for these, they get all the normal > functionality that these devices have, which include matching by > device name ot the driver name, and udev events being appropriately > triggered. As long as the platform drivers for these devices have the > correct modalias lines, autoloading of the modules will work and the > drivers will be correctly matched and probed. > > The Asahi kernel builds most of the platform support as modules, > including these, so we know it works (if it didn't, then lots of > module autoloading would be broken on non-DT platforms.) > > > > Again the separate nodes are there because the RTC and the reboot > > > functionality are logically separate and handled by different MFD > > > sub-drivers in Linux. > > > > It's really a question of whether the subset of functionality is going > > to get reused on its own or has its own resources in DT. MFD bindings > > are done both ways. > > I think the current position on what to do about these is that everyone > is looking for someone else to make a decision, and no one wants to! > > Firstly, I don't think that the number of properties in a node should > have a bearing on the design of the DT binding - what should have a > bearing is the logical partitioning of functionality. > > Mark suggests that it would take six months for OpenBSD to transition to > some other description - for example, if we merged the nodes. Note that we're totally willing to do that if there is a good technical reason for changes to the binding. We just have to find a way to upgrade existing installations of OpenBSD 7.1 which is a bit of a challenge as the SMC GPIOs are essential for wifi which on the laptops is the only network connection available. > Hector says that MacOS's firmware description has the nodes merged, but > their description is a mess. To elaborate on that a bit more, the use of sub-nodes provides a nice separation between the SMC hardware interface (the main node) and the functionality offered by the firmware running on the SMC (the sub-nodes). Another argument for having sub-nodes is that the firmware actually exposes *two* GPIO controllers. For now we only support the "master" PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a separate set of SMC "keys". We currently don't need any of the pins on the "slave", so we don't expose it in the DT yet. > The overall preference seems to be to keep the sub-nodes unless there > is a strong technical reason not to. > > The feeling I am getting from the review is that there doesn't seem to > be a strong technical reason to merge the nodes - there are desires and > preferences, but nothing concrete. > > So at this point, I think it would make sense if I post a v2 with all > the updates so far (sorry, given the long drawn out discussions on > this, I've lost track of what changes have been made to the code, so > I won't include a detailed change log.) > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 9:31 ` Mark Kettenis @ 2022-09-06 11:22 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-06 11:22 UTC (permalink / raw) To: Mark Kettenis Cc: Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > Another argument for having sub-nodes is that the firmware actually > exposes *two* GPIO controllers. For now we only support the "master" > PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > separate set of SMC "keys". We currently don't need any of the pins > on the "slave", so we don't expose it in the DT yet. That sounds backward, like we don't expose device X as DT node because $OS doesn't use it yet. DT should just expose (by nodes or other ways) all hardware that exist or at least all hardware we know about no matter what $OS is using. FWIW I think nodes makes most sense because no doubt for example the RTC is a separate hardware unit somewhere, and so is the GPIO. The fact that it is hidden behind a software abstraction doesn't change the fact that the HW definitely has these discrete units. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 11:22 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-06 11:22 UTC (permalink / raw) To: Mark Kettenis Cc: Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > Another argument for having sub-nodes is that the firmware actually > exposes *two* GPIO controllers. For now we only support the "master" > PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > separate set of SMC "keys". We currently don't need any of the pins > on the "slave", so we don't expose it in the DT yet. That sounds backward, like we don't expose device X as DT node because $OS doesn't use it yet. DT should just expose (by nodes or other ways) all hardware that exist or at least all hardware we know about no matter what $OS is using. FWIW I think nodes makes most sense because no doubt for example the RTC is a separate hardware unit somewhere, and so is the GPIO. The fact that it is hidden behind a software abstraction doesn't change the fact that the HW definitely has these discrete units. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 11:22 ` Linus Walleij @ 2022-09-06 11:36 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 11:36 UTC (permalink / raw) To: Linus Walleij, Mark Kettenis Cc: Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 06/09/2022 20.22, Linus Walleij wrote: > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > >> Another argument for having sub-nodes is that the firmware actually >> exposes *two* GPIO controllers. For now we only support the "master" >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a >> separate set of SMC "keys". We currently don't need any of the pins >> on the "slave", so we don't expose it in the DT yet. > > That sounds backward, like we don't expose device X as DT node > because $OS doesn't use it yet. DT should just expose (by nodes or > other ways) all hardware that exist or at least all hardware we know > about no matter what $OS is using. How so? The are piles and piles of unused hardware not exposed in the DT, and piles and piles of hardware that will be used but we haven't figured out how to do it yet, so it's not exposed. For example, we know there are like 8 or so UARTs, but we don't define them in the DT because they are not connected to anything on any existing device and we don't need them. Apple does the same thing in their DTs (only used hardware is defined). I don't really see the point of exposing a GPIO controller when we don't actually do anything with the pins yet, and might never do so. Having drivers bind and stay unused just increases the amount of code running without any ultimate purpose, so why do it? It's not like any other OS would use the hardware either - GPIOs are only useful if they are referenced in the DT for something, and we don't have anything that would reference these. For SMC in particular, there's a huge amount of functionality we don't have drivers for yet, and I don't see the point of trying to conjure up DT bindings for it until someone writes a driver (and has a reason to do so) :) > FWIW I think nodes makes most sense because no doubt for example > the RTC is a separate hardware unit somewhere, and so is the > GPIO. The fact that it is hidden behind a software abstraction doesn't > change the fact that the HW definitely has these discrete units. The RTC and the GPIO happen to be part of the same physical IC (PMU), but yes, I agree. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 11:36 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 11:36 UTC (permalink / raw) To: Linus Walleij, Mark Kettenis Cc: Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 06/09/2022 20.22, Linus Walleij wrote: > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > >> Another argument for having sub-nodes is that the firmware actually >> exposes *two* GPIO controllers. For now we only support the "master" >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a >> separate set of SMC "keys". We currently don't need any of the pins >> on the "slave", so we don't expose it in the DT yet. > > That sounds backward, like we don't expose device X as DT node > because $OS doesn't use it yet. DT should just expose (by nodes or > other ways) all hardware that exist or at least all hardware we know > about no matter what $OS is using. How so? The are piles and piles of unused hardware not exposed in the DT, and piles and piles of hardware that will be used but we haven't figured out how to do it yet, so it's not exposed. For example, we know there are like 8 or so UARTs, but we don't define them in the DT because they are not connected to anything on any existing device and we don't need them. Apple does the same thing in their DTs (only used hardware is defined). I don't really see the point of exposing a GPIO controller when we don't actually do anything with the pins yet, and might never do so. Having drivers bind and stay unused just increases the amount of code running without any ultimate purpose, so why do it? It's not like any other OS would use the hardware either - GPIOs are only useful if they are referenced in the DT for something, and we don't have anything that would reference these. For SMC in particular, there's a huge amount of functionality we don't have drivers for yet, and I don't see the point of trying to conjure up DT bindings for it until someone writes a driver (and has a reason to do so) :) > FWIW I think nodes makes most sense because no doubt for example > the RTC is a separate hardware unit somewhere, and so is the > GPIO. The fact that it is hidden behind a software abstraction doesn't > change the fact that the HW definitely has these discrete units. The RTC and the GPIO happen to be part of the same physical IC (PMU), but yes, I agree. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 11:36 ` Hector Martin @ 2022-09-06 11:57 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-06 11:57 UTC (permalink / raw) To: Hector Martin Cc: Mark Kettenis, Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote: > On 06/09/2022 20.22, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > >> Another argument for having sub-nodes is that the firmware actually > >> exposes *two* GPIO controllers. For now we only support the "master" > >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > >> separate set of SMC "keys". We currently don't need any of the pins > >> on the "slave", so we don't expose it in the DT yet. > > > > That sounds backward, like we don't expose device X as DT node > > because $OS doesn't use it yet. DT should just expose (by nodes or > > other ways) all hardware that exist or at least all hardware we know > > about no matter what $OS is using. > > How so? The are piles and piles of unused hardware not exposed in the > DT, and piles and piles of hardware that will be used but we haven't > figured out how to do it yet, so it's not exposed. For example, we know > there are like 8 or so UARTs, but we don't define them in the DT because > they are not connected to anything on any existing device and we don't > need them. Apple does the same thing in their DTs (only used hardware is > defined). > > I don't really see the point of exposing a GPIO controller when we don't > actually do anything with the pins yet, and might never do so. Having > drivers bind and stay unused just increases the amount of code running > without any ultimate purpose, so why do it? It's not like any other OS > would use the hardware either - GPIOs are only useful if they are > referenced in the DT for something, and we don't have anything that > would reference these. This comes from the FDT background in OpenFirmware, and there is definitely a timeline perspective (also called "waterfall model") in that line of thinking: a DT is written that describes the hardware and flashed into the BIOS and never changed, then the operating system is implemented at a later point. This is how e.g. the PC ACPI BIOS tables are also thinking about themselves. Of course the world does not work like that, but as a standard process DT and ACPI works with the same ambition as any such process: slowly and impersonal, like the planets, or the plants. The ambition that a DT should always remain backward compatible comes from the same historical root and reasoning. Any agile development or (heh) hardware discovers through reverse engineering will of course drive a truck through that line of thinking. Realistically, use the same approach as with everything else, I like the IETF motto "rough consensus and running code", any ambition taken too far will just stifle development. So I'd say make an honest effort to resonably describe the nodes we see will be useful in the foreseeable future. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 11:57 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-06 11:57 UTC (permalink / raw) To: Hector Martin Cc: Mark Kettenis, Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote: > On 06/09/2022 20.22, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > >> Another argument for having sub-nodes is that the firmware actually > >> exposes *two* GPIO controllers. For now we only support the "master" > >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > >> separate set of SMC "keys". We currently don't need any of the pins > >> on the "slave", so we don't expose it in the DT yet. > > > > That sounds backward, like we don't expose device X as DT node > > because $OS doesn't use it yet. DT should just expose (by nodes or > > other ways) all hardware that exist or at least all hardware we know > > about no matter what $OS is using. > > How so? The are piles and piles of unused hardware not exposed in the > DT, and piles and piles of hardware that will be used but we haven't > figured out how to do it yet, so it's not exposed. For example, we know > there are like 8 or so UARTs, but we don't define them in the DT because > they are not connected to anything on any existing device and we don't > need them. Apple does the same thing in their DTs (only used hardware is > defined). > > I don't really see the point of exposing a GPIO controller when we don't > actually do anything with the pins yet, and might never do so. Having > drivers bind and stay unused just increases the amount of code running > without any ultimate purpose, so why do it? It's not like any other OS > would use the hardware either - GPIOs are only useful if they are > referenced in the DT for something, and we don't have anything that > would reference these. This comes from the FDT background in OpenFirmware, and there is definitely a timeline perspective (also called "waterfall model") in that line of thinking: a DT is written that describes the hardware and flashed into the BIOS and never changed, then the operating system is implemented at a later point. This is how e.g. the PC ACPI BIOS tables are also thinking about themselves. Of course the world does not work like that, but as a standard process DT and ACPI works with the same ambition as any such process: slowly and impersonal, like the planets, or the plants. The ambition that a DT should always remain backward compatible comes from the same historical root and reasoning. Any agile development or (heh) hardware discovers through reverse engineering will of course drive a truck through that line of thinking. Realistically, use the same approach as with everything else, I like the IETF motto "rough consensus and running code", any ambition taken too far will just stifle development. So I'd say make an honest effort to resonably describe the nodes we see will be useful in the foreseeable future. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 11:57 ` Linus Walleij @ 2022-09-06 13:28 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 13:28 UTC (permalink / raw) To: Linus Walleij Cc: Mark Kettenis, Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 06/09/2022 20.57, Linus Walleij wrote: > On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote: >> On 06/09/2022 20.22, Linus Walleij wrote: >>> On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: >>> >>>> Another argument for having sub-nodes is that the firmware actually >>>> exposes *two* GPIO controllers. For now we only support the "master" >>>> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a >>>> separate set of SMC "keys". We currently don't need any of the pins >>>> on the "slave", so we don't expose it in the DT yet. >>> >>> That sounds backward, like we don't expose device X as DT node >>> because $OS doesn't use it yet. DT should just expose (by nodes or >>> other ways) all hardware that exist or at least all hardware we know >>> about no matter what $OS is using. >> >> How so? The are piles and piles of unused hardware not exposed in the >> DT, and piles and piles of hardware that will be used but we haven't >> figured out how to do it yet, so it's not exposed. For example, we know >> there are like 8 or so UARTs, but we don't define them in the DT because >> they are not connected to anything on any existing device and we don't >> need them. Apple does the same thing in their DTs (only used hardware is >> defined). >> >> I don't really see the point of exposing a GPIO controller when we don't >> actually do anything with the pins yet, and might never do so. Having >> drivers bind and stay unused just increases the amount of code running >> without any ultimate purpose, so why do it? It's not like any other OS >> would use the hardware either - GPIOs are only useful if they are >> referenced in the DT for something, and we don't have anything that >> would reference these. > > This comes from the FDT background in OpenFirmware, and there is > definitely a timeline perspective (also called "waterfall model") in that > line of thinking: a DT is written that describes the hardware and flashed > into the BIOS and never changed, then the operating system is > implemented at a later point. This is how e.g. the PC ACPI BIOS tables > are also thinking about themselves. Yes, but again, that only makes sense from the point of view of describing hardware that exists, is useful, and could be used by the OS. For any given platform X, if platform X does not use the secondary GPIO controller for any service describable in the DT, then there is no point in describing that GPIO controller. Same way ACPI tables do not describe every single physical GPIO available on a platform, just whatever is used by the AML. This is the case for every existing Apple device to my knowledge. Apple's device trees have zero references to the secondary controller's GPIOs. It's possible they are only used internally by SMC, or they were added to support future platforms that don't exist yet, or for debugging purposes, or who knows. If some day we find a use for those GPIOs, that would require a DT change *anyway*, to describe that usage, and the controller could be described then (we did something like that, using a GPIO that Apple doesn't, for the interim display-backlight power control support, though that is a temporary hack that will go away). Heck, we don't even know what these GPIOs are connected to right now! Ultimately, we're working with a reverse engineered platform here, and DTs will inevitaby be incremental. But in this particular case, of hardware that has no known useful purpose to an OS, I don't see the point in gratuitously describing it. And besides, the way we set things up, forward-compatible DT upgrades are trivial, and no actual user on this platform is going to be stuck with an old DT and newer software (if their software supports the platform properly, and that takes more than the relatively trivial DT upgrade stuff anyway). I'm a lot more interested in getting bindings upstreamed ASAP (so we can start guaranteeing no backwards-compat breaks, which is important to avoid outright breakage) than I am in trying to be exhaustive up front with device instances. It's perfectly fine to say that users have to upgrade both their DTs and kernels to get newer hardware support, on these platforms. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 13:28 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 13:28 UTC (permalink / raw) To: Linus Walleij Cc: Mark Kettenis, Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 06/09/2022 20.57, Linus Walleij wrote: > On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote: >> On 06/09/2022 20.22, Linus Walleij wrote: >>> On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: >>> >>>> Another argument for having sub-nodes is that the firmware actually >>>> exposes *two* GPIO controllers. For now we only support the "master" >>>> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a >>>> separate set of SMC "keys". We currently don't need any of the pins >>>> on the "slave", so we don't expose it in the DT yet. >>> >>> That sounds backward, like we don't expose device X as DT node >>> because $OS doesn't use it yet. DT should just expose (by nodes or >>> other ways) all hardware that exist or at least all hardware we know >>> about no matter what $OS is using. >> >> How so? The are piles and piles of unused hardware not exposed in the >> DT, and piles and piles of hardware that will be used but we haven't >> figured out how to do it yet, so it's not exposed. For example, we know >> there are like 8 or so UARTs, but we don't define them in the DT because >> they are not connected to anything on any existing device and we don't >> need them. Apple does the same thing in their DTs (only used hardware is >> defined). >> >> I don't really see the point of exposing a GPIO controller when we don't >> actually do anything with the pins yet, and might never do so. Having >> drivers bind and stay unused just increases the amount of code running >> without any ultimate purpose, so why do it? It's not like any other OS >> would use the hardware either - GPIOs are only useful if they are >> referenced in the DT for something, and we don't have anything that >> would reference these. > > This comes from the FDT background in OpenFirmware, and there is > definitely a timeline perspective (also called "waterfall model") in that > line of thinking: a DT is written that describes the hardware and flashed > into the BIOS and never changed, then the operating system is > implemented at a later point. This is how e.g. the PC ACPI BIOS tables > are also thinking about themselves. Yes, but again, that only makes sense from the point of view of describing hardware that exists, is useful, and could be used by the OS. For any given platform X, if platform X does not use the secondary GPIO controller for any service describable in the DT, then there is no point in describing that GPIO controller. Same way ACPI tables do not describe every single physical GPIO available on a platform, just whatever is used by the AML. This is the case for every existing Apple device to my knowledge. Apple's device trees have zero references to the secondary controller's GPIOs. It's possible they are only used internally by SMC, or they were added to support future platforms that don't exist yet, or for debugging purposes, or who knows. If some day we find a use for those GPIOs, that would require a DT change *anyway*, to describe that usage, and the controller could be described then (we did something like that, using a GPIO that Apple doesn't, for the interim display-backlight power control support, though that is a temporary hack that will go away). Heck, we don't even know what these GPIOs are connected to right now! Ultimately, we're working with a reverse engineered platform here, and DTs will inevitaby be incremental. But in this particular case, of hardware that has no known useful purpose to an OS, I don't see the point in gratuitously describing it. And besides, the way we set things up, forward-compatible DT upgrades are trivial, and no actual user on this platform is going to be stuck with an old DT and newer software (if their software supports the platform properly, and that takes more than the relatively trivial DT upgrade stuff anyway). I'm a lot more interested in getting bindings upstreamed ASAP (so we can start guaranteeing no backwards-compat breaks, which is important to avoid outright breakage) than I am in trying to be exhaustive up front with device instances. It's perfectly fine to say that users have to upgrade both their DTs and kernels to get newer hardware support, on these platforms. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 13:28 ` Hector Martin @ 2022-09-06 13:43 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 13:43 UTC (permalink / raw) To: Hector Martin Cc: Linus Walleij, Mark Kettenis, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 10:28:25PM +0900, Hector Martin wrote: > Ultimately, we're working with a reverse engineered platform here, and > DTs will inevitaby be incremental. But in this particular case, of > hardware that has no known useful purpose to an OS, I don't see the > point in gratuitously describing it. And besides, the way we set things > up, forward-compatible DT upgrades are trivial, and no actual user on > this platform is going to be stuck with an old DT and newer software (if > their software supports the platform properly, and that takes more than > the relatively trivial DT upgrade stuff anyway). I'm a lot more > interested in getting bindings upstreamed ASAP (so we can start > guaranteeing no backwards-compat breaks, which is important to avoid > outright breakage) than I am in trying to be exhaustive up front with > device instances. It's perfectly fine to say that users have to upgrade > both their DTs and kernels to get newer hardware support, on these > platforms. It's also a very common process for SoCs - almost no one writes the DT first and then writes the drivers. You always see on the mailing list series of patches that add a driver for some bit of hardware, along with patches adding the DT binding and the DT description. I don't think you're doing anything different here to what is common practice within the mainline kernel community with this approach. The exception to that is when adding a driver for feature X in a SoC, it's common to add all instances of X to the dtsi with ``status = "disabled"'' and only enable the appropriate blocks on platforms that need it. So, for example, if a SoC has three network interfaces, all of them identical, when adding a network driver and the bindings for the network hardware, one would add all three to the SoC description whether or not the platform one was working with makes use of them. It means that one has to think about how to support all instances of the hardware on the platform and design the binding to allow that flexibility, rather than having to augment the binding later. In the case of gpio-macsmc, how would we later add support for the slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? How do we tell the gpio-macsmc code to use a different set of keys? Should DT describe the key "prefix" (in other words "gp" vs "gP"), or should it describe it some other way. What if Apple decides to instantiate another GPIO controller in a later platform with a different prefix, could that be accomodated without breaking any solution we come up today? Maybe the solution to this would be to describe the key prefix in DT as that's effectively its "reg". Or maybe we use "reg" to describe it somehow (which is value of the key, which seems to have an "address" like quality to it?) We don't have to implement code for this now, we just need to get a reasonably correct DT binding for the gpio controller. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 13:43 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 13:43 UTC (permalink / raw) To: Hector Martin Cc: Linus Walleij, Mark Kettenis, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 10:28:25PM +0900, Hector Martin wrote: > Ultimately, we're working with a reverse engineered platform here, and > DTs will inevitaby be incremental. But in this particular case, of > hardware that has no known useful purpose to an OS, I don't see the > point in gratuitously describing it. And besides, the way we set things > up, forward-compatible DT upgrades are trivial, and no actual user on > this platform is going to be stuck with an old DT and newer software (if > their software supports the platform properly, and that takes more than > the relatively trivial DT upgrade stuff anyway). I'm a lot more > interested in getting bindings upstreamed ASAP (so we can start > guaranteeing no backwards-compat breaks, which is important to avoid > outright breakage) than I am in trying to be exhaustive up front with > device instances. It's perfectly fine to say that users have to upgrade > both their DTs and kernels to get newer hardware support, on these > platforms. It's also a very common process for SoCs - almost no one writes the DT first and then writes the drivers. You always see on the mailing list series of patches that add a driver for some bit of hardware, along with patches adding the DT binding and the DT description. I don't think you're doing anything different here to what is common practice within the mainline kernel community with this approach. The exception to that is when adding a driver for feature X in a SoC, it's common to add all instances of X to the dtsi with ``status = "disabled"'' and only enable the appropriate blocks on platforms that need it. So, for example, if a SoC has three network interfaces, all of them identical, when adding a network driver and the bindings for the network hardware, one would add all three to the SoC description whether or not the platform one was working with makes use of them. It means that one has to think about how to support all instances of the hardware on the platform and design the binding to allow that flexibility, rather than having to augment the binding later. In the case of gpio-macsmc, how would we later add support for the slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? How do we tell the gpio-macsmc code to use a different set of keys? Should DT describe the key "prefix" (in other words "gp" vs "gP"), or should it describe it some other way. What if Apple decides to instantiate another GPIO controller in a later platform with a different prefix, could that be accomodated without breaking any solution we come up today? Maybe the solution to this would be to describe the key prefix in DT as that's effectively its "reg". Or maybe we use "reg" to describe it somehow (which is value of the key, which seems to have an "address" like quality to it?) We don't have to implement code for this now, we just need to get a reasonably correct DT binding for the gpio controller. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 13:43 ` Russell King (Oracle) @ 2022-09-06 13:53 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 13:53 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Mark Kettenis, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 06/09/2022 22.43, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 10:28:25PM +0900, Hector Martin wrote: >> Ultimately, we're working with a reverse engineered platform here, and >> DTs will inevitaby be incremental. But in this particular case, of >> hardware that has no known useful purpose to an OS, I don't see the >> point in gratuitously describing it. And besides, the way we set things >> up, forward-compatible DT upgrades are trivial, and no actual user on >> this platform is going to be stuck with an old DT and newer software (if >> their software supports the platform properly, and that takes more than >> the relatively trivial DT upgrade stuff anyway). I'm a lot more >> interested in getting bindings upstreamed ASAP (so we can start >> guaranteeing no backwards-compat breaks, which is important to avoid >> outright breakage) than I am in trying to be exhaustive up front with >> device instances. It's perfectly fine to say that users have to upgrade >> both their DTs and kernels to get newer hardware support, on these >> platforms. > > It's also a very common process for SoCs - almost no one writes the > DT first and then writes the drivers. You always see on the mailing > list series of patches that add a driver for some bit of hardware, > along with patches adding the DT binding and the DT description. > > I don't think you're doing anything different here to what is common > practice within the mainline kernel community with this approach. > > The exception to that is when adding a driver for feature X in a SoC, > it's common to add all instances of X to the dtsi with ``status = > "disabled"'' and only enable the appropriate blocks on platforms that > need it. > > So, for example, if a SoC has three network interfaces, all of them > identical, when adding a network driver and the bindings for the > network hardware, one would add all three to the SoC description > whether or not the platform one was working with makes use of them. Right, and that makes sense for SoCs that third parties can incorporate into any arbitrary platform, and which have documentation listing those instances, because then board-level DTs can just enable the ones they need. But here we're working with SoCs where the only reference for what hardware exists *is* Apple's DT, and it only lists hardware that is in use on existing platforms. So there is no sane way for us to know what hardware exists, except what we can infer from reading the tea leaves (e.g. you can tell how many UARTs there are from the power domains and leaked schematics, but this doesn't extend to everything else). For example, we also know that these SoCs have a second Neural Engine that Apple have disabled on all shipping platforms, that the t600x series has an unused USB3 controller, etc... but there's no way we can safely describe these things in the DT if we can't test that they work and we don't have documentation even telling us how they're supposed to work :) > In the case of gpio-macsmc, how would we later add support for the > slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? > How do we tell the gpio-macsmc code to use a different set of keys? > Should DT describe the key "prefix" (in other words "gp" vs "gP"), > or should it describe it some other way. What if Apple decides to > instantiate another GPIO controller in a later platform with a > different prefix, could that be accomodated without breaking any > solution we come up today? > > Maybe the solution to this would be to describe the key prefix in DT > as that's effectively its "reg". Or maybe we use "reg" to describe > it somehow (which is value of the key, which seems to have an > "address" like quality to it?) > > We don't have to implement code for this now, we just need to get a > reasonably correct DT binding for the gpio controller. I agree that this is something to think about (I was about to reply on the subject). I can think of two ways: using `reg` for the key name, but that feels icky since it's ASCII and not *really* a register number/address, or something like this: gpio@0 { apple,smc-key-base = "gP00"; ... } gpio@1 { apple,smc-key-base = "gp00"; ... } But this ties back to the device enumeration too, since right now the DT does not drive that (we'd have to add the subdevice to the mfd subdevice list somehow anyway, if we don't switch to compatibles). I'd love to hear Rob's opinion on this one, and also whether the existing Linux and OpenBSD code would currently find gpio@0 {} instead of gpio {} for backwards compat. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 13:53 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 13:53 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Mark Kettenis, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 06/09/2022 22.43, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 10:28:25PM +0900, Hector Martin wrote: >> Ultimately, we're working with a reverse engineered platform here, and >> DTs will inevitaby be incremental. But in this particular case, of >> hardware that has no known useful purpose to an OS, I don't see the >> point in gratuitously describing it. And besides, the way we set things >> up, forward-compatible DT upgrades are trivial, and no actual user on >> this platform is going to be stuck with an old DT and newer software (if >> their software supports the platform properly, and that takes more than >> the relatively trivial DT upgrade stuff anyway). I'm a lot more >> interested in getting bindings upstreamed ASAP (so we can start >> guaranteeing no backwards-compat breaks, which is important to avoid >> outright breakage) than I am in trying to be exhaustive up front with >> device instances. It's perfectly fine to say that users have to upgrade >> both their DTs and kernels to get newer hardware support, on these >> platforms. > > It's also a very common process for SoCs - almost no one writes the > DT first and then writes the drivers. You always see on the mailing > list series of patches that add a driver for some bit of hardware, > along with patches adding the DT binding and the DT description. > > I don't think you're doing anything different here to what is common > practice within the mainline kernel community with this approach. > > The exception to that is when adding a driver for feature X in a SoC, > it's common to add all instances of X to the dtsi with ``status = > "disabled"'' and only enable the appropriate blocks on platforms that > need it. > > So, for example, if a SoC has three network interfaces, all of them > identical, when adding a network driver and the bindings for the > network hardware, one would add all three to the SoC description > whether or not the platform one was working with makes use of them. Right, and that makes sense for SoCs that third parties can incorporate into any arbitrary platform, and which have documentation listing those instances, because then board-level DTs can just enable the ones they need. But here we're working with SoCs where the only reference for what hardware exists *is* Apple's DT, and it only lists hardware that is in use on existing platforms. So there is no sane way for us to know what hardware exists, except what we can infer from reading the tea leaves (e.g. you can tell how many UARTs there are from the power domains and leaked schematics, but this doesn't extend to everything else). For example, we also know that these SoCs have a second Neural Engine that Apple have disabled on all shipping platforms, that the t600x series has an unused USB3 controller, etc... but there's no way we can safely describe these things in the DT if we can't test that they work and we don't have documentation even telling us how they're supposed to work :) > In the case of gpio-macsmc, how would we later add support for the > slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? > How do we tell the gpio-macsmc code to use a different set of keys? > Should DT describe the key "prefix" (in other words "gp" vs "gP"), > or should it describe it some other way. What if Apple decides to > instantiate another GPIO controller in a later platform with a > different prefix, could that be accomodated without breaking any > solution we come up today? > > Maybe the solution to this would be to describe the key prefix in DT > as that's effectively its "reg". Or maybe we use "reg" to describe > it somehow (which is value of the key, which seems to have an > "address" like quality to it?) > > We don't have to implement code for this now, we just need to get a > reasonably correct DT binding for the gpio controller. I agree that this is something to think about (I was about to reply on the subject). I can think of two ways: using `reg` for the key name, but that feels icky since it's ASCII and not *really* a register number/address, or something like this: gpio@0 { apple,smc-key-base = "gP00"; ... } gpio@1 { apple,smc-key-base = "gp00"; ... } But this ties back to the device enumeration too, since right now the DT does not drive that (we'd have to add the subdevice to the mfd subdevice list somehow anyway, if we don't switch to compatibles). I'd love to hear Rob's opinion on this one, and also whether the existing Linux and OpenBSD code would currently find gpio@0 {} instead of gpio {} for backwards compat. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 13:53 ` Hector Martin @ 2022-09-06 14:25 ` Mark Kettenis -1 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-06 14:25 UTC (permalink / raw) To: Hector Martin Cc: linux, linus.walleij, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Tue, 6 Sep 2022 22:53:47 +0900 > From: Hector Martin <marcan@marcan.st> > > On 06/09/2022 22.43, Russell King (Oracle) wrote: > > In the case of gpio-macsmc, how would we later add support for the > > slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? > > How do we tell the gpio-macsmc code to use a different set of keys? > > Should DT describe the key "prefix" (in other words "gp" vs "gP"), > > or should it describe it some other way. What if Apple decides to > > instantiate another GPIO controller in a later platform with a > > different prefix, could that be accomodated without breaking any > > solution we come up today? > > > > Maybe the solution to this would be to describe the key prefix in DT > > as that's effectively its "reg". Or maybe we use "reg" to describe > > it somehow (which is value of the key, which seems to have an > > "address" like quality to it?) > > > > We don't have to implement code for this now, we just need to get a > > reasonably correct DT binding for the gpio controller. > > I agree that this is something to think about (I was about to reply on > the subject). > > I can think of two ways: using `reg` for the key name, but that feels > icky since it's ASCII and not *really* a register number/address, or > something like this: > > gpio@0 { > apple,smc-key-base = "gP00"; > ... > } > > gpio@1 { > apple,smc-key-base = "gp00"; > ... > } This would still require us to add a (one-cell) "reg" property and would require adding the appropriate "#address-cells" and "#size-cells" properties to the SMC node. > But this ties back to the device enumeration too, since right now the DT > does not drive that (we'd have to add the subdevice to the mfd subdevice > list somehow anyway, if we don't switch to compatibles). > > I'd love to hear Rob's opinion on this one, and also whether the > existing Linux and OpenBSD code would currently find gpio@0 {} instead > of gpio {} for backwards compat. The OpenBSD driver does a lookup by name and the "@0" is part of that name. So that would break backwards compat. Maybe just name the slave GPIO controller "gpio-slave"? If we add compatibles, the compatibles for the nodes should propbably be different such that we can switch to do a lookup by compatible? ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 14:25 ` Mark Kettenis 0 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-06 14:25 UTC (permalink / raw) To: Hector Martin Cc: linux, linus.walleij, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Tue, 6 Sep 2022 22:53:47 +0900 > From: Hector Martin <marcan@marcan.st> > > On 06/09/2022 22.43, Russell King (Oracle) wrote: > > In the case of gpio-macsmc, how would we later add support for the > > slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? > > How do we tell the gpio-macsmc code to use a different set of keys? > > Should DT describe the key "prefix" (in other words "gp" vs "gP"), > > or should it describe it some other way. What if Apple decides to > > instantiate another GPIO controller in a later platform with a > > different prefix, could that be accomodated without breaking any > > solution we come up today? > > > > Maybe the solution to this would be to describe the key prefix in DT > > as that's effectively its "reg". Or maybe we use "reg" to describe > > it somehow (which is value of the key, which seems to have an > > "address" like quality to it?) > > > > We don't have to implement code for this now, we just need to get a > > reasonably correct DT binding for the gpio controller. > > I agree that this is something to think about (I was about to reply on > the subject). > > I can think of two ways: using `reg` for the key name, but that feels > icky since it's ASCII and not *really* a register number/address, or > something like this: > > gpio@0 { > apple,smc-key-base = "gP00"; > ... > } > > gpio@1 { > apple,smc-key-base = "gp00"; > ... > } This would still require us to add a (one-cell) "reg" property and would require adding the appropriate "#address-cells" and "#size-cells" properties to the SMC node. > But this ties back to the device enumeration too, since right now the DT > does not drive that (we'd have to add the subdevice to the mfd subdevice > list somehow anyway, if we don't switch to compatibles). > > I'd love to hear Rob's opinion on this one, and also whether the > existing Linux and OpenBSD code would currently find gpio@0 {} instead > of gpio {} for backwards compat. The OpenBSD driver does a lookup by name and the "@0" is part of that name. So that would break backwards compat. Maybe just name the slave GPIO controller "gpio-slave"? If we add compatibles, the compatibles for the nodes should propbably be different such that we can switch to do a lookup by compatible? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 14:25 ` Mark Kettenis @ 2022-09-06 14:54 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 14:54 UTC (permalink / raw) To: Mark Kettenis Cc: Hector Martin, linus.walleij, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 04:25:49PM +0200, Mark Kettenis wrote: > > Date: Tue, 6 Sep 2022 22:53:47 +0900 > > From: Hector Martin <marcan@marcan.st> > > > > I agree that this is something to think about (I was about to reply on > > the subject). > > > > I can think of two ways: using `reg` for the key name, but that feels > > icky since it's ASCII and not *really* a register number/address, or > > something like this: > > > > gpio@0 { > > apple,smc-key-base = "gP00"; > > ... > > } > > > > gpio@1 { > > apple,smc-key-base = "gp00"; > > ... > > } > > This would still require us to add a (one-cell) "reg" property and > would require adding the appropriate "#address-cells" and > "#size-cells" properties to the SMC node. Yes, and at that point, as I suggested, it probably would be better to use: #address-cells = <1>; #size-cells = <0>; gpio@67503030 { reg = <0x67503030>; }; gpio@67703030 { reg = <0x67703030>; }; Then the "reg" has a meaning that is directly related to the SMC. > > But this ties back to the device enumeration too, since right now the DT > > does not drive that (we'd have to add the subdevice to the mfd subdevice > > list somehow anyway, if we don't switch to compatibles). > > > > I'd love to hear Rob's opinion on this one, and also whether the > > existing Linux and OpenBSD code would currently find gpio@0 {} instead > > of gpio {} for backwards compat. > > The OpenBSD driver does a lookup by name and the "@0" is part of that > name. So that would break backwards compat. Oh, that's annoying - and is a different behaviour to Linux. On Linux, we only look at the node name up to the @ when matching (see of_node_name_eq() in drivers/of/base.c, so it doesn't matter to Linux what follows the @ when you try to look up a node named "gpio" - you'll find gpio@anythingyoulike. > Maybe just name the slave GPIO controller "gpio-slave"? If we add > compatibles, the compatibles for the nodes should propbably be > different such that we can switch to do a lookup by compatible? I don't think the DT folk would be happy with "gpio-slave" because node names are supposed to be generic. Also, "slave" probably isn't a good choice of name in this modern era given past history. Rather than the above, we could use "reg" to indicate which GPIO controller we're talking about, and lookup the reg value in a table to give the key. So gpio@0, reg=<0> => gP00, gpio@1, reg=<1> => gp00. gpio@2, reg=<2> => whatever next. That sounds like it won't break the existing OpenBSD. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 14:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 14:54 UTC (permalink / raw) To: Mark Kettenis Cc: Hector Martin, linus.walleij, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 04:25:49PM +0200, Mark Kettenis wrote: > > Date: Tue, 6 Sep 2022 22:53:47 +0900 > > From: Hector Martin <marcan@marcan.st> > > > > I agree that this is something to think about (I was about to reply on > > the subject). > > > > I can think of two ways: using `reg` for the key name, but that feels > > icky since it's ASCII and not *really* a register number/address, or > > something like this: > > > > gpio@0 { > > apple,smc-key-base = "gP00"; > > ... > > } > > > > gpio@1 { > > apple,smc-key-base = "gp00"; > > ... > > } > > This would still require us to add a (one-cell) "reg" property and > would require adding the appropriate "#address-cells" and > "#size-cells" properties to the SMC node. Yes, and at that point, as I suggested, it probably would be better to use: #address-cells = <1>; #size-cells = <0>; gpio@67503030 { reg = <0x67503030>; }; gpio@67703030 { reg = <0x67703030>; }; Then the "reg" has a meaning that is directly related to the SMC. > > But this ties back to the device enumeration too, since right now the DT > > does not drive that (we'd have to add the subdevice to the mfd subdevice > > list somehow anyway, if we don't switch to compatibles). > > > > I'd love to hear Rob's opinion on this one, and also whether the > > existing Linux and OpenBSD code would currently find gpio@0 {} instead > > of gpio {} for backwards compat. > > The OpenBSD driver does a lookup by name and the "@0" is part of that > name. So that would break backwards compat. Oh, that's annoying - and is a different behaviour to Linux. On Linux, we only look at the node name up to the @ when matching (see of_node_name_eq() in drivers/of/base.c, so it doesn't matter to Linux what follows the @ when you try to look up a node named "gpio" - you'll find gpio@anythingyoulike. > Maybe just name the slave GPIO controller "gpio-slave"? If we add > compatibles, the compatibles for the nodes should propbably be > different such that we can switch to do a lookup by compatible? I don't think the DT folk would be happy with "gpio-slave" because node names are supposed to be generic. Also, "slave" probably isn't a good choice of name in this modern era given past history. Rather than the above, we could use "reg" to indicate which GPIO controller we're talking about, and lookup the reg value in a table to give the key. So gpio@0, reg=<0> => gP00, gpio@1, reg=<1> => gp00. gpio@2, reg=<2> => whatever next. That sounds like it won't break the existing OpenBSD. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 14:54 ` Russell King (Oracle) @ 2022-09-06 15:38 ` Mark Kettenis -1 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-06 15:38 UTC (permalink / raw) To: Russell King (Oracle) Cc: marcan, linus.walleij, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Tue, 6 Sep 2022 15:54:50 +0100 > From: "Russell King (Oracle)" <linux@armlinux.org.uk> > > On Tue, Sep 06, 2022 at 04:25:49PM +0200, Mark Kettenis wrote: > > > Date: Tue, 6 Sep 2022 22:53:47 +0900 > > > From: Hector Martin <marcan@marcan.st> > > > > > > I agree that this is something to think about (I was about to reply on > > > the subject). > > > > > > I can think of two ways: using `reg` for the key name, but that feels > > > icky since it's ASCII and not *really* a register number/address, or > > > something like this: > > > > > > gpio@0 { > > > apple,smc-key-base = "gP00"; > > > ... > > > } > > > > > > gpio@1 { > > > apple,smc-key-base = "gp00"; > > > ... > > > } > > > > This would still require us to add a (one-cell) "reg" property and > > would require adding the appropriate "#address-cells" and > > "#size-cells" properties to the SMC node. > > Yes, and at that point, as I suggested, it probably would be better > to use: > > #address-cells = <1>; > #size-cells = <0>; > > gpio@67503030 { > reg = <0x67503030>; > }; > > gpio@67703030 { > reg = <0x67703030>; > }; > > Then the "reg" has a meaning that is directly related to the SMC. > > > > But this ties back to the device enumeration too, since right now the DT > > > does not drive that (we'd have to add the subdevice to the mfd subdevice > > > list somehow anyway, if we don't switch to compatibles). > > > > > > I'd love to hear Rob's opinion on this one, and also whether the > > > existing Linux and OpenBSD code would currently find gpio@0 {} instead > > > of gpio {} for backwards compat. > > > > The OpenBSD driver does a lookup by name and the "@0" is part of that > > name. So that would break backwards compat. > > Oh, that's annoying - and is a different behaviour to Linux. > > On Linux, we only look at the node name up to the @ when matching (see > of_node_name_eq() in drivers/of/base.c, so it doesn't matter to Linux > what follows the @ when you try to look up a node named "gpio" - you'll > find gpio@anythingyoulike. So maybe I should change our code to match what Linux does. OpenBSD 7.2 is scheduled for release on November 1st, and I can probably get that change in quickly. If we can hold off updating the device trees in the Asahi installer until then the transition should be smooth enough. > > Maybe just name the slave GPIO controller "gpio-slave"? If we add > > compatibles, the compatibles for the nodes should propbably be > > different such that we can switch to do a lookup by compatible? > > I don't think the DT folk would be happy with "gpio-slave" because > node names are supposed to be generic. I don't think that rule applies to "named" sub-nodes like this where the name is actually significant. > Also, "slave" probably isn't a good choice of name in this modern > era given past history. Yes, we don't have to follow Apple's terminology here. > Rather than the above, we could use "reg" to indicate which GPIO > controller we're talking about, and lookup the reg value in a table > to give the key. So gpio@0, reg=<0> => gP00, gpio@1, reg=<1> => gp00. > gpio@2, reg=<2> => whatever next. > > That sounds like it won't break the existing OpenBSD. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! > ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 15:38 ` Mark Kettenis 0 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-06 15:38 UTC (permalink / raw) To: Russell King (Oracle) Cc: marcan, linus.walleij, robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Tue, 6 Sep 2022 15:54:50 +0100 > From: "Russell King (Oracle)" <linux@armlinux.org.uk> > > On Tue, Sep 06, 2022 at 04:25:49PM +0200, Mark Kettenis wrote: > > > Date: Tue, 6 Sep 2022 22:53:47 +0900 > > > From: Hector Martin <marcan@marcan.st> > > > > > > I agree that this is something to think about (I was about to reply on > > > the subject). > > > > > > I can think of two ways: using `reg` for the key name, but that feels > > > icky since it's ASCII and not *really* a register number/address, or > > > something like this: > > > > > > gpio@0 { > > > apple,smc-key-base = "gP00"; > > > ... > > > } > > > > > > gpio@1 { > > > apple,smc-key-base = "gp00"; > > > ... > > > } > > > > This would still require us to add a (one-cell) "reg" property and > > would require adding the appropriate "#address-cells" and > > "#size-cells" properties to the SMC node. > > Yes, and at that point, as I suggested, it probably would be better > to use: > > #address-cells = <1>; > #size-cells = <0>; > > gpio@67503030 { > reg = <0x67503030>; > }; > > gpio@67703030 { > reg = <0x67703030>; > }; > > Then the "reg" has a meaning that is directly related to the SMC. > > > > But this ties back to the device enumeration too, since right now the DT > > > does not drive that (we'd have to add the subdevice to the mfd subdevice > > > list somehow anyway, if we don't switch to compatibles). > > > > > > I'd love to hear Rob's opinion on this one, and also whether the > > > existing Linux and OpenBSD code would currently find gpio@0 {} instead > > > of gpio {} for backwards compat. > > > > The OpenBSD driver does a lookup by name and the "@0" is part of that > > name. So that would break backwards compat. > > Oh, that's annoying - and is a different behaviour to Linux. > > On Linux, we only look at the node name up to the @ when matching (see > of_node_name_eq() in drivers/of/base.c, so it doesn't matter to Linux > what follows the @ when you try to look up a node named "gpio" - you'll > find gpio@anythingyoulike. So maybe I should change our code to match what Linux does. OpenBSD 7.2 is scheduled for release on November 1st, and I can probably get that change in quickly. If we can hold off updating the device trees in the Asahi installer until then the transition should be smooth enough. > > Maybe just name the slave GPIO controller "gpio-slave"? If we add > > compatibles, the compatibles for the nodes should propbably be > > different such that we can switch to do a lookup by compatible? > > I don't think the DT folk would be happy with "gpio-slave" because > node names are supposed to be generic. I don't think that rule applies to "named" sub-nodes like this where the name is actually significant. > Also, "slave" probably isn't a good choice of name in this modern > era given past history. Yes, we don't have to follow Apple's terminology here. > Rather than the above, we could use "reg" to indicate which GPIO > controller we're talking about, and lookup the reg value in a table > to give the key. So gpio@0, reg=<0> => gP00, gpio@1, reg=<1> => gp00. > gpio@2, reg=<2> => whatever next. > > That sounds like it won't break the existing OpenBSD. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 14:54 ` Russell King (Oracle) @ 2022-09-06 15:55 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 15:55 UTC (permalink / raw) To: Russell King (Oracle) Cc: Mark Kettenis, Hector Martin, linus.walleij, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 03:54:50PM +0100, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 04:25:49PM +0200, Mark Kettenis wrote: > > > Date: Tue, 6 Sep 2022 22:53:47 +0900 > > > From: Hector Martin <marcan@marcan.st> > > > > > > I agree that this is something to think about (I was about to reply on > > > the subject). > > > > > > I can think of two ways: using `reg` for the key name, but that feels > > > icky since it's ASCII and not *really* a register number/address, or > > > something like this: > > > > > > gpio@0 { > > > apple,smc-key-base = "gP00"; > > > ... > > > } > > > > > > gpio@1 { > > > apple,smc-key-base = "gp00"; > > > ... > > > } > > > > This would still require us to add a (one-cell) "reg" property and > > would require adding the appropriate "#address-cells" and > > "#size-cells" properties to the SMC node. > > Yes, and at that point, as I suggested, it probably would be better > to use: > > #address-cells = <1>; > #size-cells = <0>; > > gpio@67503030 { > reg = <0x67503030>; > }; > > gpio@67703030 { > reg = <0x67703030>; > }; > > Then the "reg" has a meaning that is directly related to the SMC. That's certainly odd, but if that's how it is addressed, then okay I suppose. > > > > But this ties back to the device enumeration too, since right now the DT > > > does not drive that (we'd have to add the subdevice to the mfd subdevice > > > list somehow anyway, if we don't switch to compatibles). > > > > > > I'd love to hear Rob's opinion on this one, and also whether the > > > existing Linux and OpenBSD code would currently find gpio@0 {} instead > > > of gpio {} for backwards compat. Node names are generally not considered ABI except when they are. :) Generally, core code doesn't care. Specific bindings with defined child nodes often do, but finding nodes by compatible is strongly preferred. Linux drivers can bind by node name (w/o unit-address), but that's really only ever done on ancient h/w. > > > > The OpenBSD driver does a lookup by name and the "@0" is part of that > > name. So that would break backwards compat. > > Oh, that's annoying - and is a different behaviour to Linux. > > On Linux, we only look at the node name up to the @ when matching (see > of_node_name_eq() in drivers/of/base.c, so it doesn't matter to Linux > what follows the @ when you try to look up a node named "gpio" - you'll > find gpio@anythingyoulike. > > > Maybe just name the slave GPIO controller "gpio-slave"? If we add > > compatibles, the compatibles for the nodes should propbably be > > different such that we can switch to do a lookup by compatible? > > I don't think the DT folk would be happy with "gpio-slave" because > node names are supposed to be generic. Also, "slave" probably isn't > a good choice of name in this modern era given past history. Yeah, not a great choice for both reasons. > Rather than the above, we could use "reg" to indicate which GPIO > controller we're talking about, and lookup the reg value in a table > to give the key. So gpio@0, reg=<0> => gP00, gpio@1, reg=<1> => gp00. > gpio@2, reg=<2> => whatever next. Keep in mind that for any level, there is only 1 address space. So if there's anything else with multiple instances, they share the same address space. IOW, you couldn't have say 'rtc@1'. (Another example of why I want to see a full picture.) > > That sounds like it won't break the existing OpenBSD. No? Isn't OpenBSD looking for 'gpio' which wouldn't find 'gpio@0'? Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 15:55 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 15:55 UTC (permalink / raw) To: Russell King (Oracle) Cc: Mark Kettenis, Hector Martin, linus.walleij, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 03:54:50PM +0100, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 04:25:49PM +0200, Mark Kettenis wrote: > > > Date: Tue, 6 Sep 2022 22:53:47 +0900 > > > From: Hector Martin <marcan@marcan.st> > > > > > > I agree that this is something to think about (I was about to reply on > > > the subject). > > > > > > I can think of two ways: using `reg` for the key name, but that feels > > > icky since it's ASCII and not *really* a register number/address, or > > > something like this: > > > > > > gpio@0 { > > > apple,smc-key-base = "gP00"; > > > ... > > > } > > > > > > gpio@1 { > > > apple,smc-key-base = "gp00"; > > > ... > > > } > > > > This would still require us to add a (one-cell) "reg" property and > > would require adding the appropriate "#address-cells" and > > "#size-cells" properties to the SMC node. > > Yes, and at that point, as I suggested, it probably would be better > to use: > > #address-cells = <1>; > #size-cells = <0>; > > gpio@67503030 { > reg = <0x67503030>; > }; > > gpio@67703030 { > reg = <0x67703030>; > }; > > Then the "reg" has a meaning that is directly related to the SMC. That's certainly odd, but if that's how it is addressed, then okay I suppose. > > > > But this ties back to the device enumeration too, since right now the DT > > > does not drive that (we'd have to add the subdevice to the mfd subdevice > > > list somehow anyway, if we don't switch to compatibles). > > > > > > I'd love to hear Rob's opinion on this one, and also whether the > > > existing Linux and OpenBSD code would currently find gpio@0 {} instead > > > of gpio {} for backwards compat. Node names are generally not considered ABI except when they are. :) Generally, core code doesn't care. Specific bindings with defined child nodes often do, but finding nodes by compatible is strongly preferred. Linux drivers can bind by node name (w/o unit-address), but that's really only ever done on ancient h/w. > > > > The OpenBSD driver does a lookup by name and the "@0" is part of that > > name. So that would break backwards compat. > > Oh, that's annoying - and is a different behaviour to Linux. > > On Linux, we only look at the node name up to the @ when matching (see > of_node_name_eq() in drivers/of/base.c, so it doesn't matter to Linux > what follows the @ when you try to look up a node named "gpio" - you'll > find gpio@anythingyoulike. > > > Maybe just name the slave GPIO controller "gpio-slave"? If we add > > compatibles, the compatibles for the nodes should propbably be > > different such that we can switch to do a lookup by compatible? > > I don't think the DT folk would be happy with "gpio-slave" because > node names are supposed to be generic. Also, "slave" probably isn't > a good choice of name in this modern era given past history. Yeah, not a great choice for both reasons. > Rather than the above, we could use "reg" to indicate which GPIO > controller we're talking about, and lookup the reg value in a table > to give the key. So gpio@0, reg=<0> => gP00, gpio@1, reg=<1> => gp00. > gpio@2, reg=<2> => whatever next. Keep in mind that for any level, there is only 1 address space. So if there's anything else with multiple instances, they share the same address space. IOW, you couldn't have say 'rtc@1'. (Another example of why I want to see a full picture.) > > That sounds like it won't break the existing OpenBSD. No? Isn't OpenBSD looking for 'gpio' which wouldn't find 'gpio@0'? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 13:28 ` Hector Martin @ 2022-09-06 13:46 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-06 13:46 UTC (permalink / raw) To: Hector Martin Cc: Mark Kettenis, Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 6, 2022 at 3:28 PM Hector Martin <marcan@marcan.st> wrote: > On 06/09/2022 20.57, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote: > > This comes from the FDT background in OpenFirmware, and there is > > definitely a timeline perspective (also called "waterfall model") in that > > line of thinking: a DT is written that describes the hardware and flashed > > into the BIOS and never changed, then the operating system is > > implemented at a later point. This is how e.g. the PC ACPI BIOS tables > > are also thinking about themselves. > > Yes, but again, that only makes sense from the point of view of > describing hardware that exists, is useful, and could be used by the OS. > > For any given platform X, if platform X does not use the secondary GPIO > controller for any service describable in the DT, then there is no point > in describing that GPIO controller. Same way ACPI tables do not describe > every single physical GPIO available on a platform, just whatever is > used by the AML. Good point. I don't know what ambition DT should have here. If there is a discrete component on I2C for example, we tend to describe it fully, this kind of stuff with misc "dark silicon" didn't exist when DT was first conceived. > If some day we find a use for those GPIOs, that would require a DT > change *anyway*, to describe that usage, and the controller could be > described then (we did something like that, using a GPIO that Apple > doesn't, for the interim display-backlight power control support, though > that is a temporary hack that will go away). Heck, we don't even know > what these GPIOs are connected to right now! > > Ultimately, we're working with a reverse engineered platform here, and > DTs will inevitaby be incremental. (...) That's OK, I think the patch series is good enough as it is and should be merged, so I have added my Reviewed-by. I think the world is a better place with support for Apple silicon being developed in-tree. > I'm a lot more > interested in getting bindings upstreamed ASAP (so we can start > guaranteeing no backwards-compat breaks, which is important to avoid > outright breakage) than I am in trying to be exhaustive up front with > device instances. It's perfectly fine to say that users have to upgrade > both their DTs and kernels to get newer hardware support, on these > platforms. I agree. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 13:46 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-06 13:46 UTC (permalink / raw) To: Hector Martin Cc: Mark Kettenis, Russell King (Oracle), robh, krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 6, 2022 at 3:28 PM Hector Martin <marcan@marcan.st> wrote: > On 06/09/2022 20.57, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote: > > This comes from the FDT background in OpenFirmware, and there is > > definitely a timeline perspective (also called "waterfall model") in that > > line of thinking: a DT is written that describes the hardware and flashed > > into the BIOS and never changed, then the operating system is > > implemented at a later point. This is how e.g. the PC ACPI BIOS tables > > are also thinking about themselves. > > Yes, but again, that only makes sense from the point of view of > describing hardware that exists, is useful, and could be used by the OS. > > For any given platform X, if platform X does not use the secondary GPIO > controller for any service describable in the DT, then there is no point > in describing that GPIO controller. Same way ACPI tables do not describe > every single physical GPIO available on a platform, just whatever is > used by the AML. Good point. I don't know what ambition DT should have here. If there is a discrete component on I2C for example, we tend to describe it fully, this kind of stuff with misc "dark silicon" didn't exist when DT was first conceived. > If some day we find a use for those GPIOs, that would require a DT > change *anyway*, to describe that usage, and the controller could be > described then (we did something like that, using a GPIO that Apple > doesn't, for the interim display-backlight power control support, though > that is a temporary hack that will go away). Heck, we don't even know > what these GPIOs are connected to right now! > > Ultimately, we're working with a reverse engineered platform here, and > DTs will inevitaby be incremental. (...) That's OK, I think the patch series is good enough as it is and should be merged, so I have added my Reviewed-by. I think the world is a better place with support for Apple silicon being developed in-tree. > I'm a lot more > interested in getting bindings upstreamed ASAP (so we can start > guaranteeing no backwards-compat breaks, which is important to avoid > outright breakage) than I am in trying to be exhaustive up front with > device instances. It's perfectly fine to say that users have to upgrade > both their DTs and kernels to get newer hardware support, on these > platforms. I agree. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 11:36 ` Hector Martin @ 2022-09-06 15:34 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 15:34 UTC (permalink / raw) To: Hector Martin Cc: Linus Walleij, Mark Kettenis, Russell King (Oracle), krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 08:36:25PM +0900, Hector Martin wrote: > On 06/09/2022 20.22, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > >> Another argument for having sub-nodes is that the firmware actually > >> exposes *two* GPIO controllers. For now we only support the "master" > >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > >> separate set of SMC "keys". We currently don't need any of the pins > >> on the "slave", so we don't expose it in the DT yet. > > > > That sounds backward, like we don't expose device X as DT node > > because $OS doesn't use it yet. DT should just expose (by nodes or > > other ways) all hardware that exist or at least all hardware we know > > about no matter what $OS is using. > > How so? The are piles and piles of unused hardware not exposed in the > DT, and piles and piles of hardware that will be used but we haven't > figured out how to do it yet, so it's not exposed. For example, we know > there are like 8 or so UARTs, but we don't define them in the DT because > they are not connected to anything on any existing device and we don't > need them. Apple does the same thing in their DTs (only used hardware is > defined). > > I don't really see the point of exposing a GPIO controller when we don't > actually do anything with the pins yet, and might never do so. Having > drivers bind and stay unused just increases the amount of code running > without any ultimate purpose, so why do it? It's not like any other OS > would use the hardware either - GPIOs are only useful if they are > referenced in the DT for something, and we don't have anything that > would reference these. > > For SMC in particular, there's a huge amount of functionality we don't > have drivers for yet, and I don't see the point of trying to conjure up > DT bindings for it until someone writes a driver (and has a reason to do > so) :) Exposing in a DT is one thing. Defining in the binding is another. Even if it's not complete bindings, but just a fuller description of what functionality the MFD contains is. For example, just knowing there are 2 instances of GPIO, I'm much more inclined to agree GPIO should be a subnode. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 15:34 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 15:34 UTC (permalink / raw) To: Hector Martin Cc: Linus Walleij, Mark Kettenis, Russell King (Oracle), krzysztof.kozlowski, arnd, lee, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 08:36:25PM +0900, Hector Martin wrote: > On 06/09/2022 20.22, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > >> Another argument for having sub-nodes is that the firmware actually > >> exposes *two* GPIO controllers. For now we only support the "master" > >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > >> separate set of SMC "keys". We currently don't need any of the pins > >> on the "slave", so we don't expose it in the DT yet. > > > > That sounds backward, like we don't expose device X as DT node > > because $OS doesn't use it yet. DT should just expose (by nodes or > > other ways) all hardware that exist or at least all hardware we know > > about no matter what $OS is using. > > How so? The are piles and piles of unused hardware not exposed in the > DT, and piles and piles of hardware that will be used but we haven't > figured out how to do it yet, so it's not exposed. For example, we know > there are like 8 or so UARTs, but we don't define them in the DT because > they are not connected to anything on any existing device and we don't > need them. Apple does the same thing in their DTs (only used hardware is > defined). > > I don't really see the point of exposing a GPIO controller when we don't > actually do anything with the pins yet, and might never do so. Having > drivers bind and stay unused just increases the amount of code running > without any ultimate purpose, so why do it? It's not like any other OS > would use the hardware either - GPIOs are only useful if they are > referenced in the DT for something, and we don't have anything that > would reference these. > > For SMC in particular, there's a huge amount of functionality we don't > have drivers for yet, and I don't see the point of trying to conjure up > DT bindings for it until someone writes a driver (and has a reason to do > so) :) Exposing in a DT is one thing. Defining in the binding is another. Even if it's not complete bindings, but just a fuller description of what functionality the MFD contains is. For example, just knowing there are 2 instances of GPIO, I'm much more inclined to agree GPIO should be a subnode. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 9:04 ` Russell King (Oracle) @ 2022-09-06 16:10 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 16:10 UTC (permalink / raw) To: Russell King (Oracle) Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 10:04:45AM +0100, Russell King (Oracle) wrote: > On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > > This one is actually pretty odd in that the child nodes don't have a > > compatible string which breaks the automagical probing. > > I don't think that is necessarily true, and I don't think it's true in > this case. It is, because you are creating the devices in the driver rather than creating devices based on child nodes that exist. > > The SMC core driver instructs the MFD core to create devices for the > individual functional items: > > static const struct mfd_cell apple_smc_devs[] = { > { > .name = "macsmc-gpio", > }, > { > .name = "macsmc-hid", > }, > { > .name = "macsmc-power", > }, > { > .name = "macsmc-reboot", > }, > { > .name = "macsmc-rtc", > }, > }; > > Since MFD uses platform devices for these, they get all the normal > functionality that these devices have, which include matching by > device name ot the driver name, and udev events being appropriately > triggered. As long as the platform drivers for these devices have the > correct modalias lines, autoloading of the modules will work and the > drivers will be correctly matched and probed. Yes, and that's how MFD devices with no child nodes work. The difference is those get any DT info out of the parent node. Here you are presumably manually getting the child DT node you want for each driver. > The Asahi kernel builds most of the platform support as modules, > including these, so we know it works (if it didn't, then lots of > module autoloading would be broken on non-DT platforms.) > > > > Again the separate nodes are there because the RTC and the reboot > > > functionality are logically separate and handled by different MFD > > > sub-drivers in Linux. > > > > It's really a question of whether the subset of functionality is going > > to get reused on its own or has its own resources in DT. MFD bindings > > are done both ways. > > I think the current position on what to do about these is that everyone > is looking for someone else to make a decision, and no one wants to! I'm just looking for more information first. > Firstly, I don't think that the number of properties in a node should > have a bearing on the design of the DT binding - what should have a > bearing is the logical partitioning of functionality. It's not strictly about number of properties. Though nodes with only a compatible string is generally a red flag for me. > Mark suggests that it would take six months for OpenBSD to transition to > some other description - for example, if we merged the nodes. The risk you take when using undocumented bindings... > Hector says that MacOS's firmware description has the nodes merged, but > their description is a mess. > > The overall preference seems to be to keep the sub-nodes unless there > is a strong technical reason not to. > > The feeling I am getting from the review is that there doesn't seem to > be a strong technical reason to merge the nodes - there are desires and > preferences, but nothing concrete. > > So at this point, I think it would make sense if I post a v2 with all > the updates so far (sorry, given the long drawn out discussions on > this, I've lost track of what changes have been made to the code, so > I won't include a detailed change log.) As I said elsewhere, sub-nodes is probably the right choice here. I think they need compatible strings in the child nodes, and addressing has to be sorted out which it seems may also break OpenBSD. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 16:10 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 16:10 UTC (permalink / raw) To: Russell King (Oracle) Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Tue, Sep 06, 2022 at 10:04:45AM +0100, Russell King (Oracle) wrote: > On Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > > This one is actually pretty odd in that the child nodes don't have a > > compatible string which breaks the automagical probing. > > I don't think that is necessarily true, and I don't think it's true in > this case. It is, because you are creating the devices in the driver rather than creating devices based on child nodes that exist. > > The SMC core driver instructs the MFD core to create devices for the > individual functional items: > > static const struct mfd_cell apple_smc_devs[] = { > { > .name = "macsmc-gpio", > }, > { > .name = "macsmc-hid", > }, > { > .name = "macsmc-power", > }, > { > .name = "macsmc-reboot", > }, > { > .name = "macsmc-rtc", > }, > }; > > Since MFD uses platform devices for these, they get all the normal > functionality that these devices have, which include matching by > device name ot the driver name, and udev events being appropriately > triggered. As long as the platform drivers for these devices have the > correct modalias lines, autoloading of the modules will work and the > drivers will be correctly matched and probed. Yes, and that's how MFD devices with no child nodes work. The difference is those get any DT info out of the parent node. Here you are presumably manually getting the child DT node you want for each driver. > The Asahi kernel builds most of the platform support as modules, > including these, so we know it works (if it didn't, then lots of > module autoloading would be broken on non-DT platforms.) > > > > Again the separate nodes are there because the RTC and the reboot > > > functionality are logically separate and handled by different MFD > > > sub-drivers in Linux. > > > > It's really a question of whether the subset of functionality is going > > to get reused on its own or has its own resources in DT. MFD bindings > > are done both ways. > > I think the current position on what to do about these is that everyone > is looking for someone else to make a decision, and no one wants to! I'm just looking for more information first. > Firstly, I don't think that the number of properties in a node should > have a bearing on the design of the DT binding - what should have a > bearing is the logical partitioning of functionality. It's not strictly about number of properties. Though nodes with only a compatible string is generally a red flag for me. > Mark suggests that it would take six months for OpenBSD to transition to > some other description - for example, if we merged the nodes. The risk you take when using undocumented bindings... > Hector says that MacOS's firmware description has the nodes merged, but > their description is a mess. > > The overall preference seems to be to keep the sub-nodes unless there > is a strong technical reason not to. > > The feeling I am getting from the review is that there doesn't seem to > be a strong technical reason to merge the nodes - there are desires and > preferences, but nothing concrete. > > So at this point, I think it would make sense if I post a v2 with all > the updates so far (sorry, given the long drawn out discussions on > this, I've lost track of what changes have been made to the code, so > I won't include a detailed change log.) As I said elsewhere, sub-nodes is probably the right choice here. I think they need compatible strings in the child nodes, and addressing has to be sorted out which it seems may also break OpenBSD. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 16:10 ` Rob Herring @ 2022-09-06 17:00 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 17:00 UTC (permalink / raw) To: Rob Herring, Russell King (Oracle) Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 07/09/2022 01.10, Rob Herring wrote: >> So at this point, I think it would make sense if I post a v2 with all >> the updates so far (sorry, given the long drawn out discussions on >> this, I've lost track of what changes have been made to the code, so >> I won't include a detailed change log.) > > As I said elsewhere, sub-nodes is probably the right choice here. I > think they need compatible strings in the child nodes, and addressing > has to be sorted out which it seems may also break OpenBSD. So addressing only makes sense for GPIO, out of the nodes we have so far - that's the only thing with two discrete instances whose access can be entirely described by a single base key name, and which are otherwise compatible. Everything else is pretty much single-instance, and talks to multiple keys, so there isn't one single "address" key that would make semantic sense to use as the node address. There are some indexed keys, but at a deeper level (e.g. multiple battery cells part of the charge control subsystem, multiple Type C ports as part of the AC/power input subsystem, etc.). And in those cases, these subdevices are mostly homogeneous and we would never need multiple nodes for them at the DT level, they'd just be implicitly handled by those drivers. GPIO is quite special in that 1) it only has a single key type (which is overloaded using advanced features to provide, effectively, sub-registers to control all the GPIO features per pin), 2) a single key represents a single pin, 3) keys are numbered in a reasoanble way, and 4) there are two prefixes for two discrete GPIO controllers. For pretty much everything else SMC does, we just have a bag of keys with no real rhyme nor reason from the point of view of an "address space". Given that, how would this work? Is it legal/reasonable for only the gpio nodes to have addressing/reg properties, and everything else to just have a node name with no concept of address? Does it even make sense to special case gpio in this way, vs. just having something like gpio {} / gpio-sec {} (if we ever even need gpio-sec, which is an open question)? - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 17:00 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 17:00 UTC (permalink / raw) To: Rob Herring, Russell King (Oracle) Cc: Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 07/09/2022 01.10, Rob Herring wrote: >> So at this point, I think it would make sense if I post a v2 with all >> the updates so far (sorry, given the long drawn out discussions on >> this, I've lost track of what changes have been made to the code, so >> I won't include a detailed change log.) > > As I said elsewhere, sub-nodes is probably the right choice here. I > think they need compatible strings in the child nodes, and addressing > has to be sorted out which it seems may also break OpenBSD. So addressing only makes sense for GPIO, out of the nodes we have so far - that's the only thing with two discrete instances whose access can be entirely described by a single base key name, and which are otherwise compatible. Everything else is pretty much single-instance, and talks to multiple keys, so there isn't one single "address" key that would make semantic sense to use as the node address. There are some indexed keys, but at a deeper level (e.g. multiple battery cells part of the charge control subsystem, multiple Type C ports as part of the AC/power input subsystem, etc.). And in those cases, these subdevices are mostly homogeneous and we would never need multiple nodes for them at the DT level, they'd just be implicitly handled by those drivers. GPIO is quite special in that 1) it only has a single key type (which is overloaded using advanced features to provide, effectively, sub-registers to control all the GPIO features per pin), 2) a single key represents a single pin, 3) keys are numbered in a reasoanble way, and 4) there are two prefixes for two discrete GPIO controllers. For pretty much everything else SMC does, we just have a bag of keys with no real rhyme nor reason from the point of view of an "address space". Given that, how would this work? Is it legal/reasonable for only the gpio nodes to have addressing/reg properties, and everything else to just have a node name with no concept of address? Does it even make sense to special case gpio in this way, vs. just having something like gpio {} / gpio-sec {} (if we ever even need gpio-sec, which is an open question)? - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 17:00 ` Hector Martin @ 2022-09-06 17:35 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 17:35 UTC (permalink / raw) To: Hector Martin Cc: Russell King (Oracle), Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: > On 07/09/2022 01.10, Rob Herring wrote: > >> So at this point, I think it would make sense if I post a v2 with all > >> the updates so far (sorry, given the long drawn out discussions on > >> this, I've lost track of what changes have been made to the code, so > >> I won't include a detailed change log.) > > > > As I said elsewhere, sub-nodes is probably the right choice here. I > > think they need compatible strings in the child nodes, and addressing > > has to be sorted out which it seems may also break OpenBSD. > > So addressing only makes sense for GPIO, out of the nodes we have so far > - that's the only thing with two discrete instances whose access can be > entirely described by a single base key name, and which are otherwise > compatible. > > Everything else is pretty much single-instance, and talks to multiple > keys, so there isn't one single "address" key that would make semantic > sense to use as the node address. Unit-addresses are just the first address in 'reg'. So multiple addresses or not doesn't really matter. > There are some indexed keys, but at a > deeper level (e.g. multiple battery cells part of the charge control > subsystem, multiple Type C ports as part of the AC/power input > subsystem, etc.). And in those cases, these subdevices are mostly > homogeneous and we would never need multiple nodes for them at the DT > level, they'd just be implicitly handled by those drivers. Type-C will be fun depending on how much of the muxing/altmode details have to get exposed. > GPIO is quite special in that 1) it only has a single key type (which is > overloaded using advanced features to provide, effectively, > sub-registers to control all the GPIO features per pin), 2) a single key > represents a single pin, 3) keys are numbered in a reasoanble way, and > 4) there are two prefixes for two discrete GPIO controllers. For pretty > much everything else SMC does, we just have a bag of keys with no real > rhyme nor reason from the point of view of an "address space". > > Given that, how would this work? Is it legal/reasonable for only the > gpio nodes to have addressing/reg properties, and everything else to > just have a node name with no concept of address? Not ideal, but allowed. > Does it even make > sense to special case gpio in this way, vs. just having something like > gpio {} / gpio-sec {} (if we ever even need gpio-sec, which is an open > question)? If not unit-addresses, the 2nd choice we do is 'gpio-0', 'gpio-1', etc. Though that is mainly in the GPIO based consumer bindings like gpio-pwm, spi-gpio, etc. where there's really not anything to use for an address. If only those 2 nodes, then I really don't care so much and gpio-sec would be fine. It's 1 node in 1 binding. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 17:35 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-06 17:35 UTC (permalink / raw) To: Hector Martin Cc: Russell King (Oracle), Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: > On 07/09/2022 01.10, Rob Herring wrote: > >> So at this point, I think it would make sense if I post a v2 with all > >> the updates so far (sorry, given the long drawn out discussions on > >> this, I've lost track of what changes have been made to the code, so > >> I won't include a detailed change log.) > > > > As I said elsewhere, sub-nodes is probably the right choice here. I > > think they need compatible strings in the child nodes, and addressing > > has to be sorted out which it seems may also break OpenBSD. > > So addressing only makes sense for GPIO, out of the nodes we have so far > - that's the only thing with two discrete instances whose access can be > entirely described by a single base key name, and which are otherwise > compatible. > > Everything else is pretty much single-instance, and talks to multiple > keys, so there isn't one single "address" key that would make semantic > sense to use as the node address. Unit-addresses are just the first address in 'reg'. So multiple addresses or not doesn't really matter. > There are some indexed keys, but at a > deeper level (e.g. multiple battery cells part of the charge control > subsystem, multiple Type C ports as part of the AC/power input > subsystem, etc.). And in those cases, these subdevices are mostly > homogeneous and we would never need multiple nodes for them at the DT > level, they'd just be implicitly handled by those drivers. Type-C will be fun depending on how much of the muxing/altmode details have to get exposed. > GPIO is quite special in that 1) it only has a single key type (which is > overloaded using advanced features to provide, effectively, > sub-registers to control all the GPIO features per pin), 2) a single key > represents a single pin, 3) keys are numbered in a reasoanble way, and > 4) there are two prefixes for two discrete GPIO controllers. For pretty > much everything else SMC does, we just have a bag of keys with no real > rhyme nor reason from the point of view of an "address space". > > Given that, how would this work? Is it legal/reasonable for only the > gpio nodes to have addressing/reg properties, and everything else to > just have a node name with no concept of address? Not ideal, but allowed. > Does it even make > sense to special case gpio in this way, vs. just having something like > gpio {} / gpio-sec {} (if we ever even need gpio-sec, which is an open > question)? If not unit-addresses, the 2nd choice we do is 'gpio-0', 'gpio-1', etc. Though that is mainly in the GPIO based consumer bindings like gpio-pwm, spi-gpio, etc. where there's really not anything to use for an address. If only those 2 nodes, then I really don't care so much and gpio-sec would be fine. It's 1 node in 1 binding. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 17:35 ` Rob Herring @ 2022-09-06 17:40 ` Sven Peter -1 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-06 17:40 UTC (permalink / raw) To: Rob Herring, Hector Martin Cc: Russell King (Oracle), Mark Kettenis, krzysztof.kozlowski, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, open list:GPIO SUBSYSTEM, Krzysztof Kozlowski, devicetree On Tue, Sep 6, 2022, at 19:35, Rob Herring wrote: > On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: >> On 07/09/2022 01.10, Rob Herring wrote: >> >> So at this point, I think it would make sense if I post a v2 with all >> >> the updates so far (sorry, given the long drawn out discussions on >> >> this, I've lost track of what changes have been made to the code, so >> >> I won't include a detailed change log.) >> > >> > As I said elsewhere, sub-nodes is probably the right choice here. I >> > think they need compatible strings in the child nodes, and addressing >> > has to be sorted out which it seems may also break OpenBSD. >> >> So addressing only makes sense for GPIO, out of the nodes we have so far >> - that's the only thing with two discrete instances whose access can be >> entirely described by a single base key name, and which are otherwise >> compatible. >> >> Everything else is pretty much single-instance, and talks to multiple >> keys, so there isn't one single "address" key that would make semantic >> sense to use as the node address. > > Unit-addresses are just the first address in 'reg'. So multiple > addresses or not doesn't really matter. > >> There are some indexed keys, but at a >> deeper level (e.g. multiple battery cells part of the charge control >> subsystem, multiple Type C ports as part of the AC/power input >> subsystem, etc.). And in those cases, these subdevices are mostly >> homogeneous and we would never need multiple nodes for them at the DT >> level, they'd just be implicitly handled by those drivers. > > Type-C will be fun depending on how much of the muxing/altmode > details have to get exposed. Type-C is going to be a lot of "fun", but the SMC is not directly involved. I still don't have a full picture but these boards have TPS6598x chips which trigger the entire mess whenever a new mode was negotiated and the "Apple Type-C PHY" contains the actual mux. The SMC has a side channel to these TPS6598x chips as well but it seems to only handle charging without having to communicate with whatever kernel is running on the main processor. Sven ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 17:40 ` Sven Peter 0 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-06 17:40 UTC (permalink / raw) To: Rob Herring, Hector Martin Cc: Russell King (Oracle), Mark Kettenis, krzysztof.kozlowski, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, open list:GPIO SUBSYSTEM, Krzysztof Kozlowski, devicetree On Tue, Sep 6, 2022, at 19:35, Rob Herring wrote: > On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: >> On 07/09/2022 01.10, Rob Herring wrote: >> >> So at this point, I think it would make sense if I post a v2 with all >> >> the updates so far (sorry, given the long drawn out discussions on >> >> this, I've lost track of what changes have been made to the code, so >> >> I won't include a detailed change log.) >> > >> > As I said elsewhere, sub-nodes is probably the right choice here. I >> > think they need compatible strings in the child nodes, and addressing >> > has to be sorted out which it seems may also break OpenBSD. >> >> So addressing only makes sense for GPIO, out of the nodes we have so far >> - that's the only thing with two discrete instances whose access can be >> entirely described by a single base key name, and which are otherwise >> compatible. >> >> Everything else is pretty much single-instance, and talks to multiple >> keys, so there isn't one single "address" key that would make semantic >> sense to use as the node address. > > Unit-addresses are just the first address in 'reg'. So multiple > addresses or not doesn't really matter. > >> There are some indexed keys, but at a >> deeper level (e.g. multiple battery cells part of the charge control >> subsystem, multiple Type C ports as part of the AC/power input >> subsystem, etc.). And in those cases, these subdevices are mostly >> homogeneous and we would never need multiple nodes for them at the DT >> level, they'd just be implicitly handled by those drivers. > > Type-C will be fun depending on how much of the muxing/altmode > details have to get exposed. Type-C is going to be a lot of "fun", but the SMC is not directly involved. I still don't have a full picture but these boards have TPS6598x chips which trigger the entire mess whenever a new mode was negotiated and the "Apple Type-C PHY" contains the actual mux. The SMC has a side channel to these TPS6598x chips as well but it seems to only handle charging without having to communicate with whatever kernel is running on the main processor. Sven _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 17:35 ` Rob Herring @ 2022-09-06 18:38 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 18:38 UTC (permalink / raw) To: Rob Herring Cc: Russell King (Oracle), Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 07/09/2022 02.35, Rob Herring wrote: > On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: >> On 07/09/2022 01.10, Rob Herring wrote: >>>> So at this point, I think it would make sense if I post a v2 with all >>>> the updates so far (sorry, given the long drawn out discussions on >>>> this, I've lost track of what changes have been made to the code, so >>>> I won't include a detailed change log.) >>> >>> As I said elsewhere, sub-nodes is probably the right choice here. I >>> think they need compatible strings in the child nodes, and addressing >>> has to be sorted out which it seems may also break OpenBSD. >> >> So addressing only makes sense for GPIO, out of the nodes we have so far >> - that's the only thing with two discrete instances whose access can be >> entirely described by a single base key name, and which are otherwise >> compatible. >> >> Everything else is pretty much single-instance, and talks to multiple >> keys, so there isn't one single "address" key that would make semantic >> sense to use as the node address. > > Unit-addresses are just the first address in 'reg'. So multiple > addresses or not doesn't really matter. Okay, but we're obviously not going to list every single SMC key used by any given node in the device tree (that'd be a giant mess, other than for hwmon which is a story for another time), and it doesn't make sense to pick an arbitrary one as the reg address and then ignore it in the driver. >> There are some indexed keys, but at a >> deeper level (e.g. multiple battery cells part of the charge control >> subsystem, multiple Type C ports as part of the AC/power input >> subsystem, etc.). And in those cases, these subdevices are mostly >> homogeneous and we would never need multiple nodes for them at the DT >> level, they'd just be implicitly handled by those drivers. > > Type-C will be fun depending on how much of the muxing/altmode > details have to get exposed. As sven mentioned that will be fun, but thankfully not part of this binding (SMC only cares for power supply purposes, and since our direct driver already exposes power config info in Linux (or should, and we can improve that), I don't particularly have plans to expose the SMC Type-C data other than perhaps something in the existing power supply driver to indicate which port is the currently chosen power input. > If only those 2 nodes, then I really don't care so much and gpio-sec > would be fine. It's 1 node in 1 binding. I think it might make sense to just go with this then. If Apple ever introduces yet another GPIO sub-controller we can just add another one, and honestly I don't think that's very likely, given they don't even use any of the GPIOs from the second one from the AP yet. I don't see SMC growing a big list of GPIO controllers any time soon, such that we regret doing it this way. And then the node-name can just map to a given key prefix statically in the driver, and thus we don't even need a property for that (gpio would be gP?? and gpio-sec gp?? right now). - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-06 18:38 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 18:38 UTC (permalink / raw) To: Rob Herring Cc: Russell King (Oracle), Mark Kettenis, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On 07/09/2022 02.35, Rob Herring wrote: > On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: >> On 07/09/2022 01.10, Rob Herring wrote: >>>> So at this point, I think it would make sense if I post a v2 with all >>>> the updates so far (sorry, given the long drawn out discussions on >>>> this, I've lost track of what changes have been made to the code, so >>>> I won't include a detailed change log.) >>> >>> As I said elsewhere, sub-nodes is probably the right choice here. I >>> think they need compatible strings in the child nodes, and addressing >>> has to be sorted out which it seems may also break OpenBSD. >> >> So addressing only makes sense for GPIO, out of the nodes we have so far >> - that's the only thing with two discrete instances whose access can be >> entirely described by a single base key name, and which are otherwise >> compatible. >> >> Everything else is pretty much single-instance, and talks to multiple >> keys, so there isn't one single "address" key that would make semantic >> sense to use as the node address. > > Unit-addresses are just the first address in 'reg'. So multiple > addresses or not doesn't really matter. Okay, but we're obviously not going to list every single SMC key used by any given node in the device tree (that'd be a giant mess, other than for hwmon which is a story for another time), and it doesn't make sense to pick an arbitrary one as the reg address and then ignore it in the driver. >> There are some indexed keys, but at a >> deeper level (e.g. multiple battery cells part of the charge control >> subsystem, multiple Type C ports as part of the AC/power input >> subsystem, etc.). And in those cases, these subdevices are mostly >> homogeneous and we would never need multiple nodes for them at the DT >> level, they'd just be implicitly handled by those drivers. > > Type-C will be fun depending on how much of the muxing/altmode > details have to get exposed. As sven mentioned that will be fun, but thankfully not part of this binding (SMC only cares for power supply purposes, and since our direct driver already exposes power config info in Linux (or should, and we can improve that), I don't particularly have plans to expose the SMC Type-C data other than perhaps something in the existing power supply driver to indicate which port is the currently chosen power input. > If only those 2 nodes, then I really don't care so much and gpio-sec > would be fine. It's 1 node in 1 binding. I think it might make sense to just go with this then. If Apple ever introduces yet another GPIO sub-controller we can just add another one, and honestly I don't think that's very likely, given they don't even use any of the GPIOs from the second one from the AP yet. I don't see SMC growing a big list of GPIO controllers any time soon, such that we regret doing it this way. And then the node-name can just map to a given key prefix statically in the driver, and thus we don't even need a property for that (gpio would be gP?? and gpio-sec gp?? right now). - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-06 18:38 ` Hector Martin @ 2022-09-07 9:39 ` Mark Kettenis -1 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-07 9:39 UTC (permalink / raw) To: Hector Martin Cc: robh, linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Wed, 7 Sep 2022 03:38:09 +0900 > From: Hector Martin <marcan@marcan.st> > > On 07/09/2022 02.35, Rob Herring wrote: > > > If only those 2 nodes, then I really don't care so much and gpio-sec > > would be fine. It's 1 node in 1 binding. > > I think it might make sense to just go with this then. If Apple ever > introduces yet another GPIO sub-controller we can just add another one, > and honestly I don't think that's very likely, given they don't even use > any of the GPIOs from the second one from the AP yet. I don't see SMC > growing a big list of GPIO controllers any time soon, such that we > regret doing it this way. And then the node-name can just map to a given > key prefix statically in the driver, and thus we don't even need a > property for that (gpio would be gP?? and gpio-sec gp?? right now). We could also use a compatible property to map the key prefix. For example we could have "apple,smc-gpio-primary" map to gP?? and "apple,smc-gpio-secondary" map to gp??. Then we can keep the generic "gpio" name for both GPIO nodes. And if Apple introduces yet another GPIO sub-controller we just have to invent a new compatible for it. Probably the cleanest solution if Rob still thinks it is better for these nodes to have a compatible property anyway. ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-07 9:39 ` Mark Kettenis 0 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-07 9:39 UTC (permalink / raw) To: Hector Martin Cc: robh, linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > Date: Wed, 7 Sep 2022 03:38:09 +0900 > From: Hector Martin <marcan@marcan.st> > > On 07/09/2022 02.35, Rob Herring wrote: > > > If only those 2 nodes, then I really don't care so much and gpio-sec > > would be fine. It's 1 node in 1 binding. > > I think it might make sense to just go with this then. If Apple ever > introduces yet another GPIO sub-controller we can just add another one, > and honestly I don't think that's very likely, given they don't even use > any of the GPIOs from the second one from the AP yet. I don't see SMC > growing a big list of GPIO controllers any time soon, such that we > regret doing it this way. And then the node-name can just map to a given > key prefix statically in the driver, and thus we don't even need a > property for that (gpio would be gP?? and gpio-sec gp?? right now). We could also use a compatible property to map the key prefix. For example we could have "apple,smc-gpio-primary" map to gP?? and "apple,smc-gpio-secondary" map to gp??. Then we can keep the generic "gpio" name for both GPIO nodes. And if Apple introduces yet another GPIO sub-controller we just have to invent a new compatible for it. Probably the cleanest solution if Rob still thinks it is better for these nodes to have a compatible property anyway. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 15:56 ` Russell King (Oracle) @ 2022-09-01 22:26 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-01 22:26 UTC (permalink / raw) To: Russell King (Oracle) Cc: Krzysztof Kozlowski, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter, Krzysztof Kozlowski, devicetree On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > > >>>>> + compatible: > > >>>>> + items: > > >>>>> + - enum: > > >>>>> + - apple,t8103-smc > > >>>> > > >>>> You miss two spaces of indentation on this level. > > >>> > > >>> Should that be picked up by the dt checker? I have a problem that Krzysztof is quicker. ;) Maybe I should stop screening the emails (for the times I break things mostly). > > >> > > >> I think yamllint complains about it. It is not a hard-dependency, so > > >> maybe you don't have it installed. > > >> > > >>> > > >>>>> + - apple,t8112-smc > > >>>>> + - apple,t6000-smc > > >>>> > > >>>> Bring some order here - either alphabetical or by date of release (as in > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > > >>>> that orders. > > >>> > > >>> Ok. > > >>> > > >>>>> + - const: apple,smc > > >>>>> + > > >>>>> + reg: > > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > > >>>> > > >>>> You need constraints for size/order, so in this context list with > > >>>> described items. > > >>> > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > >>> objected to it. > > >> > > >> One way: > > >> reg: > > >> items: > > >> - description: SMC area > > >> - description: SRAM area > > >> > > >> but actually this is very similar what you wrote for reg-names - kind of > > >> obvious, so easier way: > > >> > > >> reg: > > >> maxItems: 2 > > > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > > ints. > > > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > > the dt checker. > > > > > > With the two descriptions, it's the same failure. > > > > Yeah, they should create same result. > > > > > > > > I think the problem is that the checker has no knowledge in the example > > > of how big each address and size element of the reg property is. So, > > > it's interpreting it as four entries of 32-bit address,size pairs > > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > > if I increase the number of "- description" entries to four then it's > > > happy. > > > > > > So, what's the solution? > > > > > > > If you open generated DTS examples (in your > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > > address/size cells are expected. By default it is I think address/size > > cells=1, so you need a bus node setting it to 2. > > Thanks, that works. The patch with all those points addressed now looks > like: > > 8<=== > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > Controller > > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ > 1 file changed, 61 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > new file mode 100644 > index 000000000000..168f237c2962 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > @@ -0,0 +1,61 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller implements various functions > + such as GPIO, RTC, power, reboot. > + > +properties: > + compatible: > + items: > + - enum: > + - apple,t6000-smc > + - apple,t8103-smc > + - apple,t8112-smc > + - const: apple,smc > + > + reg: > + items: > + - description: SMC area > + - description: SRAM area Based on the disjoint addresses, is this really one device? Perhaps the SRAM area should use mmio-sram binding? That already supports sub-dividing the sram for different uses. I'll comment more on the full example. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 22:26 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-01 22:26 UTC (permalink / raw) To: Russell King (Oracle) Cc: Krzysztof Kozlowski, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter, Krzysztof Kozlowski, devicetree On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > > >>>>> + compatible: > > >>>>> + items: > > >>>>> + - enum: > > >>>>> + - apple,t8103-smc > > >>>> > > >>>> You miss two spaces of indentation on this level. > > >>> > > >>> Should that be picked up by the dt checker? I have a problem that Krzysztof is quicker. ;) Maybe I should stop screening the emails (for the times I break things mostly). > > >> > > >> I think yamllint complains about it. It is not a hard-dependency, so > > >> maybe you don't have it installed. > > >> > > >>> > > >>>>> + - apple,t8112-smc > > >>>>> + - apple,t6000-smc > > >>>> > > >>>> Bring some order here - either alphabetical or by date of release (as in > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > > >>>> that orders. > > >>> > > >>> Ok. > > >>> > > >>>>> + - const: apple,smc > > >>>>> + > > >>>>> + reg: > > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > > >>>> > > >>>> You need constraints for size/order, so in this context list with > > >>>> described items. > > >>> > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > >>> objected to it. > > >> > > >> One way: > > >> reg: > > >> items: > > >> - description: SMC area > > >> - description: SRAM area > > >> > > >> but actually this is very similar what you wrote for reg-names - kind of > > >> obvious, so easier way: > > >> > > >> reg: > > >> maxItems: 2 > > > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > > ints. > > > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > > the dt checker. > > > > > > With the two descriptions, it's the same failure. > > > > Yeah, they should create same result. > > > > > > > > I think the problem is that the checker has no knowledge in the example > > > of how big each address and size element of the reg property is. So, > > > it's interpreting it as four entries of 32-bit address,size pairs > > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > > if I increase the number of "- description" entries to four then it's > > > happy. > > > > > > So, what's the solution? > > > > > > > If you open generated DTS examples (in your > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > > address/size cells are expected. By default it is I think address/size > > cells=1, so you need a bus node setting it to 2. > > Thanks, that works. The patch with all those points addressed now looks > like: > > 8<=== > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > Controller > > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ > 1 file changed, 61 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > new file mode 100644 > index 000000000000..168f237c2962 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > @@ -0,0 +1,61 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller implements various functions > + such as GPIO, RTC, power, reboot. > + > +properties: > + compatible: > + items: > + - enum: > + - apple,t6000-smc > + - apple,t8103-smc > + - apple,t8112-smc > + - const: apple,smc > + > + reg: > + items: > + - description: SMC area > + - description: SRAM area Based on the disjoint addresses, is this really one device? Perhaps the SRAM area should use mmio-sram binding? That already supports sub-dividing the sram for different uses. I'll comment more on the full example. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 22:26 ` Rob Herring @ 2022-09-02 14:49 ` Mark Kettenis -1 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-02 14:49 UTC (permalink / raw) To: Rob Herring Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > From: Rob Herring <robh+dt@kernel.org> > Date: Thu, 1 Sep 2022 17:26:18 -0500 > > On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > > > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > > > >>>>> + compatible: > > > >>>>> + items: > > > >>>>> + - enum: > > > >>>>> + - apple,t8103-smc > > > >>>> > > > >>>> You miss two spaces of indentation on this level. > > > >>> > > > >>> Should that be picked up by the dt checker? > > I have a problem that Krzysztof is quicker. ;) Maybe I should stop > screening the emails (for the times I break things mostly). > > > > >> > > > >> I think yamllint complains about it. It is not a hard-dependency, so > > > >> maybe you don't have it installed. > > > >> > > > >>> > > > >>>>> + - apple,t8112-smc > > > >>>>> + - apple,t6000-smc > > > >>>> > > > >>>> Bring some order here - either alphabetical or by date of release (as in > > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > > > >>>> that orders. > > > >>> > > > >>> Ok. > > > >>> > > > >>>>> + - const: apple,smc > > > >>>>> + > > > >>>>> + reg: > > > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > > > >>>> > > > >>>> You need constraints for size/order, so in this context list with > > > >>>> described items. > > > >>> > > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > > >>> objected to it. > > > >> > > > >> One way: > > > >> reg: > > > >> items: > > > >> - description: SMC area > > > >> - description: SRAM area > > > >> > > > >> but actually this is very similar what you wrote for reg-names - kind of > > > >> obvious, so easier way: > > > >> > > > >> reg: > > > >> maxItems: 2 > > > > > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > > > ints. > > > > > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > > > the dt checker. > > > > > > > > With the two descriptions, it's the same failure. > > > > > > Yeah, they should create same result. > > > > > > > > > > > I think the problem is that the checker has no knowledge in the example > > > > of how big each address and size element of the reg property is. So, > > > > it's interpreting it as four entries of 32-bit address,size pairs > > > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > > > if I increase the number of "- description" entries to four then it's > > > > happy. > > > > > > > > So, what's the solution? > > > > > > > > > > If you open generated DTS examples (in your > > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > > > address/size cells are expected. By default it is I think address/size > > > cells=1, so you need a bus node setting it to 2. > > > > Thanks, that works. The patch with all those points addressed now looks > > like: > > > > 8<=== > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > Controller > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > new file mode 100644 > > index 000000000000..168f237c2962 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > @@ -0,0 +1,61 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Apple Mac System Management Controller > > + > > +maintainers: > > + - Hector Martin <marcan@marcan.st> > > + > > +description: > > + Apple Mac System Management Controller implements various functions > > + such as GPIO, RTC, power, reboot. > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - apple,t6000-smc > > + - apple,t8103-smc > > + - apple,t8112-smc > > + - const: apple,smc > > + > > + reg: > > + items: > > + - description: SMC area > > + - description: SRAM area > > Based on the disjoint addresses, is this really one device? Perhaps > the SRAM area should use mmio-sram binding? That already supports > sub-dividing the sram for different uses. I'll comment more on the > full example. To me it does look as if the SRAM is part of the SMC coprocessor block. It is probably part of a larger SRAM on the side of the SMC coprocessor. There is a gap, but the addresses are close. The only thing in between is the SMC mailbox, which is represented by a separate node. The address of the SRAM can be discovered by sending SMC commands. I believe Hector added it in order to verify the address that the SMC firmware provides. My OpenBSD driver doesn't use it, so in that sense changing the binding to use a separate node with a "mmio-sram" compatible (and presumably an "apple,sram" property to reference that node using a phandle) would work fine. The extra level of indirection obviously would mean more code in the Linux SMC driver though. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-02 14:49 ` Mark Kettenis 0 siblings, 0 replies; 342+ messages in thread From: Mark Kettenis @ 2022-09-02 14:49 UTC (permalink / raw) To: Rob Herring Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree > From: Rob Herring <robh+dt@kernel.org> > Date: Thu, 1 Sep 2022 17:26:18 -0500 > > On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > > > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > > > >>>>> + compatible: > > > >>>>> + items: > > > >>>>> + - enum: > > > >>>>> + - apple,t8103-smc > > > >>>> > > > >>>> You miss two spaces of indentation on this level. > > > >>> > > > >>> Should that be picked up by the dt checker? > > I have a problem that Krzysztof is quicker. ;) Maybe I should stop > screening the emails (for the times I break things mostly). > > > > >> > > > >> I think yamllint complains about it. It is not a hard-dependency, so > > > >> maybe you don't have it installed. > > > >> > > > >>> > > > >>>>> + - apple,t8112-smc > > > >>>>> + - apple,t6000-smc > > > >>>> > > > >>>> Bring some order here - either alphabetical or by date of release (as in > > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > > > >>>> that orders. > > > >>> > > > >>> Ok. > > > >>> > > > >>>>> + - const: apple,smc > > > >>>>> + > > > >>>>> + reg: > > > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > > > >>>> > > > >>>> You need constraints for size/order, so in this context list with > > > >>>> described items. > > > >>> > > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > > >>> objected to it. > > > >> > > > >> One way: > > > >> reg: > > > >> items: > > > >> - description: SMC area > > > >> - description: SRAM area > > > >> > > > >> but actually this is very similar what you wrote for reg-names - kind of > > > >> obvious, so easier way: > > > >> > > > >> reg: > > > >> maxItems: 2 > > > > > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > > > ints. > > > > > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > > > the dt checker. > > > > > > > > With the two descriptions, it's the same failure. > > > > > > Yeah, they should create same result. > > > > > > > > > > > I think the problem is that the checker has no knowledge in the example > > > > of how big each address and size element of the reg property is. So, > > > > it's interpreting it as four entries of 32-bit address,size pairs > > > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > > > if I increase the number of "- description" entries to four then it's > > > > happy. > > > > > > > > So, what's the solution? > > > > > > > > > > If you open generated DTS examples (in your > > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > > > address/size cells are expected. By default it is I think address/size > > > cells=1, so you need a bus node setting it to 2. > > > > Thanks, that works. The patch with all those points addressed now looks > > like: > > > > 8<=== > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > Controller > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ > > 1 file changed, 61 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > new file mode 100644 > > index 000000000000..168f237c2962 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > @@ -0,0 +1,61 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Apple Mac System Management Controller > > + > > +maintainers: > > + - Hector Martin <marcan@marcan.st> > > + > > +description: > > + Apple Mac System Management Controller implements various functions > > + such as GPIO, RTC, power, reboot. > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - apple,t6000-smc > > + - apple,t8103-smc > > + - apple,t8112-smc > > + - const: apple,smc > > + > > + reg: > > + items: > > + - description: SMC area > > + - description: SRAM area > > Based on the disjoint addresses, is this really one device? Perhaps > the SRAM area should use mmio-sram binding? That already supports > sub-dividing the sram for different uses. I'll comment more on the > full example. To me it does look as if the SRAM is part of the SMC coprocessor block. It is probably part of a larger SRAM on the side of the SMC coprocessor. There is a gap, but the addresses are close. The only thing in between is the SMC mailbox, which is represented by a separate node. The address of the SRAM can be discovered by sending SMC commands. I believe Hector added it in order to verify the address that the SMC firmware provides. My OpenBSD driver doesn't use it, so in that sense changing the binding to use a separate node with a "mmio-sram" compatible (and presumably an "apple,sram" property to reference that node using a phandle) would work fine. The extra level of indirection obviously would mean more code in the Linux SMC driver though. ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-02 14:49 ` Mark Kettenis @ 2022-09-02 17:04 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-02 17:04 UTC (permalink / raw) To: Mark Kettenis Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 04:49:37PM +0200, Mark Kettenis wrote: > > From: Rob Herring <robh+dt@kernel.org> > > Date: Thu, 1 Sep 2022 17:26:18 -0500 > > > > On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > > > > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > > > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > > > > >>>>> + compatible: > > > > >>>>> + items: > > > > >>>>> + - enum: > > > > >>>>> + - apple,t8103-smc > > > > >>>> > > > > >>>> You miss two spaces of indentation on this level. > > > > >>> > > > > >>> Should that be picked up by the dt checker? > > > > I have a problem that Krzysztof is quicker. ;) Maybe I should stop > > screening the emails (for the times I break things mostly). > > > > > > >> > > > > >> I think yamllint complains about it. It is not a hard-dependency, so > > > > >> maybe you don't have it installed. > > > > >> > > > > >>> > > > > >>>>> + - apple,t8112-smc > > > > >>>>> + - apple,t6000-smc > > > > >>>> > > > > >>>> Bring some order here - either alphabetical or by date of release (as in > > > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > > > > >>>> that orders. > > > > >>> > > > > >>> Ok. > > > > >>> > > > > >>>>> + - const: apple,smc > > > > >>>>> + > > > > >>>>> + reg: > > > > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > > > > >>>> > > > > >>>> You need constraints for size/order, so in this context list with > > > > >>>> described items. > > > > >>> > > > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > > > >>> objected to it. > > > > >> > > > > >> One way: > > > > >> reg: > > > > >> items: > > > > >> - description: SMC area > > > > >> - description: SRAM area > > > > >> > > > > >> but actually this is very similar what you wrote for reg-names - kind of > > > > >> obvious, so easier way: > > > > >> > > > > >> reg: > > > > >> maxItems: 2 > > > > > > > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > > > > ints. > > > > > > > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > > > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > > > > the dt checker. > > > > > > > > > > With the two descriptions, it's the same failure. > > > > > > > > Yeah, they should create same result. > > > > > > > > > > > > > > I think the problem is that the checker has no knowledge in the example > > > > > of how big each address and size element of the reg property is. So, > > > > > it's interpreting it as four entries of 32-bit address,size pairs > > > > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > > > > if I increase the number of "- description" entries to four then it's > > > > > happy. > > > > > > > > > > So, what's the solution? > > > > > > > > > > > > > If you open generated DTS examples (in your > > > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > > > > address/size cells are expected. By default it is I think address/size > > > > cells=1, so you need a bus node setting it to 2. > > > > > > Thanks, that works. The patch with all those points addressed now looks > > > like: > > > > > > 8<=== > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > Controller > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > --- > > > .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ > > > 1 file changed, 61 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > new file mode 100644 > > > index 000000000000..168f237c2962 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > @@ -0,0 +1,61 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Apple Mac System Management Controller > > > + > > > +maintainers: > > > + - Hector Martin <marcan@marcan.st> > > > + > > > +description: > > > + Apple Mac System Management Controller implements various functions > > > + such as GPIO, RTC, power, reboot. > > > + > > > +properties: > > > + compatible: > > > + items: > > > + - enum: > > > + - apple,t6000-smc > > > + - apple,t8103-smc > > > + - apple,t8112-smc > > > + - const: apple,smc > > > + > > > + reg: > > > + items: > > > + - description: SMC area > > > + - description: SRAM area > > > > Based on the disjoint addresses, is this really one device? Perhaps > > the SRAM area should use mmio-sram binding? That already supports > > sub-dividing the sram for different uses. I'll comment more on the > > full example. > > To me it does look as if the SRAM is part of the SMC coprocessor > block. It is probably part of a larger SRAM on the side of the SMC > coprocessor. There is a gap, but the addresses are close. The only > thing in between is the SMC mailbox, which is represented by a > separate node. Okay, fair enough. Let's keep them together. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-02 17:04 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-02 17:04 UTC (permalink / raw) To: Mark Kettenis Cc: linux, krzysztof.kozlowski, arnd, lee, linus.walleij, alyssa, asahi, brgl, marcan, linux-arm-kernel, linux-gpio, sven, krzysztof.kozlowski+dt, devicetree On Fri, Sep 02, 2022 at 04:49:37PM +0200, Mark Kettenis wrote: > > From: Rob Herring <robh+dt@kernel.org> > > Date: Thu, 1 Sep 2022 17:26:18 -0500 > > > > On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote: > > > > On 01/09/2022 18:24, Russell King (Oracle) wrote: > > > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote: > > > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote: > > > > >>>>> + compatible: > > > > >>>>> + items: > > > > >>>>> + - enum: > > > > >>>>> + - apple,t8103-smc > > > > >>>> > > > > >>>> You miss two spaces of indentation on this level. > > > > >>> > > > > >>> Should that be picked up by the dt checker? > > > > I have a problem that Krzysztof is quicker. ;) Maybe I should stop > > screening the emails (for the times I break things mostly). > > > > > > >> > > > > >> I think yamllint complains about it. It is not a hard-dependency, so > > > > >> maybe you don't have it installed. > > > > >> > > > > >>> > > > > >>>>> + - apple,t8112-smc > > > > >>>>> + - apple,t6000-smc > > > > >>>> > > > > >>>> Bring some order here - either alphabetical or by date of release (as in > > > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of > > > > >>>> that orders. > > > > >>> > > > > >>> Ok. > > > > >>> > > > > >>>>> + - const: apple,smc > > > > >>>>> + > > > > >>>>> + reg: > > > > >>>>> + description: Two regions, one for the SMC area and one for the SRAM area. > > > > >>>> > > > > >>>> You need constraints for size/order, so in this context list with > > > > >>>> described items. > > > > >>> > > > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker > > > > >>> objected to it. > > > > >> > > > > >> One way: > > > > >> reg: > > > > >> items: > > > > >> - description: SMC area > > > > >> - description: SRAM area > > > > >> > > > > >> but actually this is very similar what you wrote for reg-names - kind of > > > > >> obvious, so easier way: > > > > >> > > > > >> reg: > > > > >> maxItems: 2 > > > > > > > > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists > > > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit > > > > > ints. > > > > > > > > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long > > > > > From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > > > Hence, I originally had maxItems: 2, and ended up deleting it because of > > > > > the dt checker. > > > > > > > > > > With the two descriptions, it's the same failure. > > > > > > > > Yeah, they should create same result. > > > > > > > > > > > > > > I think the problem is that the checker has no knowledge in the example > > > > > of how big each address and size element of the reg property is. So, > > > > > it's interpreting it as four entries of 32-bit address,size pairs > > > > > instead of two entries of 64-bit address,size pairs. Yep, that's it, > > > > > if I increase the number of "- description" entries to four then it's > > > > > happy. > > > > > > > > > > So, what's the solution? > > > > > > > > > > > > > If you open generated DTS examples (in your > > > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which > > > > address/size cells are expected. By default it is I think address/size > > > > cells=1, so you need a bus node setting it to 2. > > > > > > Thanks, that works. The patch with all those points addressed now looks > > > like: > > > > > > 8<=== > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> > > > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management > > > Controller > > > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > --- > > > .../devicetree/bindings/mfd/apple,smc.yaml | 61 +++++++++++++++++++ > > > 1 file changed, 61 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > new file mode 100644 > > > index 000000000000..168f237c2962 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > @@ -0,0 +1,61 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Apple Mac System Management Controller > > > + > > > +maintainers: > > > + - Hector Martin <marcan@marcan.st> > > > + > > > +description: > > > + Apple Mac System Management Controller implements various functions > > > + such as GPIO, RTC, power, reboot. > > > + > > > +properties: > > > + compatible: > > > + items: > > > + - enum: > > > + - apple,t6000-smc > > > + - apple,t8103-smc > > > + - apple,t8112-smc > > > + - const: apple,smc > > > + > > > + reg: > > > + items: > > > + - description: SMC area > > > + - description: SRAM area > > > > Based on the disjoint addresses, is this really one device? Perhaps > > the SRAM area should use mmio-sram binding? That already supports > > sub-dividing the sram for different uses. I'll comment more on the > > full example. > > To me it does look as if the SRAM is part of the SMC coprocessor > block. It is probably part of a larger SRAM on the side of the SMC > coprocessor. There is a gap, but the addresses are close. The only > thing in between is the SMC mailbox, which is represented by a > separate node. Okay, fair enough. Let's keep them together. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 19:14 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-01 19:14 UTC (permalink / raw) To: Russell King (Oracle) Cc: linux-arm-kernel, Alyssa Rosenzweig, Arnd Bergmann, Krzysztof Kozlowski, Lee Jones, asahi, devicetree, Sven Peter, Linus Walleij, Hector Martin, Bartosz Golaszewski, linux-gpio, Rob Herring On Thu, 01 Sep 2022 14:54:25 +0100, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 53 +++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/mfd/apple,smc.yaml:20:9: [warning] wrong indentation: expected 10 but found 8 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-09-01 19:14 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-09-01 19:14 UTC (permalink / raw) To: Russell King (Oracle) Cc: linux-arm-kernel, Alyssa Rosenzweig, Arnd Bergmann, Krzysztof Kozlowski, Lee Jones, asahi, devicetree, Sven Peter, Linus Walleij, Hector Martin, Bartosz Golaszewski, linux-gpio, Rob Herring On Thu, 01 Sep 2022 14:54:25 +0100, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 53 +++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/mfd/apple,smc.yaml:20:9: [warning] wrong indentation: expected 10 but found 8 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 13:54 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree Add the DT binding for the Apple Mac System Management Controller GPIOs. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 +++++++++++++++++++ .../devicetree/bindings/mfd/apple,smc.yaml | 4 +++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml diff --git a/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml new file mode 100644 index 000000000000..ee620fe50ca8 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller GPIO + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + This describes the binding for the Apple Mac System Management Controller + GPIO block. + +properties: + gpio-controller: true + '#gpio-cells': + const: 2 + +additionalProperties: false + +examples: + - | + smc_gpio: gpio { + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml index 794d3a6eb04a..bb799a27638d 100644 --- a/Documentation/devicetree/bindings/mfd/apple,smc.yaml +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -34,6 +34,10 @@ title: Apple Mac System Management Controller description: A phandle to the mailbox channel +patternProperties: + gpio: + $ref: /schemas/gpio/gpio-macsmc.yaml + additionalProperties: false required: -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-09-01 13:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree Add the DT binding for the Apple Mac System Management Controller GPIOs. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 +++++++++++++++++++ .../devicetree/bindings/mfd/apple,smc.yaml | 4 +++ 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml diff --git a/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml new file mode 100644 index 000000000000..ee620fe50ca8 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller GPIO + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + This describes the binding for the Apple Mac System Management Controller + GPIO block. + +properties: + gpio-controller: true + '#gpio-cells': + const: 2 + +additionalProperties: false + +examples: + - | + smc_gpio: gpio { + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml index 794d3a6eb04a..bb799a27638d 100644 --- a/Documentation/devicetree/bindings/mfd/apple,smc.yaml +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -34,6 +34,10 @@ title: Apple Mac System Management Controller description: A phandle to the mailbox channel +patternProperties: + gpio: + $ref: /schemas/gpio/gpio-macsmc.yaml + additionalProperties: false required: -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 15:11 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:11 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 16:54, Russell King (Oracle) wrote: > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 +++++++++++++++++++ > .../devicetree/bindings/mfd/apple,smc.yaml | 4 +++ > 2 files changed, 32 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > new file mode 100644 > index 000000000000..ee620fe50ca8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > @@ -0,0 +1,28 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# filename based on the compatible... which is missing here, so this leads to the question - why this is separate device/child node? It won't bind to anything, won't be populated, right? > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller GPIO > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + This describes the binding for the Apple Mac System Management Controller > + GPIO block. > + > +properties: > + gpio-controller: true > + '#gpio-cells': > + const: 2 > + > +additionalProperties: false > + > +examples: > + - | > + smc_gpio: gpio { > + gpio-controller; > + #gpio-cells = <2>; > + }; > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > index 794d3a6eb04a..bb799a27638d 100644 > --- a/Documentation/devicetree/bindings/mfd/apple,smc.yaml > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > @@ -34,6 +34,10 @@ title: Apple Mac System Management Controller > description: > A phandle to the mailbox channel > > +patternProperties: This is not a pattern, so "gpio" goes to "properties:". > + gpio: > + $ref: /schemas/gpio/gpio-macsmc.yaml > + > additionalProperties: false > > required: Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-09-01 15:11 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:11 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On 01/09/2022 16:54, Russell King (Oracle) wrote: > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 +++++++++++++++++++ > .../devicetree/bindings/mfd/apple,smc.yaml | 4 +++ > 2 files changed, 32 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > new file mode 100644 > index 000000000000..ee620fe50ca8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > @@ -0,0 +1,28 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# filename based on the compatible... which is missing here, so this leads to the question - why this is separate device/child node? It won't bind to anything, won't be populated, right? > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller GPIO > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + This describes the binding for the Apple Mac System Management Controller > + GPIO block. > + > +properties: > + gpio-controller: true > + '#gpio-cells': > + const: 2 > + > +additionalProperties: false > + > +examples: > + - | > + smc_gpio: gpio { > + gpio-controller; > + #gpio-cells = <2>; > + }; > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > index 794d3a6eb04a..bb799a27638d 100644 > --- a/Documentation/devicetree/bindings/mfd/apple,smc.yaml > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > @@ -34,6 +34,10 @@ title: Apple Mac System Management Controller > description: > A phandle to the mailbox channel > > +patternProperties: This is not a pattern, so "gpio" goes to "properties:". > + gpio: > + $ref: /schemas/gpio/gpio-macsmc.yaml > + > additionalProperties: false > > required: Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-09-01 15:11 ` Krzysztof Kozlowski @ 2022-09-01 15:14 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:14 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:11:30PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 16:54, Russell King (Oracle) wrote: > > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 +++++++++++++++++++ > > .../devicetree/bindings/mfd/apple,smc.yaml | 4 +++ > > 2 files changed, 32 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > new file mode 100644 > > index 000000000000..ee620fe50ca8 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > @@ -0,0 +1,28 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# > > filename based on the compatible... which is missing here, so this leads > to the question - why this is separate device/child node? It won't bind > to anything, won't be populated, right? The node is a child of the apple,smc mfd device, and is referenced from that description. Should this be embedded in the DT description for the apple,smc device? It'll also have other nodes as well, for the RTC etc. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-09-01 15:14 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-01 15:14 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter, Rob Herring, Krzysztof Kozlowski, devicetree On Thu, Sep 01, 2022 at 06:11:30PM +0300, Krzysztof Kozlowski wrote: > On 01/09/2022 16:54, Russell King (Oracle) wrote: > > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../devicetree/bindings/gpio/gpio-macsmc.yaml | 28 +++++++++++++++++++ > > .../devicetree/bindings/mfd/apple,smc.yaml | 4 +++ > > 2 files changed, 32 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > new file mode 100644 > > index 000000000000..ee620fe50ca8 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/gpio-macsmc.yaml > > @@ -0,0 +1,28 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# > > filename based on the compatible... which is missing here, so this leads > to the question - why this is separate device/child node? It won't bind > to anything, won't be populated, right? The node is a child of the apple,smc mfd device, and is referenced from that description. Should this be embedded in the DT description for the apple,smc device? It'll also have other nodes as well, for the RTC etc. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 13:54 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> This allows a client to receive messages in atomic context, by polling. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/soc/apple/rtkit.c | 6 ++++++ include/linux/soc/apple/rtkit.h | 12 ++++++++++++ 2 files changed, 18 insertions(+) diff --git a/drivers/soc/apple/rtkit.c b/drivers/soc/apple/rtkit.c index cf1129e9f76b..031ec4aa06d5 100644 --- a/drivers/soc/apple/rtkit.c +++ b/drivers/soc/apple/rtkit.c @@ -660,6 +660,12 @@ int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message, } EXPORT_SYMBOL_GPL(apple_rtkit_send_message_wait); +int apple_rtkit_poll(struct apple_rtkit *rtk) +{ + return mbox_client_peek_data(rtk->mbox_chan); +} +EXPORT_SYMBOL_GPL(apple_rtkit_poll); + int apple_rtkit_start_ep(struct apple_rtkit *rtk, u8 endpoint) { u64 msg; diff --git a/include/linux/soc/apple/rtkit.h b/include/linux/soc/apple/rtkit.h index 88eb832eac7b..c9cabb679cd1 100644 --- a/include/linux/soc/apple/rtkit.h +++ b/include/linux/soc/apple/rtkit.h @@ -152,4 +152,16 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message, int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message, unsigned long timeout, bool atomic); +/* + * Process incoming messages in atomic context. + * This only guarantees that messages arrive as far as the recv_message_early + * callback; drivers expecting to handle incoming messages synchronously + * by calling this function must do it that way. + * Will return 1 if some data was processed, 0 if none was, or a + * negative error code on failure. + * + * @rtk: RTKit reference + */ +int apple_rtkit_poll(struct apple_rtkit *rtk); + #endif /* _LINUX_APPLE_RTKIT_H_ */ -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll @ 2022-09-01 13:54 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> This allows a client to receive messages in atomic context, by polling. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/soc/apple/rtkit.c | 6 ++++++ include/linux/soc/apple/rtkit.h | 12 ++++++++++++ 2 files changed, 18 insertions(+) diff --git a/drivers/soc/apple/rtkit.c b/drivers/soc/apple/rtkit.c index cf1129e9f76b..031ec4aa06d5 100644 --- a/drivers/soc/apple/rtkit.c +++ b/drivers/soc/apple/rtkit.c @@ -660,6 +660,12 @@ int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message, } EXPORT_SYMBOL_GPL(apple_rtkit_send_message_wait); +int apple_rtkit_poll(struct apple_rtkit *rtk) +{ + return mbox_client_peek_data(rtk->mbox_chan); +} +EXPORT_SYMBOL_GPL(apple_rtkit_poll); + int apple_rtkit_start_ep(struct apple_rtkit *rtk, u8 endpoint) { u64 msg; diff --git a/include/linux/soc/apple/rtkit.h b/include/linux/soc/apple/rtkit.h index 88eb832eac7b..c9cabb679cd1 100644 --- a/include/linux/soc/apple/rtkit.h +++ b/include/linux/soc/apple/rtkit.h @@ -152,4 +152,16 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message, int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message, unsigned long timeout, bool atomic); +/* + * Process incoming messages in atomic context. + * This only guarantees that messages arrive as far as the recv_message_early + * callback; drivers expecting to handle incoming messages synchronously + * by calling this function must do it that way. + * Will return 1 if some data was processed, 0 if none was, or a + * negative error code on failure. + * + * @rtk: RTKit reference + */ +int apple_rtkit_poll(struct apple_rtkit *rtk); + #endif /* _LINUX_APPLE_RTKIT_H_ */ -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll 2022-09-01 13:54 ` Russell King @ 2022-09-01 17:00 ` Sven Peter -1 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-01 17:00 UTC (permalink / raw) To: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM On Thu, Sep 1, 2022, at 15:54, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This allows a client to receive messages in atomic context, by polling. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Sven Peter <sven@svenpeter.dev> ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll @ 2022-09-01 17:00 ` Sven Peter 0 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-01 17:00 UTC (permalink / raw) To: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM On Thu, Sep 1, 2022, at 15:54, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This allows a client to receive messages in atomic context, by polling. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Sven Peter <sven@svenpeter.dev> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll 2022-09-01 13:54 ` Russell King @ 2022-09-01 17:25 ` Eric Curtin -1 siblings, 0 replies; 342+ messages in thread From: Eric Curtin @ 2022-09-01 17:25 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 1 Sept 2022 at 15:03, Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > This allows a client to receive messages in atomic context, by polling. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Eric Curtin <ecurtin@redhat.com> ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll @ 2022-09-01 17:25 ` Eric Curtin 0 siblings, 0 replies; 342+ messages in thread From: Eric Curtin @ 2022-09-01 17:25 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 1 Sept 2022 at 15:03, Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > This allows a client to receive messages in atomic context, by polling. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Eric Curtin <ecurtin@redhat.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 13:54 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements support for the SMC (System Management Controller) in Apple Macs. In contrast to the existing applesmc driver, it uses pluggable backends that allow it to support different SMC implementations, and uses the MFD subsystem to expose the core SMC functionality so that specific features (gpio, hwmon, battery, etc.) can be implemented by separate drivers in their respective downstream subsystems. The initial RTKit backend adds support for Apple Silicon Macs (M1 et al). We hope a backend for T2 Macs will be written in the future (since those are not supported by applesmc), and eventually an x86 backend would allow us to fully deprecate applesmc in favor of this driver. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 49 ++++ drivers/platform/apple/Makefile | 11 + drivers/platform/apple/smc.h | 28 ++ drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ include/linux/mfd/macsmc.h | 86 ++++++ 8 files changed, 877 insertions(+) create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/smc.h create mode 100644 drivers/platform/apple/smc_core.c create mode 100644 drivers/platform/apple/smc_rtkit.c create mode 100644 include/linux/mfd/macsmc.h diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index b437847b6237..5f8b9bcdb830 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" source "drivers/platform/surface/Kconfig" +source "drivers/platform/apple/Kconfig" + source "drivers/platform/x86/Kconfig" diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 4de08ef4ec9d..3e5d5039a28c 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig new file mode 100644 index 000000000000..42525aa9fbbe --- /dev/null +++ b/drivers/platform/apple/Kconfig @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Apple Platform-Specific Drivers +# + +menuconfig APPLE_PLATFORMS + bool "Apple Mac Platform-Specific Device Drivers" + default y + help + Say Y here to get to see options for platform-specific device drivers + for Apple devices. This option alone does not add any kernel code. + + If you say N, all options in this submenu will be skipped and disabled. + +if APPLE_PLATFORMS + +config APPLE_SMC + tristate "Apple SMC Driver" + depends on ARCH_APPLE || COMPILE_TEST + default ARCH_APPLE + select MFD_CORE + help + Build support for the Apple System Management Controller present in + Apple Macs. This driver currently supports the SMC in Apple Silicon + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). + + Say Y here if you have an Apple Silicon Mac. + + To compile this driver as a module, choose M here: the module will + be called macsmc. + +if APPLE_SMC + +config APPLE_SMC_RTKIT + tristate "RTKit (Apple Silicon) backend" + depends on ARCH_APPLE || COMPILE_TEST + depends on APPLE_RTKIT + default ARCH_APPLE + help + Build support for SMC communications via the RTKit backend. This is + required for Apple Silicon Macs. + + Say Y here if you have an Apple Silicon Mac. + + To compile this driver as a module, choose M here: the module will + be called macsmc-rtkit. + +endif +endif diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile new file mode 100644 index 000000000000..79fac195398b --- /dev/null +++ b/drivers/platform/apple/Makefile @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for linux/drivers/platform/apple +# Apple Platform-Specific Drivers +# + +macsmc-y += smc_core.o +macsmc-rtkit-y += smc_rtkit.o + +obj-$(CONFIG_APPLE_SMC) += macsmc.o +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h new file mode 100644 index 000000000000..8ae51887b2c5 --- /dev/null +++ b/drivers/platform/apple/smc.h @@ -0,0 +1,28 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC internal core definitions + * Copyright (C) The Asahi Linux Contributors + */ + +#ifndef _SMC_H +#define _SMC_H + +#include <linux/mfd/macsmc.h> + +struct apple_smc_backend_ops { + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + int (*get_key_by_index)(void *cookie, int index, smc_key *key); + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); +}; + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, + void *cookie); +void *apple_smc_get_cookie(struct apple_smc *smc); +int apple_smc_remove(struct apple_smc *smc); +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); + +#endif diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c new file mode 100644 index 000000000000..daf029cd072f --- /dev/null +++ b/drivers/platform/apple/smc_core.c @@ -0,0 +1,249 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core framework + * Copyright The Asahi Linux Contributors + */ + +#include <linux/device.h> +#include <linux/mfd/core.h> +#include <linux/mutex.h> +#include <linux/notifier.h> +#include "smc.h" + +struct apple_smc { + struct device *dev; + + void *be_cookie; + const struct apple_smc_backend_ops *be; + + struct mutex mutex; + + u32 key_count; + smc_key first_key; + smc_key last_key; + + struct blocking_notifier_head event_handlers; +}; + +static const struct mfd_cell apple_smc_devs[] = { + { + .name = "macsmc-gpio", + }, + { + .name = "macsmc-hid", + }, + { + .name = "macsmc-power", + }, + { + .name = "macsmc-reboot", + }, + { + .name = "macsmc-rtc", + }, +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->read_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_read); + +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->write_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write); + +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + /* + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff + * final calls, so it doesn't really matter at that point. + */ + if (!mutex_trylock(&smc->mutex)) + return -EBUSY; + + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write_atomic); + +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_rw); + +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_by_index); + +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_info(smc->be_cookie, key, info); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_info); + +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) +{ + int start = 0, count = smc->key_count; + int ret; + + if (key <= smc->first_key) + return 0; + if (key > smc->last_key) + return smc->key_count; + + while (count > 1) { + int pivot = start + ((count - 1) >> 1); + smc_key pkey; + + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); + if (ret < 0) + return ret; + + if (pkey == key) + return pivot; + + pivot++; + + if (pkey < key) { + count -= pivot - start; + start = pivot; + } else { + count = pivot - start; + } + } + + return start; +} +EXPORT_SYMBOL(apple_smc_find_first_key_index); + +int apple_smc_get_key_count(struct apple_smc *smc) +{ + return smc->key_count; +} +EXPORT_SYMBOL(apple_smc_get_key_count); + +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) +{ + dev_dbg(smc->dev, "Event: 0x%08x\n", event); + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); +} +EXPORT_SYMBOL(apple_smc_event_received); + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_register(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_register_notifier); + +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_unregister(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_unregister_notifier); + +void *apple_smc_get_cookie(struct apple_smc *smc) +{ + return smc->be_cookie; +} +EXPORT_SYMBOL(apple_smc_get_cookie); + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) +{ + struct apple_smc *smc; + u32 count; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return ERR_PTR(-ENOMEM); + + smc->dev = dev; + smc->be_cookie = cookie; + smc->be = ops; + mutex_init(&smc->mutex); + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); + + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); + smc->key_count = be32_to_cpu(count); + + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); + + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, &smc->last_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); + + /* Enable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", + smc->key_count, &smc->first_key, &smc->last_key); + + dev_set_drvdata(dev, smc); + + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); + + return smc; +} +EXPORT_SYMBOL(apple_smc_probe); + +int apple_smc_remove(struct apple_smc *smc) +{ + mfd_remove_devices(smc->dev); + + /* Disable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + return 0; +} +EXPORT_SYMBOL(apple_smc_remove); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC core"); diff --git a/drivers/platform/apple/smc_rtkit.c b/drivers/platform/apple/smc_rtkit.c new file mode 100644 index 000000000000..5b7c4c475bbb --- /dev/null +++ b/drivers/platform/apple/smc_rtkit.c @@ -0,0 +1,451 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC RTKit backend + * Copyright The Asahi Linux Contributors + */ + +#include <asm/unaligned.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/io.h> +#include <linux/ioport.h> +#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/soc/apple/rtkit.h> +#include "smc.h" + +#define SMC_ENDPOINT 0x20 + +/* Guess */ +#define SMC_SHMEM_SIZE 0x1000 + +#define SMC_MSG_READ_KEY 0x10 +#define SMC_MSG_WRITE_KEY 0x11 +#define SMC_MSG_GET_KEY_BY_INDEX 0x12 +#define SMC_MSG_GET_KEY_INFO 0x13 +#define SMC_MSG_INITIALIZE 0x17 +#define SMC_MSG_NOTIFICATION 0x18 +#define SMC_MSG_RW_KEY 0x20 + +#define SMC_DATA GENMASK(63, 32) +#define SMC_WSIZE GENMASK(31, 24) +#define SMC_SIZE GENMASK(23, 16) +#define SMC_ID GENMASK(15, 12) +#define SMC_MSG GENMASK(7, 0) +#define SMC_RESULT SMC_MSG + +#define SMC_RECV_TIMEOUT 100 + +struct apple_smc_rtkit { + struct device *dev; + struct apple_smc *core; + struct apple_rtkit *rtk; + + struct completion init_done; + bool initialized; + bool alive; + + struct resource *sram; + void __iomem *sram_base; + struct apple_rtkit_shmem shmem; + + unsigned int msg_id; + + bool atomic_pending; + struct completion cmd_done; + u64 cmd_ret; +}; + +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + u64 msg; + u8 result; + + if (size > SMC_SHMEM_SIZE || size == 0) + return -EINVAL; + + if (!smc->alive) + return -EIO; + + memcpy_toio(smc->shmem.iomem, buf, size); + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, key)); + smc->atomic_pending = true; + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, true); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command (%d)\n", ret); + return ret; + } + + while (smc->atomic_pending) { + ret = apple_rtkit_poll(smc->rtk); + if (ret < 0) { + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); + return ret; + } + udelay(100); + } + + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + return -EIO; + } + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int apple_smc_cmd(struct apple_smc_rtkit *smc, u64 cmd, u64 arg, + u64 size, u64 wsize, u32 *ret_data) +{ + int ret; + u64 msg; + u8 result; + + if (!smc->alive) + return -EIO; + + reinit_completion(&smc->cmd_done); + + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, cmd) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_WSIZE, wsize) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, arg)); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, false); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command\n"); + return ret; + } + + do { + if (wait_for_completion_timeout(&smc->cmd_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + dev_err(smc->dev, "Command timed out (%llx)", msg); + return -ETIMEDOUT; + } + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) + break; + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + } while(1); + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + if (ret_data) + *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int _apple_smc_rtkit_read_key(struct apple_smc_rtkit *smc, smc_key key, + void *buf, size_t size, size_t wsize) +{ + int ret; + u32 rdata; + u64 cmd; + + if (size > SMC_SHMEM_SIZE || size == 0) + return -EINVAL; + + cmd = wsize ? SMC_MSG_RW_KEY : SMC_MSG_READ_KEY; + + ret = apple_smc_cmd(smc, cmd, key, size, wsize, &rdata); + if (ret < 0) + return ret; + + if (size <= 4) + memcpy(buf, &rdata, size); + else + memcpy_fromio(buf, smc->shmem.iomem, size); + + return ret; +} + +static int apple_smc_rtkit_read_key(void *cookie, smc_key key, void *buf, size_t size) +{ + return _apple_smc_rtkit_read_key(cookie, key, buf, size, 0); +} + +static int apple_smc_rtkit_write_key(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + + if (size > SMC_SHMEM_SIZE || size == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, buf, size); + return apple_smc_cmd(smc, SMC_MSG_WRITE_KEY, key, size, 0, NULL); +} + +static int apple_smc_rtkit_rw_key(void *cookie, smc_key key, + void *wbuf, size_t wsize, void *rbuf, size_t rsize) +{ + struct apple_smc_rtkit *smc = cookie; + + if (wsize > SMC_SHMEM_SIZE || wsize == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, wbuf, wsize); + return _apple_smc_rtkit_read_key(smc, key, rbuf, rsize, wsize); +} + +static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, smc_key *key) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); + + *key = swab32(*key); + return ret; +} + +static int apple_smc_rtkit_get_key_info(void *cookie, smc_key key, struct apple_smc_key_info *info) +{ + struct apple_smc_rtkit *smc = cookie; + u8 key_info[6]; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_INFO, key, 0, 0, NULL); + if (ret >= 0 && info) { + info->size = key_info[0]; + info->type_code = get_unaligned_be32(&key_info[1]); + info->flags = key_info[5]; + } + return ret; +} + +static const struct apple_smc_backend_ops apple_smc_rtkit_be_ops = { + .read_key = apple_smc_rtkit_read_key, + .write_key = apple_smc_rtkit_write_key, + .write_key_atomic = apple_smc_rtkit_write_key_atomic, + .rw_key = apple_smc_rtkit_rw_key, + .get_key_by_index = apple_smc_rtkit_get_key_by_index, + .get_key_info = apple_smc_rtkit_get_key_info, +}; + +static void apple_smc_rtkit_crashed(void *cookie) +{ + struct apple_smc_rtkit *smc = cookie; + + dev_err(smc->dev, "SMC crashed! Your system will reboot in a few seconds...\n"); + smc->alive = false; +} + +static int apple_smc_rtkit_shmem_setup(void *cookie, struct apple_rtkit_shmem *bfr) +{ + struct apple_smc_rtkit *smc = cookie; + struct resource res = { + .start = bfr->iova, + .end = bfr->iova + bfr->size - 1, + .name = "rtkit_map", + .flags = smc->sram->flags, + }; + + if (!bfr->iova) { + dev_err(smc->dev, "RTKit wants a RAM buffer\n"); + return -EIO; + } + + if (res.end < res.start || !resource_contains(smc->sram, &res)) { + dev_err(smc->dev, + "RTKit buffer request outside SRAM region: %pR", &res); + return -EFAULT; + } + + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); + bfr->is_mapped = true; + + return 0; +} + +static void apple_smc_rtkit_shmem_destroy(void *cookie, struct apple_rtkit_shmem *bfr) +{ + // no-op +} + +static bool apple_smc_rtkit_recv_early(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return false; + } + + if (!smc->initialized) { + int ret; + + smc->shmem.iova = message; + smc->shmem.size = SMC_SHMEM_SIZE; + ret = apple_smc_rtkit_shmem_setup(smc, &smc->shmem); + if (ret < 0) + dev_err(smc->dev, "Failed to initialize shared memory\n"); + else + smc->alive = true; + smc->initialized = true; + complete(&smc->init_done); + } else if (FIELD_GET(SMC_MSG, message) == SMC_MSG_NOTIFICATION) { + /* Handle these in the RTKit worker thread */ + return false; + } else { + smc->cmd_ret = message; + if (smc->atomic_pending) { + smc->atomic_pending = false; + } else { + complete(&smc->cmd_done); + } + } + + return true; +} + +static void apple_smc_rtkit_recv(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return; + } + + if (FIELD_GET(SMC_MSG, message) != SMC_MSG_NOTIFICATION) { + dev_err(smc->dev, "Received unknown message from worker: 0x%llx\n", message); + return; + } + + apple_smc_event_received(smc->core, FIELD_GET(SMC_DATA, message)); +} + +static const struct apple_rtkit_ops apple_smc_rtkit_ops = { + .crashed = apple_smc_rtkit_crashed, + .recv_message = apple_smc_rtkit_recv, + .recv_message_early = apple_smc_rtkit_recv_early, + .shmem_setup = apple_smc_rtkit_shmem_setup, + .shmem_destroy = apple_smc_rtkit_shmem_destroy, +}; + +static int apple_smc_rtkit_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct apple_smc_rtkit *smc; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return -ENOMEM; + + smc->dev = dev; + + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); + if (!smc->sram) + return dev_err_probe(dev, EIO, + "No SRAM region"); + + smc->sram_base = devm_ioremap_resource(dev, smc->sram); + if (IS_ERR(smc->sram_base)) + return dev_err_probe(dev, PTR_ERR(smc->sram_base), + "Failed to map SRAM region"); + + smc->rtk = + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); + if (IS_ERR(smc->rtk)) + return dev_err_probe(dev, PTR_ERR(smc->rtk), + "Failed to intialize RTKit"); + + ret = apple_rtkit_wake(smc->rtk); + if (ret != 0) + return dev_err_probe(dev, ret, + "Failed to wake up SMC"); + + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); + if (ret != 0) { + dev_err(dev, "Failed to start endpoint"); + goto cleanup; + } + + init_completion(&smc->init_done); + init_completion(&smc->cmd_done); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); + if (ret < 0) + return dev_err_probe(dev, ret, + "Failed to send init message"); + + if (wait_for_completion_timeout(&smc->init_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + ret = -ETIMEDOUT; + dev_err(dev, "Timed out initializing SMC"); + goto cleanup; + } + + if (!smc->alive) { + ret = -EIO; + goto cleanup; + } + + smc->core = apple_smc_probe(dev, &apple_smc_rtkit_be_ops, smc); + if (IS_ERR(smc->core)) { + ret = PTR_ERR(smc->core); + goto cleanup; + } + + return 0; + +cleanup: + /* Try to shut down RTKit, if it's not completely wedged */ + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return ret; +} + +static int apple_smc_rtkit_remove(struct platform_device *pdev) +{ + struct apple_smc *core = platform_get_drvdata(pdev); + struct apple_smc_rtkit *smc = apple_smc_get_cookie(core); + + apple_smc_remove(core); + + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return 0; +} + +static const struct of_device_id apple_smc_rtkit_of_match[] = { + { .compatible = "apple,smc" }, + {}, +}; +MODULE_DEVICE_TABLE(of, apple_smc_rtkit_of_match); + +static struct platform_driver apple_smc_rtkit_driver = { + .driver = { + .name = "macsmc-rtkit", + .owner = THIS_MODULE, + .of_match_table = apple_smc_rtkit_of_match, + }, + .probe = apple_smc_rtkit_probe, + .remove = apple_smc_rtkit_remove, +}; +module_platform_driver(apple_smc_rtkit_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC RTKit backend driver"); diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h new file mode 100644 index 000000000000..39b4dc4ca881 --- /dev/null +++ b/include/linux/mfd/macsmc.h @@ -0,0 +1,86 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core definitions + * Copyright (C) The Asahi Linux Contributors + */ + +#ifndef _LINUX_MFD_MACSMC_H +#define _LINUX_MFD_MACSMC_H + +struct apple_smc; + +typedef u32 smc_key; + +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) + +#define APPLE_SMC_READABLE BIT(7) +#define APPLE_SMC_WRITABLE BIT(6) +#define APPLE_SMC_FUNCTION BIT(4) + +struct apple_smc_key_info { + u8 size; + u32 type_code; + u8 flags; +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + +int apple_smc_get_key_count(struct apple_smc *smc); +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); + +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) +{ + return apple_smc_get_key_info(smc, key, NULL) >= 0; +} + +#define APPLE_SMC_TYPE_OPS(type) \ + static inline int apple_smc_read_##type(struct apple_smc *smc, smc_key key, type *p) \ + { \ + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ + } \ + static inline int apple_smc_write_##type(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_write_##type##_atomic(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key key, \ + type w, type *r) \ + { \ + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ + } + +APPLE_SMC_TYPE_OPS(u64) +APPLE_SMC_TYPE_OPS(u32) +APPLE_SMC_TYPE_OPS(u16) +APPLE_SMC_TYPE_OPS(u8) +APPLE_SMC_TYPE_OPS(s64) +APPLE_SMC_TYPE_OPS(s32) +APPLE_SMC_TYPE_OPS(s16) +APPLE_SMC_TYPE_OPS(s8) + +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) +{ + u8 val; + int ret = apple_smc_read_u8(smc, key, &val); + if (ret < 0) + return ret; + return val ? 1 : 0; +} +#define apple_smc_write_flag apple_smc_write_u8 + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); + +#endif -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-01 13:54 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements support for the SMC (System Management Controller) in Apple Macs. In contrast to the existing applesmc driver, it uses pluggable backends that allow it to support different SMC implementations, and uses the MFD subsystem to expose the core SMC functionality so that specific features (gpio, hwmon, battery, etc.) can be implemented by separate drivers in their respective downstream subsystems. The initial RTKit backend adds support for Apple Silicon Macs (M1 et al). We hope a backend for T2 Macs will be written in the future (since those are not supported by applesmc), and eventually an x86 backend would allow us to fully deprecate applesmc in favor of this driver. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 49 ++++ drivers/platform/apple/Makefile | 11 + drivers/platform/apple/smc.h | 28 ++ drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ include/linux/mfd/macsmc.h | 86 ++++++ 8 files changed, 877 insertions(+) create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/smc.h create mode 100644 drivers/platform/apple/smc_core.c create mode 100644 drivers/platform/apple/smc_rtkit.c create mode 100644 include/linux/mfd/macsmc.h diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index b437847b6237..5f8b9bcdb830 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" source "drivers/platform/surface/Kconfig" +source "drivers/platform/apple/Kconfig" + source "drivers/platform/x86/Kconfig" diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 4de08ef4ec9d..3e5d5039a28c 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig new file mode 100644 index 000000000000..42525aa9fbbe --- /dev/null +++ b/drivers/platform/apple/Kconfig @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Apple Platform-Specific Drivers +# + +menuconfig APPLE_PLATFORMS + bool "Apple Mac Platform-Specific Device Drivers" + default y + help + Say Y here to get to see options for platform-specific device drivers + for Apple devices. This option alone does not add any kernel code. + + If you say N, all options in this submenu will be skipped and disabled. + +if APPLE_PLATFORMS + +config APPLE_SMC + tristate "Apple SMC Driver" + depends on ARCH_APPLE || COMPILE_TEST + default ARCH_APPLE + select MFD_CORE + help + Build support for the Apple System Management Controller present in + Apple Macs. This driver currently supports the SMC in Apple Silicon + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). + + Say Y here if you have an Apple Silicon Mac. + + To compile this driver as a module, choose M here: the module will + be called macsmc. + +if APPLE_SMC + +config APPLE_SMC_RTKIT + tristate "RTKit (Apple Silicon) backend" + depends on ARCH_APPLE || COMPILE_TEST + depends on APPLE_RTKIT + default ARCH_APPLE + help + Build support for SMC communications via the RTKit backend. This is + required for Apple Silicon Macs. + + Say Y here if you have an Apple Silicon Mac. + + To compile this driver as a module, choose M here: the module will + be called macsmc-rtkit. + +endif +endif diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile new file mode 100644 index 000000000000..79fac195398b --- /dev/null +++ b/drivers/platform/apple/Makefile @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for linux/drivers/platform/apple +# Apple Platform-Specific Drivers +# + +macsmc-y += smc_core.o +macsmc-rtkit-y += smc_rtkit.o + +obj-$(CONFIG_APPLE_SMC) += macsmc.o +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h new file mode 100644 index 000000000000..8ae51887b2c5 --- /dev/null +++ b/drivers/platform/apple/smc.h @@ -0,0 +1,28 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC internal core definitions + * Copyright (C) The Asahi Linux Contributors + */ + +#ifndef _SMC_H +#define _SMC_H + +#include <linux/mfd/macsmc.h> + +struct apple_smc_backend_ops { + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + int (*get_key_by_index)(void *cookie, int index, smc_key *key); + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); +}; + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, + void *cookie); +void *apple_smc_get_cookie(struct apple_smc *smc); +int apple_smc_remove(struct apple_smc *smc); +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); + +#endif diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c new file mode 100644 index 000000000000..daf029cd072f --- /dev/null +++ b/drivers/platform/apple/smc_core.c @@ -0,0 +1,249 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core framework + * Copyright The Asahi Linux Contributors + */ + +#include <linux/device.h> +#include <linux/mfd/core.h> +#include <linux/mutex.h> +#include <linux/notifier.h> +#include "smc.h" + +struct apple_smc { + struct device *dev; + + void *be_cookie; + const struct apple_smc_backend_ops *be; + + struct mutex mutex; + + u32 key_count; + smc_key first_key; + smc_key last_key; + + struct blocking_notifier_head event_handlers; +}; + +static const struct mfd_cell apple_smc_devs[] = { + { + .name = "macsmc-gpio", + }, + { + .name = "macsmc-hid", + }, + { + .name = "macsmc-power", + }, + { + .name = "macsmc-reboot", + }, + { + .name = "macsmc-rtc", + }, +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->read_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_read); + +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->write_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write); + +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + /* + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff + * final calls, so it doesn't really matter at that point. + */ + if (!mutex_trylock(&smc->mutex)) + return -EBUSY; + + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write_atomic); + +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_rw); + +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_by_index); + +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_info(smc->be_cookie, key, info); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_info); + +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) +{ + int start = 0, count = smc->key_count; + int ret; + + if (key <= smc->first_key) + return 0; + if (key > smc->last_key) + return smc->key_count; + + while (count > 1) { + int pivot = start + ((count - 1) >> 1); + smc_key pkey; + + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); + if (ret < 0) + return ret; + + if (pkey == key) + return pivot; + + pivot++; + + if (pkey < key) { + count -= pivot - start; + start = pivot; + } else { + count = pivot - start; + } + } + + return start; +} +EXPORT_SYMBOL(apple_smc_find_first_key_index); + +int apple_smc_get_key_count(struct apple_smc *smc) +{ + return smc->key_count; +} +EXPORT_SYMBOL(apple_smc_get_key_count); + +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) +{ + dev_dbg(smc->dev, "Event: 0x%08x\n", event); + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); +} +EXPORT_SYMBOL(apple_smc_event_received); + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_register(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_register_notifier); + +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_unregister(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_unregister_notifier); + +void *apple_smc_get_cookie(struct apple_smc *smc) +{ + return smc->be_cookie; +} +EXPORT_SYMBOL(apple_smc_get_cookie); + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) +{ + struct apple_smc *smc; + u32 count; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return ERR_PTR(-ENOMEM); + + smc->dev = dev; + smc->be_cookie = cookie; + smc->be = ops; + mutex_init(&smc->mutex); + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); + + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); + smc->key_count = be32_to_cpu(count); + + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); + + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, &smc->last_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); + + /* Enable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", + smc->key_count, &smc->first_key, &smc->last_key); + + dev_set_drvdata(dev, smc); + + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); + + return smc; +} +EXPORT_SYMBOL(apple_smc_probe); + +int apple_smc_remove(struct apple_smc *smc) +{ + mfd_remove_devices(smc->dev); + + /* Disable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + return 0; +} +EXPORT_SYMBOL(apple_smc_remove); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC core"); diff --git a/drivers/platform/apple/smc_rtkit.c b/drivers/platform/apple/smc_rtkit.c new file mode 100644 index 000000000000..5b7c4c475bbb --- /dev/null +++ b/drivers/platform/apple/smc_rtkit.c @@ -0,0 +1,451 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC RTKit backend + * Copyright The Asahi Linux Contributors + */ + +#include <asm/unaligned.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/io.h> +#include <linux/ioport.h> +#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/soc/apple/rtkit.h> +#include "smc.h" + +#define SMC_ENDPOINT 0x20 + +/* Guess */ +#define SMC_SHMEM_SIZE 0x1000 + +#define SMC_MSG_READ_KEY 0x10 +#define SMC_MSG_WRITE_KEY 0x11 +#define SMC_MSG_GET_KEY_BY_INDEX 0x12 +#define SMC_MSG_GET_KEY_INFO 0x13 +#define SMC_MSG_INITIALIZE 0x17 +#define SMC_MSG_NOTIFICATION 0x18 +#define SMC_MSG_RW_KEY 0x20 + +#define SMC_DATA GENMASK(63, 32) +#define SMC_WSIZE GENMASK(31, 24) +#define SMC_SIZE GENMASK(23, 16) +#define SMC_ID GENMASK(15, 12) +#define SMC_MSG GENMASK(7, 0) +#define SMC_RESULT SMC_MSG + +#define SMC_RECV_TIMEOUT 100 + +struct apple_smc_rtkit { + struct device *dev; + struct apple_smc *core; + struct apple_rtkit *rtk; + + struct completion init_done; + bool initialized; + bool alive; + + struct resource *sram; + void __iomem *sram_base; + struct apple_rtkit_shmem shmem; + + unsigned int msg_id; + + bool atomic_pending; + struct completion cmd_done; + u64 cmd_ret; +}; + +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + u64 msg; + u8 result; + + if (size > SMC_SHMEM_SIZE || size == 0) + return -EINVAL; + + if (!smc->alive) + return -EIO; + + memcpy_toio(smc->shmem.iomem, buf, size); + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, key)); + smc->atomic_pending = true; + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, true); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command (%d)\n", ret); + return ret; + } + + while (smc->atomic_pending) { + ret = apple_rtkit_poll(smc->rtk); + if (ret < 0) { + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); + return ret; + } + udelay(100); + } + + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + return -EIO; + } + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int apple_smc_cmd(struct apple_smc_rtkit *smc, u64 cmd, u64 arg, + u64 size, u64 wsize, u32 *ret_data) +{ + int ret; + u64 msg; + u8 result; + + if (!smc->alive) + return -EIO; + + reinit_completion(&smc->cmd_done); + + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, cmd) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_WSIZE, wsize) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, arg)); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, false); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command\n"); + return ret; + } + + do { + if (wait_for_completion_timeout(&smc->cmd_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + dev_err(smc->dev, "Command timed out (%llx)", msg); + return -ETIMEDOUT; + } + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) + break; + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + } while(1); + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + if (ret_data) + *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int _apple_smc_rtkit_read_key(struct apple_smc_rtkit *smc, smc_key key, + void *buf, size_t size, size_t wsize) +{ + int ret; + u32 rdata; + u64 cmd; + + if (size > SMC_SHMEM_SIZE || size == 0) + return -EINVAL; + + cmd = wsize ? SMC_MSG_RW_KEY : SMC_MSG_READ_KEY; + + ret = apple_smc_cmd(smc, cmd, key, size, wsize, &rdata); + if (ret < 0) + return ret; + + if (size <= 4) + memcpy(buf, &rdata, size); + else + memcpy_fromio(buf, smc->shmem.iomem, size); + + return ret; +} + +static int apple_smc_rtkit_read_key(void *cookie, smc_key key, void *buf, size_t size) +{ + return _apple_smc_rtkit_read_key(cookie, key, buf, size, 0); +} + +static int apple_smc_rtkit_write_key(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + + if (size > SMC_SHMEM_SIZE || size == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, buf, size); + return apple_smc_cmd(smc, SMC_MSG_WRITE_KEY, key, size, 0, NULL); +} + +static int apple_smc_rtkit_rw_key(void *cookie, smc_key key, + void *wbuf, size_t wsize, void *rbuf, size_t rsize) +{ + struct apple_smc_rtkit *smc = cookie; + + if (wsize > SMC_SHMEM_SIZE || wsize == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, wbuf, wsize); + return _apple_smc_rtkit_read_key(smc, key, rbuf, rsize, wsize); +} + +static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, smc_key *key) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); + + *key = swab32(*key); + return ret; +} + +static int apple_smc_rtkit_get_key_info(void *cookie, smc_key key, struct apple_smc_key_info *info) +{ + struct apple_smc_rtkit *smc = cookie; + u8 key_info[6]; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_INFO, key, 0, 0, NULL); + if (ret >= 0 && info) { + info->size = key_info[0]; + info->type_code = get_unaligned_be32(&key_info[1]); + info->flags = key_info[5]; + } + return ret; +} + +static const struct apple_smc_backend_ops apple_smc_rtkit_be_ops = { + .read_key = apple_smc_rtkit_read_key, + .write_key = apple_smc_rtkit_write_key, + .write_key_atomic = apple_smc_rtkit_write_key_atomic, + .rw_key = apple_smc_rtkit_rw_key, + .get_key_by_index = apple_smc_rtkit_get_key_by_index, + .get_key_info = apple_smc_rtkit_get_key_info, +}; + +static void apple_smc_rtkit_crashed(void *cookie) +{ + struct apple_smc_rtkit *smc = cookie; + + dev_err(smc->dev, "SMC crashed! Your system will reboot in a few seconds...\n"); + smc->alive = false; +} + +static int apple_smc_rtkit_shmem_setup(void *cookie, struct apple_rtkit_shmem *bfr) +{ + struct apple_smc_rtkit *smc = cookie; + struct resource res = { + .start = bfr->iova, + .end = bfr->iova + bfr->size - 1, + .name = "rtkit_map", + .flags = smc->sram->flags, + }; + + if (!bfr->iova) { + dev_err(smc->dev, "RTKit wants a RAM buffer\n"); + return -EIO; + } + + if (res.end < res.start || !resource_contains(smc->sram, &res)) { + dev_err(smc->dev, + "RTKit buffer request outside SRAM region: %pR", &res); + return -EFAULT; + } + + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); + bfr->is_mapped = true; + + return 0; +} + +static void apple_smc_rtkit_shmem_destroy(void *cookie, struct apple_rtkit_shmem *bfr) +{ + // no-op +} + +static bool apple_smc_rtkit_recv_early(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return false; + } + + if (!smc->initialized) { + int ret; + + smc->shmem.iova = message; + smc->shmem.size = SMC_SHMEM_SIZE; + ret = apple_smc_rtkit_shmem_setup(smc, &smc->shmem); + if (ret < 0) + dev_err(smc->dev, "Failed to initialize shared memory\n"); + else + smc->alive = true; + smc->initialized = true; + complete(&smc->init_done); + } else if (FIELD_GET(SMC_MSG, message) == SMC_MSG_NOTIFICATION) { + /* Handle these in the RTKit worker thread */ + return false; + } else { + smc->cmd_ret = message; + if (smc->atomic_pending) { + smc->atomic_pending = false; + } else { + complete(&smc->cmd_done); + } + } + + return true; +} + +static void apple_smc_rtkit_recv(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return; + } + + if (FIELD_GET(SMC_MSG, message) != SMC_MSG_NOTIFICATION) { + dev_err(smc->dev, "Received unknown message from worker: 0x%llx\n", message); + return; + } + + apple_smc_event_received(smc->core, FIELD_GET(SMC_DATA, message)); +} + +static const struct apple_rtkit_ops apple_smc_rtkit_ops = { + .crashed = apple_smc_rtkit_crashed, + .recv_message = apple_smc_rtkit_recv, + .recv_message_early = apple_smc_rtkit_recv_early, + .shmem_setup = apple_smc_rtkit_shmem_setup, + .shmem_destroy = apple_smc_rtkit_shmem_destroy, +}; + +static int apple_smc_rtkit_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct apple_smc_rtkit *smc; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return -ENOMEM; + + smc->dev = dev; + + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); + if (!smc->sram) + return dev_err_probe(dev, EIO, + "No SRAM region"); + + smc->sram_base = devm_ioremap_resource(dev, smc->sram); + if (IS_ERR(smc->sram_base)) + return dev_err_probe(dev, PTR_ERR(smc->sram_base), + "Failed to map SRAM region"); + + smc->rtk = + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); + if (IS_ERR(smc->rtk)) + return dev_err_probe(dev, PTR_ERR(smc->rtk), + "Failed to intialize RTKit"); + + ret = apple_rtkit_wake(smc->rtk); + if (ret != 0) + return dev_err_probe(dev, ret, + "Failed to wake up SMC"); + + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); + if (ret != 0) { + dev_err(dev, "Failed to start endpoint"); + goto cleanup; + } + + init_completion(&smc->init_done); + init_completion(&smc->cmd_done); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); + if (ret < 0) + return dev_err_probe(dev, ret, + "Failed to send init message"); + + if (wait_for_completion_timeout(&smc->init_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + ret = -ETIMEDOUT; + dev_err(dev, "Timed out initializing SMC"); + goto cleanup; + } + + if (!smc->alive) { + ret = -EIO; + goto cleanup; + } + + smc->core = apple_smc_probe(dev, &apple_smc_rtkit_be_ops, smc); + if (IS_ERR(smc->core)) { + ret = PTR_ERR(smc->core); + goto cleanup; + } + + return 0; + +cleanup: + /* Try to shut down RTKit, if it's not completely wedged */ + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return ret; +} + +static int apple_smc_rtkit_remove(struct platform_device *pdev) +{ + struct apple_smc *core = platform_get_drvdata(pdev); + struct apple_smc_rtkit *smc = apple_smc_get_cookie(core); + + apple_smc_remove(core); + + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return 0; +} + +static const struct of_device_id apple_smc_rtkit_of_match[] = { + { .compatible = "apple,smc" }, + {}, +}; +MODULE_DEVICE_TABLE(of, apple_smc_rtkit_of_match); + +static struct platform_driver apple_smc_rtkit_driver = { + .driver = { + .name = "macsmc-rtkit", + .owner = THIS_MODULE, + .of_match_table = apple_smc_rtkit_of_match, + }, + .probe = apple_smc_rtkit_probe, + .remove = apple_smc_rtkit_remove, +}; +module_platform_driver(apple_smc_rtkit_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC RTKit backend driver"); diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h new file mode 100644 index 000000000000..39b4dc4ca881 --- /dev/null +++ b/include/linux/mfd/macsmc.h @@ -0,0 +1,86 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core definitions + * Copyright (C) The Asahi Linux Contributors + */ + +#ifndef _LINUX_MFD_MACSMC_H +#define _LINUX_MFD_MACSMC_H + +struct apple_smc; + +typedef u32 smc_key; + +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) + +#define APPLE_SMC_READABLE BIT(7) +#define APPLE_SMC_WRITABLE BIT(6) +#define APPLE_SMC_FUNCTION BIT(4) + +struct apple_smc_key_info { + u8 size; + u32 type_code; + u8 flags; +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + +int apple_smc_get_key_count(struct apple_smc *smc); +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); + +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) +{ + return apple_smc_get_key_info(smc, key, NULL) >= 0; +} + +#define APPLE_SMC_TYPE_OPS(type) \ + static inline int apple_smc_read_##type(struct apple_smc *smc, smc_key key, type *p) \ + { \ + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ + } \ + static inline int apple_smc_write_##type(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_write_##type##_atomic(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key key, \ + type w, type *r) \ + { \ + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ + } + +APPLE_SMC_TYPE_OPS(u64) +APPLE_SMC_TYPE_OPS(u32) +APPLE_SMC_TYPE_OPS(u16) +APPLE_SMC_TYPE_OPS(u8) +APPLE_SMC_TYPE_OPS(s64) +APPLE_SMC_TYPE_OPS(s32) +APPLE_SMC_TYPE_OPS(s16) +APPLE_SMC_TYPE_OPS(s8) + +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) +{ + u8 val; + int ret = apple_smc_read_u8(smc, key, &val); + if (ret < 0) + return ret; + return val ? 1 : 0; +} +#define apple_smc_write_flag apple_smc_write_u8 + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); + +#endif -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 13:54 ` Russell King @ 2022-09-01 17:50 ` Sven Peter -1 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-01 17:50 UTC (permalink / raw) To: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM Thanks for trying to upstream this! I just have three minor comments: On Thu, Sep 1, 2022, at 15:54, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. > > The initial RTKit backend adds support for Apple Silicon Macs (M1 et > al). We hope a backend for T2 Macs will be written in the future > (since those are not supported by applesmc), and eventually an x86 > backend would allow us to fully deprecate applesmc in favor of this > driver. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/platform/Kconfig | 2 + > drivers/platform/Makefile | 1 + > drivers/platform/apple/Kconfig | 49 ++++ > drivers/platform/apple/Makefile | 11 + > drivers/platform/apple/smc.h | 28 ++ > drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ > drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ > include/linux/mfd/macsmc.h | 86 ++++++ > 8 files changed, 877 insertions(+) > create mode 100644 drivers/platform/apple/Kconfig > create mode 100644 drivers/platform/apple/Makefile > create mode 100644 drivers/platform/apple/smc.h > create mode 100644 drivers/platform/apple/smc_core.c > create mode 100644 drivers/platform/apple/smc_rtkit.c > create mode 100644 include/linux/mfd/macsmc.h > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > index b437847b6237..5f8b9bcdb830 100644 > --- a/drivers/platform/Kconfig > +++ b/drivers/platform/Kconfig > @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" > > source "drivers/platform/surface/Kconfig" > > +source "drivers/platform/apple/Kconfig" > + > source "drivers/platform/x86/Kconfig" > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > index 4de08ef4ec9d..3e5d5039a28c 100644 > --- a/drivers/platform/Makefile > +++ b/drivers/platform/Makefile > @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ > obj-$(CONFIG_GOLDFISH) += goldfish/ > obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ > +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ > diff --git a/drivers/platform/apple/Kconfig > b/drivers/platform/apple/Kconfig > new file mode 100644 > index 000000000000..42525aa9fbbe > --- /dev/null > +++ b/drivers/platform/apple/Kconfig > @@ -0,0 +1,49 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Apple Platform-Specific Drivers > +# > + > +menuconfig APPLE_PLATFORMS > + bool "Apple Mac Platform-Specific Device Drivers" > + default y > + help > + Say Y here to get to see options for platform-specific device > drivers > + for Apple devices. This option alone does not add any kernel code. > + > + If you say N, all options in this submenu will be skipped and > disabled. > + > +if APPLE_PLATFORMS > + > +config APPLE_SMC > + tristate "Apple SMC Driver" > + depends on ARCH_APPLE || COMPILE_TEST > + default ARCH_APPLE > + select MFD_CORE > + help > + Build support for the Apple System Management Controller present in > + Apple Macs. This driver currently supports the SMC in Apple Silicon > + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc. > + > +if APPLE_SMC > + > +config APPLE_SMC_RTKIT > + tristate "RTKit (Apple Silicon) backend" > + depends on ARCH_APPLE || COMPILE_TEST > + depends on APPLE_RTKIT > + default ARCH_APPLE > + help > + Build support for SMC communications via the RTKit backend. This is > + required for Apple Silicon Macs. > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc-rtkit. > + > +endif > +endif > diff --git a/drivers/platform/apple/Makefile > b/drivers/platform/apple/Makefile > new file mode 100644 > index 000000000000..79fac195398b > --- /dev/null > +++ b/drivers/platform/apple/Makefile > @@ -0,0 +1,11 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for linux/drivers/platform/apple > +# Apple Platform-Specific Drivers > +# > + > +macsmc-y += smc_core.o > +macsmc-rtkit-y += smc_rtkit.o > + > +obj-$(CONFIG_APPLE_SMC) += macsmc.o > +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o > diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h > new file mode 100644 > index 000000000000..8ae51887b2c5 > --- /dev/null > +++ b/drivers/platform/apple/smc.h > @@ -0,0 +1,28 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC internal core definitions > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _SMC_H > +#define _SMC_H > + > +#include <linux/mfd/macsmc.h> > + > +struct apple_smc_backend_ops { > + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t > size); > + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > + int (*get_key_info)(void *cookie, smc_key key, struct > apple_smc_key_info *info); > +}; > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct > apple_smc_backend_ops *ops, > + void *cookie); > +void *apple_smc_get_cookie(struct apple_smc *smc); > +int apple_smc_remove(struct apple_smc *smc); > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > + > +#endif > diff --git a/drivers/platform/apple/smc_core.c > b/drivers/platform/apple/smc_core.c > new file mode 100644 > index 000000000000..daf029cd072f > --- /dev/null > +++ b/drivers/platform/apple/smc_core.c > @@ -0,0 +1,249 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core framework > + * Copyright The Asahi Linux Contributors > + */ > + > +#include <linux/device.h> > +#include <linux/mfd/core.h> > +#include <linux/mutex.h> > +#include <linux/notifier.h> > +#include "smc.h" > + > +struct apple_smc { > + struct device *dev; > + > + void *be_cookie; > + const struct apple_smc_backend_ops *be; > + > + struct mutex mutex; > + > + u32 key_count; > + smc_key first_key; > + smc_key last_key; > + > + struct blocking_notifier_head event_handlers; > +}; > + > +static const struct mfd_cell apple_smc_devs[] = { > + { > + .name = "macsmc-gpio", > + }, > + { > + .name = "macsmc-hid", > + }, > + { > + .name = "macsmc-power", > + }, > + { > + .name = "macsmc-reboot", > + }, > + { > + .name = "macsmc-rtc", > + }, > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, > size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->read_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_read); > + > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, > size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->write_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write); > + > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void > *buf, size_t size) > +{ > + int ret; > + > + /* > + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff > + * final calls, so it doesn't really matter at that point. > + */ > + if (!mutex_trylock(&smc->mutex)) > + return -EBUSY; > + > + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write_atomic); > + > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, > size_t wsize, > + void *rbuf, size_t rsize) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_rw); > + > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, > smc_key *key) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_by_index); > + > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct > apple_smc_key_info *info) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_info(smc->be_cookie, key, info); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_info); > + > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) > +{ > + int start = 0, count = smc->key_count; > + int ret; > + > + if (key <= smc->first_key) > + return 0; > + if (key > smc->last_key) > + return smc->key_count; > + > + while (count > 1) { > + int pivot = start + ((count - 1) >> 1); > + smc_key pkey; > + > + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); > + if (ret < 0) > + return ret; > + > + if (pkey == key) > + return pivot; > + > + pivot++; > + > + if (pkey < key) { > + count -= pivot - start; > + start = pivot; > + } else { > + count = pivot - start; > + } > + } > + > + return start; > +} > +EXPORT_SYMBOL(apple_smc_find_first_key_index); > + > +int apple_smc_get_key_count(struct apple_smc *smc) > +{ > + return smc->key_count; > +} > +EXPORT_SYMBOL(apple_smc_get_key_count); > + > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) > +{ > + dev_dbg(smc->dev, "Event: 0x%08x\n", event); > + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); > +} > +EXPORT_SYMBOL(apple_smc_event_received); > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct > notifier_block *n) > +{ > + return blocking_notifier_chain_register(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_register_notifier); > + > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct > notifier_block *n) > +{ > + return blocking_notifier_chain_unregister(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_unregister_notifier); > + > +void *apple_smc_get_cookie(struct apple_smc *smc) > +{ > + return smc->be_cookie; > +} > +EXPORT_SYMBOL(apple_smc_get_cookie); > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct > apple_smc_backend_ops *ops, void *cookie) > +{ > + struct apple_smc *smc; > + u32 count; > + int ret; > + > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > + if (!smc) > + return ERR_PTR(-ENOMEM); > + > + smc->dev = dev; > + smc->be_cookie = cookie; > + smc->be = ops; > + mutex_init(&smc->mutex); > + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); > + > + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); > + smc->key_count = be32_to_cpu(count); > + > + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); > + > + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, > &smc->last_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); > + > + /* Enable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); > + > + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", > + smc->key_count, &smc->first_key, &smc->last_key); I don't think upstream supports %p4ch. marcan added that format in our downstream tree iirc. > + > + dev_set_drvdata(dev, smc); > + > + ret = mfd_add_devices(dev, -1, apple_smc_devs, > ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization > failed")); > + > + return smc; > +} > +EXPORT_SYMBOL(apple_smc_probe); > + > +int apple_smc_remove(struct apple_smc *smc) > +{ > + mfd_remove_devices(smc->dev); > + > + /* Disable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); > + > + return 0; > +} > +EXPORT_SYMBOL(apple_smc_remove); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC core"); > diff --git a/drivers/platform/apple/smc_rtkit.c > b/drivers/platform/apple/smc_rtkit.c > new file mode 100644 > index 000000000000..5b7c4c475bbb > --- /dev/null > +++ b/drivers/platform/apple/smc_rtkit.c > @@ -0,0 +1,451 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC RTKit backend > + * Copyright The Asahi Linux Contributors > + */ > + > +#include <asm/unaligned.h> > +#include <linux/delay.h> > +#include <linux/device.h> > +#include <linux/io.h> > +#include <linux/ioport.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > +#include <linux/soc/apple/rtkit.h> > +#include "smc.h" > + > +#define SMC_ENDPOINT 0x20 > + > +/* Guess */ > +#define SMC_SHMEM_SIZE 0x1000 > + > +#define SMC_MSG_READ_KEY 0x10 > +#define SMC_MSG_WRITE_KEY 0x11 > +#define SMC_MSG_GET_KEY_BY_INDEX 0x12 > +#define SMC_MSG_GET_KEY_INFO 0x13 > +#define SMC_MSG_INITIALIZE 0x17 > +#define SMC_MSG_NOTIFICATION 0x18 > +#define SMC_MSG_RW_KEY 0x20 > + > +#define SMC_DATA GENMASK(63, 32) > +#define SMC_WSIZE GENMASK(31, 24) > +#define SMC_SIZE GENMASK(23, 16) > +#define SMC_ID GENMASK(15, 12) > +#define SMC_MSG GENMASK(7, 0) > +#define SMC_RESULT SMC_MSG > + > +#define SMC_RECV_TIMEOUT 100 > + > +struct apple_smc_rtkit { > + struct device *dev; > + struct apple_smc *core; > + struct apple_rtkit *rtk; > + > + struct completion init_done; > + bool initialized; > + bool alive; > + > + struct resource *sram; > + void __iomem *sram_base; > + struct apple_rtkit_shmem shmem; > + > + unsigned int msg_id; > + > + bool atomic_pending; > + struct completion cmd_done; > + u64 cmd_ret; > +}; > + > +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, > void *buf, size_t size) > +{ > + struct apple_smc_rtkit *smc = cookie; > + int ret; > + u64 msg; > + u8 result; > + > + if (size > SMC_SHMEM_SIZE || size == 0) > + return -EINVAL; > + > + if (!smc->alive) > + return -EIO; > + > + memcpy_toio(smc->shmem.iomem, buf, size); > + smc->msg_id = (smc->msg_id + 1) & 0xf; > + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | > + FIELD_PREP(SMC_SIZE, size) | > + FIELD_PREP(SMC_ID, smc->msg_id) | > + FIELD_PREP(SMC_DATA, key)); > + smc->atomic_pending = true; > + > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, > true); > + if (ret < 0) { > + dev_err(smc->dev, "Failed to send command (%d)\n", ret); > + return ret; > + } > + > + while (smc->atomic_pending) { > + ret = apple_rtkit_poll(smc->rtk); > + if (ret < 0) { > + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); > + return ret; > + } > + udelay(100); > + } I guess we could use try_wait_for_completion here and get rid of the special smc->atomic_pending path. Not sure if it makes the code much simpler though. > + > + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got > %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); > + return -EIO; > + } > + > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; > + > + return FIELD_GET(SMC_SIZE, smc->cmd_ret); > +} > + > +static int apple_smc_cmd(struct apple_smc_rtkit *smc, u64 cmd, u64 arg, > + u64 size, u64 wsize, u32 *ret_data) > +{ > + int ret; > + u64 msg; > + u8 result; > + > + if (!smc->alive) > + return -EIO; > + > + reinit_completion(&smc->cmd_done); > + > + smc->msg_id = (smc->msg_id + 1) & 0xf; > + msg = (FIELD_PREP(SMC_MSG, cmd) | > + FIELD_PREP(SMC_SIZE, size) | > + FIELD_PREP(SMC_WSIZE, wsize) | > + FIELD_PREP(SMC_ID, smc->msg_id) | > + FIELD_PREP(SMC_DATA, arg)); > + > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, > false); > + if (ret < 0) { > + dev_err(smc->dev, "Failed to send command\n"); > + return ret; > + } > + > + do { > + if (wait_for_completion_timeout(&smc->cmd_done, > + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { > + dev_err(smc->dev, "Command timed out (%llx)", msg); > + return -ETIMEDOUT; > + } > + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) > + break; > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got > %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); > + } while(1); > + > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; > + > + if (ret_data) > + *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); > + > + return FIELD_GET(SMC_SIZE, smc->cmd_ret); > +} > + > +static int _apple_smc_rtkit_read_key(struct apple_smc_rtkit *smc, > smc_key key, > + void *buf, size_t size, size_t wsize) > +{ > + int ret; > + u32 rdata; > + u64 cmd; > + > + if (size > SMC_SHMEM_SIZE || size == 0) > + return -EINVAL; > + > + cmd = wsize ? SMC_MSG_RW_KEY : SMC_MSG_READ_KEY; > + > + ret = apple_smc_cmd(smc, cmd, key, size, wsize, &rdata); > + if (ret < 0) > + return ret; > + > + if (size <= 4) > + memcpy(buf, &rdata, size); > + else > + memcpy_fromio(buf, smc->shmem.iomem, size); > + > + return ret; > +} > + > +static int apple_smc_rtkit_read_key(void *cookie, smc_key key, void > *buf, size_t size) > +{ > + return _apple_smc_rtkit_read_key(cookie, key, buf, size, 0); > +} > + > +static int apple_smc_rtkit_write_key(void *cookie, smc_key key, void > *buf, size_t size) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (size > SMC_SHMEM_SIZE || size == 0) > + return -EINVAL; > + > + memcpy_toio(smc->shmem.iomem, buf, size); > + return apple_smc_cmd(smc, SMC_MSG_WRITE_KEY, key, size, 0, NULL); > +} > + > +static int apple_smc_rtkit_rw_key(void *cookie, smc_key key, > + void *wbuf, size_t wsize, void *rbuf, size_t rsize) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (wsize > SMC_SHMEM_SIZE || wsize == 0) > + return -EINVAL; > + > + memcpy_toio(smc->shmem.iomem, wbuf, wsize); > + return _apple_smc_rtkit_read_key(smc, key, rbuf, rsize, wsize); > +} > + > +static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, > smc_key *key) > +{ > + struct apple_smc_rtkit *smc = cookie; > + int ret; > + > + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); > + > + *key = swab32(*key); > + return ret; > +} > + > +static int apple_smc_rtkit_get_key_info(void *cookie, smc_key key, > struct apple_smc_key_info *info) > +{ > + struct apple_smc_rtkit *smc = cookie; > + u8 key_info[6]; > + int ret; > + > + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_INFO, key, 0, 0, NULL); > + if (ret >= 0 && info) { > + info->size = key_info[0]; > + info->type_code = get_unaligned_be32(&key_info[1]); > + info->flags = key_info[5]; > + } > + return ret; > +} > + > +static const struct apple_smc_backend_ops apple_smc_rtkit_be_ops = { > + .read_key = apple_smc_rtkit_read_key, > + .write_key = apple_smc_rtkit_write_key, > + .write_key_atomic = apple_smc_rtkit_write_key_atomic, > + .rw_key = apple_smc_rtkit_rw_key, > + .get_key_by_index = apple_smc_rtkit_get_key_by_index, > + .get_key_info = apple_smc_rtkit_get_key_info, > +}; > + > +static void apple_smc_rtkit_crashed(void *cookie) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + dev_err(smc->dev, "SMC crashed! Your system will reboot in a few > seconds...\n"); > + smc->alive = false; > +} > + > +static int apple_smc_rtkit_shmem_setup(void *cookie, struct > apple_rtkit_shmem *bfr) > +{ > + struct apple_smc_rtkit *smc = cookie; > + struct resource res = { > + .start = bfr->iova, > + .end = bfr->iova + bfr->size - 1, > + .name = "rtkit_map", > + .flags = smc->sram->flags, > + }; > + > + if (!bfr->iova) { > + dev_err(smc->dev, "RTKit wants a RAM buffer\n"); > + return -EIO; > + } > + > + if (res.end < res.start || !resource_contains(smc->sram, &res)) { > + dev_err(smc->dev, > + "RTKit buffer request outside SRAM region: %pR", &res); > + return -EFAULT; > + } > + > + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); > + bfr->is_mapped = true; > + > + return 0; > +} > + > +static void apple_smc_rtkit_shmem_destroy(void *cookie, struct > apple_rtkit_shmem *bfr) > +{ > + // no-op > +} > + > +static bool apple_smc_rtkit_recv_early(void *cookie, u8 endpoint, u64 > message) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (endpoint != SMC_ENDPOINT) { > + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", > endpoint); > + return false; > + } > + > + if (!smc->initialized) { > + int ret; > + > + smc->shmem.iova = message; > + smc->shmem.size = SMC_SHMEM_SIZE; > + ret = apple_smc_rtkit_shmem_setup(smc, &smc->shmem); > + if (ret < 0) > + dev_err(smc->dev, "Failed to initialize shared memory\n"); > + else > + smc->alive = true; > + smc->initialized = true; > + complete(&smc->init_done); > + } else if (FIELD_GET(SMC_MSG, message) == SMC_MSG_NOTIFICATION) { > + /* Handle these in the RTKit worker thread */ > + return false; > + } else { > + smc->cmd_ret = message; > + if (smc->atomic_pending) { > + smc->atomic_pending = false; > + } else { > + complete(&smc->cmd_done); > + } > + } > + > + return true; > +} > + > +static void apple_smc_rtkit_recv(void *cookie, u8 endpoint, u64 > message) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (endpoint != SMC_ENDPOINT) { > + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", > endpoint); > + return; > + } > + > + if (FIELD_GET(SMC_MSG, message) != SMC_MSG_NOTIFICATION) { > + dev_err(smc->dev, "Received unknown message from worker: 0x%llx\n", > message); > + return; > + } > + > + apple_smc_event_received(smc->core, FIELD_GET(SMC_DATA, message)); > +} > + > +static const struct apple_rtkit_ops apple_smc_rtkit_ops = { > + .crashed = apple_smc_rtkit_crashed, > + .recv_message = apple_smc_rtkit_recv, > + .recv_message_early = apple_smc_rtkit_recv_early, > + .shmem_setup = apple_smc_rtkit_shmem_setup, > + .shmem_destroy = apple_smc_rtkit_shmem_destroy, > +}; > + > +static int apple_smc_rtkit_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct apple_smc_rtkit *smc; > + int ret; > + > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > + if (!smc) > + return -ENOMEM; > + > + smc->dev = dev; > + > + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, > "sram"); > + if (!smc->sram) > + return dev_err_probe(dev, EIO, > + "No SRAM region"); > + > + smc->sram_base = devm_ioremap_resource(dev, smc->sram); > + if (IS_ERR(smc->sram_base)) > + return dev_err_probe(dev, PTR_ERR(smc->sram_base), > + "Failed to map SRAM region"); > + > + smc->rtk = > + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); > + if (IS_ERR(smc->rtk)) > + return dev_err_probe(dev, PTR_ERR(smc->rtk), > + "Failed to intialize RTKit"); > + > + ret = apple_rtkit_wake(smc->rtk); > + if (ret != 0) > + return dev_err_probe(dev, ret, > + "Failed to wake up SMC"); > + > + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); > + if (ret != 0) { > + dev_err(dev, "Failed to start endpoint"); > + goto cleanup; > + } > + > + init_completion(&smc->init_done); > + init_completion(&smc->cmd_done); > + > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, > + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); > + if (ret < 0) > + return dev_err_probe(dev, ret, > + "Failed to send init message"); This should probably also "goto cleanup" here just in case we somehow manage to send the shutdown message after this one failed. > + > + if (wait_for_completion_timeout(&smc->init_done, > + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { > + ret = -ETIMEDOUT; > + dev_err(dev, "Timed out initializing SMC"); > + goto cleanup; > + } > + > + if (!smc->alive) { > + ret = -EIO; > + goto cleanup; > + } > + > + smc->core = apple_smc_probe(dev, &apple_smc_rtkit_be_ops, smc); > + if (IS_ERR(smc->core)) { > + ret = PTR_ERR(smc->core); > + goto cleanup; > + } > + > + return 0; > + > +cleanup: > + /* Try to shut down RTKit, if it's not completely wedged */ > + if (apple_rtkit_is_running(smc->rtk)) > + apple_rtkit_quiesce(smc->rtk); > + > + return ret; > +} > + > +static int apple_smc_rtkit_remove(struct platform_device *pdev) > +{ > + struct apple_smc *core = platform_get_drvdata(pdev); > + struct apple_smc_rtkit *smc = apple_smc_get_cookie(core); > + > + apple_smc_remove(core); > + > + if (apple_rtkit_is_running(smc->rtk)) > + apple_rtkit_quiesce(smc->rtk); > + > + return 0; > +} > + > +static const struct of_device_id apple_smc_rtkit_of_match[] = { > + { .compatible = "apple,smc" }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, apple_smc_rtkit_of_match); > + > +static struct platform_driver apple_smc_rtkit_driver = { > + .driver = { > + .name = "macsmc-rtkit", > + .owner = THIS_MODULE, > + .of_match_table = apple_smc_rtkit_of_match, > + }, > + .probe = apple_smc_rtkit_probe, > + .remove = apple_smc_rtkit_remove, > +}; > +module_platform_driver(apple_smc_rtkit_driver); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC RTKit backend driver"); > diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h > new file mode 100644 > index 000000000000..39b4dc4ca881 > --- /dev/null > +++ b/include/linux/mfd/macsmc.h > @@ -0,0 +1,86 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core definitions > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _LINUX_MFD_MACSMC_H > +#define _LINUX_MFD_MACSMC_H > + > +struct apple_smc; > + > +typedef u32 smc_key; > + > +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) > +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | > (s)[3]) > + > +#define APPLE_SMC_READABLE BIT(7) > +#define APPLE_SMC_WRITABLE BIT(6) > +#define APPLE_SMC_FUNCTION BIT(4) > + > +struct apple_smc_key_info { > + u8 size; > + u32 type_code; > + u8 flags; > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, > size_t size); > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, > size_t size); > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void > *buf, size_t size); > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, > size_t wsize, > + void *rbuf, size_t rsize); > + > +int apple_smc_get_key_count(struct apple_smc *smc); > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, > smc_key *key); > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct > apple_smc_key_info *info); > + > +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key > key) > +{ > + return apple_smc_get_key_info(smc, key, NULL) >= 0; > +} > + > +#define APPLE_SMC_TYPE_OPS(type) \ > + static inline int apple_smc_read_##type(struct apple_smc *smc, > smc_key key, type *p) \ > + { \ > + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ > + } \ > + static inline int apple_smc_write_##type(struct apple_smc *smc, > smc_key key, type p) \ > + { \ > + return apple_smc_write(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_write_##type##_atomic(struct apple_smc > *smc, smc_key key, type p) \ > + { \ > + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key > key, \ > + type w, type *r) \ > + { \ > + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ > + } > + > +APPLE_SMC_TYPE_OPS(u64) > +APPLE_SMC_TYPE_OPS(u32) > +APPLE_SMC_TYPE_OPS(u16) > +APPLE_SMC_TYPE_OPS(u8) > +APPLE_SMC_TYPE_OPS(s64) > +APPLE_SMC_TYPE_OPS(s32) > +APPLE_SMC_TYPE_OPS(s16) > +APPLE_SMC_TYPE_OPS(s8) > + > +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key > key) > +{ > + u8 val; > + int ret = apple_smc_read_u8(smc, key, &val); > + if (ret < 0) > + return ret; > + return val ? 1 : 0; > +} > +#define apple_smc_write_flag apple_smc_write_u8 > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct > notifier_block *n); > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct > notifier_block *n); > + > +#endif > -- > 2.30.2 Sven ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-01 17:50 ` Sven Peter 0 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-01 17:50 UTC (permalink / raw) To: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM Thanks for trying to upstream this! I just have three minor comments: On Thu, Sep 1, 2022, at 15:54, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. > > The initial RTKit backend adds support for Apple Silicon Macs (M1 et > al). We hope a backend for T2 Macs will be written in the future > (since those are not supported by applesmc), and eventually an x86 > backend would allow us to fully deprecate applesmc in favor of this > driver. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/platform/Kconfig | 2 + > drivers/platform/Makefile | 1 + > drivers/platform/apple/Kconfig | 49 ++++ > drivers/platform/apple/Makefile | 11 + > drivers/platform/apple/smc.h | 28 ++ > drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ > drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ > include/linux/mfd/macsmc.h | 86 ++++++ > 8 files changed, 877 insertions(+) > create mode 100644 drivers/platform/apple/Kconfig > create mode 100644 drivers/platform/apple/Makefile > create mode 100644 drivers/platform/apple/smc.h > create mode 100644 drivers/platform/apple/smc_core.c > create mode 100644 drivers/platform/apple/smc_rtkit.c > create mode 100644 include/linux/mfd/macsmc.h > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > index b437847b6237..5f8b9bcdb830 100644 > --- a/drivers/platform/Kconfig > +++ b/drivers/platform/Kconfig > @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" > > source "drivers/platform/surface/Kconfig" > > +source "drivers/platform/apple/Kconfig" > + > source "drivers/platform/x86/Kconfig" > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > index 4de08ef4ec9d..3e5d5039a28c 100644 > --- a/drivers/platform/Makefile > +++ b/drivers/platform/Makefile > @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ > obj-$(CONFIG_GOLDFISH) += goldfish/ > obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ > +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ > diff --git a/drivers/platform/apple/Kconfig > b/drivers/platform/apple/Kconfig > new file mode 100644 > index 000000000000..42525aa9fbbe > --- /dev/null > +++ b/drivers/platform/apple/Kconfig > @@ -0,0 +1,49 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Apple Platform-Specific Drivers > +# > + > +menuconfig APPLE_PLATFORMS > + bool "Apple Mac Platform-Specific Device Drivers" > + default y > + help > + Say Y here to get to see options for platform-specific device > drivers > + for Apple devices. This option alone does not add any kernel code. > + > + If you say N, all options in this submenu will be skipped and > disabled. > + > +if APPLE_PLATFORMS > + > +config APPLE_SMC > + tristate "Apple SMC Driver" > + depends on ARCH_APPLE || COMPILE_TEST > + default ARCH_APPLE > + select MFD_CORE > + help > + Build support for the Apple System Management Controller present in > + Apple Macs. This driver currently supports the SMC in Apple Silicon > + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc. > + > +if APPLE_SMC > + > +config APPLE_SMC_RTKIT > + tristate "RTKit (Apple Silicon) backend" > + depends on ARCH_APPLE || COMPILE_TEST > + depends on APPLE_RTKIT > + default ARCH_APPLE > + help > + Build support for SMC communications via the RTKit backend. This is > + required for Apple Silicon Macs. > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc-rtkit. > + > +endif > +endif > diff --git a/drivers/platform/apple/Makefile > b/drivers/platform/apple/Makefile > new file mode 100644 > index 000000000000..79fac195398b > --- /dev/null > +++ b/drivers/platform/apple/Makefile > @@ -0,0 +1,11 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for linux/drivers/platform/apple > +# Apple Platform-Specific Drivers > +# > + > +macsmc-y += smc_core.o > +macsmc-rtkit-y += smc_rtkit.o > + > +obj-$(CONFIG_APPLE_SMC) += macsmc.o > +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o > diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h > new file mode 100644 > index 000000000000..8ae51887b2c5 > --- /dev/null > +++ b/drivers/platform/apple/smc.h > @@ -0,0 +1,28 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC internal core definitions > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _SMC_H > +#define _SMC_H > + > +#include <linux/mfd/macsmc.h> > + > +struct apple_smc_backend_ops { > + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t > size); > + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > + int (*get_key_info)(void *cookie, smc_key key, struct > apple_smc_key_info *info); > +}; > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct > apple_smc_backend_ops *ops, > + void *cookie); > +void *apple_smc_get_cookie(struct apple_smc *smc); > +int apple_smc_remove(struct apple_smc *smc); > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > + > +#endif > diff --git a/drivers/platform/apple/smc_core.c > b/drivers/platform/apple/smc_core.c > new file mode 100644 > index 000000000000..daf029cd072f > --- /dev/null > +++ b/drivers/platform/apple/smc_core.c > @@ -0,0 +1,249 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core framework > + * Copyright The Asahi Linux Contributors > + */ > + > +#include <linux/device.h> > +#include <linux/mfd/core.h> > +#include <linux/mutex.h> > +#include <linux/notifier.h> > +#include "smc.h" > + > +struct apple_smc { > + struct device *dev; > + > + void *be_cookie; > + const struct apple_smc_backend_ops *be; > + > + struct mutex mutex; > + > + u32 key_count; > + smc_key first_key; > + smc_key last_key; > + > + struct blocking_notifier_head event_handlers; > +}; > + > +static const struct mfd_cell apple_smc_devs[] = { > + { > + .name = "macsmc-gpio", > + }, > + { > + .name = "macsmc-hid", > + }, > + { > + .name = "macsmc-power", > + }, > + { > + .name = "macsmc-reboot", > + }, > + { > + .name = "macsmc-rtc", > + }, > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, > size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->read_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_read); > + > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, > size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->write_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write); > + > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void > *buf, size_t size) > +{ > + int ret; > + > + /* > + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff > + * final calls, so it doesn't really matter at that point. > + */ > + if (!mutex_trylock(&smc->mutex)) > + return -EBUSY; > + > + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write_atomic); > + > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, > size_t wsize, > + void *rbuf, size_t rsize) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_rw); > + > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, > smc_key *key) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_by_index); > + > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct > apple_smc_key_info *info) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_info(smc->be_cookie, key, info); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_info); > + > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) > +{ > + int start = 0, count = smc->key_count; > + int ret; > + > + if (key <= smc->first_key) > + return 0; > + if (key > smc->last_key) > + return smc->key_count; > + > + while (count > 1) { > + int pivot = start + ((count - 1) >> 1); > + smc_key pkey; > + > + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); > + if (ret < 0) > + return ret; > + > + if (pkey == key) > + return pivot; > + > + pivot++; > + > + if (pkey < key) { > + count -= pivot - start; > + start = pivot; > + } else { > + count = pivot - start; > + } > + } > + > + return start; > +} > +EXPORT_SYMBOL(apple_smc_find_first_key_index); > + > +int apple_smc_get_key_count(struct apple_smc *smc) > +{ > + return smc->key_count; > +} > +EXPORT_SYMBOL(apple_smc_get_key_count); > + > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) > +{ > + dev_dbg(smc->dev, "Event: 0x%08x\n", event); > + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); > +} > +EXPORT_SYMBOL(apple_smc_event_received); > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct > notifier_block *n) > +{ > + return blocking_notifier_chain_register(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_register_notifier); > + > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct > notifier_block *n) > +{ > + return blocking_notifier_chain_unregister(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_unregister_notifier); > + > +void *apple_smc_get_cookie(struct apple_smc *smc) > +{ > + return smc->be_cookie; > +} > +EXPORT_SYMBOL(apple_smc_get_cookie); > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct > apple_smc_backend_ops *ops, void *cookie) > +{ > + struct apple_smc *smc; > + u32 count; > + int ret; > + > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > + if (!smc) > + return ERR_PTR(-ENOMEM); > + > + smc->dev = dev; > + smc->be_cookie = cookie; > + smc->be = ops; > + mutex_init(&smc->mutex); > + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); > + > + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); > + smc->key_count = be32_to_cpu(count); > + > + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); > + > + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, > &smc->last_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); > + > + /* Enable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); > + > + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", > + smc->key_count, &smc->first_key, &smc->last_key); I don't think upstream supports %p4ch. marcan added that format in our downstream tree iirc. > + > + dev_set_drvdata(dev, smc); > + > + ret = mfd_add_devices(dev, -1, apple_smc_devs, > ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization > failed")); > + > + return smc; > +} > +EXPORT_SYMBOL(apple_smc_probe); > + > +int apple_smc_remove(struct apple_smc *smc) > +{ > + mfd_remove_devices(smc->dev); > + > + /* Disable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); > + > + return 0; > +} > +EXPORT_SYMBOL(apple_smc_remove); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC core"); > diff --git a/drivers/platform/apple/smc_rtkit.c > b/drivers/platform/apple/smc_rtkit.c > new file mode 100644 > index 000000000000..5b7c4c475bbb > --- /dev/null > +++ b/drivers/platform/apple/smc_rtkit.c > @@ -0,0 +1,451 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC RTKit backend > + * Copyright The Asahi Linux Contributors > + */ > + > +#include <asm/unaligned.h> > +#include <linux/delay.h> > +#include <linux/device.h> > +#include <linux/io.h> > +#include <linux/ioport.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > +#include <linux/soc/apple/rtkit.h> > +#include "smc.h" > + > +#define SMC_ENDPOINT 0x20 > + > +/* Guess */ > +#define SMC_SHMEM_SIZE 0x1000 > + > +#define SMC_MSG_READ_KEY 0x10 > +#define SMC_MSG_WRITE_KEY 0x11 > +#define SMC_MSG_GET_KEY_BY_INDEX 0x12 > +#define SMC_MSG_GET_KEY_INFO 0x13 > +#define SMC_MSG_INITIALIZE 0x17 > +#define SMC_MSG_NOTIFICATION 0x18 > +#define SMC_MSG_RW_KEY 0x20 > + > +#define SMC_DATA GENMASK(63, 32) > +#define SMC_WSIZE GENMASK(31, 24) > +#define SMC_SIZE GENMASK(23, 16) > +#define SMC_ID GENMASK(15, 12) > +#define SMC_MSG GENMASK(7, 0) > +#define SMC_RESULT SMC_MSG > + > +#define SMC_RECV_TIMEOUT 100 > + > +struct apple_smc_rtkit { > + struct device *dev; > + struct apple_smc *core; > + struct apple_rtkit *rtk; > + > + struct completion init_done; > + bool initialized; > + bool alive; > + > + struct resource *sram; > + void __iomem *sram_base; > + struct apple_rtkit_shmem shmem; > + > + unsigned int msg_id; > + > + bool atomic_pending; > + struct completion cmd_done; > + u64 cmd_ret; > +}; > + > +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, > void *buf, size_t size) > +{ > + struct apple_smc_rtkit *smc = cookie; > + int ret; > + u64 msg; > + u8 result; > + > + if (size > SMC_SHMEM_SIZE || size == 0) > + return -EINVAL; > + > + if (!smc->alive) > + return -EIO; > + > + memcpy_toio(smc->shmem.iomem, buf, size); > + smc->msg_id = (smc->msg_id + 1) & 0xf; > + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | > + FIELD_PREP(SMC_SIZE, size) | > + FIELD_PREP(SMC_ID, smc->msg_id) | > + FIELD_PREP(SMC_DATA, key)); > + smc->atomic_pending = true; > + > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, > true); > + if (ret < 0) { > + dev_err(smc->dev, "Failed to send command (%d)\n", ret); > + return ret; > + } > + > + while (smc->atomic_pending) { > + ret = apple_rtkit_poll(smc->rtk); > + if (ret < 0) { > + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); > + return ret; > + } > + udelay(100); > + } I guess we could use try_wait_for_completion here and get rid of the special smc->atomic_pending path. Not sure if it makes the code much simpler though. > + > + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got > %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); > + return -EIO; > + } > + > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; > + > + return FIELD_GET(SMC_SIZE, smc->cmd_ret); > +} > + > +static int apple_smc_cmd(struct apple_smc_rtkit *smc, u64 cmd, u64 arg, > + u64 size, u64 wsize, u32 *ret_data) > +{ > + int ret; > + u64 msg; > + u8 result; > + > + if (!smc->alive) > + return -EIO; > + > + reinit_completion(&smc->cmd_done); > + > + smc->msg_id = (smc->msg_id + 1) & 0xf; > + msg = (FIELD_PREP(SMC_MSG, cmd) | > + FIELD_PREP(SMC_SIZE, size) | > + FIELD_PREP(SMC_WSIZE, wsize) | > + FIELD_PREP(SMC_ID, smc->msg_id) | > + FIELD_PREP(SMC_DATA, arg)); > + > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, > false); > + if (ret < 0) { > + dev_err(smc->dev, "Failed to send command\n"); > + return ret; > + } > + > + do { > + if (wait_for_completion_timeout(&smc->cmd_done, > + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { > + dev_err(smc->dev, "Command timed out (%llx)", msg); > + return -ETIMEDOUT; > + } > + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) > + break; > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got > %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); > + } while(1); > + > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; > + > + if (ret_data) > + *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); > + > + return FIELD_GET(SMC_SIZE, smc->cmd_ret); > +} > + > +static int _apple_smc_rtkit_read_key(struct apple_smc_rtkit *smc, > smc_key key, > + void *buf, size_t size, size_t wsize) > +{ > + int ret; > + u32 rdata; > + u64 cmd; > + > + if (size > SMC_SHMEM_SIZE || size == 0) > + return -EINVAL; > + > + cmd = wsize ? SMC_MSG_RW_KEY : SMC_MSG_READ_KEY; > + > + ret = apple_smc_cmd(smc, cmd, key, size, wsize, &rdata); > + if (ret < 0) > + return ret; > + > + if (size <= 4) > + memcpy(buf, &rdata, size); > + else > + memcpy_fromio(buf, smc->shmem.iomem, size); > + > + return ret; > +} > + > +static int apple_smc_rtkit_read_key(void *cookie, smc_key key, void > *buf, size_t size) > +{ > + return _apple_smc_rtkit_read_key(cookie, key, buf, size, 0); > +} > + > +static int apple_smc_rtkit_write_key(void *cookie, smc_key key, void > *buf, size_t size) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (size > SMC_SHMEM_SIZE || size == 0) > + return -EINVAL; > + > + memcpy_toio(smc->shmem.iomem, buf, size); > + return apple_smc_cmd(smc, SMC_MSG_WRITE_KEY, key, size, 0, NULL); > +} > + > +static int apple_smc_rtkit_rw_key(void *cookie, smc_key key, > + void *wbuf, size_t wsize, void *rbuf, size_t rsize) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (wsize > SMC_SHMEM_SIZE || wsize == 0) > + return -EINVAL; > + > + memcpy_toio(smc->shmem.iomem, wbuf, wsize); > + return _apple_smc_rtkit_read_key(smc, key, rbuf, rsize, wsize); > +} > + > +static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, > smc_key *key) > +{ > + struct apple_smc_rtkit *smc = cookie; > + int ret; > + > + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); > + > + *key = swab32(*key); > + return ret; > +} > + > +static int apple_smc_rtkit_get_key_info(void *cookie, smc_key key, > struct apple_smc_key_info *info) > +{ > + struct apple_smc_rtkit *smc = cookie; > + u8 key_info[6]; > + int ret; > + > + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_INFO, key, 0, 0, NULL); > + if (ret >= 0 && info) { > + info->size = key_info[0]; > + info->type_code = get_unaligned_be32(&key_info[1]); > + info->flags = key_info[5]; > + } > + return ret; > +} > + > +static const struct apple_smc_backend_ops apple_smc_rtkit_be_ops = { > + .read_key = apple_smc_rtkit_read_key, > + .write_key = apple_smc_rtkit_write_key, > + .write_key_atomic = apple_smc_rtkit_write_key_atomic, > + .rw_key = apple_smc_rtkit_rw_key, > + .get_key_by_index = apple_smc_rtkit_get_key_by_index, > + .get_key_info = apple_smc_rtkit_get_key_info, > +}; > + > +static void apple_smc_rtkit_crashed(void *cookie) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + dev_err(smc->dev, "SMC crashed! Your system will reboot in a few > seconds...\n"); > + smc->alive = false; > +} > + > +static int apple_smc_rtkit_shmem_setup(void *cookie, struct > apple_rtkit_shmem *bfr) > +{ > + struct apple_smc_rtkit *smc = cookie; > + struct resource res = { > + .start = bfr->iova, > + .end = bfr->iova + bfr->size - 1, > + .name = "rtkit_map", > + .flags = smc->sram->flags, > + }; > + > + if (!bfr->iova) { > + dev_err(smc->dev, "RTKit wants a RAM buffer\n"); > + return -EIO; > + } > + > + if (res.end < res.start || !resource_contains(smc->sram, &res)) { > + dev_err(smc->dev, > + "RTKit buffer request outside SRAM region: %pR", &res); > + return -EFAULT; > + } > + > + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); > + bfr->is_mapped = true; > + > + return 0; > +} > + > +static void apple_smc_rtkit_shmem_destroy(void *cookie, struct > apple_rtkit_shmem *bfr) > +{ > + // no-op > +} > + > +static bool apple_smc_rtkit_recv_early(void *cookie, u8 endpoint, u64 > message) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (endpoint != SMC_ENDPOINT) { > + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", > endpoint); > + return false; > + } > + > + if (!smc->initialized) { > + int ret; > + > + smc->shmem.iova = message; > + smc->shmem.size = SMC_SHMEM_SIZE; > + ret = apple_smc_rtkit_shmem_setup(smc, &smc->shmem); > + if (ret < 0) > + dev_err(smc->dev, "Failed to initialize shared memory\n"); > + else > + smc->alive = true; > + smc->initialized = true; > + complete(&smc->init_done); > + } else if (FIELD_GET(SMC_MSG, message) == SMC_MSG_NOTIFICATION) { > + /* Handle these in the RTKit worker thread */ > + return false; > + } else { > + smc->cmd_ret = message; > + if (smc->atomic_pending) { > + smc->atomic_pending = false; > + } else { > + complete(&smc->cmd_done); > + } > + } > + > + return true; > +} > + > +static void apple_smc_rtkit_recv(void *cookie, u8 endpoint, u64 > message) > +{ > + struct apple_smc_rtkit *smc = cookie; > + > + if (endpoint != SMC_ENDPOINT) { > + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", > endpoint); > + return; > + } > + > + if (FIELD_GET(SMC_MSG, message) != SMC_MSG_NOTIFICATION) { > + dev_err(smc->dev, "Received unknown message from worker: 0x%llx\n", > message); > + return; > + } > + > + apple_smc_event_received(smc->core, FIELD_GET(SMC_DATA, message)); > +} > + > +static const struct apple_rtkit_ops apple_smc_rtkit_ops = { > + .crashed = apple_smc_rtkit_crashed, > + .recv_message = apple_smc_rtkit_recv, > + .recv_message_early = apple_smc_rtkit_recv_early, > + .shmem_setup = apple_smc_rtkit_shmem_setup, > + .shmem_destroy = apple_smc_rtkit_shmem_destroy, > +}; > + > +static int apple_smc_rtkit_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct apple_smc_rtkit *smc; > + int ret; > + > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > + if (!smc) > + return -ENOMEM; > + > + smc->dev = dev; > + > + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, > "sram"); > + if (!smc->sram) > + return dev_err_probe(dev, EIO, > + "No SRAM region"); > + > + smc->sram_base = devm_ioremap_resource(dev, smc->sram); > + if (IS_ERR(smc->sram_base)) > + return dev_err_probe(dev, PTR_ERR(smc->sram_base), > + "Failed to map SRAM region"); > + > + smc->rtk = > + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); > + if (IS_ERR(smc->rtk)) > + return dev_err_probe(dev, PTR_ERR(smc->rtk), > + "Failed to intialize RTKit"); > + > + ret = apple_rtkit_wake(smc->rtk); > + if (ret != 0) > + return dev_err_probe(dev, ret, > + "Failed to wake up SMC"); > + > + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); > + if (ret != 0) { > + dev_err(dev, "Failed to start endpoint"); > + goto cleanup; > + } > + > + init_completion(&smc->init_done); > + init_completion(&smc->cmd_done); > + > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, > + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); > + if (ret < 0) > + return dev_err_probe(dev, ret, > + "Failed to send init message"); This should probably also "goto cleanup" here just in case we somehow manage to send the shutdown message after this one failed. > + > + if (wait_for_completion_timeout(&smc->init_done, > + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { > + ret = -ETIMEDOUT; > + dev_err(dev, "Timed out initializing SMC"); > + goto cleanup; > + } > + > + if (!smc->alive) { > + ret = -EIO; > + goto cleanup; > + } > + > + smc->core = apple_smc_probe(dev, &apple_smc_rtkit_be_ops, smc); > + if (IS_ERR(smc->core)) { > + ret = PTR_ERR(smc->core); > + goto cleanup; > + } > + > + return 0; > + > +cleanup: > + /* Try to shut down RTKit, if it's not completely wedged */ > + if (apple_rtkit_is_running(smc->rtk)) > + apple_rtkit_quiesce(smc->rtk); > + > + return ret; > +} > + > +static int apple_smc_rtkit_remove(struct platform_device *pdev) > +{ > + struct apple_smc *core = platform_get_drvdata(pdev); > + struct apple_smc_rtkit *smc = apple_smc_get_cookie(core); > + > + apple_smc_remove(core); > + > + if (apple_rtkit_is_running(smc->rtk)) > + apple_rtkit_quiesce(smc->rtk); > + > + return 0; > +} > + > +static const struct of_device_id apple_smc_rtkit_of_match[] = { > + { .compatible = "apple,smc" }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, apple_smc_rtkit_of_match); > + > +static struct platform_driver apple_smc_rtkit_driver = { > + .driver = { > + .name = "macsmc-rtkit", > + .owner = THIS_MODULE, > + .of_match_table = apple_smc_rtkit_of_match, > + }, > + .probe = apple_smc_rtkit_probe, > + .remove = apple_smc_rtkit_remove, > +}; > +module_platform_driver(apple_smc_rtkit_driver); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC RTKit backend driver"); > diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h > new file mode 100644 > index 000000000000..39b4dc4ca881 > --- /dev/null > +++ b/include/linux/mfd/macsmc.h > @@ -0,0 +1,86 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core definitions > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _LINUX_MFD_MACSMC_H > +#define _LINUX_MFD_MACSMC_H > + > +struct apple_smc; > + > +typedef u32 smc_key; > + > +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) > +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | > (s)[3]) > + > +#define APPLE_SMC_READABLE BIT(7) > +#define APPLE_SMC_WRITABLE BIT(6) > +#define APPLE_SMC_FUNCTION BIT(4) > + > +struct apple_smc_key_info { > + u8 size; > + u32 type_code; > + u8 flags; > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, > size_t size); > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, > size_t size); > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void > *buf, size_t size); > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, > size_t wsize, > + void *rbuf, size_t rsize); > + > +int apple_smc_get_key_count(struct apple_smc *smc); > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, > smc_key *key); > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct > apple_smc_key_info *info); > + > +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key > key) > +{ > + return apple_smc_get_key_info(smc, key, NULL) >= 0; > +} > + > +#define APPLE_SMC_TYPE_OPS(type) \ > + static inline int apple_smc_read_##type(struct apple_smc *smc, > smc_key key, type *p) \ > + { \ > + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ > + } \ > + static inline int apple_smc_write_##type(struct apple_smc *smc, > smc_key key, type p) \ > + { \ > + return apple_smc_write(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_write_##type##_atomic(struct apple_smc > *smc, smc_key key, type p) \ > + { \ > + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key > key, \ > + type w, type *r) \ > + { \ > + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ > + } > + > +APPLE_SMC_TYPE_OPS(u64) > +APPLE_SMC_TYPE_OPS(u32) > +APPLE_SMC_TYPE_OPS(u16) > +APPLE_SMC_TYPE_OPS(u8) > +APPLE_SMC_TYPE_OPS(s64) > +APPLE_SMC_TYPE_OPS(s32) > +APPLE_SMC_TYPE_OPS(s16) > +APPLE_SMC_TYPE_OPS(s8) > + > +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key > key) > +{ > + u8 val; > + int ret = apple_smc_read_u8(smc, key, &val); > + if (ret < 0) > + return ret; > + return val ? 1 : 0; > +} > +#define apple_smc_write_flag apple_smc_write_u8 > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct > notifier_block *n); > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct > notifier_block *n); > + > +#endif > -- > 2.30.2 Sven _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 17:50 ` Sven Peter @ 2022-09-05 10:55 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 10:55 UTC (permalink / raw) To: Sven Peter Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM On Thu, Sep 01, 2022 at 07:50:31PM +0200, Sven Peter wrote: > Thanks for trying to upstream this! > I just have three minor comments: > > On Thu, Sep 1, 2022, at 15:54, Russell King wrote: > > + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", > > + smc->key_count, &smc->first_key, &smc->last_key); > > I don't think upstream supports %p4ch. marcan added that format in our downstream > tree iirc. Before that can be resolved, we need the discussion about how to deal with SMC keys to be resolved. Andy was suggesting using the endian conversion macros in the GPIO driver to convert the hex XX value in the gPXX keys which doesn't sound right. If we changed the smc_key typedef to something like: typedef struct { char s[4]; } smc_key; Then we can safely print them using %.4s. We can also pass: key.s + 2 to hex2bin() since it will be in the correct order. We may need to do some fixups when placing the key in the SMC messages. If I'm reading the smc_rtkit code correctly, then apple_smc_rtkit_get_key_by_index() swabs the returned key from the SMC, but when we pass keys to the SMC, we don't swab them? So keys to the SMC are in reverse byte order compared to the natural string, but keys returned from the SMC are in conventional byte order for a string? Is that right, or am I getting confused? What I mean is that for a key ABCD, it's passed to the SMC as A in bits 63..56, B in 55..48, C in 47..40, D in 39..32. When we receive a key, A is in bits 7..0, B in bits 15..8, C in bits 23..16 and D in 31..24? > > +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, > > void *buf, size_t size) > > +{ > > + struct apple_smc_rtkit *smc = cookie; > > + int ret; > > + u64 msg; > > + u8 result; > > + > > + if (size > SMC_SHMEM_SIZE || size == 0) > > + return -EINVAL; > > + > > + if (!smc->alive) > > + return -EIO; > > + > > + memcpy_toio(smc->shmem.iomem, buf, size); > > + smc->msg_id = (smc->msg_id + 1) & 0xf; > > + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | > > + FIELD_PREP(SMC_SIZE, size) | > > + FIELD_PREP(SMC_ID, smc->msg_id) | > > + FIELD_PREP(SMC_DATA, key)); > > + smc->atomic_pending = true; > > + > > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, > > true); > > + if (ret < 0) { > > + dev_err(smc->dev, "Failed to send command (%d)\n", ret); > > + return ret; > > + } > > + > > + while (smc->atomic_pending) { > > + ret = apple_rtkit_poll(smc->rtk); > > + if (ret < 0) { > > + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); > > + return ret; > > + } > > + udelay(100); > > + } > > I guess we could use try_wait_for_completion here and get rid of the special > smc->atomic_pending path. Not sure if it makes the code much simpler though. Delving into this, it seems this code is buggy. If apple_smc_rtkit_write_key_atomic() is used from atomic contexts, what prevents apple_smc_rtkit_write_key_atomic() being called while apple_smc_rtkit_write_key() is executing? Both these functions copy data to smc->shmem.iomem, so a call to the atomic function will overwrite the non-atomic function's data. Given that there doesn't seem to be a way to specify the offset of the data in shmem to the SMC, are we sure that we can sensibly support an atomic write operation? Using try_wait_for_completion() just ends up destroying more context in the non-atomic path. In any case, how can we be sure that the call to apple_smc_rtkit_recv_early() was really meant to complete the atomic write as opposed to something else? I guess that would trigger a "Command sequence mismatch" and an EIO error if it happens. Have these occurred? Lastly: #define SMC_SHMEM_SIZE 0x1000 #define SMC_WSIZE GENMASK(31, 24) #define SMC_SIZE GENMASK(23, 16) The size fields are one byte, but we error out if the size is larger than the shmem size: if (size > SMC_SHMEM_SIZE || size == 0) return -EINVAL; but we still try to squeeze the size into this byte-wide field: FIELD_PREP(SMC_SIZE, size) | which isn't goint to work. If the size is limited by the protocol to 255 bytes (or is it 256, where 0 means 256?) then surely we should be erroring out if size is above that maximum rather than the shmem size. > > +static int apple_smc_rtkit_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct apple_smc_rtkit *smc; > > + int ret; > > + > > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > > + if (!smc) > > + return -ENOMEM; > > + > > + smc->dev = dev; > > + > > + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, > > "sram"); > > + if (!smc->sram) > > + return dev_err_probe(dev, EIO, > > + "No SRAM region"); > > + > > + smc->sram_base = devm_ioremap_resource(dev, smc->sram); > > + if (IS_ERR(smc->sram_base)) > > + return dev_err_probe(dev, PTR_ERR(smc->sram_base), > > + "Failed to map SRAM region"); > > + > > + smc->rtk = > > + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); > > + if (IS_ERR(smc->rtk)) > > + return dev_err_probe(dev, PTR_ERR(smc->rtk), > > + "Failed to intialize RTKit"); > > + > > + ret = apple_rtkit_wake(smc->rtk); > > + if (ret != 0) > > + return dev_err_probe(dev, ret, > > + "Failed to wake up SMC"); > > + > > + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); > > + if (ret != 0) { > > + dev_err(dev, "Failed to start endpoint"); > > + goto cleanup; > > + } > > + > > + init_completion(&smc->init_done); > > + init_completion(&smc->cmd_done); > > + > > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, > > + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); > > + if (ret < 0) > > + return dev_err_probe(dev, ret, > > + "Failed to send init message"); > > This should probably also "goto cleanup" here just in case we somehow manage to > send the shutdown message after this one failed. Good point, thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-05 10:55 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 10:55 UTC (permalink / raw) To: Sven Peter Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM On Thu, Sep 01, 2022 at 07:50:31PM +0200, Sven Peter wrote: > Thanks for trying to upstream this! > I just have three minor comments: > > On Thu, Sep 1, 2022, at 15:54, Russell King wrote: > > + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", > > + smc->key_count, &smc->first_key, &smc->last_key); > > I don't think upstream supports %p4ch. marcan added that format in our downstream > tree iirc. Before that can be resolved, we need the discussion about how to deal with SMC keys to be resolved. Andy was suggesting using the endian conversion macros in the GPIO driver to convert the hex XX value in the gPXX keys which doesn't sound right. If we changed the smc_key typedef to something like: typedef struct { char s[4]; } smc_key; Then we can safely print them using %.4s. We can also pass: key.s + 2 to hex2bin() since it will be in the correct order. We may need to do some fixups when placing the key in the SMC messages. If I'm reading the smc_rtkit code correctly, then apple_smc_rtkit_get_key_by_index() swabs the returned key from the SMC, but when we pass keys to the SMC, we don't swab them? So keys to the SMC are in reverse byte order compared to the natural string, but keys returned from the SMC are in conventional byte order for a string? Is that right, or am I getting confused? What I mean is that for a key ABCD, it's passed to the SMC as A in bits 63..56, B in 55..48, C in 47..40, D in 39..32. When we receive a key, A is in bits 7..0, B in bits 15..8, C in bits 23..16 and D in 31..24? > > +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, > > void *buf, size_t size) > > +{ > > + struct apple_smc_rtkit *smc = cookie; > > + int ret; > > + u64 msg; > > + u8 result; > > + > > + if (size > SMC_SHMEM_SIZE || size == 0) > > + return -EINVAL; > > + > > + if (!smc->alive) > > + return -EIO; > > + > > + memcpy_toio(smc->shmem.iomem, buf, size); > > + smc->msg_id = (smc->msg_id + 1) & 0xf; > > + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | > > + FIELD_PREP(SMC_SIZE, size) | > > + FIELD_PREP(SMC_ID, smc->msg_id) | > > + FIELD_PREP(SMC_DATA, key)); > > + smc->atomic_pending = true; > > + > > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, > > true); > > + if (ret < 0) { > > + dev_err(smc->dev, "Failed to send command (%d)\n", ret); > > + return ret; > > + } > > + > > + while (smc->atomic_pending) { > > + ret = apple_rtkit_poll(smc->rtk); > > + if (ret < 0) { > > + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); > > + return ret; > > + } > > + udelay(100); > > + } > > I guess we could use try_wait_for_completion here and get rid of the special > smc->atomic_pending path. Not sure if it makes the code much simpler though. Delving into this, it seems this code is buggy. If apple_smc_rtkit_write_key_atomic() is used from atomic contexts, what prevents apple_smc_rtkit_write_key_atomic() being called while apple_smc_rtkit_write_key() is executing? Both these functions copy data to smc->shmem.iomem, so a call to the atomic function will overwrite the non-atomic function's data. Given that there doesn't seem to be a way to specify the offset of the data in shmem to the SMC, are we sure that we can sensibly support an atomic write operation? Using try_wait_for_completion() just ends up destroying more context in the non-atomic path. In any case, how can we be sure that the call to apple_smc_rtkit_recv_early() was really meant to complete the atomic write as opposed to something else? I guess that would trigger a "Command sequence mismatch" and an EIO error if it happens. Have these occurred? Lastly: #define SMC_SHMEM_SIZE 0x1000 #define SMC_WSIZE GENMASK(31, 24) #define SMC_SIZE GENMASK(23, 16) The size fields are one byte, but we error out if the size is larger than the shmem size: if (size > SMC_SHMEM_SIZE || size == 0) return -EINVAL; but we still try to squeeze the size into this byte-wide field: FIELD_PREP(SMC_SIZE, size) | which isn't goint to work. If the size is limited by the protocol to 255 bytes (or is it 256, where 0 means 256?) then surely we should be erroring out if size is above that maximum rather than the shmem size. > > +static int apple_smc_rtkit_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct apple_smc_rtkit *smc; > > + int ret; > > + > > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > > + if (!smc) > > + return -ENOMEM; > > + > > + smc->dev = dev; > > + > > + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, > > "sram"); > > + if (!smc->sram) > > + return dev_err_probe(dev, EIO, > > + "No SRAM region"); > > + > > + smc->sram_base = devm_ioremap_resource(dev, smc->sram); > > + if (IS_ERR(smc->sram_base)) > > + return dev_err_probe(dev, PTR_ERR(smc->sram_base), > > + "Failed to map SRAM region"); > > + > > + smc->rtk = > > + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); > > + if (IS_ERR(smc->rtk)) > > + return dev_err_probe(dev, PTR_ERR(smc->rtk), > > + "Failed to intialize RTKit"); > > + > > + ret = apple_rtkit_wake(smc->rtk); > > + if (ret != 0) > > + return dev_err_probe(dev, ret, > > + "Failed to wake up SMC"); > > + > > + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); > > + if (ret != 0) { > > + dev_err(dev, "Failed to start endpoint"); > > + goto cleanup; > > + } > > + > > + init_completion(&smc->init_done); > > + init_completion(&smc->cmd_done); > > + > > + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, > > + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); > > + if (ret < 0) > > + return dev_err_probe(dev, ret, > > + "Failed to send init message"); > > This should probably also "goto cleanup" here just in case we somehow manage to > send the shutdown message after this one failed. Good point, thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-05 10:55 ` Russell King (Oracle) @ 2022-09-05 16:53 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 16:53 UTC (permalink / raw) To: Russell King (Oracle), Sven Peter Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, open list:GPIO SUBSYSTEM On 05/09/2022 19.55, Russell King (Oracle) wrote: > Delving into this, it seems this code is buggy. > > If apple_smc_rtkit_write_key_atomic() is used from atomic contexts, > what prevents apple_smc_rtkit_write_key_atomic() being called while > apple_smc_rtkit_write_key() is executing? This does: > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + /* > + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff > + * final calls, so it doesn't really matter at that point. > + */ > + if (!mutex_trylock(&smc->mutex)) > + return -EBUSY; > + > + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write_atomic); I tried making this actually work properly while I was considering using the atomic call in non-shutdown contexts, but gave up - it gets very hairy, and is probably impossible under the premise that the atomic side can always block on the non-atomic side and end up deadlocking due to the nature of things. But right now, since this is only ever used for final shutdown, there is no contention possible. The mutex_trylock there is a safety, in case someone tries using this in some other context, that will just bail if there is contention with non-atomic acesses. Maybe there should be a warning there, something like "SMC: contention between atomic accesses and non-atomic accesses is not supported". > Lastly: > > #define SMC_SHMEM_SIZE 0x1000 > > #define SMC_WSIZE GENMASK(31, 24) > #define SMC_SIZE GENMASK(23, 16) > > The size fields are one byte, but we error out if the size is larger > than the shmem size: > > if (size > SMC_SHMEM_SIZE || size == 0) > return -EINVAL; > > but we still try to squeeze the size into this byte-wide field: > > FIELD_PREP(SMC_SIZE, size) | > > which isn't goint to work. If the size is limited by the protocol to > 255 bytes (or is it 256, where 0 means 256?) then surely we should be > erroring out if size is above that maximum rather than the shmem size. Good point, this should be 255 bytes max. *checks* Yeah, the longest SMC key we have in practice is 120 bytes, so let's just #define SMC_MAX_SIZE 255 or something like that. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-05 16:53 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 16:53 UTC (permalink / raw) To: Russell King (Oracle), Sven Peter Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, open list:GPIO SUBSYSTEM On 05/09/2022 19.55, Russell King (Oracle) wrote: > Delving into this, it seems this code is buggy. > > If apple_smc_rtkit_write_key_atomic() is used from atomic contexts, > what prevents apple_smc_rtkit_write_key_atomic() being called while > apple_smc_rtkit_write_key() is executing? This does: > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + /* > + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff > + * final calls, so it doesn't really matter at that point. > + */ > + if (!mutex_trylock(&smc->mutex)) > + return -EBUSY; > + > + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write_atomic); I tried making this actually work properly while I was considering using the atomic call in non-shutdown contexts, but gave up - it gets very hairy, and is probably impossible under the premise that the atomic side can always block on the non-atomic side and end up deadlocking due to the nature of things. But right now, since this is only ever used for final shutdown, there is no contention possible. The mutex_trylock there is a safety, in case someone tries using this in some other context, that will just bail if there is contention with non-atomic acesses. Maybe there should be a warning there, something like "SMC: contention between atomic accesses and non-atomic accesses is not supported". > Lastly: > > #define SMC_SHMEM_SIZE 0x1000 > > #define SMC_WSIZE GENMASK(31, 24) > #define SMC_SIZE GENMASK(23, 16) > > The size fields are one byte, but we error out if the size is larger > than the shmem size: > > if (size > SMC_SHMEM_SIZE || size == 0) > return -EINVAL; > > but we still try to squeeze the size into this byte-wide field: > > FIELD_PREP(SMC_SIZE, size) | > > which isn't goint to work. If the size is limited by the protocol to > 255 bytes (or is it 256, where 0 means 256?) then surely we should be > erroring out if size is above that maximum rather than the shmem size. Good point, this should be 255 bytes max. *checks* Yeah, the longest SMC key we have in practice is 120 bytes, so let's just #define SMC_MAX_SIZE 255 or something like that. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 13:54 ` Russell King @ 2022-09-01 19:26 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-01 19:26 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. > > The initial RTKit backend adds support for Apple Silicon Macs (M1 et > al). We hope a backend for T2 Macs will be written in the future > (since those are not supported by applesmc), and eventually an x86 > backend would allow us to fully deprecate applesmc in favor of this > driver. ... > drivers/platform/Kconfig | 2 + > drivers/platform/Makefile | 1 + > drivers/platform/apple/Kconfig | 49 ++++ > drivers/platform/apple/Makefile | 11 + Are you going to collect the code from, e.g., PDx86 which supports some apple devices here? ... > +EXPORT_SYMBOL(apple_smc_read); Can you from day 1 make it a namespaced variant? Ditto for the rest of the exported stuff. ... > +#include <asm/unaligned.h> Usually we put asm/* after linux/*. Missed bits.h. > +#include <linux/delay.h> > +#include <linux/device.h> > +#include <linux/io.h> > +#include <linux/ioport.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > +#include <linux/soc/apple/rtkit.h> ... > + smc->msg_id = (smc->msg_id + 1) & 0xf; % 16 will tell much cleaner of the purpose, no? ... > + while (smc->atomic_pending) { > + ret = apple_rtkit_poll(smc->rtk); > + if (ret < 0) { > + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); > + return ret; > + } > + udelay(100); > + } Something from iopoll.h to be utilised? ... > + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); Why casting? > + return -EIO; > + } ... > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; And this is in Linux error numbering space?! ... > + smc->msg_id = (smc->msg_id + 1) & 0xf; See above. Perhaps you need a macro / inline helper for this to avoid dups. ... > + do { > + if (wait_for_completion_timeout(&smc->cmd_done, > + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { > + dev_err(smc->dev, "Command timed out (%llx)", msg); > + return -ETIMEDOUT; > + } > + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) > + break; > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); Guaranteed to flood the logs... > + } while(1); ...with such a conditional. ... > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; Linux error numbering space? ... > + if (size <= 4) > + memcpy(buf, &rdata, size); > + else > + memcpy_fromio(buf, smc->shmem.iomem, size); This is unclear why plain memcpy() for the small size and what are the side effects of the memory. Maybe you wanted memremap() instead of ioremap() to begin with? ... > + *key = swab32(*key); swab32s() ... > + if (res.end < res.start || !resource_contains(smc->sram, &res)) { Is it a reimplementation of something like resource_intersect() and Co? > + dev_err(smc->dev, > + "RTKit buffer request outside SRAM region: %pR", &res); > + return -EFAULT; > + } ... > + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); Isn't it better to write as res.start + (base - start) ? ... > + if (smc->atomic_pending) { > + smc->atomic_pending = false; > + } else { > + complete(&smc->cmd_done); > + } Redundant {} in both cases. ... > + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); > + if (!smc->sram) > + return dev_err_probe(dev, EIO, > + "No SRAM region"); Dup, the below does this message for you. > + smc->sram_base = devm_ioremap_resource(dev, smc->sram); > + if (IS_ERR(smc->sram_base)) > + return dev_err_probe(dev, PTR_ERR(smc->sram_base), > + "Failed to map SRAM region"); Don't we have devm_platform_ioremap_resource_byname() ? ... > + ret = apple_rtkit_wake(smc->rtk); > + if (ret != 0) Drop all these ' != 0' > + return dev_err_probe(dev, ret, > + "Failed to wake up SMC"); Why not on one line? ... > +static const struct of_device_id apple_smc_rtkit_of_match[] = { > + { .compatible = "apple,smc" }, > + {}, No comma for the terminator entry. > +}; ... > +static struct platform_driver apple_smc_rtkit_driver = { > + .driver = { > + .name = "macsmc-rtkit", > + .owner = THIS_MODULE, Unneeded dup. > + .of_match_table = apple_smc_rtkit_of_match, > + }, > + .probe = apple_smc_rtkit_probe, > + .remove = apple_smc_rtkit_remove, > +}; ... > +typedef u32 smc_key; Why?! ... > +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) If s is a byte buffer, the above is NIH get_unaligned_be32(). Or in case of alignment be32_to_cpu() with respective type (__be32) to be used. ... > +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) > +{ > + u8 val; > + int ret = apple_smc_read_u8(smc, key, &val); Split assignment and definition. > + if (ret < 0) > + return ret; > + return val ? 1 : 0; > +} ... > +#define apple_smc_write_flag apple_smc_write_u8 Why is it needed? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-01 19:26 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-01 19:26 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. > > The initial RTKit backend adds support for Apple Silicon Macs (M1 et > al). We hope a backend for T2 Macs will be written in the future > (since those are not supported by applesmc), and eventually an x86 > backend would allow us to fully deprecate applesmc in favor of this > driver. ... > drivers/platform/Kconfig | 2 + > drivers/platform/Makefile | 1 + > drivers/platform/apple/Kconfig | 49 ++++ > drivers/platform/apple/Makefile | 11 + Are you going to collect the code from, e.g., PDx86 which supports some apple devices here? ... > +EXPORT_SYMBOL(apple_smc_read); Can you from day 1 make it a namespaced variant? Ditto for the rest of the exported stuff. ... > +#include <asm/unaligned.h> Usually we put asm/* after linux/*. Missed bits.h. > +#include <linux/delay.h> > +#include <linux/device.h> > +#include <linux/io.h> > +#include <linux/ioport.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > +#include <linux/soc/apple/rtkit.h> ... > + smc->msg_id = (smc->msg_id + 1) & 0xf; % 16 will tell much cleaner of the purpose, no? ... > + while (smc->atomic_pending) { > + ret = apple_rtkit_poll(smc->rtk); > + if (ret < 0) { > + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); > + return ret; > + } > + udelay(100); > + } Something from iopoll.h to be utilised? ... > + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); Why casting? > + return -EIO; > + } ... > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; And this is in Linux error numbering space?! ... > + smc->msg_id = (smc->msg_id + 1) & 0xf; See above. Perhaps you need a macro / inline helper for this to avoid dups. ... > + do { > + if (wait_for_completion_timeout(&smc->cmd_done, > + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { > + dev_err(smc->dev, "Command timed out (%llx)", msg); > + return -ETIMEDOUT; > + } > + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) > + break; > + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", > + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); Guaranteed to flood the logs... > + } while(1); ...with such a conditional. ... > + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); > + if (result != 0) > + return -result; Linux error numbering space? ... > + if (size <= 4) > + memcpy(buf, &rdata, size); > + else > + memcpy_fromio(buf, smc->shmem.iomem, size); This is unclear why plain memcpy() for the small size and what are the side effects of the memory. Maybe you wanted memremap() instead of ioremap() to begin with? ... > + *key = swab32(*key); swab32s() ... > + if (res.end < res.start || !resource_contains(smc->sram, &res)) { Is it a reimplementation of something like resource_intersect() and Co? > + dev_err(smc->dev, > + "RTKit buffer request outside SRAM region: %pR", &res); > + return -EFAULT; > + } ... > + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); Isn't it better to write as res.start + (base - start) ? ... > + if (smc->atomic_pending) { > + smc->atomic_pending = false; > + } else { > + complete(&smc->cmd_done); > + } Redundant {} in both cases. ... > + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); > + if (!smc->sram) > + return dev_err_probe(dev, EIO, > + "No SRAM region"); Dup, the below does this message for you. > + smc->sram_base = devm_ioremap_resource(dev, smc->sram); > + if (IS_ERR(smc->sram_base)) > + return dev_err_probe(dev, PTR_ERR(smc->sram_base), > + "Failed to map SRAM region"); Don't we have devm_platform_ioremap_resource_byname() ? ... > + ret = apple_rtkit_wake(smc->rtk); > + if (ret != 0) Drop all these ' != 0' > + return dev_err_probe(dev, ret, > + "Failed to wake up SMC"); Why not on one line? ... > +static const struct of_device_id apple_smc_rtkit_of_match[] = { > + { .compatible = "apple,smc" }, > + {}, No comma for the terminator entry. > +}; ... > +static struct platform_driver apple_smc_rtkit_driver = { > + .driver = { > + .name = "macsmc-rtkit", > + .owner = THIS_MODULE, Unneeded dup. > + .of_match_table = apple_smc_rtkit_of_match, > + }, > + .probe = apple_smc_rtkit_probe, > + .remove = apple_smc_rtkit_remove, > +}; ... > +typedef u32 smc_key; Why?! ... > +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) If s is a byte buffer, the above is NIH get_unaligned_be32(). Or in case of alignment be32_to_cpu() with respective type (__be32) to be used. ... > +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) > +{ > + u8 val; > + int ret = apple_smc_read_u8(smc, key, &val); Split assignment and definition. > + if (ret < 0) > + return ret; > + return val ? 1 : 0; > +} ... > +#define apple_smc_write_flag apple_smc_write_u8 Why is it needed? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 19:26 ` Andy Shevchenko @ 2022-09-02 6:45 ` Sven Peter -1 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-02 6:45 UTC (permalink / raw) To: Andy Shevchenko, Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM On Thu, Sep 1, 2022, at 21:26, Andy Shevchenko wrote: > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: [...] > > ... > >> + if (size <= 4) >> + memcpy(buf, &rdata, size); >> + else >> + memcpy_fromio(buf, smc->shmem.iomem, size); > > This is unclear why plain memcpy() for the small size and what are the > side effects of the memory. Maybe you wanted memremap() instead of > ioremap() to begin with? rdata is used for small buffers, comes directly as part of a message sent on the underlying hardware FIFO and is on the stack (and thus mapped as as Normal memory) while smc->shmem.iomem has to be Device-nGnRnE. Mapping it with any other attributes will generate SErrors for each access. Sven ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-02 6:45 ` Sven Peter 0 siblings, 0 replies; 342+ messages in thread From: Sven Peter @ 2022-09-02 6:45 UTC (permalink / raw) To: Andy Shevchenko, Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM On Thu, Sep 1, 2022, at 21:26, Andy Shevchenko wrote: > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: [...] > > ... > >> + if (size <= 4) >> + memcpy(buf, &rdata, size); >> + else >> + memcpy_fromio(buf, smc->shmem.iomem, size); > > This is unclear why plain memcpy() for the small size and what are the > side effects of the memory. Maybe you wanted memremap() instead of > ioremap() to begin with? rdata is used for small buffers, comes directly as part of a message sent on the underlying hardware FIFO and is on the stack (and thus mapped as as Normal memory) while smc->shmem.iomem has to be Device-nGnRnE. Mapping it with any other attributes will generate SErrors for each access. Sven _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 19:26 ` Andy Shevchenko @ 2022-09-05 14:45 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 14:45 UTC (permalink / raw) To: Andy Shevchenko, Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 02/09/2022 04.26, Andy Shevchenko wrote: > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: >> >> From: Hector Martin <marcan@marcan.st> >> >> This driver implements support for the SMC (System Management >> Controller) in Apple Macs. In contrast to the existing applesmc driver, >> it uses pluggable backends that allow it to support different SMC >> implementations, and uses the MFD subsystem to expose the core SMC >> functionality so that specific features (gpio, hwmon, battery, etc.) can >> be implemented by separate drivers in their respective downstream >> subsystems. >> >> The initial RTKit backend adds support for Apple Silicon Macs (M1 et >> al). We hope a backend for T2 Macs will be written in the future >> (since those are not supported by applesmc), and eventually an x86 >> backend would allow us to fully deprecate applesmc in favor of this >> driver. > > ... > >> drivers/platform/Kconfig | 2 + >> drivers/platform/Makefile | 1 + >> drivers/platform/apple/Kconfig | 49 ++++ >> drivers/platform/apple/Makefile | 11 + > > Are you going to collect the code from, e.g., PDx86 which supports > some apple devices here? This driver is intended to eventually supersede hwmon/applesmc.c, once it gets the missing features (hwmon in particular) and someone writes a legacy x86 backend. In the meantime, it is likely to first gain support for T2 machines, which applesmc.c does not have. >> + smc->msg_id = (smc->msg_id + 1) & 0xf; > > % 16 will tell much cleaner of the purpose, no? I disagree. msg_id goes in a bit field in SMC messages, and & 0xf perfectly conveys the idea that it is limited to 4 bits. > > ... > >> + while (smc->atomic_pending) { >> + ret = apple_rtkit_poll(smc->rtk); >> + if (ret < 0) { >> + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); >> + return ret; >> + } >> + udelay(100); >> + } > > Something from iopoll.h to be utilised? No? Andy, I know you like to rapid-fire code reviews, but please read and understand the code you're reviewing with context, don't just fire off random comments based on gut feeling. This is calling through a framework that winds up in the mailbox code and then through a callback processes incoming messages. It's not an iopoll. > >> + return -EIO; >> + } > > ... > >> + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); >> + if (result != 0) >> + return -result; > > And this is in Linux error numbering space?! It's in some random error numbering space, and who knows how we should map it. Maybe we should just return -EIO unconditionally, but that loses all available information... >> + smc->msg_id = (smc->msg_id + 1) & 0xf; > > See above. Perhaps you need a macro / inline helper for this to avoid dups. I really don't think incrementing a 4-bit counter is an idiom that kernel driver programmers are going to find confusing, and gratuituous macro use just makes the code harder to read. >> + do { >> + if (wait_for_completion_timeout(&smc->cmd_done, >> + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { >> + dev_err(smc->dev, "Command timed out (%llx)", msg); >> + return -ETIMEDOUT; >> + } >> + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) >> + break; > >> + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", >> + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); > > Guaranteed to flood the logs... No. > >> + } while(1); > > ...with such a conditional. It's waiting on a completion every loop. And the message ID is 4 bits, so the most you will ever get is 15 messages (but in practice what happens is that if this goes wrong, it just times out on the next loop, and generally everything breaks anyway, and all of it is indicative of a major bug. Again, please read the code, don't just go "dev_err() in a while(1), bad!". >> + if (size <= 4) >> + memcpy(buf, &rdata, size); >> + else >> + memcpy_fromio(buf, smc->shmem.iomem, size); > > This is unclear why plain memcpy() for the small size and what are the > side effects of the memory. It's on the stack. Can you *please* read more than two lines of context while reviewing? This is getting tiring. You do this *all* the time. It's even taking the address of the variable right there, you didn't even need to read past that one line to understand it. > Maybe you wanted memremap() instead of > ioremap() to begin with? ioremap() uses a completely different mapping mode to memremap(). They are not interchangeable and memremap will not work here. >> + if (res.end < res.start || !resource_contains(smc->sram, &res)) { > > Is it a reimplementation of something like resource_intersect() and Co? I don't know, is it? Can you please make specific suggestions instead of randomly throwing around ideas without checking whether they actually make sense? >> + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); > > Isn't it better to write as > > res.start + (base - start) > > ? smc->sram_base is the iomem base of the sram, smc->sram->start is the physical address of the sram, and res.start is the physical address of the area the SMC is referencing. __iomem + (physaddr - physaddr) == __iomem + offset == __iomem You are proposing: physaddr + (__iomem - physaddr) which not only does not make sense, it's undefined behavior in C, since you are doing pointer arithmetic exceeding the object bounds of the iomem map. >> + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); > >> + if (!smc->sram) >> + return dev_err_probe(dev, EIO, >> + "No SRAM region"); > > Dup, the below does this message for you. There is a difference between "the DT is missing the SRAM resource" and "couldn't map the SRAM resource for some reason". Why merge them into one error? > >> + smc->sram_base = devm_ioremap_resource(dev, smc->sram); >> + if (IS_ERR(smc->sram_base)) >> + return dev_err_probe(dev, PTR_ERR(smc->sram_base), >> + "Failed to map SRAM region"); > > Don't we have devm_platform_ioremap_resource_byname() ? Except I use smc->sram elsewhere. You cannot review patches by ignoring everything but the two lines of context you are staring at right now. Before complaining about something, please *look* to see if there is a good reason for the code to be the way it is. > ... > >> +typedef u32 smc_key; > > Why?! Because SMC keys are 32 bits and giving them their own type makes it explicit what is supposed to be an SMC key. > >> +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) > > If s is a byte buffer, the above is NIH get_unaligned_be32(). Or in > case of alignment be32_to_cpu() with respective type (__be32) to be > used. Except this is a constexpr, and get_unaligned_be32 is not. s is a 32-bit identifier that happens to consist of 4 8-bit character ASCII fields. This is a macro to generate them from ASCII strings, as compile-time constants. You'd have figured that out if you read ahead to where it is used, instead of continuing your two-line-context review. >> +#define apple_smc_write_flag apple_smc_write_u8 > > Why is it needed? Because some SMC keys are boolean flags, and the ABI is identical to u8 but the logical semantics are not, and the code is clearer when it makes it explicit that the value is supposed to be a boolean, not just an arbitrary 8-bit integer. Andy, no offense, but you drive-by everything I try to upstream (or author in this case) and half of your suggestions are wrong and I have to waste my time explaining why, and most of the rest are negligible style nitpicks. Every now and then you point out some useful kernel function that I didn't know about, but your signal to noise rate is terrible. Please put some effort into your reviews. It feels like you're on some kind of quest to review as much code as possible, without the slightest care for quality. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-05 14:45 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 14:45 UTC (permalink / raw) To: Andy Shevchenko, Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 02/09/2022 04.26, Andy Shevchenko wrote: > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: >> >> From: Hector Martin <marcan@marcan.st> >> >> This driver implements support for the SMC (System Management >> Controller) in Apple Macs. In contrast to the existing applesmc driver, >> it uses pluggable backends that allow it to support different SMC >> implementations, and uses the MFD subsystem to expose the core SMC >> functionality so that specific features (gpio, hwmon, battery, etc.) can >> be implemented by separate drivers in their respective downstream >> subsystems. >> >> The initial RTKit backend adds support for Apple Silicon Macs (M1 et >> al). We hope a backend for T2 Macs will be written in the future >> (since those are not supported by applesmc), and eventually an x86 >> backend would allow us to fully deprecate applesmc in favor of this >> driver. > > ... > >> drivers/platform/Kconfig | 2 + >> drivers/platform/Makefile | 1 + >> drivers/platform/apple/Kconfig | 49 ++++ >> drivers/platform/apple/Makefile | 11 + > > Are you going to collect the code from, e.g., PDx86 which supports > some apple devices here? This driver is intended to eventually supersede hwmon/applesmc.c, once it gets the missing features (hwmon in particular) and someone writes a legacy x86 backend. In the meantime, it is likely to first gain support for T2 machines, which applesmc.c does not have. >> + smc->msg_id = (smc->msg_id + 1) & 0xf; > > % 16 will tell much cleaner of the purpose, no? I disagree. msg_id goes in a bit field in SMC messages, and & 0xf perfectly conveys the idea that it is limited to 4 bits. > > ... > >> + while (smc->atomic_pending) { >> + ret = apple_rtkit_poll(smc->rtk); >> + if (ret < 0) { >> + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); >> + return ret; >> + } >> + udelay(100); >> + } > > Something from iopoll.h to be utilised? No? Andy, I know you like to rapid-fire code reviews, but please read and understand the code you're reviewing with context, don't just fire off random comments based on gut feeling. This is calling through a framework that winds up in the mailbox code and then through a callback processes incoming messages. It's not an iopoll. > >> + return -EIO; >> + } > > ... > >> + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); >> + if (result != 0) >> + return -result; > > And this is in Linux error numbering space?! It's in some random error numbering space, and who knows how we should map it. Maybe we should just return -EIO unconditionally, but that loses all available information... >> + smc->msg_id = (smc->msg_id + 1) & 0xf; > > See above. Perhaps you need a macro / inline helper for this to avoid dups. I really don't think incrementing a 4-bit counter is an idiom that kernel driver programmers are going to find confusing, and gratuituous macro use just makes the code harder to read. >> + do { >> + if (wait_for_completion_timeout(&smc->cmd_done, >> + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { >> + dev_err(smc->dev, "Command timed out (%llx)", msg); >> + return -ETIMEDOUT; >> + } >> + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) >> + break; > >> + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", >> + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); > > Guaranteed to flood the logs... No. > >> + } while(1); > > ...with such a conditional. It's waiting on a completion every loop. And the message ID is 4 bits, so the most you will ever get is 15 messages (but in practice what happens is that if this goes wrong, it just times out on the next loop, and generally everything breaks anyway, and all of it is indicative of a major bug. Again, please read the code, don't just go "dev_err() in a while(1), bad!". >> + if (size <= 4) >> + memcpy(buf, &rdata, size); >> + else >> + memcpy_fromio(buf, smc->shmem.iomem, size); > > This is unclear why plain memcpy() for the small size and what are the > side effects of the memory. It's on the stack. Can you *please* read more than two lines of context while reviewing? This is getting tiring. You do this *all* the time. It's even taking the address of the variable right there, you didn't even need to read past that one line to understand it. > Maybe you wanted memremap() instead of > ioremap() to begin with? ioremap() uses a completely different mapping mode to memremap(). They are not interchangeable and memremap will not work here. >> + if (res.end < res.start || !resource_contains(smc->sram, &res)) { > > Is it a reimplementation of something like resource_intersect() and Co? I don't know, is it? Can you please make specific suggestions instead of randomly throwing around ideas without checking whether they actually make sense? >> + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); > > Isn't it better to write as > > res.start + (base - start) > > ? smc->sram_base is the iomem base of the sram, smc->sram->start is the physical address of the sram, and res.start is the physical address of the area the SMC is referencing. __iomem + (physaddr - physaddr) == __iomem + offset == __iomem You are proposing: physaddr + (__iomem - physaddr) which not only does not make sense, it's undefined behavior in C, since you are doing pointer arithmetic exceeding the object bounds of the iomem map. >> + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); > >> + if (!smc->sram) >> + return dev_err_probe(dev, EIO, >> + "No SRAM region"); > > Dup, the below does this message for you. There is a difference between "the DT is missing the SRAM resource" and "couldn't map the SRAM resource for some reason". Why merge them into one error? > >> + smc->sram_base = devm_ioremap_resource(dev, smc->sram); >> + if (IS_ERR(smc->sram_base)) >> + return dev_err_probe(dev, PTR_ERR(smc->sram_base), >> + "Failed to map SRAM region"); > > Don't we have devm_platform_ioremap_resource_byname() ? Except I use smc->sram elsewhere. You cannot review patches by ignoring everything but the two lines of context you are staring at right now. Before complaining about something, please *look* to see if there is a good reason for the code to be the way it is. > ... > >> +typedef u32 smc_key; > > Why?! Because SMC keys are 32 bits and giving them their own type makes it explicit what is supposed to be an SMC key. > >> +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) > > If s is a byte buffer, the above is NIH get_unaligned_be32(). Or in > case of alignment be32_to_cpu() with respective type (__be32) to be > used. Except this is a constexpr, and get_unaligned_be32 is not. s is a 32-bit identifier that happens to consist of 4 8-bit character ASCII fields. This is a macro to generate them from ASCII strings, as compile-time constants. You'd have figured that out if you read ahead to where it is used, instead of continuing your two-line-context review. >> +#define apple_smc_write_flag apple_smc_write_u8 > > Why is it needed? Because some SMC keys are boolean flags, and the ABI is identical to u8 but the logical semantics are not, and the code is clearer when it makes it explicit that the value is supposed to be a boolean, not just an arbitrary 8-bit integer. Andy, no offense, but you drive-by everything I try to upstream (or author in this case) and half of your suggestions are wrong and I have to waste my time explaining why, and most of the rest are negligible style nitpicks. Every now and then you point out some useful kernel function that I didn't know about, but your signal to noise rate is terrible. Please put some effort into your reviews. It feels like you're on some kind of quest to review as much code as possible, without the slightest care for quality. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-05 14:45 ` Hector Martin @ 2022-09-05 15:00 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 15:00 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 5:45 PM Hector Martin <marcan@marcan.st> wrote: > On 02/09/2022 04.26, Andy Shevchenko wrote: ... > Andy, no offense, but you drive-by everything I try to upstream (or > author in this case) and half of your suggestions are wrong and I have > to waste my time explaining why, and most of the rest are negligible > style nitpicks. Every now and then you point out some useful kernel > function that I didn't know about, but your signal to noise rate is > terrible. Please put some effort into your reviews. It feels like you're > on some kind of quest to review as much code as possible, without the > slightest care for quality. Okay, if I ever review your code in the future, I'll try my best. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-05 15:00 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 15:00 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 5:45 PM Hector Martin <marcan@marcan.st> wrote: > On 02/09/2022 04.26, Andy Shevchenko wrote: ... > Andy, no offense, but you drive-by everything I try to upstream (or > author in this case) and half of your suggestions are wrong and I have > to waste my time explaining why, and most of the rest are negligible > style nitpicks. Every now and then you point out some useful kernel > function that I didn't know about, but your signal to noise rate is > terrible. Please put some effort into your reviews. It feels like you're > on some kind of quest to review as much code as possible, without the > slightest care for quality. Okay, if I ever review your code in the future, I'll try my best. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-01 13:54 ` Russell King @ 2022-09-08 10:58 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-08 10:58 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 01 Sep 2022, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. > > The initial RTKit backend adds support for Apple Silicon Macs (M1 et > al). We hope a backend for T2 Macs will be written in the future > (since those are not supported by applesmc), and eventually an x86 > backend would allow us to fully deprecate applesmc in favor of this > driver. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/platform/Kconfig | 2 + > drivers/platform/Makefile | 1 + > drivers/platform/apple/Kconfig | 49 ++++ > drivers/platform/apple/Makefile | 11 + > drivers/platform/apple/smc.h | 28 ++ > drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ > drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ > include/linux/mfd/macsmc.h | 86 ++++++ > 8 files changed, 877 insertions(+) > create mode 100644 drivers/platform/apple/Kconfig > create mode 100644 drivers/platform/apple/Makefile > create mode 100644 drivers/platform/apple/smc.h > create mode 100644 drivers/platform/apple/smc_core.c > create mode 100644 drivers/platform/apple/smc_rtkit.c > create mode 100644 include/linux/mfd/macsmc.h > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > index b437847b6237..5f8b9bcdb830 100644 > --- a/drivers/platform/Kconfig > +++ b/drivers/platform/Kconfig > @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" > > source "drivers/platform/surface/Kconfig" > > +source "drivers/platform/apple/Kconfig" > + > source "drivers/platform/x86/Kconfig" > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > index 4de08ef4ec9d..3e5d5039a28c 100644 > --- a/drivers/platform/Makefile > +++ b/drivers/platform/Makefile > @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ > obj-$(CONFIG_GOLDFISH) += goldfish/ > obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ > +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ > diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig > new file mode 100644 > index 000000000000..42525aa9fbbe > --- /dev/null > +++ b/drivers/platform/apple/Kconfig > @@ -0,0 +1,49 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Apple Platform-Specific Drivers > +# > + > +menuconfig APPLE_PLATFORMS > + bool "Apple Mac Platform-Specific Device Drivers" > + default y > + help > + Say Y here to get to see options for platform-specific device drivers > + for Apple devices. This option alone does not add any kernel code. > + > + If you say N, all options in this submenu will be skipped and disabled. > + > +if APPLE_PLATFORMS > + > +config APPLE_SMC > + tristate "Apple SMC Driver" > + depends on ARCH_APPLE || COMPILE_TEST > + default ARCH_APPLE > + select MFD_CORE > + help > + Build support for the Apple System Management Controller present in > + Apple Macs. This driver currently supports the SMC in Apple Silicon > + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc. > + > +if APPLE_SMC > + > +config APPLE_SMC_RTKIT > + tristate "RTKit (Apple Silicon) backend" > + depends on ARCH_APPLE || COMPILE_TEST > + depends on APPLE_RTKIT > + default ARCH_APPLE > + help > + Build support for SMC communications via the RTKit backend. This is > + required for Apple Silicon Macs. > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc-rtkit. > + > +endif > +endif > diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile > new file mode 100644 > index 000000000000..79fac195398b > --- /dev/null > +++ b/drivers/platform/apple/Makefile > @@ -0,0 +1,11 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for linux/drivers/platform/apple > +# Apple Platform-Specific Drivers > +# > + > +macsmc-y += smc_core.o > +macsmc-rtkit-y += smc_rtkit.o > + > +obj-$(CONFIG_APPLE_SMC) += macsmc.o > +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o > diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h > new file mode 100644 > index 000000000000..8ae51887b2c5 > --- /dev/null > +++ b/drivers/platform/apple/smc.h > @@ -0,0 +1,28 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC internal core definitions > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _SMC_H > +#define _SMC_H > + > +#include <linux/mfd/macsmc.h> > + > +struct apple_smc_backend_ops { > + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); > + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); > +}; > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, > + void *cookie); > +void *apple_smc_get_cookie(struct apple_smc *smc); > +int apple_smc_remove(struct apple_smc *smc); > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > + > +#endif > diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c > new file mode 100644 > index 000000000000..daf029cd072f > --- /dev/null > +++ b/drivers/platform/apple/smc_core.c > @@ -0,0 +1,249 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core framework > + * Copyright The Asahi Linux Contributors > + */ > + > +#include <linux/device.h> > +#include <linux/mfd/core.h> Please refrain from using the MFD API outside of drivers/mfd. If you need an MFD driver, please separate it out. If not, please replace it with the platform_*() API instead. Thanks. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 10:58 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-08 10:58 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 01 Sep 2022, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. > > The initial RTKit backend adds support for Apple Silicon Macs (M1 et > al). We hope a backend for T2 Macs will be written in the future > (since those are not supported by applesmc), and eventually an x86 > backend would allow us to fully deprecate applesmc in favor of this > driver. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/platform/Kconfig | 2 + > drivers/platform/Makefile | 1 + > drivers/platform/apple/Kconfig | 49 ++++ > drivers/platform/apple/Makefile | 11 + > drivers/platform/apple/smc.h | 28 ++ > drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ > drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ > include/linux/mfd/macsmc.h | 86 ++++++ > 8 files changed, 877 insertions(+) > create mode 100644 drivers/platform/apple/Kconfig > create mode 100644 drivers/platform/apple/Makefile > create mode 100644 drivers/platform/apple/smc.h > create mode 100644 drivers/platform/apple/smc_core.c > create mode 100644 drivers/platform/apple/smc_rtkit.c > create mode 100644 include/linux/mfd/macsmc.h > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > index b437847b6237..5f8b9bcdb830 100644 > --- a/drivers/platform/Kconfig > +++ b/drivers/platform/Kconfig > @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" > > source "drivers/platform/surface/Kconfig" > > +source "drivers/platform/apple/Kconfig" > + > source "drivers/platform/x86/Kconfig" > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > index 4de08ef4ec9d..3e5d5039a28c 100644 > --- a/drivers/platform/Makefile > +++ b/drivers/platform/Makefile > @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ > obj-$(CONFIG_GOLDFISH) += goldfish/ > obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ > +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ > diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig > new file mode 100644 > index 000000000000..42525aa9fbbe > --- /dev/null > +++ b/drivers/platform/apple/Kconfig > @@ -0,0 +1,49 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Apple Platform-Specific Drivers > +# > + > +menuconfig APPLE_PLATFORMS > + bool "Apple Mac Platform-Specific Device Drivers" > + default y > + help > + Say Y here to get to see options for platform-specific device drivers > + for Apple devices. This option alone does not add any kernel code. > + > + If you say N, all options in this submenu will be skipped and disabled. > + > +if APPLE_PLATFORMS > + > +config APPLE_SMC > + tristate "Apple SMC Driver" > + depends on ARCH_APPLE || COMPILE_TEST > + default ARCH_APPLE > + select MFD_CORE > + help > + Build support for the Apple System Management Controller present in > + Apple Macs. This driver currently supports the SMC in Apple Silicon > + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc. > + > +if APPLE_SMC > + > +config APPLE_SMC_RTKIT > + tristate "RTKit (Apple Silicon) backend" > + depends on ARCH_APPLE || COMPILE_TEST > + depends on APPLE_RTKIT > + default ARCH_APPLE > + help > + Build support for SMC communications via the RTKit backend. This is > + required for Apple Silicon Macs. > + > + Say Y here if you have an Apple Silicon Mac. > + > + To compile this driver as a module, choose M here: the module will > + be called macsmc-rtkit. > + > +endif > +endif > diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile > new file mode 100644 > index 000000000000..79fac195398b > --- /dev/null > +++ b/drivers/platform/apple/Makefile > @@ -0,0 +1,11 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for linux/drivers/platform/apple > +# Apple Platform-Specific Drivers > +# > + > +macsmc-y += smc_core.o > +macsmc-rtkit-y += smc_rtkit.o > + > +obj-$(CONFIG_APPLE_SMC) += macsmc.o > +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o > diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h > new file mode 100644 > index 000000000000..8ae51887b2c5 > --- /dev/null > +++ b/drivers/platform/apple/smc.h > @@ -0,0 +1,28 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC internal core definitions > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _SMC_H > +#define _SMC_H > + > +#include <linux/mfd/macsmc.h> > + > +struct apple_smc_backend_ops { > + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); > + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); > +}; > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, > + void *cookie); > +void *apple_smc_get_cookie(struct apple_smc *smc); > +int apple_smc_remove(struct apple_smc *smc); > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > + > +#endif > diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c > new file mode 100644 > index 000000000000..daf029cd072f > --- /dev/null > +++ b/drivers/platform/apple/smc_core.c > @@ -0,0 +1,249 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core framework > + * Copyright The Asahi Linux Contributors > + */ > + > +#include <linux/device.h> > +#include <linux/mfd/core.h> Please refrain from using the MFD API outside of drivers/mfd. If you need an MFD driver, please separate it out. If not, please replace it with the platform_*() API instead. Thanks. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 10:58 ` Lee Jones @ 2022-09-08 11:28 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-08 11:28 UTC (permalink / raw) To: Lee Jones, Russell King Cc: Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 08/09/2022 19.58, Lee Jones wrote: > On Thu, 01 Sep 2022, Russell King wrote: > >> From: Hector Martin <marcan@marcan.st> >> >> This driver implements support for the SMC (System Management >> Controller) in Apple Macs. In contrast to the existing applesmc driver, >> it uses pluggable backends that allow it to support different SMC >> implementations, and uses the MFD subsystem to expose the core SMC >> functionality so that specific features (gpio, hwmon, battery, etc.) can >> be implemented by separate drivers in their respective downstream >> subsystems. >> >> The initial RTKit backend adds support for Apple Silicon Macs (M1 et >> al). We hope a backend for T2 Macs will be written in the future >> (since those are not supported by applesmc), and eventually an x86 >> backend would allow us to fully deprecate applesmc in favor of this >> driver. >> >> Signed-off-by: Hector Martin <marcan@marcan.st> >> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >> --- >> drivers/platform/Kconfig | 2 + >> drivers/platform/Makefile | 1 + >> drivers/platform/apple/Kconfig | 49 ++++ >> drivers/platform/apple/Makefile | 11 + >> drivers/platform/apple/smc.h | 28 ++ >> drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ >> drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ >> include/linux/mfd/macsmc.h | 86 ++++++ >> 8 files changed, 877 insertions(+) >> create mode 100644 drivers/platform/apple/Kconfig >> create mode 100644 drivers/platform/apple/Makefile >> create mode 100644 drivers/platform/apple/smc.h >> create mode 100644 drivers/platform/apple/smc_core.c >> create mode 100644 drivers/platform/apple/smc_rtkit.c >> create mode 100644 include/linux/mfd/macsmc.h >> >> diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig >> index b437847b6237..5f8b9bcdb830 100644 >> --- a/drivers/platform/Kconfig >> +++ b/drivers/platform/Kconfig >> @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" >> >> source "drivers/platform/surface/Kconfig" >> >> +source "drivers/platform/apple/Kconfig" >> + >> source "drivers/platform/x86/Kconfig" >> diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile >> index 4de08ef4ec9d..3e5d5039a28c 100644 >> --- a/drivers/platform/Makefile >> +++ b/drivers/platform/Makefile >> @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ >> obj-$(CONFIG_GOLDFISH) += goldfish/ >> obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ >> obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ >> +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ >> diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig >> new file mode 100644 >> index 000000000000..42525aa9fbbe >> --- /dev/null >> +++ b/drivers/platform/apple/Kconfig >> @@ -0,0 +1,49 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +# >> +# Apple Platform-Specific Drivers >> +# >> + >> +menuconfig APPLE_PLATFORMS >> + bool "Apple Mac Platform-Specific Device Drivers" >> + default y >> + help >> + Say Y here to get to see options for platform-specific device drivers >> + for Apple devices. This option alone does not add any kernel code. >> + >> + If you say N, all options in this submenu will be skipped and disabled. >> + >> +if APPLE_PLATFORMS >> + >> +config APPLE_SMC >> + tristate "Apple SMC Driver" >> + depends on ARCH_APPLE || COMPILE_TEST >> + default ARCH_APPLE >> + select MFD_CORE >> + help >> + Build support for the Apple System Management Controller present in >> + Apple Macs. This driver currently supports the SMC in Apple Silicon >> + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). >> + >> + Say Y here if you have an Apple Silicon Mac. >> + >> + To compile this driver as a module, choose M here: the module will >> + be called macsmc. >> + >> +if APPLE_SMC >> + >> +config APPLE_SMC_RTKIT >> + tristate "RTKit (Apple Silicon) backend" >> + depends on ARCH_APPLE || COMPILE_TEST >> + depends on APPLE_RTKIT >> + default ARCH_APPLE >> + help >> + Build support for SMC communications via the RTKit backend. This is >> + required for Apple Silicon Macs. >> + >> + Say Y here if you have an Apple Silicon Mac. >> + >> + To compile this driver as a module, choose M here: the module will >> + be called macsmc-rtkit. >> + >> +endif >> +endif >> diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile >> new file mode 100644 >> index 000000000000..79fac195398b >> --- /dev/null >> +++ b/drivers/platform/apple/Makefile >> @@ -0,0 +1,11 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +# >> +# Makefile for linux/drivers/platform/apple >> +# Apple Platform-Specific Drivers >> +# >> + >> +macsmc-y += smc_core.o >> +macsmc-rtkit-y += smc_rtkit.o >> + >> +obj-$(CONFIG_APPLE_SMC) += macsmc.o >> +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o >> diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h >> new file mode 100644 >> index 000000000000..8ae51887b2c5 >> --- /dev/null >> +++ b/drivers/platform/apple/smc.h >> @@ -0,0 +1,28 @@ >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT >> +/* >> + * Apple SMC internal core definitions >> + * Copyright (C) The Asahi Linux Contributors >> + */ >> + >> +#ifndef _SMC_H >> +#define _SMC_H >> + >> +#include <linux/mfd/macsmc.h> >> + >> +struct apple_smc_backend_ops { >> + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); >> + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); >> + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); >> + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, >> + void *rbuf, size_t rsize); >> + int (*get_key_by_index)(void *cookie, int index, smc_key *key); >> + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); >> +}; >> + >> +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, >> + void *cookie); >> +void *apple_smc_get_cookie(struct apple_smc *smc); >> +int apple_smc_remove(struct apple_smc *smc); >> +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); >> + >> +#endif >> diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c >> new file mode 100644 >> index 000000000000..daf029cd072f >> --- /dev/null >> +++ b/drivers/platform/apple/smc_core.c >> @@ -0,0 +1,249 @@ >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT >> +/* >> + * Apple SMC core framework >> + * Copyright The Asahi Linux Contributors >> + */ >> + >> +#include <linux/device.h> >> +#include <linux/mfd/core.h> > > Please refrain from using the MFD API outside of drivers/mfd. > > If you need an MFD driver, please separate it out. > > If not, please replace it with the platform_*() API instead. There is precedent for MFD devices under platform/: drivers/platform/x86/intel/int3472/tps68470.c As well as other examples in the tree: drivers/firmware/xilinx/zynqmp.c drivers/iio/common/ssp_sensors/ssp_dev.c drivers/misc/cardreader/alcor_pci.c drivers/misc/cardreader/rtsx_pcr.c drivers/misc/cardreader/rtsx_usb.c drivers/soc/samsung/exynos-pmu.c drivers/staging/nvec/nvec.c Since it's a driver for a platform-specific firmware service, I thought it made more sense in platform/ than mfd/. It's using the MFD API because the firmware exposes multiple subsystems, and this maps very nicely to the MFD model - NIHing that scaffolding would require a whole bunch of custom matching/device creation code. But it's not exactly your typical MFD device (it's not even a separate chip, it's part of the main SoC), so I'm not sure if it really belongs in mfd/ from an organizational standpoint? - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 11:28 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-08 11:28 UTC (permalink / raw) To: Lee Jones, Russell King Cc: Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 08/09/2022 19.58, Lee Jones wrote: > On Thu, 01 Sep 2022, Russell King wrote: > >> From: Hector Martin <marcan@marcan.st> >> >> This driver implements support for the SMC (System Management >> Controller) in Apple Macs. In contrast to the existing applesmc driver, >> it uses pluggable backends that allow it to support different SMC >> implementations, and uses the MFD subsystem to expose the core SMC >> functionality so that specific features (gpio, hwmon, battery, etc.) can >> be implemented by separate drivers in their respective downstream >> subsystems. >> >> The initial RTKit backend adds support for Apple Silicon Macs (M1 et >> al). We hope a backend for T2 Macs will be written in the future >> (since those are not supported by applesmc), and eventually an x86 >> backend would allow us to fully deprecate applesmc in favor of this >> driver. >> >> Signed-off-by: Hector Martin <marcan@marcan.st> >> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >> --- >> drivers/platform/Kconfig | 2 + >> drivers/platform/Makefile | 1 + >> drivers/platform/apple/Kconfig | 49 ++++ >> drivers/platform/apple/Makefile | 11 + >> drivers/platform/apple/smc.h | 28 ++ >> drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ >> drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ >> include/linux/mfd/macsmc.h | 86 ++++++ >> 8 files changed, 877 insertions(+) >> create mode 100644 drivers/platform/apple/Kconfig >> create mode 100644 drivers/platform/apple/Makefile >> create mode 100644 drivers/platform/apple/smc.h >> create mode 100644 drivers/platform/apple/smc_core.c >> create mode 100644 drivers/platform/apple/smc_rtkit.c >> create mode 100644 include/linux/mfd/macsmc.h >> >> diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig >> index b437847b6237..5f8b9bcdb830 100644 >> --- a/drivers/platform/Kconfig >> +++ b/drivers/platform/Kconfig >> @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" >> >> source "drivers/platform/surface/Kconfig" >> >> +source "drivers/platform/apple/Kconfig" >> + >> source "drivers/platform/x86/Kconfig" >> diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile >> index 4de08ef4ec9d..3e5d5039a28c 100644 >> --- a/drivers/platform/Makefile >> +++ b/drivers/platform/Makefile >> @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ >> obj-$(CONFIG_GOLDFISH) += goldfish/ >> obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ >> obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ >> +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ >> diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig >> new file mode 100644 >> index 000000000000..42525aa9fbbe >> --- /dev/null >> +++ b/drivers/platform/apple/Kconfig >> @@ -0,0 +1,49 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +# >> +# Apple Platform-Specific Drivers >> +# >> + >> +menuconfig APPLE_PLATFORMS >> + bool "Apple Mac Platform-Specific Device Drivers" >> + default y >> + help >> + Say Y here to get to see options for platform-specific device drivers >> + for Apple devices. This option alone does not add any kernel code. >> + >> + If you say N, all options in this submenu will be skipped and disabled. >> + >> +if APPLE_PLATFORMS >> + >> +config APPLE_SMC >> + tristate "Apple SMC Driver" >> + depends on ARCH_APPLE || COMPILE_TEST >> + default ARCH_APPLE >> + select MFD_CORE >> + help >> + Build support for the Apple System Management Controller present in >> + Apple Macs. This driver currently supports the SMC in Apple Silicon >> + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). >> + >> + Say Y here if you have an Apple Silicon Mac. >> + >> + To compile this driver as a module, choose M here: the module will >> + be called macsmc. >> + >> +if APPLE_SMC >> + >> +config APPLE_SMC_RTKIT >> + tristate "RTKit (Apple Silicon) backend" >> + depends on ARCH_APPLE || COMPILE_TEST >> + depends on APPLE_RTKIT >> + default ARCH_APPLE >> + help >> + Build support for SMC communications via the RTKit backend. This is >> + required for Apple Silicon Macs. >> + >> + Say Y here if you have an Apple Silicon Mac. >> + >> + To compile this driver as a module, choose M here: the module will >> + be called macsmc-rtkit. >> + >> +endif >> +endif >> diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile >> new file mode 100644 >> index 000000000000..79fac195398b >> --- /dev/null >> +++ b/drivers/platform/apple/Makefile >> @@ -0,0 +1,11 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +# >> +# Makefile for linux/drivers/platform/apple >> +# Apple Platform-Specific Drivers >> +# >> + >> +macsmc-y += smc_core.o >> +macsmc-rtkit-y += smc_rtkit.o >> + >> +obj-$(CONFIG_APPLE_SMC) += macsmc.o >> +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o >> diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h >> new file mode 100644 >> index 000000000000..8ae51887b2c5 >> --- /dev/null >> +++ b/drivers/platform/apple/smc.h >> @@ -0,0 +1,28 @@ >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT >> +/* >> + * Apple SMC internal core definitions >> + * Copyright (C) The Asahi Linux Contributors >> + */ >> + >> +#ifndef _SMC_H >> +#define _SMC_H >> + >> +#include <linux/mfd/macsmc.h> >> + >> +struct apple_smc_backend_ops { >> + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); >> + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); >> + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); >> + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, >> + void *rbuf, size_t rsize); >> + int (*get_key_by_index)(void *cookie, int index, smc_key *key); >> + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); >> +}; >> + >> +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, >> + void *cookie); >> +void *apple_smc_get_cookie(struct apple_smc *smc); >> +int apple_smc_remove(struct apple_smc *smc); >> +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); >> + >> +#endif >> diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c >> new file mode 100644 >> index 000000000000..daf029cd072f >> --- /dev/null >> +++ b/drivers/platform/apple/smc_core.c >> @@ -0,0 +1,249 @@ >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT >> +/* >> + * Apple SMC core framework >> + * Copyright The Asahi Linux Contributors >> + */ >> + >> +#include <linux/device.h> >> +#include <linux/mfd/core.h> > > Please refrain from using the MFD API outside of drivers/mfd. > > If you need an MFD driver, please separate it out. > > If not, please replace it with the platform_*() API instead. There is precedent for MFD devices under platform/: drivers/platform/x86/intel/int3472/tps68470.c As well as other examples in the tree: drivers/firmware/xilinx/zynqmp.c drivers/iio/common/ssp_sensors/ssp_dev.c drivers/misc/cardreader/alcor_pci.c drivers/misc/cardreader/rtsx_pcr.c drivers/misc/cardreader/rtsx_usb.c drivers/soc/samsung/exynos-pmu.c drivers/staging/nvec/nvec.c Since it's a driver for a platform-specific firmware service, I thought it made more sense in platform/ than mfd/. It's using the MFD API because the firmware exposes multiple subsystems, and this maps very nicely to the MFD model - NIHing that scaffolding would require a whole bunch of custom matching/device creation code. But it's not exactly your typical MFD device (it's not even a separate chip, it's part of the main SoC), so I'm not sure if it really belongs in mfd/ from an organizational standpoint? - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 11:28 ` Hector Martin @ 2022-09-08 12:31 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-08 12:31 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 08 Sep 2022, Hector Martin wrote: > On 08/09/2022 19.58, Lee Jones wrote: > > On Thu, 01 Sep 2022, Russell King wrote: > > > >> From: Hector Martin <marcan@marcan.st> > >> > >> This driver implements support for the SMC (System Management > >> Controller) in Apple Macs. In contrast to the existing applesmc driver, > >> it uses pluggable backends that allow it to support different SMC > >> implementations, and uses the MFD subsystem to expose the core SMC > >> functionality so that specific features (gpio, hwmon, battery, etc.) can > >> be implemented by separate drivers in their respective downstream > >> subsystems. > >> > >> The initial RTKit backend adds support for Apple Silicon Macs (M1 et > >> al). We hope a backend for T2 Macs will be written in the future > >> (since those are not supported by applesmc), and eventually an x86 > >> backend would allow us to fully deprecate applesmc in favor of this > >> driver. > >> > >> Signed-off-by: Hector Martin <marcan@marcan.st> > >> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >> --- > >> drivers/platform/Kconfig | 2 + > >> drivers/platform/Makefile | 1 + > >> drivers/platform/apple/Kconfig | 49 ++++ > >> drivers/platform/apple/Makefile | 11 + > >> drivers/platform/apple/smc.h | 28 ++ > >> drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ > >> drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ > >> include/linux/mfd/macsmc.h | 86 ++++++ > >> 8 files changed, 877 insertions(+) > >> create mode 100644 drivers/platform/apple/Kconfig > >> create mode 100644 drivers/platform/apple/Makefile > >> create mode 100644 drivers/platform/apple/smc.h > >> create mode 100644 drivers/platform/apple/smc_core.c > >> create mode 100644 drivers/platform/apple/smc_rtkit.c > >> create mode 100644 include/linux/mfd/macsmc.h > >> > >> diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > >> index b437847b6237..5f8b9bcdb830 100644 > >> --- a/drivers/platform/Kconfig > >> +++ b/drivers/platform/Kconfig > >> @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" > >> > >> source "drivers/platform/surface/Kconfig" > >> > >> +source "drivers/platform/apple/Kconfig" > >> + > >> source "drivers/platform/x86/Kconfig" > >> diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > >> index 4de08ef4ec9d..3e5d5039a28c 100644 > >> --- a/drivers/platform/Makefile > >> +++ b/drivers/platform/Makefile > >> @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ > >> obj-$(CONFIG_GOLDFISH) += goldfish/ > >> obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > >> obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ > >> +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ > >> diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig > >> new file mode 100644 > >> index 000000000000..42525aa9fbbe > >> --- /dev/null > >> +++ b/drivers/platform/apple/Kconfig > >> @@ -0,0 +1,49 @@ > >> +# SPDX-License-Identifier: GPL-2.0 > >> +# > >> +# Apple Platform-Specific Drivers > >> +# > >> + > >> +menuconfig APPLE_PLATFORMS > >> + bool "Apple Mac Platform-Specific Device Drivers" > >> + default y > >> + help > >> + Say Y here to get to see options for platform-specific device drivers > >> + for Apple devices. This option alone does not add any kernel code. > >> + > >> + If you say N, all options in this submenu will be skipped and disabled. > >> + > >> +if APPLE_PLATFORMS > >> + > >> +config APPLE_SMC > >> + tristate "Apple SMC Driver" > >> + depends on ARCH_APPLE || COMPILE_TEST > >> + default ARCH_APPLE > >> + select MFD_CORE > >> + help > >> + Build support for the Apple System Management Controller present in > >> + Apple Macs. This driver currently supports the SMC in Apple Silicon > >> + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). > >> + > >> + Say Y here if you have an Apple Silicon Mac. > >> + > >> + To compile this driver as a module, choose M here: the module will > >> + be called macsmc. > >> + > >> +if APPLE_SMC > >> + > >> +config APPLE_SMC_RTKIT > >> + tristate "RTKit (Apple Silicon) backend" > >> + depends on ARCH_APPLE || COMPILE_TEST > >> + depends on APPLE_RTKIT > >> + default ARCH_APPLE > >> + help > >> + Build support for SMC communications via the RTKit backend. This is > >> + required for Apple Silicon Macs. > >> + > >> + Say Y here if you have an Apple Silicon Mac. > >> + > >> + To compile this driver as a module, choose M here: the module will > >> + be called macsmc-rtkit. > >> + > >> +endif > >> +endif > >> diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile > >> new file mode 100644 > >> index 000000000000..79fac195398b > >> --- /dev/null > >> +++ b/drivers/platform/apple/Makefile > >> @@ -0,0 +1,11 @@ > >> +# SPDX-License-Identifier: GPL-2.0 > >> +# > >> +# Makefile for linux/drivers/platform/apple > >> +# Apple Platform-Specific Drivers > >> +# > >> + > >> +macsmc-y += smc_core.o > >> +macsmc-rtkit-y += smc_rtkit.o > >> + > >> +obj-$(CONFIG_APPLE_SMC) += macsmc.o > >> +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o > >> diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h > >> new file mode 100644 > >> index 000000000000..8ae51887b2c5 > >> --- /dev/null > >> +++ b/drivers/platform/apple/smc.h > >> @@ -0,0 +1,28 @@ > >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT > >> +/* > >> + * Apple SMC internal core definitions > >> + * Copyright (C) The Asahi Linux Contributors > >> + */ > >> + > >> +#ifndef _SMC_H > >> +#define _SMC_H > >> + > >> +#include <linux/mfd/macsmc.h> > >> + > >> +struct apple_smc_backend_ops { > >> + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > >> + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > >> + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); > >> + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > >> + void *rbuf, size_t rsize); > >> + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > >> + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); > >> +}; > >> + > >> +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, > >> + void *cookie); > >> +void *apple_smc_get_cookie(struct apple_smc *smc); > >> +int apple_smc_remove(struct apple_smc *smc); > >> +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > >> + > >> +#endif > >> diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c > >> new file mode 100644 > >> index 000000000000..daf029cd072f > >> --- /dev/null > >> +++ b/drivers/platform/apple/smc_core.c > >> @@ -0,0 +1,249 @@ > >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT > >> +/* > >> + * Apple SMC core framework > >> + * Copyright The Asahi Linux Contributors > >> + */ > >> + > >> +#include <linux/device.h> > >> +#include <linux/mfd/core.h> > > > > Please refrain from using the MFD API outside of drivers/mfd. > > > > If you need an MFD driver, please separate it out. > > > > If not, please replace it with the platform_*() API instead. > > There is precedent for MFD devices under platform/: > > drivers/platform/x86/intel/int3472/tps68470.c > > As well as other examples in the tree: > > drivers/firmware/xilinx/zynqmp.c > drivers/iio/common/ssp_sensors/ssp_dev.c > drivers/misc/cardreader/alcor_pci.c > drivers/misc/cardreader/rtsx_pcr.c > drivers/misc/cardreader/rtsx_usb.c > drivers/soc/samsung/exynos-pmu.c > drivers/staging/nvec/nvec.c I'm aware of the previous offences. They each slipped-in before I could catch them. Ideally I'd like to reverse the act. However, finding time for such low-priority activities has proved challenging. I only noticed *this* occurrence due to the MFD header file. > Since it's a driver for a platform-specific firmware service, I thought > it made more sense in platform/ than mfd/. It's using the MFD API > because the firmware exposes multiple subsystems, and this maps very > nicely to the MFD model - NIHing that scaffolding would require a whole > bunch of custom matching/device creation code. I'm also aware of the convenience value of {ab}using the MFD API. > But it's not exactly your > typical MFD device (it's not even a separate chip, it's part of the main > SoC), so I'm not sure if it really belongs in mfd/ from an > organizational standpoint? There is a strong argument for all SoCs to be classed as (massive) MFDs. However seeing as they represent more of a whole platform, rather than an add-on chip, we have had the sense to represent them differently. Some such submissions I have made explicit requests to be moved form drivers/mfd *into* drivers/platform in the past. Most SoCs are solely represented in DT, omitting the requirement for subsequent device registration. Have you considered this? If so, why does this not suit your use-case? The long and the short of it is; if you wish to treat this device, or at least a section of it, as a type of MFD, then please draft that part of it as an MFD driver, residing in drivers/mfd. If it's "not really an MFD", then find another way to represent the conglomeration please. If the MFD route is the best, then you can register each of the devices, including the *-core from drivers/mfd. Grep for "cross-ec" as a relatively recently good example. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 12:31 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-08 12:31 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 08 Sep 2022, Hector Martin wrote: > On 08/09/2022 19.58, Lee Jones wrote: > > On Thu, 01 Sep 2022, Russell King wrote: > > > >> From: Hector Martin <marcan@marcan.st> > >> > >> This driver implements support for the SMC (System Management > >> Controller) in Apple Macs. In contrast to the existing applesmc driver, > >> it uses pluggable backends that allow it to support different SMC > >> implementations, and uses the MFD subsystem to expose the core SMC > >> functionality so that specific features (gpio, hwmon, battery, etc.) can > >> be implemented by separate drivers in their respective downstream > >> subsystems. > >> > >> The initial RTKit backend adds support for Apple Silicon Macs (M1 et > >> al). We hope a backend for T2 Macs will be written in the future > >> (since those are not supported by applesmc), and eventually an x86 > >> backend would allow us to fully deprecate applesmc in favor of this > >> driver. > >> > >> Signed-off-by: Hector Martin <marcan@marcan.st> > >> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >> --- > >> drivers/platform/Kconfig | 2 + > >> drivers/platform/Makefile | 1 + > >> drivers/platform/apple/Kconfig | 49 ++++ > >> drivers/platform/apple/Makefile | 11 + > >> drivers/platform/apple/smc.h | 28 ++ > >> drivers/platform/apple/smc_core.c | 249 ++++++++++++++++ > >> drivers/platform/apple/smc_rtkit.c | 451 +++++++++++++++++++++++++++++ > >> include/linux/mfd/macsmc.h | 86 ++++++ > >> 8 files changed, 877 insertions(+) > >> create mode 100644 drivers/platform/apple/Kconfig > >> create mode 100644 drivers/platform/apple/Makefile > >> create mode 100644 drivers/platform/apple/smc.h > >> create mode 100644 drivers/platform/apple/smc_core.c > >> create mode 100644 drivers/platform/apple/smc_rtkit.c > >> create mode 100644 include/linux/mfd/macsmc.h > >> > >> diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > >> index b437847b6237..5f8b9bcdb830 100644 > >> --- a/drivers/platform/Kconfig > >> +++ b/drivers/platform/Kconfig > >> @@ -13,4 +13,6 @@ source "drivers/platform/olpc/Kconfig" > >> > >> source "drivers/platform/surface/Kconfig" > >> > >> +source "drivers/platform/apple/Kconfig" > >> + > >> source "drivers/platform/x86/Kconfig" > >> diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > >> index 4de08ef4ec9d..3e5d5039a28c 100644 > >> --- a/drivers/platform/Makefile > >> +++ b/drivers/platform/Makefile > >> @@ -10,3 +10,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ > >> obj-$(CONFIG_GOLDFISH) += goldfish/ > >> obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > >> obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ > >> +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ > >> diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig > >> new file mode 100644 > >> index 000000000000..42525aa9fbbe > >> --- /dev/null > >> +++ b/drivers/platform/apple/Kconfig > >> @@ -0,0 +1,49 @@ > >> +# SPDX-License-Identifier: GPL-2.0 > >> +# > >> +# Apple Platform-Specific Drivers > >> +# > >> + > >> +menuconfig APPLE_PLATFORMS > >> + bool "Apple Mac Platform-Specific Device Drivers" > >> + default y > >> + help > >> + Say Y here to get to see options for platform-specific device drivers > >> + for Apple devices. This option alone does not add any kernel code. > >> + > >> + If you say N, all options in this submenu will be skipped and disabled. > >> + > >> +if APPLE_PLATFORMS > >> + > >> +config APPLE_SMC > >> + tristate "Apple SMC Driver" > >> + depends on ARCH_APPLE || COMPILE_TEST > >> + default ARCH_APPLE > >> + select MFD_CORE > >> + help > >> + Build support for the Apple System Management Controller present in > >> + Apple Macs. This driver currently supports the SMC in Apple Silicon > >> + Macs. For x86 Macs, see the applesmc driver (SENSORS_APPLESMC). > >> + > >> + Say Y here if you have an Apple Silicon Mac. > >> + > >> + To compile this driver as a module, choose M here: the module will > >> + be called macsmc. > >> + > >> +if APPLE_SMC > >> + > >> +config APPLE_SMC_RTKIT > >> + tristate "RTKit (Apple Silicon) backend" > >> + depends on ARCH_APPLE || COMPILE_TEST > >> + depends on APPLE_RTKIT > >> + default ARCH_APPLE > >> + help > >> + Build support for SMC communications via the RTKit backend. This is > >> + required for Apple Silicon Macs. > >> + > >> + Say Y here if you have an Apple Silicon Mac. > >> + > >> + To compile this driver as a module, choose M here: the module will > >> + be called macsmc-rtkit. > >> + > >> +endif > >> +endif > >> diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile > >> new file mode 100644 > >> index 000000000000..79fac195398b > >> --- /dev/null > >> +++ b/drivers/platform/apple/Makefile > >> @@ -0,0 +1,11 @@ > >> +# SPDX-License-Identifier: GPL-2.0 > >> +# > >> +# Makefile for linux/drivers/platform/apple > >> +# Apple Platform-Specific Drivers > >> +# > >> + > >> +macsmc-y += smc_core.o > >> +macsmc-rtkit-y += smc_rtkit.o > >> + > >> +obj-$(CONFIG_APPLE_SMC) += macsmc.o > >> +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o > >> diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h > >> new file mode 100644 > >> index 000000000000..8ae51887b2c5 > >> --- /dev/null > >> +++ b/drivers/platform/apple/smc.h > >> @@ -0,0 +1,28 @@ > >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT > >> +/* > >> + * Apple SMC internal core definitions > >> + * Copyright (C) The Asahi Linux Contributors > >> + */ > >> + > >> +#ifndef _SMC_H > >> +#define _SMC_H > >> + > >> +#include <linux/mfd/macsmc.h> > >> + > >> +struct apple_smc_backend_ops { > >> + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > >> + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > >> + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); > >> + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > >> + void *rbuf, size_t rsize); > >> + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > >> + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); > >> +}; > >> + > >> +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, > >> + void *cookie); > >> +void *apple_smc_get_cookie(struct apple_smc *smc); > >> +int apple_smc_remove(struct apple_smc *smc); > >> +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > >> + > >> +#endif > >> diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c > >> new file mode 100644 > >> index 000000000000..daf029cd072f > >> --- /dev/null > >> +++ b/drivers/platform/apple/smc_core.c > >> @@ -0,0 +1,249 @@ > >> +// SPDX-License-Identifier: GPL-2.0-only OR MIT > >> +/* > >> + * Apple SMC core framework > >> + * Copyright The Asahi Linux Contributors > >> + */ > >> + > >> +#include <linux/device.h> > >> +#include <linux/mfd/core.h> > > > > Please refrain from using the MFD API outside of drivers/mfd. > > > > If you need an MFD driver, please separate it out. > > > > If not, please replace it with the platform_*() API instead. > > There is precedent for MFD devices under platform/: > > drivers/platform/x86/intel/int3472/tps68470.c > > As well as other examples in the tree: > > drivers/firmware/xilinx/zynqmp.c > drivers/iio/common/ssp_sensors/ssp_dev.c > drivers/misc/cardreader/alcor_pci.c > drivers/misc/cardreader/rtsx_pcr.c > drivers/misc/cardreader/rtsx_usb.c > drivers/soc/samsung/exynos-pmu.c > drivers/staging/nvec/nvec.c I'm aware of the previous offences. They each slipped-in before I could catch them. Ideally I'd like to reverse the act. However, finding time for such low-priority activities has proved challenging. I only noticed *this* occurrence due to the MFD header file. > Since it's a driver for a platform-specific firmware service, I thought > it made more sense in platform/ than mfd/. It's using the MFD API > because the firmware exposes multiple subsystems, and this maps very > nicely to the MFD model - NIHing that scaffolding would require a whole > bunch of custom matching/device creation code. I'm also aware of the convenience value of {ab}using the MFD API. > But it's not exactly your > typical MFD device (it's not even a separate chip, it's part of the main > SoC), so I'm not sure if it really belongs in mfd/ from an > organizational standpoint? There is a strong argument for all SoCs to be classed as (massive) MFDs. However seeing as they represent more of a whole platform, rather than an add-on chip, we have had the sense to represent them differently. Some such submissions I have made explicit requests to be moved form drivers/mfd *into* drivers/platform in the past. Most SoCs are solely represented in DT, omitting the requirement for subsequent device registration. Have you considered this? If so, why does this not suit your use-case? The long and the short of it is; if you wish to treat this device, or at least a section of it, as a type of MFD, then please draft that part of it as an MFD driver, residing in drivers/mfd. If it's "not really an MFD", then find another way to represent the conglomeration please. If the MFD route is the best, then you can register each of the devices, including the *-core from drivers/mfd. Grep for "cross-ec" as a relatively recently good example. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 12:31 ` Lee Jones @ 2022-09-08 12:58 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-08 12:58 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 08/09/2022 21.31, Lee Jones wrote: > On Thu, 08 Sep 2022, Hector Martin wrote: >> But it's not exactly your >> typical MFD device (it's not even a separate chip, it's part of the main >> SoC), so I'm not sure if it really belongs in mfd/ from an >> organizational standpoint? > > There is a strong argument for all SoCs to be classed as (massive) > MFDs. However seeing as they represent more of a whole platform, > rather than an add-on chip, we have had the sense to represent them > differently. Some such submissions I have made explicit requests to be > moved form drivers/mfd *into* drivers/platform in the past. > > Most SoCs are solely represented in DT, omitting the requirement for > subsequent device registration. Have you considered this? If so, why > does this not suit your use-case? This driver and a subset of its sub-drivers are intended to generalize (via different backends, but no changes to sub-drivers) to legacy and T2 Mac platforms, eventually superseding applesmc (which is in hwmon/ because it started out as that, but has now grown random features and is quite a mess). Those are are Intel/UEFI machines and not DT platforms, and on those the SMC is actually a separate chip in some form (much like an EC). > The long and the short of it is; if you wish to treat this device, or > at least a section of it, as a type of MFD, then please draft that > part of it as an MFD driver, residing in drivers/mfd. If it's "not > really an MFD", then find another way to represent the conglomeration > please. > > If the MFD route is the best, then you can register each of the > devices, including the *-core from drivers/mfd. Grep for "cross-ec" > as a relatively recently good example. I think cros-ec is similar enough, yeah. As long as you don't mind having the core codebase in mfd/ (4 files: core, rtkit backend, and future T2 and legacy backends) we can do that. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 12:58 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-08 12:58 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 08/09/2022 21.31, Lee Jones wrote: > On Thu, 08 Sep 2022, Hector Martin wrote: >> But it's not exactly your >> typical MFD device (it's not even a separate chip, it's part of the main >> SoC), so I'm not sure if it really belongs in mfd/ from an >> organizational standpoint? > > There is a strong argument for all SoCs to be classed as (massive) > MFDs. However seeing as they represent more of a whole platform, > rather than an add-on chip, we have had the sense to represent them > differently. Some such submissions I have made explicit requests to be > moved form drivers/mfd *into* drivers/platform in the past. > > Most SoCs are solely represented in DT, omitting the requirement for > subsequent device registration. Have you considered this? If so, why > does this not suit your use-case? This driver and a subset of its sub-drivers are intended to generalize (via different backends, but no changes to sub-drivers) to legacy and T2 Mac platforms, eventually superseding applesmc (which is in hwmon/ because it started out as that, but has now grown random features and is quite a mess). Those are are Intel/UEFI machines and not DT platforms, and on those the SMC is actually a separate chip in some form (much like an EC). > The long and the short of it is; if you wish to treat this device, or > at least a section of it, as a type of MFD, then please draft that > part of it as an MFD driver, residing in drivers/mfd. If it's "not > really an MFD", then find another way to represent the conglomeration > please. > > If the MFD route is the best, then you can register each of the > devices, including the *-core from drivers/mfd. Grep for "cross-ec" > as a relatively recently good example. I think cros-ec is similar enough, yeah. As long as you don't mind having the core codebase in mfd/ (4 files: core, rtkit backend, and future T2 and legacy backends) we can do that. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 12:58 ` Hector Martin @ 2022-09-08 13:29 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-08 13:29 UTC (permalink / raw) To: Hector Martin Cc: Lee Jones, Russell King, Arnd Bergmann, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, Sep 8, 2022 at 2:58 PM Hector Martin <marcan@marcan.st> wrote: > > If the MFD route is the best, then you can register each of the > > devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > as a relatively recently good example. > > I think cros-ec is similar enough, yeah. As long as you don't mind > having the core codebase in mfd/ (4 files: core, rtkit backend, and > future T2 and legacy backends) we can do that. I'd even suggest its own subfolder under MFD, if you already know that there will likely be more than these 4 files. Though nothing else has a subdirectory in MFD right now so maybe Lee should approve of that first... The obvious upside to using MFD is that it has an active maintainer and patches get reviewed and merged swiftly, whereas drivers/platform is usually managed by SoC and x86 tip maintainers and what not. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 13:29 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-08 13:29 UTC (permalink / raw) To: Hector Martin Cc: Lee Jones, Russell King, Arnd Bergmann, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, Sep 8, 2022 at 2:58 PM Hector Martin <marcan@marcan.st> wrote: > > If the MFD route is the best, then you can register each of the > > devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > as a relatively recently good example. > > I think cros-ec is similar enough, yeah. As long as you don't mind > having the core codebase in mfd/ (4 files: core, rtkit backend, and > future T2 and legacy backends) we can do that. I'd even suggest its own subfolder under MFD, if you already know that there will likely be more than these 4 files. Though nothing else has a subdirectory in MFD right now so maybe Lee should approve of that first... The obvious upside to using MFD is that it has an active maintainer and patches get reviewed and merged swiftly, whereas drivers/platform is usually managed by SoC and x86 tip maintainers and what not. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 12:58 ` Hector Martin @ 2022-09-08 13:36 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-08 13:36 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 08 Sep 2022, Hector Martin wrote: > On 08/09/2022 21.31, Lee Jones wrote: > > On Thu, 08 Sep 2022, Hector Martin wrote: > >> But it's not exactly your > >> typical MFD device (it's not even a separate chip, it's part of the main > >> SoC), so I'm not sure if it really belongs in mfd/ from an > >> organizational standpoint? > > > > There is a strong argument for all SoCs to be classed as (massive) > > MFDs. However seeing as they represent more of a whole platform, > > rather than an add-on chip, we have had the sense to represent them > > differently. Some such submissions I have made explicit requests to be > > moved form drivers/mfd *into* drivers/platform in the past. > > > > Most SoCs are solely represented in DT, omitting the requirement for > > subsequent device registration. Have you considered this? If so, why > > does this not suit your use-case? > > This driver and a subset of its sub-drivers are intended to generalize > (via different backends, but no changes to sub-drivers) to legacy and T2 > Mac platforms, eventually superseding applesmc (which is in hwmon/ > because it started out as that, but has now grown random features and is > quite a mess). Those are are Intel/UEFI machines and not DT platforms, > and on those the SMC is actually a separate chip in some form (much like > an EC). Understood. Fair point. > > The long and the short of it is; if you wish to treat this device, or > > at least a section of it, as a type of MFD, then please draft that > > part of it as an MFD driver, residing in drivers/mfd. If it's "not > > really an MFD", then find another way to represent the conglomeration > > please. > > > > If the MFD route is the best, then you can register each of the > > devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > as a relatively recently good example. > > I think cros-ec is similar enough, yeah. As long as you don't mind > having the core codebase in mfd/ (4 files: core, rtkit backend, and > future T2 and legacy backends) we can do that. That's actually not what I'm suggesting. You *only* need to move the subsequent-device-registration handling into drivers/mfd. The remainder really should be treated as Platform (not to be confused with Arch Platform) code and should reside in drivers/platform. Just as we do with cros-ec. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 13:36 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-08 13:36 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 08 Sep 2022, Hector Martin wrote: > On 08/09/2022 21.31, Lee Jones wrote: > > On Thu, 08 Sep 2022, Hector Martin wrote: > >> But it's not exactly your > >> typical MFD device (it's not even a separate chip, it's part of the main > >> SoC), so I'm not sure if it really belongs in mfd/ from an > >> organizational standpoint? > > > > There is a strong argument for all SoCs to be classed as (massive) > > MFDs. However seeing as they represent more of a whole platform, > > rather than an add-on chip, we have had the sense to represent them > > differently. Some such submissions I have made explicit requests to be > > moved form drivers/mfd *into* drivers/platform in the past. > > > > Most SoCs are solely represented in DT, omitting the requirement for > > subsequent device registration. Have you considered this? If so, why > > does this not suit your use-case? > > This driver and a subset of its sub-drivers are intended to generalize > (via different backends, but no changes to sub-drivers) to legacy and T2 > Mac platforms, eventually superseding applesmc (which is in hwmon/ > because it started out as that, but has now grown random features and is > quite a mess). Those are are Intel/UEFI machines and not DT platforms, > and on those the SMC is actually a separate chip in some form (much like > an EC). Understood. Fair point. > > The long and the short of it is; if you wish to treat this device, or > > at least a section of it, as a type of MFD, then please draft that > > part of it as an MFD driver, residing in drivers/mfd. If it's "not > > really an MFD", then find another way to represent the conglomeration > > please. > > > > If the MFD route is the best, then you can register each of the > > devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > as a relatively recently good example. > > I think cros-ec is similar enough, yeah. As long as you don't mind > having the core codebase in mfd/ (4 files: core, rtkit backend, and > future T2 and legacy backends) we can do that. That's actually not what I'm suggesting. You *only* need to move the subsequent-device-registration handling into drivers/mfd. The remainder really should be treated as Platform (not to be confused with Arch Platform) code and should reside in drivers/platform. Just as we do with cros-ec. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 13:36 ` Lee Jones @ 2022-09-08 13:58 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-08 13:58 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 08/09/2022 22.36, Lee Jones wrote: > On Thu, 08 Sep 2022, Hector Martin wrote: > >> On 08/09/2022 21.31, Lee Jones wrote: >>> The long and the short of it is; if you wish to treat this device, or >>> at least a section of it, as a type of MFD, then please draft that >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not >>> really an MFD", then find another way to represent the conglomeration >>> please. >>> >>> If the MFD route is the best, then you can register each of the >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" >>> as a relatively recently good example. >> >> I think cros-ec is similar enough, yeah. As long as you don't mind >> having the core codebase in mfd/ (4 files: core, rtkit backend, and >> future T2 and legacy backends) we can do that. > > That's actually not what I'm suggesting. > > You *only* need to move the subsequent-device-registration handling > into drivers/mfd. The remainder really should be treated as Platform > (not to be confused with Arch Platform) code and should reside in > drivers/platform. Just as we do with cros-ec. That's... an interesting approach. Is the code in drivers/mfd supposed to be a subdevice itself? That seems to be what's going on with cros_ec_dev.c, but do we really need that layer of indirection? What's the point of just having effectively an array of mfd_cell and wrappers to call into the mfd core in the drivers/mfd/ tree and the rest of the driver elsewhere? - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-08 13:58 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-08 13:58 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 08/09/2022 22.36, Lee Jones wrote: > On Thu, 08 Sep 2022, Hector Martin wrote: > >> On 08/09/2022 21.31, Lee Jones wrote: >>> The long and the short of it is; if you wish to treat this device, or >>> at least a section of it, as a type of MFD, then please draft that >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not >>> really an MFD", then find another way to represent the conglomeration >>> please. >>> >>> If the MFD route is the best, then you can register each of the >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" >>> as a relatively recently good example. >> >> I think cros-ec is similar enough, yeah. As long as you don't mind >> having the core codebase in mfd/ (4 files: core, rtkit backend, and >> future T2 and legacy backends) we can do that. > > That's actually not what I'm suggesting. > > You *only* need to move the subsequent-device-registration handling > into drivers/mfd. The remainder really should be treated as Platform > (not to be confused with Arch Platform) code and should reside in > drivers/platform. Just as we do with cros-ec. That's... an interesting approach. Is the code in drivers/mfd supposed to be a subdevice itself? That seems to be what's going on with cros_ec_dev.c, but do we really need that layer of indirection? What's the point of just having effectively an array of mfd_cell and wrappers to call into the mfd core in the drivers/mfd/ tree and the rest of the driver elsewhere? - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-08 13:58 ` Hector Martin @ 2022-09-09 7:50 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-09 7:50 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 08 Sep 2022, Hector Martin wrote: > On 08/09/2022 22.36, Lee Jones wrote: > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > >> On 08/09/2022 21.31, Lee Jones wrote: > >>> The long and the short of it is; if you wish to treat this device, or > >>> at least a section of it, as a type of MFD, then please draft that > >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not > >>> really an MFD", then find another way to represent the conglomeration > >>> please. > >>> > >>> If the MFD route is the best, then you can register each of the > >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" > >>> as a relatively recently good example. > >> > >> I think cros-ec is similar enough, yeah. As long as you don't mind > >> having the core codebase in mfd/ (4 files: core, rtkit backend, and > >> future T2 and legacy backends) we can do that. > > > > That's actually not what I'm suggesting. > > > > You *only* need to move the subsequent-device-registration handling > > into drivers/mfd. The remainder really should be treated as Platform > > (not to be confused with Arch Platform) code and should reside in > > drivers/platform. Just as we do with cros-ec. > > That's... an interesting approach. How you decide to initially architect it would be your choice. We can then discuss any potential improvements / suggestions. > Is the code in drivers/mfd supposed > to be a subdevice itself? That seems to be what's going on with > cros_ec_dev.c, but do we really need that layer of indirection? Ideally not. The evolution of cros-ec happened over many iterations and much time. Initially it was almost entirely implemented in drivers/mfd until I requested for a lot of the truly platform code to be moved out, as it grew beyond the bounds of, and was therefore no longer relevant to MFD. If we were to design and build it up again from scratch, I'd suggest that the MFD part would be the core-driver / entry-point. That driver should request and initialise shared resources and register the other devices, which is essentially the MFD's mantra. > What's the point of just having effectively an array of mfd_cell and > wrappers to call into the mfd core in the drivers/mfd/ tree and the > rest of the driver elsewhere? They should be separate drivers, with MFD registering the Platform. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-09 7:50 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-09 7:50 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Thu, 08 Sep 2022, Hector Martin wrote: > On 08/09/2022 22.36, Lee Jones wrote: > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > >> On 08/09/2022 21.31, Lee Jones wrote: > >>> The long and the short of it is; if you wish to treat this device, or > >>> at least a section of it, as a type of MFD, then please draft that > >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not > >>> really an MFD", then find another way to represent the conglomeration > >>> please. > >>> > >>> If the MFD route is the best, then you can register each of the > >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" > >>> as a relatively recently good example. > >> > >> I think cros-ec is similar enough, yeah. As long as you don't mind > >> having the core codebase in mfd/ (4 files: core, rtkit backend, and > >> future T2 and legacy backends) we can do that. > > > > That's actually not what I'm suggesting. > > > > You *only* need to move the subsequent-device-registration handling > > into drivers/mfd. The remainder really should be treated as Platform > > (not to be confused with Arch Platform) code and should reside in > > drivers/platform. Just as we do with cros-ec. > > That's... an interesting approach. How you decide to initially architect it would be your choice. We can then discuss any potential improvements / suggestions. > Is the code in drivers/mfd supposed > to be a subdevice itself? That seems to be what's going on with > cros_ec_dev.c, but do we really need that layer of indirection? Ideally not. The evolution of cros-ec happened over many iterations and much time. Initially it was almost entirely implemented in drivers/mfd until I requested for a lot of the truly platform code to be moved out, as it grew beyond the bounds of, and was therefore no longer relevant to MFD. If we were to design and build it up again from scratch, I'd suggest that the MFD part would be the core-driver / entry-point. That driver should request and initialise shared resources and register the other devices, which is essentially the MFD's mantra. > What's the point of just having effectively an array of mfd_cell and > wrappers to call into the mfd core in the drivers/mfd/ tree and the > rest of the driver elsewhere? They should be separate drivers, with MFD registering the Platform. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-09 7:50 ` Lee Jones @ 2022-09-12 10:03 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-12 10:03 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: > On Thu, 08 Sep 2022, Hector Martin wrote: > > > On 08/09/2022 22.36, Lee Jones wrote: > > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > > > >> On 08/09/2022 21.31, Lee Jones wrote: > > >>> The long and the short of it is; if you wish to treat this device, or > > >>> at least a section of it, as a type of MFD, then please draft that > > >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not > > >>> really an MFD", then find another way to represent the conglomeration > > >>> please. > > >>> > > >>> If the MFD route is the best, then you can register each of the > > >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > >>> as a relatively recently good example. > > >> > > >> I think cros-ec is similar enough, yeah. As long as you don't mind > > >> having the core codebase in mfd/ (4 files: core, rtkit backend, and > > >> future T2 and legacy backends) we can do that. > > > > > > That's actually not what I'm suggesting. > > > > > > You *only* need to move the subsequent-device-registration handling > > > into drivers/mfd. The remainder really should be treated as Platform > > > (not to be confused with Arch Platform) code and should reside in > > > drivers/platform. Just as we do with cros-ec. > > > > That's... an interesting approach. > > How you decide to initially architect it would be your choice. > > We can then discuss any potential improvements / suggestions. > > > Is the code in drivers/mfd supposed > > to be a subdevice itself? That seems to be what's going on with > > cros_ec_dev.c, but do we really need that layer of indirection? > > Ideally not. The evolution of cros-ec happened over many iterations > and much time. Initially it was almost entirely implemented in > drivers/mfd until I requested for a lot of the truly platform code to > be moved out, as it grew beyond the bounds of, and was therefore no > longer relevant to MFD. > > If we were to design and build it up again from scratch, I'd suggest > that the MFD part would be the core-driver / entry-point. That driver > should request and initialise shared resources and register the other > devices, which is essentially the MFD's mantra. > > > What's the point of just having effectively an array of mfd_cell and > > wrappers to call into the mfd core in the drivers/mfd/ tree and the > > rest of the driver elsewhere? > > They should be separate drivers, with MFD registering the Platform. I'm guessing this series is now dead, and Hector needs to re-spin the patch set according to your views. I'm guessing this is going to take a major re-work of the patch series. I suspect my attempt and trying to get this upstream has made things more complicated, because I doubt Hector has updated his patch set with the review comments that have been made so far... so this is now quite a mess. I think, once this is sorted, the entire series will need to be re-reviewed entirely afresh. I've also completely lost where I was in updating the patches with all the discussion on this posting of the patch set (which is why I posted v2, because I couldn't keep track of all the emails on this version.) When I posted v2, I had already lost track, which is why it got posted. Sorry. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-12 10:03 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-12 10:03 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: > On Thu, 08 Sep 2022, Hector Martin wrote: > > > On 08/09/2022 22.36, Lee Jones wrote: > > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > > > >> On 08/09/2022 21.31, Lee Jones wrote: > > >>> The long and the short of it is; if you wish to treat this device, or > > >>> at least a section of it, as a type of MFD, then please draft that > > >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not > > >>> really an MFD", then find another way to represent the conglomeration > > >>> please. > > >>> > > >>> If the MFD route is the best, then you can register each of the > > >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > >>> as a relatively recently good example. > > >> > > >> I think cros-ec is similar enough, yeah. As long as you don't mind > > >> having the core codebase in mfd/ (4 files: core, rtkit backend, and > > >> future T2 and legacy backends) we can do that. > > > > > > That's actually not what I'm suggesting. > > > > > > You *only* need to move the subsequent-device-registration handling > > > into drivers/mfd. The remainder really should be treated as Platform > > > (not to be confused with Arch Platform) code and should reside in > > > drivers/platform. Just as we do with cros-ec. > > > > That's... an interesting approach. > > How you decide to initially architect it would be your choice. > > We can then discuss any potential improvements / suggestions. > > > Is the code in drivers/mfd supposed > > to be a subdevice itself? That seems to be what's going on with > > cros_ec_dev.c, but do we really need that layer of indirection? > > Ideally not. The evolution of cros-ec happened over many iterations > and much time. Initially it was almost entirely implemented in > drivers/mfd until I requested for a lot of the truly platform code to > be moved out, as it grew beyond the bounds of, and was therefore no > longer relevant to MFD. > > If we were to design and build it up again from scratch, I'd suggest > that the MFD part would be the core-driver / entry-point. That driver > should request and initialise shared resources and register the other > devices, which is essentially the MFD's mantra. > > > What's the point of just having effectively an array of mfd_cell and > > wrappers to call into the mfd core in the drivers/mfd/ tree and the > > rest of the driver elsewhere? > > They should be separate drivers, with MFD registering the Platform. I'm guessing this series is now dead, and Hector needs to re-spin the patch set according to your views. I'm guessing this is going to take a major re-work of the patch series. I suspect my attempt and trying to get this upstream has made things more complicated, because I doubt Hector has updated his patch set with the review comments that have been made so far... so this is now quite a mess. I think, once this is sorted, the entire series will need to be re-reviewed entirely afresh. I've also completely lost where I was in updating the patches with all the discussion on this posting of the patch set (which is why I posted v2, because I couldn't keep track of all the emails on this version.) When I posted v2, I had already lost track, which is why it got posted. Sorry. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-12 10:03 ` Russell King (Oracle) @ 2022-09-12 10:55 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-12 10:55 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 12 Sep 2022, Russell King (Oracle) wrote: > On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > > > On 08/09/2022 22.36, Lee Jones wrote: > > > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > > > > > >> On 08/09/2022 21.31, Lee Jones wrote: > > > >>> The long and the short of it is; if you wish to treat this device, or > > > >>> at least a section of it, as a type of MFD, then please draft that > > > >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not > > > >>> really an MFD", then find another way to represent the conglomeration > > > >>> please. > > > >>> > > > >>> If the MFD route is the best, then you can register each of the > > > >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > > >>> as a relatively recently good example. > > > >> > > > >> I think cros-ec is similar enough, yeah. As long as you don't mind > > > >> having the core codebase in mfd/ (4 files: core, rtkit backend, and > > > >> future T2 and legacy backends) we can do that. > > > > > > > > That's actually not what I'm suggesting. > > > > > > > > You *only* need to move the subsequent-device-registration handling > > > > into drivers/mfd. The remainder really should be treated as Platform > > > > (not to be confused with Arch Platform) code and should reside in > > > > drivers/platform. Just as we do with cros-ec. > > > > > > That's... an interesting approach. > > > > How you decide to initially architect it would be your choice. > > > > We can then discuss any potential improvements / suggestions. > > > > > Is the code in drivers/mfd supposed > > > to be a subdevice itself? That seems to be what's going on with > > > cros_ec_dev.c, but do we really need that layer of indirection? > > > > Ideally not. The evolution of cros-ec happened over many iterations > > and much time. Initially it was almost entirely implemented in > > drivers/mfd until I requested for a lot of the truly platform code to > > be moved out, as it grew beyond the bounds of, and was therefore no > > longer relevant to MFD. > > > > If we were to design and build it up again from scratch, I'd suggest > > that the MFD part would be the core-driver / entry-point. That driver > > should request and initialise shared resources and register the other > > devices, which is essentially the MFD's mantra. > > > > > What's the point of just having effectively an array of mfd_cell and > > > wrappers to call into the mfd core in the drivers/mfd/ tree and the > > > rest of the driver elsewhere? > > > > They should be separate drivers, with MFD registering the Platform. > > I'm guessing this series is now dead, and Hector needs to re-spin the > patch set according to your views. I'm guessing this is going to take > a major re-work of the patch series. > > I suspect my attempt and trying to get this upstream has made things > more complicated, because I doubt Hector has updated his patch set > with the review comments that have been made so far... so this is > now quite a mess. I think, once this is sorted, the entire series > will need to be re-reviewed entirely afresh. I have no insight into what Hector is doing, or plans to do. > I've also completely lost where I was in updating the patches with > all the discussion on this posting of the patch set (which is why I > posted v2, because I couldn't keep track of all the emails on this > version.) When I posted v2, I had already lost track, which is why > it got posted. Apologies if this has hindered your good work. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-09-12 10:55 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-09-12 10:55 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 12 Sep 2022, Russell King (Oracle) wrote: > On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > > > On 08/09/2022 22.36, Lee Jones wrote: > > > > On Thu, 08 Sep 2022, Hector Martin wrote: > > > > > > > >> On 08/09/2022 21.31, Lee Jones wrote: > > > >>> The long and the short of it is; if you wish to treat this device, or > > > >>> at least a section of it, as a type of MFD, then please draft that > > > >>> part of it as an MFD driver, residing in drivers/mfd. If it's "not > > > >>> really an MFD", then find another way to represent the conglomeration > > > >>> please. > > > >>> > > > >>> If the MFD route is the best, then you can register each of the > > > >>> devices, including the *-core from drivers/mfd. Grep for "cross-ec" > > > >>> as a relatively recently good example. > > > >> > > > >> I think cros-ec is similar enough, yeah. As long as you don't mind > > > >> having the core codebase in mfd/ (4 files: core, rtkit backend, and > > > >> future T2 and legacy backends) we can do that. > > > > > > > > That's actually not what I'm suggesting. > > > > > > > > You *only* need to move the subsequent-device-registration handling > > > > into drivers/mfd. The remainder really should be treated as Platform > > > > (not to be confused with Arch Platform) code and should reside in > > > > drivers/platform. Just as we do with cros-ec. > > > > > > That's... an interesting approach. > > > > How you decide to initially architect it would be your choice. > > > > We can then discuss any potential improvements / suggestions. > > > > > Is the code in drivers/mfd supposed > > > to be a subdevice itself? That seems to be what's going on with > > > cros_ec_dev.c, but do we really need that layer of indirection? > > > > Ideally not. The evolution of cros-ec happened over many iterations > > and much time. Initially it was almost entirely implemented in > > drivers/mfd until I requested for a lot of the truly platform code to > > be moved out, as it grew beyond the bounds of, and was therefore no > > longer relevant to MFD. > > > > If we were to design and build it up again from scratch, I'd suggest > > that the MFD part would be the core-driver / entry-point. That driver > > should request and initialise shared resources and register the other > > devices, which is essentially the MFD's mantra. > > > > > What's the point of just having effectively an array of mfd_cell and > > > wrappers to call into the mfd core in the drivers/mfd/ tree and the > > > rest of the driver elsewhere? > > > > They should be separate drivers, with MFD registering the Platform. > > I'm guessing this series is now dead, and Hector needs to re-spin the > patch set according to your views. I'm guessing this is going to take > a major re-work of the patch series. > > I suspect my attempt and trying to get this upstream has made things > more complicated, because I doubt Hector has updated his patch set > with the review comments that have been made so far... so this is > now quite a mess. I think, once this is sorted, the entire series > will need to be re-reviewed entirely afresh. I have no insight into what Hector is doing, or plans to do. > I've also completely lost where I was in updating the patches with > all the discussion on this posting of the patch set (which is why I > posted v2, because I couldn't keep track of all the emails on this > version.) When I posted v2, I had already lost track, which is why > it got posted. Apologies if this has hindered your good work. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-12 10:55 ` Lee Jones @ 2022-10-28 15:36 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-28 15:36 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > I'm guessing this series is now dead, and Hector needs to re-spin the > > patch set according to your views. I'm guessing this is going to take > > a major re-work of the patch series. > > > > I suspect my attempt and trying to get this upstream has made things > > more complicated, because I doubt Hector has updated his patch set > > with the review comments that have been made so far... so this is > > now quite a mess. I think, once this is sorted, the entire series > > will need to be re-reviewed entirely afresh. > > I have no insight into what Hector is doing, or plans to do. It seems there's no plans by Hector to address this, so it comes down to me. So, guessing what you're after, would something like the following work for you? I don't see *any* point in creating more yet more platform devices unless we're on a mission to maximise wasted memory resources (which this split will already be doing by creating two small modules instead of one.) Obviously, this is not an official patch yet, it's just to find out what code structure you are looking for. diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 78c6d9d99c3f..8d4c0508a2c8 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o +obj-$(CONFIG_APPLE_SMC) += apple-smc.o + obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c new file mode 100644 index 000000000000..bc59d1c5e13d --- /dev/null +++ b/drivers/mfd/apple-smc.c @@ -0,0 +1,38 @@ +#include <linux/mfd/core.h> +#include <linux/mfd/apple-smc.h> + +static const struct mfd_cell apple_smc_devs[] = { + { + .name = "macsmc-gpio", + .of_compatible = "apple,smc-gpio", + }, + { + .name = "macsmc-hid", + }, + { + .name = "macsmc-power", + }, + { + .name = "macsmc-reboot", + }, + { + .name = "macsmc-rtc", + }, +}; + +int apple_smc_mfd_probe(struct device *dev) +{ + return mfd_add_devices(dev, -1, apple_smc_devs, + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); +} +EXPORT_SYMBOL(apple_smc_mfd_probe); + +void apple_smc_mfd_remove(struct device *dev) +{ + mfd_remove_devices(dev); +} +EXPORT_SYMBOL(apple_smc_mfd_remove); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC MFD core"); diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c index 148a3f8173d3..d4a502835b27 100644 --- a/drivers/platform/apple/smc_core.c +++ b/drivers/platform/apple/smc_core.c @@ -5,7 +5,7 @@ */ #include <linux/device.h> -#include <linux/mfd/core.h> +#include <linux/mfd/apple-smc.h> #include <linux/mutex.h> #include <linux/notifier.h> #include "smc.h" @@ -25,25 +25,6 @@ struct apple_smc { struct blocking_notifier_head event_handlers; }; -static const struct mfd_cell apple_smc_devs[] = { - { - .name = "macsmc-gpio", - .of_compatible = "apple,smc-gpio", - }, - { - .name = "macsmc-hid", - }, - { - .name = "macsmc-power", - }, - { - .name = "macsmc-reboot", - }, - { - .name = "macsmc-rtc", - }, -}; - int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) { int ret; @@ -226,7 +207,7 @@ struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_bac dev_set_drvdata(dev, smc); - ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); + ret = apple_smc_mfd_probe(dev); if (ret) return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); @@ -236,7 +217,7 @@ EXPORT_SYMBOL(apple_smc_probe); int apple_smc_remove(struct apple_smc *smc) { - mfd_remove_devices(smc->dev); + apple_smc_mfd_remove(smc->dev); /* Disable notifications */ apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); diff --git a/include/linux/mfd/apple-smc.h b/include/linux/mfd/apple-smc.h new file mode 100644 index 000000000000..2f34ca0f07f3 --- /dev/null +++ b/include/linux/mfd/apple-smc.h @@ -0,0 +1,9 @@ +#ifndef LINUX_MFD_APPLE_SMC_H +#define LINUX_MFD_APPLE_SMC_H + +struct device; + +int apple_smc_mfd_probe(struct device *dev); +void apple_smc_mfd_remove(struct device *dev); + +#endif -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-28 15:36 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-28 15:36 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > I'm guessing this series is now dead, and Hector needs to re-spin the > > patch set according to your views. I'm guessing this is going to take > > a major re-work of the patch series. > > > > I suspect my attempt and trying to get this upstream has made things > > more complicated, because I doubt Hector has updated his patch set > > with the review comments that have been made so far... so this is > > now quite a mess. I think, once this is sorted, the entire series > > will need to be re-reviewed entirely afresh. > > I have no insight into what Hector is doing, or plans to do. It seems there's no plans by Hector to address this, so it comes down to me. So, guessing what you're after, would something like the following work for you? I don't see *any* point in creating more yet more platform devices unless we're on a mission to maximise wasted memory resources (which this split will already be doing by creating two small modules instead of one.) Obviously, this is not an official patch yet, it's just to find out what code structure you are looking for. diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 78c6d9d99c3f..8d4c0508a2c8 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o +obj-$(CONFIG_APPLE_SMC) += apple-smc.o + obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c new file mode 100644 index 000000000000..bc59d1c5e13d --- /dev/null +++ b/drivers/mfd/apple-smc.c @@ -0,0 +1,38 @@ +#include <linux/mfd/core.h> +#include <linux/mfd/apple-smc.h> + +static const struct mfd_cell apple_smc_devs[] = { + { + .name = "macsmc-gpio", + .of_compatible = "apple,smc-gpio", + }, + { + .name = "macsmc-hid", + }, + { + .name = "macsmc-power", + }, + { + .name = "macsmc-reboot", + }, + { + .name = "macsmc-rtc", + }, +}; + +int apple_smc_mfd_probe(struct device *dev) +{ + return mfd_add_devices(dev, -1, apple_smc_devs, + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); +} +EXPORT_SYMBOL(apple_smc_mfd_probe); + +void apple_smc_mfd_remove(struct device *dev) +{ + mfd_remove_devices(dev); +} +EXPORT_SYMBOL(apple_smc_mfd_remove); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC MFD core"); diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c index 148a3f8173d3..d4a502835b27 100644 --- a/drivers/platform/apple/smc_core.c +++ b/drivers/platform/apple/smc_core.c @@ -5,7 +5,7 @@ */ #include <linux/device.h> -#include <linux/mfd/core.h> +#include <linux/mfd/apple-smc.h> #include <linux/mutex.h> #include <linux/notifier.h> #include "smc.h" @@ -25,25 +25,6 @@ struct apple_smc { struct blocking_notifier_head event_handlers; }; -static const struct mfd_cell apple_smc_devs[] = { - { - .name = "macsmc-gpio", - .of_compatible = "apple,smc-gpio", - }, - { - .name = "macsmc-hid", - }, - { - .name = "macsmc-power", - }, - { - .name = "macsmc-reboot", - }, - { - .name = "macsmc-rtc", - }, -}; - int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) { int ret; @@ -226,7 +207,7 @@ struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_bac dev_set_drvdata(dev, smc); - ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); + ret = apple_smc_mfd_probe(dev); if (ret) return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); @@ -236,7 +217,7 @@ EXPORT_SYMBOL(apple_smc_probe); int apple_smc_remove(struct apple_smc *smc) { - mfd_remove_devices(smc->dev); + apple_smc_mfd_remove(smc->dev); /* Disable notifications */ apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); diff --git a/include/linux/mfd/apple-smc.h b/include/linux/mfd/apple-smc.h new file mode 100644 index 000000000000..2f34ca0f07f3 --- /dev/null +++ b/include/linux/mfd/apple-smc.h @@ -0,0 +1,9 @@ +#ifndef LINUX_MFD_APPLE_SMC_H +#define LINUX_MFD_APPLE_SMC_H + +struct device; + +int apple_smc_mfd_probe(struct device *dev); +void apple_smc_mfd_remove(struct device *dev); + +#endif -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-28 15:36 ` Russell King (Oracle) @ 2022-10-31 8:46 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 8:46 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > patch set according to your views. I'm guessing this is going to take > > > a major re-work of the patch series. > > > > > > I suspect my attempt and trying to get this upstream has made things > > > more complicated, because I doubt Hector has updated his patch set > > > with the review comments that have been made so far... so this is > > > now quite a mess. I think, once this is sorted, the entire series > > > will need to be re-reviewed entirely afresh. > > > > I have no insight into what Hector is doing, or plans to do. > > It seems there's no plans by Hector to address this, so it comes down > to me. > > So, guessing what you're after, would something like the following > work for you? I don't see *any* point in creating more yet more > platform devices unless we're on a mission to maximise wasted memory > resources (which this split will already be doing by creating two > small modules instead of one.) > > Obviously, this is not an official patch yet, it's just to find out > what code structure you are looking for. > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 78c6d9d99c3f..8d4c0508a2c8 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > + > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > new file mode 100644 > index 000000000000..bc59d1c5e13d > --- /dev/null > +++ b/drivers/mfd/apple-smc.c > @@ -0,0 +1,38 @@ > +#include <linux/mfd/core.h> > +#include <linux/mfd/apple-smc.h> > + > +static const struct mfd_cell apple_smc_devs[] = { > + { > + .name = "macsmc-gpio", > + .of_compatible = "apple,smc-gpio", > + }, > + { > + .name = "macsmc-hid", > + }, > + { > + .name = "macsmc-power", > + }, > + { > + .name = "macsmc-reboot", > + }, > + { > + .name = "macsmc-rtc", > + }, > +}; > + > +int apple_smc_mfd_probe(struct device *dev) > +{ > + return mfd_add_devices(dev, -1, apple_smc_devs, > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > +} > +EXPORT_SYMBOL(apple_smc_mfd_probe); > + > +void apple_smc_mfd_remove(struct device *dev) > +{ > + mfd_remove_devices(dev); > +} > +EXPORT_SYMBOL(apple_smc_mfd_remove); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC MFD core"); Conceptually interesting, not seen this one before, but clearly a hack, no? Pretty sure all of the other cores in MFD are represented by a Platform Device. Why not implement the inverse? The Apple SMC is clearly an MFD, in Linux terms, so why not move the Platform Device into here, fetch all of the global resources, register the sub-devices, then call into the rtkit implementation in drivers/platform? -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 8:46 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 8:46 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > patch set according to your views. I'm guessing this is going to take > > > a major re-work of the patch series. > > > > > > I suspect my attempt and trying to get this upstream has made things > > > more complicated, because I doubt Hector has updated his patch set > > > with the review comments that have been made so far... so this is > > > now quite a mess. I think, once this is sorted, the entire series > > > will need to be re-reviewed entirely afresh. > > > > I have no insight into what Hector is doing, or plans to do. > > It seems there's no plans by Hector to address this, so it comes down > to me. > > So, guessing what you're after, would something like the following > work for you? I don't see *any* point in creating more yet more > platform devices unless we're on a mission to maximise wasted memory > resources (which this split will already be doing by creating two > small modules instead of one.) > > Obviously, this is not an official patch yet, it's just to find out > what code structure you are looking for. > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 78c6d9d99c3f..8d4c0508a2c8 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > + > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > new file mode 100644 > index 000000000000..bc59d1c5e13d > --- /dev/null > +++ b/drivers/mfd/apple-smc.c > @@ -0,0 +1,38 @@ > +#include <linux/mfd/core.h> > +#include <linux/mfd/apple-smc.h> > + > +static const struct mfd_cell apple_smc_devs[] = { > + { > + .name = "macsmc-gpio", > + .of_compatible = "apple,smc-gpio", > + }, > + { > + .name = "macsmc-hid", > + }, > + { > + .name = "macsmc-power", > + }, > + { > + .name = "macsmc-reboot", > + }, > + { > + .name = "macsmc-rtc", > + }, > +}; > + > +int apple_smc_mfd_probe(struct device *dev) > +{ > + return mfd_add_devices(dev, -1, apple_smc_devs, > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > +} > +EXPORT_SYMBOL(apple_smc_mfd_probe); > + > +void apple_smc_mfd_remove(struct device *dev) > +{ > + mfd_remove_devices(dev); > +} > +EXPORT_SYMBOL(apple_smc_mfd_remove); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC MFD core"); Conceptually interesting, not seen this one before, but clearly a hack, no? Pretty sure all of the other cores in MFD are represented by a Platform Device. Why not implement the inverse? The Apple SMC is clearly an MFD, in Linux terms, so why not move the Platform Device into here, fetch all of the global resources, register the sub-devices, then call into the rtkit implementation in drivers/platform? -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 8:46 ` Lee Jones @ 2022-10-31 9:03 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-31 9:03 UTC (permalink / raw) To: Lee Jones, Russell King (Oracle) Cc: Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 31/10/2022 17.46, Lee Jones wrote: > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > >> On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: >>>> I'm guessing this series is now dead, and Hector needs to re-spin the >>>> patch set according to your views. I'm guessing this is going to take >>>> a major re-work of the patch series. >>>> >>>> I suspect my attempt and trying to get this upstream has made things >>>> more complicated, because I doubt Hector has updated his patch set >>>> with the review comments that have been made so far... so this is >>>> now quite a mess. I think, once this is sorted, the entire series >>>> will need to be re-reviewed entirely afresh. >>> >>> I have no insight into what Hector is doing, or plans to do. >> >> It seems there's no plans by Hector to address this, so it comes down >> to me. >> >> So, guessing what you're after, would something like the following >> work for you? I don't see *any* point in creating more yet more >> platform devices unless we're on a mission to maximise wasted memory >> resources (which this split will already be doing by creating two >> small modules instead of one.) >> >> Obviously, this is not an official patch yet, it's just to find out >> what code structure you are looking for. >> >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index 78c6d9d99c3f..8d4c0508a2c8 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o >> obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o >> obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o >> >> +obj-$(CONFIG_APPLE_SMC) += apple-smc.o >> + >> obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o >> obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o >> >> diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c >> new file mode 100644 >> index 000000000000..bc59d1c5e13d >> --- /dev/null >> +++ b/drivers/mfd/apple-smc.c >> @@ -0,0 +1,38 @@ >> +#include <linux/mfd/core.h> >> +#include <linux/mfd/apple-smc.h> >> + >> +static const struct mfd_cell apple_smc_devs[] = { >> + { >> + .name = "macsmc-gpio", >> + .of_compatible = "apple,smc-gpio", >> + }, >> + { >> + .name = "macsmc-hid", >> + }, >> + { >> + .name = "macsmc-power", >> + }, >> + { >> + .name = "macsmc-reboot", >> + }, >> + { >> + .name = "macsmc-rtc", >> + }, >> +}; >> + >> +int apple_smc_mfd_probe(struct device *dev) >> +{ >> + return mfd_add_devices(dev, -1, apple_smc_devs, >> + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); >> +} >> +EXPORT_SYMBOL(apple_smc_mfd_probe); >> + >> +void apple_smc_mfd_remove(struct device *dev) >> +{ >> + mfd_remove_devices(dev); >> +} >> +EXPORT_SYMBOL(apple_smc_mfd_remove); >> + >> +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); >> +MODULE_LICENSE("Dual MIT/GPL"); >> +MODULE_DESCRIPTION("Apple SMC MFD core"); > > Conceptually interesting, not seen this one before, but clearly a > hack, no? Pretty sure all of the other cores in MFD are represented > by a Platform Device. > > Why not implement the inverse? The Apple SMC is clearly an MFD, in > Linux terms, so why not move the Platform Device into here, fetch all > of the global resources, register the sub-devices, then call into the > rtkit implementation in drivers/platform? Because the RTKit implementation is *one* of several possible backends, and the others aren't even necessarily platform devices, and may have their own registration requirements (e.g. probing for ACPI stuff on x86). The entry points are completely different depending on the flavor. They will have to be different modules that compile on different architectures and load based on completely different device IDs. This is common in Linux. There's the core xHCI driver, then an xhci-plat wrapper for platform devices, and an xhci-pci wrapper for PCI devices. It makes no sense to have the driver entry point be the core and then somehow call back out to xhci-pci and xhci-plat when those are different drivers with different match lists and different registration requirements. It sounds like you have a mental model of what you want for MFD that doesn't actually fit how hardware works, and you're trying to shoehorn this into it without thinking. Linux is perfectly capable of representing things in a way that works with this hardware, but you need to let go of this idea that "the mfd driver lives in drivers/mfd and is the entry point but also I don't want any platform/abstraction/silliness in there" because that just doesn't work. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 9:03 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-31 9:03 UTC (permalink / raw) To: Lee Jones, Russell King (Oracle) Cc: Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 31/10/2022 17.46, Lee Jones wrote: > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > >> On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: >>>> I'm guessing this series is now dead, and Hector needs to re-spin the >>>> patch set according to your views. I'm guessing this is going to take >>>> a major re-work of the patch series. >>>> >>>> I suspect my attempt and trying to get this upstream has made things >>>> more complicated, because I doubt Hector has updated his patch set >>>> with the review comments that have been made so far... so this is >>>> now quite a mess. I think, once this is sorted, the entire series >>>> will need to be re-reviewed entirely afresh. >>> >>> I have no insight into what Hector is doing, or plans to do. >> >> It seems there's no plans by Hector to address this, so it comes down >> to me. >> >> So, guessing what you're after, would something like the following >> work for you? I don't see *any* point in creating more yet more >> platform devices unless we're on a mission to maximise wasted memory >> resources (which this split will already be doing by creating two >> small modules instead of one.) >> >> Obviously, this is not an official patch yet, it's just to find out >> what code structure you are looking for. >> >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index 78c6d9d99c3f..8d4c0508a2c8 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o >> obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o >> obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o >> >> +obj-$(CONFIG_APPLE_SMC) += apple-smc.o >> + >> obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o >> obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o >> >> diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c >> new file mode 100644 >> index 000000000000..bc59d1c5e13d >> --- /dev/null >> +++ b/drivers/mfd/apple-smc.c >> @@ -0,0 +1,38 @@ >> +#include <linux/mfd/core.h> >> +#include <linux/mfd/apple-smc.h> >> + >> +static const struct mfd_cell apple_smc_devs[] = { >> + { >> + .name = "macsmc-gpio", >> + .of_compatible = "apple,smc-gpio", >> + }, >> + { >> + .name = "macsmc-hid", >> + }, >> + { >> + .name = "macsmc-power", >> + }, >> + { >> + .name = "macsmc-reboot", >> + }, >> + { >> + .name = "macsmc-rtc", >> + }, >> +}; >> + >> +int apple_smc_mfd_probe(struct device *dev) >> +{ >> + return mfd_add_devices(dev, -1, apple_smc_devs, >> + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); >> +} >> +EXPORT_SYMBOL(apple_smc_mfd_probe); >> + >> +void apple_smc_mfd_remove(struct device *dev) >> +{ >> + mfd_remove_devices(dev); >> +} >> +EXPORT_SYMBOL(apple_smc_mfd_remove); >> + >> +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); >> +MODULE_LICENSE("Dual MIT/GPL"); >> +MODULE_DESCRIPTION("Apple SMC MFD core"); > > Conceptually interesting, not seen this one before, but clearly a > hack, no? Pretty sure all of the other cores in MFD are represented > by a Platform Device. > > Why not implement the inverse? The Apple SMC is clearly an MFD, in > Linux terms, so why not move the Platform Device into here, fetch all > of the global resources, register the sub-devices, then call into the > rtkit implementation in drivers/platform? Because the RTKit implementation is *one* of several possible backends, and the others aren't even necessarily platform devices, and may have their own registration requirements (e.g. probing for ACPI stuff on x86). The entry points are completely different depending on the flavor. They will have to be different modules that compile on different architectures and load based on completely different device IDs. This is common in Linux. There's the core xHCI driver, then an xhci-plat wrapper for platform devices, and an xhci-pci wrapper for PCI devices. It makes no sense to have the driver entry point be the core and then somehow call back out to xhci-pci and xhci-plat when those are different drivers with different match lists and different registration requirements. It sounds like you have a mental model of what you want for MFD that doesn't actually fit how hardware works, and you're trying to shoehorn this into it without thinking. Linux is perfectly capable of representing things in a way that works with this hardware, but you need to let go of this idea that "the mfd driver lives in drivers/mfd and is the entry point but also I don't want any platform/abstraction/silliness in there" because that just doesn't work. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 8:46 ` Lee Jones @ 2022-10-31 9:44 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-31 9:44 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > patch set according to your views. I'm guessing this is going to take > > > > a major re-work of the patch series. > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > more complicated, because I doubt Hector has updated his patch set > > > > with the review comments that have been made so far... so this is > > > > now quite a mess. I think, once this is sorted, the entire series > > > > will need to be re-reviewed entirely afresh. > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > It seems there's no plans by Hector to address this, so it comes down > > to me. > > > > So, guessing what you're after, would something like the following > > work for you? I don't see *any* point in creating more yet more > > platform devices unless we're on a mission to maximise wasted memory > > resources (which this split will already be doing by creating two > > small modules instead of one.) > > > > Obviously, this is not an official patch yet, it's just to find out > > what code structure you are looking for. > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > --- a/drivers/mfd/Makefile > > +++ b/drivers/mfd/Makefile > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > + > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > new file mode 100644 > > index 000000000000..bc59d1c5e13d > > --- /dev/null > > +++ b/drivers/mfd/apple-smc.c > > @@ -0,0 +1,38 @@ > > +#include <linux/mfd/core.h> > > +#include <linux/mfd/apple-smc.h> > > + > > +static const struct mfd_cell apple_smc_devs[] = { > > + { > > + .name = "macsmc-gpio", > > + .of_compatible = "apple,smc-gpio", > > + }, > > + { > > + .name = "macsmc-hid", > > + }, > > + { > > + .name = "macsmc-power", > > + }, > > + { > > + .name = "macsmc-reboot", > > + }, > > + { > > + .name = "macsmc-rtc", > > + }, > > +}; > > + > > +int apple_smc_mfd_probe(struct device *dev) > > +{ > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > +} > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > + > > +void apple_smc_mfd_remove(struct device *dev) > > +{ > > + mfd_remove_devices(dev); > > +} > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > + > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > +MODULE_LICENSE("Dual MIT/GPL"); > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > Conceptually interesting, not seen this one before, but clearly a > hack, no? Pretty sure all of the other cores in MFD are represented > by a Platform Device. No one seems to understand what you actually want to see with the smc-core.c part, so I'm trying to find out what code structure would suit you. It seemed from the thread that moving smc-core.c to drivers/mfd wasn't desirable, but there was the desire to move the mfd bits into there - so that's what I've done with this patch. It doesn't make any sense what so ever to add yet another platform device into this structure with all of the complication around what happens if the user forces it to unbind, so I didn't. > Why not implement the inverse? What do you mean "the inverse" ? The inverse of this patch is moving everything of smc-core.c except the MFD bits into drivers/mfd leaving the MFD bits in drivers/platform/apple, which makes no sense. > The Apple SMC is clearly an MFD, in > Linux terms, so why not move the Platform Device into here, fetch all > of the global resources, register the sub-devices, then call into the > rtkit implementation in drivers/platform? I thought you had previously ruled out the idea of moving the contents of drivers/platform/apple into drivers/mfd, but maybe your position on that had changed through the course of the discussion. It's really not obvious to me what you want from what's been said in this thread. So, I ask the direct question - would moving the code that is in this patch set from drivers/platform/apple to drivers/mfd then make it acceptable to you? In other words: drivers/platform/apple/smc_core.c drivers/platform/apple/smc.h drivers/platform/apple/smc_rtkit.c If not, then please clearly and fully state what you want to see. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 9:44 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-31 9:44 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > patch set according to your views. I'm guessing this is going to take > > > > a major re-work of the patch series. > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > more complicated, because I doubt Hector has updated his patch set > > > > with the review comments that have been made so far... so this is > > > > now quite a mess. I think, once this is sorted, the entire series > > > > will need to be re-reviewed entirely afresh. > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > It seems there's no plans by Hector to address this, so it comes down > > to me. > > > > So, guessing what you're after, would something like the following > > work for you? I don't see *any* point in creating more yet more > > platform devices unless we're on a mission to maximise wasted memory > > resources (which this split will already be doing by creating two > > small modules instead of one.) > > > > Obviously, this is not an official patch yet, it's just to find out > > what code structure you are looking for. > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > --- a/drivers/mfd/Makefile > > +++ b/drivers/mfd/Makefile > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > + > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > new file mode 100644 > > index 000000000000..bc59d1c5e13d > > --- /dev/null > > +++ b/drivers/mfd/apple-smc.c > > @@ -0,0 +1,38 @@ > > +#include <linux/mfd/core.h> > > +#include <linux/mfd/apple-smc.h> > > + > > +static const struct mfd_cell apple_smc_devs[] = { > > + { > > + .name = "macsmc-gpio", > > + .of_compatible = "apple,smc-gpio", > > + }, > > + { > > + .name = "macsmc-hid", > > + }, > > + { > > + .name = "macsmc-power", > > + }, > > + { > > + .name = "macsmc-reboot", > > + }, > > + { > > + .name = "macsmc-rtc", > > + }, > > +}; > > + > > +int apple_smc_mfd_probe(struct device *dev) > > +{ > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > +} > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > + > > +void apple_smc_mfd_remove(struct device *dev) > > +{ > > + mfd_remove_devices(dev); > > +} > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > + > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > +MODULE_LICENSE("Dual MIT/GPL"); > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > Conceptually interesting, not seen this one before, but clearly a > hack, no? Pretty sure all of the other cores in MFD are represented > by a Platform Device. No one seems to understand what you actually want to see with the smc-core.c part, so I'm trying to find out what code structure would suit you. It seemed from the thread that moving smc-core.c to drivers/mfd wasn't desirable, but there was the desire to move the mfd bits into there - so that's what I've done with this patch. It doesn't make any sense what so ever to add yet another platform device into this structure with all of the complication around what happens if the user forces it to unbind, so I didn't. > Why not implement the inverse? What do you mean "the inverse" ? The inverse of this patch is moving everything of smc-core.c except the MFD bits into drivers/mfd leaving the MFD bits in drivers/platform/apple, which makes no sense. > The Apple SMC is clearly an MFD, in > Linux terms, so why not move the Platform Device into here, fetch all > of the global resources, register the sub-devices, then call into the > rtkit implementation in drivers/platform? I thought you had previously ruled out the idea of moving the contents of drivers/platform/apple into drivers/mfd, but maybe your position on that had changed through the course of the discussion. It's really not obvious to me what you want from what's been said in this thread. So, I ask the direct question - would moving the code that is in this patch set from drivers/platform/apple to drivers/mfd then make it acceptable to you? In other words: drivers/platform/apple/smc_core.c drivers/platform/apple/smc.h drivers/platform/apple/smc_rtkit.c If not, then please clearly and fully state what you want to see. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 9:44 ` Russell King (Oracle) @ 2022-10-31 17:24 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 17:24 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > > patch set according to your views. I'm guessing this is going to take > > > > > a major re-work of the patch series. > > > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > > more complicated, because I doubt Hector has updated his patch set > > > > > with the review comments that have been made so far... so this is > > > > > now quite a mess. I think, once this is sorted, the entire series > > > > > will need to be re-reviewed entirely afresh. > > > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > > > It seems there's no plans by Hector to address this, so it comes down > > > to me. > > > > > > So, guessing what you're after, would something like the following > > > work for you? I don't see *any* point in creating more yet more > > > platform devices unless we're on a mission to maximise wasted memory > > > resources (which this split will already be doing by creating two > > > small modules instead of one.) > > > > > > Obviously, this is not an official patch yet, it's just to find out > > > what code structure you are looking for. > > > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > > --- a/drivers/mfd/Makefile > > > +++ b/drivers/mfd/Makefile > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > > + > > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > > new file mode 100644 > > > index 000000000000..bc59d1c5e13d > > > --- /dev/null > > > +++ b/drivers/mfd/apple-smc.c > > > @@ -0,0 +1,38 @@ > > > +#include <linux/mfd/core.h> > > > +#include <linux/mfd/apple-smc.h> > > > + > > > +static const struct mfd_cell apple_smc_devs[] = { > > > + { > > > + .name = "macsmc-gpio", > > > + .of_compatible = "apple,smc-gpio", > > > + }, > > > + { > > > + .name = "macsmc-hid", > > > + }, > > > + { > > > + .name = "macsmc-power", > > > + }, > > > + { > > > + .name = "macsmc-reboot", > > > + }, > > > + { > > > + .name = "macsmc-rtc", > > > + }, > > > +}; > > > + > > > +int apple_smc_mfd_probe(struct device *dev) > > > +{ > > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > > +} > > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > > + > > > +void apple_smc_mfd_remove(struct device *dev) > > > +{ > > > + mfd_remove_devices(dev); > > > +} > > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > > + > > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > > +MODULE_LICENSE("Dual MIT/GPL"); > > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > > > Conceptually interesting, not seen this one before, but clearly a > > hack, no? Pretty sure all of the other cores in MFD are represented > > by a Platform Device. > > No one seems to understand what you actually want to see with the > smc-core.c part, so I'm trying to find out what code structure > would suit you. > > It seemed from the thread that moving smc-core.c to drivers/mfd > wasn't desirable, but there was the desire to move the mfd bits > into there - so that's what I've done with this patch. It doesn't > make any sense what so ever to add yet another platform device > into this structure with all of the complication around what happens > if the user forces it to unbind, so I didn't. > > > Why not implement the inverse? > > What do you mean "the inverse" ? The inverse of this patch is moving > everything of smc-core.c except the MFD bits into drivers/mfd leaving > the MFD bits in drivers/platform/apple, which makes no sense. > > > The Apple SMC is clearly an MFD, in > > Linux terms, so why not move the Platform Device into here, fetch all > > of the global resources, register the sub-devices, then call into the > > rtkit implementation in drivers/platform? > > I thought you had previously ruled out the idea of moving the contents > of drivers/platform/apple into drivers/mfd, but maybe your position on > that had changed through the course of the discussion. It's really not > obvious to me what you want from what's been said in this thread. > > So, I ask the direct question - would moving the code that is in this > patch set from drivers/platform/apple to drivers/mfd then make it > acceptable to you? In other words: > > drivers/platform/apple/smc_core.c > drivers/platform/apple/smc.h > drivers/platform/apple/smc_rtkit.c > > If not, then please clearly and fully state what you want to see. Sorry Russell, I'm out of time today. Please see my recent reply to Hector for now and I'll get back to you first thing. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 17:24 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 17:24 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > > patch set according to your views. I'm guessing this is going to take > > > > > a major re-work of the patch series. > > > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > > more complicated, because I doubt Hector has updated his patch set > > > > > with the review comments that have been made so far... so this is > > > > > now quite a mess. I think, once this is sorted, the entire series > > > > > will need to be re-reviewed entirely afresh. > > > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > > > It seems there's no plans by Hector to address this, so it comes down > > > to me. > > > > > > So, guessing what you're after, would something like the following > > > work for you? I don't see *any* point in creating more yet more > > > platform devices unless we're on a mission to maximise wasted memory > > > resources (which this split will already be doing by creating two > > > small modules instead of one.) > > > > > > Obviously, this is not an official patch yet, it's just to find out > > > what code structure you are looking for. > > > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > > --- a/drivers/mfd/Makefile > > > +++ b/drivers/mfd/Makefile > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > > + > > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > > new file mode 100644 > > > index 000000000000..bc59d1c5e13d > > > --- /dev/null > > > +++ b/drivers/mfd/apple-smc.c > > > @@ -0,0 +1,38 @@ > > > +#include <linux/mfd/core.h> > > > +#include <linux/mfd/apple-smc.h> > > > + > > > +static const struct mfd_cell apple_smc_devs[] = { > > > + { > > > + .name = "macsmc-gpio", > > > + .of_compatible = "apple,smc-gpio", > > > + }, > > > + { > > > + .name = "macsmc-hid", > > > + }, > > > + { > > > + .name = "macsmc-power", > > > + }, > > > + { > > > + .name = "macsmc-reboot", > > > + }, > > > + { > > > + .name = "macsmc-rtc", > > > + }, > > > +}; > > > + > > > +int apple_smc_mfd_probe(struct device *dev) > > > +{ > > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > > +} > > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > > + > > > +void apple_smc_mfd_remove(struct device *dev) > > > +{ > > > + mfd_remove_devices(dev); > > > +} > > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > > + > > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > > +MODULE_LICENSE("Dual MIT/GPL"); > > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > > > Conceptually interesting, not seen this one before, but clearly a > > hack, no? Pretty sure all of the other cores in MFD are represented > > by a Platform Device. > > No one seems to understand what you actually want to see with the > smc-core.c part, so I'm trying to find out what code structure > would suit you. > > It seemed from the thread that moving smc-core.c to drivers/mfd > wasn't desirable, but there was the desire to move the mfd bits > into there - so that's what I've done with this patch. It doesn't > make any sense what so ever to add yet another platform device > into this structure with all of the complication around what happens > if the user forces it to unbind, so I didn't. > > > Why not implement the inverse? > > What do you mean "the inverse" ? The inverse of this patch is moving > everything of smc-core.c except the MFD bits into drivers/mfd leaving > the MFD bits in drivers/platform/apple, which makes no sense. > > > The Apple SMC is clearly an MFD, in > > Linux terms, so why not move the Platform Device into here, fetch all > > of the global resources, register the sub-devices, then call into the > > rtkit implementation in drivers/platform? > > I thought you had previously ruled out the idea of moving the contents > of drivers/platform/apple into drivers/mfd, but maybe your position on > that had changed through the course of the discussion. It's really not > obvious to me what you want from what's been said in this thread. > > So, I ask the direct question - would moving the code that is in this > patch set from drivers/platform/apple to drivers/mfd then make it > acceptable to you? In other words: > > drivers/platform/apple/smc_core.c > drivers/platform/apple/smc.h > drivers/platform/apple/smc_rtkit.c > > If not, then please clearly and fully state what you want to see. Sorry Russell, I'm out of time today. Please see my recent reply to Hector for now and I'll get back to you first thing. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 17:24 ` Lee Jones @ 2022-10-31 19:47 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-31 19:47 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Oct 31, 2022 at 05:24:53PM +0000, Lee Jones wrote: > On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > > > On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > > > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > > > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > > > patch set according to your views. I'm guessing this is going to take > > > > > > a major re-work of the patch series. > > > > > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > > > more complicated, because I doubt Hector has updated his patch set > > > > > > with the review comments that have been made so far... so this is > > > > > > now quite a mess. I think, once this is sorted, the entire series > > > > > > will need to be re-reviewed entirely afresh. > > > > > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > > > > > It seems there's no plans by Hector to address this, so it comes down > > > > to me. > > > > > > > > So, guessing what you're after, would something like the following > > > > work for you? I don't see *any* point in creating more yet more > > > > platform devices unless we're on a mission to maximise wasted memory > > > > resources (which this split will already be doing by creating two > > > > small modules instead of one.) > > > > > > > > Obviously, this is not an official patch yet, it's just to find out > > > > what code structure you are looking for. > > > > > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > > > --- a/drivers/mfd/Makefile > > > > +++ b/drivers/mfd/Makefile > > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > > > + > > > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > > > new file mode 100644 > > > > index 000000000000..bc59d1c5e13d > > > > --- /dev/null > > > > +++ b/drivers/mfd/apple-smc.c > > > > @@ -0,0 +1,38 @@ > > > > +#include <linux/mfd/core.h> > > > > +#include <linux/mfd/apple-smc.h> > > > > + > > > > +static const struct mfd_cell apple_smc_devs[] = { > > > > + { > > > > + .name = "macsmc-gpio", > > > > + .of_compatible = "apple,smc-gpio", > > > > + }, > > > > + { > > > > + .name = "macsmc-hid", > > > > + }, > > > > + { > > > > + .name = "macsmc-power", > > > > + }, > > > > + { > > > > + .name = "macsmc-reboot", > > > > + }, > > > > + { > > > > + .name = "macsmc-rtc", > > > > + }, > > > > +}; > > > > + > > > > +int apple_smc_mfd_probe(struct device *dev) > > > > +{ > > > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > > > +} > > > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > > > + > > > > +void apple_smc_mfd_remove(struct device *dev) > > > > +{ > > > > + mfd_remove_devices(dev); > > > > +} > > > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > > > + > > > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > > > +MODULE_LICENSE("Dual MIT/GPL"); > > > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > > > > > Conceptually interesting, not seen this one before, but clearly a > > > hack, no? Pretty sure all of the other cores in MFD are represented > > > by a Platform Device. > > > > No one seems to understand what you actually want to see with the > > smc-core.c part, so I'm trying to find out what code structure > > would suit you. > > > > It seemed from the thread that moving smc-core.c to drivers/mfd > > wasn't desirable, but there was the desire to move the mfd bits > > into there - so that's what I've done with this patch. It doesn't > > make any sense what so ever to add yet another platform device > > into this structure with all of the complication around what happens > > if the user forces it to unbind, so I didn't. > > > > > Why not implement the inverse? > > > > What do you mean "the inverse" ? The inverse of this patch is moving > > everything of smc-core.c except the MFD bits into drivers/mfd leaving > > the MFD bits in drivers/platform/apple, which makes no sense. > > > > > The Apple SMC is clearly an MFD, in > > > Linux terms, so why not move the Platform Device into here, fetch all > > > of the global resources, register the sub-devices, then call into the > > > rtkit implementation in drivers/platform? > > > > I thought you had previously ruled out the idea of moving the contents > > of drivers/platform/apple into drivers/mfd, but maybe your position on > > that had changed through the course of the discussion. It's really not > > obvious to me what you want from what's been said in this thread. > > > > So, I ask the direct question - would moving the code that is in this > > patch set from drivers/platform/apple to drivers/mfd then make it > > acceptable to you? In other words: > > > > drivers/platform/apple/smc_core.c > > drivers/platform/apple/smc.h > > drivers/platform/apple/smc_rtkit.c > > > > If not, then please clearly and fully state what you want to see. > > Sorry Russell, I'm out of time today. Please see my recent reply to > Hector for now and I'll get back to you first thing. Hi Lee, Thanks - I look forward to it. Having read your response to Hector, I am wondering whether there's a misunderstanding of the code, so I'm hoping that my attempt in my reply helps to clear up any code misunderstandings. If you want to ask questions about the code, you know where to find me on irc, and I'll more than happily answer anything you want to know about the code structure. Russell. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 19:47 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-31 19:47 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Oct 31, 2022 at 05:24:53PM +0000, Lee Jones wrote: > On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > > > On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > > > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > > > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > > > patch set according to your views. I'm guessing this is going to take > > > > > > a major re-work of the patch series. > > > > > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > > > more complicated, because I doubt Hector has updated his patch set > > > > > > with the review comments that have been made so far... so this is > > > > > > now quite a mess. I think, once this is sorted, the entire series > > > > > > will need to be re-reviewed entirely afresh. > > > > > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > > > > > It seems there's no plans by Hector to address this, so it comes down > > > > to me. > > > > > > > > So, guessing what you're after, would something like the following > > > > work for you? I don't see *any* point in creating more yet more > > > > platform devices unless we're on a mission to maximise wasted memory > > > > resources (which this split will already be doing by creating two > > > > small modules instead of one.) > > > > > > > > Obviously, this is not an official patch yet, it's just to find out > > > > what code structure you are looking for. > > > > > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > > > --- a/drivers/mfd/Makefile > > > > +++ b/drivers/mfd/Makefile > > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > > > + > > > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > > > new file mode 100644 > > > > index 000000000000..bc59d1c5e13d > > > > --- /dev/null > > > > +++ b/drivers/mfd/apple-smc.c > > > > @@ -0,0 +1,38 @@ > > > > +#include <linux/mfd/core.h> > > > > +#include <linux/mfd/apple-smc.h> > > > > + > > > > +static const struct mfd_cell apple_smc_devs[] = { > > > > + { > > > > + .name = "macsmc-gpio", > > > > + .of_compatible = "apple,smc-gpio", > > > > + }, > > > > + { > > > > + .name = "macsmc-hid", > > > > + }, > > > > + { > > > > + .name = "macsmc-power", > > > > + }, > > > > + { > > > > + .name = "macsmc-reboot", > > > > + }, > > > > + { > > > > + .name = "macsmc-rtc", > > > > + }, > > > > +}; > > > > + > > > > +int apple_smc_mfd_probe(struct device *dev) > > > > +{ > > > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > > > +} > > > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > > > + > > > > +void apple_smc_mfd_remove(struct device *dev) > > > > +{ > > > > + mfd_remove_devices(dev); > > > > +} > > > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > > > + > > > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > > > +MODULE_LICENSE("Dual MIT/GPL"); > > > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > > > > > Conceptually interesting, not seen this one before, but clearly a > > > hack, no? Pretty sure all of the other cores in MFD are represented > > > by a Platform Device. > > > > No one seems to understand what you actually want to see with the > > smc-core.c part, so I'm trying to find out what code structure > > would suit you. > > > > It seemed from the thread that moving smc-core.c to drivers/mfd > > wasn't desirable, but there was the desire to move the mfd bits > > into there - so that's what I've done with this patch. It doesn't > > make any sense what so ever to add yet another platform device > > into this structure with all of the complication around what happens > > if the user forces it to unbind, so I didn't. > > > > > Why not implement the inverse? > > > > What do you mean "the inverse" ? The inverse of this patch is moving > > everything of smc-core.c except the MFD bits into drivers/mfd leaving > > the MFD bits in drivers/platform/apple, which makes no sense. > > > > > The Apple SMC is clearly an MFD, in > > > Linux terms, so why not move the Platform Device into here, fetch all > > > of the global resources, register the sub-devices, then call into the > > > rtkit implementation in drivers/platform? > > > > I thought you had previously ruled out the idea of moving the contents > > of drivers/platform/apple into drivers/mfd, but maybe your position on > > that had changed through the course of the discussion. It's really not > > obvious to me what you want from what's been said in this thread. > > > > So, I ask the direct question - would moving the code that is in this > > patch set from drivers/platform/apple to drivers/mfd then make it > > acceptable to you? In other words: > > > > drivers/platform/apple/smc_core.c > > drivers/platform/apple/smc.h > > drivers/platform/apple/smc_rtkit.c > > > > If not, then please clearly and fully state what you want to see. > > Sorry Russell, I'm out of time today. Please see my recent reply to > Hector for now and I'll get back to you first thing. Hi Lee, Thanks - I look forward to it. Having read your response to Hector, I am wondering whether there's a misunderstanding of the code, so I'm hoping that my attempt in my reply helps to clear up any code misunderstandings. If you want to ask questions about the code, you know where to find me on irc, and I'll more than happily answer anything you want to know about the code structure. Russell. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 19:47 ` Russell King (Oracle) @ 2022-11-01 9:59 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-01 9:59 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > On Mon, Oct 31, 2022 at 05:24:53PM +0000, Lee Jones wrote: > > On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > > > > > On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > > > > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > > > > > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > > > > patch set according to your views. I'm guessing this is going to take > > > > > > > a major re-work of the patch series. > > > > > > > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > > > > more complicated, because I doubt Hector has updated his patch set > > > > > > > with the review comments that have been made so far... so this is > > > > > > > now quite a mess. I think, once this is sorted, the entire series > > > > > > > will need to be re-reviewed entirely afresh. > > > > > > > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > > > > > > > It seems there's no plans by Hector to address this, so it comes down > > > > > to me. > > > > > > > > > > So, guessing what you're after, would something like the following > > > > > work for you? I don't see *any* point in creating more yet more > > > > > platform devices unless we're on a mission to maximise wasted memory > > > > > resources (which this split will already be doing by creating two > > > > > small modules instead of one.) > > > > > > > > > > Obviously, this is not an official patch yet, it's just to find out > > > > > what code structure you are looking for. > > > > > > > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > > > > --- a/drivers/mfd/Makefile > > > > > +++ b/drivers/mfd/Makefile > > > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > > > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > > > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > > > > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > > > > + > > > > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > > > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > > > > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > > > > new file mode 100644 > > > > > index 000000000000..bc59d1c5e13d > > > > > --- /dev/null > > > > > +++ b/drivers/mfd/apple-smc.c > > > > > @@ -0,0 +1,38 @@ > > > > > +#include <linux/mfd/core.h> > > > > > +#include <linux/mfd/apple-smc.h> > > > > > + > > > > > +static const struct mfd_cell apple_smc_devs[] = { > > > > > + { > > > > > + .name = "macsmc-gpio", > > > > > + .of_compatible = "apple,smc-gpio", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-hid", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-power", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-reboot", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-rtc", > > > > > + }, > > > > > +}; > > > > > + > > > > > +int apple_smc_mfd_probe(struct device *dev) > > > > > +{ > > > > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > > > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > > > > +} > > > > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > > > > + > > > > > +void apple_smc_mfd_remove(struct device *dev) > > > > > +{ > > > > > + mfd_remove_devices(dev); > > > > > +} > > > > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > > > > + > > > > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > > > > +MODULE_LICENSE("Dual MIT/GPL"); > > > > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > > > > > > > Conceptually interesting, not seen this one before, but clearly a > > > > hack, no? Pretty sure all of the other cores in MFD are represented > > > > by a Platform Device. > > > > > > No one seems to understand what you actually want to see with the > > > smc-core.c part, so I'm trying to find out what code structure > > > would suit you. > > > > > > It seemed from the thread that moving smc-core.c to drivers/mfd > > > wasn't desirable, but there was the desire to move the mfd bits > > > into there - so that's what I've done with this patch. It doesn't > > > make any sense what so ever to add yet another platform device > > > into this structure with all of the complication around what happens > > > if the user forces it to unbind, so I didn't. > > > > > > > Why not implement the inverse? > > > > > > What do you mean "the inverse" ? The inverse of this patch is moving > > > everything of smc-core.c except the MFD bits into drivers/mfd leaving > > > the MFD bits in drivers/platform/apple, which makes no sense. > > > > > > > The Apple SMC is clearly an MFD, in > > > > Linux terms, so why not move the Platform Device into here, fetch all > > > > of the global resources, register the sub-devices, then call into the > > > > rtkit implementation in drivers/platform? > > > > > > I thought you had previously ruled out the idea of moving the contents > > > of drivers/platform/apple into drivers/mfd, but maybe your position on > > > that had changed through the course of the discussion. It's really not > > > obvious to me what you want from what's been said in this thread. > > > > > > So, I ask the direct question - would moving the code that is in this > > > patch set from drivers/platform/apple to drivers/mfd then make it > > > acceptable to you? In other words: > > > > > > drivers/platform/apple/smc_core.c > > > drivers/platform/apple/smc.h > > > drivers/platform/apple/smc_rtkit.c > > > > > > If not, then please clearly and fully state what you want to see. > > > > Sorry Russell, I'm out of time today. Please see my recent reply to > > Hector for now and I'll get back to you first thing. > > Hi Lee, > > Thanks - I look forward to it. Having read your response to Hector, I > am wondering whether there's a misunderstanding of the code, so I'm > hoping that my attempt in my reply helps to clear up any code > misunderstandings. > > If you want to ask questions about the code, you know where to find > me on irc, and I'll more than happily answer anything you want to > know about the code structure. That might be helpful, thanks. Let's keep in on-list for now, in case others are following along. For now, I'll go take a look at your other response. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-11-01 9:59 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-01 9:59 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > On Mon, Oct 31, 2022 at 05:24:53PM +0000, Lee Jones wrote: > > On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > > > > > On Mon, Oct 31, 2022 at 08:46:25AM +0000, Lee Jones wrote: > > > > On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > > > > > > > > > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > > > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > > > > > patch set according to your views. I'm guessing this is going to take > > > > > > > a major re-work of the patch series. > > > > > > > > > > > > > > I suspect my attempt and trying to get this upstream has made things > > > > > > > more complicated, because I doubt Hector has updated his patch set > > > > > > > with the review comments that have been made so far... so this is > > > > > > > now quite a mess. I think, once this is sorted, the entire series > > > > > > > will need to be re-reviewed entirely afresh. > > > > > > > > > > > > I have no insight into what Hector is doing, or plans to do. > > > > > > > > > > It seems there's no plans by Hector to address this, so it comes down > > > > > to me. > > > > > > > > > > So, guessing what you're after, would something like the following > > > > > work for you? I don't see *any* point in creating more yet more > > > > > platform devices unless we're on a mission to maximise wasted memory > > > > > resources (which this split will already be doing by creating two > > > > > small modules instead of one.) > > > > > > > > > > Obviously, this is not an official patch yet, it's just to find out > > > > > what code structure you are looking for. > > > > > > > > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > > > index 78c6d9d99c3f..8d4c0508a2c8 100644 > > > > > --- a/drivers/mfd/Makefile > > > > > +++ b/drivers/mfd/Makefile > > > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > > > > > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > > > > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > > > > > > > > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > > > > > + > > > > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > > > > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > > > > > > > > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > > > > > new file mode 100644 > > > > > index 000000000000..bc59d1c5e13d > > > > > --- /dev/null > > > > > +++ b/drivers/mfd/apple-smc.c > > > > > @@ -0,0 +1,38 @@ > > > > > +#include <linux/mfd/core.h> > > > > > +#include <linux/mfd/apple-smc.h> > > > > > + > > > > > +static const struct mfd_cell apple_smc_devs[] = { > > > > > + { > > > > > + .name = "macsmc-gpio", > > > > > + .of_compatible = "apple,smc-gpio", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-hid", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-power", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-reboot", > > > > > + }, > > > > > + { > > > > > + .name = "macsmc-rtc", > > > > > + }, > > > > > +}; > > > > > + > > > > > +int apple_smc_mfd_probe(struct device *dev) > > > > > +{ > > > > > + return mfd_add_devices(dev, -1, apple_smc_devs, > > > > > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > > > > > +} > > > > > +EXPORT_SYMBOL(apple_smc_mfd_probe); > > > > > + > > > > > +void apple_smc_mfd_remove(struct device *dev) > > > > > +{ > > > > > + mfd_remove_devices(dev); > > > > > +} > > > > > +EXPORT_SYMBOL(apple_smc_mfd_remove); > > > > > + > > > > > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > > > > > +MODULE_LICENSE("Dual MIT/GPL"); > > > > > +MODULE_DESCRIPTION("Apple SMC MFD core"); > > > > > > > > Conceptually interesting, not seen this one before, but clearly a > > > > hack, no? Pretty sure all of the other cores in MFD are represented > > > > by a Platform Device. > > > > > > No one seems to understand what you actually want to see with the > > > smc-core.c part, so I'm trying to find out what code structure > > > would suit you. > > > > > > It seemed from the thread that moving smc-core.c to drivers/mfd > > > wasn't desirable, but there was the desire to move the mfd bits > > > into there - so that's what I've done with this patch. It doesn't > > > make any sense what so ever to add yet another platform device > > > into this structure with all of the complication around what happens > > > if the user forces it to unbind, so I didn't. > > > > > > > Why not implement the inverse? > > > > > > What do you mean "the inverse" ? The inverse of this patch is moving > > > everything of smc-core.c except the MFD bits into drivers/mfd leaving > > > the MFD bits in drivers/platform/apple, which makes no sense. > > > > > > > The Apple SMC is clearly an MFD, in > > > > Linux terms, so why not move the Platform Device into here, fetch all > > > > of the global resources, register the sub-devices, then call into the > > > > rtkit implementation in drivers/platform? > > > > > > I thought you had previously ruled out the idea of moving the contents > > > of drivers/platform/apple into drivers/mfd, but maybe your position on > > > that had changed through the course of the discussion. It's really not > > > obvious to me what you want from what's been said in this thread. > > > > > > So, I ask the direct question - would moving the code that is in this > > > patch set from drivers/platform/apple to drivers/mfd then make it > > > acceptable to you? In other words: > > > > > > drivers/platform/apple/smc_core.c > > > drivers/platform/apple/smc.h > > > drivers/platform/apple/smc_rtkit.c > > > > > > If not, then please clearly and fully state what you want to see. > > > > Sorry Russell, I'm out of time today. Please see my recent reply to > > Hector for now and I'll get back to you first thing. > > Hi Lee, > > Thanks - I look forward to it. Having read your response to Hector, I > am wondering whether there's a misunderstanding of the code, so I'm > hoping that my attempt in my reply helps to clear up any code > misunderstandings. > > If you want to ask questions about the code, you know where to find > me on irc, and I'll more than happily answer anything you want to > know about the code structure. That might be helpful, thanks. Let's keep in on-list for now, in case others are following along. For now, I'll go take a look at your other response. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-09-09 7:50 ` Lee Jones @ 2022-10-29 6:40 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-29 6:40 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 09/09/2022 16.50, Lee Jones wrote: >> What's the point of just having effectively an array of mfd_cell and >> wrappers to call into the mfd core in the drivers/mfd/ tree and the >> rest of the driver elsewhere? > > They should be separate drivers, with MFD registering the Platform. Why? What purpose does this serve? I'm still confused. There's one parent device, which provides services to the child devices. There isn't one parent device which wraps a platform service which is used by children. This makes no sense. The platform device is the root, if it exposes MFD services, then it has to be in that direction, not the other way around. Look at how this patch series is architected. There is smc_core.c, which implements SMC helpers and wrappers on top of a generic backend, and registers with the MFD subsystem. And then there is smc_rtkit.c which is the actual platform implementation on top of the RTKit framework, and is the actual platform device entry point. A priori, the only thing that makes sense to me right now would be to move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. That way the mfd registration would be in drivers/mfd (as would be the services offered to sub-drivers), but the actual backend implementation would be in platform/ (and there would eventually be others, e.g. at least two more for x86 systems). That does mean that the driver entry point will be in platform/, with mfd/smc_core.c serving as effectively library code to plumb in the mfd stuff into one of several possible platform devices. Would that work for you? - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-29 6:40 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-29 6:40 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 09/09/2022 16.50, Lee Jones wrote: >> What's the point of just having effectively an array of mfd_cell and >> wrappers to call into the mfd core in the drivers/mfd/ tree and the >> rest of the driver elsewhere? > > They should be separate drivers, with MFD registering the Platform. Why? What purpose does this serve? I'm still confused. There's one parent device, which provides services to the child devices. There isn't one parent device which wraps a platform service which is used by children. This makes no sense. The platform device is the root, if it exposes MFD services, then it has to be in that direction, not the other way around. Look at how this patch series is architected. There is smc_core.c, which implements SMC helpers and wrappers on top of a generic backend, and registers with the MFD subsystem. And then there is smc_rtkit.c which is the actual platform implementation on top of the RTKit framework, and is the actual platform device entry point. A priori, the only thing that makes sense to me right now would be to move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. That way the mfd registration would be in drivers/mfd (as would be the services offered to sub-drivers), but the actual backend implementation would be in platform/ (and there would eventually be others, e.g. at least two more for x86 systems). That does mean that the driver entry point will be in platform/, with mfd/smc_core.c serving as effectively library code to plumb in the mfd stuff into one of several possible platform devices. Would that work for you? - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-29 6:40 ` Hector Martin @ 2022-10-31 8:48 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 8:48 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Sat, 29 Oct 2022, Hector Martin wrote: > On 09/09/2022 16.50, Lee Jones wrote: > >> What's the point of just having effectively an array of mfd_cell and > >> wrappers to call into the mfd core in the drivers/mfd/ tree and the > >> rest of the driver elsewhere? > > > > They should be separate drivers, with MFD registering the Platform. > > Why? What purpose does this serve? I'm still confused. There's one > parent device, which provides services to the child devices. There isn't > one parent device which wraps a platform service which is used by > children. This makes no sense. The platform device is the root, if it > exposes MFD services, then it has to be in that direction, not the other > way around. > > Look at how this patch series is architected. There is smc_core.c, which > implements SMC helpers and wrappers on top of a generic backend, and > registers with the MFD subsystem. And then there is smc_rtkit.c which is > the actual platform implementation on top of the RTKit framework, and is > the actual platform device entry point. > > A priori, the only thing that makes sense to me right now would be to > move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. > That way the mfd registration would be in drivers/mfd (as would be the > services offered to sub-drivers), but the actual backend implementation > would be in platform/ (and there would eventually be others, e.g. at > least two more for x86 systems). That does mean that the driver entry > point will be in platform/, with mfd/smc_core.c serving as effectively > library code to plumb in the mfd stuff into one of several possible > platform devices. Would that work for you? Yes, sounds sensible. However, keep all of the abstraction craziness somewhere else and fetch and share all of your shared resources from the MFD (SMC) driver. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 8:48 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 8:48 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Sat, 29 Oct 2022, Hector Martin wrote: > On 09/09/2022 16.50, Lee Jones wrote: > >> What's the point of just having effectively an array of mfd_cell and > >> wrappers to call into the mfd core in the drivers/mfd/ tree and the > >> rest of the driver elsewhere? > > > > They should be separate drivers, with MFD registering the Platform. > > Why? What purpose does this serve? I'm still confused. There's one > parent device, which provides services to the child devices. There isn't > one parent device which wraps a platform service which is used by > children. This makes no sense. The platform device is the root, if it > exposes MFD services, then it has to be in that direction, not the other > way around. > > Look at how this patch series is architected. There is smc_core.c, which > implements SMC helpers and wrappers on top of a generic backend, and > registers with the MFD subsystem. And then there is smc_rtkit.c which is > the actual platform implementation on top of the RTKit framework, and is > the actual platform device entry point. > > A priori, the only thing that makes sense to me right now would be to > move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. > That way the mfd registration would be in drivers/mfd (as would be the > services offered to sub-drivers), but the actual backend implementation > would be in platform/ (and there would eventually be others, e.g. at > least two more for x86 systems). That does mean that the driver entry > point will be in platform/, with mfd/smc_core.c serving as effectively > library code to plumb in the mfd stuff into one of several possible > platform devices. Would that work for you? Yes, sounds sensible. However, keep all of the abstraction craziness somewhere else and fetch and share all of your shared resources from the MFD (SMC) driver. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 8:48 ` Lee Jones @ 2022-10-31 8:58 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-31 8:58 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 31/10/2022 17.48, Lee Jones wrote: > On Sat, 29 Oct 2022, Hector Martin wrote: > >> On 09/09/2022 16.50, Lee Jones wrote: >>>> What's the point of just having effectively an array of mfd_cell and >>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the >>>> rest of the driver elsewhere? >>> >>> They should be separate drivers, with MFD registering the Platform. >> >> Why? What purpose does this serve? I'm still confused. There's one >> parent device, which provides services to the child devices. There isn't >> one parent device which wraps a platform service which is used by >> children. This makes no sense. The platform device is the root, if it >> exposes MFD services, then it has to be in that direction, not the other >> way around. >> >> Look at how this patch series is architected. There is smc_core.c, which >> implements SMC helpers and wrappers on top of a generic backend, and >> registers with the MFD subsystem. And then there is smc_rtkit.c which is >> the actual platform implementation on top of the RTKit framework, and is >> the actual platform device entry point. >> >> A priori, the only thing that makes sense to me right now would be to >> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. >> That way the mfd registration would be in drivers/mfd (as would be the >> services offered to sub-drivers), but the actual backend implementation >> would be in platform/ (and there would eventually be others, e.g. at >> least two more for x86 systems). That does mean that the driver entry >> point will be in platform/, with mfd/smc_core.c serving as effectively >> library code to plumb in the mfd stuff into one of several possible >> platform devices. Would that work for you? > > Yes, sounds sensible. However, keep all of the abstraction craziness > somewhere else and fetch and share all of your shared resources from > the MFD (SMC) driver. I'm not sure what you mean by that. The abstraction (smc_core.c) *is* the shared resource. All it does is wrap ops callbacks with a mutex and add a couple helpers for finding keys. Do you literally want us to just have this in drivers/mfd? // SPDX-License-Identifier: GPL-2.0-only OR MIT /* * Apple SMC MFD wrapper * Copyright The Asahi Linux Contributors */ #include <linux/device.h> #include "smc.h" static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", }, { .name = "macsmc-hid", }, { .name = "macsmc-power", }, { .name = "macsmc-reboot", }, { .name = "macsmc-rtc", }, }; int apple_smc_add_mfd_devices(struct device *dev) { ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); if (ret) return dev_err_probe(dev, ret, "Subdevice initialization failed"); return 0; } EXPORT_SYMBOL(apple_smc_add_mfd_devices); int apple_smc_remove_mfd_devices(struct device *dev) { mfd_remove_devices(smc->dev); return 0; } EXPORT_SYMBOL(apple_smc_add_mfd_devices); MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); MODULE_LICENSE("Dual MIT/GPL"); MODULE_DESCRIPTION("Apple SMC MFD wrapper"); Because this feels *immensely* silly and pointless. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 8:58 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-31 8:58 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 31/10/2022 17.48, Lee Jones wrote: > On Sat, 29 Oct 2022, Hector Martin wrote: > >> On 09/09/2022 16.50, Lee Jones wrote: >>>> What's the point of just having effectively an array of mfd_cell and >>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the >>>> rest of the driver elsewhere? >>> >>> They should be separate drivers, with MFD registering the Platform. >> >> Why? What purpose does this serve? I'm still confused. There's one >> parent device, which provides services to the child devices. There isn't >> one parent device which wraps a platform service which is used by >> children. This makes no sense. The platform device is the root, if it >> exposes MFD services, then it has to be in that direction, not the other >> way around. >> >> Look at how this patch series is architected. There is smc_core.c, which >> implements SMC helpers and wrappers on top of a generic backend, and >> registers with the MFD subsystem. And then there is smc_rtkit.c which is >> the actual platform implementation on top of the RTKit framework, and is >> the actual platform device entry point. >> >> A priori, the only thing that makes sense to me right now would be to >> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. >> That way the mfd registration would be in drivers/mfd (as would be the >> services offered to sub-drivers), but the actual backend implementation >> would be in platform/ (and there would eventually be others, e.g. at >> least two more for x86 systems). That does mean that the driver entry >> point will be in platform/, with mfd/smc_core.c serving as effectively >> library code to plumb in the mfd stuff into one of several possible >> platform devices. Would that work for you? > > Yes, sounds sensible. However, keep all of the abstraction craziness > somewhere else and fetch and share all of your shared resources from > the MFD (SMC) driver. I'm not sure what you mean by that. The abstraction (smc_core.c) *is* the shared resource. All it does is wrap ops callbacks with a mutex and add a couple helpers for finding keys. Do you literally want us to just have this in drivers/mfd? // SPDX-License-Identifier: GPL-2.0-only OR MIT /* * Apple SMC MFD wrapper * Copyright The Asahi Linux Contributors */ #include <linux/device.h> #include "smc.h" static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", }, { .name = "macsmc-hid", }, { .name = "macsmc-power", }, { .name = "macsmc-reboot", }, { .name = "macsmc-rtc", }, }; int apple_smc_add_mfd_devices(struct device *dev) { ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); if (ret) return dev_err_probe(dev, ret, "Subdevice initialization failed"); return 0; } EXPORT_SYMBOL(apple_smc_add_mfd_devices); int apple_smc_remove_mfd_devices(struct device *dev) { mfd_remove_devices(smc->dev); return 0; } EXPORT_SYMBOL(apple_smc_add_mfd_devices); MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); MODULE_LICENSE("Dual MIT/GPL"); MODULE_DESCRIPTION("Apple SMC MFD wrapper"); Because this feels *immensely* silly and pointless. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 8:58 ` Hector Martin @ 2022-10-31 9:29 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 9:29 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Hector Martin wrote: > On 31/10/2022 17.48, Lee Jones wrote: > > On Sat, 29 Oct 2022, Hector Martin wrote: > > > >> On 09/09/2022 16.50, Lee Jones wrote: > >>>> What's the point of just having effectively an array of mfd_cell and > >>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the > >>>> rest of the driver elsewhere? > >>> > >>> They should be separate drivers, with MFD registering the Platform. > >> > >> Why? What purpose does this serve? I'm still confused. There's one > >> parent device, which provides services to the child devices. There isn't > >> one parent device which wraps a platform service which is used by > >> children. This makes no sense. The platform device is the root, if it > >> exposes MFD services, then it has to be in that direction, not the other > >> way around. > >> > >> Look at how this patch series is architected. There is smc_core.c, which > >> implements SMC helpers and wrappers on top of a generic backend, and > >> registers with the MFD subsystem. And then there is smc_rtkit.c which is > >> the actual platform implementation on top of the RTKit framework, and is > >> the actual platform device entry point. > >> > >> A priori, the only thing that makes sense to me right now would be to > >> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. > >> That way the mfd registration would be in drivers/mfd (as would be the > >> services offered to sub-drivers), but the actual backend implementation > >> would be in platform/ (and there would eventually be others, e.g. at > >> least two more for x86 systems). That does mean that the driver entry > >> point will be in platform/, with mfd/smc_core.c serving as effectively > >> library code to plumb in the mfd stuff into one of several possible > >> platform devices. Would that work for you? > > > > Yes, sounds sensible. However, keep all of the abstraction craziness > > somewhere else and fetch and share all of your shared resources from > > the MFD (SMC) driver. > > I'm not sure what you mean by that. The abstraction (smc_core.c) *is* > the shared resource. All it does is wrap ops callbacks with a mutex and > add a couple helpers for finding keys. Do you literally want us to just > have this in drivers/mfd? > > // SPDX-License-Identifier: GPL-2.0-only OR MIT > /* > * Apple SMC MFD wrapper > * Copyright The Asahi Linux Contributors > */ > > #include <linux/device.h> > #include "smc.h" > > static const struct mfd_cell apple_smc_devs[] = { > { > .name = "macsmc-gpio", > }, > { > .name = "macsmc-hid", > }, > { > .name = "macsmc-power", > }, > { > .name = "macsmc-reboot", > }, > { > .name = "macsmc-rtc", > }, > }; > > int apple_smc_add_mfd_devices(struct device *dev) > { > ret = mfd_add_devices(dev, -1, apple_smc_devs, > ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > if (ret) > return dev_err_probe(dev, ret, "Subdevice initialization failed"); > > return 0; > } > EXPORT_SYMBOL(apple_smc_add_mfd_devices); > > int apple_smc_remove_mfd_devices(struct device *dev) > { > mfd_remove_devices(smc->dev); > > return 0; > } > EXPORT_SYMBOL(apple_smc_add_mfd_devices); > > MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > MODULE_LICENSE("Dual MIT/GPL"); > MODULE_DESCRIPTION("Apple SMC MFD wrapper"); > > Because this feels *immensely* silly and pointless. ... and hacky. I agree. [BTW: if this is all you want to do, have you considered simple-mfd?] No, I want you to author a proper MFD device. The hardware you're describing in this submission *is* an MFD. So use the subsystem properly, instead of abusing it as a shim API to simply register platform devices. Request the device-wide memory (and other shared resources) here. Conduct core operations and initialisation here, then call into your Platform and other child devices to initiate the real work. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 9:29 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 9:29 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Hector Martin wrote: > On 31/10/2022 17.48, Lee Jones wrote: > > On Sat, 29 Oct 2022, Hector Martin wrote: > > > >> On 09/09/2022 16.50, Lee Jones wrote: > >>>> What's the point of just having effectively an array of mfd_cell and > >>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the > >>>> rest of the driver elsewhere? > >>> > >>> They should be separate drivers, with MFD registering the Platform. > >> > >> Why? What purpose does this serve? I'm still confused. There's one > >> parent device, which provides services to the child devices. There isn't > >> one parent device which wraps a platform service which is used by > >> children. This makes no sense. The platform device is the root, if it > >> exposes MFD services, then it has to be in that direction, not the other > >> way around. > >> > >> Look at how this patch series is architected. There is smc_core.c, which > >> implements SMC helpers and wrappers on top of a generic backend, and > >> registers with the MFD subsystem. And then there is smc_rtkit.c which is > >> the actual platform implementation on top of the RTKit framework, and is > >> the actual platform device entry point. > >> > >> A priori, the only thing that makes sense to me right now would be to > >> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. > >> That way the mfd registration would be in drivers/mfd (as would be the > >> services offered to sub-drivers), but the actual backend implementation > >> would be in platform/ (and there would eventually be others, e.g. at > >> least two more for x86 systems). That does mean that the driver entry > >> point will be in platform/, with mfd/smc_core.c serving as effectively > >> library code to plumb in the mfd stuff into one of several possible > >> platform devices. Would that work for you? > > > > Yes, sounds sensible. However, keep all of the abstraction craziness > > somewhere else and fetch and share all of your shared resources from > > the MFD (SMC) driver. > > I'm not sure what you mean by that. The abstraction (smc_core.c) *is* > the shared resource. All it does is wrap ops callbacks with a mutex and > add a couple helpers for finding keys. Do you literally want us to just > have this in drivers/mfd? > > // SPDX-License-Identifier: GPL-2.0-only OR MIT > /* > * Apple SMC MFD wrapper > * Copyright The Asahi Linux Contributors > */ > > #include <linux/device.h> > #include "smc.h" > > static const struct mfd_cell apple_smc_devs[] = { > { > .name = "macsmc-gpio", > }, > { > .name = "macsmc-hid", > }, > { > .name = "macsmc-power", > }, > { > .name = "macsmc-reboot", > }, > { > .name = "macsmc-rtc", > }, > }; > > int apple_smc_add_mfd_devices(struct device *dev) > { > ret = mfd_add_devices(dev, -1, apple_smc_devs, > ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > if (ret) > return dev_err_probe(dev, ret, "Subdevice initialization failed"); > > return 0; > } > EXPORT_SYMBOL(apple_smc_add_mfd_devices); > > int apple_smc_remove_mfd_devices(struct device *dev) > { > mfd_remove_devices(smc->dev); > > return 0; > } > EXPORT_SYMBOL(apple_smc_add_mfd_devices); > > MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > MODULE_LICENSE("Dual MIT/GPL"); > MODULE_DESCRIPTION("Apple SMC MFD wrapper"); > > Because this feels *immensely* silly and pointless. ... and hacky. I agree. [BTW: if this is all you want to do, have you considered simple-mfd?] No, I want you to author a proper MFD device. The hardware you're describing in this submission *is* an MFD. So use the subsystem properly, instead of abusing it as a shim API to simply register platform devices. Request the device-wide memory (and other shared resources) here. Conduct core operations and initialisation here, then call into your Platform and other child devices to initiate the real work. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 9:29 ` Lee Jones @ 2022-10-31 9:44 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-31 9:44 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 31/10/2022 18.29, Lee Jones wrote: > On Mon, 31 Oct 2022, Hector Martin wrote: > >> On 31/10/2022 17.48, Lee Jones wrote: >>> On Sat, 29 Oct 2022, Hector Martin wrote: >>> >>>> On 09/09/2022 16.50, Lee Jones wrote: >>>>>> What's the point of just having effectively an array of mfd_cell and >>>>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the >>>>>> rest of the driver elsewhere? >>>>> >>>>> They should be separate drivers, with MFD registering the Platform. >>>> >>>> Why? What purpose does this serve? I'm still confused. There's one >>>> parent device, which provides services to the child devices. There isn't >>>> one parent device which wraps a platform service which is used by >>>> children. This makes no sense. The platform device is the root, if it >>>> exposes MFD services, then it has to be in that direction, not the other >>>> way around. >>>> >>>> Look at how this patch series is architected. There is smc_core.c, which >>>> implements SMC helpers and wrappers on top of a generic backend, and >>>> registers with the MFD subsystem. And then there is smc_rtkit.c which is >>>> the actual platform implementation on top of the RTKit framework, and is >>>> the actual platform device entry point. >>>> >>>> A priori, the only thing that makes sense to me right now would be to >>>> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. >>>> That way the mfd registration would be in drivers/mfd (as would be the >>>> services offered to sub-drivers), but the actual backend implementation >>>> would be in platform/ (and there would eventually be others, e.g. at >>>> least two more for x86 systems). That does mean that the driver entry >>>> point will be in platform/, with mfd/smc_core.c serving as effectively >>>> library code to plumb in the mfd stuff into one of several possible >>>> platform devices. Would that work for you? >>> >>> Yes, sounds sensible. However, keep all of the abstraction craziness >>> somewhere else and fetch and share all of your shared resources from >>> the MFD (SMC) driver. >> >> I'm not sure what you mean by that. The abstraction (smc_core.c) *is* >> the shared resource. All it does is wrap ops callbacks with a mutex and >> add a couple helpers for finding keys. Do you literally want us to just >> have this in drivers/mfd? >> >> // SPDX-License-Identifier: GPL-2.0-only OR MIT >> /* >> * Apple SMC MFD wrapper >> * Copyright The Asahi Linux Contributors >> */ >> >> #include <linux/device.h> >> #include "smc.h" >> >> static const struct mfd_cell apple_smc_devs[] = { >> { >> .name = "macsmc-gpio", >> }, >> { >> .name = "macsmc-hid", >> }, >> { >> .name = "macsmc-power", >> }, >> { >> .name = "macsmc-reboot", >> }, >> { >> .name = "macsmc-rtc", >> }, >> }; >> >> int apple_smc_add_mfd_devices(struct device *dev) >> { >> ret = mfd_add_devices(dev, -1, apple_smc_devs, >> ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); >> if (ret) >> return dev_err_probe(dev, ret, "Subdevice initialization failed"); >> >> return 0; >> } >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); >> >> int apple_smc_remove_mfd_devices(struct device *dev) >> { >> mfd_remove_devices(smc->dev); >> >> return 0; >> } >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); >> >> MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); >> MODULE_LICENSE("Dual MIT/GPL"); >> MODULE_DESCRIPTION("Apple SMC MFD wrapper"); >> >> Because this feels *immensely* silly and pointless. > > ... and hacky. I agree. > > [BTW: if this is all you want to do, have you considered simple-mfd?] > > No, I want you to author a proper MFD device. You don't seem to understand how MFD devices actually map to the hardware we're working with here. > The hardware you're describing in this submission *is* an MFD. So use > the subsystem properly, instead of abusing it as a shim API to simply > register platform devices. *sigh* the hardware I'm describing is a *class* of MFD devices. They all work the same way as far as the sub-devices see, but operate on completely different hardware backends. If you do not want "gooey platform stuff" in drivers/mfd, then it *has* to be a dumb shim. You have 3 options: - We move everything into drivers/mfd, which means there will (eventually) be 3 backend modules binding to real hardware devices and one shared core which actually does the MFD registration and provides common services. - We move just the core into drivers/mfd, which means the device binding will happen elsewhere, and the only code in the MFD subsystem will be common code and will be called as a library (via module exports, not via device binding). - We give up and just have a dumb shim in drivers/mfd as above, because you don't want to work with us. Either you work with how our hardware works or we go with this dumb shim workaround. You seem to want us to simultaneously "author a proper MFD device" and "not put platform stuff in MFD". We can't do both at the same time. Either the code is here or it is elsewhere. > Request the device-wide memory (and other shared resources) here. That's what smc_rtkit.c does, but you seem not to want that code in mfd. > Conduct core operations and initialisation here The RTKit library is in charge of core RTKit initialization, smc_rtkit is in charge of SMC-specific initialization, and smc_core.c is in charge of core SMC operations and initialization. What, exactly, do you want to move into drivers/mfd? (hint: not the RTKit library, that is shared by many other drivers). > then call into your Platform and other child devices to initiate the real work. There is nothing to call into, the child devices will bind and call *back* into the SMC core to do their job. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 9:44 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-10-31 9:44 UTC (permalink / raw) To: Lee Jones Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 31/10/2022 18.29, Lee Jones wrote: > On Mon, 31 Oct 2022, Hector Martin wrote: > >> On 31/10/2022 17.48, Lee Jones wrote: >>> On Sat, 29 Oct 2022, Hector Martin wrote: >>> >>>> On 09/09/2022 16.50, Lee Jones wrote: >>>>>> What's the point of just having effectively an array of mfd_cell and >>>>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the >>>>>> rest of the driver elsewhere? >>>>> >>>>> They should be separate drivers, with MFD registering the Platform. >>>> >>>> Why? What purpose does this serve? I'm still confused. There's one >>>> parent device, which provides services to the child devices. There isn't >>>> one parent device which wraps a platform service which is used by >>>> children. This makes no sense. The platform device is the root, if it >>>> exposes MFD services, then it has to be in that direction, not the other >>>> way around. >>>> >>>> Look at how this patch series is architected. There is smc_core.c, which >>>> implements SMC helpers and wrappers on top of a generic backend, and >>>> registers with the MFD subsystem. And then there is smc_rtkit.c which is >>>> the actual platform implementation on top of the RTKit framework, and is >>>> the actual platform device entry point. >>>> >>>> A priori, the only thing that makes sense to me right now would be to >>>> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. >>>> That way the mfd registration would be in drivers/mfd (as would be the >>>> services offered to sub-drivers), but the actual backend implementation >>>> would be in platform/ (and there would eventually be others, e.g. at >>>> least two more for x86 systems). That does mean that the driver entry >>>> point will be in platform/, with mfd/smc_core.c serving as effectively >>>> library code to plumb in the mfd stuff into one of several possible >>>> platform devices. Would that work for you? >>> >>> Yes, sounds sensible. However, keep all of the abstraction craziness >>> somewhere else and fetch and share all of your shared resources from >>> the MFD (SMC) driver. >> >> I'm not sure what you mean by that. The abstraction (smc_core.c) *is* >> the shared resource. All it does is wrap ops callbacks with a mutex and >> add a couple helpers for finding keys. Do you literally want us to just >> have this in drivers/mfd? >> >> // SPDX-License-Identifier: GPL-2.0-only OR MIT >> /* >> * Apple SMC MFD wrapper >> * Copyright The Asahi Linux Contributors >> */ >> >> #include <linux/device.h> >> #include "smc.h" >> >> static const struct mfd_cell apple_smc_devs[] = { >> { >> .name = "macsmc-gpio", >> }, >> { >> .name = "macsmc-hid", >> }, >> { >> .name = "macsmc-power", >> }, >> { >> .name = "macsmc-reboot", >> }, >> { >> .name = "macsmc-rtc", >> }, >> }; >> >> int apple_smc_add_mfd_devices(struct device *dev) >> { >> ret = mfd_add_devices(dev, -1, apple_smc_devs, >> ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); >> if (ret) >> return dev_err_probe(dev, ret, "Subdevice initialization failed"); >> >> return 0; >> } >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); >> >> int apple_smc_remove_mfd_devices(struct device *dev) >> { >> mfd_remove_devices(smc->dev); >> >> return 0; >> } >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); >> >> MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); >> MODULE_LICENSE("Dual MIT/GPL"); >> MODULE_DESCRIPTION("Apple SMC MFD wrapper"); >> >> Because this feels *immensely* silly and pointless. > > ... and hacky. I agree. > > [BTW: if this is all you want to do, have you considered simple-mfd?] > > No, I want you to author a proper MFD device. You don't seem to understand how MFD devices actually map to the hardware we're working with here. > The hardware you're describing in this submission *is* an MFD. So use > the subsystem properly, instead of abusing it as a shim API to simply > register platform devices. *sigh* the hardware I'm describing is a *class* of MFD devices. They all work the same way as far as the sub-devices see, but operate on completely different hardware backends. If you do not want "gooey platform stuff" in drivers/mfd, then it *has* to be a dumb shim. You have 3 options: - We move everything into drivers/mfd, which means there will (eventually) be 3 backend modules binding to real hardware devices and one shared core which actually does the MFD registration and provides common services. - We move just the core into drivers/mfd, which means the device binding will happen elsewhere, and the only code in the MFD subsystem will be common code and will be called as a library (via module exports, not via device binding). - We give up and just have a dumb shim in drivers/mfd as above, because you don't want to work with us. Either you work with how our hardware works or we go with this dumb shim workaround. You seem to want us to simultaneously "author a proper MFD device" and "not put platform stuff in MFD". We can't do both at the same time. Either the code is here or it is elsewhere. > Request the device-wide memory (and other shared resources) here. That's what smc_rtkit.c does, but you seem not to want that code in mfd. > Conduct core operations and initialisation here The RTKit library is in charge of core RTKit initialization, smc_rtkit is in charge of SMC-specific initialization, and smc_core.c is in charge of core SMC operations and initialization. What, exactly, do you want to move into drivers/mfd? (hint: not the RTKit library, that is shared by many other drivers). > then call into your Platform and other child devices to initiate the real work. There is nothing to call into, the child devices will bind and call *back* into the SMC core to do their job. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 9:44 ` Hector Martin @ 2022-10-31 17:23 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 17:23 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Hector Martin wrote: > On 31/10/2022 18.29, Lee Jones wrote: > > On Mon, 31 Oct 2022, Hector Martin wrote: > > > >> On 31/10/2022 17.48, Lee Jones wrote: > >>> On Sat, 29 Oct 2022, Hector Martin wrote: > >>> > >>>> On 09/09/2022 16.50, Lee Jones wrote: > >>>>>> What's the point of just having effectively an array of mfd_cell and > >>>>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the > >>>>>> rest of the driver elsewhere? > >>>>> > >>>>> They should be separate drivers, with MFD registering the Platform. > >>>> > >>>> Why? What purpose does this serve? I'm still confused. There's one > >>>> parent device, which provides services to the child devices. There isn't > >>>> one parent device which wraps a platform service which is used by > >>>> children. This makes no sense. The platform device is the root, if it > >>>> exposes MFD services, then it has to be in that direction, not the other > >>>> way around. > >>>> > >>>> Look at how this patch series is architected. There is smc_core.c, which > >>>> implements SMC helpers and wrappers on top of a generic backend, and > >>>> registers with the MFD subsystem. And then there is smc_rtkit.c which is > >>>> the actual platform implementation on top of the RTKit framework, and is > >>>> the actual platform device entry point. > >>>> > >>>> A priori, the only thing that makes sense to me right now would be to > >>>> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. > >>>> That way the mfd registration would be in drivers/mfd (as would be the > >>>> services offered to sub-drivers), but the actual backend implementation > >>>> would be in platform/ (and there would eventually be others, e.g. at > >>>> least two more for x86 systems). That does mean that the driver entry > >>>> point will be in platform/, with mfd/smc_core.c serving as effectively > >>>> library code to plumb in the mfd stuff into one of several possible > >>>> platform devices. Would that work for you? > >>> > >>> Yes, sounds sensible. However, keep all of the abstraction craziness > >>> somewhere else and fetch and share all of your shared resources from > >>> the MFD (SMC) driver. > >> > >> I'm not sure what you mean by that. The abstraction (smc_core.c) *is* > >> the shared resource. All it does is wrap ops callbacks with a mutex and > >> add a couple helpers for finding keys. Do you literally want us to just > >> have this in drivers/mfd? > >> > >> // SPDX-License-Identifier: GPL-2.0-only OR MIT > >> /* > >> * Apple SMC MFD wrapper > >> * Copyright The Asahi Linux Contributors > >> */ > >> > >> #include <linux/device.h> > >> #include "smc.h" > >> > >> static const struct mfd_cell apple_smc_devs[] = { > >> { > >> .name = "macsmc-gpio", > >> }, > >> { > >> .name = "macsmc-hid", > >> }, > >> { > >> .name = "macsmc-power", > >> }, > >> { > >> .name = "macsmc-reboot", > >> }, > >> { > >> .name = "macsmc-rtc", > >> }, > >> }; > >> > >> int apple_smc_add_mfd_devices(struct device *dev) > >> { > >> ret = mfd_add_devices(dev, -1, apple_smc_devs, > >> ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > >> if (ret) > >> return dev_err_probe(dev, ret, "Subdevice initialization failed"); > >> > >> return 0; > >> } > >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); > >> > >> int apple_smc_remove_mfd_devices(struct device *dev) > >> { > >> mfd_remove_devices(smc->dev); > >> > >> return 0; > >> } > >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); > >> > >> MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > >> MODULE_LICENSE("Dual MIT/GPL"); > >> MODULE_DESCRIPTION("Apple SMC MFD wrapper"); > >> > >> Because this feels *immensely* silly and pointless. > > > > ... and hacky. I agree. > > > > [BTW: if this is all you want to do, have you considered simple-mfd?] > > > > No, I want you to author a proper MFD device. > > You don't seem to understand how MFD devices actually map to the > hardware we're working with here. Via an abstracted message passing API and a little shared memory? The former eventually ending up in the MBOX API? > > The hardware you're describing in this submission *is* an MFD. So use > > the subsystem properly, instead of abusing it as a shim API to simply > > register platform devices. > > *sigh* the hardware I'm describing is a *class* of MFD devices. They all > work the same way as far as the sub-devices see, but operate on > completely different hardware backends. That's common. Usually we're using talking; SPI, I2C, USB and MMIO, but a bespoke message passing API is not out of the realms of normal. > If you do not want "gooey > platform stuff" in drivers/mfd, then it *has* to be a dumb shim. > > You have 3 options: > > - We move everything into drivers/mfd, which means there will > (eventually) be 3 backend modules binding to real hardware devices and > one shared core which actually does the MFD registration and provides > common services. Moving everything isn't an option. A split would be the most reasonable approach. We just need to decide on which parts should reside on which side of the MFD / Platform boundary. > - We move just the core into drivers/mfd, which means the device binding > will happen elsewhere, and the only code in the MFD subsystem will be > common code and will be called as a library (via module exports, not via > device binding). What are you describing as 'the core' here? And which device binding are you alluding to? Sub-device registration or something else? > - We give up and just have a dumb shim in drivers/mfd as above, because > you don't want to work with us. If I wasn't willing to work with you, who are you conversing with? Side-note: Tweeting derogatory comments about the people who have volunteered to take valuable time out of their day to help you, is no good way to encourage people to "work with you"! Most, if not all of us do this willingly and with no additional benefit, purely to help others. Seeing such horrid things spread widely, is a guaranteed way to spoil someone's day. > Either you work with how our hardware works or we go with this dumb shim > workaround. It sounds like you have this the wrong way around. Linux and its associated subsystems aren't going to bend and flex around your design decisions. You need to apply a little flexibility and work with us to find something that'll work for everyone. > You seem to want us to simultaneously "author a proper MFD > device" and "not put platform stuff in MFD". We can't do both at the > same time. Either the code is here or it is elsewhere. Of course you can. Just like everyone else does. After taking quite a bit of time out of my day to look at this today, I can see that your RTKit initialisation implementation is actually much more suited to MFD than the SMC wrappers. One thing that I'm still a little unsure about is future the hierarchy and layering of all these drivers. Which is it you say can / will be swapped out for different methods of initialisation? I see that you pass a bunch of function pointers from the RTKit implementation into the SMC. Which in turn offers an exported (apple_smc_*) API. In most of the frameworks I have knowledge of, the core provides the Ops structure and it's populated by the client device. I'm sure having that clear in my head will go some ways to put me in a position to advise you further. > > Request the device-wide memory (and other shared resources) here. > > That's what smc_rtkit.c does, but you seem not to want that code in mfd. I'm not sure I explicitly said that. > > Conduct core operations and initialisation here > > The RTKit library is in charge of core RTKit initialization, smc_rtkit > is in charge of SMC-specific initialization, and smc_core.c is in charge > of core SMC operations and initialization. What, exactly, do you want to > move into drivers/mfd? (hint: not the RTKit library, that is shared by > many other drivers). > > > then call into your Platform and other child devices to initiate the real work. > > There is nothing to call into, the child devices will bind and call > *back* into the SMC core to do their job. "call into" was not a good choice of words here. Simply, let the child devices go about their business and do whatever they were designed to do. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 17:23 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-10-31 17:23 UTC (permalink / raw) To: Hector Martin Cc: Russell King, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Hector Martin wrote: > On 31/10/2022 18.29, Lee Jones wrote: > > On Mon, 31 Oct 2022, Hector Martin wrote: > > > >> On 31/10/2022 17.48, Lee Jones wrote: > >>> On Sat, 29 Oct 2022, Hector Martin wrote: > >>> > >>>> On 09/09/2022 16.50, Lee Jones wrote: > >>>>>> What's the point of just having effectively an array of mfd_cell and > >>>>>> wrappers to call into the mfd core in the drivers/mfd/ tree and the > >>>>>> rest of the driver elsewhere? > >>>>> > >>>>> They should be separate drivers, with MFD registering the Platform. > >>>> > >>>> Why? What purpose does this serve? I'm still confused. There's one > >>>> parent device, which provides services to the child devices. There isn't > >>>> one parent device which wraps a platform service which is used by > >>>> children. This makes no sense. The platform device is the root, if it > >>>> exposes MFD services, then it has to be in that direction, not the other > >>>> way around. > >>>> > >>>> Look at how this patch series is architected. There is smc_core.c, which > >>>> implements SMC helpers and wrappers on top of a generic backend, and > >>>> registers with the MFD subsystem. And then there is smc_rtkit.c which is > >>>> the actual platform implementation on top of the RTKit framework, and is > >>>> the actual platform device entry point. > >>>> > >>>> A priori, the only thing that makes sense to me right now would be to > >>>> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. > >>>> That way the mfd registration would be in drivers/mfd (as would be the > >>>> services offered to sub-drivers), but the actual backend implementation > >>>> would be in platform/ (and there would eventually be others, e.g. at > >>>> least two more for x86 systems). That does mean that the driver entry > >>>> point will be in platform/, with mfd/smc_core.c serving as effectively > >>>> library code to plumb in the mfd stuff into one of several possible > >>>> platform devices. Would that work for you? > >>> > >>> Yes, sounds sensible. However, keep all of the abstraction craziness > >>> somewhere else and fetch and share all of your shared resources from > >>> the MFD (SMC) driver. > >> > >> I'm not sure what you mean by that. The abstraction (smc_core.c) *is* > >> the shared resource. All it does is wrap ops callbacks with a mutex and > >> add a couple helpers for finding keys. Do you literally want us to just > >> have this in drivers/mfd? > >> > >> // SPDX-License-Identifier: GPL-2.0-only OR MIT > >> /* > >> * Apple SMC MFD wrapper > >> * Copyright The Asahi Linux Contributors > >> */ > >> > >> #include <linux/device.h> > >> #include "smc.h" > >> > >> static const struct mfd_cell apple_smc_devs[] = { > >> { > >> .name = "macsmc-gpio", > >> }, > >> { > >> .name = "macsmc-hid", > >> }, > >> { > >> .name = "macsmc-power", > >> }, > >> { > >> .name = "macsmc-reboot", > >> }, > >> { > >> .name = "macsmc-rtc", > >> }, > >> }; > >> > >> int apple_smc_add_mfd_devices(struct device *dev) > >> { > >> ret = mfd_add_devices(dev, -1, apple_smc_devs, > >> ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > >> if (ret) > >> return dev_err_probe(dev, ret, "Subdevice initialization failed"); > >> > >> return 0; > >> } > >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); > >> > >> int apple_smc_remove_mfd_devices(struct device *dev) > >> { > >> mfd_remove_devices(smc->dev); > >> > >> return 0; > >> } > >> EXPORT_SYMBOL(apple_smc_add_mfd_devices); > >> > >> MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > >> MODULE_LICENSE("Dual MIT/GPL"); > >> MODULE_DESCRIPTION("Apple SMC MFD wrapper"); > >> > >> Because this feels *immensely* silly and pointless. > > > > ... and hacky. I agree. > > > > [BTW: if this is all you want to do, have you considered simple-mfd?] > > > > No, I want you to author a proper MFD device. > > You don't seem to understand how MFD devices actually map to the > hardware we're working with here. Via an abstracted message passing API and a little shared memory? The former eventually ending up in the MBOX API? > > The hardware you're describing in this submission *is* an MFD. So use > > the subsystem properly, instead of abusing it as a shim API to simply > > register platform devices. > > *sigh* the hardware I'm describing is a *class* of MFD devices. They all > work the same way as far as the sub-devices see, but operate on > completely different hardware backends. That's common. Usually we're using talking; SPI, I2C, USB and MMIO, but a bespoke message passing API is not out of the realms of normal. > If you do not want "gooey > platform stuff" in drivers/mfd, then it *has* to be a dumb shim. > > You have 3 options: > > - We move everything into drivers/mfd, which means there will > (eventually) be 3 backend modules binding to real hardware devices and > one shared core which actually does the MFD registration and provides > common services. Moving everything isn't an option. A split would be the most reasonable approach. We just need to decide on which parts should reside on which side of the MFD / Platform boundary. > - We move just the core into drivers/mfd, which means the device binding > will happen elsewhere, and the only code in the MFD subsystem will be > common code and will be called as a library (via module exports, not via > device binding). What are you describing as 'the core' here? And which device binding are you alluding to? Sub-device registration or something else? > - We give up and just have a dumb shim in drivers/mfd as above, because > you don't want to work with us. If I wasn't willing to work with you, who are you conversing with? Side-note: Tweeting derogatory comments about the people who have volunteered to take valuable time out of their day to help you, is no good way to encourage people to "work with you"! Most, if not all of us do this willingly and with no additional benefit, purely to help others. Seeing such horrid things spread widely, is a guaranteed way to spoil someone's day. > Either you work with how our hardware works or we go with this dumb shim > workaround. It sounds like you have this the wrong way around. Linux and its associated subsystems aren't going to bend and flex around your design decisions. You need to apply a little flexibility and work with us to find something that'll work for everyone. > You seem to want us to simultaneously "author a proper MFD > device" and "not put platform stuff in MFD". We can't do both at the > same time. Either the code is here or it is elsewhere. Of course you can. Just like everyone else does. After taking quite a bit of time out of my day to look at this today, I can see that your RTKit initialisation implementation is actually much more suited to MFD than the SMC wrappers. One thing that I'm still a little unsure about is future the hierarchy and layering of all these drivers. Which is it you say can / will be swapped out for different methods of initialisation? I see that you pass a bunch of function pointers from the RTKit implementation into the SMC. Which in turn offers an exported (apple_smc_*) API. In most of the frameworks I have knowledge of, the core provides the Ops structure and it's populated by the client device. I'm sure having that clear in my head will go some ways to put me in a position to advise you further. > > Request the device-wide memory (and other shared resources) here. > > That's what smc_rtkit.c does, but you seem not to want that code in mfd. I'm not sure I explicitly said that. > > Conduct core operations and initialisation here > > The RTKit library is in charge of core RTKit initialization, smc_rtkit > is in charge of SMC-specific initialization, and smc_core.c is in charge > of core SMC operations and initialization. What, exactly, do you want to > move into drivers/mfd? (hint: not the RTKit library, that is shared by > many other drivers). > > > then call into your Platform and other child devices to initiate the real work. > > There is nothing to call into, the child devices will bind and call > *back* into the SMC core to do their job. "call into" was not a good choice of words here. Simply, let the child devices go about their business and do whatever they were designed to do. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 17:23 ` Lee Jones @ 2022-10-31 19:34 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-31 19:34 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Oct 31, 2022 at 05:23:12PM +0000, Lee Jones wrote: > I see that you pass a bunch of function pointers from the RTKit > implementation into the SMC. Which in turn offers an exported > (apple_smc_*) API. In most of the frameworks I have knowledge of, the > core provides the Ops structure and it's populated by the client > device. Sorry Lee, I don't get this point. From what I can see, the apple_smc_backend_ops struct is owned by the core System Management Controller code, and RTKit backend fills in an instance of these ops and provides that to the core SMC code. The RTKit backend is just how we walk to the System Management Controller. It is not a client. I don't see this being any different to struct file_operations, seq_operations, vm_operations_struct, block_Device_operations, and so on and so forth. Having read your response, I wonder if you're confused about what the smc_core and smc_rtkit code actually are - because you seem to think that smc_rtkit is a _client_ of the smc_core code. It isn't, as I explain above, it's how we talk to the System Management Controller, and smc_core provides a uniform interface to the client drivers such as GPIO, RTC etc. Essentially, we have: Hardware Backend Core Clients .---- RTC / .--- GPIO Mailbox -- RTKit -- SMC Core -- MFD -- HID \ `--- Power `---- Reboot RTKit is just _one_ possible backend, there are other backends that can be used to interface to the underlying platform implementation to talk to the SMC. > I'm sure having that clear in my head will go some ways to put me in a > position to advise you further. > > > > Request the device-wide memory (and other shared resources) here. > > > > That's what smc_rtkit.c does, but you seem not to want that code in mfd. > > I'm not sure I explicitly said that. On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: | If we were to design and build it up again from scratch, I'd suggest | that the MFD part would be the core-driver / entry-point. That driver | should request and initialise shared resources and register the other | devices, which is essentially the MFD's mantra. This is exactly what smc_rtkit is doing, which as I've mentioned above is the backend provider of access to the System Management Controller. Backend-independent access to the System Management Controller is done via smc_core which - at least to me - seems to be entirely correct, and it seems entirely appropriate that this should be responsible for creating the individual clients that make use of the System Management Controller's facilities such as GPIO, RTC etc. > "call into" was not a good choice of words here. Simply, let the > child devices go about their business and do whatever they were > designed to do. ... by calling into the code which provides them with access to the System Management Controller - that being through smc_core and ultimately which ever backend is used to finally communicate with the System Management Controller. At this point, I'm wondering whether you're somehow expecting client devices to map memory and read/write some registers. This is not that kind of setup. The address space is entirely virtual, through a set of four byte keys that indicate to the System Management Controller which fine-grained resource one wants to access. That being an individual GPIO line or some other parameter of the system. The memory that you see smc_rtkit claim is for passing messages, none of the clients have a right to directly access that memory - indeed, doing so would be a total layering violation and really bad bit of design. So, I hope my response helps fill in some of the detail about what this code is doing, how it works and how it's been designed. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-10-31 19:34 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-31 19:34 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Oct 31, 2022 at 05:23:12PM +0000, Lee Jones wrote: > I see that you pass a bunch of function pointers from the RTKit > implementation into the SMC. Which in turn offers an exported > (apple_smc_*) API. In most of the frameworks I have knowledge of, the > core provides the Ops structure and it's populated by the client > device. Sorry Lee, I don't get this point. From what I can see, the apple_smc_backend_ops struct is owned by the core System Management Controller code, and RTKit backend fills in an instance of these ops and provides that to the core SMC code. The RTKit backend is just how we walk to the System Management Controller. It is not a client. I don't see this being any different to struct file_operations, seq_operations, vm_operations_struct, block_Device_operations, and so on and so forth. Having read your response, I wonder if you're confused about what the smc_core and smc_rtkit code actually are - because you seem to think that smc_rtkit is a _client_ of the smc_core code. It isn't, as I explain above, it's how we talk to the System Management Controller, and smc_core provides a uniform interface to the client drivers such as GPIO, RTC etc. Essentially, we have: Hardware Backend Core Clients .---- RTC / .--- GPIO Mailbox -- RTKit -- SMC Core -- MFD -- HID \ `--- Power `---- Reboot RTKit is just _one_ possible backend, there are other backends that can be used to interface to the underlying platform implementation to talk to the SMC. > I'm sure having that clear in my head will go some ways to put me in a > position to advise you further. > > > > Request the device-wide memory (and other shared resources) here. > > > > That's what smc_rtkit.c does, but you seem not to want that code in mfd. > > I'm not sure I explicitly said that. On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: | If we were to design and build it up again from scratch, I'd suggest | that the MFD part would be the core-driver / entry-point. That driver | should request and initialise shared resources and register the other | devices, which is essentially the MFD's mantra. This is exactly what smc_rtkit is doing, which as I've mentioned above is the backend provider of access to the System Management Controller. Backend-independent access to the System Management Controller is done via smc_core which - at least to me - seems to be entirely correct, and it seems entirely appropriate that this should be responsible for creating the individual clients that make use of the System Management Controller's facilities such as GPIO, RTC etc. > "call into" was not a good choice of words here. Simply, let the > child devices go about their business and do whatever they were > designed to do. ... by calling into the code which provides them with access to the System Management Controller - that being through smc_core and ultimately which ever backend is used to finally communicate with the System Management Controller. At this point, I'm wondering whether you're somehow expecting client devices to map memory and read/write some registers. This is not that kind of setup. The address space is entirely virtual, through a set of four byte keys that indicate to the System Management Controller which fine-grained resource one wants to access. That being an individual GPIO line or some other parameter of the system. The memory that you see smc_rtkit claim is for passing messages, none of the clients have a right to directly access that memory - indeed, doing so would be a total layering violation and really bad bit of design. So, I hope my response helps fill in some of the detail about what this code is doing, how it works and how it's been designed. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-10-31 19:34 ` Russell King (Oracle) @ 2022-11-02 13:12 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-02 13:12 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > On Mon, Oct 31, 2022 at 05:23:12PM +0000, Lee Jones wrote: > > I see that you pass a bunch of function pointers from the RTKit > > implementation into the SMC. Which in turn offers an exported > > (apple_smc_*) API. In most of the frameworks I have knowledge of, the > > core provides the Ops structure and it's populated by the client > > device. > > Sorry Lee, I don't get this point. From what I can see, the > apple_smc_backend_ops struct is owned by the core System Management > Controller code, and RTKit backend fills in an instance of these ops > and provides that to the core SMC code. The RTKit backend is just > how we walk to the System Management Controller. It is not a client. > > I don't see this being any different to struct file_operations, > seq_operations, vm_operations_struct, block_Device_operations, > and so on and so forth. > > Having read your response, I wonder if you're confused about what the > smc_core and smc_rtkit code actually are - because you seem to think > that smc_rtkit is a _client_ of the smc_core code. It isn't, as I > explain above, it's how we talk to the System Management Controller, > and smc_core provides a uniform interface to the client drivers such > as GPIO, RTC etc. > > Essentially, we have: > > Hardware Backend Core Clients > .---- RTC > / .--- GPIO > Mailbox -- RTKit -- SMC Core -- MFD -- HID > \ `--- Power > `---- Reboot The issue I see with the current implementation is that, what you are calling the SMC Core here, is being viewed as the parent to all of these client (child / sub) devices. However, in reality, the SMC Core is little more than a function pointer shim / pass-through without it's own Device. In order for it to register the child-devices, it's effectively borrowing and branching off of the RTKit's Device, which from a Device Driver hierarchy stand-point feels odd. > RTKit is just _one_ possible backend, there are other backends that > can be used to interface to the underlying platform implementation to > talk to the SMC. Right, this is the tricky part. The way I see it, the best route would be to make the RTKit, which is the real Linux Device (with real resources), the direct parent (no sharing) and move it to MFD. However, the looming question then becomes, "what happens when the RTKit is removed and swapped out for something else?", does that mean anything you swap it out with will need to become an MFD also? How would the children get registered otherwise? The TL;DR is, I can see why it's been architected this way, but it doesn't really fit in with the Device Driver norms, which makes it quite difficult to shoehorn in without the issues (using MFD API outside of MFD and borrowing Devices) we're encountering here. > > I'm sure having that clear in my head will go some ways to put me in a > > position to advise you further. > > > > > > Request the device-wide memory (and other shared resources) here. > > > > > > That's what smc_rtkit.c does, but you seem not to want that code in mfd. > > > > I'm not sure I explicitly said that. > > On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: > | If we were to design and build it up again from scratch, I'd suggest > | that the MFD part would be the core-driver / entry-point. That driver > | should request and initialise shared resources and register the other > | devices, which is essentially the MFD's mantra. > > This is exactly what smc_rtkit is doing, which as I've mentioned above > is the backend provider of access to the System Management Controller. > Backend-independent access to the System Management Controller is done > via smc_core which - at least to me - seems to be entirely correct, > and it seems entirely appropriate that this should be responsible for > creating the individual clients that make use of the System Management > Controller's facilities such as GPIO, RTC etc. Making a shim-layer without a real Device become a parent to sub-devices is the part I'm finding most difficult to swallow. > > "call into" was not a good choice of words here. Simply, let the > > child devices go about their business and do whatever they were > > designed to do. > > ... by calling into the code which provides them with access to the > System Management Controller - that being through smc_core and > ultimately which ever backend is used to finally communicate with the > System Management Controller. Right. No problem with that part. Mailbox, I2C, SPI, MMIO, USB, makes no difference to me. > At this point, I'm wondering whether you're somehow expecting client > devices to map memory and read/write some registers. This is not that > kind of setup. The address space is entirely virtual, through a set > of four byte keys that indicate to the System Management Controller > which fine-grained resource one wants to access. That being an > individual GPIO line or some other parameter of the system. No, not at all. A public API mapping to whatever the H/W communication strategy (I2C, SPI, ...) is a perfectly viable implementation. > The memory that you see smc_rtkit claim is for passing messages, none > of the clients have a right to directly access that memory - indeed, > doing so would be a total layering violation and really bad bit of > design. This is not a concept I have an issue understanding. > So, I hope my response helps fill in some of the detail about what > this code is doing, how it works and how it's been designed. I have a strong grasp of the concept presented. :) If we can find an acceptable way to create a proper and correct device hierarchy, I think we're in a good place. My present suggestion is to make the RTKit the MFD and spawn the child devices directly from it. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-11-02 13:12 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-02 13:12 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Mon, 31 Oct 2022, Russell King (Oracle) wrote: > On Mon, Oct 31, 2022 at 05:23:12PM +0000, Lee Jones wrote: > > I see that you pass a bunch of function pointers from the RTKit > > implementation into the SMC. Which in turn offers an exported > > (apple_smc_*) API. In most of the frameworks I have knowledge of, the > > core provides the Ops structure and it's populated by the client > > device. > > Sorry Lee, I don't get this point. From what I can see, the > apple_smc_backend_ops struct is owned by the core System Management > Controller code, and RTKit backend fills in an instance of these ops > and provides that to the core SMC code. The RTKit backend is just > how we walk to the System Management Controller. It is not a client. > > I don't see this being any different to struct file_operations, > seq_operations, vm_operations_struct, block_Device_operations, > and so on and so forth. > > Having read your response, I wonder if you're confused about what the > smc_core and smc_rtkit code actually are - because you seem to think > that smc_rtkit is a _client_ of the smc_core code. It isn't, as I > explain above, it's how we talk to the System Management Controller, > and smc_core provides a uniform interface to the client drivers such > as GPIO, RTC etc. > > Essentially, we have: > > Hardware Backend Core Clients > .---- RTC > / .--- GPIO > Mailbox -- RTKit -- SMC Core -- MFD -- HID > \ `--- Power > `---- Reboot The issue I see with the current implementation is that, what you are calling the SMC Core here, is being viewed as the parent to all of these client (child / sub) devices. However, in reality, the SMC Core is little more than a function pointer shim / pass-through without it's own Device. In order for it to register the child-devices, it's effectively borrowing and branching off of the RTKit's Device, which from a Device Driver hierarchy stand-point feels odd. > RTKit is just _one_ possible backend, there are other backends that > can be used to interface to the underlying platform implementation to > talk to the SMC. Right, this is the tricky part. The way I see it, the best route would be to make the RTKit, which is the real Linux Device (with real resources), the direct parent (no sharing) and move it to MFD. However, the looming question then becomes, "what happens when the RTKit is removed and swapped out for something else?", does that mean anything you swap it out with will need to become an MFD also? How would the children get registered otherwise? The TL;DR is, I can see why it's been architected this way, but it doesn't really fit in with the Device Driver norms, which makes it quite difficult to shoehorn in without the issues (using MFD API outside of MFD and borrowing Devices) we're encountering here. > > I'm sure having that clear in my head will go some ways to put me in a > > position to advise you further. > > > > > > Request the device-wide memory (and other shared resources) here. > > > > > > That's what smc_rtkit.c does, but you seem not to want that code in mfd. > > > > I'm not sure I explicitly said that. > > On Fri, Sep 09, 2022 at 08:50:07AM +0100, Lee Jones wrote: > | If we were to design and build it up again from scratch, I'd suggest > | that the MFD part would be the core-driver / entry-point. That driver > | should request and initialise shared resources and register the other > | devices, which is essentially the MFD's mantra. > > This is exactly what smc_rtkit is doing, which as I've mentioned above > is the backend provider of access to the System Management Controller. > Backend-independent access to the System Management Controller is done > via smc_core which - at least to me - seems to be entirely correct, > and it seems entirely appropriate that this should be responsible for > creating the individual clients that make use of the System Management > Controller's facilities such as GPIO, RTC etc. Making a shim-layer without a real Device become a parent to sub-devices is the part I'm finding most difficult to swallow. > > "call into" was not a good choice of words here. Simply, let the > > child devices go about their business and do whatever they were > > designed to do. > > ... by calling into the code which provides them with access to the > System Management Controller - that being through smc_core and > ultimately which ever backend is used to finally communicate with the > System Management Controller. Right. No problem with that part. Mailbox, I2C, SPI, MMIO, USB, makes no difference to me. > At this point, I'm wondering whether you're somehow expecting client > devices to map memory and read/write some registers. This is not that > kind of setup. The address space is entirely virtual, through a set > of four byte keys that indicate to the System Management Controller > which fine-grained resource one wants to access. That being an > individual GPIO line or some other parameter of the system. No, not at all. A public API mapping to whatever the H/W communication strategy (I2C, SPI, ...) is a perfectly viable implementation. > The memory that you see smc_rtkit claim is for passing messages, none > of the clients have a right to directly access that memory - indeed, > doing so would be a total layering violation and really bad bit of > design. This is not a concept I have an issue understanding. > So, I hope my response helps fill in some of the detail about what > this code is doing, how it works and how it's been designed. I have a strong grasp of the concept presented. :) If we can find an acceptable way to create a proper and correct device hierarchy, I think we're in a good place. My present suggestion is to make the RTKit the MFD and spawn the child devices directly from it. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver 2022-11-02 13:12 ` Lee Jones @ 2022-11-02 15:54 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-02 15:54 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter Hi Lee, One of the things we discussed on IRC was moving the shim to a header file. Moving code into functions in a header file requires the functions to be marked "static inline", and when I mentioned that you seemed to be rather surprised. They need to be static to give them compilation-unit scope so two different users of them don't expose the functions to each other, creating a linker error. They also need to be "inline" so the compiler knows that they're supposed to be shim-style functions and avoids the compiler warning that static functions aren't being used. Most can be moved out, but we end up with one rather large function which feels way too bulky to move into a header file, that being apple_smc_find_first_key_index(). So, this is what it looks like moving everything except that function, and it means we need somewhere for that function to live outside of a header file. This raises the question whether there really is much point to moving the shim out. If we do manage to move the shim out, we're left with the shim initialisation and the MFD bits left in smc_core.c, and we've already established that oving the MFD bits isn't what you're after. So, we could move that initialisation and MFD bits to smc_rtkit.c... but then what happens when the next backend comes along (which will be for Intel based MACs), we would need to duplicate that code in another backend. To me, making this change just feels wrong - not just mildly wrong - because it exposes things that consumers of the SMC API offered by the core shouldn't really know about, such as the contents of struct apple_smc and struct apple_smc_backend_ops. I'm really not sure doing this results in an improvement. Here's the changes on top of this patch set anyway. From what I understand that you want for MFD, you want a single .c file that is a device driver itself, which then talks directly to MFD with nothing else inbetween. The only way I can think of achieving that is to essentially move the contents of smc_rtkit.c into smc_core.c, and when it comes to merging the Intel SMC support, that also has to go into smc_core.c as well - which means we end up with a lot of dead code and #ifdef's in that .c file - which is not nice. drivers/platform/apple/smc.h | 24 +++--- drivers/platform/apple/smc_core.c | 127 ---------------------------- include/linux/mfd/macsmc.h | 136 +++++++++++++++++++++++++++--- 3 files changed, 138 insertions(+), 149 deletions(-) diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h index 8ae51887b2c5..fa86411d5044 100644 --- a/drivers/platform/apple/smc.h +++ b/drivers/platform/apple/smc.h @@ -7,22 +7,24 @@ #ifndef _SMC_H #define _SMC_H +#include <linux/device.h> #include <linux/mfd/macsmc.h> -struct apple_smc_backend_ops { - int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); - int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); - int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); - int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, - void *rbuf, size_t rsize); - int (*get_key_by_index)(void *cookie, int index, smc_key *key); - int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); -}; +static inline void apple_smc_event_received(struct apple_smc *smc, + uint32_t event) +{ + dev_dbg(smc->dev, "Event: 0x%08x\n", event); + + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); +} + +static inline void *apple_smc_get_cookie(struct apple_smc *smc) +{ + return smc->be_cookie; +} struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie); -void *apple_smc_get_cookie(struct apple_smc *smc); int apple_smc_remove(struct apple_smc *smc); -void apple_smc_event_received(struct apple_smc *smc, uint32_t event); #endif diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c index 148a3f8173d3..0902d2f811f4 100644 --- a/drivers/platform/apple/smc_core.c +++ b/drivers/platform/apple/smc_core.c @@ -6,25 +6,8 @@ #include <linux/device.h> #include <linux/mfd/core.h> -#include <linux/mutex.h> -#include <linux/notifier.h> #include "smc.h" -struct apple_smc { - struct device *dev; - - void *be_cookie; - const struct apple_smc_backend_ops *be; - - struct mutex mutex; - - u32 key_count; - smc_key first_key; - smc_key last_key; - - struct blocking_notifier_head event_handlers; -}; - static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", @@ -44,85 +27,6 @@ static const struct mfd_cell apple_smc_devs[] = { }, }; -int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->read_key(smc->be_cookie, key, buf, size); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_read); - -int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->write_key(smc->be_cookie, key, buf, size); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_write); - -int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) -{ - int ret; - - /* - * Will fail if SMC is busy. This is only used by SMC reboot/poweroff - * final calls, so it doesn't really matter at that point. - */ - if (!mutex_trylock(&smc->mutex)) - return -EBUSY; - - ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_write_atomic); - -int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, - void *rbuf, size_t rsize) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_rw); - -int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->get_key_by_index(smc->be_cookie, index, key); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_get_key_by_index); - -int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->get_key_info(smc->be_cookie, key, info); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_get_key_info); - int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) { int start = 0, count = smc->key_count; @@ -158,37 +62,6 @@ int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) } EXPORT_SYMBOL(apple_smc_find_first_key_index); -int apple_smc_get_key_count(struct apple_smc *smc) -{ - return smc->key_count; -} -EXPORT_SYMBOL(apple_smc_get_key_count); - -void apple_smc_event_received(struct apple_smc *smc, uint32_t event) -{ - dev_dbg(smc->dev, "Event: 0x%08x\n", event); - blocking_notifier_call_chain(&smc->event_handlers, event, NULL); -} -EXPORT_SYMBOL(apple_smc_event_received); - -int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) -{ - return blocking_notifier_chain_register(&smc->event_handlers, n); -} -EXPORT_SYMBOL(apple_smc_register_notifier); - -int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) -{ - return blocking_notifier_chain_unregister(&smc->event_handlers, n); -} -EXPORT_SYMBOL(apple_smc_unregister_notifier); - -void *apple_smc_get_cookie(struct apple_smc *smc) -{ - return smc->be_cookie; -} -EXPORT_SYMBOL(apple_smc_get_cookie); - struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) { struct apple_smc *smc; diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h index 39b4dc4ca881..147d6f957cb1 100644 --- a/include/linux/mfd/macsmc.h +++ b/include/linux/mfd/macsmc.h @@ -7,7 +7,10 @@ #ifndef _LINUX_MFD_MACSMC_H #define _LINUX_MFD_MACSMC_H -struct apple_smc; +#include <linux/errno.h> +#include <linux/mutex.h> +#include <linux/notifier.h> +#include <linux/types.h> typedef u32 smc_key; @@ -24,16 +27,118 @@ struct apple_smc_key_info { u8 flags; }; -int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); -int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); -int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); -int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, - void *rbuf, size_t rsize); +struct device; + +struct apple_smc_backend_ops { + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + int (*get_key_by_index)(void *cookie, int index, smc_key *key); + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); +}; + +struct apple_smc { + struct device *dev; + + void *be_cookie; + const struct apple_smc_backend_ops *be; + + struct mutex mutex; + + u32 key_count; + smc_key first_key; + smc_key last_key; + + struct blocking_notifier_head event_handlers; +}; + +static inline int apple_smc_read(struct apple_smc *smc, smc_key key, + void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->read_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_write(struct apple_smc *smc, smc_key key, + void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->write_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, + void *buf, size_t size) +{ + int ret; + + /* + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff + * final calls, so it shouldn't really matter at that point. + */ + if (!mutex_trylock(&smc->mutex)) + return -EBUSY; + + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_rw(struct apple_smc *smc, smc_key key, + void *wbuf, size_t wsize, + void *rbuf, size_t rsize) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_get_key_count(struct apple_smc *smc) +{ + return smc->key_count; +} + +static inline int apple_smc_get_key_by_index(struct apple_smc *smc, int index, + smc_key *key) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, + struct apple_smc_key_info *info) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_info(smc->be_cookie, key, info); + mutex_unlock(&smc->mutex); + + return ret; +} -int apple_smc_get_key_count(struct apple_smc *smc); int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); -int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); -int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) { @@ -80,7 +185,16 @@ static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) } #define apple_smc_write_flag apple_smc_write_u8 -int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); -int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); +static inline int apple_smc_register_notifier(struct apple_smc *smc, + struct notifier_block *n) +{ + return blocking_notifier_chain_register(&smc->event_handlers, n); +} + +static inline int apple_smc_unregister_notifier(struct apple_smc *smc, + struct notifier_block *n) +{ + return blocking_notifier_chain_unregister(&smc->event_handlers, n); +} #endif -- 2.30.2 -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver @ 2022-11-02 15:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-02 15:54 UTC (permalink / raw) To: Lee Jones Cc: Hector Martin, Arnd Bergmann, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter Hi Lee, One of the things we discussed on IRC was moving the shim to a header file. Moving code into functions in a header file requires the functions to be marked "static inline", and when I mentioned that you seemed to be rather surprised. They need to be static to give them compilation-unit scope so two different users of them don't expose the functions to each other, creating a linker error. They also need to be "inline" so the compiler knows that they're supposed to be shim-style functions and avoids the compiler warning that static functions aren't being used. Most can be moved out, but we end up with one rather large function which feels way too bulky to move into a header file, that being apple_smc_find_first_key_index(). So, this is what it looks like moving everything except that function, and it means we need somewhere for that function to live outside of a header file. This raises the question whether there really is much point to moving the shim out. If we do manage to move the shim out, we're left with the shim initialisation and the MFD bits left in smc_core.c, and we've already established that oving the MFD bits isn't what you're after. So, we could move that initialisation and MFD bits to smc_rtkit.c... but then what happens when the next backend comes along (which will be for Intel based MACs), we would need to duplicate that code in another backend. To me, making this change just feels wrong - not just mildly wrong - because it exposes things that consumers of the SMC API offered by the core shouldn't really know about, such as the contents of struct apple_smc and struct apple_smc_backend_ops. I'm really not sure doing this results in an improvement. Here's the changes on top of this patch set anyway. From what I understand that you want for MFD, you want a single .c file that is a device driver itself, which then talks directly to MFD with nothing else inbetween. The only way I can think of achieving that is to essentially move the contents of smc_rtkit.c into smc_core.c, and when it comes to merging the Intel SMC support, that also has to go into smc_core.c as well - which means we end up with a lot of dead code and #ifdef's in that .c file - which is not nice. drivers/platform/apple/smc.h | 24 +++--- drivers/platform/apple/smc_core.c | 127 ---------------------------- include/linux/mfd/macsmc.h | 136 +++++++++++++++++++++++++++--- 3 files changed, 138 insertions(+), 149 deletions(-) diff --git a/drivers/platform/apple/smc.h b/drivers/platform/apple/smc.h index 8ae51887b2c5..fa86411d5044 100644 --- a/drivers/platform/apple/smc.h +++ b/drivers/platform/apple/smc.h @@ -7,22 +7,24 @@ #ifndef _SMC_H #define _SMC_H +#include <linux/device.h> #include <linux/mfd/macsmc.h> -struct apple_smc_backend_ops { - int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); - int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); - int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); - int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, - void *rbuf, size_t rsize); - int (*get_key_by_index)(void *cookie, int index, smc_key *key); - int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); -}; +static inline void apple_smc_event_received(struct apple_smc *smc, + uint32_t event) +{ + dev_dbg(smc->dev, "Event: 0x%08x\n", event); + + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); +} + +static inline void *apple_smc_get_cookie(struct apple_smc *smc) +{ + return smc->be_cookie; +} struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie); -void *apple_smc_get_cookie(struct apple_smc *smc); int apple_smc_remove(struct apple_smc *smc); -void apple_smc_event_received(struct apple_smc *smc, uint32_t event); #endif diff --git a/drivers/platform/apple/smc_core.c b/drivers/platform/apple/smc_core.c index 148a3f8173d3..0902d2f811f4 100644 --- a/drivers/platform/apple/smc_core.c +++ b/drivers/platform/apple/smc_core.c @@ -6,25 +6,8 @@ #include <linux/device.h> #include <linux/mfd/core.h> -#include <linux/mutex.h> -#include <linux/notifier.h> #include "smc.h" -struct apple_smc { - struct device *dev; - - void *be_cookie; - const struct apple_smc_backend_ops *be; - - struct mutex mutex; - - u32 key_count; - smc_key first_key; - smc_key last_key; - - struct blocking_notifier_head event_handlers; -}; - static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", @@ -44,85 +27,6 @@ static const struct mfd_cell apple_smc_devs[] = { }, }; -int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->read_key(smc->be_cookie, key, buf, size); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_read); - -int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->write_key(smc->be_cookie, key, buf, size); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_write); - -int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) -{ - int ret; - - /* - * Will fail if SMC is busy. This is only used by SMC reboot/poweroff - * final calls, so it doesn't really matter at that point. - */ - if (!mutex_trylock(&smc->mutex)) - return -EBUSY; - - ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_write_atomic); - -int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, - void *rbuf, size_t rsize) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_rw); - -int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->get_key_by_index(smc->be_cookie, index, key); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_get_key_by_index); - -int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) -{ - int ret; - - mutex_lock(&smc->mutex); - ret = smc->be->get_key_info(smc->be_cookie, key, info); - mutex_unlock(&smc->mutex); - - return ret; -} -EXPORT_SYMBOL(apple_smc_get_key_info); - int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) { int start = 0, count = smc->key_count; @@ -158,37 +62,6 @@ int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) } EXPORT_SYMBOL(apple_smc_find_first_key_index); -int apple_smc_get_key_count(struct apple_smc *smc) -{ - return smc->key_count; -} -EXPORT_SYMBOL(apple_smc_get_key_count); - -void apple_smc_event_received(struct apple_smc *smc, uint32_t event) -{ - dev_dbg(smc->dev, "Event: 0x%08x\n", event); - blocking_notifier_call_chain(&smc->event_handlers, event, NULL); -} -EXPORT_SYMBOL(apple_smc_event_received); - -int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) -{ - return blocking_notifier_chain_register(&smc->event_handlers, n); -} -EXPORT_SYMBOL(apple_smc_register_notifier); - -int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) -{ - return blocking_notifier_chain_unregister(&smc->event_handlers, n); -} -EXPORT_SYMBOL(apple_smc_unregister_notifier); - -void *apple_smc_get_cookie(struct apple_smc *smc) -{ - return smc->be_cookie; -} -EXPORT_SYMBOL(apple_smc_get_cookie); - struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) { struct apple_smc *smc; diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h index 39b4dc4ca881..147d6f957cb1 100644 --- a/include/linux/mfd/macsmc.h +++ b/include/linux/mfd/macsmc.h @@ -7,7 +7,10 @@ #ifndef _LINUX_MFD_MACSMC_H #define _LINUX_MFD_MACSMC_H -struct apple_smc; +#include <linux/errno.h> +#include <linux/mutex.h> +#include <linux/notifier.h> +#include <linux/types.h> typedef u32 smc_key; @@ -24,16 +27,118 @@ struct apple_smc_key_info { u8 flags; }; -int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); -int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); -int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); -int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, - void *rbuf, size_t rsize); +struct device; + +struct apple_smc_backend_ops { + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + int (*get_key_by_index)(void *cookie, int index, smc_key *key); + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); +}; + +struct apple_smc { + struct device *dev; + + void *be_cookie; + const struct apple_smc_backend_ops *be; + + struct mutex mutex; + + u32 key_count; + smc_key first_key; + smc_key last_key; + + struct blocking_notifier_head event_handlers; +}; + +static inline int apple_smc_read(struct apple_smc *smc, smc_key key, + void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->read_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_write(struct apple_smc *smc, smc_key key, + void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->write_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, + void *buf, size_t size) +{ + int ret; + + /* + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff + * final calls, so it shouldn't really matter at that point. + */ + if (!mutex_trylock(&smc->mutex)) + return -EBUSY; + + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_rw(struct apple_smc *smc, smc_key key, + void *wbuf, size_t wsize, + void *rbuf, size_t rsize) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_get_key_count(struct apple_smc *smc) +{ + return smc->key_count; +} + +static inline int apple_smc_get_key_by_index(struct apple_smc *smc, int index, + smc_key *key) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); + mutex_unlock(&smc->mutex); + + return ret; +} + +static inline int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, + struct apple_smc_key_info *info) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_info(smc->be_cookie, key, info); + mutex_unlock(&smc->mutex); + + return ret; +} -int apple_smc_get_key_count(struct apple_smc *smc); int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); -int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); -int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) { @@ -80,7 +185,16 @@ static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) } #define apple_smc_write_flag apple_smc_write_u8 -int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); -int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); +static inline int apple_smc_register_notifier(struct apple_smc *smc, + struct notifier_block *n) +{ + return blocking_notifier_chain_register(&smc->event_handlers, n); +} + +static inline int apple_smc_unregister_notifier(struct apple_smc *smc, + struct notifier_block *n) +{ + return blocking_notifier_chain_unregister(&smc->event_handlers, n); +} #endif -- 2.30.2 -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 13:54 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements the GPIO service on top of the SMC framework on Apple Mac machines. In particular, these are the GPIOs present in the PMU IC which are used to control power to certain on-board devices. Although the underlying hardware supports various pin config settings (input/output, open drain, etc.), this driver does not implement that functionality and leaves it up to the firmware to configure things properly. We also don't yet support interrupts/events. This is sufficient for device power control, which is the only thing we need to support at this point. More features will be implemented when needed. To our knowledge, only Apple Silicon Macs implement this SMC feature. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/gpio/Kconfig | 11 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 238 +++++++++++++++++++++++++++++++++++++ 3 files changed, 250 insertions(+) create mode 100644 drivers/gpio/gpio-macsmc.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 0642f579196f..9b87f5ebe1b9 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -1292,6 +1292,17 @@ config GPIO_LP87565 This driver can also be built as a module. If so, the module will be called gpio-lp87565. +config GPIO_MACSMC + tristate "Apple Mac SMC GPIO" + depends on APPLE_SMC + default ARCH_APPLE + help + Support for GPIOs controlled by the SMC microcontroller on Apple Mac + systems. + + This driver can also be built as a module. If so, the module will be + called gpio-macsmc. + config GPIO_MADERA tristate "Cirrus Logic Madera class codecs" depends on PINCTRL_MADERA diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index a0985d30f51b..a401a467c6f4 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o +obj-$(CONFIG_GPIO_MACSMC) += gpio-macsmc.o obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o diff --git a/drivers/gpio/gpio-macsmc.c b/drivers/gpio/gpio-macsmc.c new file mode 100644 index 000000000000..ff9950afb69a --- /dev/null +++ b/drivers/gpio/gpio-macsmc.c @@ -0,0 +1,238 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC GPIO driver + * Copyright The Asahi Linux Contributors + * + * This driver implements basic SMC PMU GPIO support that can read inputs + * and write outputs. Mode changes and IRQ config are not yet implemented. + */ + +#include <linux/bitmap.h> +#include <linux/device.h> +#include <linux/gpio/driver.h> +#include <linux/mfd/core.h> +#include <linux/mfd/macsmc.h> + +#define MAX_GPIO 64 + +/* + * Commands 0-6 are, presumably, the intended API. + * Command 0xff lets you get/set the pin configuration in detail directly, + * but the bit meanings seem not to be stable between devices/PMU hardware + * versions. + * + * We're going to try to make do with the low commands for now. + * We don't implement pin mode changes at this time. + */ + +#define CMD_ACTION (0 << 24) +#define CMD_OUTPUT (1 << 24) +#define CMD_INPUT (2 << 24) +#define CMD_PINMODE (3 << 24) +#define CMD_IRQ_ENABLE (4 << 24) +#define CMD_IRQ_ACK (5 << 24) +#define CMD_IRQ_MODE (6 << 24) +#define CMD_CONFIG (0xff << 24) + +#define MODE_INPUT 0 +#define MODE_OUTPUT 1 +#define MODE_VALUE_0 0 +#define MODE_VALUE_1 2 + +#define IRQ_MODE_HIGH 0 +#define IRQ_MODE_LOW 1 +#define IRQ_MODE_RISING 2 +#define IRQ_MODE_FALLING 3 +#define IRQ_MODE_BOTH 4 + +#define CONFIG_MASK GENMASK(23, 16) +#define CONFIG_VAL GENMASK(7, 0) + +#define CONFIG_OUTMODE GENMASK(7, 6) +#define CONFIG_IRQMODE GENMASK(5, 3) +#define CONFIG_PULLDOWN BIT(2) +#define CONFIG_PULLUP BIT(1) +#define CONFIG_OUTVAL BIT(0) + +/* + * output modes seem to differ depending on the PMU in use... ? + * j274 / M1 (Sera PMU): + * 0 = input + * 1 = output + * 2 = open drain + * 3 = disable + * j314 / M1Pro (Maverick PMU): + * 0 = input + * 1 = open drain + * 2 = output + * 3 = ? + */ + +struct macsmc_gpio { + struct device *dev; + struct apple_smc *smc; + struct gpio_chip gc; + + int first_index; +}; + +static int macsmc_gpio_nr(smc_key key) +{ + int low = hex_to_bin(key & 0xff); + int high = hex_to_bin((key >> 8) & 0xff); + + if (low < 0 || high < 0) + return -1; + + return low | (high << 4); +} + +static int macsmc_gpio_key(unsigned int offset) +{ + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); +} + +static int macsmc_gpio_get_direction(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 val; + int ret; + + /* First try reading the explicit pin mode register */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); + if (!ret) + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; + + /* + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. + * Fall back to reading IRQ mode, which will only succeed for inputs. + */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; +} + +static int macsmc_gpio_get(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 val; + int ret; + + ret = macsmc_gpio_get_direction(gc, offset); + if (ret < 0) + return ret; + + if (ret == GPIO_LINE_DIRECTION_OUT) + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); + else + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); + + if (ret < 0) + return ret; + + return val ? 1 : 0; +} + +static void macsmc_gpio_set(struct gpio_chip *gc, unsigned int offset, int value) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + int ret; + + value |= CMD_OUTPUT; + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); + if (ret < 0) + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); +} + +static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, + unsigned long *valid_mask, unsigned int ngpios) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; + int i; + + if (count > MAX_GPIO) + count = MAX_GPIO; + + bitmap_zero(valid_mask, ngpios); + + for (i = 0; i < count; i++) { + smc_key key; + int gpio_nr; + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); + + if (ret < 0) + return ret; + + if (key > SMC_KEY(gPff)) + break; + + gpio_nr = macsmc_gpio_nr(key); + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); + continue; + } + + set_bit(gpio_nr, valid_mask); + } + + return 0; +} + +static int macsmc_gpio_probe(struct platform_device *pdev) +{ + struct macsmc_gpio *smcgp; + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent); + smc_key key; + int ret; + + smcgp = devm_kzalloc(&pdev->dev, sizeof(*smcgp), GFP_KERNEL); + if (!smcgp) + return -ENOMEM; + + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); + + smcgp->dev = &pdev->dev; + smcgp->smc = smc; + smcgp->first_index = apple_smc_find_first_key_index(smc, SMC_KEY(gP00)); + + if (smcgp->first_index >= apple_smc_get_key_count(smc)) + return -ENODEV; + + ret = apple_smc_get_key_by_index(smc, smcgp->first_index, &key); + if (ret < 0) + return ret; + + if (key > macsmc_gpio_key(MAX_GPIO - 1)) + return -ENODEV; + + dev_info(smcgp->dev, "First GPIO key: %p4ch\n", &key); + + smcgp->gc.label = "macsmc-pmu-gpio"; + smcgp->gc.owner = THIS_MODULE; + smcgp->gc.get = macsmc_gpio_get; + smcgp->gc.set = macsmc_gpio_set; + smcgp->gc.get_direction = macsmc_gpio_get_direction; + smcgp->gc.init_valid_mask = macsmc_gpio_init_valid_mask; + smcgp->gc.can_sleep = true; + smcgp->gc.ngpio = MAX_GPIO; + smcgp->gc.base = -1; + smcgp->gc.parent = &pdev->dev; + + return devm_gpiochip_add_data(&pdev->dev, &smcgp->gc, smcgp); +} + +static struct platform_driver macsmc_gpio_driver = { + .driver = { + .name = "macsmc-gpio", + }, + .probe = macsmc_gpio_probe, +}; +module_platform_driver(macsmc_gpio_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC GPIO driver"); +MODULE_ALIAS("platform:macsmc-gpio"); -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-01 13:54 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements the GPIO service on top of the SMC framework on Apple Mac machines. In particular, these are the GPIOs present in the PMU IC which are used to control power to certain on-board devices. Although the underlying hardware supports various pin config settings (input/output, open drain, etc.), this driver does not implement that functionality and leaves it up to the firmware to configure things properly. We also don't yet support interrupts/events. This is sufficient for device power control, which is the only thing we need to support at this point. More features will be implemented when needed. To our knowledge, only Apple Silicon Macs implement this SMC feature. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/gpio/Kconfig | 11 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 238 +++++++++++++++++++++++++++++++++++++ 3 files changed, 250 insertions(+) create mode 100644 drivers/gpio/gpio-macsmc.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 0642f579196f..9b87f5ebe1b9 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -1292,6 +1292,17 @@ config GPIO_LP87565 This driver can also be built as a module. If so, the module will be called gpio-lp87565. +config GPIO_MACSMC + tristate "Apple Mac SMC GPIO" + depends on APPLE_SMC + default ARCH_APPLE + help + Support for GPIOs controlled by the SMC microcontroller on Apple Mac + systems. + + This driver can also be built as a module. If so, the module will be + called gpio-macsmc. + config GPIO_MADERA tristate "Cirrus Logic Madera class codecs" depends on PINCTRL_MADERA diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index a0985d30f51b..a401a467c6f4 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o +obj-$(CONFIG_GPIO_MACSMC) += gpio-macsmc.o obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o diff --git a/drivers/gpio/gpio-macsmc.c b/drivers/gpio/gpio-macsmc.c new file mode 100644 index 000000000000..ff9950afb69a --- /dev/null +++ b/drivers/gpio/gpio-macsmc.c @@ -0,0 +1,238 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC GPIO driver + * Copyright The Asahi Linux Contributors + * + * This driver implements basic SMC PMU GPIO support that can read inputs + * and write outputs. Mode changes and IRQ config are not yet implemented. + */ + +#include <linux/bitmap.h> +#include <linux/device.h> +#include <linux/gpio/driver.h> +#include <linux/mfd/core.h> +#include <linux/mfd/macsmc.h> + +#define MAX_GPIO 64 + +/* + * Commands 0-6 are, presumably, the intended API. + * Command 0xff lets you get/set the pin configuration in detail directly, + * but the bit meanings seem not to be stable between devices/PMU hardware + * versions. + * + * We're going to try to make do with the low commands for now. + * We don't implement pin mode changes at this time. + */ + +#define CMD_ACTION (0 << 24) +#define CMD_OUTPUT (1 << 24) +#define CMD_INPUT (2 << 24) +#define CMD_PINMODE (3 << 24) +#define CMD_IRQ_ENABLE (4 << 24) +#define CMD_IRQ_ACK (5 << 24) +#define CMD_IRQ_MODE (6 << 24) +#define CMD_CONFIG (0xff << 24) + +#define MODE_INPUT 0 +#define MODE_OUTPUT 1 +#define MODE_VALUE_0 0 +#define MODE_VALUE_1 2 + +#define IRQ_MODE_HIGH 0 +#define IRQ_MODE_LOW 1 +#define IRQ_MODE_RISING 2 +#define IRQ_MODE_FALLING 3 +#define IRQ_MODE_BOTH 4 + +#define CONFIG_MASK GENMASK(23, 16) +#define CONFIG_VAL GENMASK(7, 0) + +#define CONFIG_OUTMODE GENMASK(7, 6) +#define CONFIG_IRQMODE GENMASK(5, 3) +#define CONFIG_PULLDOWN BIT(2) +#define CONFIG_PULLUP BIT(1) +#define CONFIG_OUTVAL BIT(0) + +/* + * output modes seem to differ depending on the PMU in use... ? + * j274 / M1 (Sera PMU): + * 0 = input + * 1 = output + * 2 = open drain + * 3 = disable + * j314 / M1Pro (Maverick PMU): + * 0 = input + * 1 = open drain + * 2 = output + * 3 = ? + */ + +struct macsmc_gpio { + struct device *dev; + struct apple_smc *smc; + struct gpio_chip gc; + + int first_index; +}; + +static int macsmc_gpio_nr(smc_key key) +{ + int low = hex_to_bin(key & 0xff); + int high = hex_to_bin((key >> 8) & 0xff); + + if (low < 0 || high < 0) + return -1; + + return low | (high << 4); +} + +static int macsmc_gpio_key(unsigned int offset) +{ + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); +} + +static int macsmc_gpio_get_direction(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 val; + int ret; + + /* First try reading the explicit pin mode register */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); + if (!ret) + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; + + /* + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. + * Fall back to reading IRQ mode, which will only succeed for inputs. + */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; +} + +static int macsmc_gpio_get(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 val; + int ret; + + ret = macsmc_gpio_get_direction(gc, offset); + if (ret < 0) + return ret; + + if (ret == GPIO_LINE_DIRECTION_OUT) + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); + else + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); + + if (ret < 0) + return ret; + + return val ? 1 : 0; +} + +static void macsmc_gpio_set(struct gpio_chip *gc, unsigned int offset, int value) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + int ret; + + value |= CMD_OUTPUT; + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); + if (ret < 0) + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); +} + +static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, + unsigned long *valid_mask, unsigned int ngpios) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; + int i; + + if (count > MAX_GPIO) + count = MAX_GPIO; + + bitmap_zero(valid_mask, ngpios); + + for (i = 0; i < count; i++) { + smc_key key; + int gpio_nr; + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); + + if (ret < 0) + return ret; + + if (key > SMC_KEY(gPff)) + break; + + gpio_nr = macsmc_gpio_nr(key); + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); + continue; + } + + set_bit(gpio_nr, valid_mask); + } + + return 0; +} + +static int macsmc_gpio_probe(struct platform_device *pdev) +{ + struct macsmc_gpio *smcgp; + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent); + smc_key key; + int ret; + + smcgp = devm_kzalloc(&pdev->dev, sizeof(*smcgp), GFP_KERNEL); + if (!smcgp) + return -ENOMEM; + + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); + + smcgp->dev = &pdev->dev; + smcgp->smc = smc; + smcgp->first_index = apple_smc_find_first_key_index(smc, SMC_KEY(gP00)); + + if (smcgp->first_index >= apple_smc_get_key_count(smc)) + return -ENODEV; + + ret = apple_smc_get_key_by_index(smc, smcgp->first_index, &key); + if (ret < 0) + return ret; + + if (key > macsmc_gpio_key(MAX_GPIO - 1)) + return -ENODEV; + + dev_info(smcgp->dev, "First GPIO key: %p4ch\n", &key); + + smcgp->gc.label = "macsmc-pmu-gpio"; + smcgp->gc.owner = THIS_MODULE; + smcgp->gc.get = macsmc_gpio_get; + smcgp->gc.set = macsmc_gpio_set; + smcgp->gc.get_direction = macsmc_gpio_get_direction; + smcgp->gc.init_valid_mask = macsmc_gpio_init_valid_mask; + smcgp->gc.can_sleep = true; + smcgp->gc.ngpio = MAX_GPIO; + smcgp->gc.base = -1; + smcgp->gc.parent = &pdev->dev; + + return devm_gpiochip_add_data(&pdev->dev, &smcgp->gc, smcgp); +} + +static struct platform_driver macsmc_gpio_driver = { + .driver = { + .name = "macsmc-gpio", + }, + .probe = macsmc_gpio_probe, +}; +module_platform_driver(macsmc_gpio_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC GPIO driver"); +MODULE_ALIAS("platform:macsmc-gpio"); -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 13:54 ` Russell King @ 2022-09-01 18:55 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-01 18:55 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > This driver implements the GPIO service on top of the SMC framework > on Apple Mac machines. In particular, these are the GPIOs present in the > PMU IC which are used to control power to certain on-board devices. > > Although the underlying hardware supports various pin config settings > (input/output, open drain, etc.), this driver does not implement that > functionality and leaves it up to the firmware to configure things > properly. We also don't yet support interrupts/events. This is > sufficient for device power control, which is the only thing we need to > support at this point. More features will be implemented when needed. > > To our knowledge, only Apple Silicon Macs implement this SMC feature. ... > +/* > + * Commands 0-6 are, presumably, the intended API. > + * Command 0xff lets you get/set the pin configuration in detail directly, > + * but the bit meanings seem not to be stable between devices/PMU hardware > + * versions. Probably for debugging purposes... > + * > + * We're going to try to make do with the low commands for now. > + * We don't implement pin mode changes at this time. > + */ ... > +/* > + * output modes seem to differ depending on the PMU in use... ? Output > + * j274 / M1 (Sera PMU): > + * 0 = input > + * 1 = output > + * 2 = open drain > + * 3 = disable > + * j314 / M1Pro (Maverick PMU): > + * 0 = input > + * 1 = open drain > + * 2 = output > + * 3 = ? > + */ ... > +struct macsmc_gpio { > + struct device *dev; > + struct apple_smc *smc; > + struct gpio_chip gc; You might save some CPU cycles / code by shuffling members around. Usually we put gpio_chip as a first one, so pointer arithmetics to get it becomes a bit simpler, but it needs to be checked by the tool and also paying attention to what is used in critical paths (so performance-wise). > + int first_index; > +}; ... > +static int macsmc_gpio_nr(smc_key key) > +{ > + int low = hex_to_bin(key & 0xff); > + int high = hex_to_bin((key >> 8) & 0xff); > + > + if (low < 0 || high < 0) > + return -1; > + > + return low | (high << 4); > +} NIH hex2bin(). > +static int macsmc_gpio_key(unsigned int offset) > +{ > + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); > +} NIH hex_byte_pack(). ... > + /* First try reading the explicit pin mode register */ > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > + if (!ret) > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > + > + /* > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > + * Fall back to reading IRQ mode, which will only succeed for inputs. > + */ > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; What is the meaning of val in this case? ... > + if (ret == GPIO_LINE_DIRECTION_OUT) > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); > + else > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); > + Unnecessary blank line. > + if (ret < 0) > + return ret; ... > + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); > + if (ret < 0) > + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); Strange specifier... It seems like a hashed pointer with added (or skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', '%p4cc'? Ditto for other cases. ... > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; I would split this assignment and move it closer to the first user. > + int i; > + > + if (count > MAX_GPIO) > + count = MAX_GPIO; Hmm... When can it be the case? > + bitmap_zero(valid_mask, ngpios); > + > + for (i = 0; i < count; i++) { > + smc_key key; > + int gpio_nr; > + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); Ditto. > + > + if (ret < 0) > + return ret; > + > + if (key > SMC_KEY(gPff)) > + break; > + > + gpio_nr = macsmc_gpio_nr(key); > + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { > + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); Yeah, according to the code it will print something you didn't want. > + continue; > + } > + > + set_bit(gpio_nr, valid_mask); > + } > + > + return 0; > +} ... > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); Can we use fwnode APIs instead? Or do you really need this? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-01 18:55 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-01 18:55 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > This driver implements the GPIO service on top of the SMC framework > on Apple Mac machines. In particular, these are the GPIOs present in the > PMU IC which are used to control power to certain on-board devices. > > Although the underlying hardware supports various pin config settings > (input/output, open drain, etc.), this driver does not implement that > functionality and leaves it up to the firmware to configure things > properly. We also don't yet support interrupts/events. This is > sufficient for device power control, which is the only thing we need to > support at this point. More features will be implemented when needed. > > To our knowledge, only Apple Silicon Macs implement this SMC feature. ... > +/* > + * Commands 0-6 are, presumably, the intended API. > + * Command 0xff lets you get/set the pin configuration in detail directly, > + * but the bit meanings seem not to be stable between devices/PMU hardware > + * versions. Probably for debugging purposes... > + * > + * We're going to try to make do with the low commands for now. > + * We don't implement pin mode changes at this time. > + */ ... > +/* > + * output modes seem to differ depending on the PMU in use... ? Output > + * j274 / M1 (Sera PMU): > + * 0 = input > + * 1 = output > + * 2 = open drain > + * 3 = disable > + * j314 / M1Pro (Maverick PMU): > + * 0 = input > + * 1 = open drain > + * 2 = output > + * 3 = ? > + */ ... > +struct macsmc_gpio { > + struct device *dev; > + struct apple_smc *smc; > + struct gpio_chip gc; You might save some CPU cycles / code by shuffling members around. Usually we put gpio_chip as a first one, so pointer arithmetics to get it becomes a bit simpler, but it needs to be checked by the tool and also paying attention to what is used in critical paths (so performance-wise). > + int first_index; > +}; ... > +static int macsmc_gpio_nr(smc_key key) > +{ > + int low = hex_to_bin(key & 0xff); > + int high = hex_to_bin((key >> 8) & 0xff); > + > + if (low < 0 || high < 0) > + return -1; > + > + return low | (high << 4); > +} NIH hex2bin(). > +static int macsmc_gpio_key(unsigned int offset) > +{ > + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); > +} NIH hex_byte_pack(). ... > + /* First try reading the explicit pin mode register */ > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > + if (!ret) > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > + > + /* > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > + * Fall back to reading IRQ mode, which will only succeed for inputs. > + */ > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; What is the meaning of val in this case? ... > + if (ret == GPIO_LINE_DIRECTION_OUT) > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); > + else > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); > + Unnecessary blank line. > + if (ret < 0) > + return ret; ... > + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); > + if (ret < 0) > + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); Strange specifier... It seems like a hashed pointer with added (or skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', '%p4cc'? Ditto for other cases. ... > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; I would split this assignment and move it closer to the first user. > + int i; > + > + if (count > MAX_GPIO) > + count = MAX_GPIO; Hmm... When can it be the case? > + bitmap_zero(valid_mask, ngpios); > + > + for (i = 0; i < count; i++) { > + smc_key key; > + int gpio_nr; > + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); Ditto. > + > + if (ret < 0) > + return ret; > + > + if (key > SMC_KEY(gPff)) > + break; > + > + gpio_nr = macsmc_gpio_nr(key); > + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { > + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); Yeah, according to the code it will print something you didn't want. > + continue; > + } > + > + set_bit(gpio_nr, valid_mask); > + } > + > + return 0; > +} ... > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); Can we use fwnode APIs instead? Or do you really need this? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 18:55 ` Andy Shevchenko @ 2022-09-01 21:51 ` Martin Povišer -1 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-01 21:51 UTC (permalink / raw) To: Andy Shevchenko Cc: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter > On 1. 9. 2022, at 20:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: >> + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); >> + if (ret < 0) >> + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); > > Strange specifier... It seems like a hashed pointer with added (or > skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', > '%p4cc'? > Ditto for other cases. As was pointed out by Sven elsewhere in the thread, this is an unupstreamed specifier (that was missed as a dependency of this code). https://github.com/AsahiLinux/linux/blob/f8c0d18173a7b649999ee27515393f7aae40310c/Documentation/core-api/printk-formats.rst#generic-fourcc-code Martin ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-01 21:51 ` Martin Povišer 0 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-01 21:51 UTC (permalink / raw) To: Andy Shevchenko Cc: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter > On 1. 9. 2022, at 20:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: >> + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); >> + if (ret < 0) >> + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); > > Strange specifier... It seems like a hashed pointer with added (or > skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', > '%p4cc'? > Ditto for other cases. As was pointed out by Sven elsewhere in the thread, this is an unupstreamed specifier (that was missed as a dependency of this code). https://github.com/AsahiLinux/linux/blob/f8c0d18173a7b649999ee27515393f7aae40310c/Documentation/core-api/printk-formats.rst#generic-fourcc-code Martin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 21:51 ` Martin Povišer @ 2022-09-02 6:31 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 6:31 UTC (permalink / raw) To: povik Cc: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: > > On 1. 9. 2022, at 20:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > >> + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); > >> + if (ret < 0) > >> + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); > > > > Strange specifier... It seems like a hashed pointer with added (or > > skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', > > '%p4cc'? > > Ditto for other cases. > > As was pointed out by Sven elsewhere in the thread, this is an > unupstreamed specifier (that was missed as a dependency of this > code). > > https://github.com/AsahiLinux/linux/blob/f8c0d18173a7b649999ee27515393f7aae40310c/Documentation/core-api/printk-formats.rst#generic-fourcc-code I don't see why we need that. The %.4s (0x%08x) is repeating that with the existing codebase. (I do understand why v4l2/drm have it). Ideally the first should use %4pE, but it might not be suitable in some cases. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 6:31 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 6:31 UTC (permalink / raw) To: povik Cc: Russell King, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: > > On 1. 9. 2022, at 20:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > >> + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); > >> + if (ret < 0) > >> + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); > > > > Strange specifier... It seems like a hashed pointer with added (or > > skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', > > '%p4cc'? > > Ditto for other cases. > > As was pointed out by Sven elsewhere in the thread, this is an > unupstreamed specifier (that was missed as a dependency of this > code). > > https://github.com/AsahiLinux/linux/blob/f8c0d18173a7b649999ee27515393f7aae40310c/Documentation/core-api/printk-formats.rst#generic-fourcc-code I don't see why we need that. The %.4s (0x%08x) is repeating that with the existing codebase. (I do understand why v4l2/drm have it). Ideally the first should use %4pE, but it might not be suitable in some cases. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
[parent not found: <3B649A66-8116-432D-B88A-B5CE493EF930@cutebit.org>]
[parent not found: <CAHp75VeB3_sZ2vsSxMSsLeJSkyemDh9iOPHXJCN1mhodA13LNQ@mail.gmail.com>]
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs [not found] ` <CAHp75VeB3_sZ2vsSxMSsLeJSkyemDh9iOPHXJCN1mhodA13LNQ@mail.gmail.com> @ 2022-09-02 11:12 ` Martin Povišer 0 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-02 11:12 UTC (permalink / raw) To: Andy Shevchenko Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter Pardon, I lost the CC list in my earlier reply. Adding it back now. > On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: >>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: >>>>> On 1. 9. 2022, at 20:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>>>> On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: >>>> >>>>>> + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); >>>>>> + if (ret < 0) >>>>>> + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); >>>>> >>>>> Strange specifier... It seems like a hashed pointer with added (or >>>>> skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', >>>>> '%p4cc'? >>>>> Ditto for other cases. >>>> >>>> As was pointed out by Sven elsewhere in the thread, this is an >>>> unupstreamed specifier (that was missed as a dependency of this >>>> code). >>>> >>>> https://github.com/AsahiLinux/linux/blob/f8c0d18173a7b649999ee27515393f7aae40310c/Documentation/core-api/printk-formats.rst#generic-fourcc-code >>> >>> I don't see why we need that. The %.4s (0x%08x) is repeating that with >>> the existing codebase. (I do understand why v4l2/drm have it). Ideally >>> the first should use %4pE, but it might not be suitable in some cases. >> >> Just from a superficial understanding of things: %p4ch on little-endian >> will print in a reversed order to %.4s. As I see it the handling of >> endianness is the value proposition of the new specifiers. > > So, what prevents you from adding this to %pE? > The preferred way is not adding a specifier for a single user with a > particular case, esp. when it's covered by the existing ones. Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? If you think that would be accepted... I guess this was added on the assumption that keys like this will be a common occurrence in interaction with Apple firmware. Though greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the SMC code (9 times): ./drivers/power/reset/macsmc-reboot.c ./drivers/platform/apple/smc_core.c ./drivers/gpio/gpio-macsmc.c >> So >> >> %p4ch - interpret as an u32, print the character in most significant byte first > > %.4s + be32_to_cpu() Well, AIUI instead of printk(“%p4ch = ...\n”, &key); you need to do u32 key_be = cpu_to_be32(key); printk(“%.4s = ...\n”, &key_be); in at least 9 places now, the number of which will probably grow. Just to make the case for *some* printk helper. > >> %p4cb - the same as %.4s > >> %p4cl - reversed to %.4s > > %.4s + swab32() Sure, these two are uninteresting, probably added for completeness. > > So? Well, so nothing. I am primarily explaining how that strange specifier came to be. Martin > -- > With Best Regards, > Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 11:12 ` Martin Povišer 0 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-02 11:12 UTC (permalink / raw) To: Andy Shevchenko Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter Pardon, I lost the CC list in my earlier reply. Adding it back now. > On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: >>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: >>>>> On 1. 9. 2022, at 20:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>>>> On Thu, Sep 1, 2022 at 5:17 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: >>>> >>>>>> + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); >>>>>> + if (ret < 0) >>>>>> + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); >>>>> >>>>> Strange specifier... It seems like a hashed pointer with added (or >>>>> skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', >>>>> '%p4cc'? >>>>> Ditto for other cases. >>>> >>>> As was pointed out by Sven elsewhere in the thread, this is an >>>> unupstreamed specifier (that was missed as a dependency of this >>>> code). >>>> >>>> https://github.com/AsahiLinux/linux/blob/f8c0d18173a7b649999ee27515393f7aae40310c/Documentation/core-api/printk-formats.rst#generic-fourcc-code >>> >>> I don't see why we need that. The %.4s (0x%08x) is repeating that with >>> the existing codebase. (I do understand why v4l2/drm have it). Ideally >>> the first should use %4pE, but it might not be suitable in some cases. >> >> Just from a superficial understanding of things: %p4ch on little-endian >> will print in a reversed order to %.4s. As I see it the handling of >> endianness is the value proposition of the new specifiers. > > So, what prevents you from adding this to %pE? > The preferred way is not adding a specifier for a single user with a > particular case, esp. when it's covered by the existing ones. Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? If you think that would be accepted... I guess this was added on the assumption that keys like this will be a common occurrence in interaction with Apple firmware. Though greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the SMC code (9 times): ./drivers/power/reset/macsmc-reboot.c ./drivers/platform/apple/smc_core.c ./drivers/gpio/gpio-macsmc.c >> So >> >> %p4ch - interpret as an u32, print the character in most significant byte first > > %.4s + be32_to_cpu() Well, AIUI instead of printk(“%p4ch = ...\n”, &key); you need to do u32 key_be = cpu_to_be32(key); printk(“%.4s = ...\n”, &key_be); in at least 9 places now, the number of which will probably grow. Just to make the case for *some* printk helper. > >> %p4cb - the same as %.4s > >> %p4cl - reversed to %.4s > > %.4s + swab32() Sure, these two are uninteresting, probably added for completeness. > > So? Well, so nothing. I am primarily explaining how that strange specifier came to be. Martin > -- > With Best Regards, > Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 11:12 ` Martin Povišer @ 2022-09-02 13:33 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 13:33 UTC (permalink / raw) To: Martin Povišer Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: > > On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: > >>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: ... > >>> I don't see why we need that. The %.4s (0x%08x) is repeating that with > >>> the existing codebase. (I do understand why v4l2/drm have it). Ideally > >>> the first should use %4pE, but it might not be suitable in some cases. > >> > >> Just from a superficial understanding of things: %p4ch on little-endian > >> will print in a reversed order to %.4s. As I see it the handling of > >> endianness is the value proposition of the new specifiers. > > > > So, what prevents you from adding this to %pE? > > The preferred way is not adding a specifier for a single user with a > > particular case, esp. when it's covered by the existing ones. > > Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? > If you think that would be accepted... > > I guess this was added on the assumption that keys like this will > be a common occurrence in interaction with Apple firmware. Though > greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the > SMC code (9 times): > > ./drivers/power/reset/macsmc-reboot.c > ./drivers/platform/apple/smc_core.c > ./drivers/gpio/gpio-macsmc.c > >> %p4ch - interpret as an u32, print the character in most significant byte first > > > > %.4s + be32_to_cpu() > > Well, AIUI instead of > > printk(“%p4ch = ...\n”, &key); > > you need to do > > u32 key_be = cpu_to_be32(key); > printk(“%.4s = ...\n”, &key_be); > > in at least 9 places now, the number of which will probably grow. > Just to make the case for *some* printk helper. Wouldn't this be one line printk(“%.4s = ...\n”, &cpu_to_be32(key)); ? So I don't see disadvantages right now. Later on we can consider a new specifier _separately_, otherwise this series would be dragging for no sense. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 13:33 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 13:33 UTC (permalink / raw) To: Martin Povišer Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: > > On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: > >>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: ... > >>> I don't see why we need that. The %.4s (0x%08x) is repeating that with > >>> the existing codebase. (I do understand why v4l2/drm have it). Ideally > >>> the first should use %4pE, but it might not be suitable in some cases. > >> > >> Just from a superficial understanding of things: %p4ch on little-endian > >> will print in a reversed order to %.4s. As I see it the handling of > >> endianness is the value proposition of the new specifiers. > > > > So, what prevents you from adding this to %pE? > > The preferred way is not adding a specifier for a single user with a > > particular case, esp. when it's covered by the existing ones. > > Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? > If you think that would be accepted... > > I guess this was added on the assumption that keys like this will > be a common occurrence in interaction with Apple firmware. Though > greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the > SMC code (9 times): > > ./drivers/power/reset/macsmc-reboot.c > ./drivers/platform/apple/smc_core.c > ./drivers/gpio/gpio-macsmc.c > >> %p4ch - interpret as an u32, print the character in most significant byte first > > > > %.4s + be32_to_cpu() > > Well, AIUI instead of > > printk(“%p4ch = ...\n”, &key); > > you need to do > > u32 key_be = cpu_to_be32(key); > printk(“%.4s = ...\n”, &key_be); > > in at least 9 places now, the number of which will probably grow. > Just to make the case for *some* printk helper. Wouldn't this be one line printk(“%.4s = ...\n”, &cpu_to_be32(key)); ? So I don't see disadvantages right now. Later on we can consider a new specifier _separately_, otherwise this series would be dragging for no sense. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 13:33 ` Andy Shevchenko @ 2022-09-02 13:36 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 13:36 UTC (permalink / raw) To: Martin Povišer Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 4:33 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: ... > > in at least 9 places now, the number of which will probably grow. > > Just to make the case for *some* printk helper. > > Wouldn't this be one line > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > ? > > So I don't see disadvantages right now. Later on we can consider a new > specifier _separately_, otherwise this series would be dragging for no > sense. Just to make my point clear. The single user or small subset of users does not justify the new specifier. New specifier is a lot of burden to printf() code. Find 3+ independent users and we can talk again. That's why I suggest to either create a local (to apple whatever stuff) helper or use existing specifiers in _this_ series. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 13:36 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 13:36 UTC (permalink / raw) To: Martin Povišer Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 4:33 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: ... > > in at least 9 places now, the number of which will probably grow. > > Just to make the case for *some* printk helper. > > Wouldn't this be one line > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > ? > > So I don't see disadvantages right now. Later on we can consider a new > specifier _separately_, otherwise this series would be dragging for no > sense. Just to make my point clear. The single user or small subset of users does not justify the new specifier. New specifier is a lot of burden to printf() code. Find 3+ independent users and we can talk again. That's why I suggest to either create a local (to apple whatever stuff) helper or use existing specifiers in _this_ series. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 13:33 ` Andy Shevchenko @ 2022-09-02 13:37 ` Martin Povišer -1 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-02 13:37 UTC (permalink / raw) To: Andy Shevchenko Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter > On 2. 9. 2022, at 15:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: >>> On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>> On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: >>>>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>>>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: > > ... > >>>>> I don't see why we need that. The %.4s (0x%08x) is repeating that with >>>>> the existing codebase. (I do understand why v4l2/drm have it). Ideally >>>>> the first should use %4pE, but it might not be suitable in some cases. >>>> >>>> Just from a superficial understanding of things: %p4ch on little-endian >>>> will print in a reversed order to %.4s. As I see it the handling of >>>> endianness is the value proposition of the new specifiers. >>> >>> So, what prevents you from adding this to %pE? >>> The preferred way is not adding a specifier for a single user with a >>> particular case, esp. when it's covered by the existing ones. >> >> Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? >> If you think that would be accepted... >> >> I guess this was added on the assumption that keys like this will >> be a common occurrence in interaction with Apple firmware. Though >> greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the >> SMC code (9 times): >> >> ./drivers/power/reset/macsmc-reboot.c >> ./drivers/platform/apple/smc_core.c >> ./drivers/gpio/gpio-macsmc.c > >>>> %p4ch - interpret as an u32, print the character in most significant byte first >>> >>> %.4s + be32_to_cpu() >> >> Well, AIUI instead of >> >> printk(“%p4ch = ...\n”, &key); >> >> you need to do >> >> u32 key_be = cpu_to_be32(key); >> printk(“%.4s = ...\n”, &key_be); >> >> in at least 9 places now, the number of which will probably grow. >> Just to make the case for *some* printk helper. > > Wouldn't this be one line > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > ? That would compile? I thought that’s not valid C, taking an address of function’s return value. > > So I don't see disadvantages right now. Later on we can consider a new > specifier _separately_, otherwise this series would be dragging for no > sense. Absolutely agreed on the latter point. Martin ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 13:37 ` Martin Povišer 0 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-02 13:37 UTC (permalink / raw) To: Andy Shevchenko Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter > On 2. 9. 2022, at 15:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: >>> On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>> On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: >>>>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>>>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: > > ... > >>>>> I don't see why we need that. The %.4s (0x%08x) is repeating that with >>>>> the existing codebase. (I do understand why v4l2/drm have it). Ideally >>>>> the first should use %4pE, but it might not be suitable in some cases. >>>> >>>> Just from a superficial understanding of things: %p4ch on little-endian >>>> will print in a reversed order to %.4s. As I see it the handling of >>>> endianness is the value proposition of the new specifiers. >>> >>> So, what prevents you from adding this to %pE? >>> The preferred way is not adding a specifier for a single user with a >>> particular case, esp. when it's covered by the existing ones. >> >> Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? >> If you think that would be accepted... >> >> I guess this was added on the assumption that keys like this will >> be a common occurrence in interaction with Apple firmware. Though >> greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the >> SMC code (9 times): >> >> ./drivers/power/reset/macsmc-reboot.c >> ./drivers/platform/apple/smc_core.c >> ./drivers/gpio/gpio-macsmc.c > >>>> %p4ch - interpret as an u32, print the character in most significant byte first >>> >>> %.4s + be32_to_cpu() >> >> Well, AIUI instead of >> >> printk(“%p4ch = ...\n”, &key); >> >> you need to do >> >> u32 key_be = cpu_to_be32(key); >> printk(“%.4s = ...\n”, &key_be); >> >> in at least 9 places now, the number of which will probably grow. >> Just to make the case for *some* printk helper. > > Wouldn't this be one line > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > ? That would compile? I thought that’s not valid C, taking an address of function’s return value. > > So I don't see disadvantages right now. Later on we can consider a new > specifier _separately_, otherwise this series would be dragging for no > sense. Absolutely agreed on the latter point. Martin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 13:37 ` Martin Povišer @ 2022-09-02 14:41 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 14:41 UTC (permalink / raw) To: Martin Povišer Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 4:37 PM Martin Povišer <povik@cutebit.org> wrote: > > On 2. 9. 2022, at 15:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: ... > >> you need to do > >> > >> u32 key_be = cpu_to_be32(key); > >> printk(“%.4s = ...\n”, &key_be); > >> > >> in at least 9 places now, the number of which will probably grow. > >> Just to make the case for *some* printk helper. > > > > Wouldn't this be one line > > > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > > > ? > > That would compile? I thought that’s not valid C, taking an > address of function’s return value. Ah, you are right. My bad. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 14:41 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 14:41 UTC (permalink / raw) To: Martin Povišer Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 4:37 PM Martin Povišer <povik@cutebit.org> wrote: > > On 2. 9. 2022, at 15:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: ... > >> you need to do > >> > >> u32 key_be = cpu_to_be32(key); > >> printk(“%.4s = ...\n”, &key_be); > >> > >> in at least 9 places now, the number of which will probably grow. > >> Just to make the case for *some* printk helper. > > > > Wouldn't this be one line > > > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > > > ? > > That would compile? I thought that’s not valid C, taking an > address of function’s return value. Ah, you are right. My bad. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 13:37 ` Martin Povišer @ 2022-09-02 14:45 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 14:45 UTC (permalink / raw) To: Martin Povišer, Andy Shevchenko Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 03:37:27PM +0200, Martin Povišer wrote: > > > On 2. 9. 2022, at 15:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: > >>> On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>> On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: > >>>>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>>>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: > > > > ... > > > >>>>> I don't see why we need that. The %.4s (0x%08x) is repeating that with > >>>>> the existing codebase. (I do understand why v4l2/drm have it). Ideally > >>>>> the first should use %4pE, but it might not be suitable in some cases. > >>>> > >>>> Just from a superficial understanding of things: %p4ch on little-endian > >>>> will print in a reversed order to %.4s. As I see it the handling of > >>>> endianness is the value proposition of the new specifiers. > >>> > >>> So, what prevents you from adding this to %pE? > >>> The preferred way is not adding a specifier for a single user with a > >>> particular case, esp. when it's covered by the existing ones. > >> > >> Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? > >> If you think that would be accepted... > >> > >> I guess this was added on the assumption that keys like this will > >> be a common occurrence in interaction with Apple firmware. Though > >> greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the > >> SMC code (9 times): > >> > >> ./drivers/power/reset/macsmc-reboot.c > >> ./drivers/platform/apple/smc_core.c > >> ./drivers/gpio/gpio-macsmc.c > > > >>>> %p4ch - interpret as an u32, print the character in most significant byte first > >>> > >>> %.4s + be32_to_cpu() > >> > >> Well, AIUI instead of > >> > >> printk(“%p4ch = ...\n”, &key); > >> > >> you need to do > >> > >> u32 key_be = cpu_to_be32(key); > >> printk(“%.4s = ...\n”, &key_be); > >> > >> in at least 9 places now, the number of which will probably grow. > >> Just to make the case for *some* printk helper. > > > > Wouldn't this be one line > > > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > > > ? > > That would compile? I thought that’s not valid C, taking an > address of function’s return value. It isn't legal C. int foo(int bar); int blah(int *v); int test(int v) { return blah(&foo(v)); } t.c: In function ‘test’: t.c:7:14: error: lvalue required as unary ‘&’ operand And just to make sure that it's not just my test that is wrong, and there's something magical about cpu_to_be32()... In file included from include/linux/device.h:15, from drivers/gpio/gpio-macsmc.c:11: drivers/gpio/gpio-macsmc.c: In function 'macsmc_gpio_probe': drivers/gpio/gpio-macsmc.c:356:49: error: lvalue required as unary '&' operand 356 | dev_info(smcgp->dev, "First GPIO key: %.4s\n", &cpu_to_be32(key)); | ^ include/linux/dev_printk.h:110:23: note: in definition of macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ drivers/gpio/gpio-macsmc.c:356:2: note: in expansion of macro 'dev_info' 356 | dev_info(smcgp->dev, "First GPIO key: %.4s\n", &cpu_to_be32(key)); | ^~~~~~~~ make[3]: *** [scripts/Makefile.build:249: drivers/gpio/gpio-macsmc.o] Error 1 make[2]: *** [scripts/Makefile.build:466: drivers/gpio] Error 2 make[1]: *** [Makefile:1843: drivers] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:219: __sub-make] Error 2 So, sorry Andy, but this suggestion does not appear to be legal C. This also applies to your suggestion in the other sub-thread of: ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); As we've now discovered that this is not legal C, can we back up *both* discussions and start again on these points. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 14:45 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 14:45 UTC (permalink / raw) To: Martin Povišer, Andy Shevchenko Cc: Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 03:37:27PM +0200, Martin Povišer wrote: > > > On 2. 9. 2022, at 15:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > On Fri, Sep 2, 2022 at 2:12 PM Martin Povišer <povik@cutebit.org> wrote: > >>> On 2. 9. 2022, at 12:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>> On Fri, Sep 2, 2022 at 12:47 PM Martin Povišer <povik@cutebit.org> wrote: > >>>>> On 2. 9. 2022, at 8:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>>>> On Fri, Sep 2, 2022 at 12:52 AM Martin Povišer <povik@cutebit.org> wrote: > > > > ... > > > >>>>> I don't see why we need that. The %.4s (0x%08x) is repeating that with > >>>>> the existing codebase. (I do understand why v4l2/drm have it). Ideally > >>>>> the first should use %4pE, but it might not be suitable in some cases. > >>>> > >>>> Just from a superficial understanding of things: %p4ch on little-endian > >>>> will print in a reversed order to %.4s. As I see it the handling of > >>>> endianness is the value proposition of the new specifiers. > >>> > >>> So, what prevents you from adding this to %pE? > >>> The preferred way is not adding a specifier for a single user with a > >>> particular case, esp. when it's covered by the existing ones. > >> > >> Adding the endianness conversion into %pE as, ehm, an ‘escaping flag’? > >> If you think that would be accepted... > >> > >> I guess this was added on the assumption that keys like this will > >> be a common occurrence in interaction with Apple firmware. Though > >> greping the ‘asahi’ staging tree for ‘%p4ch’ I only see it in the > >> SMC code (9 times): > >> > >> ./drivers/power/reset/macsmc-reboot.c > >> ./drivers/platform/apple/smc_core.c > >> ./drivers/gpio/gpio-macsmc.c > > > >>>> %p4ch - interpret as an u32, print the character in most significant byte first > >>> > >>> %.4s + be32_to_cpu() > >> > >> Well, AIUI instead of > >> > >> printk(“%p4ch = ...\n”, &key); > >> > >> you need to do > >> > >> u32 key_be = cpu_to_be32(key); > >> printk(“%.4s = ...\n”, &key_be); > >> > >> in at least 9 places now, the number of which will probably grow. > >> Just to make the case for *some* printk helper. > > > > Wouldn't this be one line > > > > printk(“%.4s = ...\n”, &cpu_to_be32(key)); > > > > ? > > That would compile? I thought that’s not valid C, taking an > address of function’s return value. It isn't legal C. int foo(int bar); int blah(int *v); int test(int v) { return blah(&foo(v)); } t.c: In function ‘test’: t.c:7:14: error: lvalue required as unary ‘&’ operand And just to make sure that it's not just my test that is wrong, and there's something magical about cpu_to_be32()... In file included from include/linux/device.h:15, from drivers/gpio/gpio-macsmc.c:11: drivers/gpio/gpio-macsmc.c: In function 'macsmc_gpio_probe': drivers/gpio/gpio-macsmc.c:356:49: error: lvalue required as unary '&' operand 356 | dev_info(smcgp->dev, "First GPIO key: %.4s\n", &cpu_to_be32(key)); | ^ include/linux/dev_printk.h:110:23: note: in definition of macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ drivers/gpio/gpio-macsmc.c:356:2: note: in expansion of macro 'dev_info' 356 | dev_info(smcgp->dev, "First GPIO key: %.4s\n", &cpu_to_be32(key)); | ^~~~~~~~ make[3]: *** [scripts/Makefile.build:249: drivers/gpio/gpio-macsmc.o] Error 1 make[2]: *** [scripts/Makefile.build:466: drivers/gpio] Error 2 make[1]: *** [Makefile:1843: drivers] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:219: __sub-make] Error 2 So, sorry Andy, but this suggestion does not appear to be legal C. This also applies to your suggestion in the other sub-thread of: ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); As we've now discovered that this is not legal C, can we back up *both* discussions and start again on these points. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 18:55 ` Andy Shevchenko @ 2022-09-02 10:05 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 10:05 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > +static int macsmc_gpio_nr(smc_key key) > > +{ > > + int low = hex_to_bin(key & 0xff); > > + int high = hex_to_bin((key >> 8) & 0xff); > > + > > + if (low < 0 || high < 0) > > + return -1; > > + > > + return low | (high << 4); > > +} > > NIH hex2bin(). Is using hex2bin really better? static int macsmc_gpio_nr(smc_key key) { char k[2]; u8 result; int ret; k[0] = key; k[1] = key >> 8; ret = hex2bin(&result, k, 2); if (ret < 0) return ret; return result; } This looks to me like it consumes more CPU cycles - because we have to write each "character" to the stack, then call a function, only to then call the hex_to_bin() function. One can't just pass "key" into hex2bin because that will bring with it endian issues. > > +static int macsmc_gpio_key(unsigned int offset) > > +{ > > + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); > > +} > > NIH hex_byte_pack(). This would become: char buf[2]; hex_byte_pack(buf, offset); return _SMC_KEY("gP\0\0") | buf[0] << 8 | buf[1]; to avoid the endian issues. It just seems to be a more complex way to do the conversion. One could then argue that this is just a NIH sprintf(), so it could then be written: char buf[5]; snprintf(buf, sizeof(buf), "gP%02x", offset); return _SMC_KEY(buf); which looks nicer, but involves a lot more code. Since this is called for every GPIO operation, and you were worred above about the layout of the macsmc_gpio structure (which is a micro- optimisation), it seems weird to be concerned about the efficiency of the structure layout and then suggest less efficient code in each of the functional paths of the driver. There seems to be a contradiction. > > + /* First try reading the explicit pin mode register */ > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > > + if (!ret) > > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > > + > > + /* > > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > > + * Fall back to reading IRQ mode, which will only succeed for inputs. > > + */ > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > What is the meaning of val in this case? Reading the comment, it seems that "val" is irrelevant. I'm not sure that needs explaining given there's a comment that's already explaining what is going on here. > > + if (ret == GPIO_LINE_DIRECTION_OUT) > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); > > + else > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); > > > + > > Unnecessary blank line. I think that's personal style preference, it isn't mentioned in the coding style. However, the following is much nicer and likely produces better code: if (ret == GPIO_LINE_DIRECTION_OUT) cmd = CMD_OUTPUT; else cmd = CMD_INPUT; ret = apple_smc_rw_u32(smcgp->smc, key, cmd, &val); if (ret < 0) return ret; > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; > > I would split this assignment and move it closer to the first user. > > > + int i; > > + > > + if (count > MAX_GPIO) > > + count = MAX_GPIO; > > Hmm... When can it be the case? That's a question for the Asahi folk - it's not obvious whether it could or could not be from the code. I think it depends on firmware. > > + bitmap_zero(valid_mask, ngpios); > > + > > + for (i = 0; i < count; i++) { > > + smc_key key; > > + int gpio_nr; > > > + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > Ditto. What does "ditto" here mean, because I don't think you mean "Hmm... When can it be the case?" and "I would split this assignment and move it closer to the first user." doesn't seem to be relevant either. > > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > Can we use fwnode APIs instead? > Or do you really need this? Ouch, that's not nice. I can change this to: fwnode = device_get_named_child_node(pdev->dev.parent, "gpio"); device_set_node(&pdev->dev, fwnode); but even that isn't _that_ nice. I'd like to hear comments from the Asahi folk about whether these sub-blocks of the SMC can have compatibles, so that the MFD layer can automatically fill in the firmware nodes on the struct device before the probe function gets called. If not, then I think it would be reasonable to have a discussion with Lee about extending MFD to be able to have mfd cells name a child, so that MFD can do the above instead of having it littered amongst drivers. Thanks for the review. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 10:05 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 10:05 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > +static int macsmc_gpio_nr(smc_key key) > > +{ > > + int low = hex_to_bin(key & 0xff); > > + int high = hex_to_bin((key >> 8) & 0xff); > > + > > + if (low < 0 || high < 0) > > + return -1; > > + > > + return low | (high << 4); > > +} > > NIH hex2bin(). Is using hex2bin really better? static int macsmc_gpio_nr(smc_key key) { char k[2]; u8 result; int ret; k[0] = key; k[1] = key >> 8; ret = hex2bin(&result, k, 2); if (ret < 0) return ret; return result; } This looks to me like it consumes more CPU cycles - because we have to write each "character" to the stack, then call a function, only to then call the hex_to_bin() function. One can't just pass "key" into hex2bin because that will bring with it endian issues. > > +static int macsmc_gpio_key(unsigned int offset) > > +{ > > + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); > > +} > > NIH hex_byte_pack(). This would become: char buf[2]; hex_byte_pack(buf, offset); return _SMC_KEY("gP\0\0") | buf[0] << 8 | buf[1]; to avoid the endian issues. It just seems to be a more complex way to do the conversion. One could then argue that this is just a NIH sprintf(), so it could then be written: char buf[5]; snprintf(buf, sizeof(buf), "gP%02x", offset); return _SMC_KEY(buf); which looks nicer, but involves a lot more code. Since this is called for every GPIO operation, and you were worred above about the layout of the macsmc_gpio structure (which is a micro- optimisation), it seems weird to be concerned about the efficiency of the structure layout and then suggest less efficient code in each of the functional paths of the driver. There seems to be a contradiction. > > + /* First try reading the explicit pin mode register */ > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > > + if (!ret) > > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > > + > > + /* > > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > > + * Fall back to reading IRQ mode, which will only succeed for inputs. > > + */ > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > What is the meaning of val in this case? Reading the comment, it seems that "val" is irrelevant. I'm not sure that needs explaining given there's a comment that's already explaining what is going on here. > > + if (ret == GPIO_LINE_DIRECTION_OUT) > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); > > + else > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); > > > + > > Unnecessary blank line. I think that's personal style preference, it isn't mentioned in the coding style. However, the following is much nicer and likely produces better code: if (ret == GPIO_LINE_DIRECTION_OUT) cmd = CMD_OUTPUT; else cmd = CMD_INPUT; ret = apple_smc_rw_u32(smcgp->smc, key, cmd, &val); if (ret < 0) return ret; > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; > > I would split this assignment and move it closer to the first user. > > > + int i; > > + > > + if (count > MAX_GPIO) > > + count = MAX_GPIO; > > Hmm... When can it be the case? That's a question for the Asahi folk - it's not obvious whether it could or could not be from the code. I think it depends on firmware. > > + bitmap_zero(valid_mask, ngpios); > > + > > + for (i = 0; i < count; i++) { > > + smc_key key; > > + int gpio_nr; > > > + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > Ditto. What does "ditto" here mean, because I don't think you mean "Hmm... When can it be the case?" and "I would split this assignment and move it closer to the first user." doesn't seem to be relevant either. > > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > Can we use fwnode APIs instead? > Or do you really need this? Ouch, that's not nice. I can change this to: fwnode = device_get_named_child_node(pdev->dev.parent, "gpio"); device_set_node(&pdev->dev, fwnode); but even that isn't _that_ nice. I'd like to hear comments from the Asahi folk about whether these sub-blocks of the SMC can have compatibles, so that the MFD layer can automatically fill in the firmware nodes on the struct device before the probe function gets called. If not, then I think it would be reasonable to have a discussion with Lee about extending MFD to be able to have mfd cells name a child, so that MFD can do the above instead of having it littered amongst drivers. Thanks for the review. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 10:05 ` Russell King (Oracle) @ 2022-09-02 10:37 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 10:37 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: ... > > > +static int macsmc_gpio_nr(smc_key key) > > > +{ > > > + int low = hex_to_bin(key & 0xff); > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > + > > > + if (low < 0 || high < 0) > > > + return -1; > > > + > > > + return low | (high << 4); > > > +} > > > > NIH hex2bin(). > > Is using hex2bin really better? Yes. > static int macsmc_gpio_nr(smc_key key) > { > char k[2]; > u8 result; > int ret; > > k[0] = key; > k[1] = key >> 8; > > ret = hex2bin(&result, k, 2); > if (ret < 0) > return ret; > > return result; > } > > This looks to me like it consumes more CPU cycles - because we have to > write each "character" to the stack, then call a function, only to then > call the hex_to_bin() function. One can't just pass "key" into hex2bin > because that will bring with it endian issues. With one detail missed, why do you need all that if you can use byteorder helpers()? What's the stack? Just replace this entire function with the respectful calls to hex2bin(). ... > > > +static int macsmc_gpio_key(unsigned int offset) > > > +{ > > > + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); > > > +} > > > > NIH hex_byte_pack(). > > This would become: > > char buf[2]; > > hex_byte_pack(buf, offset); > > return _SMC_KEY("gP\0\0") | buf[0] << 8 | buf[1]; You have a point here. > to avoid the endian issues. It just seems to be a more complex way to > do the conversion. One could then argue that this is just a NIH > sprintf(), so it could then be written: No, no. snprintf() is too much here. > which looks nicer, but involves a lot more code. > > Since this is called for every GPIO operation, and you were worred above > about the layout of the macsmc_gpio structure (which is a micro- > optimisation), it seems weird to be concerned about the efficiency of > the structure layout and then suggest less efficient code in each of the > functional paths of the driver. There seems to be a contradiction. ... > > > + /* First try reading the explicit pin mode register */ > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > > > + if (!ret) > > > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > > > + > > > + /* > > > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > > > + * Fall back to reading IRQ mode, which will only succeed for inputs. > > > + */ > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > > > What is the meaning of val in this case? > > Reading the comment, it seems that "val" is irrelevant. I'm not sure that > needs explaining given there's a comment that's already explaining what > is going on here. OK. Just convert then (!ret) --> ret. ... > > > + if (ret == GPIO_LINE_DIRECTION_OUT) > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); > > > + else > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); > > > > > + > > > > Unnecessary blank line. > > I think that's personal style preference, it isn't mentioned in the coding > style. However, the following is much nicer and likely produces better > code: > > if (ret == GPIO_LINE_DIRECTION_OUT) > cmd = CMD_OUTPUT; > else > cmd = CMD_INPUT; > > ret = apple_smc_rw_u32(smcgp->smc, key, cmd, &val); > if (ret < 0) > return ret; Go for it! ... > > > + if (count > MAX_GPIO) > > > + count = MAX_GPIO; > > > > Hmm... When can it be the case? > > That's a question for the Asahi folk - it's not obvious whether it could > or could not be from the code. I think it depends on firmware. If it's the case, why does the code not support higher GPIOs? Needs at least a comment. ... > > > + bitmap_zero(valid_mask, ngpios); > > > + > > > + for (i = 0; i < count; i++) { > > > + smc_key key; > > > + int gpio_nr; > > > > > + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > > > Ditto. > > What does "ditto" here mean, because I don't think you mean "Hmm... > When can it be the case?" and "I would split this assignment and move > it closer to the first user." doesn't seem to be relevant either. Split int ret = foo(); to int ret; ret = foo(); ... > > > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > > > Can we use fwnode APIs instead? > > Or do you really need this? > > Ouch, that's not nice. I can change this to: (Some background on why my eye caught this. We as GPIO SIG in the kernel want to move the library to be fwnode one without looking into the underneath property provider. This kind of lines makes driver look a bit ugly from that perspective) > fwnode = device_get_named_child_node(pdev->dev.parent, "gpio"); > device_set_node(&pdev->dev, fwnode); > > but even that isn't _that_ nice. I'd like to hear comments from the Asahi > folk about whether these sub-blocks of the SMC can have compatibles, so > that the MFD layer can automatically fill in the firmware nodes on the > struct device before the probe function gets called. > If not, then I think it would be reasonable to have a discussion with > Lee about extending MFD to be able to have mfd cells name a child, so > that MFD can do the above instead of having it littered amongst drivers. MFD cells can be matched by compatible strings. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 10:37 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 10:37 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: ... > > > +static int macsmc_gpio_nr(smc_key key) > > > +{ > > > + int low = hex_to_bin(key & 0xff); > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > + > > > + if (low < 0 || high < 0) > > > + return -1; > > > + > > > + return low | (high << 4); > > > +} > > > > NIH hex2bin(). > > Is using hex2bin really better? Yes. > static int macsmc_gpio_nr(smc_key key) > { > char k[2]; > u8 result; > int ret; > > k[0] = key; > k[1] = key >> 8; > > ret = hex2bin(&result, k, 2); > if (ret < 0) > return ret; > > return result; > } > > This looks to me like it consumes more CPU cycles - because we have to > write each "character" to the stack, then call a function, only to then > call the hex_to_bin() function. One can't just pass "key" into hex2bin > because that will bring with it endian issues. With one detail missed, why do you need all that if you can use byteorder helpers()? What's the stack? Just replace this entire function with the respectful calls to hex2bin(). ... > > > +static int macsmc_gpio_key(unsigned int offset) > > > +{ > > > + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); > > > +} > > > > NIH hex_byte_pack(). > > This would become: > > char buf[2]; > > hex_byte_pack(buf, offset); > > return _SMC_KEY("gP\0\0") | buf[0] << 8 | buf[1]; You have a point here. > to avoid the endian issues. It just seems to be a more complex way to > do the conversion. One could then argue that this is just a NIH > sprintf(), so it could then be written: No, no. snprintf() is too much here. > which looks nicer, but involves a lot more code. > > Since this is called for every GPIO operation, and you were worred above > about the layout of the macsmc_gpio structure (which is a micro- > optimisation), it seems weird to be concerned about the efficiency of > the structure layout and then suggest less efficient code in each of the > functional paths of the driver. There seems to be a contradiction. ... > > > + /* First try reading the explicit pin mode register */ > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > > > + if (!ret) > > > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > > > + > > > + /* > > > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > > > + * Fall back to reading IRQ mode, which will only succeed for inputs. > > > + */ > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > > > What is the meaning of val in this case? > > Reading the comment, it seems that "val" is irrelevant. I'm not sure that > needs explaining given there's a comment that's already explaining what > is going on here. OK. Just convert then (!ret) --> ret. ... > > > + if (ret == GPIO_LINE_DIRECTION_OUT) > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_OUTPUT, &val); > > > + else > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_INPUT, &val); > > > > > + > > > > Unnecessary blank line. > > I think that's personal style preference, it isn't mentioned in the coding > style. However, the following is much nicer and likely produces better > code: > > if (ret == GPIO_LINE_DIRECTION_OUT) > cmd = CMD_OUTPUT; > else > cmd = CMD_INPUT; > > ret = apple_smc_rw_u32(smcgp->smc, key, cmd, &val); > if (ret < 0) > return ret; Go for it! ... > > > + if (count > MAX_GPIO) > > > + count = MAX_GPIO; > > > > Hmm... When can it be the case? > > That's a question for the Asahi folk - it's not obvious whether it could > or could not be from the code. I think it depends on firmware. If it's the case, why does the code not support higher GPIOs? Needs at least a comment. ... > > > + bitmap_zero(valid_mask, ngpios); > > > + > > > + for (i = 0; i < count; i++) { > > > + smc_key key; > > > + int gpio_nr; > > > > > + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > > > Ditto. > > What does "ditto" here mean, because I don't think you mean "Hmm... > When can it be the case?" and "I would split this assignment and move > it closer to the first user." doesn't seem to be relevant either. Split int ret = foo(); to int ret; ret = foo(); ... > > > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > > > Can we use fwnode APIs instead? > > Or do you really need this? > > Ouch, that's not nice. I can change this to: (Some background on why my eye caught this. We as GPIO SIG in the kernel want to move the library to be fwnode one without looking into the underneath property provider. This kind of lines makes driver look a bit ugly from that perspective) > fwnode = device_get_named_child_node(pdev->dev.parent, "gpio"); > device_set_node(&pdev->dev, fwnode); > > but even that isn't _that_ nice. I'd like to hear comments from the Asahi > folk about whether these sub-blocks of the SMC can have compatibles, so > that the MFD layer can automatically fill in the firmware nodes on the > struct device before the probe function gets called. > If not, then I think it would be reasonable to have a discussion with > Lee about extending MFD to be able to have mfd cells name a child, so > that MFD can do the above instead of having it littered amongst drivers. MFD cells can be matched by compatible strings. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 10:37 ` Andy Shevchenko @ 2022-09-02 11:32 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 11:32 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > +static int macsmc_gpio_nr(smc_key key) > > > > +{ > > > > + int low = hex_to_bin(key & 0xff); > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > + > > > > + if (low < 0 || high < 0) > > > > + return -1; > > > > + > > > > + return low | (high << 4); > > > > +} > > > > > > NIH hex2bin(). > > > > Is using hex2bin really better? > > Yes. > > > static int macsmc_gpio_nr(smc_key key) > > { > > char k[2]; > > u8 result; > > int ret; > > > > k[0] = key; > > k[1] = key >> 8; > > > > ret = hex2bin(&result, k, 2); > > if (ret < 0) > > return ret; > > > > return result; > > } > > > > This looks to me like it consumes more CPU cycles - because we have to > > write each "character" to the stack, then call a function, only to then > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > because that will bring with it endian issues. > > With one detail missed, why do you need all that if you can use > byteorder helpers()? What's the stack? Just replace this entire > function with the respectful calls to hex2bin(). Sorry, I don't understand what you're suggesting, because it doesn't make sense to me. The byteorder helpers do not give a char array, which is what hex2bin() wants, so we end up with something like: __le16 foo = cpu_to_le16(key); u8 result; ret = hex2bin(&result, (char *)&foo, 1); if (ret < 0) return ret; return result; This to me looks like yucky code, It still results in "foo" having to be on the stack, because the out-of-line hex2bin() requires a pointer to be passed as the second argument. Maybe you could provide an example of what you're thinking of, because I'm at a loss to understand what you're thinking this should look like. > > > > + /* First try reading the explicit pin mode register */ > > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > > > > + if (!ret) > > > > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > > > > + > > > > + /* > > > > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > > > > + * Fall back to reading IRQ mode, which will only succeed for inputs. > > > > + */ > > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > > > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > > > > > What is the meaning of val in this case? > > > > Reading the comment, it seems that "val" is irrelevant. I'm not sure that > > needs explaining given there's a comment that's already explaining what > > is going on here. > > OK. > Just convert then (!ret) --> ret. Already done, thanks. > > > > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > > > > > Can we use fwnode APIs instead? > > > Or do you really need this? > > > > Ouch, that's not nice. I can change this to: > > (Some background on why my eye caught this. We as GPIO SIG in the > kernel want to move the library to be fwnode one without looking into > the underneath property provider. This kind of lines makes driver look > a bit ugly from that perspective) I agree, I'd prefer it not to be there. > > fwnode = device_get_named_child_node(pdev->dev.parent, "gpio"); > > device_set_node(&pdev->dev, fwnode); > > > > but even that isn't _that_ nice. I'd like to hear comments from the Asahi > > folk about whether these sub-blocks of the SMC can have compatibles, so > > that the MFD layer can automatically fill in the firmware nodes on the > > struct device before the probe function gets called. > > > If not, then I think it would be reasonable to have a discussion with > > Lee about extending MFD to be able to have mfd cells name a child, so > > that MFD can do the above instead of having it littered amongst drivers. > > MFD cells can be matched by compatible strings. Yes, that's what I meant in my preceeding paragraph above, but it needs involvement and decisions from the Asahi maintainers. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 11:32 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 11:32 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > +static int macsmc_gpio_nr(smc_key key) > > > > +{ > > > > + int low = hex_to_bin(key & 0xff); > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > + > > > > + if (low < 0 || high < 0) > > > > + return -1; > > > > + > > > > + return low | (high << 4); > > > > +} > > > > > > NIH hex2bin(). > > > > Is using hex2bin really better? > > Yes. > > > static int macsmc_gpio_nr(smc_key key) > > { > > char k[2]; > > u8 result; > > int ret; > > > > k[0] = key; > > k[1] = key >> 8; > > > > ret = hex2bin(&result, k, 2); > > if (ret < 0) > > return ret; > > > > return result; > > } > > > > This looks to me like it consumes more CPU cycles - because we have to > > write each "character" to the stack, then call a function, only to then > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > because that will bring with it endian issues. > > With one detail missed, why do you need all that if you can use > byteorder helpers()? What's the stack? Just replace this entire > function with the respectful calls to hex2bin(). Sorry, I don't understand what you're suggesting, because it doesn't make sense to me. The byteorder helpers do not give a char array, which is what hex2bin() wants, so we end up with something like: __le16 foo = cpu_to_le16(key); u8 result; ret = hex2bin(&result, (char *)&foo, 1); if (ret < 0) return ret; return result; This to me looks like yucky code, It still results in "foo" having to be on the stack, because the out-of-line hex2bin() requires a pointer to be passed as the second argument. Maybe you could provide an example of what you're thinking of, because I'm at a loss to understand what you're thinking this should look like. > > > > + /* First try reading the explicit pin mode register */ > > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); > > > > + if (!ret) > > > > + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; > > > > + > > > > + /* > > > > + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. > > > > + * Fall back to reading IRQ mode, which will only succeed for inputs. > > > > + */ > > > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > > > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > > > > > What is the meaning of val in this case? > > > > Reading the comment, it seems that "val" is irrelevant. I'm not sure that > > needs explaining given there's a comment that's already explaining what > > is going on here. > > OK. > Just convert then (!ret) --> ret. Already done, thanks. > > > > + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > > > > > Can we use fwnode APIs instead? > > > Or do you really need this? > > > > Ouch, that's not nice. I can change this to: > > (Some background on why my eye caught this. We as GPIO SIG in the > kernel want to move the library to be fwnode one without looking into > the underneath property provider. This kind of lines makes driver look > a bit ugly from that perspective) I agree, I'd prefer it not to be there. > > fwnode = device_get_named_child_node(pdev->dev.parent, "gpio"); > > device_set_node(&pdev->dev, fwnode); > > > > but even that isn't _that_ nice. I'd like to hear comments from the Asahi > > folk about whether these sub-blocks of the SMC can have compatibles, so > > that the MFD layer can automatically fill in the firmware nodes on the > > struct device before the probe function gets called. > > > If not, then I think it would be reasonable to have a discussion with > > Lee about extending MFD to be able to have mfd cells name a child, so > > that MFD can do the above instead of having it littered amongst drivers. > > MFD cells can be matched by compatible strings. Yes, that's what I meant in my preceeding paragraph above, but it needs involvement and decisions from the Asahi maintainers. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 11:32 ` Russell King (Oracle) @ 2022-09-02 13:39 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 13:39 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > +{ > > > > > + int low = hex_to_bin(key & 0xff); > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > + > > > > > + if (low < 0 || high < 0) > > > > > + return -1; > > > > > + > > > > > + return low | (high << 4); > > > > > +} > > > > > > > > NIH hex2bin(). > > > > > > Is using hex2bin really better? > > > > Yes. > > > > > static int macsmc_gpio_nr(smc_key key) > > > { > > > char k[2]; > > > u8 result; > > > int ret; > > > > > > k[0] = key; > > > k[1] = key >> 8; > > > > > > ret = hex2bin(&result, k, 2); > > > if (ret < 0) > > > return ret; > > > > > > return result; > > > } > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > write each "character" to the stack, then call a function, only to then > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > because that will bring with it endian issues. > > > > With one detail missed, why do you need all that if you can use > > byteorder helpers()? What's the stack? Just replace this entire > > function with the respectful calls to hex2bin(). > > Sorry, I don't understand what you're suggesting, because it doesn't > make sense to me. The byteorder helpers do not give a char array, which > is what hex2bin() wants, so we end up with something like: > > __le16 foo = cpu_to_le16(key); > u8 result; > > ret = hex2bin(&result, (char *)&foo, 1); > if (ret < 0) > return ret; > > return result; > > This to me looks like yucky code, It still results in "foo" having to > be on the stack, because the out-of-line hex2bin() requires a pointer > to be passed as the second argument. > > Maybe you could provide an example of what you're thinking of, because > I'm at a loss to understand what you're thinking this should look like. So, let's look into the real callers to see, oh wait, it's a single caller! Why can't you simply do ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); if (ret < 0) return ret; in-place there? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 13:39 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 13:39 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > +{ > > > > > + int low = hex_to_bin(key & 0xff); > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > + > > > > > + if (low < 0 || high < 0) > > > > > + return -1; > > > > > + > > > > > + return low | (high << 4); > > > > > +} > > > > > > > > NIH hex2bin(). > > > > > > Is using hex2bin really better? > > > > Yes. > > > > > static int macsmc_gpio_nr(smc_key key) > > > { > > > char k[2]; > > > u8 result; > > > int ret; > > > > > > k[0] = key; > > > k[1] = key >> 8; > > > > > > ret = hex2bin(&result, k, 2); > > > if (ret < 0) > > > return ret; > > > > > > return result; > > > } > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > write each "character" to the stack, then call a function, only to then > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > because that will bring with it endian issues. > > > > With one detail missed, why do you need all that if you can use > > byteorder helpers()? What's the stack? Just replace this entire > > function with the respectful calls to hex2bin(). > > Sorry, I don't understand what you're suggesting, because it doesn't > make sense to me. The byteorder helpers do not give a char array, which > is what hex2bin() wants, so we end up with something like: > > __le16 foo = cpu_to_le16(key); > u8 result; > > ret = hex2bin(&result, (char *)&foo, 1); > if (ret < 0) > return ret; > > return result; > > This to me looks like yucky code, It still results in "foo" having to > be on the stack, because the out-of-line hex2bin() requires a pointer > to be passed as the second argument. > > Maybe you could provide an example of what you're thinking of, because > I'm at a loss to understand what you're thinking this should look like. So, let's look into the real callers to see, oh wait, it's a single caller! Why can't you simply do ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); if (ret < 0) return ret; in-place there? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 13:39 ` Andy Shevchenko @ 2022-09-02 14:46 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 14:46 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > +{ > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > + > > > > > > + if (low < 0 || high < 0) > > > > > > + return -1; > > > > > > + > > > > > > + return low | (high << 4); > > > > > > +} > > > > > > > > > > NIH hex2bin(). > > > > > > > > Is using hex2bin really better? > > > > > > Yes. > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > { > > > > char k[2]; > > > > u8 result; > > > > int ret; > > > > > > > > k[0] = key; > > > > k[1] = key >> 8; > > > > > > > > ret = hex2bin(&result, k, 2); > > > > if (ret < 0) > > > > return ret; > > > > > > > > return result; > > > > } > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > write each "character" to the stack, then call a function, only to then > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > because that will bring with it endian issues. > > > > > > With one detail missed, why do you need all that if you can use > > > byteorder helpers()? What's the stack? Just replace this entire > > > function with the respectful calls to hex2bin(). > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > make sense to me. The byteorder helpers do not give a char array, which > > is what hex2bin() wants, so we end up with something like: > > > > __le16 foo = cpu_to_le16(key); > > u8 result; > > > > ret = hex2bin(&result, (char *)&foo, 1); > > if (ret < 0) > > return ret; > > > > return result; > > > > This to me looks like yucky code, It still results in "foo" having to > > be on the stack, because the out-of-line hex2bin() requires a pointer > > to be passed as the second argument. > > > > Maybe you could provide an example of what you're thinking of, because > > I'm at a loss to understand what you're thinking this should look like. > > So, let's look into the real callers to see, oh wait, it's a single caller! > Why can't you simply do > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > if (ret < 0) > return ret; > > in-place there? This is not legal C. Please can we back up this discussion, and start over with legal C suggestions. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 14:46 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 14:46 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > +{ > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > + > > > > > > + if (low < 0 || high < 0) > > > > > > + return -1; > > > > > > + > > > > > > + return low | (high << 4); > > > > > > +} > > > > > > > > > > NIH hex2bin(). > > > > > > > > Is using hex2bin really better? > > > > > > Yes. > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > { > > > > char k[2]; > > > > u8 result; > > > > int ret; > > > > > > > > k[0] = key; > > > > k[1] = key >> 8; > > > > > > > > ret = hex2bin(&result, k, 2); > > > > if (ret < 0) > > > > return ret; > > > > > > > > return result; > > > > } > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > write each "character" to the stack, then call a function, only to then > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > because that will bring with it endian issues. > > > > > > With one detail missed, why do you need all that if you can use > > > byteorder helpers()? What's the stack? Just replace this entire > > > function with the respectful calls to hex2bin(). > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > make sense to me. The byteorder helpers do not give a char array, which > > is what hex2bin() wants, so we end up with something like: > > > > __le16 foo = cpu_to_le16(key); > > u8 result; > > > > ret = hex2bin(&result, (char *)&foo, 1); > > if (ret < 0) > > return ret; > > > > return result; > > > > This to me looks like yucky code, It still results in "foo" having to > > be on the stack, because the out-of-line hex2bin() requires a pointer > > to be passed as the second argument. > > > > Maybe you could provide an example of what you're thinking of, because > > I'm at a loss to understand what you're thinking this should look like. > > So, let's look into the real callers to see, oh wait, it's a single caller! > Why can't you simply do > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > if (ret < 0) > return ret; > > in-place there? This is not legal C. Please can we back up this discussion, and start over with legal C suggestions. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 14:46 ` Russell King (Oracle) @ 2022-09-02 14:53 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 14:53 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > <linux@armlinux.org.uk> wrote: > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > +{ > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > + > > > > > > > + if (low < 0 || high < 0) > > > > > > > + return -1; > > > > > > > + > > > > > > > + return low | (high << 4); > > > > > > > +} > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > Is using hex2bin really better? > > > > > > > > Yes. > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > { > > > > > char k[2]; > > > > > u8 result; > > > > > int ret; > > > > > > > > > > k[0] = key; > > > > > k[1] = key >> 8; > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > > > return result; > > > > > } > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > write each "character" to the stack, then call a function, only to then > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > because that will bring with it endian issues. > > > > > > > > With one detail missed, why do you need all that if you can use > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > function with the respectful calls to hex2bin(). > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > make sense to me. The byteorder helpers do not give a char array, which > > > is what hex2bin() wants, so we end up with something like: > > > > > > __le16 foo = cpu_to_le16(key); > > > u8 result; > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > if (ret < 0) > > > return ret; > > > > > > return result; > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > to be passed as the second argument. > > > > > > Maybe you could provide an example of what you're thinking of, because > > > I'm at a loss to understand what you're thinking this should look like. > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > Why can't you simply do > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > if (ret < 0) > > return ret; > > > > in-place there? > > This is not legal C. I acknowledged this, sorry. > Please can we back up this discussion, and start > over with legal C suggestions. Thanks. Suggestion was given as well, let's create a helper used by apple stuff and later on we will consider the separate submission for the (new) specifier. Would it work for you? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 14:53 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 14:53 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > <linux@armlinux.org.uk> wrote: > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > +{ > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > + > > > > > > > + if (low < 0 || high < 0) > > > > > > > + return -1; > > > > > > > + > > > > > > > + return low | (high << 4); > > > > > > > +} > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > Is using hex2bin really better? > > > > > > > > Yes. > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > { > > > > > char k[2]; > > > > > u8 result; > > > > > int ret; > > > > > > > > > > k[0] = key; > > > > > k[1] = key >> 8; > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > > > return result; > > > > > } > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > write each "character" to the stack, then call a function, only to then > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > because that will bring with it endian issues. > > > > > > > > With one detail missed, why do you need all that if you can use > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > function with the respectful calls to hex2bin(). > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > make sense to me. The byteorder helpers do not give a char array, which > > > is what hex2bin() wants, so we end up with something like: > > > > > > __le16 foo = cpu_to_le16(key); > > > u8 result; > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > if (ret < 0) > > > return ret; > > > > > > return result; > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > to be passed as the second argument. > > > > > > Maybe you could provide an example of what you're thinking of, because > > > I'm at a loss to understand what you're thinking this should look like. > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > Why can't you simply do > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > if (ret < 0) > > return ret; > > > > in-place there? > > This is not legal C. I acknowledged this, sorry. > Please can we back up this discussion, and start > over with legal C suggestions. Thanks. Suggestion was given as well, let's create a helper used by apple stuff and later on we will consider the separate submission for the (new) specifier. Would it work for you? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 14:53 ` Andy Shevchenko @ 2022-09-02 15:34 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 15:34 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > > +{ > > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > > + > > > > > > > > + if (low < 0 || high < 0) > > > > > > > > + return -1; > > > > > > > > + > > > > > > > > + return low | (high << 4); > > > > > > > > +} > > > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > > > Is using hex2bin really better? > > > > > > > > > > Yes. > > > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > > { > > > > > > char k[2]; > > > > > > u8 result; > > > > > > int ret; > > > > > > > > > > > > k[0] = key; > > > > > > k[1] = key >> 8; > > > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > > if (ret < 0) > > > > > > return ret; > > > > > > > > > > > > return result; > > > > > > } > > > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > > write each "character" to the stack, then call a function, only to then > > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > > because that will bring with it endian issues. > > > > > > > > > > With one detail missed, why do you need all that if you can use > > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > > function with the respectful calls to hex2bin(). > > > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > > make sense to me. The byteorder helpers do not give a char array, which > > > > is what hex2bin() wants, so we end up with something like: > > > > > > > > __le16 foo = cpu_to_le16(key); > > > > u8 result; > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > if (ret < 0) > > > > return ret; > > > > > > > > return result; > > > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > > to be passed as the second argument. > > > > > > > > Maybe you could provide an example of what you're thinking of, because > > > > I'm at a loss to understand what you're thinking this should look like. > > > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > > Why can't you simply do > > > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > > if (ret < 0) > > > return ret; > > > > > > in-place there? > > > > This is not legal C. > > I acknowledged this, sorry. > > > Please can we back up this discussion, and start > > over with legal C suggestions. Thanks. > > Suggestion was given as well, let's create a helper used by apple > stuff and later on we will consider the separate submission for the > (new) specifier. Would it work for you? This sub-thread isn't about the %p4ch specifier. It's about a reasonable implementation of macsmc_gpio_nr(). Extracting from the context above, the original code was: static int macsmc_gpio_nr(smc_key key) { int low = hex_to_bin(key & 0xff); int high = hex_to_bin((key >> 8) & 0xff); if (low < 0 || high < 0) return -1; return low | (high << 4); } I suggested: static int macsmc_gpio_nr(smc_key key) { char k[2]; u8 result; int ret; k[0] = key; k[1] = key >> 8; ret = hex2bin(&result, k, 2); if (ret < 0) return ret; return result; } You didn't like that, so I then suggested: static int macsmc_gpio_nr(smc_key key) { __le16 foo = cpu_to_le16(key); u8 result; int ret; ret = hex2bin(&result, (char *)&foo, 1); if (ret < 0) return ret; return result; } which you also didn't like, and then you suggested something that isn't legal C. So, I then asked you to backup this discussion... As I've made a number of suggestions, and you've essentially rejected them all, I still need to know what you would find acceptable for this, because I'm out of ideas. (I haven't bothered to check whether my last suggestion even works - I am hoping to find out what general style of code you would accept here. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 15:34 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-02 15:34 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > > <linux@armlinux.org.uk> wrote: > > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > > +{ > > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > > + > > > > > > > > + if (low < 0 || high < 0) > > > > > > > > + return -1; > > > > > > > > + > > > > > > > > + return low | (high << 4); > > > > > > > > +} > > > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > > > Is using hex2bin really better? > > > > > > > > > > Yes. > > > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > > { > > > > > > char k[2]; > > > > > > u8 result; > > > > > > int ret; > > > > > > > > > > > > k[0] = key; > > > > > > k[1] = key >> 8; > > > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > > if (ret < 0) > > > > > > return ret; > > > > > > > > > > > > return result; > > > > > > } > > > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > > write each "character" to the stack, then call a function, only to then > > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > > because that will bring with it endian issues. > > > > > > > > > > With one detail missed, why do you need all that if you can use > > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > > function with the respectful calls to hex2bin(). > > > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > > make sense to me. The byteorder helpers do not give a char array, which > > > > is what hex2bin() wants, so we end up with something like: > > > > > > > > __le16 foo = cpu_to_le16(key); > > > > u8 result; > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > if (ret < 0) > > > > return ret; > > > > > > > > return result; > > > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > > to be passed as the second argument. > > > > > > > > Maybe you could provide an example of what you're thinking of, because > > > > I'm at a loss to understand what you're thinking this should look like. > > > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > > Why can't you simply do > > > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > > if (ret < 0) > > > return ret; > > > > > > in-place there? > > > > This is not legal C. > > I acknowledged this, sorry. > > > Please can we back up this discussion, and start > > over with legal C suggestions. Thanks. > > Suggestion was given as well, let's create a helper used by apple > stuff and later on we will consider the separate submission for the > (new) specifier. Would it work for you? This sub-thread isn't about the %p4ch specifier. It's about a reasonable implementation of macsmc_gpio_nr(). Extracting from the context above, the original code was: static int macsmc_gpio_nr(smc_key key) { int low = hex_to_bin(key & 0xff); int high = hex_to_bin((key >> 8) & 0xff); if (low < 0 || high < 0) return -1; return low | (high << 4); } I suggested: static int macsmc_gpio_nr(smc_key key) { char k[2]; u8 result; int ret; k[0] = key; k[1] = key >> 8; ret = hex2bin(&result, k, 2); if (ret < 0) return ret; return result; } You didn't like that, so I then suggested: static int macsmc_gpio_nr(smc_key key) { __le16 foo = cpu_to_le16(key); u8 result; int ret; ret = hex2bin(&result, (char *)&foo, 1); if (ret < 0) return ret; return result; } which you also didn't like, and then you suggested something that isn't legal C. So, I then asked you to backup this discussion... As I've made a number of suggestions, and you've essentially rejected them all, I still need to know what you would find acceptable for this, because I'm out of ideas. (I haven't bothered to check whether my last suggestion even works - I am hoping to find out what general style of code you would accept here. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 15:34 ` Russell King (Oracle) @ 2022-09-02 15:43 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 15:43 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > > > <linux@armlinux.org.uk> wrote: > > > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > > > <linux@armlinux.org.uk> wrote: > > > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > > > +{ > > > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > > > + > > > > > > > > > + if (low < 0 || high < 0) > > > > > > > > > + return -1; > > > > > > > > > + > > > > > > > > > + return low | (high << 4); > > > > > > > > > +} > > > > > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > > > > > Is using hex2bin really better? > > > > > > > > > > > > Yes. > > > > > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > > > { > > > > > > > char k[2]; > > > > > > > u8 result; > > > > > > > int ret; > > > > > > > > > > > > > > k[0] = key; > > > > > > > k[1] = key >> 8; > > > > > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > > > if (ret < 0) > > > > > > > return ret; > > > > > > > > > > > > > > return result; > > > > > > > } > > > > > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > > > write each "character" to the stack, then call a function, only to then > > > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > > > because that will bring with it endian issues. > > > > > > > > > > > > With one detail missed, why do you need all that if you can use > > > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > > > function with the respectful calls to hex2bin(). > > > > > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > > > make sense to me. The byteorder helpers do not give a char array, which > > > > > is what hex2bin() wants, so we end up with something like: > > > > > > > > > > __le16 foo = cpu_to_le16(key); > > > > > u8 result; > > > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > > > return result; > > > > > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > > > to be passed as the second argument. > > > > > > > > > > Maybe you could provide an example of what you're thinking of, because > > > > > I'm at a loss to understand what you're thinking this should look like. > > > > > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > > > Why can't you simply do > > > > > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > > > if (ret < 0) > > > > return ret; > > > > > > > > in-place there? > > > > > > This is not legal C. > > > > I acknowledged this, sorry. > > > > > Please can we back up this discussion, and start > > > over with legal C suggestions. Thanks. > > > > Suggestion was given as well, let's create a helper used by apple > > stuff and later on we will consider the separate submission for the > > (new) specifier. Would it work for you? > > This sub-thread isn't about the %p4ch specifier. It's about a > reasonable implementation of macsmc_gpio_nr(). > > Extracting from the context above, the original code was: > > static int macsmc_gpio_nr(smc_key key) > { > int low = hex_to_bin(key & 0xff); > int high = hex_to_bin((key >> 8) & 0xff); > > if (low < 0 || high < 0) > return -1; > > return low | (high << 4); > } > > I suggested: > > static int macsmc_gpio_nr(smc_key key) > { > char k[2]; > u8 result; > int ret; > > k[0] = key; > k[1] = key >> 8; > > ret = hex2bin(&result, k, 2); > if (ret < 0) > return ret; > > return result; > } > > You didn't like that, so I then suggested: > > static int macsmc_gpio_nr(smc_key key) > { > __le16 foo = cpu_to_le16(key); > u8 result; > int ret; > > ret = hex2bin(&result, (char *)&foo, 1); > if (ret < 0) > return ret; > > return result; > } > > which you also didn't like, ...based on the wrong suggestion below. That said, the above is fine to me. > and then you suggested something that isn't > legal C. So, I then asked you to backup this discussion... > > As I've made a number of suggestions, and you've essentially rejected > them all, I still need to know what you would find acceptable for this, > because I'm out of ideas. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 15:43 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-02 15:43 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > > > <linux@armlinux.org.uk> wrote: > > > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > > > <linux@armlinux.org.uk> wrote: > > > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > > > +{ > > > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > > > + > > > > > > > > > + if (low < 0 || high < 0) > > > > > > > > > + return -1; > > > > > > > > > + > > > > > > > > > + return low | (high << 4); > > > > > > > > > +} > > > > > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > > > > > Is using hex2bin really better? > > > > > > > > > > > > Yes. > > > > > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > > > { > > > > > > > char k[2]; > > > > > > > u8 result; > > > > > > > int ret; > > > > > > > > > > > > > > k[0] = key; > > > > > > > k[1] = key >> 8; > > > > > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > > > if (ret < 0) > > > > > > > return ret; > > > > > > > > > > > > > > return result; > > > > > > > } > > > > > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > > > write each "character" to the stack, then call a function, only to then > > > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > > > because that will bring with it endian issues. > > > > > > > > > > > > With one detail missed, why do you need all that if you can use > > > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > > > function with the respectful calls to hex2bin(). > > > > > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > > > make sense to me. The byteorder helpers do not give a char array, which > > > > > is what hex2bin() wants, so we end up with something like: > > > > > > > > > > __le16 foo = cpu_to_le16(key); > > > > > u8 result; > > > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > > > return result; > > > > > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > > > to be passed as the second argument. > > > > > > > > > > Maybe you could provide an example of what you're thinking of, because > > > > > I'm at a loss to understand what you're thinking this should look like. > > > > > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > > > Why can't you simply do > > > > > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > > > if (ret < 0) > > > > return ret; > > > > > > > > in-place there? > > > > > > This is not legal C. > > > > I acknowledged this, sorry. > > > > > Please can we back up this discussion, and start > > > over with legal C suggestions. Thanks. > > > > Suggestion was given as well, let's create a helper used by apple > > stuff and later on we will consider the separate submission for the > > (new) specifier. Would it work for you? > > This sub-thread isn't about the %p4ch specifier. It's about a > reasonable implementation of macsmc_gpio_nr(). > > Extracting from the context above, the original code was: > > static int macsmc_gpio_nr(smc_key key) > { > int low = hex_to_bin(key & 0xff); > int high = hex_to_bin((key >> 8) & 0xff); > > if (low < 0 || high < 0) > return -1; > > return low | (high << 4); > } > > I suggested: > > static int macsmc_gpio_nr(smc_key key) > { > char k[2]; > u8 result; > int ret; > > k[0] = key; > k[1] = key >> 8; > > ret = hex2bin(&result, k, 2); > if (ret < 0) > return ret; > > return result; > } > > You didn't like that, so I then suggested: > > static int macsmc_gpio_nr(smc_key key) > { > __le16 foo = cpu_to_le16(key); > u8 result; > int ret; > > ret = hex2bin(&result, (char *)&foo, 1); > if (ret < 0) > return ret; > > return result; > } > > which you also didn't like, ...based on the wrong suggestion below. That said, the above is fine to me. > and then you suggested something that isn't > legal C. So, I then asked you to backup this discussion... > > As I've made a number of suggestions, and you've essentially rejected > them all, I still need to know what you would find acceptable for this, > because I'm out of ideas. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 15:43 ` Andy Shevchenko @ 2022-09-05 10:20 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 10:20 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 06:43:36PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > > > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > > > > <linux@armlinux.org.uk> wrote: > > > > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > > > > <linux@armlinux.org.uk> wrote: > > > > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > > > > +{ > > > > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > > > > + > > > > > > > > > > + if (low < 0 || high < 0) > > > > > > > > > > + return -1; > > > > > > > > > > + > > > > > > > > > > + return low | (high << 4); > > > > > > > > > > +} > > > > > > > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > > > > > > > Is using hex2bin really better? > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > > > > { > > > > > > > > char k[2]; > > > > > > > > u8 result; > > > > > > > > int ret; > > > > > > > > > > > > > > > > k[0] = key; > > > > > > > > k[1] = key >> 8; > > > > > > > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > > > > if (ret < 0) > > > > > > > > return ret; > > > > > > > > > > > > > > > > return result; > > > > > > > > } > > > > > > > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > > > > write each "character" to the stack, then call a function, only to then > > > > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > > > > because that will bring with it endian issues. > > > > > > > > > > > > > > With one detail missed, why do you need all that if you can use > > > > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > > > > function with the respectful calls to hex2bin(). > > > > > > > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > > > > make sense to me. The byteorder helpers do not give a char array, which > > > > > > is what hex2bin() wants, so we end up with something like: > > > > > > > > > > > > __le16 foo = cpu_to_le16(key); > > > > > > u8 result; > > > > > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > > > if (ret < 0) > > > > > > return ret; > > > > > > > > > > > > return result; > > > > > > > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > > > > to be passed as the second argument. > > > > > > > > > > > > Maybe you could provide an example of what you're thinking of, because > > > > > > I'm at a loss to understand what you're thinking this should look like. > > > > > > > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > > > > Why can't you simply do > > > > > > > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > > > in-place there? > > > > > > > > This is not legal C. > > > > > > I acknowledged this, sorry. > > > > > > > Please can we back up this discussion, and start > > > > over with legal C suggestions. Thanks. > > > > > > Suggestion was given as well, let's create a helper used by apple > > > stuff and later on we will consider the separate submission for the > > > (new) specifier. Would it work for you? > > > > This sub-thread isn't about the %p4ch specifier. It's about a > > reasonable implementation of macsmc_gpio_nr(). > > > > Extracting from the context above, the original code was: > > > > static int macsmc_gpio_nr(smc_key key) > > { > > int low = hex_to_bin(key & 0xff); > > int high = hex_to_bin((key >> 8) & 0xff); > > > > if (low < 0 || high < 0) > > return -1; > > > > return low | (high << 4); > > } > > > > I suggested: > > > > static int macsmc_gpio_nr(smc_key key) > > { > > char k[2]; > > u8 result; > > int ret; > > > > k[0] = key; > > k[1] = key >> 8; > > > > ret = hex2bin(&result, k, 2); > > if (ret < 0) > > return ret; > > > > return result; > > } > > > > You didn't like that, so I then suggested: > > > > static int macsmc_gpio_nr(smc_key key) > > { > > __le16 foo = cpu_to_le16(key); > > u8 result; > > int ret; > > > > ret = hex2bin(&result, (char *)&foo, 1); > > if (ret < 0) > > return ret; > > > > return result; > > } > > > > which you also didn't like, > > ...based on the wrong suggestion below. That said, the above is fine to me. To be honest, using the endian conversion macro there doesn't feel right and is more prone to programming errors. I can't tell just by looking at it that either cpu_to_le16() or cpu_to_le32() would be the right thing here - and if it's not obvious then it's a bug waiting to happen. As if to prove the point, the above suggestions turn out to *all* be buggy. The initial suggestion gets the k[0] and k[1] assignment round the wrong way. The second, le16() is definitely not the right conversion. If we start using the endian conversion macros, then this is going to screw up if someone runs a BE kernel against the SMC (since the _SMC_KEY() macro will still be doing its conversion.) This seems utterly counter-productive, and I've spent quite a long time trying to work out what would be correct. At this point, I'm not sure that changing what has already been established in the Asahi Linux tree for something entirely different in mainline is going to be practical - it's a recipe for repeated mistakes converting keys from the Asahi kernel to the mainline kernel. It's not _just_ the GPIO driver. There are multiple other drivers that will be impacted by changing the scheme here. Any change to the scheme for these SMC keys needs to happen in the Asahi kernel tree by the Asahi Linux maintainers, not by someone pushing the code upstream - doing so would be a recipe for repeated trainwrecks. So, I'm going with my first suggestion for the hex2bin() conversion above, and adding a comment thusly: /* * The most significant nibble comes from k[0] and key bits 15..8 * The least significant nibble comes from k[1] and key bits 7..0 */ k[0] = key >> 8; k[1] = key; because I needed the comment to prove to myself that I wasn't breaking this code. Maybe it's obvious to you, but it isn't obvious to everyone. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 10:20 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 10:20 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Fri, Sep 02, 2022 at 06:43:36PM +0300, Andy Shevchenko wrote: > On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 5:46 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Fri, Sep 02, 2022 at 04:39:16PM +0300, Andy Shevchenko wrote: > > > > > On Fri, Sep 2, 2022 at 2:33 PM Russell King (Oracle) > > > > > <linux@armlinux.org.uk> wrote: > > > > > > On Fri, Sep 02, 2022 at 01:37:14PM +0300, Andy Shevchenko wrote: > > > > > > > On Fri, Sep 2, 2022 at 1:05 PM Russell King (Oracle) > > > > > > > <linux@armlinux.org.uk> wrote: > > > > > > > > On Thu, Sep 01, 2022 at 09:55:23PM +0300, Andy Shevchenko wrote: > > > > > > > > > > +static int macsmc_gpio_nr(smc_key key) > > > > > > > > > > +{ > > > > > > > > > > + int low = hex_to_bin(key & 0xff); > > > > > > > > > > + int high = hex_to_bin((key >> 8) & 0xff); > > > > > > > > > > + > > > > > > > > > > + if (low < 0 || high < 0) > > > > > > > > > > + return -1; > > > > > > > > > > + > > > > > > > > > > + return low | (high << 4); > > > > > > > > > > +} > > > > > > > > > > > > > > > > > > NIH hex2bin(). > > > > > > > > > > > > > > > > Is using hex2bin really better? > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > static int macsmc_gpio_nr(smc_key key) > > > > > > > > { > > > > > > > > char k[2]; > > > > > > > > u8 result; > > > > > > > > int ret; > > > > > > > > > > > > > > > > k[0] = key; > > > > > > > > k[1] = key >> 8; > > > > > > > > > > > > > > > > ret = hex2bin(&result, k, 2); > > > > > > > > if (ret < 0) > > > > > > > > return ret; > > > > > > > > > > > > > > > > return result; > > > > > > > > } > > > > > > > > > > > > > > > > This looks to me like it consumes more CPU cycles - because we have to > > > > > > > > write each "character" to the stack, then call a function, only to then > > > > > > > > call the hex_to_bin() function. One can't just pass "key" into hex2bin > > > > > > > > because that will bring with it endian issues. > > > > > > > > > > > > > > With one detail missed, why do you need all that if you can use > > > > > > > byteorder helpers()? What's the stack? Just replace this entire > > > > > > > function with the respectful calls to hex2bin(). > > > > > > > > > > > > Sorry, I don't understand what you're suggesting, because it doesn't > > > > > > make sense to me. The byteorder helpers do not give a char array, which > > > > > > is what hex2bin() wants, so we end up with something like: > > > > > > > > > > > > __le16 foo = cpu_to_le16(key); > > > > > > u8 result; > > > > > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > > > if (ret < 0) > > > > > > return ret; > > > > > > > > > > > > return result; > > > > > > > > > > > > This to me looks like yucky code, It still results in "foo" having to > > > > > > be on the stack, because the out-of-line hex2bin() requires a pointer > > > > > > to be passed as the second argument. > > > > > > > > > > > > Maybe you could provide an example of what you're thinking of, because > > > > > > I'm at a loss to understand what you're thinking this should look like. > > > > > > > > > > So, let's look into the real callers to see, oh wait, it's a single caller! > > > > > Why can't you simply do > > > > > > > > > > ret = hex2bin(&result, (char *)&cpu_to_le16(key), 1); > > > > > if (ret < 0) > > > > > return ret; > > > > > > > > > > in-place there? > > > > > > > > This is not legal C. > > > > > > I acknowledged this, sorry. > > > > > > > Please can we back up this discussion, and start > > > > over with legal C suggestions. Thanks. > > > > > > Suggestion was given as well, let's create a helper used by apple > > > stuff and later on we will consider the separate submission for the > > > (new) specifier. Would it work for you? > > > > This sub-thread isn't about the %p4ch specifier. It's about a > > reasonable implementation of macsmc_gpio_nr(). > > > > Extracting from the context above, the original code was: > > > > static int macsmc_gpio_nr(smc_key key) > > { > > int low = hex_to_bin(key & 0xff); > > int high = hex_to_bin((key >> 8) & 0xff); > > > > if (low < 0 || high < 0) > > return -1; > > > > return low | (high << 4); > > } > > > > I suggested: > > > > static int macsmc_gpio_nr(smc_key key) > > { > > char k[2]; > > u8 result; > > int ret; > > > > k[0] = key; > > k[1] = key >> 8; > > > > ret = hex2bin(&result, k, 2); > > if (ret < 0) > > return ret; > > > > return result; > > } > > > > You didn't like that, so I then suggested: > > > > static int macsmc_gpio_nr(smc_key key) > > { > > __le16 foo = cpu_to_le16(key); > > u8 result; > > int ret; > > > > ret = hex2bin(&result, (char *)&foo, 1); > > if (ret < 0) > > return ret; > > > > return result; > > } > > > > which you also didn't like, > > ...based on the wrong suggestion below. That said, the above is fine to me. To be honest, using the endian conversion macro there doesn't feel right and is more prone to programming errors. I can't tell just by looking at it that either cpu_to_le16() or cpu_to_le32() would be the right thing here - and if it's not obvious then it's a bug waiting to happen. As if to prove the point, the above suggestions turn out to *all* be buggy. The initial suggestion gets the k[0] and k[1] assignment round the wrong way. The second, le16() is definitely not the right conversion. If we start using the endian conversion macros, then this is going to screw up if someone runs a BE kernel against the SMC (since the _SMC_KEY() macro will still be doing its conversion.) This seems utterly counter-productive, and I've spent quite a long time trying to work out what would be correct. At this point, I'm not sure that changing what has already been established in the Asahi Linux tree for something entirely different in mainline is going to be practical - it's a recipe for repeated mistakes converting keys from the Asahi kernel to the mainline kernel. It's not _just_ the GPIO driver. There are multiple other drivers that will be impacted by changing the scheme here. Any change to the scheme for these SMC keys needs to happen in the Asahi kernel tree by the Asahi Linux maintainers, not by someone pushing the code upstream - doing so would be a recipe for repeated trainwrecks. So, I'm going with my first suggestion for the hex2bin() conversion above, and adding a comment thusly: /* * The most significant nibble comes from k[0] and key bits 15..8 * The least significant nibble comes from k[1] and key bits 7..0 */ k[0] = key >> 8; k[1] = key; because I needed the comment to prove to myself that I wasn't breaking this code. Maybe it's obvious to you, but it isn't obvious to everyone. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 10:20 ` Russell King (Oracle) @ 2022-09-05 10:32 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 10:32 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 1:20 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 06:43:36PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: ... > > > static int macsmc_gpio_nr(smc_key key) > > > { > > > __le16 foo = cpu_to_le16(key); > > > u8 result; > > > int ret; > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > if (ret < 0) > > > return ret; > > > > > > return result; > > > } > > > > > > which you also didn't like, > > > > ...based on the wrong suggestion below. That said, the above is fine to me. > > To be honest, using the endian conversion macro there doesn't feel > right and is more prone to programming errors. I can't tell just by > looking at it that either cpu_to_le16() or cpu_to_le32() would be the > right thing here - and if it's not obvious then it's a bug waiting to > happen. > > As if to prove the point, the above suggestions turn out to *all* be > buggy. > > The initial suggestion gets the k[0] and k[1] assignment round the > wrong way. The second, le16() is definitely not the right conversion. > If we start using the endian conversion macros, then this is going to > screw up if someone runs a BE kernel against the SMC (since the > _SMC_KEY() macro will still be doing its conversion.) > > This seems utterly counter-productive, and I've spent quite a long > time trying to work out what would be correct. > > At this point, I'm not sure that changing what has already been > established in the Asahi Linux tree for something entirely different > in mainline is going to be practical - it's a recipe for repeated > mistakes converting keys from the Asahi kernel to the mainline > kernel. > > It's not _just_ the GPIO driver. There are multiple other drivers > that will be impacted by changing the scheme here. > > Any change to the scheme for these SMC keys needs to happen in the > Asahi kernel tree by the Asahi Linux maintainers, not by someone > pushing the code upstream - doing so would be a recipe for repeated > trainwrecks. > > So, I'm going with my first suggestion for the hex2bin() conversion > above, and adding a comment thusly: > > /* > * The most significant nibble comes from k[0] and key bits 15..8 > * The least significant nibble comes from k[1] and key bits 7..0 > */ > k[0] = key >> 8; > k[1] = key; > > because I needed the comment to prove to myself that I wasn't breaking > this code. Maybe it's obvious to you, but it isn't obvious to everyone. And how is it different to the key being __be16 and all operations against it be correct with the endianness helpers? Adding redundant comments when the bitwise type exists seems just like being afraid of the unknown. Ah, I see that in one of your long letters the proposal somehow switched from (implicit) be16 to (explicit) le16... Still to me it's not enough justification for the comment, but since it has no effect on the code generation, add it if you think it would be better. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 10:32 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 10:32 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 1:20 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 06:43:36PM +0300, Andy Shevchenko wrote: > > On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: ... > > > static int macsmc_gpio_nr(smc_key key) > > > { > > > __le16 foo = cpu_to_le16(key); > > > u8 result; > > > int ret; > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > if (ret < 0) > > > return ret; > > > > > > return result; > > > } > > > > > > which you also didn't like, > > > > ...based on the wrong suggestion below. That said, the above is fine to me. > > To be honest, using the endian conversion macro there doesn't feel > right and is more prone to programming errors. I can't tell just by > looking at it that either cpu_to_le16() or cpu_to_le32() would be the > right thing here - and if it's not obvious then it's a bug waiting to > happen. > > As if to prove the point, the above suggestions turn out to *all* be > buggy. > > The initial suggestion gets the k[0] and k[1] assignment round the > wrong way. The second, le16() is definitely not the right conversion. > If we start using the endian conversion macros, then this is going to > screw up if someone runs a BE kernel against the SMC (since the > _SMC_KEY() macro will still be doing its conversion.) > > This seems utterly counter-productive, and I've spent quite a long > time trying to work out what would be correct. > > At this point, I'm not sure that changing what has already been > established in the Asahi Linux tree for something entirely different > in mainline is going to be practical - it's a recipe for repeated > mistakes converting keys from the Asahi kernel to the mainline > kernel. > > It's not _just_ the GPIO driver. There are multiple other drivers > that will be impacted by changing the scheme here. > > Any change to the scheme for these SMC keys needs to happen in the > Asahi kernel tree by the Asahi Linux maintainers, not by someone > pushing the code upstream - doing so would be a recipe for repeated > trainwrecks. > > So, I'm going with my first suggestion for the hex2bin() conversion > above, and adding a comment thusly: > > /* > * The most significant nibble comes from k[0] and key bits 15..8 > * The least significant nibble comes from k[1] and key bits 7..0 > */ > k[0] = key >> 8; > k[1] = key; > > because I needed the comment to prove to myself that I wasn't breaking > this code. Maybe it's obvious to you, but it isn't obvious to everyone. And how is it different to the key being __be16 and all operations against it be correct with the endianness helpers? Adding redundant comments when the bitwise type exists seems just like being afraid of the unknown. Ah, I see that in one of your long letters the proposal somehow switched from (implicit) be16 to (explicit) le16... Still to me it's not enough justification for the comment, but since it has no effect on the code generation, add it if you think it would be better. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 10:32 ` Andy Shevchenko @ 2022-09-05 13:10 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 13:10 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 1:20 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 06:43:36PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > > ... > > > > > static int macsmc_gpio_nr(smc_key key) > > > > { > > > > __le16 foo = cpu_to_le16(key); > > > > u8 result; > > > > int ret; > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > if (ret < 0) > > > > return ret; > > > > > > > > return result; > > > > } > > > > > > > > which you also didn't like, > > > > > > ...based on the wrong suggestion below. That said, the above is fine to me. > > > > To be honest, using the endian conversion macro there doesn't feel > > right and is more prone to programming errors. I can't tell just by > > looking at it that either cpu_to_le16() or cpu_to_le32() would be the > > right thing here - and if it's not obvious then it's a bug waiting to > > happen. > > > > As if to prove the point, the above suggestions turn out to *all* be > > buggy. > > > > The initial suggestion gets the k[0] and k[1] assignment round the > > wrong way. The second, le16() is definitely not the right conversion. > > If we start using the endian conversion macros, then this is going to > > screw up if someone runs a BE kernel against the SMC (since the > > _SMC_KEY() macro will still be doing its conversion.) > > > > This seems utterly counter-productive, and I've spent quite a long > > time trying to work out what would be correct. > > > > At this point, I'm not sure that changing what has already been > > established in the Asahi Linux tree for something entirely different > > in mainline is going to be practical - it's a recipe for repeated > > mistakes converting keys from the Asahi kernel to the mainline > > kernel. > > > > It's not _just_ the GPIO driver. There are multiple other drivers > > that will be impacted by changing the scheme here. > > > > Any change to the scheme for these SMC keys needs to happen in the > > Asahi kernel tree by the Asahi Linux maintainers, not by someone > > pushing the code upstream - doing so would be a recipe for repeated > > trainwrecks. > > > > So, I'm going with my first suggestion for the hex2bin() conversion > > above, and adding a comment thusly: > > > > /* > > * The most significant nibble comes from k[0] and key bits 15..8 > > * The least significant nibble comes from k[1] and key bits 7..0 > > */ > > k[0] = key >> 8; > > k[1] = key; > > > > because I needed the comment to prove to myself that I wasn't breaking > > this code. Maybe it's obvious to you, but it isn't obvious to everyone. > > And how is it different to the key being __be16 and all operations > against it be correct with the endianness helpers? First, the key is not 16-bit, it's 32-bit. Secondly, the "key" returned from the SMC is always swab()'d before we use it - and before we pass it back to the SMC. There's a big open question right now about whether it's the Asahi developers choice to arrange the four character key in big-endian form on LE platforms, and whether this is application processor endian dependent or not. It's packed into a 64-bit integer: msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | FIELD_PREP(SMC_SIZE, size) | FIELD_PREP(SMC_ID, smc->msg_id) | FIELD_PREP(SMC_DATA, key)); in bits 32..63, which is then written using writeq_relaxed() to the mailbox registers. However, the keys returned from the SMC are the opposite endian-ness: static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, smc_key *key) { struct apple_smc_rtkit *smc = cookie; int ret; ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); *key = swab32(*key); return ret; } where apple_smc_cmd() does this to get the returned data: if (ret_data) *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); which comes from apple_smc_rtkit_recv_early(..., u64 message): smc->cmd_ret = message; which comes from apple_rtkit_rx(): if (ep >= APPLE_RTKIT_APP_ENDPOINT_START && rtk->ops->recv_message_early && rtk->ops->recv_message_early(rtk->cookie, ep, msg->msg0)) return; which ultimately comes from apple_mbox_hw_recv(); msg->msg0 = readq_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_recv0); So what _is_ the right endian for the keys? I've no idea. > Adding redundant > comments when the bitwise type exists seems just like being afraid of > the unknown. Ah, I see that in one of your long letters the proposal > somehow switched from (implicit) be16 to (explicit) le16... Still to > me it's not enough justification for the comment, but since it has no > effect on the code generation, add it if you think it would be better. If you have a clear picture what this should be throughout multiple drivers (it seems you do) then please explain it to me, and make proposals to the Asahi Linux people how the SMC key stuff can be more understandable, because quite honestly, I don't think I'm qualified to touch what they have without introducing a shit-load of bugs. And in that circumstance, simple obviously correct code is better than a pile of steaming crap that no longer works. Even worse is when there's a fundamental incompatibility between what we have in mainline and what Asahi folk are using. Even worse is if this breaks on other Apple application-processor architectures. Let me say again: I am not changing this. That's for Asahi people to do if they wish. I am the just middle-man here. And yes, we need to do something about the %p4ch stuff. I have _no_ idea how to properly solve that right now - and how to properly solve that depends on what comes out of the discussion about what endianness this "smc_key" thing should be. Unless I get some input from the Asahi folk, I won't be posting a v2, because I can't address stuff like %p4ch without that. And I'm not going to mess about with endian conversions in silly places when it's not obvious that it's the right thing to be doing. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 13:10 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 13:10 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 1:20 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Fri, Sep 02, 2022 at 06:43:36PM +0300, Andy Shevchenko wrote: > > > On Fri, Sep 2, 2022 at 6:34 PM Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > On Fri, Sep 02, 2022 at 05:53:25PM +0300, Andy Shevchenko wrote: > > ... > > > > > static int macsmc_gpio_nr(smc_key key) > > > > { > > > > __le16 foo = cpu_to_le16(key); > > > > u8 result; > > > > int ret; > > > > > > > > ret = hex2bin(&result, (char *)&foo, 1); > > > > if (ret < 0) > > > > return ret; > > > > > > > > return result; > > > > } > > > > > > > > which you also didn't like, > > > > > > ...based on the wrong suggestion below. That said, the above is fine to me. > > > > To be honest, using the endian conversion macro there doesn't feel > > right and is more prone to programming errors. I can't tell just by > > looking at it that either cpu_to_le16() or cpu_to_le32() would be the > > right thing here - and if it's not obvious then it's a bug waiting to > > happen. > > > > As if to prove the point, the above suggestions turn out to *all* be > > buggy. > > > > The initial suggestion gets the k[0] and k[1] assignment round the > > wrong way. The second, le16() is definitely not the right conversion. > > If we start using the endian conversion macros, then this is going to > > screw up if someone runs a BE kernel against the SMC (since the > > _SMC_KEY() macro will still be doing its conversion.) > > > > This seems utterly counter-productive, and I've spent quite a long > > time trying to work out what would be correct. > > > > At this point, I'm not sure that changing what has already been > > established in the Asahi Linux tree for something entirely different > > in mainline is going to be practical - it's a recipe for repeated > > mistakes converting keys from the Asahi kernel to the mainline > > kernel. > > > > It's not _just_ the GPIO driver. There are multiple other drivers > > that will be impacted by changing the scheme here. > > > > Any change to the scheme for these SMC keys needs to happen in the > > Asahi kernel tree by the Asahi Linux maintainers, not by someone > > pushing the code upstream - doing so would be a recipe for repeated > > trainwrecks. > > > > So, I'm going with my first suggestion for the hex2bin() conversion > > above, and adding a comment thusly: > > > > /* > > * The most significant nibble comes from k[0] and key bits 15..8 > > * The least significant nibble comes from k[1] and key bits 7..0 > > */ > > k[0] = key >> 8; > > k[1] = key; > > > > because I needed the comment to prove to myself that I wasn't breaking > > this code. Maybe it's obvious to you, but it isn't obvious to everyone. > > And how is it different to the key being __be16 and all operations > against it be correct with the endianness helpers? First, the key is not 16-bit, it's 32-bit. Secondly, the "key" returned from the SMC is always swab()'d before we use it - and before we pass it back to the SMC. There's a big open question right now about whether it's the Asahi developers choice to arrange the four character key in big-endian form on LE platforms, and whether this is application processor endian dependent or not. It's packed into a 64-bit integer: msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | FIELD_PREP(SMC_SIZE, size) | FIELD_PREP(SMC_ID, smc->msg_id) | FIELD_PREP(SMC_DATA, key)); in bits 32..63, which is then written using writeq_relaxed() to the mailbox registers. However, the keys returned from the SMC are the opposite endian-ness: static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, smc_key *key) { struct apple_smc_rtkit *smc = cookie; int ret; ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); *key = swab32(*key); return ret; } where apple_smc_cmd() does this to get the returned data: if (ret_data) *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); which comes from apple_smc_rtkit_recv_early(..., u64 message): smc->cmd_ret = message; which comes from apple_rtkit_rx(): if (ep >= APPLE_RTKIT_APP_ENDPOINT_START && rtk->ops->recv_message_early && rtk->ops->recv_message_early(rtk->cookie, ep, msg->msg0)) return; which ultimately comes from apple_mbox_hw_recv(); msg->msg0 = readq_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_recv0); So what _is_ the right endian for the keys? I've no idea. > Adding redundant > comments when the bitwise type exists seems just like being afraid of > the unknown. Ah, I see that in one of your long letters the proposal > somehow switched from (implicit) be16 to (explicit) le16... Still to > me it's not enough justification for the comment, but since it has no > effect on the code generation, add it if you think it would be better. If you have a clear picture what this should be throughout multiple drivers (it seems you do) then please explain it to me, and make proposals to the Asahi Linux people how the SMC key stuff can be more understandable, because quite honestly, I don't think I'm qualified to touch what they have without introducing a shit-load of bugs. And in that circumstance, simple obviously correct code is better than a pile of steaming crap that no longer works. Even worse is when there's a fundamental incompatibility between what we have in mainline and what Asahi folk are using. Even worse is if this breaks on other Apple application-processor architectures. Let me say again: I am not changing this. That's for Asahi people to do if they wish. I am the just middle-man here. And yes, we need to do something about the %p4ch stuff. I have _no_ idea how to properly solve that right now - and how to properly solve that depends on what comes out of the discussion about what endianness this "smc_key" thing should be. Unless I get some input from the Asahi folk, I won't be posting a v2, because I can't address stuff like %p4ch without that. And I'm not going to mess about with endian conversions in silly places when it's not obvious that it's the right thing to be doing. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 13:10 ` Russell King (Oracle) @ 2022-09-05 13:16 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 13:16 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: ... > Let me say again: I am not changing this. That's for Asahi people to > do if they wish. I am the just middle-man here. While I agree on technical aspects, this mythical "they" is frustrating me. They haven't participated in this discussion (yet?) so they do not care, why should we (as a community of upstream)? P.S. Do you have a platform to test all these? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 13:16 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 13:16 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: ... > Let me say again: I am not changing this. That's for Asahi people to > do if they wish. I am the just middle-man here. While I agree on technical aspects, this mythical "they" is frustrating me. They haven't participated in this discussion (yet?) so they do not care, why should we (as a community of upstream)? P.S. Do you have a platform to test all these? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 13:16 ` Andy Shevchenko @ 2022-09-05 14:01 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 14:01 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > ... > > > Let me say again: I am not changing this. That's for Asahi people to > > do if they wish. I am the just middle-man here. > > While I agree on technical aspects, this mythical "they" is > frustrating me. They haven't participated in this discussion (yet?) so > they do not care, why should we (as a community of upstream)? That's strange. I wonder. If they don't exist, then I wonder how Linus is running Linux on aarch64 apple hardware. Maybe it's not me with a problem here? Hector has been promising to get involved in this discussion for a few days now, his latest comment on IRC yesterday: 16:23 <@marcan> I'm going to allocate tuesday to playing the merge game (rmk: haven't forgotten about you either, IRQs today, but I'll get to it before tuesday): So he is aware that he needs to respond - but like any central project lead developer, he's probably exceedingly busy with other issues. > P.S. Do you have a platform to test all these? Yes, but that doesn't mean I can do testing sufficient to ensure that the modifications are correct. As I understand things, the SMC is not limited to just aarch64 hardware. It doesn't mean that "if it boots it must be okay" is sufficient. So, how about you stop insisting on changes until Hector can respond to some of the questions raised; as I've said many times, you are asking for stuff to be changed that is quite clearly in the realm of decisions that the Asahi developer(s) have taken, and I have no right to change them without reference to them - because I do not know this platform well enough to make the decisions you're asking of me. I'm not going to say that again; I'm going to start ignoring you if you persist in demanding that I make these kinds of decisions, because *you* leave me no other option but to do that... because *you* just don't seem to be willing to accept that I need others to be involved in these decisions. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 14:01 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 14:01 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > ... > > > Let me say again: I am not changing this. That's for Asahi people to > > do if they wish. I am the just middle-man here. > > While I agree on technical aspects, this mythical "they" is > frustrating me. They haven't participated in this discussion (yet?) so > they do not care, why should we (as a community of upstream)? That's strange. I wonder. If they don't exist, then I wonder how Linus is running Linux on aarch64 apple hardware. Maybe it's not me with a problem here? Hector has been promising to get involved in this discussion for a few days now, his latest comment on IRC yesterday: 16:23 <@marcan> I'm going to allocate tuesday to playing the merge game (rmk: haven't forgotten about you either, IRQs today, but I'll get to it before tuesday): So he is aware that he needs to respond - but like any central project lead developer, he's probably exceedingly busy with other issues. > P.S. Do you have a platform to test all these? Yes, but that doesn't mean I can do testing sufficient to ensure that the modifications are correct. As I understand things, the SMC is not limited to just aarch64 hardware. It doesn't mean that "if it boots it must be okay" is sufficient. So, how about you stop insisting on changes until Hector can respond to some of the questions raised; as I've said many times, you are asking for stuff to be changed that is quite clearly in the realm of decisions that the Asahi developer(s) have taken, and I have no right to change them without reference to them - because I do not know this platform well enough to make the decisions you're asking of me. I'm not going to say that again; I'm going to start ignoring you if you persist in demanding that I make these kinds of decisions, because *you* leave me no other option but to do that... because *you* just don't seem to be willing to accept that I need others to be involved in these decisions. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 14:01 ` Russell King (Oracle) @ 2022-09-05 14:02 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 14:02 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 03:01:09PM +0100, Russell King (Oracle) wrote: > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > > > ... > > > > > Let me say again: I am not changing this. That's for Asahi people to > > > do if they wish. I am the just middle-man here. > > > > While I agree on technical aspects, this mythical "they" is > > frustrating me. They haven't participated in this discussion (yet?) so > > they do not care, why should we (as a community of upstream)? > > That's strange. I wonder. If they don't exist, then I wonder how Linus > is running Linux on aarch64 apple hardware. Maybe it's not me with a > problem here? > > Hector has been promising to get involved in this discussion for a few > days now, his latest comment on IRC yesterday: > > 16:23 <@marcan> I'm going to allocate tuesday to playing the merge game (rmk: > haven't forgotten about you either, IRQs today, but I'll get to > it before tuesday): > > So he is aware that he needs to respond - but like any central project > lead developer, he's probably exceedingly busy with other issues. > > > P.S. Do you have a platform to test all these? > > Yes, but that doesn't mean I can do testing sufficient to ensure that > the modifications are correct. As I understand things, the SMC is not > limited to just aarch64 hardware. > > It doesn't mean that "if it boots it must be okay" is sufficient. > > So, how about you stop insisting on changes until Hector can respond > to some of the questions raised; as I've said many times, you are > asking for stuff to be changed that is quite clearly in the realm of > decisions that the Asahi developer(s) have taken, and I have no right > to change them without reference to them - because I do not know this > platform well enough to make the decisions you're asking of me. > > I'm not going to say that again; I'm going to start ignoring you if > you persist in demanding that I make these kinds of decisions, because > *you* leave me no other option but to do that... because *you* just > don't seem to be willing to accept that I need others to be involved > in these decisions. Oh, and another thing. Your behaviour on this is making me regret trying to get involved in improving the upstream support for this platform. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 14:02 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 14:02 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 03:01:09PM +0100, Russell King (Oracle) wrote: > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > > > ... > > > > > Let me say again: I am not changing this. That's for Asahi people to > > > do if they wish. I am the just middle-man here. > > > > While I agree on technical aspects, this mythical "they" is > > frustrating me. They haven't participated in this discussion (yet?) so > > they do not care, why should we (as a community of upstream)? > > That's strange. I wonder. If they don't exist, then I wonder how Linus > is running Linux on aarch64 apple hardware. Maybe it's not me with a > problem here? > > Hector has been promising to get involved in this discussion for a few > days now, his latest comment on IRC yesterday: > > 16:23 <@marcan> I'm going to allocate tuesday to playing the merge game (rmk: > haven't forgotten about you either, IRQs today, but I'll get to > it before tuesday): > > So he is aware that he needs to respond - but like any central project > lead developer, he's probably exceedingly busy with other issues. > > > P.S. Do you have a platform to test all these? > > Yes, but that doesn't mean I can do testing sufficient to ensure that > the modifications are correct. As I understand things, the SMC is not > limited to just aarch64 hardware. > > It doesn't mean that "if it boots it must be okay" is sufficient. > > So, how about you stop insisting on changes until Hector can respond > to some of the questions raised; as I've said many times, you are > asking for stuff to be changed that is quite clearly in the realm of > decisions that the Asahi developer(s) have taken, and I have no right > to change them without reference to them - because I do not know this > platform well enough to make the decisions you're asking of me. > > I'm not going to say that again; I'm going to start ignoring you if > you persist in demanding that I make these kinds of decisions, because > *you* leave me no other option but to do that... because *you* just > don't seem to be willing to accept that I need others to be involved > in these decisions. Oh, and another thing. Your behaviour on this is making me regret trying to get involved in improving the upstream support for this platform. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 14:02 ` Russell King (Oracle) @ 2022-09-05 14:42 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 14:42 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 5:02 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Mon, Sep 05, 2022 at 03:01:09PM +0100, Russell King (Oracle) wrote: ... > Oh, and another thing. Your behaviour on this is making me regret > trying to get involved in improving the upstream support for this > platform. Taking into account that technical aspects quite likely are not the cause, what did you expect to be different? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 14:42 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 14:42 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 5:02 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Mon, Sep 05, 2022 at 03:01:09PM +0100, Russell King (Oracle) wrote: ... > Oh, and another thing. Your behaviour on this is making me regret > trying to get involved in improving the upstream support for this > platform. Taking into account that technical aspects quite likely are not the cause, what did you expect to be different? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 14:42 ` Andy Shevchenko @ 2022-09-05 14:53 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 14:53 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 05:42:46PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 5:02 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Mon, Sep 05, 2022 at 03:01:09PM +0100, Russell King (Oracle) wrote: > > ... > > > Oh, and another thing. Your behaviour on this is making me regret > > trying to get involved in improving the upstream support for this > > platform. > > Taking into account that technical aspects quite likely are not the > cause, what did you expect to be different? How about the decency to wait for the Asahi developers to respond, which they now have - but I haven't read it yet. How about some understanding that I might not have all the answers. How about some understanding that the issue with the SMC Keys is bigger than just the one driver, and that cpu_to_whatever may not be appropriate. How about some understanding and patience on your part? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 14:53 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 14:53 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 05:42:46PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 5:02 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Mon, Sep 05, 2022 at 03:01:09PM +0100, Russell King (Oracle) wrote: > > ... > > > Oh, and another thing. Your behaviour on this is making me regret > > trying to get involved in improving the upstream support for this > > platform. > > Taking into account that technical aspects quite likely are not the > cause, what did you expect to be different? How about the decency to wait for the Asahi developers to respond, which they now have - but I haven't read it yet. How about some understanding that I might not have all the answers. How about some understanding that the issue with the SMC Keys is bigger than just the one driver, and that cpu_to_whatever may not be appropriate. How about some understanding and patience on your part? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 14:01 ` Russell King (Oracle) @ 2022-09-05 14:50 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 14:50 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 5:01 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: ... > > > Let me say again: I am not changing this. That's for Asahi people to > > > do if they wish. I am the just middle-man here. > > > > While I agree on technical aspects, this mythical "they" is > > frustrating me. They haven't participated in this discussion (yet?) so > > they do not care, why should we (as a community of upstream)? > > That's strange. I wonder. If they don't exist, then I wonder how Linus > is running Linux on aarch64 apple hardware. Maybe it's not me with a > problem here? You mentioned them several times in the thread and no response from them. > Hector has been promising to get involved in this discussion for a few > days now, his latest comment on IRC yesterday: IRC is not an email discussion and if he is not alone in the team, who else can answer the queries? But it's good that there is an interest from their side. > 16:23 <@marcan> I'm going to allocate tuesday to playing the merge game (rmk: > haven't forgotten about you either, IRQs today, but I'll get to > it before tuesday): > > So he is aware that he needs to respond - but like any central project > lead developer, he's probably exceedingly busy with other issues. > So, how about you stop insisting on changes until Hector can respond > to some of the questions raised; as I've said many times, you are > asking for stuff to be changed that is quite clearly in the realm of > decisions that the Asahi developer(s) have taken, and I have no right > to change them without reference to them - because I do not know this > platform well enough to make the decisions you're asking of me. > > I'm not going to say that again; I'm going to start ignoring you if > you persist in demanding that I make these kinds of decisions, because > *you* leave me no other option but to do that... because *you* just > don't seem to be willing to accept that I need others to be involved > in these decisions. If I spoke like this for all contributions, from our side to the upstream, I would become a crazy guy, because upstream almost always insists on some changes here and there in the patches which are longer than a couple of dozens of LoCs and more than a single in a series. It's normal practice to follow the latest available APIs in the kernel. Nevertheless, I told *you*, that technically I have no more issues. Let's wait for the technical response from them. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 14:50 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 14:50 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 5:01 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: ... > > > Let me say again: I am not changing this. That's for Asahi people to > > > do if they wish. I am the just middle-man here. > > > > While I agree on technical aspects, this mythical "they" is > > frustrating me. They haven't participated in this discussion (yet?) so > > they do not care, why should we (as a community of upstream)? > > That's strange. I wonder. If they don't exist, then I wonder how Linus > is running Linux on aarch64 apple hardware. Maybe it's not me with a > problem here? You mentioned them several times in the thread and no response from them. > Hector has been promising to get involved in this discussion for a few > days now, his latest comment on IRC yesterday: IRC is not an email discussion and if he is not alone in the team, who else can answer the queries? But it's good that there is an interest from their side. > 16:23 <@marcan> I'm going to allocate tuesday to playing the merge game (rmk: > haven't forgotten about you either, IRQs today, but I'll get to > it before tuesday): > > So he is aware that he needs to respond - but like any central project > lead developer, he's probably exceedingly busy with other issues. > So, how about you stop insisting on changes until Hector can respond > to some of the questions raised; as I've said many times, you are > asking for stuff to be changed that is quite clearly in the realm of > decisions that the Asahi developer(s) have taken, and I have no right > to change them without reference to them - because I do not know this > platform well enough to make the decisions you're asking of me. > > I'm not going to say that again; I'm going to start ignoring you if > you persist in demanding that I make these kinds of decisions, because > *you* leave me no other option but to do that... because *you* just > don't seem to be willing to accept that I need others to be involved > in these decisions. If I spoke like this for all contributions, from our side to the upstream, I would become a crazy guy, because upstream almost always insists on some changes here and there in the patches which are longer than a couple of dozens of LoCs and more than a single in a series. It's normal practice to follow the latest available APIs in the kernel. Nevertheless, I told *you*, that technically I have no more issues. Let's wait for the technical response from them. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 14:01 ` Russell King (Oracle) @ 2022-09-05 15:52 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:52 UTC (permalink / raw) To: Russell King (Oracle), Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 05/09/2022 23.01, Russell King (Oracle) wrote: > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: >> P.S. Do you have a platform to test all these? > > Yes, but that doesn't mean I can do testing sufficient to ensure that > the modifications are correct. As I understand things, the SMC is not > limited to just aarch64 hardware. FWIW, the RTKit backend is limited to aarch64 hardware, and that's also why I kept all the endian-munging there. T2 and legacy x86 backends (which don't exist yet, so whether things need changing for those platforms is an open question anyway) would respectively do whatever endian-munging is appropriate for them. So at this point, only Apple Mx AArch64 SoCs matter, though I *tried* to write the code in the way that I thought was most likely to cleanly transfer over to other SMC platforms by just changing the backend code. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:52 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:52 UTC (permalink / raw) To: Russell King (Oracle), Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 05/09/2022 23.01, Russell King (Oracle) wrote: > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: >> P.S. Do you have a platform to test all these? > > Yes, but that doesn't mean I can do testing sufficient to ensure that > the modifications are correct. As I understand things, the SMC is not > limited to just aarch64 hardware. FWIW, the RTKit backend is limited to aarch64 hardware, and that's also why I kept all the endian-munging there. T2 and legacy x86 backends (which don't exist yet, so whether things need changing for those platforms is an open question anyway) would respectively do whatever endian-munging is appropriate for them. So at this point, only Apple Mx AArch64 SoCs matter, though I *tried* to write the code in the way that I thought was most likely to cleanly transfer over to other SMC platforms by just changing the backend code. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 15:52 ` Hector Martin @ 2022-09-05 15:56 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 15:56 UTC (permalink / raw) To: Hector Martin Cc: Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Tue, Sep 06, 2022 at 12:52:48AM +0900, Hector Martin wrote: > On 05/09/2022 23.01, Russell King (Oracle) wrote: > > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > >> P.S. Do you have a platform to test all these? > > > > Yes, but that doesn't mean I can do testing sufficient to ensure that > > the modifications are correct. As I understand things, the SMC is not > > limited to just aarch64 hardware. > > FWIW, the RTKit backend is limited to aarch64 hardware, and that's also > why I kept all the endian-munging there. T2 and legacy x86 backends > (which don't exist yet, so whether things need changing for those > platforms is an open question anyway) would respectively do whatever > endian-munging is appropriate for them. > > So at this point, only Apple Mx AArch64 SoCs matter, though I *tried* to > write the code in the way that I thought was most likely to cleanly > transfer over to other SMC platforms by just changing the backend code. Right, and that's a good argument not to go and change the smc_key layout... that invites one hell of a big headache (also for the reasons you've set out in one of your previous replies.) I'm going to back out the hex2bin conversion; you've made a good argument why the code is the way it is. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:56 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 15:56 UTC (permalink / raw) To: Hector Martin Cc: Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Tue, Sep 06, 2022 at 12:52:48AM +0900, Hector Martin wrote: > On 05/09/2022 23.01, Russell King (Oracle) wrote: > > On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > >> P.S. Do you have a platform to test all these? > > > > Yes, but that doesn't mean I can do testing sufficient to ensure that > > the modifications are correct. As I understand things, the SMC is not > > limited to just aarch64 hardware. > > FWIW, the RTKit backend is limited to aarch64 hardware, and that's also > why I kept all the endian-munging there. T2 and legacy x86 backends > (which don't exist yet, so whether things need changing for those > platforms is an open question anyway) would respectively do whatever > endian-munging is appropriate for them. > > So at this point, only Apple Mx AArch64 SoCs matter, though I *tried* to > write the code in the way that I thought was most likely to cleanly > transfer over to other SMC platforms by just changing the backend code. Right, and that's a good argument not to go and change the smc_key layout... that invites one hell of a big headache (also for the reasons you've set out in one of your previous replies.) I'm going to back out the hex2bin conversion; you've made a good argument why the code is the way it is. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 13:16 ` Andy Shevchenko @ 2022-09-05 15:32 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 15:32 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > ... > > > Let me say again: I am not changing this. That's for Asahi people to > > do if they wish. I am the just middle-man here. > > While I agree on technical aspects, this mythical "they" is > frustrating me. They haven't participated in this discussion (yet?) so > they do not care, why should we (as a community of upstream)? > > P.S. Do you have a platform to test all these? Right, having addressed as many review comments as I possibly can, I've rebuilt and booted it on the platform - and the good news is, it still works _but_ I don't have enough support in the "mainline" kernel that I'm testing for anything to make use of any of the interrupt support in this patch set - so I can't actually test those changes. I'm going to drop the interrupt patch temporarily as it's unnecessary for what I want to do, which will be one less patch to worry about. I still need a resolution between you and Hector over the smc_key issue - specifically, do I pick up the patch that adds support for %p4ch, or do we re-architect the smc_key thing and also in doing so get rid of the need for your "endian conversion" thing. Given that Hector has rejected some of your comments, I now need to back out those changes that resulted from your NIH comments. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:32 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 15:32 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 04:16:27PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > ... > > > Let me say again: I am not changing this. That's for Asahi people to > > do if they wish. I am the just middle-man here. > > While I agree on technical aspects, this mythical "they" is > frustrating me. They haven't participated in this discussion (yet?) so > they do not care, why should we (as a community of upstream)? > > P.S. Do you have a platform to test all these? Right, having addressed as many review comments as I possibly can, I've rebuilt and booted it on the platform - and the good news is, it still works _but_ I don't have enough support in the "mainline" kernel that I'm testing for anything to make use of any of the interrupt support in this patch set - so I can't actually test those changes. I'm going to drop the interrupt patch temporarily as it's unnecessary for what I want to do, which will be one less patch to worry about. I still need a resolution between you and Hector over the smc_key issue - specifically, do I pick up the patch that adds support for %p4ch, or do we re-architect the smc_key thing and also in doing so get rid of the need for your "endian conversion" thing. Given that Hector has rejected some of your comments, I now need to back out those changes that resulted from your NIH comments. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 15:32 ` Russell King (Oracle) @ 2022-09-05 15:44 ` Martin Povišer -1 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-05 15:44 UTC (permalink / raw) To: Russell King (Oracle) Cc: Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter > On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > I still need a resolution between you and Hector over the smc_key > issue - specifically, do I pick up the patch that adds support for > %p4ch, or do we re-architect the smc_key thing and also in doing so > get rid of the need for your "endian conversion" thing. Idea about the %p4ch thing: We will leave the keys true to their nature (i.e. 32-bit integer), and at least initially for the prints we will employ macros #define SMC_KEYFMT “%c%c%c%c” #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) used like printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); This has the nice property that it is pretty much like the specifier, and later can be easily replaced with the real thing. -- Martin ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:44 ` Martin Povišer 0 siblings, 0 replies; 342+ messages in thread From: Martin Povišer @ 2022-09-05 15:44 UTC (permalink / raw) To: Russell King (Oracle) Cc: Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter > On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > I still need a resolution between you and Hector over the smc_key > issue - specifically, do I pick up the patch that adds support for > %p4ch, or do we re-architect the smc_key thing and also in doing so > get rid of the need for your "endian conversion" thing. Idea about the %p4ch thing: We will leave the keys true to their nature (i.e. 32-bit integer), and at least initially for the prints we will employ macros #define SMC_KEYFMT “%c%c%c%c” #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) used like printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); This has the nice property that it is pretty much like the specifier, and later can be easily replaced with the real thing. -- Martin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 15:44 ` Martin Povišer @ 2022-09-05 15:58 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:58 UTC (permalink / raw) To: Martin Povišer, Russell King (Oracle) Cc: Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 06/09/2022 00.44, Martin Povišer wrote: > >> On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > >> I still need a resolution between you and Hector over the smc_key >> issue - specifically, do I pick up the patch that adds support for >> %p4ch, or do we re-architect the smc_key thing and also in doing so >> get rid of the need for your "endian conversion" thing. > > Idea about the %p4ch thing: We will leave the keys true > to their nature (i.e. 32-bit integer), and at least initially > for the prints we will employ macros > > #define SMC_KEYFMT “%c%c%c%c” > #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) > > used like > > printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); > > This has the nice property that it is pretty much like the specifier, > and later can be easily replaced with the real thing. Not the prettiest, but I'll take this over trying to mess around with string buffer conversions or anything involving non-native endianness if the printk specifier patch is going to be controversial. I'd prefer shorter macro names though, like SMC_KFMT/SMC_KVAL(), to avoid further lengthening already-long printk lines. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:58 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:58 UTC (permalink / raw) To: Martin Povišer, Russell King (Oracle) Cc: Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 06/09/2022 00.44, Martin Povišer wrote: > >> On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > >> I still need a resolution between you and Hector over the smc_key >> issue - specifically, do I pick up the patch that adds support for >> %p4ch, or do we re-architect the smc_key thing and also in doing so >> get rid of the need for your "endian conversion" thing. > > Idea about the %p4ch thing: We will leave the keys true > to their nature (i.e. 32-bit integer), and at least initially > for the prints we will employ macros > > #define SMC_KEYFMT “%c%c%c%c” > #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) > > used like > > printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); > > This has the nice property that it is pretty much like the specifier, > and later can be easily replaced with the real thing. Not the prettiest, but I'll take this over trying to mess around with string buffer conversions or anything involving non-native endianness if the printk specifier patch is going to be controversial. I'd prefer shorter macro names though, like SMC_KFMT/SMC_KVAL(), to avoid further lengthening already-long printk lines. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 15:58 ` Hector Martin @ 2022-09-05 16:13 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 16:13 UTC (permalink / raw) To: Hector Martin Cc: Martin Povišer, Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Tue, Sep 06, 2022 at 12:58:48AM +0900, Hector Martin wrote: > On 06/09/2022 00.44, Martin Povišer wrote: > > > >> On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > > >> I still need a resolution between you and Hector over the smc_key > >> issue - specifically, do I pick up the patch that adds support for > >> %p4ch, or do we re-architect the smc_key thing and also in doing so > >> get rid of the need for your "endian conversion" thing. > > > > Idea about the %p4ch thing: We will leave the keys true > > to their nature (i.e. 32-bit integer), and at least initially > > for the prints we will employ macros > > > > #define SMC_KEYFMT “%c%c%c%c” > > #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) > > > > used like > > > > printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); > > > > This has the nice property that it is pretty much like the specifier, > > and later can be easily replaced with the real thing. > > Not the prettiest, but I'll take this over trying to mess around with > string buffer conversions or anything involving non-native endianness if > the printk specifier patch is going to be controversial. > > I'd prefer shorter macro names though, like SMC_KFMT/SMC_KVAL(), to > avoid further lengthening already-long printk lines. I suggest that I try resubmitting the series with IRQ support dropped, and with the %p4ch support in it and we'll see what happens. If %p4ch gets accepted, then changing it would be adding extra work. In any case, these %p... format extensions are supposed to avoid yucky stuff such as the above. Andy's objection to %p4ch was predicated on using the illegal C of &cpu_to_be32(key) which has been shown to have been a waste of time. For reference for those reading this, %p4ch doesn't print only print the key as characters, it prints the hex value as well. For example: macsmc-rtkit 23e400000.smc: Initialized (922 keys #KEY (0x234b4559)..zETM (0x7a45544d)) ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ macsmc-gpio macsmc-gpio: First GPIO key: gP01 (0x67503031) ^^^^^^^^^^^^^^^^^ The underlined strings is the output from %p4ch. So, even if Andy's cpu_to_be32() idea was legal C, it wouldn't be functionally the same without adding extra code to every place that one of these keys is printed. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 16:13 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 16:13 UTC (permalink / raw) To: Hector Martin Cc: Martin Povišer, Andy Shevchenko, Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Tue, Sep 06, 2022 at 12:58:48AM +0900, Hector Martin wrote: > On 06/09/2022 00.44, Martin Povišer wrote: > > > >> On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > > >> I still need a resolution between you and Hector over the smc_key > >> issue - specifically, do I pick up the patch that adds support for > >> %p4ch, or do we re-architect the smc_key thing and also in doing so > >> get rid of the need for your "endian conversion" thing. > > > > Idea about the %p4ch thing: We will leave the keys true > > to their nature (i.e. 32-bit integer), and at least initially > > for the prints we will employ macros > > > > #define SMC_KEYFMT “%c%c%c%c” > > #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) > > > > used like > > > > printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); > > > > This has the nice property that it is pretty much like the specifier, > > and later can be easily replaced with the real thing. > > Not the prettiest, but I'll take this over trying to mess around with > string buffer conversions or anything involving non-native endianness if > the printk specifier patch is going to be controversial. > > I'd prefer shorter macro names though, like SMC_KFMT/SMC_KVAL(), to > avoid further lengthening already-long printk lines. I suggest that I try resubmitting the series with IRQ support dropped, and with the %p4ch support in it and we'll see what happens. If %p4ch gets accepted, then changing it would be adding extra work. In any case, these %p... format extensions are supposed to avoid yucky stuff such as the above. Andy's objection to %p4ch was predicated on using the illegal C of &cpu_to_be32(key) which has been shown to have been a waste of time. For reference for those reading this, %p4ch doesn't print only print the key as characters, it prints the hex value as well. For example: macsmc-rtkit 23e400000.smc: Initialized (922 keys #KEY (0x234b4559)..zETM (0x7a45544d)) ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ macsmc-gpio macsmc-gpio: First GPIO key: gP01 (0x67503031) ^^^^^^^^^^^^^^^^^ The underlined strings is the output from %p4ch. So, even if Andy's cpu_to_be32() idea was legal C, it wouldn't be functionally the same without adding extra code to every place that one of these keys is printed. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 16:13 ` Russell King (Oracle) @ 2022-09-05 19:10 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-05 19:10 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Martin Povišer, Andy Shevchenko, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 6:13 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > I suggest that I try resubmitting the series with IRQ support dropped, > and with the %p4ch support in it and we'll see what happens. You can add my Reviewed-by: Linus Walleij <linus.walleij@linaro.org> on the result, and the code should go in when Hector & you are happy with it. I surely trust you to fix the final polish. I don't mind the IRQ patch either, but I understand it's a bit annoying if you can't test it on anything. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 19:10 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-05 19:10 UTC (permalink / raw) To: Russell King (Oracle) Cc: Hector Martin, Martin Povišer, Andy Shevchenko, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 6:13 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > I suggest that I try resubmitting the series with IRQ support dropped, > and with the %p4ch support in it and we'll see what happens. You can add my Reviewed-by: Linus Walleij <linus.walleij@linaro.org> on the result, and the code should go in when Hector & you are happy with it. I surely trust you to fix the final polish. I don't mind the IRQ patch either, but I understand it's a bit annoying if you can't test it on anything. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 19:10 ` Linus Walleij @ 2022-09-06 6:51 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 6:51 UTC (permalink / raw) To: Linus Walleij, Russell King (Oracle) Cc: Martin Povišer, Andy Shevchenko, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 06/09/2022 04.10, Linus Walleij wrote: > On Mon, Sep 5, 2022 at 6:13 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > >> I suggest that I try resubmitting the series with IRQ support dropped, >> and with the %p4ch support in it and we'll see what happens. > > You can add my > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > on the result, and the code should go in when Hector & you are > happy with it. I surely trust you to fix the final polish. > > I don't mind the IRQ patch either, but I understand it's a bit > annoying if you can't test it on anything. Thank you! FWIW, I wrote that commit as part of working on PCIe power saving and the SD card reader specifically, where the SMC GPIO card detect pin can replace the internal card detect, and this allows us to completely power down the SD card reader when there is no card inserted. But that PCIe power management code isn't anywhere near done yet, I just tested that using the SMC card detect IRQ works as expected with sdhci-pci. So it's perfectly fine to hold off on that patch until later, and submit it once we've actually been using it downstream for a bit and it gets some testing. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-06 6:51 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 6:51 UTC (permalink / raw) To: Linus Walleij, Russell King (Oracle) Cc: Martin Povišer, Andy Shevchenko, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 06/09/2022 04.10, Linus Walleij wrote: > On Mon, Sep 5, 2022 at 6:13 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > >> I suggest that I try resubmitting the series with IRQ support dropped, >> and with the %p4ch support in it and we'll see what happens. > > You can add my > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > on the result, and the code should go in when Hector & you are > happy with it. I surely trust you to fix the final polish. > > I don't mind the IRQ patch either, but I understand it's a bit > annoying if you can't test it on anything. Thank you! FWIW, I wrote that commit as part of working on PCIe power saving and the SD card reader specifically, where the SMC GPIO card detect pin can replace the internal card detect, and this allows us to completely power down the SD card reader when there is no card inserted. But that PCIe power management code isn't anywhere near done yet, I just tested that using the SMC card detect IRQ works as expected with sdhci-pci. So it's perfectly fine to hold off on that patch until later, and submit it once we've actually been using it downstream for a bit and it gets some testing. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 13:16 ` Andy Shevchenko @ 2022-09-05 15:47 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:47 UTC (permalink / raw) To: Andy Shevchenko, Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 05/09/2022 22.16, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: >> On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > ... > >> Let me say again: I am not changing this. That's for Asahi people to >> do if they wish. I am the just middle-man here. > > While I agree on technical aspects, this mythical "they" is > frustrating me. They haven't participated in this discussion (yet?) so > they do not care, why should we (as a community of upstream)? Hi Andy, This was submitted 4 days before your comment, 2 of which were the weekend. Not all of us spend our weekends reviewing patches. Russell graciously volunteered to help upstream this patchset and I hadn't had a chance to reply yet. I would appreciate it if you don't accuse us of "not caring", or I might have to start pointing out upstreaming attempts by us that were ignored by the respective maintainers for *months*, not 4 days. Glass houses and throwing stones and all that. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:47 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:47 UTC (permalink / raw) To: Andy Shevchenko, Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 05/09/2022 22.16, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 4:10 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: >> On Mon, Sep 05, 2022 at 01:32:29PM +0300, Andy Shevchenko wrote: > > ... > >> Let me say again: I am not changing this. That's for Asahi people to >> do if they wish. I am the just middle-man here. > > While I agree on technical aspects, this mythical "they" is > frustrating me. They haven't participated in this discussion (yet?) so > they do not care, why should we (as a community of upstream)? Hi Andy, This was submitted 4 days before your comment, 2 of which were the weekend. Not all of us spend our weekends reviewing patches. Russell graciously volunteered to help upstream this patchset and I hadn't had a chance to reply yet. I would appreciate it if you don't accuse us of "not caring", or I might have to start pointing out upstreaming attempts by us that were ignored by the respective maintainers for *months*, not 4 days. Glass houses and throwing stones and all that. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-05 10:20 ` Russell King (Oracle) @ 2022-09-05 15:39 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:39 UTC (permalink / raw) To: Russell King (Oracle), Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 05/09/2022 19.20, Russell King (Oracle) wrote: > So, I'm going with my first suggestion for the hex2bin() conversion > above, and adding a comment thusly: > > /* > * The most significant nibble comes from k[0] and key bits 15..8 > * The least significant nibble comes from k[1] and key bits 7..0 > */ > k[0] = key >> 8; > k[1] = key; > > because I needed the comment to prove to myself that I wasn't breaking > this code. Maybe it's obvious to you, but it isn't obvious to everyone. Honestly, I don't see what this buys us over the original code. It's longer, no more readable, makes you think about the order that characters are stored in the string as an extra indirection step, which as as you found out with having to write the comment, is easy to get backwards. But I will say it is at least *semantically* correct, if awkward. Let's back up and talk a bit about SMC keys for a second. First, SMC is a legacy mess and plays around with endianness wrong in several places - there are values which are in wrong-endian for no reason, etc. So any discussion over "what would happen on a big-endian platform" is ultimately speculation. If this ever ends up running on some ancient PowerPC Mac (did any of those ever ship with an SMC that followed these semantics?) then we'll have to deal with the endianness issues then and correct any incorrect assumptions, because right now we just don't have the information on what Apple's *intent* was when designing this whole thing, if there was an intent at all. That said. When I designed this driver, and the way I understand the hardware, I consider SMC keys to be 32-bit integers containing packed ASCII characters in natural integer order, that is, 0xAABBCCDD representing the fourcc ABCD in that order. The SMC backend is designed with this in mind, and puts things in the right endian in the right contexts when it comes to the actual interface with the SMC coprocessor (which is, itself, a mix of shared memory - which is a bag of bytes - and 64-bit mailbox messages - which are fundamentally integers and merely represented in little-endian at the hardware level - so I'm sure how you can see how this gets interesting). In other words, at the driver level, *SMC keys are not character strings, nor integers stored in some byte order*. They are integers. Integers do not have a byte order until they are stored to memory. Therefore, using functions that operate on strings on SMC keys is wrong, and requires you to make a trip through endian-land to get it right (as you found out). Making the representation of SMC keys in the driver 32-bit integers makes manipulating them easier and ergonomic in C, and allows for things like comparisons (look at how the GPIO code uses < to compare SMC keys, which maps to ASCIIbetical sort the way the keys are naturally encoded), while basically relegating all the endian issues to the SMC core. For comparison, if the data structure were a char[4] in reading order, there would be no ergonomic way to do comparisons without some helper function/macro. And comparisons are used quite a bit as part of the self-discovery aspects of SMC (there's that binary search function to find key indices, which also took like 4 tries to get right... please don't break it! :). This is why I added a printk specifier, because V4L/etc already had a very special-purpose specifier with fancy rules just for them, and I think a generic FOURCC style format specifier that works in any context is useful (this isn't the only driver dealing with this kind of FOURCC-style construct). The printk patch in particular adds 4 variations to the existing v4l specifier that that interpret endianness differently, so it can be used in any context (in this context, the specifier is 'h' which means 'host endian' and is the correct specifier for abstract integers, which are passed by reference in this case and therefore inherit the host endianness). - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:39 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:39 UTC (permalink / raw) To: Russell King (Oracle), Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 05/09/2022 19.20, Russell King (Oracle) wrote: > So, I'm going with my first suggestion for the hex2bin() conversion > above, and adding a comment thusly: > > /* > * The most significant nibble comes from k[0] and key bits 15..8 > * The least significant nibble comes from k[1] and key bits 7..0 > */ > k[0] = key >> 8; > k[1] = key; > > because I needed the comment to prove to myself that I wasn't breaking > this code. Maybe it's obvious to you, but it isn't obvious to everyone. Honestly, I don't see what this buys us over the original code. It's longer, no more readable, makes you think about the order that characters are stored in the string as an extra indirection step, which as as you found out with having to write the comment, is easy to get backwards. But I will say it is at least *semantically* correct, if awkward. Let's back up and talk a bit about SMC keys for a second. First, SMC is a legacy mess and plays around with endianness wrong in several places - there are values which are in wrong-endian for no reason, etc. So any discussion over "what would happen on a big-endian platform" is ultimately speculation. If this ever ends up running on some ancient PowerPC Mac (did any of those ever ship with an SMC that followed these semantics?) then we'll have to deal with the endianness issues then and correct any incorrect assumptions, because right now we just don't have the information on what Apple's *intent* was when designing this whole thing, if there was an intent at all. That said. When I designed this driver, and the way I understand the hardware, I consider SMC keys to be 32-bit integers containing packed ASCII characters in natural integer order, that is, 0xAABBCCDD representing the fourcc ABCD in that order. The SMC backend is designed with this in mind, and puts things in the right endian in the right contexts when it comes to the actual interface with the SMC coprocessor (which is, itself, a mix of shared memory - which is a bag of bytes - and 64-bit mailbox messages - which are fundamentally integers and merely represented in little-endian at the hardware level - so I'm sure how you can see how this gets interesting). In other words, at the driver level, *SMC keys are not character strings, nor integers stored in some byte order*. They are integers. Integers do not have a byte order until they are stored to memory. Therefore, using functions that operate on strings on SMC keys is wrong, and requires you to make a trip through endian-land to get it right (as you found out). Making the representation of SMC keys in the driver 32-bit integers makes manipulating them easier and ergonomic in C, and allows for things like comparisons (look at how the GPIO code uses < to compare SMC keys, which maps to ASCIIbetical sort the way the keys are naturally encoded), while basically relegating all the endian issues to the SMC core. For comparison, if the data structure were a char[4] in reading order, there would be no ergonomic way to do comparisons without some helper function/macro. And comparisons are used quite a bit as part of the self-discovery aspects of SMC (there's that binary search function to find key indices, which also took like 4 tries to get right... please don't break it! :). This is why I added a printk specifier, because V4L/etc already had a very special-purpose specifier with fancy rules just for them, and I think a generic FOURCC style format specifier that works in any context is useful (this isn't the only driver dealing with this kind of FOURCC-style construct). The printk patch in particular adds 4 variations to the existing v4l specifier that that interpret endianness differently, so it can be used in any context (in this context, the specifier is 'h' which means 'host endian' and is the correct specifier for abstract integers, which are passed by reference in this case and therefore inherit the host endianness). - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-02 10:05 ` Russell King (Oracle) @ 2022-09-05 15:16 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:16 UTC (permalink / raw) To: Russell King (Oracle), Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter, Rob Herring On 02/09/2022 19.05, Russell King (Oracle) wrote: > but even that isn't _that_ nice. I'd like to hear comments from the Asahi > folk about whether these sub-blocks of the SMC can have compatibles, so > that the MFD layer can automatically fill in the firmware nodes on the > struct device before the probe function gets called. I'm fine with adding compatibles if this makes the of/fwnode handling simpler. However, keep in mind these aren't hardware, they're effectively software services implemented in a coprocessor. The idea behind not having compatibles was that the SMC stuff should be self-discovering enough that it can decide what's available and not at runtime, and that the SMC core needs to probe before the child devices anyway, so it's not like this can be a simple-bus. But I'm new to the MFD subsystem, so if compatibles make life easier, sure. Personally, I'd defer to Rob's opinon on this (CC'ed), since he has the last word on DT bindings :). - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:16 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:16 UTC (permalink / raw) To: Russell King (Oracle), Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter, Rob Herring On 02/09/2022 19.05, Russell King (Oracle) wrote: > but even that isn't _that_ nice. I'd like to hear comments from the Asahi > folk about whether these sub-blocks of the SMC can have compatibles, so > that the MFD layer can automatically fill in the firmware nodes on the > struct device before the probe function gets called. I'm fine with adding compatibles if this makes the of/fwnode handling simpler. However, keep in mind these aren't hardware, they're effectively software services implemented in a coprocessor. The idea behind not having compatibles was that the SMC stuff should be self-discovering enough that it can decide what's available and not at runtime, and that the SMC core needs to probe before the child devices anyway, so it's not like this can be a simple-bus. But I'm new to the MFD subsystem, so if compatibles make life easier, sure. Personally, I'd defer to Rob's opinon on this (CC'ed), since he has the last word on DT bindings :). - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 18:55 ` Andy Shevchenko @ 2022-09-05 15:04 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:04 UTC (permalink / raw) To: Andy Shevchenko, Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 02/09/2022 03.55, Andy Shevchenko wrote: >> +struct macsmc_gpio { >> + struct device *dev; >> + struct apple_smc *smc; >> + struct gpio_chip gc; > > You might save some CPU cycles / code by shuffling members around. > Usually we put gpio_chip as a first one, so pointer arithmetics to get > it becomes a bit simpler, but it needs to be checked by the tool and > also paying attention to what is used in critical paths (so > performance-wise). This is a GPIO chip accessed via a remote CPU. Saving two cycles on pointer arithmetic is the very definition of premature optimization. > >> + int first_index; >> +}; > > ... > >> +static int macsmc_gpio_nr(smc_key key) >> +{ >> + int low = hex_to_bin(key & 0xff); >> + int high = hex_to_bin((key >> 8) & 0xff); >> + >> + if (low < 0 || high < 0) >> + return -1; >> + >> + return low | (high << 4); >> +} > > NIH hex2bin(). No. hex2bin() works on string buffers. This works on an integer containing packed characters. They are not the same, and do not have the same semantics endian-wise. Integer represent numbers abstractly, byte buffers represent bytes in memory in sequence. >> +static int macsmc_gpio_key(unsigned int offset) >> +{ >> + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); >> +} > > NIH hex_byte_pack(). Same comment as above. >> + /* First try reading the explicit pin mode register */ >> + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); >> + if (!ret) >> + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; >> + >> + /* >> + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. >> + * Fall back to reading IRQ mode, which will only succeed for inputs. >> + */ >> + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); >> + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > What is the meaning of val in this case? Have you tried reading the comment above the code? When I write code doing something unintuitive and put a comment on top, I expect reviewers to *read* it. If you're not going to do that, I might as well stop writing comments. > Strange specifier... It seems like a hashed pointer with added (or > skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', > '%p4cc'? > Ditto for other cases. As mentioned in the other thread, there was a missed dependency that added this specifier. > >> + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); >> + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; > > I would split this assignment and move it closer to the first user. It is one line away from the first user. > >> + int i; >> + >> + if (count > MAX_GPIO) >> + count = MAX_GPIO; > > Hmm... When can it be the case? Let's find out! Two lines above: + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; So I get the toal SMC key count, which is probably 1000 or so, then subtract the index of the first GPIO key, to get an upper bound on the last GPIO key just to make sure we don't run off the end of the key list. In other words, pretty much always. But you didn't read two lines prior, did you. > >> + bitmap_zero(valid_mask, ngpios); >> + >> + for (i = 0; i < count; i++) { >> + smc_key key; >> + int gpio_nr; > >> + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > Ditto. This is zero lines away from the first user. > >> + >> + if (ret < 0) >> + return ret; >> + >> + if (key > SMC_KEY(gPff)) >> + break; >> + >> + gpio_nr = macsmc_gpio_nr(key); >> + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { >> + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); > > Yeah, according to the code it will print something you didn't want. What? >> + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > Can we use fwnode APIs instead? > Or do you really need this? This is a producer, not a consumer. It needs to set the of_node so there is something for consumers to target in the device tree. The consumers may well use fwnode APIs. - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-05 15:04 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-05 15:04 UTC (permalink / raw) To: Andy Shevchenko, Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On 02/09/2022 03.55, Andy Shevchenko wrote: >> +struct macsmc_gpio { >> + struct device *dev; >> + struct apple_smc *smc; >> + struct gpio_chip gc; > > You might save some CPU cycles / code by shuffling members around. > Usually we put gpio_chip as a first one, so pointer arithmetics to get > it becomes a bit simpler, but it needs to be checked by the tool and > also paying attention to what is used in critical paths (so > performance-wise). This is a GPIO chip accessed via a remote CPU. Saving two cycles on pointer arithmetic is the very definition of premature optimization. > >> + int first_index; >> +}; > > ... > >> +static int macsmc_gpio_nr(smc_key key) >> +{ >> + int low = hex_to_bin(key & 0xff); >> + int high = hex_to_bin((key >> 8) & 0xff); >> + >> + if (low < 0 || high < 0) >> + return -1; >> + >> + return low | (high << 4); >> +} > > NIH hex2bin(). No. hex2bin() works on string buffers. This works on an integer containing packed characters. They are not the same, and do not have the same semantics endian-wise. Integer represent numbers abstractly, byte buffers represent bytes in memory in sequence. >> +static int macsmc_gpio_key(unsigned int offset) >> +{ >> + return _SMC_KEY("gP\0\0") | (hex_asc_hi(offset) << 8) | hex_asc_lo(offset); >> +} > > NIH hex_byte_pack(). Same comment as above. >> + /* First try reading the explicit pin mode register */ >> + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); >> + if (!ret) >> + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; >> + >> + /* >> + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. >> + * Fall back to reading IRQ mode, which will only succeed for inputs. >> + */ >> + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); >> + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT; > > What is the meaning of val in this case? Have you tried reading the comment above the code? When I write code doing something unintuitive and put a comment on top, I expect reviewers to *read* it. If you're not going to do that, I might as well stop writing comments. > Strange specifier... It seems like a hashed pointer with added (or > skipped? I don't remember) '4ch'. Perhaps you meant one of '%pE', > '%p4cc'? > Ditto for other cases. As mentioned in the other thread, there was a missed dependency that added this specifier. > >> + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); >> + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; > > I would split this assignment and move it closer to the first user. It is one line away from the first user. > >> + int i; >> + >> + if (count > MAX_GPIO) >> + count = MAX_GPIO; > > Hmm... When can it be the case? Let's find out! Two lines above: + int count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; So I get the toal SMC key count, which is probably 1000 or so, then subtract the index of the first GPIO key, to get an upper bound on the last GPIO key just to make sure we don't run off the end of the key list. In other words, pretty much always. But you didn't read two lines prior, did you. > >> + bitmap_zero(valid_mask, ngpios); >> + >> + for (i = 0; i < count; i++) { >> + smc_key key; >> + int gpio_nr; > >> + int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > Ditto. This is zero lines away from the first user. > >> + >> + if (ret < 0) >> + return ret; >> + >> + if (key > SMC_KEY(gPff)) >> + break; >> + >> + gpio_nr = macsmc_gpio_nr(key); >> + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { >> + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); > > Yeah, according to the code it will print something you didn't want. What? >> + pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); > > Can we use fwnode APIs instead? > Or do you really need this? This is a producer, not a consumer. It needs to set the of_node so there is something for consumers to target in the device tree. The consumers may well use fwnode APIs. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs 2022-09-01 13:54 ` Russell King @ 2022-09-02 9:42 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-02 9:42 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements the GPIO service on top of the SMC framework > on Apple Mac machines. In particular, these are the GPIOs present in the > PMU IC which are used to control power to certain on-board devices. > > Although the underlying hardware supports various pin config settings > (input/output, open drain, etc.), this driver does not implement that > functionality and leaves it up to the firmware to configure things > properly. We also don't yet support interrupts/events. This is > sufficient for device power control, which is the only thing we need to > support at this point. More features will be implemented when needed. > > To our knowledge, only Apple Silicon Macs implement this SMC feature. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Overall this looks very good provided the SMC API is fine with the platform/MFD maintainers, I like the usage of .init_valid_mask which is used just as intended. Andy's detailed review points should be addressed reasonably after that it's: Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-09-02 9:42 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-02 9:42 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements the GPIO service on top of the SMC framework > on Apple Mac machines. In particular, these are the GPIOs present in the > PMU IC which are used to control power to certain on-board devices. > > Although the underlying hardware supports various pin config settings > (input/output, open drain, etc.), this driver does not implement that > functionality and leaves it up to the firmware to configure things > properly. We also don't yet support interrupts/events. This is > sufficient for device power control, which is the only thing we need to > support at this point. More features will be implemented when needed. > > To our knowledge, only Apple Silicon Macs implement this SMC feature. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Overall this looks very good provided the SMC API is fine with the platform/MFD maintainers, I like the usage of .init_valid_mask which is used just as intended. Andy's detailed review points should be addressed reasonably after that it's: Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 13:54 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> Add IRQ support to the macsmc driver. This patch has updates from Joey Gouly and Russell King. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/gpio/gpio-macsmc.c | 156 +++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) diff --git a/drivers/gpio/gpio-macsmc.c b/drivers/gpio/gpio-macsmc.c index ff9950afb69a..939e2dc33c6f 100644 --- a/drivers/gpio/gpio-macsmc.c +++ b/drivers/gpio/gpio-macsmc.c @@ -10,6 +10,7 @@ #include <linux/bitmap.h> #include <linux/device.h> #include <linux/gpio/driver.h> +#include <linux/irq.h> #include <linux/mfd/core.h> #include <linux/mfd/macsmc.h> @@ -68,10 +69,20 @@ * 3 = ? */ +#define SMC_EV_GPIO 0x7202 + struct macsmc_gpio { struct device *dev; struct apple_smc *smc; struct gpio_chip gc; + struct notifier_block nb; + + struct mutex irq_mutex; + DECLARE_BITMAP(irq_supported, MAX_GPIO); + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); + DECLARE_BITMAP(irq_enable, MAX_GPIO); + u32 irq_mode_shadow[MAX_GPIO]; + u32 irq_mode[MAX_GPIO]; int first_index; }; @@ -161,6 +172,7 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, for (i = 0; i < count; i++) { smc_key key; int gpio_nr; + u32 val; int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); if (ret < 0) @@ -176,11 +188,143 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, } set_bit(gpio_nr, valid_mask); + + /* Check for IRQ support */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); + if (!ret) + set_bit(gpio_nr, smcgp->irq_supported); + } + + return 0; +} + +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) +{ + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); + u16 type = event >> 16; + u8 offset = (event >> 8) & 0xff; + smc_key key = macsmc_gpio_key(offset); + unsigned long flags; + int ret; + + if (type != SMC_EV_GPIO) + return NOTIFY_DONE; + + if (offset > MAX_GPIO) { + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); + return NOTIFY_BAD; + } + + local_irq_save(flags); + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); + local_irq_restore(flags); + + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); + + return (ret == 0) ? NOTIFY_OK : NOTIFY_DONE; +} + +static void macsmc_gpio_irq_enable(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + + gpiochip_enable_irq(gc, irqd_to_hwirq(d)); + set_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); +} + +static void macsmc_gpio_irq_disable(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + + clear_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); + gpiochip_disable_irq(gc, irqd_to_hwirq(d)); +} + +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + int offset = irqd_to_hwirq(d); + u32 mode; + + if (!test_bit(offset, smcgp->irq_supported)) + return -EINVAL; + + switch (type & IRQ_TYPE_SENSE_MASK) { + case IRQ_TYPE_LEVEL_HIGH: + mode = IRQ_MODE_HIGH; + break; + case IRQ_TYPE_LEVEL_LOW: + mode = IRQ_MODE_LOW; + break; + case IRQ_TYPE_EDGE_RISING: + mode = IRQ_MODE_RISING; + break; + case IRQ_TYPE_EDGE_FALLING: + mode = IRQ_MODE_FALLING; + break; + case IRQ_TYPE_EDGE_BOTH: + mode = IRQ_MODE_BOTH; + break; + default: + return -EINVAL; } + smcgp->irq_mode_shadow[offset] = mode; return 0; } +static void macsmc_gpio_irq_bus_lock(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + + mutex_lock(&smcgp->irq_mutex); +} + +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); + int offset = irqd_to_hwirq(d); + bool val; + + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); + else + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; + } + + val = test_bit(offset, smcgp->irq_enable_shadow); + if (test_bit(offset, smcgp->irq_enable) != val) { + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ENABLE | val) < 0) + dev_err(smcgp->dev, "GPIO IRQ en/disable failed for %p4ch\n", &key); + else + change_bit(offset, smcgp->irq_enable); + } + + mutex_unlock(&smcgp->irq_mutex); +} + +static const struct irq_chip macsmc_gpio_irqchip = { + .name = "macsmc-pmu-gpio", + .irq_mask = macsmc_gpio_irq_disable, + .irq_unmask = macsmc_gpio_irq_enable, + .irq_set_type = macsmc_gpio_irq_set_type, + .irq_bus_lock = macsmc_gpio_irq_bus_lock, + .irq_bus_sync_unlock = macsmc_gpio_irq_bus_sync_unlock, + .irq_set_type = macsmc_gpio_irq_set_type, + .flags = IRQCHIP_SET_TYPE_MASKED | + IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_IMMUTABLE, + GPIOCHIP_IRQ_RESOURCE_HELPERS, +}; + static int macsmc_gpio_probe(struct platform_device *pdev) { struct macsmc_gpio *smcgp; @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) smcgp->gc.base = -1; smcgp->gc.parent = &pdev->dev; + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); + smcgp->gc.irq.parent_handler = NULL; + smcgp->gc.irq.num_parents = 0; + smcgp->gc.irq.parents = NULL; + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; + smcgp->gc.irq.handler = handle_simple_irq; + + mutex_init(&smcgp->irq_mutex); + + smcgp->nb.notifier_call = macsmc_gpio_event; + apple_smc_register_notifier(smc, &smcgp->nb); + return devm_gpiochip_add_data(&pdev->dev, &smcgp->gc, smcgp); } -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-01 13:54 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-09-01 13:54 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter From: Hector Martin <marcan@marcan.st> Add IRQ support to the macsmc driver. This patch has updates from Joey Gouly and Russell King. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/gpio/gpio-macsmc.c | 156 +++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) diff --git a/drivers/gpio/gpio-macsmc.c b/drivers/gpio/gpio-macsmc.c index ff9950afb69a..939e2dc33c6f 100644 --- a/drivers/gpio/gpio-macsmc.c +++ b/drivers/gpio/gpio-macsmc.c @@ -10,6 +10,7 @@ #include <linux/bitmap.h> #include <linux/device.h> #include <linux/gpio/driver.h> +#include <linux/irq.h> #include <linux/mfd/core.h> #include <linux/mfd/macsmc.h> @@ -68,10 +69,20 @@ * 3 = ? */ +#define SMC_EV_GPIO 0x7202 + struct macsmc_gpio { struct device *dev; struct apple_smc *smc; struct gpio_chip gc; + struct notifier_block nb; + + struct mutex irq_mutex; + DECLARE_BITMAP(irq_supported, MAX_GPIO); + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); + DECLARE_BITMAP(irq_enable, MAX_GPIO); + u32 irq_mode_shadow[MAX_GPIO]; + u32 irq_mode[MAX_GPIO]; int first_index; }; @@ -161,6 +172,7 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, for (i = 0; i < count; i++) { smc_key key; int gpio_nr; + u32 val; int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); if (ret < 0) @@ -176,11 +188,143 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, } set_bit(gpio_nr, valid_mask); + + /* Check for IRQ support */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); + if (!ret) + set_bit(gpio_nr, smcgp->irq_supported); + } + + return 0; +} + +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) +{ + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); + u16 type = event >> 16; + u8 offset = (event >> 8) & 0xff; + smc_key key = macsmc_gpio_key(offset); + unsigned long flags; + int ret; + + if (type != SMC_EV_GPIO) + return NOTIFY_DONE; + + if (offset > MAX_GPIO) { + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); + return NOTIFY_BAD; + } + + local_irq_save(flags); + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); + local_irq_restore(flags); + + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); + + return (ret == 0) ? NOTIFY_OK : NOTIFY_DONE; +} + +static void macsmc_gpio_irq_enable(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + + gpiochip_enable_irq(gc, irqd_to_hwirq(d)); + set_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); +} + +static void macsmc_gpio_irq_disable(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + + clear_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); + gpiochip_disable_irq(gc, irqd_to_hwirq(d)); +} + +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + int offset = irqd_to_hwirq(d); + u32 mode; + + if (!test_bit(offset, smcgp->irq_supported)) + return -EINVAL; + + switch (type & IRQ_TYPE_SENSE_MASK) { + case IRQ_TYPE_LEVEL_HIGH: + mode = IRQ_MODE_HIGH; + break; + case IRQ_TYPE_LEVEL_LOW: + mode = IRQ_MODE_LOW; + break; + case IRQ_TYPE_EDGE_RISING: + mode = IRQ_MODE_RISING; + break; + case IRQ_TYPE_EDGE_FALLING: + mode = IRQ_MODE_FALLING; + break; + case IRQ_TYPE_EDGE_BOTH: + mode = IRQ_MODE_BOTH; + break; + default: + return -EINVAL; } + smcgp->irq_mode_shadow[offset] = mode; return 0; } +static void macsmc_gpio_irq_bus_lock(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + + mutex_lock(&smcgp->irq_mutex); +} + +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); + int offset = irqd_to_hwirq(d); + bool val; + + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); + else + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; + } + + val = test_bit(offset, smcgp->irq_enable_shadow); + if (test_bit(offset, smcgp->irq_enable) != val) { + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ENABLE | val) < 0) + dev_err(smcgp->dev, "GPIO IRQ en/disable failed for %p4ch\n", &key); + else + change_bit(offset, smcgp->irq_enable); + } + + mutex_unlock(&smcgp->irq_mutex); +} + +static const struct irq_chip macsmc_gpio_irqchip = { + .name = "macsmc-pmu-gpio", + .irq_mask = macsmc_gpio_irq_disable, + .irq_unmask = macsmc_gpio_irq_enable, + .irq_set_type = macsmc_gpio_irq_set_type, + .irq_bus_lock = macsmc_gpio_irq_bus_lock, + .irq_bus_sync_unlock = macsmc_gpio_irq_bus_sync_unlock, + .irq_set_type = macsmc_gpio_irq_set_type, + .flags = IRQCHIP_SET_TYPE_MASKED | + IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_IMMUTABLE, + GPIOCHIP_IRQ_RESOURCE_HELPERS, +}; + static int macsmc_gpio_probe(struct platform_device *pdev) { struct macsmc_gpio *smcgp; @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) smcgp->gc.base = -1; smcgp->gc.parent = &pdev->dev; + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); + smcgp->gc.irq.parent_handler = NULL; + smcgp->gc.irq.num_parents = 0; + smcgp->gc.irq.parents = NULL; + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; + smcgp->gc.irq.handler = handle_simple_irq; + + mutex_init(&smcgp->irq_mutex); + + smcgp->nb.notifier_call = macsmc_gpio_event; + apple_smc_register_notifier(smc, &smcgp->nb); + return devm_gpiochip_add_data(&pdev->dev, &smcgp->gc, smcgp); } -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-01 13:54 ` Russell King @ 2022-09-01 18:03 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-01 18:03 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > Add IRQ support to the macsmc driver. This patch has updates from Joey > Gouly and Russell King. ... > + u16 type = event >> 16; > + u8 offset = (event >> 8) & 0xff; The ' & 0xff' part is redundant. ... > + return (ret == 0) ? NOTIFY_OK : NOTIFY_DONE; Parentheses and ' == 0' parts are redundant. You may swap ternary operands. ... > +static void macsmc_gpio_irq_enable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + gpiochip_enable_irq(gc, irqd_to_hwirq(d)); > + set_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); You may use temporary variable for hwirq irq_hw_number_t hwirq = irdq_to_hwirq(d); > +} > + > +static void macsmc_gpio_irq_disable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + clear_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); > + gpiochip_disable_irq(gc, irqd_to_hwirq(d)); Ditto. > +} > + > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + int offset = irqd_to_hwirq(d); As above. > + u32 mode; > + if (!test_bit(offset, smcgp->irq_supported)) > + return -EINVAL; We have a valid mask for IRQs. Can it be used here instead? > + switch (type & IRQ_TYPE_SENSE_MASK) { > + case IRQ_TYPE_LEVEL_HIGH: > + mode = IRQ_MODE_HIGH; > + break; > + case IRQ_TYPE_LEVEL_LOW: > + mode = IRQ_MODE_LOW; > + break; > + case IRQ_TYPE_EDGE_RISING: > + mode = IRQ_MODE_RISING; > + break; > + case IRQ_TYPE_EDGE_FALLING: > + mode = IRQ_MODE_FALLING; > + break; > + case IRQ_TYPE_EDGE_BOTH: > + mode = IRQ_MODE_BOTH; > + break; > + default: > + return -EINVAL; > } > > + smcgp->irq_mode_shadow[offset] = mode; Usually we want to have handle_bad_irq() handler by default and in ->set_type() we lock a handler depending on the flags. Why is this not the case in this driver? > return 0; > } ... > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > + int offset = irqd_to_hwirq(d); As above. > + bool val; > + > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > + else > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > + } > + > + val = test_bit(offset, smcgp->irq_enable_shadow); > + if (test_bit(offset, smcgp->irq_enable) != val) { > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ENABLE | val) < 0) > + dev_err(smcgp->dev, "GPIO IRQ en/disable failed for %p4ch\n", &key); > + else > + change_bit(offset, smcgp->irq_enable); > + } > + > + mutex_unlock(&smcgp->irq_mutex); > +} -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-01 18:03 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-01 18:03 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > Add IRQ support to the macsmc driver. This patch has updates from Joey > Gouly and Russell King. ... > + u16 type = event >> 16; > + u8 offset = (event >> 8) & 0xff; The ' & 0xff' part is redundant. ... > + return (ret == 0) ? NOTIFY_OK : NOTIFY_DONE; Parentheses and ' == 0' parts are redundant. You may swap ternary operands. ... > +static void macsmc_gpio_irq_enable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + gpiochip_enable_irq(gc, irqd_to_hwirq(d)); > + set_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); You may use temporary variable for hwirq irq_hw_number_t hwirq = irdq_to_hwirq(d); > +} > + > +static void macsmc_gpio_irq_disable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + clear_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); > + gpiochip_disable_irq(gc, irqd_to_hwirq(d)); Ditto. > +} > + > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + int offset = irqd_to_hwirq(d); As above. > + u32 mode; > + if (!test_bit(offset, smcgp->irq_supported)) > + return -EINVAL; We have a valid mask for IRQs. Can it be used here instead? > + switch (type & IRQ_TYPE_SENSE_MASK) { > + case IRQ_TYPE_LEVEL_HIGH: > + mode = IRQ_MODE_HIGH; > + break; > + case IRQ_TYPE_LEVEL_LOW: > + mode = IRQ_MODE_LOW; > + break; > + case IRQ_TYPE_EDGE_RISING: > + mode = IRQ_MODE_RISING; > + break; > + case IRQ_TYPE_EDGE_FALLING: > + mode = IRQ_MODE_FALLING; > + break; > + case IRQ_TYPE_EDGE_BOTH: > + mode = IRQ_MODE_BOTH; > + break; > + default: > + return -EINVAL; > } > > + smcgp->irq_mode_shadow[offset] = mode; Usually we want to have handle_bad_irq() handler by default and in ->set_type() we lock a handler depending on the flags. Why is this not the case in this driver? > return 0; > } ... > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > + int offset = irqd_to_hwirq(d); As above. > + bool val; > + > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > + else > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > + } > + > + val = test_bit(offset, smcgp->irq_enable_shadow); > + if (test_bit(offset, smcgp->irq_enable) != val) { > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ENABLE | val) < 0) > + dev_err(smcgp->dev, "GPIO IRQ en/disable failed for %p4ch\n", &key); > + else > + change_bit(offset, smcgp->irq_enable); > + } > + > + mutex_unlock(&smcgp->irq_mutex); > +} -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-01 18:03 ` Andy Shevchenko @ 2022-09-05 11:54 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 11:54 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 01, 2022 at 09:03:49PM +0300, Andy Shevchenko wrote: > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > > > Add IRQ support to the macsmc driver. This patch has updates from Joey > > Gouly and Russell King. > > ... > > > + u16 type = event >> 16; > > + u8 offset = (event >> 8) & 0xff; > > The ' & 0xff' part is redundant. It's probably also more logical to call this "hwirq". > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); ... > > + if (!test_bit(offset, smcgp->irq_supported)) > > + return -EINVAL; > > We have a valid mask for IRQs. Can it be used here instead? Looks like we can, thanks for the suggestion. > > + smcgp->irq_mode_shadow[offset] = mode; > > Usually we want to have handle_bad_irq() handler by default and in > ->set_type() we lock a handler depending on the flags. Why is this not > the case in this driver? "lock a handler" ? I guess you mean select a handler. I don't see a reason why we couldn't switch between handle_bad_irq() and handle_simple_irq(). I would guess (I don't know the implementation details of the Apple platform) that the SMC forwards a message when the IRQ happens, but I'm guessing that this is well tested on the platform with the simple flow handler. Changing it to something else would need discussion with the Asahi Linux folk. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-05 11:54 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 11:54 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Linus Walleij, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Thu, Sep 01, 2022 at 09:03:49PM +0300, Andy Shevchenko wrote: > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > From: Hector Martin <marcan@marcan.st> > > > > Add IRQ support to the macsmc driver. This patch has updates from Joey > > Gouly and Russell King. > > ... > > > + u16 type = event >> 16; > > + u8 offset = (event >> 8) & 0xff; > > The ' & 0xff' part is redundant. It's probably also more logical to call this "hwirq". > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); ... > > + if (!test_bit(offset, smcgp->irq_supported)) > > + return -EINVAL; > > We have a valid mask for IRQs. Can it be used here instead? Looks like we can, thanks for the suggestion. > > + smcgp->irq_mode_shadow[offset] = mode; > > Usually we want to have handle_bad_irq() handler by default and in > ->set_type() we lock a handler depending on the flags. Why is this not > the case in this driver? "lock a handler" ? I guess you mean select a handler. I don't see a reason why we couldn't switch between handle_bad_irq() and handle_simple_irq(). I would guess (I don't know the implementation details of the Apple platform) that the SMC forwards a message when the IRQ happens, but I'm guessing that this is well tested on the platform with the simple flow handler. Changing it to something else would need discussion with the Asahi Linux folk. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
[parent not found: <CAHp75VeDGCp8J6wnmCqGpV++vs2Zur9Mfp71Dk8dVXcuHFnCrQ@mail.gmail.com>]
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support [not found] ` <CAHp75VeDGCp8J6wnmCqGpV++vs2Zur9Mfp71Dk8dVXcuHFnCrQ@mail.gmail.com> @ 2022-09-05 13:21 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 13:21 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 4:04 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Mon, Sep 5, 2022 at 2:54 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 09:03:49PM +0300, Andy Shevchenko wrote: > > > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > ... > > > > Usually we want to have handle_bad_irq() handler by default and in > > > ->set_type() we lock a handler depending on the flags. Why is this not > > > the case in this driver? > > > > "lock a handler" ? I guess you mean select a handler. > > Yes, I was a bit confused by API naming (irq_set_handler_locked() was it). > > > I don't see a reason why we couldn't switch between handle_bad_irq() > > and handle_simple_irq(). I would guess (I don't know the implementation > > details of the Apple platform) that the SMC forwards a message when the > > IRQ happens, but I'm guessing that this is well tested on the platform > > with the simple flow handler. > > I have had a real case where it makes quite a difference: > eb441337c714 ("gpio: pca953x: Set IRQ type when handle Intel Galileo Gen 2") > > The missed ->irq_set_type() call shows a bug in the IRQ flow in the > code. This became visible due to the switch to handle_bad_irq() and > was hidden with other default handlers. After this I ask people to use > the default handler to be a "bad" one. > > > Changing it to something else would need > > discussion with the Asahi Linux folk. > > > > -- > With Best Regards, > Andy Shevchenko -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-05 13:21 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 13:21 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 5, 2022 at 4:04 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Mon, Sep 5, 2022 at 2:54 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > On Thu, Sep 01, 2022 at 09:03:49PM +0300, Andy Shevchenko wrote: > > > On Thu, Sep 1, 2022 at 5:18 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > ... > > > > Usually we want to have handle_bad_irq() handler by default and in > > > ->set_type() we lock a handler depending on the flags. Why is this not > > > the case in this driver? > > > > "lock a handler" ? I guess you mean select a handler. > > Yes, I was a bit confused by API naming (irq_set_handler_locked() was it). > > > I don't see a reason why we couldn't switch between handle_bad_irq() > > and handle_simple_irq(). I would guess (I don't know the implementation > > details of the Apple platform) that the SMC forwards a message when the > > IRQ happens, but I'm guessing that this is well tested on the platform > > with the simple flow handler. > > I have had a real case where it makes quite a difference: > eb441337c714 ("gpio: pca953x: Set IRQ type when handle Intel Galileo Gen 2") > > The missed ->irq_set_type() call shows a bug in the IRQ flow in the > code. This became visible due to the switch to handle_bad_irq() and > was hidden with other default handlers. After this I ask people to use > the default handler to be a "bad" one. > > > Changing it to something else would need > > discussion with the Asahi Linux folk. > > > > -- > With Best Regards, > Andy Shevchenko -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-01 13:54 ` Russell King @ 2022-09-02 13:21 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-02 13:21 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > From: Hector Martin <marcan@marcan.st> > > Add IRQ support to the macsmc driver. This patch has updates from Joey > Gouly and Russell King. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Overall looks very good, again some detailed remarks from Andy should be addressed, apart from that you need to add: select GPIOLIB_IRQCHIP to the Kconfig entry for the driver, or else the compile robots are going to hit some configuration that doesn't compile. > + struct mutex irq_mutex; > + DECLARE_BITMAP(irq_supported, MAX_GPIO); If you can use the .init_valid_mask from struct gpio_irq_chip instead, it will allocate this mask dynamically for the irqchip. (Further comment below.) > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); Please rename irq_unmasked_shadow as it is tracking this and not what the irqchip core calls enabled/disabled. > + DECLARE_BITMAP(irq_enable, MAX_GPIO); I think this state should be possible to set/get from the irqchip core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. > + u32 irq_mode_shadow[MAX_GPIO]; > + u32 irq_mode[MAX_GPIO]; > > int first_index; > }; > @@ -161,6 +172,7 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, > for (i = 0; i < count; i++) { > smc_key key; > int gpio_nr; > + u32 val; > int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > if (ret < 0) > @@ -176,11 +188,143 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, > } > > set_bit(gpio_nr, valid_mask); > + > + /* Check for IRQ support */ > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > + if (!ret) > + set_bit(gpio_nr, smcgp->irq_supported); > + } > + > + return 0; > +} This gets initialized from the struct gpio_chip .init_valid_mask, but struct gpio_irq_chip has its own callback with the same name, which is preferred to be used for this, check if you can use that instead, it makes the use more obvious. > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > +{ > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > + u16 type = event >> 16; > + u8 offset = (event >> 8) & 0xff; > + smc_key key = macsmc_gpio_key(offset); > + unsigned long flags; > + int ret; > + > + if (type != SMC_EV_GPIO) > + return NOTIFY_DONE; > + > + if (offset > MAX_GPIO) { > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > + return NOTIFY_BAD; > + } > + > + local_irq_save(flags); > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > + local_irq_restore(flags); Isn't irq_bus_lock/unlock protecting us here already? (I might be getting it wrong...) Since this is coming from a notifier and not an IRQ or threaded IRQ I actually am a bit puzzled on how to handle it... you probably know it better than me, maybe ask Marc Z if anything is unclear. > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); isn't this one of those cases where we should implement the irqchip callback .irq_ack() specifically for this? That callback will only be used by edge triggered IRQs but I guess that would realistically be all we support anyway? (See comment below on .set_type) > +static void macsmc_gpio_irq_enable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + gpiochip_enable_irq(gc, irqd_to_hwirq(d)); > + set_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); > +} > + > +static void macsmc_gpio_irq_disable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + clear_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); > + gpiochip_disable_irq(gc, irqd_to_hwirq(d)); > +} I would rename these unmask/mask to match the callback hooks they are implementing, since there are irqchips callbacks with these names I get a but confused. > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + int offset = irqd_to_hwirq(d); > + u32 mode; > + > + if (!test_bit(offset, smcgp->irq_supported)) > + return -EINVAL; > + > + switch (type & IRQ_TYPE_SENSE_MASK) { > + case IRQ_TYPE_LEVEL_HIGH: > + mode = IRQ_MODE_HIGH; > + break; > + case IRQ_TYPE_LEVEL_LOW: > + mode = IRQ_MODE_LOW; > + break; > + case IRQ_TYPE_EDGE_RISING: > + mode = IRQ_MODE_RISING; > + break; > + case IRQ_TYPE_EDGE_FALLING: > + mode = IRQ_MODE_FALLING; > + break; > + case IRQ_TYPE_EDGE_BOTH: > + mode = IRQ_MODE_BOTH; > + break; > + default: > + return -EINVAL; I don't know how level IRQs would work on this essentially message-passing process context interrupt. Maybe I am getting it all wrong, but for level the line should be held low/high until the IRQ is serviced, it would be possible to test if this actually works by *not* servicing an IRQ and see if the SMC then sends another message notifier for the same IRQ. I strongly suspect that actually only edges are supported, but there might be semantics I don't understand here. > } > > + smcgp->irq_mode_shadow[offset] = mode; Hm yeah I guess this shadow mode is necessary for the sync to work. > return 0; > } > > +static void macsmc_gpio_irq_bus_lock(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + mutex_lock(&smcgp->irq_mutex); > +} > + > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > + int offset = irqd_to_hwirq(d); > + bool val; > + > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > + else > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > + } > + > + val = test_bit(offset, smcgp->irq_enable_shadow); > + if (test_bit(offset, smcgp->irq_enable) != val) { So what you want to know for each line is (correct me if I'm wrong): - Is it enabled (unmasked) or not? - Did it get changed enabled->disabled, disabled->enabled since macsmc_gpio_irq_bus_lock()? Doesn't the irqchip core track the first part of this for you? irqd_irq_masked(d) should tell you the same thing as irq_enable, just inverted. irq_enable_shadow is a bit tricker, I guess you might need that since the irqchip doesn't track state changes. > static int macsmc_gpio_probe(struct platform_device *pdev) > { > struct macsmc_gpio *smcgp; > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > smcgp->gc.base = -1; > smcgp->gc.parent = &pdev->dev; > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > + smcgp->gc.irq.parent_handler = NULL; > + smcgp->gc.irq.num_parents = 0; > + smcgp->gc.irq.parents = NULL; > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > + smcgp->gc.irq.handler = handle_simple_irq; I would consider setting this to handle_edge_irq() and implement .irq_ack(). I might be wrong. But overall since this IRQ is driven by a notifier I feel a bit lost. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-02 13:21 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-02 13:21 UTC (permalink / raw) To: Russell King Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > From: Hector Martin <marcan@marcan.st> > > Add IRQ support to the macsmc driver. This patch has updates from Joey > Gouly and Russell King. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Overall looks very good, again some detailed remarks from Andy should be addressed, apart from that you need to add: select GPIOLIB_IRQCHIP to the Kconfig entry for the driver, or else the compile robots are going to hit some configuration that doesn't compile. > + struct mutex irq_mutex; > + DECLARE_BITMAP(irq_supported, MAX_GPIO); If you can use the .init_valid_mask from struct gpio_irq_chip instead, it will allocate this mask dynamically for the irqchip. (Further comment below.) > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); Please rename irq_unmasked_shadow as it is tracking this and not what the irqchip core calls enabled/disabled. > + DECLARE_BITMAP(irq_enable, MAX_GPIO); I think this state should be possible to set/get from the irqchip core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. > + u32 irq_mode_shadow[MAX_GPIO]; > + u32 irq_mode[MAX_GPIO]; > > int first_index; > }; > @@ -161,6 +172,7 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, > for (i = 0; i < count; i++) { > smc_key key; > int gpio_nr; > + u32 val; > int ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); > > if (ret < 0) > @@ -176,11 +188,143 @@ static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, > } > > set_bit(gpio_nr, valid_mask); > + > + /* Check for IRQ support */ > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); > + if (!ret) > + set_bit(gpio_nr, smcgp->irq_supported); > + } > + > + return 0; > +} This gets initialized from the struct gpio_chip .init_valid_mask, but struct gpio_irq_chip has its own callback with the same name, which is preferred to be used for this, check if you can use that instead, it makes the use more obvious. > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > +{ > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > + u16 type = event >> 16; > + u8 offset = (event >> 8) & 0xff; > + smc_key key = macsmc_gpio_key(offset); > + unsigned long flags; > + int ret; > + > + if (type != SMC_EV_GPIO) > + return NOTIFY_DONE; > + > + if (offset > MAX_GPIO) { > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > + return NOTIFY_BAD; > + } > + > + local_irq_save(flags); > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > + local_irq_restore(flags); Isn't irq_bus_lock/unlock protecting us here already? (I might be getting it wrong...) Since this is coming from a notifier and not an IRQ or threaded IRQ I actually am a bit puzzled on how to handle it... you probably know it better than me, maybe ask Marc Z if anything is unclear. > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); isn't this one of those cases where we should implement the irqchip callback .irq_ack() specifically for this? That callback will only be used by edge triggered IRQs but I guess that would realistically be all we support anyway? (See comment below on .set_type) > +static void macsmc_gpio_irq_enable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + gpiochip_enable_irq(gc, irqd_to_hwirq(d)); > + set_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); > +} > + > +static void macsmc_gpio_irq_disable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + clear_bit(irqd_to_hwirq(d), smcgp->irq_enable_shadow); > + gpiochip_disable_irq(gc, irqd_to_hwirq(d)); > +} I would rename these unmask/mask to match the callback hooks they are implementing, since there are irqchips callbacks with these names I get a but confused. > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + int offset = irqd_to_hwirq(d); > + u32 mode; > + > + if (!test_bit(offset, smcgp->irq_supported)) > + return -EINVAL; > + > + switch (type & IRQ_TYPE_SENSE_MASK) { > + case IRQ_TYPE_LEVEL_HIGH: > + mode = IRQ_MODE_HIGH; > + break; > + case IRQ_TYPE_LEVEL_LOW: > + mode = IRQ_MODE_LOW; > + break; > + case IRQ_TYPE_EDGE_RISING: > + mode = IRQ_MODE_RISING; > + break; > + case IRQ_TYPE_EDGE_FALLING: > + mode = IRQ_MODE_FALLING; > + break; > + case IRQ_TYPE_EDGE_BOTH: > + mode = IRQ_MODE_BOTH; > + break; > + default: > + return -EINVAL; I don't know how level IRQs would work on this essentially message-passing process context interrupt. Maybe I am getting it all wrong, but for level the line should be held low/high until the IRQ is serviced, it would be possible to test if this actually works by *not* servicing an IRQ and see if the SMC then sends another message notifier for the same IRQ. I strongly suspect that actually only edges are supported, but there might be semantics I don't understand here. > } > > + smcgp->irq_mode_shadow[offset] = mode; Hm yeah I guess this shadow mode is necessary for the sync to work. > return 0; > } > > +static void macsmc_gpio_irq_bus_lock(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + > + mutex_lock(&smcgp->irq_mutex); > +} > + > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > + int offset = irqd_to_hwirq(d); > + bool val; > + > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > + else > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > + } > + > + val = test_bit(offset, smcgp->irq_enable_shadow); > + if (test_bit(offset, smcgp->irq_enable) != val) { So what you want to know for each line is (correct me if I'm wrong): - Is it enabled (unmasked) or not? - Did it get changed enabled->disabled, disabled->enabled since macsmc_gpio_irq_bus_lock()? Doesn't the irqchip core track the first part of this for you? irqd_irq_masked(d) should tell you the same thing as irq_enable, just inverted. irq_enable_shadow is a bit tricker, I guess you might need that since the irqchip doesn't track state changes. > static int macsmc_gpio_probe(struct platform_device *pdev) > { > struct macsmc_gpio *smcgp; > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > smcgp->gc.base = -1; > smcgp->gc.parent = &pdev->dev; > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > + smcgp->gc.irq.parent_handler = NULL; > + smcgp->gc.irq.num_parents = 0; > + smcgp->gc.irq.parents = NULL; > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > + smcgp->gc.irq.handler = handle_simple_irq; I would consider setting this to handle_edge_irq() and implement .irq_ack(). I might be wrong. But overall since this IRQ is driven by a notifier I feel a bit lost. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-02 13:21 ` Linus Walleij @ 2022-09-05 12:47 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 12:47 UTC (permalink / raw) To: Linus Walleij Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); > > Please rename irq_unmasked_shadow as it is tracking > this and not what the irqchip core calls enabled/disabled. > > > + DECLARE_BITMAP(irq_enable, MAX_GPIO); > > I think this state should be possible to set/get from the irqchip > core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. I think you're getting the two mixed up. irq_enable_shadow (irq_unmasked_shadow) is updated from the ->irq_mask and ->irq_unmask callbacaks, and will track !irqd_irq_masked(d) state. So, I think we can get rid of irq_enable_shadow and just use !irqd_irq_masked(d). The irq_enable bit array tracks the state on the SMC, and is used to indicate whether we need to update that state when we unlock the bus (which is when the driver talks to the SMC to reconfigure it.) So, I think killing irq_enable_shadow and replacing irq_enable with irq_unmasked would be correct - and going a bit further, irq_smc_unmasked to show that it's the SMC's status. > > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > > +{ > > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > > + u16 type = event >> 16; > > + u8 offset = (event >> 8) & 0xff; > > + smc_key key = macsmc_gpio_key(offset); > > + unsigned long flags; > > + int ret; > > + > > + if (type != SMC_EV_GPIO) > > + return NOTIFY_DONE; > > + > > + if (offset > MAX_GPIO) { > > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > > + return NOTIFY_BAD; > > + } > > + > > + local_irq_save(flags); > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > + local_irq_restore(flags); > > Isn't irq_bus_lock/unlock protecting us here already? > (I might be getting it wrong...) Hmm, where does irq_bus_lock get called? Given this function is called while running a blocking notifier chain, interrupts will not be disabled on entry to this function. I haven't found a place in the maze of irq handling code that generic_handle_domain_irq() would end up using the bus lock/unlock functions - and if they did, with the above IRQ saving, the kernel would WARN() about calling mutex_lock() with IRQs disabled. So it doesn't. This actually entirely negates any benefit of the kernel trying to mask or unmask an interrupt in "hardware" while running the handler - since macsmc_gpio_irq_bus_sync_unlock() won't be called, the state on the SMC won't get touched. > Since this is coming from a notifier and not an IRQ or threaded > IRQ I actually am a bit puzzled on how to handle it... you probably > know it better than me, maybe ask Marc Z if anything is > unclear. It's been years since I did any real platform porting work, so deep knowledge of the IRQ subsystem has evaporated. > > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > > isn't this one of those cases where we should implement the > irqchip callback .irq_ack() specifically for this? > > That callback will only be used by edge triggered IRQs but > I guess that would realistically be all we support anyway? > (See comment below on .set_type) I would imagine it depends on how the SMC GPIO interrupt works - whether the ACK is ACK as we know it in Linux (x86 PIC) or whether it's ACK as in a notification to the SMC that we have finished handling the interrupt and it can send us the next interrupt. I suspect we don't know that level of detail of the platform, so given that this is what the Asahi kernel does, that's the best we have. > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + int offset = irqd_to_hwirq(d); > > + u32 mode; > > + > > + if (!test_bit(offset, smcgp->irq_supported)) > > + return -EINVAL; > > + > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > + case IRQ_TYPE_LEVEL_HIGH: > > + mode = IRQ_MODE_HIGH; > > + break; > > + case IRQ_TYPE_LEVEL_LOW: > > + mode = IRQ_MODE_LOW; > > + break; > > + case IRQ_TYPE_EDGE_RISING: > > + mode = IRQ_MODE_RISING; > > + break; > > + case IRQ_TYPE_EDGE_FALLING: > > + mode = IRQ_MODE_FALLING; > > + break; > > + case IRQ_TYPE_EDGE_BOTH: > > + mode = IRQ_MODE_BOTH; > > + break; > > + default: > > + return -EINVAL; > > I don't know how level IRQs would work on this essentially > message-passing process context interrupt. Maybe I am getting > it all wrong, but for level the line should be held low/high until > the IRQ is serviced, it would be possible to test if this actually > works by *not* servicing an IRQ and see if the SMC then sends > another message notifier for the same IRQ. If level IRQs are not supported, then it's strange that the Asahi folk have been able to reverse engineer the CMD_IRQ_MODE codes for these states. Maybe the SMC issues another message for a level IRQ after it receives a CMD_IRQ_ACK message if the level interrupt is still asserted? > I strongly suspect that actually only edges are supported, but > there might be semantics I don't understand here. > > > } > > > > + smcgp->irq_mode_shadow[offset] = mode; > > Hm yeah I guess this shadow mode is necessary for the sync > to work. Ineed. > > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > > + int offset = irqd_to_hwirq(d); > > + bool val; > > + > > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > > + else > > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > > + } > > + > > + val = test_bit(offset, smcgp->irq_enable_shadow); > > + if (test_bit(offset, smcgp->irq_enable) != val) { > > So what you want to know for each line is (correct me if I'm wrong): > - Is it enabled (unmasked) or not? > - Did it get changed enabled->disabled, disabled->enabled since > macsmc_gpio_irq_bus_lock()? I think you mean here "did the 'enable' state change between macsmc_gpio_irq_bus_lock() and macsmc_gpio_irq_bus_unlock". > Doesn't the irqchip core track the first part of this for you? > irqd_irq_masked(d) should tell you the same thing as > irq_enable, just inverted. > > irq_enable_shadow is a bit tricker, I guess you might need that since > the irqchip doesn't track state changes. Yep, which is what I've said above in this reply where these bitmaps are declared. > > static int macsmc_gpio_probe(struct platform_device *pdev) > > { > > struct macsmc_gpio *smcgp; > > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > > smcgp->gc.base = -1; > > smcgp->gc.parent = &pdev->dev; > > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > + smcgp->gc.irq.parent_handler = NULL; > > + smcgp->gc.irq.num_parents = 0; > > + smcgp->gc.irq.parents = NULL; > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > + smcgp->gc.irq.handler = handle_simple_irq; > > I would consider setting this to handle_edge_irq() and implement > .irq_ack(). I might be wrong. I don't think that's suitable, because then we'll be calling irq_ack() before the handler has run - and we won't be notifying the SMC that the interrupt has been masked. So it could send another notification for the same IRQ while it's still being handled. Then there's the question about level IRQs as well. I think, given that I don't know how the SMC works (presumably the Asahi folk have a bit more of an idea, but that will be based on reverse engineering effort) that I am not going to modify this driver's behaviour drastically by changing the flow handler to the edge flow handler from the simple flow. To me, that could well be a disaster for this driver. That would be something for the Asahi folk to look at. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-05 12:47 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 12:47 UTC (permalink / raw) To: Linus Walleij Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); > > Please rename irq_unmasked_shadow as it is tracking > this and not what the irqchip core calls enabled/disabled. > > > + DECLARE_BITMAP(irq_enable, MAX_GPIO); > > I think this state should be possible to set/get from the irqchip > core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. I think you're getting the two mixed up. irq_enable_shadow (irq_unmasked_shadow) is updated from the ->irq_mask and ->irq_unmask callbacaks, and will track !irqd_irq_masked(d) state. So, I think we can get rid of irq_enable_shadow and just use !irqd_irq_masked(d). The irq_enable bit array tracks the state on the SMC, and is used to indicate whether we need to update that state when we unlock the bus (which is when the driver talks to the SMC to reconfigure it.) So, I think killing irq_enable_shadow and replacing irq_enable with irq_unmasked would be correct - and going a bit further, irq_smc_unmasked to show that it's the SMC's status. > > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > > +{ > > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > > + u16 type = event >> 16; > > + u8 offset = (event >> 8) & 0xff; > > + smc_key key = macsmc_gpio_key(offset); > > + unsigned long flags; > > + int ret; > > + > > + if (type != SMC_EV_GPIO) > > + return NOTIFY_DONE; > > + > > + if (offset > MAX_GPIO) { > > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > > + return NOTIFY_BAD; > > + } > > + > > + local_irq_save(flags); > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > + local_irq_restore(flags); > > Isn't irq_bus_lock/unlock protecting us here already? > (I might be getting it wrong...) Hmm, where does irq_bus_lock get called? Given this function is called while running a blocking notifier chain, interrupts will not be disabled on entry to this function. I haven't found a place in the maze of irq handling code that generic_handle_domain_irq() would end up using the bus lock/unlock functions - and if they did, with the above IRQ saving, the kernel would WARN() about calling mutex_lock() with IRQs disabled. So it doesn't. This actually entirely negates any benefit of the kernel trying to mask or unmask an interrupt in "hardware" while running the handler - since macsmc_gpio_irq_bus_sync_unlock() won't be called, the state on the SMC won't get touched. > Since this is coming from a notifier and not an IRQ or threaded > IRQ I actually am a bit puzzled on how to handle it... you probably > know it better than me, maybe ask Marc Z if anything is > unclear. It's been years since I did any real platform porting work, so deep knowledge of the IRQ subsystem has evaporated. > > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > > isn't this one of those cases where we should implement the > irqchip callback .irq_ack() specifically for this? > > That callback will only be used by edge triggered IRQs but > I guess that would realistically be all we support anyway? > (See comment below on .set_type) I would imagine it depends on how the SMC GPIO interrupt works - whether the ACK is ACK as we know it in Linux (x86 PIC) or whether it's ACK as in a notification to the SMC that we have finished handling the interrupt and it can send us the next interrupt. I suspect we don't know that level of detail of the platform, so given that this is what the Asahi kernel does, that's the best we have. > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + int offset = irqd_to_hwirq(d); > > + u32 mode; > > + > > + if (!test_bit(offset, smcgp->irq_supported)) > > + return -EINVAL; > > + > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > + case IRQ_TYPE_LEVEL_HIGH: > > + mode = IRQ_MODE_HIGH; > > + break; > > + case IRQ_TYPE_LEVEL_LOW: > > + mode = IRQ_MODE_LOW; > > + break; > > + case IRQ_TYPE_EDGE_RISING: > > + mode = IRQ_MODE_RISING; > > + break; > > + case IRQ_TYPE_EDGE_FALLING: > > + mode = IRQ_MODE_FALLING; > > + break; > > + case IRQ_TYPE_EDGE_BOTH: > > + mode = IRQ_MODE_BOTH; > > + break; > > + default: > > + return -EINVAL; > > I don't know how level IRQs would work on this essentially > message-passing process context interrupt. Maybe I am getting > it all wrong, but for level the line should be held low/high until > the IRQ is serviced, it would be possible to test if this actually > works by *not* servicing an IRQ and see if the SMC then sends > another message notifier for the same IRQ. If level IRQs are not supported, then it's strange that the Asahi folk have been able to reverse engineer the CMD_IRQ_MODE codes for these states. Maybe the SMC issues another message for a level IRQ after it receives a CMD_IRQ_ACK message if the level interrupt is still asserted? > I strongly suspect that actually only edges are supported, but > there might be semantics I don't understand here. > > > } > > > > + smcgp->irq_mode_shadow[offset] = mode; > > Hm yeah I guess this shadow mode is necessary for the sync > to work. Ineed. > > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > > + int offset = irqd_to_hwirq(d); > > + bool val; > > + > > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > > + else > > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > > + } > > + > > + val = test_bit(offset, smcgp->irq_enable_shadow); > > + if (test_bit(offset, smcgp->irq_enable) != val) { > > So what you want to know for each line is (correct me if I'm wrong): > - Is it enabled (unmasked) or not? > - Did it get changed enabled->disabled, disabled->enabled since > macsmc_gpio_irq_bus_lock()? I think you mean here "did the 'enable' state change between macsmc_gpio_irq_bus_lock() and macsmc_gpio_irq_bus_unlock". > Doesn't the irqchip core track the first part of this for you? > irqd_irq_masked(d) should tell you the same thing as > irq_enable, just inverted. > > irq_enable_shadow is a bit tricker, I guess you might need that since > the irqchip doesn't track state changes. Yep, which is what I've said above in this reply where these bitmaps are declared. > > static int macsmc_gpio_probe(struct platform_device *pdev) > > { > > struct macsmc_gpio *smcgp; > > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > > smcgp->gc.base = -1; > > smcgp->gc.parent = &pdev->dev; > > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > + smcgp->gc.irq.parent_handler = NULL; > > + smcgp->gc.irq.num_parents = 0; > > + smcgp->gc.irq.parents = NULL; > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > + smcgp->gc.irq.handler = handle_simple_irq; > > I would consider setting this to handle_edge_irq() and implement > .irq_ack(). I might be wrong. I don't think that's suitable, because then we'll be calling irq_ack() before the handler has run - and we won't be notifying the SMC that the interrupt has been masked. So it could send another notification for the same IRQ while it's still being handled. Then there's the question about level IRQs as well. I think, given that I don't know how the SMC works (presumably the Asahi folk have a bit more of an idea, but that will be based on reverse engineering effort) that I am not going to modify this driver's behaviour drastically by changing the flow handler to the edge flow handler from the simple flow. To me, that could well be a disaster for this driver. That would be something for the Asahi folk to look at. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Fwd: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-05 12:47 ` Russell King (Oracle) @ 2022-09-05 13:19 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 13:19 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter (Replied privately to Russell by a mistake) ---------- Forwarded message --------- From: Russell King (Oracle) <linux@armlinux.org.uk> Date: Mon, Sep 5, 2022 at 3:50 PM Subject: Re: [PATCH 6/6] gpio: macsmc: Add IRQ support To: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee@kernel.org>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, <asahi@lists.linux.dev>, Bartosz Golaszewski <brgl@bgdev.pl>, Hector Martin <marcan@marcan.st>, <linux-arm-kernel@lists.infradead.org>, <linux-gpio@vger.kernel.org>, Sven Peter <sven@svenpeter.dev> On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); > > Please rename irq_unmasked_shadow as it is tracking > this and not what the irqchip core calls enabled/disabled. > > > + DECLARE_BITMAP(irq_enable, MAX_GPIO); > > I think this state should be possible to set/get from the irqchip > core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. I think you're getting the two mixed up. irq_enable_shadow (irq_unmasked_shadow) is updated from the ->irq_mask and ->irq_unmask callbacaks, and will track !irqd_irq_masked(d) state. So, I think we can get rid of irq_enable_shadow and just use !irqd_irq_masked(d). The irq_enable bit array tracks the state on the SMC, and is used to indicate whether we need to update that state when we unlock the bus (which is when the driver talks to the SMC to reconfigure it.) So, I think killing irq_enable_shadow and replacing irq_enable with irq_unmasked would be correct - and going a bit further, irq_smc_unmasked to show that it's the SMC's status. > > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > > +{ > > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > > + u16 type = event >> 16; > > + u8 offset = (event >> 8) & 0xff; > > + smc_key key = macsmc_gpio_key(offset); > > + unsigned long flags; > > + int ret; > > + > > + if (type != SMC_EV_GPIO) > > + return NOTIFY_DONE; > > + > > + if (offset > MAX_GPIO) { > > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > > + return NOTIFY_BAD; > > + } > > + > > + local_irq_save(flags); > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > + local_irq_restore(flags); > > Isn't irq_bus_lock/unlock protecting us here already? > (I might be getting it wrong...) Hmm, where does irq_bus_lock get called? Given this function is called while running a blocking notifier chain, interrupts will not be disabled on entry to this function. I haven't found a place in the maze of irq handling code that generic_handle_domain_irq() would end up using the bus lock/unlock functions - and if they did, with the above IRQ saving, the kernel would WARN() about calling mutex_lock() with IRQs disabled. So it doesn't. This actually entirely negates any benefit of the kernel trying to mask or unmask an interrupt in "hardware" while running the handler - since macsmc_gpio_irq_bus_sync_unlock() won't be called, the state on the SMC won't get touched. > Since this is coming from a notifier and not an IRQ or threaded > IRQ I actually am a bit puzzled on how to handle it... you probably > know it better than me, maybe ask Marc Z if anything is > unclear. It's been years since I did any real platform porting work, so deep knowledge of the IRQ subsystem has evaporated. > > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > > isn't this one of those cases where we should implement the > irqchip callback .irq_ack() specifically for this? > > That callback will only be used by edge triggered IRQs but > I guess that would realistically be all we support anyway? > (See comment below on .set_type) I would imagine it depends on how the SMC GPIO interrupt works - whether the ACK is ACK as we know it in Linux (x86 PIC) or whether it's ACK as in a notification to the SMC that we have finished handling the interrupt and it can send us the next interrupt. I suspect we don't know that level of detail of the platform, so given that this is what the Asahi kernel does, that's the best we have. > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + int offset = irqd_to_hwirq(d); > > + u32 mode; > > + > > + if (!test_bit(offset, smcgp->irq_supported)) > > + return -EINVAL; > > + > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > + case IRQ_TYPE_LEVEL_HIGH: > > + mode = IRQ_MODE_HIGH; > > + break; > > + case IRQ_TYPE_LEVEL_LOW: > > + mode = IRQ_MODE_LOW; > > + break; > > + case IRQ_TYPE_EDGE_RISING: > > + mode = IRQ_MODE_RISING; > > + break; > > + case IRQ_TYPE_EDGE_FALLING: > > + mode = IRQ_MODE_FALLING; > > + break; > > + case IRQ_TYPE_EDGE_BOTH: > > + mode = IRQ_MODE_BOTH; > > + break; > > + default: > > + return -EINVAL; > > I don't know how level IRQs would work on this essentially > message-passing process context interrupt. Maybe I am getting > it all wrong, but for level the line should be held low/high until > the IRQ is serviced, it would be possible to test if this actually > works by *not* servicing an IRQ and see if the SMC then sends > another message notifier for the same IRQ. If level IRQs are not supported, then it's strange that the Asahi folk have been able to reverse engineer the CMD_IRQ_MODE codes for these states. Maybe the SMC issues another message for a level IRQ after it receives a CMD_IRQ_ACK message if the level interrupt is still asserted? > I strongly suspect that actually only edges are supported, but > there might be semantics I don't understand here. > > > } > > > > + smcgp->irq_mode_shadow[offset] = mode; > > Hm yeah I guess this shadow mode is necessary for the sync > to work. Ineed. > > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > > + int offset = irqd_to_hwirq(d); > > + bool val; > > + > > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > > + else > > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > > + } > > + > > + val = test_bit(offset, smcgp->irq_enable_shadow); > > + if (test_bit(offset, smcgp->irq_enable) != val) { > > So what you want to know for each line is (correct me if I'm wrong): > - Is it enabled (unmasked) or not? > - Did it get changed enabled->disabled, disabled->enabled since > macsmc_gpio_irq_bus_lock()? I think you mean here "did the 'enable' state change between macsmc_gpio_irq_bus_lock() and macsmc_gpio_irq_bus_unlock". > Doesn't the irqchip core track the first part of this for you? > irqd_irq_masked(d) should tell you the same thing as > irq_enable, just inverted. > > irq_enable_shadow is a bit tricker, I guess you might need that since > the irqchip doesn't track state changes. Yep, which is what I've said above in this reply where these bitmaps are declared. > > static int macsmc_gpio_probe(struct platform_device *pdev) > > { > > struct macsmc_gpio *smcgp; > > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > > smcgp->gc.base = -1; > > smcgp->gc.parent = &pdev->dev; > > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > + smcgp->gc.irq.parent_handler = NULL; > > + smcgp->gc.irq.num_parents = 0; > > + smcgp->gc.irq.parents = NULL; > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > + smcgp->gc.irq.handler = handle_simple_irq; > > I would consider setting this to handle_edge_irq() and implement > .irq_ack(). I might be wrong. I don't think that's suitable, because then we'll be calling irq_ack() before the handler has run - and we won't be notifying the SMC that the interrupt has been masked. So it could send another notification for the same IRQ while it's still being handled. Then there's the question about level IRQs as well. I think, given that I don't know how the SMC works (presumably the Asahi folk have a bit more of an idea, but that will be based on reverse engineering effort) that I am not going to modify this driver's behaviour drastically by changing the flow handler to the edge flow handler from the simple flow. To me, that could well be a disaster for this driver. That would be something for the Asahi folk to look at. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Fwd: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-05 13:19 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-09-05 13:19 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter (Replied privately to Russell by a mistake) ---------- Forwarded message --------- From: Russell King (Oracle) <linux@armlinux.org.uk> Date: Mon, Sep 5, 2022 at 3:50 PM Subject: Re: [PATCH 6/6] gpio: macsmc: Add IRQ support To: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee@kernel.org>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, <asahi@lists.linux.dev>, Bartosz Golaszewski <brgl@bgdev.pl>, Hector Martin <marcan@marcan.st>, <linux-arm-kernel@lists.infradead.org>, <linux-gpio@vger.kernel.org>, Sven Peter <sven@svenpeter.dev> On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); > > Please rename irq_unmasked_shadow as it is tracking > this and not what the irqchip core calls enabled/disabled. > > > + DECLARE_BITMAP(irq_enable, MAX_GPIO); > > I think this state should be possible to set/get from the irqchip > core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. I think you're getting the two mixed up. irq_enable_shadow (irq_unmasked_shadow) is updated from the ->irq_mask and ->irq_unmask callbacaks, and will track !irqd_irq_masked(d) state. So, I think we can get rid of irq_enable_shadow and just use !irqd_irq_masked(d). The irq_enable bit array tracks the state on the SMC, and is used to indicate whether we need to update that state when we unlock the bus (which is when the driver talks to the SMC to reconfigure it.) So, I think killing irq_enable_shadow and replacing irq_enable with irq_unmasked would be correct - and going a bit further, irq_smc_unmasked to show that it's the SMC's status. > > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > > +{ > > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > > + u16 type = event >> 16; > > + u8 offset = (event >> 8) & 0xff; > > + smc_key key = macsmc_gpio_key(offset); > > + unsigned long flags; > > + int ret; > > + > > + if (type != SMC_EV_GPIO) > > + return NOTIFY_DONE; > > + > > + if (offset > MAX_GPIO) { > > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > > + return NOTIFY_BAD; > > + } > > + > > + local_irq_save(flags); > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > + local_irq_restore(flags); > > Isn't irq_bus_lock/unlock protecting us here already? > (I might be getting it wrong...) Hmm, where does irq_bus_lock get called? Given this function is called while running a blocking notifier chain, interrupts will not be disabled on entry to this function. I haven't found a place in the maze of irq handling code that generic_handle_domain_irq() would end up using the bus lock/unlock functions - and if they did, with the above IRQ saving, the kernel would WARN() about calling mutex_lock() with IRQs disabled. So it doesn't. This actually entirely negates any benefit of the kernel trying to mask or unmask an interrupt in "hardware" while running the handler - since macsmc_gpio_irq_bus_sync_unlock() won't be called, the state on the SMC won't get touched. > Since this is coming from a notifier and not an IRQ or threaded > IRQ I actually am a bit puzzled on how to handle it... you probably > know it better than me, maybe ask Marc Z if anything is > unclear. It's been years since I did any real platform porting work, so deep knowledge of the IRQ subsystem has evaporated. > > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > > isn't this one of those cases where we should implement the > irqchip callback .irq_ack() specifically for this? > > That callback will only be used by edge triggered IRQs but > I guess that would realistically be all we support anyway? > (See comment below on .set_type) I would imagine it depends on how the SMC GPIO interrupt works - whether the ACK is ACK as we know it in Linux (x86 PIC) or whether it's ACK as in a notification to the SMC that we have finished handling the interrupt and it can send us the next interrupt. I suspect we don't know that level of detail of the platform, so given that this is what the Asahi kernel does, that's the best we have. > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + int offset = irqd_to_hwirq(d); > > + u32 mode; > > + > > + if (!test_bit(offset, smcgp->irq_supported)) > > + return -EINVAL; > > + > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > + case IRQ_TYPE_LEVEL_HIGH: > > + mode = IRQ_MODE_HIGH; > > + break; > > + case IRQ_TYPE_LEVEL_LOW: > > + mode = IRQ_MODE_LOW; > > + break; > > + case IRQ_TYPE_EDGE_RISING: > > + mode = IRQ_MODE_RISING; > > + break; > > + case IRQ_TYPE_EDGE_FALLING: > > + mode = IRQ_MODE_FALLING; > > + break; > > + case IRQ_TYPE_EDGE_BOTH: > > + mode = IRQ_MODE_BOTH; > > + break; > > + default: > > + return -EINVAL; > > I don't know how level IRQs would work on this essentially > message-passing process context interrupt. Maybe I am getting > it all wrong, but for level the line should be held low/high until > the IRQ is serviced, it would be possible to test if this actually > works by *not* servicing an IRQ and see if the SMC then sends > another message notifier for the same IRQ. If level IRQs are not supported, then it's strange that the Asahi folk have been able to reverse engineer the CMD_IRQ_MODE codes for these states. Maybe the SMC issues another message for a level IRQ after it receives a CMD_IRQ_ACK message if the level interrupt is still asserted? > I strongly suspect that actually only edges are supported, but > there might be semantics I don't understand here. > > > } > > > > + smcgp->irq_mode_shadow[offset] = mode; > > Hm yeah I guess this shadow mode is necessary for the sync > to work. Ineed. > > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > > +{ > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > > + int offset = irqd_to_hwirq(d); > > + bool val; > > + > > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > > + else > > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > > + } > > + > > + val = test_bit(offset, smcgp->irq_enable_shadow); > > + if (test_bit(offset, smcgp->irq_enable) != val) { > > So what you want to know for each line is (correct me if I'm wrong): > - Is it enabled (unmasked) or not? > - Did it get changed enabled->disabled, disabled->enabled since > macsmc_gpio_irq_bus_lock()? I think you mean here "did the 'enable' state change between macsmc_gpio_irq_bus_lock() and macsmc_gpio_irq_bus_unlock". > Doesn't the irqchip core track the first part of this for you? > irqd_irq_masked(d) should tell you the same thing as > irq_enable, just inverted. > > irq_enable_shadow is a bit tricker, I guess you might need that since > the irqchip doesn't track state changes. Yep, which is what I've said above in this reply where these bitmaps are declared. > > static int macsmc_gpio_probe(struct platform_device *pdev) > > { > > struct macsmc_gpio *smcgp; > > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > > smcgp->gc.base = -1; > > smcgp->gc.parent = &pdev->dev; > > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > + smcgp->gc.irq.parent_handler = NULL; > > + smcgp->gc.irq.num_parents = 0; > > + smcgp->gc.irq.parents = NULL; > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > + smcgp->gc.irq.handler = handle_simple_irq; > > I would consider setting this to handle_edge_irq() and implement > .irq_ack(). I might be wrong. I don't think that's suitable, because then we'll be calling irq_ack() before the handler has run - and we won't be notifying the SMC that the interrupt has been masked. So it could send another notification for the same IRQ while it's still being handled. Then there's the question about level IRQs as well. I think, given that I don't know how the SMC works (presumably the Asahi folk have a bit more of an idea, but that will be based on reverse engineering effort) that I am not going to modify this driver's behaviour drastically by changing the flow handler to the edge flow handler from the simple flow. To me, that could well be a disaster for this driver. That would be something for the Asahi folk to look at. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: Fwd: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-05 13:19 ` Andy Shevchenko @ 2022-09-05 21:43 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 21:43 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 04:19:22PM +0300, Andy Shevchenko wrote: > (Replied privately to Russell by a mistake) What are you doing? This email you've forwarded is not your own email that you sent to me privately but my reply to LinusW that was on the list. Are you okay, or is this a result of you rushing and not making sure that you're doing what you intend to do? Maybe you need to slow down a bit? > ---------- Forwarded message --------- > From: Russell King (Oracle) <linux@armlinux.org.uk> > Date: Mon, Sep 5, 2022 at 3:50 PM > Subject: Re: [PATCH 6/6] gpio: macsmc: Add IRQ support > To: Linus Walleij <linus.walleij@linaro.org> > Cc: Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee@kernel.org>, Alyssa > Rosenzweig <alyssa@rosenzweig.io>, <asahi@lists.linux.dev>, Bartosz > Golaszewski <brgl@bgdev.pl>, Hector Martin <marcan@marcan.st>, > <linux-arm-kernel@lists.infradead.org>, <linux-gpio@vger.kernel.org>, > Sven Peter <sven@svenpeter.dev> > > > On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > > On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); > > > > Please rename irq_unmasked_shadow as it is tracking > > this and not what the irqchip core calls enabled/disabled. > > > > > + DECLARE_BITMAP(irq_enable, MAX_GPIO); > > > > I think this state should be possible to set/get from the irqchip > > core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. > > I think you're getting the two mixed up. irq_enable_shadow > (irq_unmasked_shadow) is updated from the ->irq_mask and ->irq_unmask > callbacaks, and will track !irqd_irq_masked(d) state. So, I think we > can get rid of irq_enable_shadow and just use !irqd_irq_masked(d). > > The irq_enable bit array tracks the state on the SMC, and is used to > indicate whether we need to update that state when we unlock the bus > (which is when the driver talks to the SMC to reconfigure it.) > > So, I think killing irq_enable_shadow and replacing irq_enable with > irq_unmasked would be correct - and going a bit further, > irq_smc_unmasked to show that it's the SMC's status. > > > > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > > > +{ > > > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > > > + u16 type = event >> 16; > > > + u8 offset = (event >> 8) & 0xff; > > > + smc_key key = macsmc_gpio_key(offset); > > > + unsigned long flags; > > > + int ret; > > > + > > > + if (type != SMC_EV_GPIO) > > > + return NOTIFY_DONE; > > > + > > > + if (offset > MAX_GPIO) { > > > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > > > + return NOTIFY_BAD; > > > + } > > > + > > > + local_irq_save(flags); > > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > > + local_irq_restore(flags); > > > > Isn't irq_bus_lock/unlock protecting us here already? > > (I might be getting it wrong...) > > Hmm, where does irq_bus_lock get called? Given this function is called > while running a blocking notifier chain, interrupts will not be > disabled on entry to this function. I haven't found a place in the maze > of irq handling code that generic_handle_domain_irq() would end up using > the bus lock/unlock functions - and if they did, with the above IRQ > saving, the kernel would WARN() about calling mutex_lock() with IRQs > disabled. So it doesn't. > > This actually entirely negates any benefit of the kernel trying to mask > or unmask an interrupt in "hardware" while running the handler - since > macsmc_gpio_irq_bus_sync_unlock() won't be called, the state on the SMC > won't get touched. > > > Since this is coming from a notifier and not an IRQ or threaded > > IRQ I actually am a bit puzzled on how to handle it... you probably > > know it better than me, maybe ask Marc Z if anything is > > unclear. > > It's been years since I did any real platform porting work, so deep > knowledge of the IRQ subsystem has evaporated. > > > > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > > > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > > > > isn't this one of those cases where we should implement the > > irqchip callback .irq_ack() specifically for this? > > > > That callback will only be used by edge triggered IRQs but > > I guess that would realistically be all we support anyway? > > (See comment below on .set_type) > > I would imagine it depends on how the SMC GPIO interrupt works - > whether the ACK is ACK as we know it in Linux (x86 PIC) or whether > it's ACK as in a notification to the SMC that we have finished > handling the interrupt and it can send us the next interrupt. > > I suspect we don't know that level of detail of the platform, so > given that this is what the Asahi kernel does, that's the best we > have. > > > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > > +{ > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > > + int offset = irqd_to_hwirq(d); > > > + u32 mode; > > > + > > > + if (!test_bit(offset, smcgp->irq_supported)) > > > + return -EINVAL; > > > + > > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > > + case IRQ_TYPE_LEVEL_HIGH: > > > + mode = IRQ_MODE_HIGH; > > > + break; > > > + case IRQ_TYPE_LEVEL_LOW: > > > + mode = IRQ_MODE_LOW; > > > + break; > > > + case IRQ_TYPE_EDGE_RISING: > > > + mode = IRQ_MODE_RISING; > > > + break; > > > + case IRQ_TYPE_EDGE_FALLING: > > > + mode = IRQ_MODE_FALLING; > > > + break; > > > + case IRQ_TYPE_EDGE_BOTH: > > > + mode = IRQ_MODE_BOTH; > > > + break; > > > + default: > > > + return -EINVAL; > > > > I don't know how level IRQs would work on this essentially > > message-passing process context interrupt. Maybe I am getting > > it all wrong, but for level the line should be held low/high until > > the IRQ is serviced, it would be possible to test if this actually > > works by *not* servicing an IRQ and see if the SMC then sends > > another message notifier for the same IRQ. > > If level IRQs are not supported, then it's strange that the Asahi > folk have been able to reverse engineer the CMD_IRQ_MODE codes for > these states. > > Maybe the SMC issues another message for a level IRQ after it receives > a CMD_IRQ_ACK message if the level interrupt is still asserted? > > > I strongly suspect that actually only edges are supported, but > > there might be semantics I don't understand here. > > > > > } > > > > > > + smcgp->irq_mode_shadow[offset] = mode; > > > > Hm yeah I guess this shadow mode is necessary for the sync > > to work. > > Ineed. > > > > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > > > +{ > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > > > + int offset = irqd_to_hwirq(d); > > > + bool val; > > > + > > > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > > > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > > > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > > > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > > > + else > > > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > > > + } > > > + > > > + val = test_bit(offset, smcgp->irq_enable_shadow); > > > + if (test_bit(offset, smcgp->irq_enable) != val) { > > > > So what you want to know for each line is (correct me if I'm wrong): > > - Is it enabled (unmasked) or not? > > - Did it get changed enabled->disabled, disabled->enabled since > > macsmc_gpio_irq_bus_lock()? > > I think you mean here "did the 'enable' state change between > macsmc_gpio_irq_bus_lock() and macsmc_gpio_irq_bus_unlock". > > > Doesn't the irqchip core track the first part of this for you? > > irqd_irq_masked(d) should tell you the same thing as > > irq_enable, just inverted. > > > > irq_enable_shadow is a bit tricker, I guess you might need that since > > the irqchip doesn't track state changes. > > Yep, which is what I've said above in this reply where these bitmaps > are declared. > > > > static int macsmc_gpio_probe(struct platform_device *pdev) > > > { > > > struct macsmc_gpio *smcgp; > > > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > > > smcgp->gc.base = -1; > > > smcgp->gc.parent = &pdev->dev; > > > > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > > + smcgp->gc.irq.parent_handler = NULL; > > > + smcgp->gc.irq.num_parents = 0; > > > + smcgp->gc.irq.parents = NULL; > > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > > + smcgp->gc.irq.handler = handle_simple_irq; > > > > I would consider setting this to handle_edge_irq() and implement > > .irq_ack(). I might be wrong. > > I don't think that's suitable, because then we'll be calling irq_ack() > before the handler has run - and we won't be notifying the SMC that > the interrupt has been masked. So it could send another notification > for the same IRQ while it's still being handled. Then there's the > question about level IRQs as well. > > I think, given that I don't know how the SMC works (presumably the > Asahi folk have a bit more of an idea, but that will be based on > reverse engineering effort) that I am not going to modify this driver's > behaviour drastically by changing the flow handler to the edge flow > handler from the simple flow. To me, that could well be a disaster > for this driver. That would be something for the Asahi folk to look > at. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! > > > -- > With Best Regards, > Andy Shevchenko > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: Fwd: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-05 21:43 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-05 21:43 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm Mailing List, open list:GPIO SUBSYSTEM, Sven Peter On Mon, Sep 05, 2022 at 04:19:22PM +0300, Andy Shevchenko wrote: > (Replied privately to Russell by a mistake) What are you doing? This email you've forwarded is not your own email that you sent to me privately but my reply to LinusW that was on the list. Are you okay, or is this a result of you rushing and not making sure that you're doing what you intend to do? Maybe you need to slow down a bit? > ---------- Forwarded message --------- > From: Russell King (Oracle) <linux@armlinux.org.uk> > Date: Mon, Sep 5, 2022 at 3:50 PM > Subject: Re: [PATCH 6/6] gpio: macsmc: Add IRQ support > To: Linus Walleij <linus.walleij@linaro.org> > Cc: Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee@kernel.org>, Alyssa > Rosenzweig <alyssa@rosenzweig.io>, <asahi@lists.linux.dev>, Bartosz > Golaszewski <brgl@bgdev.pl>, Hector Martin <marcan@marcan.st>, > <linux-arm-kernel@lists.infradead.org>, <linux-gpio@vger.kernel.org>, > Sven Peter <sven@svenpeter.dev> > > > On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > > On Thu, Sep 1, 2022 at 3:54 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > > + DECLARE_BITMAP(irq_enable_shadow, MAX_GPIO); > > > > Please rename irq_unmasked_shadow as it is tracking > > this and not what the irqchip core calls enabled/disabled. > > > > > + DECLARE_BITMAP(irq_enable, MAX_GPIO); > > > > I think this state should be possible to set/get from the irqchip > > core. !irqd_irq_masked(d) on the descriptor, correct me if I'm wrong. > > I think you're getting the two mixed up. irq_enable_shadow > (irq_unmasked_shadow) is updated from the ->irq_mask and ->irq_unmask > callbacaks, and will track !irqd_irq_masked(d) state. So, I think we > can get rid of irq_enable_shadow and just use !irqd_irq_masked(d). > > The irq_enable bit array tracks the state on the SMC, and is used to > indicate whether we need to update that state when we unlock the bus > (which is when the driver talks to the SMC to reconfigure it.) > > So, I think killing irq_enable_shadow and replacing irq_enable with > irq_unmasked would be correct - and going a bit further, > irq_smc_unmasked to show that it's the SMC's status. > > > > +static int macsmc_gpio_event(struct notifier_block *nb, unsigned long event, void *data) > > > +{ > > > + struct macsmc_gpio *smcgp = container_of(nb, struct macsmc_gpio, nb); > > > + u16 type = event >> 16; > > > + u8 offset = (event >> 8) & 0xff; > > > + smc_key key = macsmc_gpio_key(offset); > > > + unsigned long flags; > > > + int ret; > > > + > > > + if (type != SMC_EV_GPIO) > > > + return NOTIFY_DONE; > > > + > > > + if (offset > MAX_GPIO) { > > > + dev_err(smcgp->dev, "GPIO event index %d out of range\n", offset); > > > + return NOTIFY_BAD; > > > + } > > > + > > > + local_irq_save(flags); > > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > > + local_irq_restore(flags); > > > > Isn't irq_bus_lock/unlock protecting us here already? > > (I might be getting it wrong...) > > Hmm, where does irq_bus_lock get called? Given this function is called > while running a blocking notifier chain, interrupts will not be > disabled on entry to this function. I haven't found a place in the maze > of irq handling code that generic_handle_domain_irq() would end up using > the bus lock/unlock functions - and if they did, with the above IRQ > saving, the kernel would WARN() about calling mutex_lock() with IRQs > disabled. So it doesn't. > > This actually entirely negates any benefit of the kernel trying to mask > or unmask an interrupt in "hardware" while running the handler - since > macsmc_gpio_irq_bus_sync_unlock() won't be called, the state on the SMC > won't get touched. > > > Since this is coming from a notifier and not an IRQ or threaded > > IRQ I actually am a bit puzzled on how to handle it... you probably > > know it better than me, maybe ask Marc Z if anything is > > unclear. > > It's been years since I did any real platform porting work, so deep > knowledge of the IRQ subsystem has evaporated. > > > > + if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > > > + dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > > > > isn't this one of those cases where we should implement the > > irqchip callback .irq_ack() specifically for this? > > > > That callback will only be used by edge triggered IRQs but > > I guess that would realistically be all we support anyway? > > (See comment below on .set_type) > > I would imagine it depends on how the SMC GPIO interrupt works - > whether the ACK is ACK as we know it in Linux (x86 PIC) or whether > it's ACK as in a notification to the SMC that we have finished > handling the interrupt and it can send us the next interrupt. > > I suspect we don't know that level of detail of the platform, so > given that this is what the Asahi kernel does, that's the best we > have. > > > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > > +{ > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > > + int offset = irqd_to_hwirq(d); > > > + u32 mode; > > > + > > > + if (!test_bit(offset, smcgp->irq_supported)) > > > + return -EINVAL; > > > + > > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > > + case IRQ_TYPE_LEVEL_HIGH: > > > + mode = IRQ_MODE_HIGH; > > > + break; > > > + case IRQ_TYPE_LEVEL_LOW: > > > + mode = IRQ_MODE_LOW; > > > + break; > > > + case IRQ_TYPE_EDGE_RISING: > > > + mode = IRQ_MODE_RISING; > > > + break; > > > + case IRQ_TYPE_EDGE_FALLING: > > > + mode = IRQ_MODE_FALLING; > > > + break; > > > + case IRQ_TYPE_EDGE_BOTH: > > > + mode = IRQ_MODE_BOTH; > > > + break; > > > + default: > > > + return -EINVAL; > > > > I don't know how level IRQs would work on this essentially > > message-passing process context interrupt. Maybe I am getting > > it all wrong, but for level the line should be held low/high until > > the IRQ is serviced, it would be possible to test if this actually > > works by *not* servicing an IRQ and see if the SMC then sends > > another message notifier for the same IRQ. > > If level IRQs are not supported, then it's strange that the Asahi > folk have been able to reverse engineer the CMD_IRQ_MODE codes for > these states. > > Maybe the SMC issues another message for a level IRQ after it receives > a CMD_IRQ_ACK message if the level interrupt is still asserted? > > > I strongly suspect that actually only edges are supported, but > > there might be semantics I don't understand here. > > > > > } > > > > > > + smcgp->irq_mode_shadow[offset] = mode; > > > > Hm yeah I guess this shadow mode is necessary for the sync > > to work. > > Ineed. > > > > +static void macsmc_gpio_irq_bus_sync_unlock(struct irq_data *d) > > > +{ > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > > + smc_key key = macsmc_gpio_key(irqd_to_hwirq(d)); > > > + int offset = irqd_to_hwirq(d); > > > + bool val; > > > + > > > + if (smcgp->irq_mode_shadow[offset] != smcgp->irq_mode[offset]) { > > > + u32 cmd = CMD_IRQ_MODE | smcgp->irq_mode_shadow[offset]; > > > + if (apple_smc_write_u32(smcgp->smc, key, cmd) < 0) > > > + dev_err(smcgp->dev, "GPIO IRQ config failed for %p4ch = 0x%x\n", &key, cmd); > > > + else > > > + smcgp->irq_mode_shadow[offset] = smcgp->irq_mode[offset]; > > > + } > > > + > > > + val = test_bit(offset, smcgp->irq_enable_shadow); > > > + if (test_bit(offset, smcgp->irq_enable) != val) { > > > > So what you want to know for each line is (correct me if I'm wrong): > > - Is it enabled (unmasked) or not? > > - Did it get changed enabled->disabled, disabled->enabled since > > macsmc_gpio_irq_bus_lock()? > > I think you mean here "did the 'enable' state change between > macsmc_gpio_irq_bus_lock() and macsmc_gpio_irq_bus_unlock". > > > Doesn't the irqchip core track the first part of this for you? > > irqd_irq_masked(d) should tell you the same thing as > > irq_enable, just inverted. > > > > irq_enable_shadow is a bit tricker, I guess you might need that since > > the irqchip doesn't track state changes. > > Yep, which is what I've said above in this reply where these bitmaps > are declared. > > > > static int macsmc_gpio_probe(struct platform_device *pdev) > > > { > > > struct macsmc_gpio *smcgp; > > > @@ -221,6 +365,18 @@ static int macsmc_gpio_probe(struct platform_device *pdev) > > > smcgp->gc.base = -1; > > > smcgp->gc.parent = &pdev->dev; > > > > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > > + smcgp->gc.irq.parent_handler = NULL; > > > + smcgp->gc.irq.num_parents = 0; > > > + smcgp->gc.irq.parents = NULL; > > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > > + smcgp->gc.irq.handler = handle_simple_irq; > > > > I would consider setting this to handle_edge_irq() and implement > > .irq_ack(). I might be wrong. > > I don't think that's suitable, because then we'll be calling irq_ack() > before the handler has run - and we won't be notifying the SMC that > the interrupt has been masked. So it could send another notification > for the same IRQ while it's still being handled. Then there's the > question about level IRQs as well. > > I think, given that I don't know how the SMC works (presumably the > Asahi folk have a bit more of an idea, but that will be based on > reverse engineering effort) that I am not going to modify this driver's > behaviour drastically by changing the flow handler to the edge flow > handler from the simple flow. To me, that could well be a disaster > for this driver. That would be something for the Asahi folk to look > at. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! > > > -- > With Best Regards, > Andy Shevchenko > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-05 12:47 ` Russell King (Oracle) @ 2022-09-05 13:27 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-05 13:27 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Sep 5, 2022 at 2:47 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > > > + local_irq_save(flags); > > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > > + local_irq_restore(flags); > > > > Isn't irq_bus_lock/unlock protecting us here already? > > (I might be getting it wrong...) > > Hmm, where does irq_bus_lock get called? Given this function is called > while running a blocking notifier chain, interrupts will not be > disabled on entry to this function. I haven't found a place in the maze > of irq handling code that generic_handle_domain_irq() would end up using > the bus lock/unlock functions - and if they did, with the above IRQ > saving, the kernel would WARN() about calling mutex_lock() with IRQs > disabled. So it doesn't. Ah I get it now, the notification mechanism goes entirely orthogonal to the irqchip, that's what got me confused. You're right, keep this. > > That callback will only be used by edge triggered IRQs but > > I guess that would realistically be all we support anyway? > > (See comment below on .set_type) > > I would imagine it depends on how the SMC GPIO interrupt works - > whether the ACK is ACK as we know it in Linux (x86 PIC) or whether > it's ACK as in a notification to the SMC that we have finished > handling the interrupt and it can send us the next interrupt. > > I suspect we don't know that level of detail of the platform, so > given that this is what the Asahi kernel does, that's the best we > have. OK > > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > > +{ > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > > + int offset = irqd_to_hwirq(d); > > > + u32 mode; > > > + > > > + if (!test_bit(offset, smcgp->irq_supported)) > > > + return -EINVAL; > > > + > > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > > + case IRQ_TYPE_LEVEL_HIGH: > > > + mode = IRQ_MODE_HIGH; > > > + break; > > > + case IRQ_TYPE_LEVEL_LOW: > > > + mode = IRQ_MODE_LOW; > > > + break; > > > + case IRQ_TYPE_EDGE_RISING: > > > + mode = IRQ_MODE_RISING; > > > + break; > > > + case IRQ_TYPE_EDGE_FALLING: > > > + mode = IRQ_MODE_FALLING; > > > + break; > > > + case IRQ_TYPE_EDGE_BOTH: > > > + mode = IRQ_MODE_BOTH; > > > + break; > > > + default: > > > + return -EINVAL; > > > > I don't know how level IRQs would work on this essentially > > message-passing process context interrupt. Maybe I am getting > > it all wrong, but for level the line should be held low/high until > > the IRQ is serviced, it would be possible to test if this actually > > works by *not* servicing an IRQ and see if the SMC then sends > > another message notifier for the same IRQ. > > If level IRQs are not supported, then it's strange that the Asahi > folk have been able to reverse engineer the CMD_IRQ_MODE codes for > these states. > > Maybe the SMC issues another message for a level IRQ after it receives > a CMD_IRQ_ACK message if the level interrupt is still asserted? (...) > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > > + smcgp->gc.irq.parent_handler = NULL; > > > + smcgp->gc.irq.num_parents = 0; > > > + smcgp->gc.irq.parents = NULL; > > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > > + smcgp->gc.irq.handler = handle_simple_irq; > > > > I would consider setting this to handle_edge_irq() and implement > > .irq_ack(). I might be wrong. > > I don't think that's suitable, because then we'll be calling irq_ack() > before the handler has run - and we won't be notifying the SMC that > the interrupt has been masked. So it could send another notification > for the same IRQ while it's still being handled. Then there's the > question about level IRQs as well. > > I think, given that I don't know how the SMC works (presumably the > Asahi folk have a bit more of an idea, but that will be based on > reverse engineering effort) that I am not going to modify this driver's > behaviour drastically by changing the flow handler to the edge flow > handler from the simple flow. To me, that could well be a disaster > for this driver. That would be something for the Asahi folk to look > at. Fair enough. From my end this will be fine to merge after you considered the things brought up and it is certainly not necessary to have any "perfect" solution, to me it is clear that what we need to do is enable the target so that people can use it and then we/Asahi can comb through it and reexamine things like this once the whole system is usable as a whole. I've seen that Konrad has even started using the M1 infrastructure to kickstart a few iPhone/iPad devices, so given how much hardware this is (in absolute units) I think it's pretty important we get to usable ASAP. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-05 13:27 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-09-05 13:27 UTC (permalink / raw) To: Russell King (Oracle) Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, Hector Martin, linux-arm-kernel, linux-gpio, Sven Peter On Mon, Sep 5, 2022 at 2:47 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > On Fri, Sep 02, 2022 at 03:21:31PM +0200, Linus Walleij wrote: > > > + local_irq_save(flags); > > > + ret = generic_handle_domain_irq(smcgp->gc.irq.domain, offset); > > > + local_irq_restore(flags); > > > > Isn't irq_bus_lock/unlock protecting us here already? > > (I might be getting it wrong...) > > Hmm, where does irq_bus_lock get called? Given this function is called > while running a blocking notifier chain, interrupts will not be > disabled on entry to this function. I haven't found a place in the maze > of irq handling code that generic_handle_domain_irq() would end up using > the bus lock/unlock functions - and if they did, with the above IRQ > saving, the kernel would WARN() about calling mutex_lock() with IRQs > disabled. So it doesn't. Ah I get it now, the notification mechanism goes entirely orthogonal to the irqchip, that's what got me confused. You're right, keep this. > > That callback will only be used by edge triggered IRQs but > > I guess that would realistically be all we support anyway? > > (See comment below on .set_type) > > I would imagine it depends on how the SMC GPIO interrupt works - > whether the ACK is ACK as we know it in Linux (x86 PIC) or whether > it's ACK as in a notification to the SMC that we have finished > handling the interrupt and it can send us the next interrupt. > > I suspect we don't know that level of detail of the platform, so > given that this is what the Asahi kernel does, that's the best we > have. OK > > > +static int macsmc_gpio_irq_set_type(struct irq_data *d, unsigned int type) > > > +{ > > > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > > > + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); > > > + int offset = irqd_to_hwirq(d); > > > + u32 mode; > > > + > > > + if (!test_bit(offset, smcgp->irq_supported)) > > > + return -EINVAL; > > > + > > > + switch (type & IRQ_TYPE_SENSE_MASK) { > > > + case IRQ_TYPE_LEVEL_HIGH: > > > + mode = IRQ_MODE_HIGH; > > > + break; > > > + case IRQ_TYPE_LEVEL_LOW: > > > + mode = IRQ_MODE_LOW; > > > + break; > > > + case IRQ_TYPE_EDGE_RISING: > > > + mode = IRQ_MODE_RISING; > > > + break; > > > + case IRQ_TYPE_EDGE_FALLING: > > > + mode = IRQ_MODE_FALLING; > > > + break; > > > + case IRQ_TYPE_EDGE_BOTH: > > > + mode = IRQ_MODE_BOTH; > > > + break; > > > + default: > > > + return -EINVAL; > > > > I don't know how level IRQs would work on this essentially > > message-passing process context interrupt. Maybe I am getting > > it all wrong, but for level the line should be held low/high until > > the IRQ is serviced, it would be possible to test if this actually > > works by *not* servicing an IRQ and see if the SMC then sends > > another message notifier for the same IRQ. > > If level IRQs are not supported, then it's strange that the Asahi > folk have been able to reverse engineer the CMD_IRQ_MODE codes for > these states. > > Maybe the SMC issues another message for a level IRQ after it receives > a CMD_IRQ_ACK message if the level interrupt is still asserted? (...) > > > + gpio_irq_chip_set_chip(&smcgp->gc.irq, &macsmc_gpio_irqchip); > > > + smcgp->gc.irq.parent_handler = NULL; > > > + smcgp->gc.irq.num_parents = 0; > > > + smcgp->gc.irq.parents = NULL; > > > + smcgp->gc.irq.default_type = IRQ_TYPE_NONE; > > > + smcgp->gc.irq.handler = handle_simple_irq; > > > > I would consider setting this to handle_edge_irq() and implement > > .irq_ack(). I might be wrong. > > I don't think that's suitable, because then we'll be calling irq_ack() > before the handler has run - and we won't be notifying the SMC that > the interrupt has been masked. So it could send another notification > for the same IRQ while it's still being handled. Then there's the > question about level IRQs as well. > > I think, given that I don't know how the SMC works (presumably the > Asahi folk have a bit more of an idea, but that will be based on > reverse engineering effort) that I am not going to modify this driver's > behaviour drastically by changing the flow handler to the edge flow > handler from the simple flow. To me, that could well be a disaster > for this driver. That would be something for the Asahi folk to look > at. Fair enough. From my end this will be fine to merge after you considered the things brought up and it is certainly not necessary to have any "perfect" solution, to me it is clear that what we need to do is enable the target so that people can use it and then we/Asahi can comb through it and reexamine things like this once the whole system is usable as a whole. I've seen that Konrad has even started using the M1 infrastructure to kickstart a few iPhone/iPad devices, so given how much hardware this is (in absolute units) I think it's pretty important we get to usable ASAP. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-02 13:21 ` Linus Walleij @ 2022-09-06 7:00 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 7:00 UTC (permalink / raw) To: Linus Walleij, Russell King Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 02/09/2022 22.21, Linus Walleij wrote: >> + switch (type & IRQ_TYPE_SENSE_MASK) { >> + case IRQ_TYPE_LEVEL_HIGH: >> + mode = IRQ_MODE_HIGH; >> + break; >> + case IRQ_TYPE_LEVEL_LOW: >> + mode = IRQ_MODE_LOW; >> + break; >> + case IRQ_TYPE_EDGE_RISING: >> + mode = IRQ_MODE_RISING; >> + break; >> + case IRQ_TYPE_EDGE_FALLING: >> + mode = IRQ_MODE_FALLING; >> + break; >> + case IRQ_TYPE_EDGE_BOTH: >> + mode = IRQ_MODE_BOTH; >> + break; >> + default: >> + return -EINVAL; > > I don't know how level IRQs would work on this essentially > message-passing process context interrupt. Maybe I am getting > it all wrong, but for level the line should be held low/high until > the IRQ is serviced, it would be possible to test if this actually > works by *not* servicing an IRQ and see if the SMC then sends > another message notifier for the same IRQ. > > I strongly suspect that actually only edges are supported, but > there might be semantics I don't understand here. IIRC that is exactly what happens - the SMC will re-fire the IRQ after the ACK if it is set to level mode and still at the active level. I do remember testing all the modes carefully when implementing this to figure out what the precise semantics are, and I *think* I agonized over the flow handlers quite a bit and decided this way would work properly for all the modes, but it's been a while so I'd have to take a look again to convince myself again :) - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-06 7:00 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 7:00 UTC (permalink / raw) To: Linus Walleij, Russell King Cc: Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 02/09/2022 22.21, Linus Walleij wrote: >> + switch (type & IRQ_TYPE_SENSE_MASK) { >> + case IRQ_TYPE_LEVEL_HIGH: >> + mode = IRQ_MODE_HIGH; >> + break; >> + case IRQ_TYPE_LEVEL_LOW: >> + mode = IRQ_MODE_LOW; >> + break; >> + case IRQ_TYPE_EDGE_RISING: >> + mode = IRQ_MODE_RISING; >> + break; >> + case IRQ_TYPE_EDGE_FALLING: >> + mode = IRQ_MODE_FALLING; >> + break; >> + case IRQ_TYPE_EDGE_BOTH: >> + mode = IRQ_MODE_BOTH; >> + break; >> + default: >> + return -EINVAL; > > I don't know how level IRQs would work on this essentially > message-passing process context interrupt. Maybe I am getting > it all wrong, but for level the line should be held low/high until > the IRQ is serviced, it would be possible to test if this actually > works by *not* servicing an IRQ and see if the SMC then sends > another message notifier for the same IRQ. > > I strongly suspect that actually only edges are supported, but > there might be semantics I don't understand here. IIRC that is exactly what happens - the SMC will re-fire the IRQ after the ACK if it is set to level mode and still at the active level. I do remember testing all the modes carefully when implementing this to figure out what the precise semantics are, and I *think* I agonized over the flow handlers quite a bit and decided this way would work properly for all the modes, but it's been a while so I'd have to take a look again to convince myself again :) - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-06 7:00 ` Hector Martin @ 2022-09-06 7:47 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 7:47 UTC (permalink / raw) To: Hector Martin Cc: Linus Walleij, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Tue, Sep 06, 2022 at 04:00:31PM +0900, Hector Martin wrote: > On 02/09/2022 22.21, Linus Walleij wrote: > >> + switch (type & IRQ_TYPE_SENSE_MASK) { > >> + case IRQ_TYPE_LEVEL_HIGH: > >> + mode = IRQ_MODE_HIGH; > >> + break; > >> + case IRQ_TYPE_LEVEL_LOW: > >> + mode = IRQ_MODE_LOW; > >> + break; > >> + case IRQ_TYPE_EDGE_RISING: > >> + mode = IRQ_MODE_RISING; > >> + break; > >> + case IRQ_TYPE_EDGE_FALLING: > >> + mode = IRQ_MODE_FALLING; > >> + break; > >> + case IRQ_TYPE_EDGE_BOTH: > >> + mode = IRQ_MODE_BOTH; > >> + break; > >> + default: > >> + return -EINVAL; > > > > I don't know how level IRQs would work on this essentially > > message-passing process context interrupt. Maybe I am getting > > it all wrong, but for level the line should be held low/high until > > the IRQ is serviced, it would be possible to test if this actually > > works by *not* servicing an IRQ and see if the SMC then sends > > another message notifier for the same IRQ. > > > > I strongly suspect that actually only edges are supported, but > > there might be semantics I don't understand here. > > IIRC that is exactly what happens - the SMC will re-fire the IRQ after > the ACK if it is set to level mode and still at the active level. > > I do remember testing all the modes carefully when implementing this to > figure out what the precise semantics are, and I *think* I agonized over > the flow handlers quite a bit and decided this way would work properly > for all the modes, but it's been a while so I'd have to take a look > again to convince myself again :) Thanks for the clarification - I think it would be useful to put some of that as comments before the CMD_IRQ_ACK write to head off any questions about this in the future. Something like this maybe? /* * This is not an "ack" int he i8253 PIC sense - it is used for level * interrupts as well. The SMC will re-fire the interrupt event after * this ACK if the level interrupt is still active. */ if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-06 7:47 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-09-06 7:47 UTC (permalink / raw) To: Hector Martin Cc: Linus Walleij, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On Tue, Sep 06, 2022 at 04:00:31PM +0900, Hector Martin wrote: > On 02/09/2022 22.21, Linus Walleij wrote: > >> + switch (type & IRQ_TYPE_SENSE_MASK) { > >> + case IRQ_TYPE_LEVEL_HIGH: > >> + mode = IRQ_MODE_HIGH; > >> + break; > >> + case IRQ_TYPE_LEVEL_LOW: > >> + mode = IRQ_MODE_LOW; > >> + break; > >> + case IRQ_TYPE_EDGE_RISING: > >> + mode = IRQ_MODE_RISING; > >> + break; > >> + case IRQ_TYPE_EDGE_FALLING: > >> + mode = IRQ_MODE_FALLING; > >> + break; > >> + case IRQ_TYPE_EDGE_BOTH: > >> + mode = IRQ_MODE_BOTH; > >> + break; > >> + default: > >> + return -EINVAL; > > > > I don't know how level IRQs would work on this essentially > > message-passing process context interrupt. Maybe I am getting > > it all wrong, but for level the line should be held low/high until > > the IRQ is serviced, it would be possible to test if this actually > > works by *not* servicing an IRQ and see if the SMC then sends > > another message notifier for the same IRQ. > > > > I strongly suspect that actually only edges are supported, but > > there might be semantics I don't understand here. > > IIRC that is exactly what happens - the SMC will re-fire the IRQ after > the ACK if it is set to level mode and still at the active level. > > I do remember testing all the modes carefully when implementing this to > figure out what the precise semantics are, and I *think* I agonized over > the flow handlers quite a bit and decided this way would work properly > for all the modes, but it's been a while so I'd have to take a look > again to convince myself again :) Thanks for the clarification - I think it would be useful to put some of that as comments before the CMD_IRQ_ACK write to head off any questions about this in the future. Something like this maybe? /* * This is not an "ack" int he i8253 PIC sense - it is used for level * interrupts as well. The SMC will re-fire the interrupt event after * this ACK if the level interrupt is still active. */ if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support 2022-09-06 7:47 ` Russell King (Oracle) @ 2022-09-06 8:00 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 8:00 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 06/09/2022 16.47, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 04:00:31PM +0900, Hector Martin wrote: >> On 02/09/2022 22.21, Linus Walleij wrote: >>>> + switch (type & IRQ_TYPE_SENSE_MASK) { >>>> + case IRQ_TYPE_LEVEL_HIGH: >>>> + mode = IRQ_MODE_HIGH; >>>> + break; >>>> + case IRQ_TYPE_LEVEL_LOW: >>>> + mode = IRQ_MODE_LOW; >>>> + break; >>>> + case IRQ_TYPE_EDGE_RISING: >>>> + mode = IRQ_MODE_RISING; >>>> + break; >>>> + case IRQ_TYPE_EDGE_FALLING: >>>> + mode = IRQ_MODE_FALLING; >>>> + break; >>>> + case IRQ_TYPE_EDGE_BOTH: >>>> + mode = IRQ_MODE_BOTH; >>>> + break; >>>> + default: >>>> + return -EINVAL; >>> >>> I don't know how level IRQs would work on this essentially >>> message-passing process context interrupt. Maybe I am getting >>> it all wrong, but for level the line should be held low/high until >>> the IRQ is serviced, it would be possible to test if this actually >>> works by *not* servicing an IRQ and see if the SMC then sends >>> another message notifier for the same IRQ. >>> >>> I strongly suspect that actually only edges are supported, but >>> there might be semantics I don't understand here. >> >> IIRC that is exactly what happens - the SMC will re-fire the IRQ after >> the ACK if it is set to level mode and still at the active level. >> >> I do remember testing all the modes carefully when implementing this to >> figure out what the precise semantics are, and I *think* I agonized over >> the flow handlers quite a bit and decided this way would work properly >> for all the modes, but it's been a while so I'd have to take a look >> again to convince myself again :) > > Thanks for the clarification - I think it would be useful to put some > of that as comments before the CMD_IRQ_ACK write to head off any > questions about this in the future. Something like this maybe? > > /* > * This is not an "ack" int he i8253 PIC sense - it is used for level > * interrupts as well. The SMC will re-fire the interrupt event after > * this ACK if the level interrupt is still active. > */ > if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > Sounds good to me! (nit: typo on "int he") - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support @ 2022-09-06 8:00 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-09-06 8:00 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Arnd Bergmann, Lee Jones, Alyssa Rosenzweig, asahi, Bartosz Golaszewski, linux-arm-kernel, linux-gpio, Sven Peter On 06/09/2022 16.47, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 04:00:31PM +0900, Hector Martin wrote: >> On 02/09/2022 22.21, Linus Walleij wrote: >>>> + switch (type & IRQ_TYPE_SENSE_MASK) { >>>> + case IRQ_TYPE_LEVEL_HIGH: >>>> + mode = IRQ_MODE_HIGH; >>>> + break; >>>> + case IRQ_TYPE_LEVEL_LOW: >>>> + mode = IRQ_MODE_LOW; >>>> + break; >>>> + case IRQ_TYPE_EDGE_RISING: >>>> + mode = IRQ_MODE_RISING; >>>> + break; >>>> + case IRQ_TYPE_EDGE_FALLING: >>>> + mode = IRQ_MODE_FALLING; >>>> + break; >>>> + case IRQ_TYPE_EDGE_BOTH: >>>> + mode = IRQ_MODE_BOTH; >>>> + break; >>>> + default: >>>> + return -EINVAL; >>> >>> I don't know how level IRQs would work on this essentially >>> message-passing process context interrupt. Maybe I am getting >>> it all wrong, but for level the line should be held low/high until >>> the IRQ is serviced, it would be possible to test if this actually >>> works by *not* servicing an IRQ and see if the SMC then sends >>> another message notifier for the same IRQ. >>> >>> I strongly suspect that actually only edges are supported, but >>> there might be semantics I don't understand here. >> >> IIRC that is exactly what happens - the SMC will re-fire the IRQ after >> the ACK if it is set to level mode and still at the active level. >> >> I do remember testing all the modes carefully when implementing this to >> figure out what the precise semantics are, and I *think* I agonized over >> the flow handlers quite a bit and decided this way would work properly >> for all the modes, but it's been a while so I'd have to take a look >> again to convince myself again :) > > Thanks for the clarification - I think it would be useful to put some > of that as comments before the CMD_IRQ_ACK write to head off any > questions about this in the future. Something like this maybe? > > /* > * This is not an "ack" int he i8253 PIC sense - it is used for level > * interrupts as well. The SMC will re-fire the interrupt event after > * this ACK if the level interrupt is still active. > */ > if (apple_smc_write_u32(smcgp->smc, key, CMD_IRQ_ACK | 1) < 0) > dev_err(smcgp->dev, "GPIO IRQ ack failed for %p4ch\n", &key); > Sounds good to me! (nit: typo on "int he") - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 0/6] Add Apple Mac System Management Controller GPIOs 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-09-01 15:12 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:12 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, devicetree, Hector Martin, Krzysztof Kozlowski, linux-arm-kernel, linux-gpio, Rob Herring, Sven Peter On 01/09/2022 16:54, Russell King (Oracle) wrote: > Hi, > > This series adds support for the Apple Mac GPIO driver. These GPIOs > are hadled via the System Management Controller. > Thank you for your patch. There is something to discuss/improve. > The first two patches add the DT binding documentation for the new > drivers. > > The second two patches add the core System Management Controller > support. > > The last two patches add the GPIO support. > > DT updates will follow once the bindings have been reviewed. ...and how can we validate that your DTS actually implements the bindings? Typical submission includes everything, either in one patchset or at least linked to each other so we can see the user of the bindings. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 0/6] Add Apple Mac System Management Controller GPIOs @ 2022-09-01 15:12 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-09-01 15:12 UTC (permalink / raw) To: Russell King (Oracle), Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, devicetree, Hector Martin, Krzysztof Kozlowski, linux-arm-kernel, linux-gpio, Rob Herring, Sven Peter On 01/09/2022 16:54, Russell King (Oracle) wrote: > Hi, > > This series adds support for the Apple Mac GPIO driver. These GPIOs > are hadled via the System Management Controller. > Thank you for your patch. There is something to discuss/improve. > The first two patches add the DT binding documentation for the new > drivers. > > The second two patches add the core System Management Controller > support. > > The last two patches add the GPIO support. > > DT updates will follow once the bindings have been reviewed. ...and how can we validate that your DTS actually implements the bindings? Typical submission includes everything, either in one patchset or at least linked to each other so we can see the user of the bindings. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 0/6] Add Apple Mac System Management Controller GPIOs 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-10-27 15:35 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-27 15:35 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, devicetree, Hector Martin, Krzysztof Kozlowski, linux-arm-kernel, linux-gpio, Rob Herring, Sven Peter On Thu, Sep 01, 2022 at 02:54:01PM +0100, Russell King (Oracle) wrote: > Hi, > > This series adds support for the Apple Mac GPIO driver. These GPIOs > are hadled via the System Management Controller. > > The first two patches add the DT binding documentation for the new > drivers. > > The second two patches add the core System Management Controller > support. > > The last two patches add the GPIO support. > > DT updates will follow once the bindings have been reviewed. > > Patches taken from the Asahi project. All, As the discussion on this series was _extremely_ long, and did not take account of my posting of v2, I will shortly be posting v3, but as a much smaller series. My plan is to get the two patches for GPIO driver sorted as an independent series from the rest of the patches (that being the platform or mfd bits). I believe I've addressed all the comments for the GPIO driver, so expect that part shortly. The other part will take longer due to further changes being required. Russell. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH 0/6] Add Apple Mac System Management Controller GPIOs @ 2022-10-27 15:35 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-10-27 15:35 UTC (permalink / raw) To: Arnd Bergmann, Lee Jones, Linus Walleij Cc: Alyssa Rosenzweig, asahi, Bartosz Golaszewski, devicetree, Hector Martin, Krzysztof Kozlowski, linux-arm-kernel, linux-gpio, Rob Herring, Sven Peter On Thu, Sep 01, 2022 at 02:54:01PM +0100, Russell King (Oracle) wrote: > Hi, > > This series adds support for the Apple Mac GPIO driver. These GPIOs > are hadled via the System Management Controller. > > The first two patches add the DT binding documentation for the new > drivers. > > The second two patches add the core System Management Controller > support. > > The last two patches add the GPIO support. > > DT updates will follow once the bindings have been reviewed. > > Patches taken from the Asahi project. All, As the discussion on this series was _extremely_ long, and did not take account of my posting of v2, I will shortly be posting v3, but as a much smaller series. My plan is to get the two patches for GPIO driver sorted as an independent series from the rest of the patches (that being the platform or mfd bits). I believe I've addressed all the comments for the GPIO driver, so expect that part shortly. The other part will take longer due to further changes being required. Russell. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 0/7] Add Apple Mac System Management Controller GPIOs 2022-09-01 13:54 ` Russell King (Oracle) @ 2022-11-08 16:32 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 16:32 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter Hi, This is version 3 of the series adds support for the Apple Mac GPIO driver. These GPIOs are hadled via the System Management Controller. The first patch adds the core SMC support to the MFD subsystem. Patch 2 prepares the printf code for printing generic fourccs, as required by patch 4 and 7. Patch 3 adds the DT binding documentation for the rtkit backend. Patch 4 adds the rtkit backend for the SMC core. Patch 5 adds the device tree updates for the rtkit communication channel and gpio sub device to DT. Patch 6 adds the DT binding documentation for the gpio client. Patch 7 adds the gpio client. Patches mostly taken from the Asahi project and then modified due to review comments from the previous postings. I may have missed some comments as there's been quite a lot of discussion on previous postings. Documentation/core-api/printk-formats.rst | 32 ++ .../devicetree/bindings/gpio/apple,smc-gpio.yaml | 37 ++ .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++ arch/arm64/boot/dts/apple/t8103.dtsi | 27 ++ drivers/gpio/Kconfig | 11 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 245 +++++++++++ drivers/mfd/Kconfig | 4 + drivers/mfd/Makefile | 1 + drivers/mfd/macsmc.c | 239 +++++++++++ drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 34 ++ drivers/platform/apple/Makefile | 7 + drivers/platform/apple/macsmc-rtkit.c | 455 +++++++++++++++++++++ include/linux/mfd/macsmc.h | 104 +++++ lib/test_printf.c | 39 +- lib/vsprintf.c | 35 +- 18 files changed, 1328 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml create mode 100644 drivers/gpio/gpio-macsmc.c create mode 100644 drivers/mfd/macsmc.c create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/macsmc-rtkit.c create mode 100644 include/linux/mfd/macsmc.h -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 0/7] Add Apple Mac System Management Controller GPIOs @ 2022-11-08 16:32 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 16:32 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter Hi, This is version 3 of the series adds support for the Apple Mac GPIO driver. These GPIOs are hadled via the System Management Controller. The first patch adds the core SMC support to the MFD subsystem. Patch 2 prepares the printf code for printing generic fourccs, as required by patch 4 and 7. Patch 3 adds the DT binding documentation for the rtkit backend. Patch 4 adds the rtkit backend for the SMC core. Patch 5 adds the device tree updates for the rtkit communication channel and gpio sub device to DT. Patch 6 adds the DT binding documentation for the gpio client. Patch 7 adds the gpio client. Patches mostly taken from the Asahi project and then modified due to review comments from the previous postings. I may have missed some comments as there's been quite a lot of discussion on previous postings. Documentation/core-api/printk-formats.rst | 32 ++ .../devicetree/bindings/gpio/apple,smc-gpio.yaml | 37 ++ .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++ arch/arm64/boot/dts/apple/t8103.dtsi | 27 ++ drivers/gpio/Kconfig | 11 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 245 +++++++++++ drivers/mfd/Kconfig | 4 + drivers/mfd/Makefile | 1 + drivers/mfd/macsmc.c | 239 +++++++++++ drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 34 ++ drivers/platform/apple/Makefile | 7 + drivers/platform/apple/macsmc-rtkit.c | 455 +++++++++++++++++++++ include/linux/mfd/macsmc.h | 104 +++++ lib/test_printf.c | 39 +- lib/vsprintf.c | 35 +- 18 files changed, 1328 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml create mode 100644 drivers/gpio/gpio-macsmc.c create mode 100644 drivers/mfd/macsmc.c create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/macsmc-rtkit.c create mode 100644 include/linux/mfd/macsmc.h -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements support for the SMC (System Management Controller) in Apple Macs. In contrast to the existing applesmc driver, it uses pluggable backends that allow it to support different SMC implementations, and uses the MFD subsystem to expose the core SMC functionality so that specific features (gpio, hwmon, battery, etc.) can be implemented by separate drivers in their respective downstream subsystems. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/mfd/Kconfig | 4 + drivers/mfd/Makefile | 1 + drivers/mfd/macsmc.c | 239 +++++++++++++++++++++++++++++++++++++ include/linux/mfd/macsmc.h | 104 ++++++++++++++++ 4 files changed, 348 insertions(+) create mode 100644 drivers/mfd/macsmc.c create mode 100644 include/linux/mfd/macsmc.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 8b93856de432..f73e098b7228 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -224,6 +224,10 @@ config MFD_CROS_EC_DEV To compile this driver as a module, choose M here: the module will be called cros-ec-dev. +config MFD_MACSMC + tristate + select MFD_CORE + config MFD_MADERA tristate "Cirrus Logic Madera codecs" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 7ed3ef4a698c..a5271b578d31 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_MFD_CROS_EC_DEV) += cros_ec_dev.o obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o +obj-$(CONFIG_MFD_MACSMC) += macsmc.o obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c new file mode 100644 index 000000000000..e5c3957efea4 --- /dev/null +++ b/drivers/mfd/macsmc.c @@ -0,0 +1,239 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core framework + * Copyright The Asahi Linux Contributors + */ + +#include <linux/device.h> +#include <linux/mfd/core.h> +#include <linux/mfd/macsmc.h> +#include <linux/mutex.h> +#include <linux/notifier.h> + +struct apple_smc { + struct device *dev; + + void *be_cookie; + const struct apple_smc_backend_ops *be; + + struct mutex mutex; + + u32 key_count; + smc_key first_key; + smc_key last_key; + + struct blocking_notifier_head event_handlers; +}; + +static const struct mfd_cell apple_smc_devs[] = { + MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"), + MFD_CELL_NAME("macsmc-hid"), + MFD_CELL_NAME("macsmc-power"), + MFD_CELL_NAME("macsmc-reboot"), + MFD_CELL_OF("macsmc-rtc", NULL, NULL, 0, 0, "apple,smc-rtc"), +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->read_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_read); + +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->write_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write); + +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + /* + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff + * final calls, so it doesn't really matter at that point. + */ + if (!mutex_trylock(&smc->mutex)) + return -EBUSY; + + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write_atomic); + +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_rw); + +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_by_index); + +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_info(smc->be_cookie, key, info); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_info); + +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) +{ + int start = 0, count = smc->key_count; + int ret; + + if (key <= smc->first_key) + return 0; + if (key > smc->last_key) + return smc->key_count; + + while (count > 1) { + int pivot = start + ((count - 1) >> 1); + smc_key pkey; + + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); + if (ret < 0) + return ret; + + if (pkey == key) + return pivot; + + pivot++; + + if (pkey < key) { + count -= pivot - start; + start = pivot; + } else { + count = pivot - start; + } + } + + return start; +} +EXPORT_SYMBOL(apple_smc_find_first_key_index); + +int apple_smc_get_key_count(struct apple_smc *smc) +{ + return smc->key_count; +} +EXPORT_SYMBOL(apple_smc_get_key_count); + +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) +{ + dev_dbg(smc->dev, "Event: 0x%08x\n", event); + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); +} +EXPORT_SYMBOL(apple_smc_event_received); + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_register(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_register_notifier); + +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_unregister(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_unregister_notifier); + +void *apple_smc_get_cookie(struct apple_smc *smc) +{ + return smc->be_cookie; +} +EXPORT_SYMBOL(apple_smc_get_cookie); + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) +{ + struct apple_smc *smc; + u32 count; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return ERR_PTR(-ENOMEM); + + smc->dev = dev; + smc->be_cookie = cookie; + smc->be = ops; + mutex_init(&smc->mutex); + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); + + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); + smc->key_count = be32_to_cpu(count); + + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); + + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, &smc->last_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); + + /* Enable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", + smc->key_count, &smc->first_key, &smc->last_key); + + dev_set_drvdata(dev, smc); + + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); + + return smc; +} +EXPORT_SYMBOL(apple_smc_probe); + +int apple_smc_remove(struct apple_smc *smc) +{ + mfd_remove_devices(smc->dev); + + /* Disable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + return 0; +} +EXPORT_SYMBOL(apple_smc_remove); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC core"); diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h new file mode 100644 index 000000000000..99cfa23f27bd --- /dev/null +++ b/include/linux/mfd/macsmc.h @@ -0,0 +1,104 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core definitions + * Copyright (C) The Asahi Linux Contributors + */ + +#ifndef _LINUX_MFD_MACSMC_H +#define _LINUX_MFD_MACSMC_H + +struct apple_smc; + +typedef u32 smc_key; + +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) + +#define APPLE_SMC_READABLE BIT(7) +#define APPLE_SMC_WRITABLE BIT(6) +#define APPLE_SMC_FUNCTION BIT(4) + +struct apple_smc_key_info { + u8 size; + u32 type_code; + u8 flags; +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + +int apple_smc_get_key_count(struct apple_smc *smc); +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); + +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) +{ + return apple_smc_get_key_info(smc, key, NULL) >= 0; +} + +#define APPLE_SMC_TYPE_OPS(type) \ + static inline int apple_smc_read_##type(struct apple_smc *smc, smc_key key, type *p) \ + { \ + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ + } \ + static inline int apple_smc_write_##type(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_write_##type##_atomic(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key key, \ + type w, type *r) \ + { \ + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ + } + +APPLE_SMC_TYPE_OPS(u64) +APPLE_SMC_TYPE_OPS(u32) +APPLE_SMC_TYPE_OPS(u16) +APPLE_SMC_TYPE_OPS(u8) +APPLE_SMC_TYPE_OPS(s64) +APPLE_SMC_TYPE_OPS(s32) +APPLE_SMC_TYPE_OPS(s16) +APPLE_SMC_TYPE_OPS(s8) + +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) +{ + u8 val; + int ret = apple_smc_read_u8(smc, key, &val); + if (ret < 0) + return ret; + return val ? 1 : 0; +} +#define apple_smc_write_flag apple_smc_write_u8 + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); + +/* backend interface */ + +struct apple_smc_backend_ops { + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + int (*get_key_by_index)(void *cookie, int index, smc_key *key); + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); +}; + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, + void *cookie); +void *apple_smc_get_cookie(struct apple_smc *smc); +int apple_smc_remove(struct apple_smc *smc); +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); + +#endif -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver @ 2022-11-08 16:33 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements support for the SMC (System Management Controller) in Apple Macs. In contrast to the existing applesmc driver, it uses pluggable backends that allow it to support different SMC implementations, and uses the MFD subsystem to expose the core SMC functionality so that specific features (gpio, hwmon, battery, etc.) can be implemented by separate drivers in their respective downstream subsystems. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/mfd/Kconfig | 4 + drivers/mfd/Makefile | 1 + drivers/mfd/macsmc.c | 239 +++++++++++++++++++++++++++++++++++++ include/linux/mfd/macsmc.h | 104 ++++++++++++++++ 4 files changed, 348 insertions(+) create mode 100644 drivers/mfd/macsmc.c create mode 100644 include/linux/mfd/macsmc.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 8b93856de432..f73e098b7228 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -224,6 +224,10 @@ config MFD_CROS_EC_DEV To compile this driver as a module, choose M here: the module will be called cros-ec-dev. +config MFD_MACSMC + tristate + select MFD_CORE + config MFD_MADERA tristate "Cirrus Logic Madera codecs" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 7ed3ef4a698c..a5271b578d31 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_MFD_CROS_EC_DEV) += cros_ec_dev.o obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o +obj-$(CONFIG_MFD_MACSMC) += macsmc.o obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c new file mode 100644 index 000000000000..e5c3957efea4 --- /dev/null +++ b/drivers/mfd/macsmc.c @@ -0,0 +1,239 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core framework + * Copyright The Asahi Linux Contributors + */ + +#include <linux/device.h> +#include <linux/mfd/core.h> +#include <linux/mfd/macsmc.h> +#include <linux/mutex.h> +#include <linux/notifier.h> + +struct apple_smc { + struct device *dev; + + void *be_cookie; + const struct apple_smc_backend_ops *be; + + struct mutex mutex; + + u32 key_count; + smc_key first_key; + smc_key last_key; + + struct blocking_notifier_head event_handlers; +}; + +static const struct mfd_cell apple_smc_devs[] = { + MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"), + MFD_CELL_NAME("macsmc-hid"), + MFD_CELL_NAME("macsmc-power"), + MFD_CELL_NAME("macsmc-reboot"), + MFD_CELL_OF("macsmc-rtc", NULL, NULL, 0, 0, "apple,smc-rtc"), +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->read_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_read); + +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->write_key(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write); + +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) +{ + int ret; + + /* + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff + * final calls, so it doesn't really matter at that point. + */ + if (!mutex_trylock(&smc->mutex)) + return -EBUSY; + + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_write_atomic); + +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_rw); + +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_by_index); + +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) +{ + int ret; + + mutex_lock(&smc->mutex); + ret = smc->be->get_key_info(smc->be_cookie, key, info); + mutex_unlock(&smc->mutex); + + return ret; +} +EXPORT_SYMBOL(apple_smc_get_key_info); + +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) +{ + int start = 0, count = smc->key_count; + int ret; + + if (key <= smc->first_key) + return 0; + if (key > smc->last_key) + return smc->key_count; + + while (count > 1) { + int pivot = start + ((count - 1) >> 1); + smc_key pkey; + + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); + if (ret < 0) + return ret; + + if (pkey == key) + return pivot; + + pivot++; + + if (pkey < key) { + count -= pivot - start; + start = pivot; + } else { + count = pivot - start; + } + } + + return start; +} +EXPORT_SYMBOL(apple_smc_find_first_key_index); + +int apple_smc_get_key_count(struct apple_smc *smc) +{ + return smc->key_count; +} +EXPORT_SYMBOL(apple_smc_get_key_count); + +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) +{ + dev_dbg(smc->dev, "Event: 0x%08x\n", event); + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); +} +EXPORT_SYMBOL(apple_smc_event_received); + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_register(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_register_notifier); + +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) +{ + return blocking_notifier_chain_unregister(&smc->event_handlers, n); +} +EXPORT_SYMBOL(apple_smc_unregister_notifier); + +void *apple_smc_get_cookie(struct apple_smc *smc) +{ + return smc->be_cookie; +} +EXPORT_SYMBOL(apple_smc_get_cookie); + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) +{ + struct apple_smc *smc; + u32 count; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return ERR_PTR(-ENOMEM); + + smc->dev = dev; + smc->be_cookie = cookie; + smc->be = ops; + mutex_init(&smc->mutex); + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); + + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); + smc->key_count = be32_to_cpu(count); + + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); + + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, &smc->last_key); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); + + /* Enable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", + smc->key_count, &smc->first_key, &smc->last_key); + + dev_set_drvdata(dev, smc); + + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); + if (ret) + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); + + return smc; +} +EXPORT_SYMBOL(apple_smc_probe); + +int apple_smc_remove(struct apple_smc *smc) +{ + mfd_remove_devices(smc->dev); + + /* Disable notifications */ + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); + + return 0; +} +EXPORT_SYMBOL(apple_smc_remove); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC core"); diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h new file mode 100644 index 000000000000..99cfa23f27bd --- /dev/null +++ b/include/linux/mfd/macsmc.h @@ -0,0 +1,104 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC core definitions + * Copyright (C) The Asahi Linux Contributors + */ + +#ifndef _LINUX_MFD_MACSMC_H +#define _LINUX_MFD_MACSMC_H + +struct apple_smc; + +typedef u32 smc_key; + +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) + +#define APPLE_SMC_READABLE BIT(7) +#define APPLE_SMC_WRITABLE BIT(6) +#define APPLE_SMC_FUNCTION BIT(4) + +struct apple_smc_key_info { + u8 size; + u32 type_code; + u8 flags; +}; + +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + +int apple_smc_get_key_count(struct apple_smc *smc); +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); + +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) +{ + return apple_smc_get_key_info(smc, key, NULL) >= 0; +} + +#define APPLE_SMC_TYPE_OPS(type) \ + static inline int apple_smc_read_##type(struct apple_smc *smc, smc_key key, type *p) \ + { \ + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ + } \ + static inline int apple_smc_write_##type(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_write_##type##_atomic(struct apple_smc *smc, smc_key key, type p) \ + { \ + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ + } \ + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key key, \ + type w, type *r) \ + { \ + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ + } + +APPLE_SMC_TYPE_OPS(u64) +APPLE_SMC_TYPE_OPS(u32) +APPLE_SMC_TYPE_OPS(u16) +APPLE_SMC_TYPE_OPS(u8) +APPLE_SMC_TYPE_OPS(s64) +APPLE_SMC_TYPE_OPS(s32) +APPLE_SMC_TYPE_OPS(s16) +APPLE_SMC_TYPE_OPS(s8) + +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) +{ + u8 val; + int ret = apple_smc_read_u8(smc, key, &val); + if (ret < 0) + return ret; + return val ? 1 : 0; +} +#define apple_smc_write_flag apple_smc_write_u8 + +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); + +/* backend interface */ + +struct apple_smc_backend_ops { + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, + void *rbuf, size_t rsize); + int (*get_key_by_index)(void *cookie, int index, smc_key *key); + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); +}; + +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, + void *cookie); +void *apple_smc_get_cookie(struct apple_smc *smc); +int apple_smc_remove(struct apple_smc *smc); +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); + +#endif -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver 2022-11-08 16:33 ` Russell King @ 2022-11-14 9:52 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-14 9:52 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, 08 Nov 2022, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. Could we have Russell's ASCII simplified architecture model here please? > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/mfd/Kconfig | 4 + > drivers/mfd/Makefile | 1 + > drivers/mfd/macsmc.c | 239 +++++++++++++++++++++++++++++++++++++ > include/linux/mfd/macsmc.h | 104 ++++++++++++++++ > 4 files changed, 348 insertions(+) > create mode 100644 drivers/mfd/macsmc.c > create mode 100644 include/linux/mfd/macsmc.h > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 8b93856de432..f73e098b7228 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -224,6 +224,10 @@ config MFD_CROS_EC_DEV > To compile this driver as a module, choose M here: the module will be > called cros-ec-dev. > > +config MFD_MACSMC > + tristate Is this selectable? Worth having a description? > + select MFD_CORE Help section? Copy / paste from the commit log should be enough. > config MFD_MADERA > tristate "Cirrus Logic Madera codecs" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 7ed3ef4a698c..a5271b578d31 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -17,6 +17,7 @@ obj-$(CONFIG_MFD_CROS_EC_DEV) += cros_ec_dev.o > obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > +obj-$(CONFIG_MFD_MACSMC) += macsmc.o > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c > new file mode 100644 > index 000000000000..e5c3957efea4 > --- /dev/null > +++ b/drivers/mfd/macsmc.c > @@ -0,0 +1,239 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core framework "SMC (System Management Controller)" Tiny nit: '\n' > + * Copyright The Asahi Linux Contributors Missing (C) Would you like an Author(s) line here? > + */ > + > +#include <linux/device.h> > +#include <linux/mfd/core.h> > +#include <linux/mfd/macsmc.h> > +#include <linux/mutex.h> > +#include <linux/notifier.h> > + Would you be kind enough to add a header here to describe the attributes please. Some of them are non-standard. > +struct apple_smc { > + struct device *dev; > + > + void *be_cookie; > + const struct apple_smc_backend_ops *be; > + > + struct mutex mutex; > + > + u32 key_count; > + smc_key first_key; > + smc_key last_key; > + > + struct blocking_notifier_head event_handlers; > +}; > + > +static const struct mfd_cell apple_smc_devs[] = { > + MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"), > + MFD_CELL_NAME("macsmc-hid"), > + MFD_CELL_NAME("macsmc-power"), > + MFD_CELL_NAME("macsmc-reboot"), > + MFD_CELL_OF("macsmc-rtc", NULL, NULL, 0, 0, "apple,smc-rtc"), > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->read_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_read); > + > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->write_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write); > + > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + /* > + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff > + * final calls, so it doesn't really matter at that point. > + */ > + if (!mutex_trylock(&smc->mutex)) > + return -EBUSY; > + > + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write_atomic); > + > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_rw); > + > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_by_index); > + > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_info(smc->be_cookie, key, info); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_info); > + > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) > +{ > + int start = 0, count = smc->key_count; > + int ret; > + > + if (key <= smc->first_key) > + return 0; > + if (key > smc->last_key) > + return smc->key_count; > + > + while (count > 1) { > + int pivot = start + ((count - 1) >> 1); > + smc_key pkey; > + > + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); > + if (ret < 0) > + return ret; > + > + if (pkey == key) > + return pivot; > + > + pivot++; > + > + if (pkey < key) { > + count -= pivot - start; > + start = pivot; > + } else { > + count = pivot - start; > + } > + } > + > + return start; > +} Maybe a 1 or 2 line comment to provide an overview of what's happening in here please. > +EXPORT_SYMBOL(apple_smc_find_first_key_index); > + > +int apple_smc_get_key_count(struct apple_smc *smc) > +{ > + return smc->key_count; > +} > +EXPORT_SYMBOL(apple_smc_get_key_count); > + > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) > +{ > + dev_dbg(smc->dev, "Event: 0x%08x\n", event); > + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); > +} > +EXPORT_SYMBOL(apple_smc_event_received); > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) > +{ > + return blocking_notifier_chain_register(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_register_notifier); > + > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) > +{ > + return blocking_notifier_chain_unregister(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_unregister_notifier); > + > +void *apple_smc_get_cookie(struct apple_smc *smc) > +{ > + return smc->be_cookie; > +} > +EXPORT_SYMBOL(apple_smc_get_cookie); These parts seem like abstraction for the sake of abstraction. Any reason why the caller can't use the blocking_notifier_* API and look into the apple_smc for themselves. > +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) > +{ > + struct apple_smc *smc; > + u32 count; > + int ret; > + > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > + if (!smc) > + return ERR_PTR(-ENOMEM); > + > + smc->dev = dev; > + smc->be_cookie = cookie; > + smc->be = ops; > + mutex_init(&smc->mutex); > + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); > + > + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); > + smc->key_count = be32_to_cpu(count); > + > + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); > + > + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, &smc->last_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); > + > + /* Enable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); > + > + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", > + smc->key_count, &smc->first_key, &smc->last_key); > + > + dev_set_drvdata(dev, smc); > + > + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); Please replace the -1 with the defines provided. > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); "Failed to register sub-devices" > + return smc; > +} > +EXPORT_SYMBOL(apple_smc_probe); > + > +int apple_smc_remove(struct apple_smc *smc) > +{ > + mfd_remove_devices(smc->dev); devm_*? > + /* Disable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); The same command enables and disables notifications? > + return 0; > +} > +EXPORT_SYMBOL(apple_smc_remove); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC core"); SMC (System Management Controller) > diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h > new file mode 100644 > index 000000000000..99cfa23f27bd > --- /dev/null > +++ b/include/linux/mfd/macsmc.h > @@ -0,0 +1,104 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core definitions SMC (System Management Controller) > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _LINUX_MFD_MACSMC_H > +#define _LINUX_MFD_MACSMC_H > + > +struct apple_smc; You can move the definition into here and omit this line. > +typedef u32 smc_key; > + > +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) > +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) > + > +#define APPLE_SMC_READABLE BIT(7) > +#define APPLE_SMC_WRITABLE BIT(6) > +#define APPLE_SMC_FUNCTION BIT(4) > + > +struct apple_smc_key_info { > + u8 size; > + u32 type_code; > + u8 flags; > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + > +int apple_smc_get_key_count(struct apple_smc *smc); > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); > + > +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) > +{ > + return apple_smc_get_key_info(smc, key, NULL) >= 0; > +} > + > +#define APPLE_SMC_TYPE_OPS(type) \ > + static inline int apple_smc_read_##type(struct apple_smc *smc, smc_key key, type *p) \ > + { \ > + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ > + } \ > + static inline int apple_smc_write_##type(struct apple_smc *smc, smc_key key, type p) \ > + { \ > + return apple_smc_write(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_write_##type##_atomic(struct apple_smc *smc, smc_key key, type p) \ > + { \ > + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key key, \ > + type w, type *r) \ > + { \ > + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ > + } > + > +APPLE_SMC_TYPE_OPS(u64) > +APPLE_SMC_TYPE_OPS(u32) > +APPLE_SMC_TYPE_OPS(u16) > +APPLE_SMC_TYPE_OPS(u8) > +APPLE_SMC_TYPE_OPS(s64) > +APPLE_SMC_TYPE_OPS(s32) > +APPLE_SMC_TYPE_OPS(s16) > +APPLE_SMC_TYPE_OPS(s8) > + > +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) > +{ > + u8 val; > + int ret = apple_smc_read_u8(smc, key, &val); Nit: Please separate the declaration and assignment via function call with a line break in between. > + if (ret < 0) > + return ret; > + return val ? 1 : 0; > +} > +#define apple_smc_write_flag apple_smc_write_u8 > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); > + > +/* backend interface */ > + > +struct apple_smc_backend_ops { > + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); > + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); > +}; > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, > + void *cookie); > +void *apple_smc_get_cookie(struct apple_smc *smc); > +int apple_smc_remove(struct apple_smc *smc); > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > + > +#endif -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver @ 2022-11-14 9:52 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-14 9:52 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, 08 Nov 2022, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. Could we have Russell's ASCII simplified architecture model here please? > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > drivers/mfd/Kconfig | 4 + > drivers/mfd/Makefile | 1 + > drivers/mfd/macsmc.c | 239 +++++++++++++++++++++++++++++++++++++ > include/linux/mfd/macsmc.h | 104 ++++++++++++++++ > 4 files changed, 348 insertions(+) > create mode 100644 drivers/mfd/macsmc.c > create mode 100644 include/linux/mfd/macsmc.h > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 8b93856de432..f73e098b7228 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -224,6 +224,10 @@ config MFD_CROS_EC_DEV > To compile this driver as a module, choose M here: the module will be > called cros-ec-dev. > > +config MFD_MACSMC > + tristate Is this selectable? Worth having a description? > + select MFD_CORE Help section? Copy / paste from the commit log should be enough. > config MFD_MADERA > tristate "Cirrus Logic Madera codecs" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 7ed3ef4a698c..a5271b578d31 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -17,6 +17,7 @@ obj-$(CONFIG_MFD_CROS_EC_DEV) += cros_ec_dev.o > obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > +obj-$(CONFIG_MFD_MACSMC) += macsmc.o > > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c > new file mode 100644 > index 000000000000..e5c3957efea4 > --- /dev/null > +++ b/drivers/mfd/macsmc.c > @@ -0,0 +1,239 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core framework "SMC (System Management Controller)" Tiny nit: '\n' > + * Copyright The Asahi Linux Contributors Missing (C) Would you like an Author(s) line here? > + */ > + > +#include <linux/device.h> > +#include <linux/mfd/core.h> > +#include <linux/mfd/macsmc.h> > +#include <linux/mutex.h> > +#include <linux/notifier.h> > + Would you be kind enough to add a header here to describe the attributes please. Some of them are non-standard. > +struct apple_smc { > + struct device *dev; > + > + void *be_cookie; > + const struct apple_smc_backend_ops *be; > + > + struct mutex mutex; > + > + u32 key_count; > + smc_key first_key; > + smc_key last_key; > + > + struct blocking_notifier_head event_handlers; > +}; > + > +static const struct mfd_cell apple_smc_devs[] = { > + MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"), > + MFD_CELL_NAME("macsmc-hid"), > + MFD_CELL_NAME("macsmc-power"), > + MFD_CELL_NAME("macsmc-reboot"), > + MFD_CELL_OF("macsmc-rtc", NULL, NULL, 0, 0, "apple,smc-rtc"), > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->read_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_read); > + > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->write_key(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write); > + > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size) > +{ > + int ret; > + > + /* > + * Will fail if SMC is busy. This is only used by SMC reboot/poweroff > + * final calls, so it doesn't really matter at that point. > + */ > + if (!mutex_trylock(&smc->mutex)) > + return -EBUSY; > + > + ret = smc->be->write_key_atomic(smc->be_cookie, key, buf, size); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_write_atomic); > + > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->rw_key(smc->be_cookie, key, wbuf, wsize, rbuf, rsize); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_rw); > + > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_by_index(smc->be_cookie, index, key); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_by_index); > + > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info) > +{ > + int ret; > + > + mutex_lock(&smc->mutex); > + ret = smc->be->get_key_info(smc->be_cookie, key, info); > + mutex_unlock(&smc->mutex); > + > + return ret; > +} > +EXPORT_SYMBOL(apple_smc_get_key_info); > + > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key) > +{ > + int start = 0, count = smc->key_count; > + int ret; > + > + if (key <= smc->first_key) > + return 0; > + if (key > smc->last_key) > + return smc->key_count; > + > + while (count > 1) { > + int pivot = start + ((count - 1) >> 1); > + smc_key pkey; > + > + ret = apple_smc_get_key_by_index(smc, pivot, &pkey); > + if (ret < 0) > + return ret; > + > + if (pkey == key) > + return pivot; > + > + pivot++; > + > + if (pkey < key) { > + count -= pivot - start; > + start = pivot; > + } else { > + count = pivot - start; > + } > + } > + > + return start; > +} Maybe a 1 or 2 line comment to provide an overview of what's happening in here please. > +EXPORT_SYMBOL(apple_smc_find_first_key_index); > + > +int apple_smc_get_key_count(struct apple_smc *smc) > +{ > + return smc->key_count; > +} > +EXPORT_SYMBOL(apple_smc_get_key_count); > + > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event) > +{ > + dev_dbg(smc->dev, "Event: 0x%08x\n", event); > + blocking_notifier_call_chain(&smc->event_handlers, event, NULL); > +} > +EXPORT_SYMBOL(apple_smc_event_received); > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n) > +{ > + return blocking_notifier_chain_register(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_register_notifier); > + > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n) > +{ > + return blocking_notifier_chain_unregister(&smc->event_handlers, n); > +} > +EXPORT_SYMBOL(apple_smc_unregister_notifier); > + > +void *apple_smc_get_cookie(struct apple_smc *smc) > +{ > + return smc->be_cookie; > +} > +EXPORT_SYMBOL(apple_smc_get_cookie); These parts seem like abstraction for the sake of abstraction. Any reason why the caller can't use the blocking_notifier_* API and look into the apple_smc for themselves. > +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, void *cookie) > +{ > + struct apple_smc *smc; > + u32 count; > + int ret; > + > + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); > + if (!smc) > + return ERR_PTR(-ENOMEM); > + > + smc->dev = dev; > + smc->be_cookie = cookie; > + smc->be = ops; > + mutex_init(&smc->mutex); > + BLOCKING_INIT_NOTIFIER_HEAD(&smc->event_handlers); > + > + ret = apple_smc_read_u32(smc, SMC_KEY(#KEY), &count); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get key count")); > + smc->key_count = be32_to_cpu(count); > + > + ret = apple_smc_get_key_by_index(smc, 0, &smc->first_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get first key")); > + > + ret = apple_smc_get_key_by_index(smc, smc->key_count - 1, &smc->last_key); > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Failed to get last key")); > + > + /* Enable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); > + > + dev_info(dev, "Initialized (%d keys %p4ch..%p4ch)\n", > + smc->key_count, &smc->first_key, &smc->last_key); > + > + dev_set_drvdata(dev, smc); > + > + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); Please replace the -1 with the defines provided. > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); "Failed to register sub-devices" > + return smc; > +} > +EXPORT_SYMBOL(apple_smc_probe); > + > +int apple_smc_remove(struct apple_smc *smc) > +{ > + mfd_remove_devices(smc->dev); devm_*? > + /* Disable notifications */ > + apple_smc_write_flag(smc, SMC_KEY(NTAP), 1); The same command enables and disables notifications? > + return 0; > +} > +EXPORT_SYMBOL(apple_smc_remove); > + > +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC core"); SMC (System Management Controller) > diff --git a/include/linux/mfd/macsmc.h b/include/linux/mfd/macsmc.h > new file mode 100644 > index 000000000000..99cfa23f27bd > --- /dev/null > +++ b/include/linux/mfd/macsmc.h > @@ -0,0 +1,104 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR MIT > +/* > + * Apple SMC core definitions SMC (System Management Controller) > + * Copyright (C) The Asahi Linux Contributors > + */ > + > +#ifndef _LINUX_MFD_MACSMC_H > +#define _LINUX_MFD_MACSMC_H > + > +struct apple_smc; You can move the definition into here and omit this line. > +typedef u32 smc_key; > + > +#define SMC_KEY(s) (smc_key)(_SMC_KEY(#s)) > +#define _SMC_KEY(s) (((s)[0] << 24) | ((s)[1] << 16) | ((s)[2] << 8) | (s)[3]) > + > +#define APPLE_SMC_READABLE BIT(7) > +#define APPLE_SMC_WRITABLE BIT(6) > +#define APPLE_SMC_FUNCTION BIT(4) > + > +struct apple_smc_key_info { > + u8 size; > + u32 type_code; > + u8 flags; > +}; > + > +int apple_smc_read(struct apple_smc *smc, smc_key key, void *buf, size_t size); > +int apple_smc_write(struct apple_smc *smc, smc_key key, void *buf, size_t size); > +int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, void *buf, size_t size); > +int apple_smc_rw(struct apple_smc *smc, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + > +int apple_smc_get_key_count(struct apple_smc *smc); > +int apple_smc_find_first_key_index(struct apple_smc *smc, smc_key key); > +int apple_smc_get_key_by_index(struct apple_smc *smc, int index, smc_key *key); > +int apple_smc_get_key_info(struct apple_smc *smc, smc_key key, struct apple_smc_key_info *info); > + > +static inline bool apple_smc_key_exists(struct apple_smc *smc, smc_key key) > +{ > + return apple_smc_get_key_info(smc, key, NULL) >= 0; > +} > + > +#define APPLE_SMC_TYPE_OPS(type) \ > + static inline int apple_smc_read_##type(struct apple_smc *smc, smc_key key, type *p) \ > + { \ > + int ret = apple_smc_read(smc, key, p, sizeof(*p)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*p)) ? -EINVAL : 0); \ > + } \ > + static inline int apple_smc_write_##type(struct apple_smc *smc, smc_key key, type p) \ > + { \ > + return apple_smc_write(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_write_##type##_atomic(struct apple_smc *smc, smc_key key, type p) \ > + { \ > + return apple_smc_write_atomic(smc, key, &p, sizeof(p)); \ > + } \ > + static inline int apple_smc_rw_##type(struct apple_smc *smc, smc_key key, \ > + type w, type *r) \ > + { \ > + int ret = apple_smc_rw(smc, key, &w, sizeof(w), r, sizeof(*r)); \ > + return (ret < 0) ? ret : ((ret != sizeof(*r)) ? -EINVAL : 0); \ > + } > + > +APPLE_SMC_TYPE_OPS(u64) > +APPLE_SMC_TYPE_OPS(u32) > +APPLE_SMC_TYPE_OPS(u16) > +APPLE_SMC_TYPE_OPS(u8) > +APPLE_SMC_TYPE_OPS(s64) > +APPLE_SMC_TYPE_OPS(s32) > +APPLE_SMC_TYPE_OPS(s16) > +APPLE_SMC_TYPE_OPS(s8) > + > +static inline int apple_smc_read_flag(struct apple_smc *smc, smc_key key) > +{ > + u8 val; > + int ret = apple_smc_read_u8(smc, key, &val); Nit: Please separate the declaration and assignment via function call with a line break in between. > + if (ret < 0) > + return ret; > + return val ? 1 : 0; > +} > +#define apple_smc_write_flag apple_smc_write_u8 > + > +int apple_smc_register_notifier(struct apple_smc *smc, struct notifier_block *n); > +int apple_smc_unregister_notifier(struct apple_smc *smc, struct notifier_block *n); > + > +/* backend interface */ > + > +struct apple_smc_backend_ops { > + int (*read_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key)(void *cookie, smc_key key, void *buf, size_t size); > + int (*write_key_atomic)(void *cookie, smc_key key, void *buf, size_t size); > + int (*rw_key)(void *cookie, smc_key key, void *wbuf, size_t wsize, > + void *rbuf, size_t rsize); > + int (*get_key_by_index)(void *cookie, int index, smc_key *key); > + int (*get_key_info)(void *cookie, smc_key key, struct apple_smc_key_info *info); > +}; > + > +struct apple_smc *apple_smc_probe(struct device *dev, const struct apple_smc_backend_ops *ops, > + void *cookie); > +void *apple_smc_get_cookie(struct apple_smc *smc); > +int apple_smc_remove(struct apple_smc *smc); > +void apple_smc_event_received(struct apple_smc *smc, uint32_t event); > + > +#endif -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver 2022-11-08 16:33 ` Russell King @ 2022-11-14 10:35 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-11-14 10:35 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 04:33:17PM +0000, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. ... > + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); PLATFORM_DEVID_NONE > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); ... > +EXPORT_SYMBOL(apple_smc_probe); Namespace? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver @ 2022-11-14 10:35 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-11-14 10:35 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 04:33:17PM +0000, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > This driver implements support for the SMC (System Management > Controller) in Apple Macs. In contrast to the existing applesmc driver, > it uses pluggable backends that allow it to support different SMC > implementations, and uses the MFD subsystem to expose the core SMC > functionality so that specific features (gpio, hwmon, battery, etc.) can > be implemented by separate drivers in their respective downstream > subsystems. ... > + ret = mfd_add_devices(dev, -1, apple_smc_devs, ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); PLATFORM_DEVID_NONE > + if (ret) > + return ERR_PTR(dev_err_probe(dev, ret, "Subdevice initialization failed")); ... > +EXPORT_SYMBOL(apple_smc_probe); Namespace? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but it's useful to be able to print generic 4-character codes formatted as an integer. Extend it to add format specifiers for printing generic 32-bit FOURCCs with various endian semantics: %p4ch Host-endian %p4cl Little-endian %p4cb Big-endian %p4cr Reverse-endian The endianness determines how bytes are interpreted as a u32, and the FOURCC is then always printed MSByte-first (this is the opposite of V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would allow printing LSByte-first FOURCCs stored in host endian order (other than the hex form being in character order, not the integer value). Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- Documentation/core-api/printk-formats.rst | 32 +++++++++++++++++++ lib/test_printf.c | 39 +++++++++++++++++++---- lib/vsprintf.c | 35 ++++++++++++++++---- 3 files changed, 93 insertions(+), 13 deletions(-) diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index dbe1aacc79d0..92a488884cf8 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -625,6 +625,38 @@ Passed by reference. %p4cc Y10 little-endian (0x20303159) %p4cc NV12 big-endian (0xb231564e) +Generic FourCC code +------------------- + +:: + %p4c[hrbl] gP00 (0x67503030) + +Print a generic FourCC code, as both ASCII characters and its numerical +value as hexadecimal. + +The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify +host, reversed, big or little endian order data respectively. Host endian +order means the data is interpreted as a 32-bit integer and the most +significant byte is printed first; that is, the character code as printed +matches the byte order stored in memory on big-endian systems, and is reversed +on little-endian systems. + +Passed by reference. + +Examples for a little-endian machine, given &(u32)0x67503030:: + + %p4ch gP00 (0x67503030) + %p4cr 00Pg (0x30305067) + %p4cb 00Pg (0x30305067) + %p4cl gP00 (0x67503030) + +Examples for a big-endian machine, given &(u32)0x67503030:: + + %p4ch gP00 (0x67503030) + %p4cr 00Pg (0x30305067) + %p4cb gP00 (0x67503030) + %p4cl 00Pg (0x30305067) + Rust ---- diff --git a/lib/test_printf.c b/lib/test_printf.c index 4bd15a593fbd..77a9128a6b5a 100644 --- a/lib/test_printf.c +++ b/lib/test_printf.c @@ -731,21 +731,46 @@ static void __init fwnode_pointer(void) software_node_unregister_nodes(softnodes); } +struct fourcc_struct { + u32 code; + const char *str; +}; + +static void __init fourcc_pointer_test(const struct fourcc_struct *fc, size_t n, + const char *fmt) +{ + size_t i; + + for (i = 0; i < n; i++) + test(fc[i].str, fmt, &fc[i].code); +} + static void __init fourcc_pointer(void) { - struct { - u32 code; - char *str; - } const try[] = { + struct fourcc_struct const try_cc[] = { { 0x3231564e, "NV12 little-endian (0x3231564e)", }, { 0xb231564e, "NV12 big-endian (0xb231564e)", }, { 0x10111213, ".... little-endian (0x10111213)", }, { 0x20303159, "Y10 little-endian (0x20303159)", }, }; - unsigned int i; + struct fourcc_struct const try_ch = { + 0x41424344, "ABCD (0x41424344)", + }; + struct fourcc_struct const try_cr = { + 0x41424344, "DCBA (0x44434241)", + }; + struct fourcc_struct const try_cl = { + le32_to_cpu(0x41424344), "ABCD (0x41424344)", + }; + struct fourcc_struct const try_cb = { + be32_to_cpu(0x41424344), "ABCD (0x41424344)", + }; - for (i = 0; i < ARRAY_SIZE(try); i++) - test(try[i].str, "%p4cc", &try[i].code); + fourcc_pointer_test(try_cc, ARRAY_SIZE(try_cc), "%p4cc"); + fourcc_pointer_test(&try_ch, 1, "%p4ch"); + fourcc_pointer_test(&try_cr, 1, "%p4cr"); + fourcc_pointer_test(&try_cl, 1, "%p4cl"); + fourcc_pointer_test(&try_cb, 1, "%p4cb"); } static void __init diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 24f37bab8bc1..17064b839f19 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, char output[sizeof("0123 little-endian (0x01234567)")]; char *p = output; unsigned int i; + bool pixel_fmt = false; u32 orig, val; - if (fmt[1] != 'c' || fmt[2] != 'c') + if (fmt[1] != 'c') return error_string(buf, end, "(%p4?)", spec); if (check_pointer(&buf, end, fourcc, spec)) return buf; orig = get_unaligned(fourcc); - val = orig & ~BIT(31); + switch (fmt[2]) { + case 'h': + val = orig; + break; + case 'r': + val = orig = swab32(orig); + break; + case 'l': + val = orig = le32_to_cpu(orig); + break; + case 'b': + val = orig = be32_to_cpu(orig); + break; + case 'c': + /* Pixel formats are printed LSB-first */ + val = swab32(orig & ~BIT(31)); + pixel_fmt = true; + break; + default: + return error_string(buf, end, "(%p4?)", spec); + } for (i = 0; i < sizeof(u32); i++) { - unsigned char c = val >> (i * 8); + unsigned char c = val >> ((3 - i) * 8); /* Print non-control ASCII characters as-is, dot otherwise */ *p++ = isascii(c) && isprint(c) ? c : '.'; } - *p++ = ' '; - strcpy(p, orig & BIT(31) ? "big-endian" : "little-endian"); - p += strlen(p); + if (pixel_fmt) { + *p++ = ' '; + strcpy(p, orig & BIT(31) ? "big-endian" : "little-endian"); + p += strlen(p); + } *p++ = ' '; *p++ = '('; -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-08 16:33 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but it's useful to be able to print generic 4-character codes formatted as an integer. Extend it to add format specifiers for printing generic 32-bit FOURCCs with various endian semantics: %p4ch Host-endian %p4cl Little-endian %p4cb Big-endian %p4cr Reverse-endian The endianness determines how bytes are interpreted as a u32, and the FOURCC is then always printed MSByte-first (this is the opposite of V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would allow printing LSByte-first FOURCCs stored in host endian order (other than the hex form being in character order, not the integer value). Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- Documentation/core-api/printk-formats.rst | 32 +++++++++++++++++++ lib/test_printf.c | 39 +++++++++++++++++++---- lib/vsprintf.c | 35 ++++++++++++++++---- 3 files changed, 93 insertions(+), 13 deletions(-) diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index dbe1aacc79d0..92a488884cf8 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -625,6 +625,38 @@ Passed by reference. %p4cc Y10 little-endian (0x20303159) %p4cc NV12 big-endian (0xb231564e) +Generic FourCC code +------------------- + +:: + %p4c[hrbl] gP00 (0x67503030) + +Print a generic FourCC code, as both ASCII characters and its numerical +value as hexadecimal. + +The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify +host, reversed, big or little endian order data respectively. Host endian +order means the data is interpreted as a 32-bit integer and the most +significant byte is printed first; that is, the character code as printed +matches the byte order stored in memory on big-endian systems, and is reversed +on little-endian systems. + +Passed by reference. + +Examples for a little-endian machine, given &(u32)0x67503030:: + + %p4ch gP00 (0x67503030) + %p4cr 00Pg (0x30305067) + %p4cb 00Pg (0x30305067) + %p4cl gP00 (0x67503030) + +Examples for a big-endian machine, given &(u32)0x67503030:: + + %p4ch gP00 (0x67503030) + %p4cr 00Pg (0x30305067) + %p4cb gP00 (0x67503030) + %p4cl 00Pg (0x30305067) + Rust ---- diff --git a/lib/test_printf.c b/lib/test_printf.c index 4bd15a593fbd..77a9128a6b5a 100644 --- a/lib/test_printf.c +++ b/lib/test_printf.c @@ -731,21 +731,46 @@ static void __init fwnode_pointer(void) software_node_unregister_nodes(softnodes); } +struct fourcc_struct { + u32 code; + const char *str; +}; + +static void __init fourcc_pointer_test(const struct fourcc_struct *fc, size_t n, + const char *fmt) +{ + size_t i; + + for (i = 0; i < n; i++) + test(fc[i].str, fmt, &fc[i].code); +} + static void __init fourcc_pointer(void) { - struct { - u32 code; - char *str; - } const try[] = { + struct fourcc_struct const try_cc[] = { { 0x3231564e, "NV12 little-endian (0x3231564e)", }, { 0xb231564e, "NV12 big-endian (0xb231564e)", }, { 0x10111213, ".... little-endian (0x10111213)", }, { 0x20303159, "Y10 little-endian (0x20303159)", }, }; - unsigned int i; + struct fourcc_struct const try_ch = { + 0x41424344, "ABCD (0x41424344)", + }; + struct fourcc_struct const try_cr = { + 0x41424344, "DCBA (0x44434241)", + }; + struct fourcc_struct const try_cl = { + le32_to_cpu(0x41424344), "ABCD (0x41424344)", + }; + struct fourcc_struct const try_cb = { + be32_to_cpu(0x41424344), "ABCD (0x41424344)", + }; - for (i = 0; i < ARRAY_SIZE(try); i++) - test(try[i].str, "%p4cc", &try[i].code); + fourcc_pointer_test(try_cc, ARRAY_SIZE(try_cc), "%p4cc"); + fourcc_pointer_test(&try_ch, 1, "%p4ch"); + fourcc_pointer_test(&try_cr, 1, "%p4cr"); + fourcc_pointer_test(&try_cl, 1, "%p4cl"); + fourcc_pointer_test(&try_cb, 1, "%p4cb"); } static void __init diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 24f37bab8bc1..17064b839f19 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, char output[sizeof("0123 little-endian (0x01234567)")]; char *p = output; unsigned int i; + bool pixel_fmt = false; u32 orig, val; - if (fmt[1] != 'c' || fmt[2] != 'c') + if (fmt[1] != 'c') return error_string(buf, end, "(%p4?)", spec); if (check_pointer(&buf, end, fourcc, spec)) return buf; orig = get_unaligned(fourcc); - val = orig & ~BIT(31); + switch (fmt[2]) { + case 'h': + val = orig; + break; + case 'r': + val = orig = swab32(orig); + break; + case 'l': + val = orig = le32_to_cpu(orig); + break; + case 'b': + val = orig = be32_to_cpu(orig); + break; + case 'c': + /* Pixel formats are printed LSB-first */ + val = swab32(orig & ~BIT(31)); + pixel_fmt = true; + break; + default: + return error_string(buf, end, "(%p4?)", spec); + } for (i = 0; i < sizeof(u32); i++) { - unsigned char c = val >> (i * 8); + unsigned char c = val >> ((3 - i) * 8); /* Print non-control ASCII characters as-is, dot otherwise */ *p++ = isascii(c) && isprint(c) ? c : '.'; } - *p++ = ' '; - strcpy(p, orig & BIT(31) ? "big-endian" : "little-endian"); - p += strlen(p); + if (pixel_fmt) { + *p++ = ' '; + strcpy(p, orig & BIT(31) ? "big-endian" : "little-endian"); + p += strlen(p); + } *p++ = ' '; *p++ = '('; -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-08 16:33 ` Russell King @ 2022-11-14 15:34 ` Petr Mladek -1 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-14 15:34 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue 2022-11-08 16:33:22, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > it's useful to be able to print generic 4-character codes formatted as > an integer. Extend it to add format specifiers for printing generic > 32-bit FOURCCs with various endian semantics: > > %p4ch Host-endian > %p4cl Little-endian > %p4cb Big-endian > %p4cr Reverse-endian > > The endianness determines how bytes are interpreted as a u32, and the > FOURCC is then always printed MSByte-first (this is the opposite of > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > allow printing LSByte-first FOURCCs stored in host endian order > (other than the hex form being in character order, not the integer > value). > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Petr Mladek <pmladek@suse.com> See one nit below. > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, > char output[sizeof("0123 little-endian (0x01234567)")]; > char *p = output; > unsigned int i; > + bool pixel_fmt = false; > u32 orig, val; > > - if (fmt[1] != 'c' || fmt[2] != 'c') > + if (fmt[1] != 'c') > return error_string(buf, end, "(%p4?)", spec); > > if (check_pointer(&buf, end, fourcc, spec)) > return buf; > > orig = get_unaligned(fourcc); > - val = orig & ~BIT(31); > + switch (fmt[2]) { > + case 'h': > + val = orig; > + break; > + case 'r': > + val = orig = swab32(orig); I do not like much these multi assignments. I think that the result was not even defined in some older C standards. Though, I can't find it now. And even make W=3 does not warn about it. > + break; > + case 'l': > + val = orig = le32_to_cpu(orig); > + break; > + case 'b': > + val = orig = be32_to_cpu(orig); > + break; Best Regards, Petr ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-14 15:34 ` Petr Mladek 0 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-14 15:34 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue 2022-11-08 16:33:22, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > it's useful to be able to print generic 4-character codes formatted as > an integer. Extend it to add format specifiers for printing generic > 32-bit FOURCCs with various endian semantics: > > %p4ch Host-endian > %p4cl Little-endian > %p4cb Big-endian > %p4cr Reverse-endian > > The endianness determines how bytes are interpreted as a u32, and the > FOURCC is then always printed MSByte-first (this is the opposite of > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > allow printing LSByte-first FOURCCs stored in host endian order > (other than the hex form being in character order, not the integer > value). > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Petr Mladek <pmladek@suse.com> See one nit below. > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, > char output[sizeof("0123 little-endian (0x01234567)")]; > char *p = output; > unsigned int i; > + bool pixel_fmt = false; > u32 orig, val; > > - if (fmt[1] != 'c' || fmt[2] != 'c') > + if (fmt[1] != 'c') > return error_string(buf, end, "(%p4?)", spec); > > if (check_pointer(&buf, end, fourcc, spec)) > return buf; > > orig = get_unaligned(fourcc); > - val = orig & ~BIT(31); > + switch (fmt[2]) { > + case 'h': > + val = orig; > + break; > + case 'r': > + val = orig = swab32(orig); I do not like much these multi assignments. I think that the result was not even defined in some older C standards. Though, I can't find it now. And even make W=3 does not warn about it. > + break; > + case 'l': > + val = orig = le32_to_cpu(orig); > + break; > + case 'b': > + val = orig = be32_to_cpu(orig); > + break; Best Regards, Petr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-14 15:34 ` Petr Mladek @ 2022-11-14 15:46 ` Andy Shevchenko -1 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-11-14 15:46 UTC (permalink / raw) To: Petr Mladek Cc: Russell King, Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > On Tue 2022-11-08 16:33:22, Russell King wrote: ... > > orig = get_unaligned(fourcc); > > - val = orig & ~BIT(31); > > + switch (fmt[2]) { > > + case 'h': > > + val = orig; > > + break; > > + case 'r': > > + val = orig = swab32(orig); > > I do not like much these multi assignments. I think that the result > was not even defined in some older C standards. Though, I can't find > it now. And even make W=3 does not warn about it. > > > + break; > > + case 'l': > > + val = orig = le32_to_cpu(orig); > > + break; > > + case 'b': > > + val = orig = be32_to_cpu(orig); > > + break; Isn't easy to fix? Something like below? switch (fmt[2]) { case 'h': break; case 'r': orig = swab32(orig); break; case 'l': orig = le32_to_cpu(orig); break; case 'b': orig = be32_to_cpu(orig); break; ... } val = orig; -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-14 15:46 ` Andy Shevchenko 0 siblings, 0 replies; 342+ messages in thread From: Andy Shevchenko @ 2022-11-14 15:46 UTC (permalink / raw) To: Petr Mladek Cc: Russell King, Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > On Tue 2022-11-08 16:33:22, Russell King wrote: ... > > orig = get_unaligned(fourcc); > > - val = orig & ~BIT(31); > > + switch (fmt[2]) { > > + case 'h': > > + val = orig; > > + break; > > + case 'r': > > + val = orig = swab32(orig); > > I do not like much these multi assignments. I think that the result > was not even defined in some older C standards. Though, I can't find > it now. And even make W=3 does not warn about it. > > > + break; > > + case 'l': > > + val = orig = le32_to_cpu(orig); > > + break; > > + case 'b': > > + val = orig = be32_to_cpu(orig); > > + break; Isn't easy to fix? Something like below? switch (fmt[2]) { case 'h': break; case 'r': orig = swab32(orig); break; case 'l': orig = le32_to_cpu(orig); break; case 'b': orig = be32_to_cpu(orig); break; ... } val = orig; -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-14 15:46 ` Andy Shevchenko @ 2022-11-14 16:18 ` Petr Mladek -1 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-14 16:18 UTC (permalink / raw) To: Andy Shevchenko Cc: Russell King, Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon 2022-11-14 17:46:28, Andy Shevchenko wrote: > On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > > On Tue 2022-11-08 16:33:22, Russell King wrote: > > ... > > > > orig = get_unaligned(fourcc); > > > - val = orig & ~BIT(31); > > > + switch (fmt[2]) { > > > + case 'h': > > > + val = orig; > > > + break; > > > + case 'r': > > > + val = orig = swab32(orig); > > > > I do not like much these multi assignments. I think that the result > > was not even defined in some older C standards. Though, I can't find > > it now. And even make W=3 does not warn about it. > > > > > + break; > > > + case 'l': > > > + val = orig = le32_to_cpu(orig); > > > + break; > > > + case 'b': > > > + val = orig = be32_to_cpu(orig); > > > + break; > > Isn't easy to fix? Something like below? > > switch (fmt[2]) { > case 'h': > break; > case 'r': > orig = swab32(orig); > break; > case 'l': > orig = le32_to_cpu(orig); > break; > case 'b': > orig = be32_to_cpu(orig); > break; > > ... > } > val = orig; I though the same. Unfortunately, this is not valid for the "case c:" path where "orig" stays untouched: case 'c': /* Pixel formats are printed LSB-first */ val = swab32(orig & ~BIT(31)); pixel_fmt = true; break; It is pity that "orig" is handled differently for the pixel and the generic formats. But I am afraid that there is no good solution. The code will always be a mess when it tries to implement a messy definition. It would be nice if the the FourCC format was used consistently in all subsystems in the first place. IMPORTANT: This brings the questions. Is there actually a standard how to print the original number in FourCC? Do we really want to modify "orig" in the generic implementation? Best Regards, Petr ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-14 16:18 ` Petr Mladek 0 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-14 16:18 UTC (permalink / raw) To: Andy Shevchenko Cc: Russell King, Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon 2022-11-14 17:46:28, Andy Shevchenko wrote: > On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > > On Tue 2022-11-08 16:33:22, Russell King wrote: > > ... > > > > orig = get_unaligned(fourcc); > > > - val = orig & ~BIT(31); > > > + switch (fmt[2]) { > > > + case 'h': > > > + val = orig; > > > + break; > > > + case 'r': > > > + val = orig = swab32(orig); > > > > I do not like much these multi assignments. I think that the result > > was not even defined in some older C standards. Though, I can't find > > it now. And even make W=3 does not warn about it. > > > > > + break; > > > + case 'l': > > > + val = orig = le32_to_cpu(orig); > > > + break; > > > + case 'b': > > > + val = orig = be32_to_cpu(orig); > > > + break; > > Isn't easy to fix? Something like below? > > switch (fmt[2]) { > case 'h': > break; > case 'r': > orig = swab32(orig); > break; > case 'l': > orig = le32_to_cpu(orig); > break; > case 'b': > orig = be32_to_cpu(orig); > break; > > ... > } > val = orig; I though the same. Unfortunately, this is not valid for the "case c:" path where "orig" stays untouched: case 'c': /* Pixel formats are printed LSB-first */ val = swab32(orig & ~BIT(31)); pixel_fmt = true; break; It is pity that "orig" is handled differently for the pixel and the generic formats. But I am afraid that there is no good solution. The code will always be a mess when it tries to implement a messy definition. It would be nice if the the FourCC format was used consistently in all subsystems in the first place. IMPORTANT: This brings the questions. Is there actually a standard how to print the original number in FourCC? Do we really want to modify "orig" in the generic implementation? Best Regards, Petr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-14 15:34 ` Petr Mladek @ 2022-11-14 16:15 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-14 16:15 UTC (permalink / raw) To: Petr Mladek Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > On Tue 2022-11-08 16:33:22, Russell King wrote: > > From: Hector Martin <marcan@marcan.st> > > > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > > it's useful to be able to print generic 4-character codes formatted as > > an integer. Extend it to add format specifiers for printing generic > > 32-bit FOURCCs with various endian semantics: > > > > %p4ch Host-endian > > %p4cl Little-endian > > %p4cb Big-endian > > %p4cr Reverse-endian > > > > The endianness determines how bytes are interpreted as a u32, and the > > FOURCC is then always printed MSByte-first (this is the opposite of > > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > > allow printing LSByte-first FOURCCs stored in host endian order > > (other than the hex form being in character order, not the integer > > value). > > > > Signed-off-by: Hector Martin <marcan@marcan.st> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Reviewed-by: Petr Mladek <pmladek@suse.com> > > See one nit below. > > > --- a/lib/vsprintf.c > > +++ b/lib/vsprintf.c > > @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, > > char output[sizeof("0123 little-endian (0x01234567)")]; > > char *p = output; > > unsigned int i; > > + bool pixel_fmt = false; > > u32 orig, val; > > > > - if (fmt[1] != 'c' || fmt[2] != 'c') > > + if (fmt[1] != 'c') > > return error_string(buf, end, "(%p4?)", spec); > > > > if (check_pointer(&buf, end, fourcc, spec)) > > return buf; > > > > orig = get_unaligned(fourcc); > > - val = orig & ~BIT(31); > > + switch (fmt[2]) { > > + case 'h': > > + val = orig; > > + break; > > + case 'r': > > + val = orig = swab32(orig); > > I do not like much these multi assignments. I think that the result > was not even defined in some older C standards. Though, I can't find > it now. And even make W=3 does not warn about it. Err. It's been supported for decades. I learnt about it back in 1992 when I was introduced to C by another experienced C programmer. It's been supported in ANSI C compilers. The Norcroft C compiler (which is strict ANSI) on Acorn platforms back in the late 1980s/1990s even supported it. I think you're a bit out of date. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-14 16:15 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-14 16:15 UTC (permalink / raw) To: Petr Mladek Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > On Tue 2022-11-08 16:33:22, Russell King wrote: > > From: Hector Martin <marcan@marcan.st> > > > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > > it's useful to be able to print generic 4-character codes formatted as > > an integer. Extend it to add format specifiers for printing generic > > 32-bit FOURCCs with various endian semantics: > > > > %p4ch Host-endian > > %p4cl Little-endian > > %p4cb Big-endian > > %p4cr Reverse-endian > > > > The endianness determines how bytes are interpreted as a u32, and the > > FOURCC is then always printed MSByte-first (this is the opposite of > > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > > allow printing LSByte-first FOURCCs stored in host endian order > > (other than the hex form being in character order, not the integer > > value). > > > > Signed-off-by: Hector Martin <marcan@marcan.st> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Reviewed-by: Petr Mladek <pmladek@suse.com> > > See one nit below. > > > --- a/lib/vsprintf.c > > +++ b/lib/vsprintf.c > > @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, > > char output[sizeof("0123 little-endian (0x01234567)")]; > > char *p = output; > > unsigned int i; > > + bool pixel_fmt = false; > > u32 orig, val; > > > > - if (fmt[1] != 'c' || fmt[2] != 'c') > > + if (fmt[1] != 'c') > > return error_string(buf, end, "(%p4?)", spec); > > > > if (check_pointer(&buf, end, fourcc, spec)) > > return buf; > > > > orig = get_unaligned(fourcc); > > - val = orig & ~BIT(31); > > + switch (fmt[2]) { > > + case 'h': > > + val = orig; > > + break; > > + case 'r': > > + val = orig = swab32(orig); > > I do not like much these multi assignments. I think that the result > was not even defined in some older C standards. Though, I can't find > it now. And even make W=3 does not warn about it. Err. It's been supported for decades. I learnt about it back in 1992 when I was introduced to C by another experienced C programmer. It's been supported in ANSI C compilers. The Norcroft C compiler (which is strict ANSI) on Acorn platforms back in the late 1980s/1990s even supported it. I think you're a bit out of date. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-14 16:15 ` Russell King (Oracle) @ 2022-11-14 16:46 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-14 16:46 UTC (permalink / raw) To: Petr Mladek Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon, Nov 14, 2022 at 04:15:50PM +0000, Russell King (Oracle) wrote: > On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > > > orig = get_unaligned(fourcc); > > > - val = orig & ~BIT(31); > > > + switch (fmt[2]) { > > > + case 'h': > > > + val = orig; > > > + break; > > > + case 'r': > > > + val = orig = swab32(orig); > > > > I do not like much these multi assignments. I think that the result > > was not even defined in some older C standards. Though, I can't find > > it now. And even make W=3 does not warn about it. > > Err. > > It's been supported for decades. I learnt about it back in 1992 when > I was introduced to C by another experienced C programmer. It's been > supported in ANSI C compilers. The Norcroft C compiler (which is > strict ANSI) on Acorn platforms back in the late 1980s/1990s even > supported it. > > I think you're a bit out of date. Oh, and it's not like there isn't precedent for doing this in lib/vsprintf.c: 841a915d20c7 vsprintf: Do not have bprintf dereference pointers + len = copy = strlen(args); If you grep lib/, there's many more examples. So, what is in Hectors patch is in no way any different from lots of other examples already merged into the kernel code. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-14 16:46 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-14 16:46 UTC (permalink / raw) To: Petr Mladek Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon, Nov 14, 2022 at 04:15:50PM +0000, Russell King (Oracle) wrote: > On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > > > orig = get_unaligned(fourcc); > > > - val = orig & ~BIT(31); > > > + switch (fmt[2]) { > > > + case 'h': > > > + val = orig; > > > + break; > > > + case 'r': > > > + val = orig = swab32(orig); > > > > I do not like much these multi assignments. I think that the result > > was not even defined in some older C standards. Though, I can't find > > it now. And even make W=3 does not warn about it. > > Err. > > It's been supported for decades. I learnt about it back in 1992 when > I was introduced to C by another experienced C programmer. It's been > supported in ANSI C compilers. The Norcroft C compiler (which is > strict ANSI) on Acorn platforms back in the late 1980s/1990s even > supported it. > > I think you're a bit out of date. Oh, and it's not like there isn't precedent for doing this in lib/vsprintf.c: 841a915d20c7 vsprintf: Do not have bprintf dereference pointers + len = copy = strlen(args); If you grep lib/, there's many more examples. So, what is in Hectors patch is in no way any different from lots of other examples already merged into the kernel code. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-14 16:15 ` Russell King (Oracle) @ 2022-11-22 12:43 ` Petr Mladek -1 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-22 12:43 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon 2022-11-14 16:15:50, Russell King (Oracle) wrote: > On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > > On Tue 2022-11-08 16:33:22, Russell King wrote: > > > From: Hector Martin <marcan@marcan.st> > > > > > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > > > it's useful to be able to print generic 4-character codes formatted as > > > an integer. Extend it to add format specifiers for printing generic > > > 32-bit FOURCCs with various endian semantics: > > > > > > %p4ch Host-endian > > > %p4cl Little-endian > > > %p4cb Big-endian > > > %p4cr Reverse-endian > > > > > > The endianness determines how bytes are interpreted as a u32, and the > > > FOURCC is then always printed MSByte-first (this is the opposite of > > > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > > > allow printing LSByte-first FOURCCs stored in host endian order > > > (other than the hex form being in character order, not the integer > > > value). > > > > > > Signed-off-by: Hector Martin <marcan@marcan.st> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > Reviewed-by: Petr Mladek <pmladek@suse.com> > > > > See one nit below. > > > > > --- a/lib/vsprintf.c > > > +++ b/lib/vsprintf.c > > > @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, > > > char output[sizeof("0123 little-endian (0x01234567)")]; > > > char *p = output; > > > unsigned int i; > > > + bool pixel_fmt = false; > > > u32 orig, val; > > > > > > - if (fmt[1] != 'c' || fmt[2] != 'c') > > > + if (fmt[1] != 'c') > > > return error_string(buf, end, "(%p4?)", spec); > > > > > > if (check_pointer(&buf, end, fourcc, spec)) > > > return buf; > > > > > > orig = get_unaligned(fourcc); > > > - val = orig & ~BIT(31); > > > + switch (fmt[2]) { > > > + case 'h': > > > + val = orig; > > > + break; > > > + case 'r': > > > + val = orig = swab32(orig); > > > > I do not like much these multi assignments. I think that the result > > was not even defined in some older C standards. Though, I can't find > > it now. And even make W=3 does not warn about it. > > Err. > > It's been supported for decades. I learnt about it back in 1992 when > I was introduced to C by another experienced C programmer. It's been > supported in ANSI C compilers. The Norcroft C compiler (which is > strict ANSI) on Acorn platforms back in the late 1980s/1990s even > supported it. Ah, the problem probably was with a more complicated assignment. For example, the result of the following code is not obvious: a = b = a++; Best Regards, Petr ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-22 12:43 ` Petr Mladek 0 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-22 12:43 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Mon 2022-11-14 16:15:50, Russell King (Oracle) wrote: > On Mon, Nov 14, 2022 at 04:34:07PM +0100, Petr Mladek wrote: > > On Tue 2022-11-08 16:33:22, Russell King wrote: > > > From: Hector Martin <marcan@marcan.st> > > > > > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > > > it's useful to be able to print generic 4-character codes formatted as > > > an integer. Extend it to add format specifiers for printing generic > > > 32-bit FOURCCs with various endian semantics: > > > > > > %p4ch Host-endian > > > %p4cl Little-endian > > > %p4cb Big-endian > > > %p4cr Reverse-endian > > > > > > The endianness determines how bytes are interpreted as a u32, and the > > > FOURCC is then always printed MSByte-first (this is the opposite of > > > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > > > allow printing LSByte-first FOURCCs stored in host endian order > > > (other than the hex form being in character order, not the integer > > > value). > > > > > > Signed-off-by: Hector Martin <marcan@marcan.st> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > Reviewed-by: Petr Mladek <pmladek@suse.com> > > > > See one nit below. > > > > > --- a/lib/vsprintf.c > > > +++ b/lib/vsprintf.c > > > @@ -1762,27 +1762,50 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc, > > > char output[sizeof("0123 little-endian (0x01234567)")]; > > > char *p = output; > > > unsigned int i; > > > + bool pixel_fmt = false; > > > u32 orig, val; > > > > > > - if (fmt[1] != 'c' || fmt[2] != 'c') > > > + if (fmt[1] != 'c') > > > return error_string(buf, end, "(%p4?)", spec); > > > > > > if (check_pointer(&buf, end, fourcc, spec)) > > > return buf; > > > > > > orig = get_unaligned(fourcc); > > > - val = orig & ~BIT(31); > > > + switch (fmt[2]) { > > > + case 'h': > > > + val = orig; > > > + break; > > > + case 'r': > > > + val = orig = swab32(orig); > > > > I do not like much these multi assignments. I think that the result > > was not even defined in some older C standards. Though, I can't find > > it now. And even make W=3 does not warn about it. > > Err. > > It's been supported for decades. I learnt about it back in 1992 when > I was introduced to C by another experienced C programmer. It's been > supported in ANSI C compilers. The Norcroft C compiler (which is > strict ANSI) on Acorn platforms back in the late 1980s/1990s even > supported it. Ah, the problem probably was with a more complicated assignment. For example, the result of the following code is not obvious: a = b = a++; Best Regards, Petr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc 2022-11-08 16:33 ` Russell King @ 2022-11-22 14:49 ` Petr Mladek -1 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-22 14:49 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue 2022-11-08 16:33:22, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > it's useful to be able to print generic 4-character codes formatted as > an integer. Extend it to add format specifiers for printing generic > 32-bit FOURCCs with various endian semantics: > > %p4ch Host-endian > %p4cl Little-endian > %p4cb Big-endian > %p4cr Reverse-endian > > The endianness determines how bytes are interpreted as a u32, and the > FOURCC is then always printed MSByte-first (this is the opposite of > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > allow printing LSByte-first FOURCCs stored in host endian order > (other than the hex form being in character order, not the integer > value). > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > Documentation/core-api/printk-formats.rst | 32 +++++++++++++++++++ > lib/test_printf.c | 39 +++++++++++++++++++---- > lib/vsprintf.c | 35 ++++++++++++++++---- > 3 files changed, 93 insertions(+), 13 deletions(-) > > diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst > index dbe1aacc79d0..92a488884cf8 100644 > --- a/Documentation/core-api/printk-formats.rst > +++ b/Documentation/core-api/printk-formats.rst > @@ -625,6 +625,38 @@ Passed by reference. > %p4cc Y10 little-endian (0x20303159) > %p4cc NV12 big-endian (0xb231564e) > > +Generic FourCC code > +------------------- > + > +:: > + %p4c[hrbl] gP00 (0x67503030) > + > +Print a generic FourCC code, as both ASCII characters and its numerical > +value as hexadecimal. > + > +The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify > +host, reversed, big or little endian order data respectively. Host endian > +order means the data is interpreted as a 32-bit integer and the most > +significant byte is printed first; that is, the character code as printed > +matches the byte order stored in memory on big-endian systems, and is reversed > +on little-endian systems. I though a bit more about the semantic and got a bit confused. It might be because I am not familiar with FourCC. Anyway, the description in the commit message provided some more clues. The following documentation looks be more clear to me: <proposal> Generic FourCC code ------------------- :: %p4c[hrbl] gP00 (0x67503030) Print a generic FourCC code, as both ASCII characters and its numerical value as hexadecimal. The generic FourCC code is always printed in the the big-endian format, the most significant byte first. This is the opposite of V4L/DRM FOURCCs. The additional ``h``, ``r``, ``b``, and ``l`` specifiers define what endianes is used to load the stored value as 32-bit integer. The value might be stored as host-endian, reverse-host-endian, big-endian, or little endian. Examples for a little-endian machine, host native load &(u32)0x67503030:: %p4ch gP00 (0x67503030) %p4cr 00Pg (0x30305067) %p4cb 00Pg (0x30305067) %p4cl gP00 (0x67503030) Examples for a big-endian machine, host native load &(u32)0x67503030:: %p4ch gP00 (0x67503030) %p4cr 00Pg (0x30305067) %p4cb gP00 (0x67503030) %p4cl 00Pg (0x30305067) </proposal> Best Regards, Petr ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc @ 2022-11-22 14:49 ` Petr Mladek 0 siblings, 0 replies; 342+ messages in thread From: Petr Mladek @ 2022-11-22 14:49 UTC (permalink / raw) To: Russell King Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue 2022-11-08 16:33:22, Russell King wrote: > From: Hector Martin <marcan@marcan.st> > > %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > it's useful to be able to print generic 4-character codes formatted as > an integer. Extend it to add format specifiers for printing generic > 32-bit FOURCCs with various endian semantics: > > %p4ch Host-endian > %p4cl Little-endian > %p4cb Big-endian > %p4cr Reverse-endian > > The endianness determines how bytes are interpreted as a u32, and the > FOURCC is then always printed MSByte-first (this is the opposite of > V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > allow printing LSByte-first FOURCCs stored in host endian order > (other than the hex form being in character order, not the integer > value). > > Signed-off-by: Hector Martin <marcan@marcan.st> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > Documentation/core-api/printk-formats.rst | 32 +++++++++++++++++++ > lib/test_printf.c | 39 +++++++++++++++++++---- > lib/vsprintf.c | 35 ++++++++++++++++---- > 3 files changed, 93 insertions(+), 13 deletions(-) > > diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst > index dbe1aacc79d0..92a488884cf8 100644 > --- a/Documentation/core-api/printk-formats.rst > +++ b/Documentation/core-api/printk-formats.rst > @@ -625,6 +625,38 @@ Passed by reference. > %p4cc Y10 little-endian (0x20303159) > %p4cc NV12 big-endian (0xb231564e) > > +Generic FourCC code > +------------------- > + > +:: > + %p4c[hrbl] gP00 (0x67503030) > + > +Print a generic FourCC code, as both ASCII characters and its numerical > +value as hexadecimal. > + > +The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify > +host, reversed, big or little endian order data respectively. Host endian > +order means the data is interpreted as a 32-bit integer and the most > +significant byte is printed first; that is, the character code as printed > +matches the byte order stored in memory on big-endian systems, and is reversed > +on little-endian systems. I though a bit more about the semantic and got a bit confused. It might be because I am not familiar with FourCC. Anyway, the description in the commit message provided some more clues. The following documentation looks be more clear to me: <proposal> Generic FourCC code ------------------- :: %p4c[hrbl] gP00 (0x67503030) Print a generic FourCC code, as both ASCII characters and its numerical value as hexadecimal. The generic FourCC code is always printed in the the big-endian format, the most significant byte first. This is the opposite of V4L/DRM FOURCCs. The additional ``h``, ``r``, ``b``, and ``l`` specifiers define what endianes is used to load the stored value as 32-bit integer. The value might be stored as host-endian, reverse-host-endian, big-endian, or little endian. Examples for a little-endian machine, host native load &(u32)0x67503030:: %p4ch gP00 (0x67503030) %p4cr 00Pg (0x30305067) %p4cb 00Pg (0x30305067) %p4cl gP00 (0x67503030) Examples for a big-endian machine, host native load &(u32)0x67503030:: %p4ch gP00 (0x67503030) %p4cr 00Pg (0x30305067) %p4cb gP00 (0x67503030) %p4cl 00Pg (0x30305067) </proposal> Best Regards, Petr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter Add a DT binding for the Apple Mac System Management Controller. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml new file mode 100644 index 000000000000..014eba5a1bbc --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller implements various functions + such as GPIO, RTC, power, reboot. + +properties: + compatible: + items: + - enum: + - apple,t6000-smc + - apple,t8103-smc + - apple,t8112-smc + - const: apple,smc + + reg: + items: + - description: SMC area + - description: SRAM area + + reg-names: + items: + - const: smc + - const: sram + + mboxes: + maxItems: 1 + + gpio: + $ref: /schemas/gpio/gpio-macsmc.yaml + +additionalProperties: false + +required: + - compatible + - reg + - reg-names + - mboxes + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + + smc_gpio: gpio { + gpio-controller; + #gpio-cells = <2>; + }; + }; + }; -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-08 16:33 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter Add a DT binding for the Apple Mac System Management Controller. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml new file mode 100644 index 000000000000..014eba5a1bbc --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller implements various functions + such as GPIO, RTC, power, reboot. + +properties: + compatible: + items: + - enum: + - apple,t6000-smc + - apple,t8103-smc + - apple,t8112-smc + - const: apple,smc + + reg: + items: + - description: SMC area + - description: SRAM area + + reg-names: + items: + - const: smc + - const: sram + + mboxes: + maxItems: 1 + + gpio: + $ref: /schemas/gpio/gpio-macsmc.yaml + +additionalProperties: false + +required: + - compatible + - reg + - reg-names + - mboxes + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + + smc_gpio: gpio { + gpio-controller; + #gpio-cells = <2>; + }; + }; + }; -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 16:33 ` Russell King (Oracle) @ 2022-11-08 20:42 ` Linus Walleij -1 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-11-08 20:42 UTC (permalink / raw) To: Russell King (Oracle) Cc: Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 8, 2022 at 5:33 PM Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Looks good to me! Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-08 20:42 ` Linus Walleij 0 siblings, 0 replies; 342+ messages in thread From: Linus Walleij @ 2022-11-08 20:42 UTC (permalink / raw) To: Russell King (Oracle) Cc: Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 8, 2022 at 5:33 PM Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Looks good to me! Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 16:33 ` Russell King (Oracle) @ 2022-11-08 20:55 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-08 20:55 UTC (permalink / raw) To: Russell King (Oracle), Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 17:33, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. Drop the second, redundant "binding" from subject. It's already in prefix. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > new file mode 100644 > index 000000000000..014eba5a1bbc > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > @@ -0,0 +1,67 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller implements various functions > + such as GPIO, RTC, power, reboot. > + > +properties: > + compatible: > + items: > + - enum: > + - apple,t6000-smc > + - apple,t8103-smc > + - apple,t8112-smc > + - const: apple,smc > + > + reg: > + items: > + - description: SMC area > + - description: SRAM area > + > + reg-names: > + items: > + - const: smc > + - const: sram > + > + mboxes: > + maxItems: 1 > + > + gpio: > + $ref: /schemas/gpio/gpio-macsmc.yaml So this depends on other patch, so: 1. You need mention the dependency in cover letter (nothing there), 2. Re-order patches. The GPIO cannot go separate tree and this must be explicitly communicated. > + > +additionalProperties: false > + > +required: > + - compatible > + - reg > + - reg-names > + - mboxes > + > +examples: > + - | > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + smc@23e400000 { Usually these are called system-controller, to have a generic name (as asked by DT spec). > + compatible = "apple,t8103-smc", "apple,smc"; > + reg = <0x2 0x3e400000 0x0 0x4000>, > + <0x2 0x3fe00000 0x0 0x100000>; Align the items (opening <). With three above: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-08 20:55 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-08 20:55 UTC (permalink / raw) To: Russell King (Oracle), Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 17:33, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. Drop the second, redundant "binding" from subject. It's already in prefix. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > new file mode 100644 > index 000000000000..014eba5a1bbc > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > @@ -0,0 +1,67 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller implements various functions > + such as GPIO, RTC, power, reboot. > + > +properties: > + compatible: > + items: > + - enum: > + - apple,t6000-smc > + - apple,t8103-smc > + - apple,t8112-smc > + - const: apple,smc > + > + reg: > + items: > + - description: SMC area > + - description: SRAM area > + > + reg-names: > + items: > + - const: smc > + - const: sram > + > + mboxes: > + maxItems: 1 > + > + gpio: > + $ref: /schemas/gpio/gpio-macsmc.yaml So this depends on other patch, so: 1. You need mention the dependency in cover letter (nothing there), 2. Re-order patches. The GPIO cannot go separate tree and this must be explicitly communicated. > + > +additionalProperties: false > + > +required: > + - compatible > + - reg > + - reg-names > + - mboxes > + > +examples: > + - | > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + smc@23e400000 { Usually these are called system-controller, to have a generic name (as asked by DT spec). > + compatible = "apple,t8103-smc", "apple,smc"; > + reg = <0x2 0x3e400000 0x0 0x4000>, > + <0x2 0x3fe00000 0x0 0x100000>; Align the items (opening <). With three above: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 20:55 ` Krzysztof Kozlowski @ 2022-11-08 22:22 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 22:22 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > Add a DT binding for the Apple Mac System Management Controller. > > Drop the second, redundant "binding" from subject. It's already in prefix. Yet another thing that's been there from the start... how many more things are you going to pick up in subsequent versions of the patch? When does this stop? In any case, taking your comment literally, "dt-bindings: mfd: add for Apple Mac System Management Controller" makes no sense, so presumably you want something more than that. In any case, I see several recent cases already merged which follow the pattern that I've used and that you've reviewed. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > new file mode 100644 > > index 000000000000..014eba5a1bbc > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > @@ -0,0 +1,67 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Apple Mac System Management Controller > > + > > +maintainers: > > + - Hector Martin <marcan@marcan.st> > > + > > +description: > > + Apple Mac System Management Controller implements various functions > > + such as GPIO, RTC, power, reboot. > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - apple,t6000-smc > > + - apple,t8103-smc > > + - apple,t8112-smc > > + - const: apple,smc > > + > > + reg: > > + items: > > + - description: SMC area > > + - description: SRAM area > > + > > + reg-names: > > + items: > > + - const: smc > > + - const: sram > > + > > + mboxes: > > + maxItems: 1 > > + > > + gpio: > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > So this depends on other patch, so: > 1. You need mention the dependency in cover letter (nothing there), > 2. Re-order patches. > > The GPIO cannot go separate tree and this must be explicitly communicated. Sigh, getting an order that is sensible is really bloody difficult. I'm quite sure Lee is only going to want to apply the mfd bits. Then what do we do with the other bits? GPIO stuff via the GPIO tree, then wait a cycle before the rest can be merged. Or what? > > + > > +additionalProperties: false > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - mboxes > > + > > +examples: > > + - | > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + smc@23e400000 { > > Usually these are called system-controller, to have a generic name (as > asked by DT spec). I'll defer to Hector for his response on this one, but you've had had plenty of opportunities to bring this up in the past - it's been there since the first posting. Frustrating is definitely the word for this drip-drip-drip review. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-08 22:22 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 22:22 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > Add a DT binding for the Apple Mac System Management Controller. > > Drop the second, redundant "binding" from subject. It's already in prefix. Yet another thing that's been there from the start... how many more things are you going to pick up in subsequent versions of the patch? When does this stop? In any case, taking your comment literally, "dt-bindings: mfd: add for Apple Mac System Management Controller" makes no sense, so presumably you want something more than that. In any case, I see several recent cases already merged which follow the pattern that I've used and that you've reviewed. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > new file mode 100644 > > index 000000000000..014eba5a1bbc > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > @@ -0,0 +1,67 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Apple Mac System Management Controller > > + > > +maintainers: > > + - Hector Martin <marcan@marcan.st> > > + > > +description: > > + Apple Mac System Management Controller implements various functions > > + such as GPIO, RTC, power, reboot. > > + > > +properties: > > + compatible: > > + items: > > + - enum: > > + - apple,t6000-smc > > + - apple,t8103-smc > > + - apple,t8112-smc > > + - const: apple,smc > > + > > + reg: > > + items: > > + - description: SMC area > > + - description: SRAM area > > + > > + reg-names: > > + items: > > + - const: smc > > + - const: sram > > + > > + mboxes: > > + maxItems: 1 > > + > > + gpio: > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > So this depends on other patch, so: > 1. You need mention the dependency in cover letter (nothing there), > 2. Re-order patches. > > The GPIO cannot go separate tree and this must be explicitly communicated. Sigh, getting an order that is sensible is really bloody difficult. I'm quite sure Lee is only going to want to apply the mfd bits. Then what do we do with the other bits? GPIO stuff via the GPIO tree, then wait a cycle before the rest can be merged. Or what? > > + > > +additionalProperties: false > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - mboxes > > + > > +examples: > > + - | > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + smc@23e400000 { > > Usually these are called system-controller, to have a generic name (as > asked by DT spec). I'll defer to Hector for his response on this one, but you've had had plenty of opportunities to bring this up in the past - it's been there since the first posting. Frustrating is definitely the word for this drip-drip-drip review. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 22:22 ` Russell King (Oracle) @ 2022-11-09 8:35 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-09 8:35 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 23:22, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>> Add a DT binding for the Apple Mac System Management Controller. >> >> Drop the second, redundant "binding" from subject. It's already in prefix. > > Yet another thing that's been there from the start... how many more > things are you going to pick up in subsequent versions of the patch? > When does this stop? > > In any case, taking your comment literally, > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > makes no sense, so presumably you want something more than that. dt-bindings: mfd: add Apple Mac System Management Controller > > In any case, I see several recent cases already merged which follow > the pattern that I've used and that you've reviewed. Any many received comments to fix. I wouldn't mention it if there was no second issue - your patchset is non-bisectable. Since you must resend, please adjust the subject. > >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>> --- >>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>> 1 file changed, 67 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>> new file mode 100644 >>> index 000000000000..014eba5a1bbc >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>> @@ -0,0 +1,67 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Apple Mac System Management Controller >>> + >>> +maintainers: >>> + - Hector Martin <marcan@marcan.st> >>> + >>> +description: >>> + Apple Mac System Management Controller implements various functions >>> + such as GPIO, RTC, power, reboot. >>> + >>> +properties: >>> + compatible: >>> + items: >>> + - enum: >>> + - apple,t6000-smc >>> + - apple,t8103-smc >>> + - apple,t8112-smc >>> + - const: apple,smc >>> + >>> + reg: >>> + items: >>> + - description: SMC area >>> + - description: SRAM area >>> + >>> + reg-names: >>> + items: >>> + - const: smc >>> + - const: sram >>> + >>> + mboxes: >>> + maxItems: 1 >>> + >>> + gpio: >>> + $ref: /schemas/gpio/gpio-macsmc.yaml >> >> So this depends on other patch, so: >> 1. You need mention the dependency in cover letter (nothing there), >> 2. Re-order patches. >> >> The GPIO cannot go separate tree and this must be explicitly communicated. > > Sigh, getting an order that is sensible is really bloody difficult. > I'm quite sure Lee is only going to want to apply the mfd bits. Then > what do we do with the other bits? GPIO stuff via the GPIO tree, then > wait a cycle before the rest can be merged. Or what? It's nothing new... bindings headers, drivers and DTS all have it since years. Your case is actually easy to solve: 1. Re-order patches, describe dependency, get ack from one maintainer so it can go via other. 2. Squash patches and describe dependency. Only one maintainer will need to pick it up (with second's ack). I don't understand why we talk about such basics, you are far way more experienced in kernel development than many of us... Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-09 8:35 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-09 8:35 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 23:22, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>> Add a DT binding for the Apple Mac System Management Controller. >> >> Drop the second, redundant "binding" from subject. It's already in prefix. > > Yet another thing that's been there from the start... how many more > things are you going to pick up in subsequent versions of the patch? > When does this stop? > > In any case, taking your comment literally, > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > makes no sense, so presumably you want something more than that. dt-bindings: mfd: add Apple Mac System Management Controller > > In any case, I see several recent cases already merged which follow > the pattern that I've used and that you've reviewed. Any many received comments to fix. I wouldn't mention it if there was no second issue - your patchset is non-bisectable. Since you must resend, please adjust the subject. > >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>> --- >>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>> 1 file changed, 67 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>> new file mode 100644 >>> index 000000000000..014eba5a1bbc >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>> @@ -0,0 +1,67 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Apple Mac System Management Controller >>> + >>> +maintainers: >>> + - Hector Martin <marcan@marcan.st> >>> + >>> +description: >>> + Apple Mac System Management Controller implements various functions >>> + such as GPIO, RTC, power, reboot. >>> + >>> +properties: >>> + compatible: >>> + items: >>> + - enum: >>> + - apple,t6000-smc >>> + - apple,t8103-smc >>> + - apple,t8112-smc >>> + - const: apple,smc >>> + >>> + reg: >>> + items: >>> + - description: SMC area >>> + - description: SRAM area >>> + >>> + reg-names: >>> + items: >>> + - const: smc >>> + - const: sram >>> + >>> + mboxes: >>> + maxItems: 1 >>> + >>> + gpio: >>> + $ref: /schemas/gpio/gpio-macsmc.yaml >> >> So this depends on other patch, so: >> 1. You need mention the dependency in cover letter (nothing there), >> 2. Re-order patches. >> >> The GPIO cannot go separate tree and this must be explicitly communicated. > > Sigh, getting an order that is sensible is really bloody difficult. > I'm quite sure Lee is only going to want to apply the mfd bits. Then > what do we do with the other bits? GPIO stuff via the GPIO tree, then > wait a cycle before the rest can be merged. Or what? It's nothing new... bindings headers, drivers and DTS all have it since years. Your case is actually easy to solve: 1. Re-order patches, describe dependency, get ack from one maintainer so it can go via other. 2. Squash patches and describe dependency. Only one maintainer will need to pick it up (with second's ack). I don't understand why we talk about such basics, you are far way more experienced in kernel development than many of us... Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 22:22 ` Russell King (Oracle) @ 2022-11-09 22:17 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-11-09 22:17 UTC (permalink / raw) To: Russell King (Oracle) Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > > Add a DT binding for the Apple Mac System Management Controller. > > > > Drop the second, redundant "binding" from subject. It's already in prefix. > > Yet another thing that's been there from the start... how many more > things are you going to pick up in subsequent versions of the patch? > When does this stop? > > In any case, taking your comment literally, > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > makes no sense, so presumably you want something more than that. > > In any case, I see several recent cases already merged which follow > the pattern that I've used and that you've reviewed. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > --- > > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > > 1 file changed, 67 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > new file mode 100644 > > > index 000000000000..014eba5a1bbc > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > @@ -0,0 +1,67 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Apple Mac System Management Controller > > > + > > > +maintainers: > > > + - Hector Martin <marcan@marcan.st> > > > + > > > +description: > > > + Apple Mac System Management Controller implements various functions > > > + such as GPIO, RTC, power, reboot. > > > + > > > +properties: > > > + compatible: > > > + items: > > > + - enum: > > > + - apple,t6000-smc > > > + - apple,t8103-smc > > > + - apple,t8112-smc > > > + - const: apple,smc > > > + > > > + reg: > > > + items: > > > + - description: SMC area > > > + - description: SRAM area > > > + > > > + reg-names: > > > + items: > > > + - const: smc > > > + - const: sram > > > + > > > + mboxes: > > > + maxItems: 1 > > > + > > > + gpio: > > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > > > So this depends on other patch, so: > > 1. You need mention the dependency in cover letter (nothing there), > > 2. Re-order patches. > > > > The GPIO cannot go separate tree and this must be explicitly communicated. > > Sigh, getting an order that is sensible is really bloody difficult. It's not. Sub-devices before the MFD. The only time that doesn't work is when the sub-devices put the parent MFD in their example. The solution there is don't do that. Just 1 complete example in the MFD schema and no examples in the sub-devices. > I'm quite sure Lee is only going to want to apply the mfd bits. Indeed. I can't seem to make Lee care... All the schemas should really be applied together. > Then > what do we do with the other bits? GPIO stuff via the GPIO tree, then > wait a cycle before the rest can be merged. Or what? The schemas must be picked up in the same cycle. I don't care so much if subsystem maintainers' trees have warnings if they don't care, but I do care for linux-next. If the subsystem bits aren't picked up, then I'll pick them up if it comes to that. Rob ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-09 22:17 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-11-09 22:17 UTC (permalink / raw) To: Russell King (Oracle) Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > > Add a DT binding for the Apple Mac System Management Controller. > > > > Drop the second, redundant "binding" from subject. It's already in prefix. > > Yet another thing that's been there from the start... how many more > things are you going to pick up in subsequent versions of the patch? > When does this stop? > > In any case, taking your comment literally, > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > makes no sense, so presumably you want something more than that. > > In any case, I see several recent cases already merged which follow > the pattern that I've used and that you've reviewed. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > --- > > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > > 1 file changed, 67 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > new file mode 100644 > > > index 000000000000..014eba5a1bbc > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > @@ -0,0 +1,67 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Apple Mac System Management Controller > > > + > > > +maintainers: > > > + - Hector Martin <marcan@marcan.st> > > > + > > > +description: > > > + Apple Mac System Management Controller implements various functions > > > + such as GPIO, RTC, power, reboot. > > > + > > > +properties: > > > + compatible: > > > + items: > > > + - enum: > > > + - apple,t6000-smc > > > + - apple,t8103-smc > > > + - apple,t8112-smc > > > + - const: apple,smc > > > + > > > + reg: > > > + items: > > > + - description: SMC area > > > + - description: SRAM area > > > + > > > + reg-names: > > > + items: > > > + - const: smc > > > + - const: sram > > > + > > > + mboxes: > > > + maxItems: 1 > > > + > > > + gpio: > > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > > > So this depends on other patch, so: > > 1. You need mention the dependency in cover letter (nothing there), > > 2. Re-order patches. > > > > The GPIO cannot go separate tree and this must be explicitly communicated. > > Sigh, getting an order that is sensible is really bloody difficult. It's not. Sub-devices before the MFD. The only time that doesn't work is when the sub-devices put the parent MFD in their example. The solution there is don't do that. Just 1 complete example in the MFD schema and no examples in the sub-devices. > I'm quite sure Lee is only going to want to apply the mfd bits. Indeed. I can't seem to make Lee care... All the schemas should really be applied together. > Then > what do we do with the other bits? GPIO stuff via the GPIO tree, then > wait a cycle before the rest can be merged. Or what? The schemas must be picked up in the same cycle. I don't care so much if subsystem maintainers' trees have warnings if they don't care, but I do care for linux-next. If the subsystem bits aren't picked up, then I'll pick them up if it comes to that. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-09 22:17 ` Rob Herring @ 2022-11-10 11:35 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-11-10 11:35 UTC (permalink / raw) To: Rob Herring, Russell King (Oracle) Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 07.17, Rob Herring wrote: > On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: >> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>> Add a DT binding for the Apple Mac System Management Controller. >>> >>> Drop the second, redundant "binding" from subject. It's already in prefix. >> >> Yet another thing that's been there from the start... how many more >> things are you going to pick up in subsequent versions of the patch? >> When does this stop? >> >> In any case, taking your comment literally, >> >> "dt-bindings: mfd: add for Apple Mac System Management Controller" >> >> makes no sense, so presumably you want something more than that. >> >> In any case, I see several recent cases already merged which follow >> the pattern that I've used and that you've reviewed. >> >>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>> --- >>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>>> 1 file changed, 67 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>> new file mode 100644 >>>> index 000000000000..014eba5a1bbc >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>> @@ -0,0 +1,67 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Apple Mac System Management Controller >>>> + >>>> +maintainers: >>>> + - Hector Martin <marcan@marcan.st> >>>> + >>>> +description: >>>> + Apple Mac System Management Controller implements various functions >>>> + such as GPIO, RTC, power, reboot. >>>> + >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - enum: >>>> + - apple,t6000-smc >>>> + - apple,t8103-smc >>>> + - apple,t8112-smc >>>> + - const: apple,smc >>>> + >>>> + reg: >>>> + items: >>>> + - description: SMC area >>>> + - description: SRAM area >>>> + >>>> + reg-names: >>>> + items: >>>> + - const: smc >>>> + - const: sram >>>> + >>>> + mboxes: >>>> + maxItems: 1 >>>> + >>>> + gpio: >>>> + $ref: /schemas/gpio/gpio-macsmc.yaml >>> >>> So this depends on other patch, so: >>> 1. You need mention the dependency in cover letter (nothing there), >>> 2. Re-order patches. >>> >>> The GPIO cannot go separate tree and this must be explicitly communicated. >> >> Sigh, getting an order that is sensible is really bloody difficult. > > It's not. Sub-devices before the MFD. The only time that doesn't work is > when the sub-devices put the parent MFD in their example. The solution > there is don't do that. Just 1 complete example in the MFD schema and no > examples in the sub-devices. > >> I'm quite sure Lee is only going to want to apply the mfd bits. > > Indeed. I can't seem to make Lee care... All the schemas should really > be applied together. > >> Then >> what do we do with the other bits? GPIO stuff via the GPIO tree, then >> wait a cycle before the rest can be merged. Or what? > > The schemas must be picked up in the same cycle. I don't care so much > if subsystem maintainers' trees have warnings if they don't care, but I > do care for linux-next. If the subsystem bits aren't picked up, then > I'll pick them up if it comes to that. > We can take all the schemas and DT changes via asahi-soc if that works for you. This also lets us move forward with more related DT changes that would apply on top of things already in that branch. Then Lee only has to take the mfd core bits (and possibly the RTKit platform part, or we can figure something else out for that). - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 11:35 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-11-10 11:35 UTC (permalink / raw) To: Rob Herring, Russell King (Oracle) Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 07.17, Rob Herring wrote: > On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: >> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>> Add a DT binding for the Apple Mac System Management Controller. >>> >>> Drop the second, redundant "binding" from subject. It's already in prefix. >> >> Yet another thing that's been there from the start... how many more >> things are you going to pick up in subsequent versions of the patch? >> When does this stop? >> >> In any case, taking your comment literally, >> >> "dt-bindings: mfd: add for Apple Mac System Management Controller" >> >> makes no sense, so presumably you want something more than that. >> >> In any case, I see several recent cases already merged which follow >> the pattern that I've used and that you've reviewed. >> >>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>> --- >>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>>> 1 file changed, 67 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>> new file mode 100644 >>>> index 000000000000..014eba5a1bbc >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>> @@ -0,0 +1,67 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Apple Mac System Management Controller >>>> + >>>> +maintainers: >>>> + - Hector Martin <marcan@marcan.st> >>>> + >>>> +description: >>>> + Apple Mac System Management Controller implements various functions >>>> + such as GPIO, RTC, power, reboot. >>>> + >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - enum: >>>> + - apple,t6000-smc >>>> + - apple,t8103-smc >>>> + - apple,t8112-smc >>>> + - const: apple,smc >>>> + >>>> + reg: >>>> + items: >>>> + - description: SMC area >>>> + - description: SRAM area >>>> + >>>> + reg-names: >>>> + items: >>>> + - const: smc >>>> + - const: sram >>>> + >>>> + mboxes: >>>> + maxItems: 1 >>>> + >>>> + gpio: >>>> + $ref: /schemas/gpio/gpio-macsmc.yaml >>> >>> So this depends on other patch, so: >>> 1. You need mention the dependency in cover letter (nothing there), >>> 2. Re-order patches. >>> >>> The GPIO cannot go separate tree and this must be explicitly communicated. >> >> Sigh, getting an order that is sensible is really bloody difficult. > > It's not. Sub-devices before the MFD. The only time that doesn't work is > when the sub-devices put the parent MFD in their example. The solution > there is don't do that. Just 1 complete example in the MFD schema and no > examples in the sub-devices. > >> I'm quite sure Lee is only going to want to apply the mfd bits. > > Indeed. I can't seem to make Lee care... All the schemas should really > be applied together. > >> Then >> what do we do with the other bits? GPIO stuff via the GPIO tree, then >> wait a cycle before the rest can be merged. Or what? > > The schemas must be picked up in the same cycle. I don't care so much > if subsystem maintainers' trees have warnings if they don't care, but I > do care for linux-next. If the subsystem bits aren't picked up, then > I'll pick them up if it comes to that. > We can take all the schemas and DT changes via asahi-soc if that works for you. This also lets us move forward with more related DT changes that would apply on top of things already in that branch. Then Lee only has to take the mfd core bits (and possibly the RTKit platform part, or we can figure something else out for that). - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-09 22:17 ` Rob Herring @ 2022-11-10 11:48 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 11:48 UTC (permalink / raw) To: Rob Herring Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: > On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > > > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Drop the second, redundant "binding" from subject. It's already in prefix. > > > > Yet another thing that's been there from the start... how many more > > things are you going to pick up in subsequent versions of the patch? > > When does this stop? > > > > In any case, taking your comment literally, > > > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > > > makes no sense, so presumably you want something more than that. > > > > In any case, I see several recent cases already merged which follow > > the pattern that I've used and that you've reviewed. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > --- > > > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > > > 1 file changed, 67 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > new file mode 100644 > > > > index 000000000000..014eba5a1bbc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > @@ -0,0 +1,67 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Apple Mac System Management Controller > > > > + > > > > +maintainers: > > > > + - Hector Martin <marcan@marcan.st> > > > > + > > > > +description: > > > > + Apple Mac System Management Controller implements various functions > > > > + such as GPIO, RTC, power, reboot. > > > > + > > > > +properties: > > > > + compatible: > > > > + items: > > > > + - enum: > > > > + - apple,t6000-smc > > > > + - apple,t8103-smc > > > > + - apple,t8112-smc > > > > + - const: apple,smc > > > > + > > > > + reg: > > > > + items: > > > > + - description: SMC area > > > > + - description: SRAM area > > > > + > > > > + reg-names: > > > > + items: > > > > + - const: smc > > > > + - const: sram > > > > + > > > > + mboxes: > > > > + maxItems: 1 > > > > + > > > > + gpio: > > > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > > > > > So this depends on other patch, so: > > > 1. You need mention the dependency in cover letter (nothing there), > > > 2. Re-order patches. > > > > > > The GPIO cannot go separate tree and this must be explicitly communicated. > > > > Sigh, getting an order that is sensible is really bloody difficult. > > It's not. Sub-devices before the MFD. The only time that doesn't work is > when the sub-devices put the parent MFD in their example. The solution > there is don't do that. Just 1 complete example in the MFD schema and no > examples in the sub-devices. Meanwhile, I was told by Krzysztof that DT schemas must always have an example. So, different person, different story. Anyway, I've washed my hands of this farce with this series. I'm not planning to post another version of it. I've had enough of this crap. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 11:48 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 11:48 UTC (permalink / raw) To: Rob Herring Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: > On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > > > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Drop the second, redundant "binding" from subject. It's already in prefix. > > > > Yet another thing that's been there from the start... how many more > > things are you going to pick up in subsequent versions of the patch? > > When does this stop? > > > > In any case, taking your comment literally, > > > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > > > makes no sense, so presumably you want something more than that. > > > > In any case, I see several recent cases already merged which follow > > the pattern that I've used and that you've reviewed. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > --- > > > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > > > 1 file changed, 67 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > new file mode 100644 > > > > index 000000000000..014eba5a1bbc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > @@ -0,0 +1,67 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Apple Mac System Management Controller > > > > + > > > > +maintainers: > > > > + - Hector Martin <marcan@marcan.st> > > > > + > > > > +description: > > > > + Apple Mac System Management Controller implements various functions > > > > + such as GPIO, RTC, power, reboot. > > > > + > > > > +properties: > > > > + compatible: > > > > + items: > > > > + - enum: > > > > + - apple,t6000-smc > > > > + - apple,t8103-smc > > > > + - apple,t8112-smc > > > > + - const: apple,smc > > > > + > > > > + reg: > > > > + items: > > > > + - description: SMC area > > > > + - description: SRAM area > > > > + > > > > + reg-names: > > > > + items: > > > > + - const: smc > > > > + - const: sram > > > > + > > > > + mboxes: > > > > + maxItems: 1 > > > > + > > > > + gpio: > > > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > > > > > So this depends on other patch, so: > > > 1. You need mention the dependency in cover letter (nothing there), > > > 2. Re-order patches. > > > > > > The GPIO cannot go separate tree and this must be explicitly communicated. > > > > Sigh, getting an order that is sensible is really bloody difficult. > > It's not. Sub-devices before the MFD. The only time that doesn't work is > when the sub-devices put the parent MFD in their example. The solution > there is don't do that. Just 1 complete example in the MFD schema and no > examples in the sub-devices. Meanwhile, I was told by Krzysztof that DT schemas must always have an example. So, different person, different story. Anyway, I've washed my hands of this farce with this series. I'm not planning to post another version of it. I've had enough of this crap. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-10 11:48 ` Russell King (Oracle) @ 2022-11-10 14:00 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-10 14:00 UTC (permalink / raw) To: Russell King (Oracle), Rob Herring Cc: Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 12:48, Russell King (Oracle) wrote: > On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: >> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: >>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>>> Add a DT binding for the Apple Mac System Management Controller. >>>> >>>> Drop the second, redundant "binding" from subject. It's already in prefix. >>> >>> Yet another thing that's been there from the start... how many more >>> things are you going to pick up in subsequent versions of the patch? >>> When does this stop? >>> >>> In any case, taking your comment literally, >>> >>> "dt-bindings: mfd: add for Apple Mac System Management Controller" >>> >>> makes no sense, so presumably you want something more than that. >>> >>> In any case, I see several recent cases already merged which follow >>> the pattern that I've used and that you've reviewed. >>> >>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>>> --- >>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>>>> 1 file changed, 67 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>> new file mode 100644 >>>>> index 000000000000..014eba5a1bbc >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>> @@ -0,0 +1,67 @@ >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: Apple Mac System Management Controller >>>>> + >>>>> +maintainers: >>>>> + - Hector Martin <marcan@marcan.st> >>>>> + >>>>> +description: >>>>> + Apple Mac System Management Controller implements various functions >>>>> + such as GPIO, RTC, power, reboot. >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + items: >>>>> + - enum: >>>>> + - apple,t6000-smc >>>>> + - apple,t8103-smc >>>>> + - apple,t8112-smc >>>>> + - const: apple,smc >>>>> + >>>>> + reg: >>>>> + items: >>>>> + - description: SMC area >>>>> + - description: SRAM area >>>>> + >>>>> + reg-names: >>>>> + items: >>>>> + - const: smc >>>>> + - const: sram >>>>> + >>>>> + mboxes: >>>>> + maxItems: 1 >>>>> + >>>>> + gpio: >>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml >>>> >>>> So this depends on other patch, so: >>>> 1. You need mention the dependency in cover letter (nothing there), >>>> 2. Re-order patches. >>>> >>>> The GPIO cannot go separate tree and this must be explicitly communicated. >>> >>> Sigh, getting an order that is sensible is really bloody difficult. >> >> It's not. Sub-devices before the MFD. The only time that doesn't work is >> when the sub-devices put the parent MFD in their example. The solution >> there is don't do that. Just 1 complete example in the MFD schema and no >> examples in the sub-devices. > > Meanwhile, I was told by Krzysztof that DT schemas must always have an > example. So, different person, different story. Hm, where do you see a message I told you to always have examples? Maybe in some discussion I mentioned that examples are desired, but not always. There is no point in having example in MFD child device schema if it is already part of the parent MFD binding, where it is actually required for complete picture. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 14:00 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-10 14:00 UTC (permalink / raw) To: Russell King (Oracle), Rob Herring Cc: Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 12:48, Russell King (Oracle) wrote: > On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: >> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: >>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>>> Add a DT binding for the Apple Mac System Management Controller. >>>> >>>> Drop the second, redundant "binding" from subject. It's already in prefix. >>> >>> Yet another thing that's been there from the start... how many more >>> things are you going to pick up in subsequent versions of the patch? >>> When does this stop? >>> >>> In any case, taking your comment literally, >>> >>> "dt-bindings: mfd: add for Apple Mac System Management Controller" >>> >>> makes no sense, so presumably you want something more than that. >>> >>> In any case, I see several recent cases already merged which follow >>> the pattern that I've used and that you've reviewed. >>> >>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>>> --- >>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>>>> 1 file changed, 67 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>> new file mode 100644 >>>>> index 000000000000..014eba5a1bbc >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>> @@ -0,0 +1,67 @@ >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: Apple Mac System Management Controller >>>>> + >>>>> +maintainers: >>>>> + - Hector Martin <marcan@marcan.st> >>>>> + >>>>> +description: >>>>> + Apple Mac System Management Controller implements various functions >>>>> + such as GPIO, RTC, power, reboot. >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + items: >>>>> + - enum: >>>>> + - apple,t6000-smc >>>>> + - apple,t8103-smc >>>>> + - apple,t8112-smc >>>>> + - const: apple,smc >>>>> + >>>>> + reg: >>>>> + items: >>>>> + - description: SMC area >>>>> + - description: SRAM area >>>>> + >>>>> + reg-names: >>>>> + items: >>>>> + - const: smc >>>>> + - const: sram >>>>> + >>>>> + mboxes: >>>>> + maxItems: 1 >>>>> + >>>>> + gpio: >>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml >>>> >>>> So this depends on other patch, so: >>>> 1. You need mention the dependency in cover letter (nothing there), >>>> 2. Re-order patches. >>>> >>>> The GPIO cannot go separate tree and this must be explicitly communicated. >>> >>> Sigh, getting an order that is sensible is really bloody difficult. >> >> It's not. Sub-devices before the MFD. The only time that doesn't work is >> when the sub-devices put the parent MFD in their example. The solution >> there is don't do that. Just 1 complete example in the MFD schema and no >> examples in the sub-devices. > > Meanwhile, I was told by Krzysztof that DT schemas must always have an > example. So, different person, different story. Hm, where do you see a message I told you to always have examples? Maybe in some discussion I mentioned that examples are desired, but not always. There is no point in having example in MFD child device schema if it is already part of the parent MFD binding, where it is actually required for complete picture. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-10 14:00 ` Krzysztof Kozlowski @ 2022-11-10 14:14 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 14:14 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Thu, Nov 10, 2022 at 03:00:16PM +0100, Krzysztof Kozlowski wrote: > On 10/11/2022 12:48, Russell King (Oracle) wrote: > > On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: > >> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > >>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > >>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: > >>>>> Add a DT binding for the Apple Mac System Management Controller. > >>>> > >>>> Drop the second, redundant "binding" from subject. It's already in prefix. > >>> > >>> Yet another thing that's been there from the start... how many more > >>> things are you going to pick up in subsequent versions of the patch? > >>> When does this stop? > >>> > >>> In any case, taking your comment literally, > >>> > >>> "dt-bindings: mfd: add for Apple Mac System Management Controller" > >>> > >>> makes no sense, so presumably you want something more than that. > >>> > >>> In any case, I see several recent cases already merged which follow > >>> the pattern that I've used and that you've reviewed. > >>> > >>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >>>>> --- > >>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > >>>>> 1 file changed, 67 insertions(+) > >>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>> new file mode 100644 > >>>>> index 000000000000..014eba5a1bbc > >>>>> --- /dev/null > >>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>> @@ -0,0 +1,67 @@ > >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>>>> +%YAML 1.2 > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Apple Mac System Management Controller > >>>>> + > >>>>> +maintainers: > >>>>> + - Hector Martin <marcan@marcan.st> > >>>>> + > >>>>> +description: > >>>>> + Apple Mac System Management Controller implements various functions > >>>>> + such as GPIO, RTC, power, reboot. > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + items: > >>>>> + - enum: > >>>>> + - apple,t6000-smc > >>>>> + - apple,t8103-smc > >>>>> + - apple,t8112-smc > >>>>> + - const: apple,smc > >>>>> + > >>>>> + reg: > >>>>> + items: > >>>>> + - description: SMC area > >>>>> + - description: SRAM area > >>>>> + > >>>>> + reg-names: > >>>>> + items: > >>>>> + - const: smc > >>>>> + - const: sram > >>>>> + > >>>>> + mboxes: > >>>>> + maxItems: 1 > >>>>> + > >>>>> + gpio: > >>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml > >>>> > >>>> So this depends on other patch, so: > >>>> 1. You need mention the dependency in cover letter (nothing there), > >>>> 2. Re-order patches. > >>>> > >>>> The GPIO cannot go separate tree and this must be explicitly communicated. > >>> > >>> Sigh, getting an order that is sensible is really bloody difficult. > >> > >> It's not. Sub-devices before the MFD. The only time that doesn't work is > >> when the sub-devices put the parent MFD in their example. The solution > >> there is don't do that. Just 1 complete example in the MFD schema and no > >> examples in the sub-devices. > > > > Meanwhile, I was told by Krzysztof that DT schemas must always have an > > example. So, different person, different story. > > Hm, where do you see a message I told you to always have examples? Maybe > in some discussion I mentioned that examples are desired, but not > always. There is no point in having example in MFD child device schema > if it is already part of the parent MFD binding, where it is actually > required for complete picture. 35ed6e48-40e6-eb14-72de-9a0a4f5b38f8@linaro.org and 2e2356f2-ded1-3cbf-4456-20054a8defda@linaro.org For the GPIO macsec binding. So I'm getting contradictory information. First you say that I need an example in the gpio macsec DT binding yaml document. Now I'm told it should go in the parent. Make up your bloody minds and stop pissing me about. This is why I've given up trying to get this in. Getting a consistent message would be nice, but it seems impossible. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 14:14 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 14:14 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Thu, Nov 10, 2022 at 03:00:16PM +0100, Krzysztof Kozlowski wrote: > On 10/11/2022 12:48, Russell King (Oracle) wrote: > > On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: > >> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > >>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > >>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: > >>>>> Add a DT binding for the Apple Mac System Management Controller. > >>>> > >>>> Drop the second, redundant "binding" from subject. It's already in prefix. > >>> > >>> Yet another thing that's been there from the start... how many more > >>> things are you going to pick up in subsequent versions of the patch? > >>> When does this stop? > >>> > >>> In any case, taking your comment literally, > >>> > >>> "dt-bindings: mfd: add for Apple Mac System Management Controller" > >>> > >>> makes no sense, so presumably you want something more than that. > >>> > >>> In any case, I see several recent cases already merged which follow > >>> the pattern that I've used and that you've reviewed. > >>> > >>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >>>>> --- > >>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > >>>>> 1 file changed, 67 insertions(+) > >>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>> new file mode 100644 > >>>>> index 000000000000..014eba5a1bbc > >>>>> --- /dev/null > >>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>> @@ -0,0 +1,67 @@ > >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>>>> +%YAML 1.2 > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Apple Mac System Management Controller > >>>>> + > >>>>> +maintainers: > >>>>> + - Hector Martin <marcan@marcan.st> > >>>>> + > >>>>> +description: > >>>>> + Apple Mac System Management Controller implements various functions > >>>>> + such as GPIO, RTC, power, reboot. > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + items: > >>>>> + - enum: > >>>>> + - apple,t6000-smc > >>>>> + - apple,t8103-smc > >>>>> + - apple,t8112-smc > >>>>> + - const: apple,smc > >>>>> + > >>>>> + reg: > >>>>> + items: > >>>>> + - description: SMC area > >>>>> + - description: SRAM area > >>>>> + > >>>>> + reg-names: > >>>>> + items: > >>>>> + - const: smc > >>>>> + - const: sram > >>>>> + > >>>>> + mboxes: > >>>>> + maxItems: 1 > >>>>> + > >>>>> + gpio: > >>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml > >>>> > >>>> So this depends on other patch, so: > >>>> 1. You need mention the dependency in cover letter (nothing there), > >>>> 2. Re-order patches. > >>>> > >>>> The GPIO cannot go separate tree and this must be explicitly communicated. > >>> > >>> Sigh, getting an order that is sensible is really bloody difficult. > >> > >> It's not. Sub-devices before the MFD. The only time that doesn't work is > >> when the sub-devices put the parent MFD in their example. The solution > >> there is don't do that. Just 1 complete example in the MFD schema and no > >> examples in the sub-devices. > > > > Meanwhile, I was told by Krzysztof that DT schemas must always have an > > example. So, different person, different story. > > Hm, where do you see a message I told you to always have examples? Maybe > in some discussion I mentioned that examples are desired, but not > always. There is no point in having example in MFD child device schema > if it is already part of the parent MFD binding, where it is actually > required for complete picture. 35ed6e48-40e6-eb14-72de-9a0a4f5b38f8@linaro.org and 2e2356f2-ded1-3cbf-4456-20054a8defda@linaro.org For the GPIO macsec binding. So I'm getting contradictory information. First you say that I need an example in the gpio macsec DT binding yaml document. Now I'm told it should go in the parent. Make up your bloody minds and stop pissing me about. This is why I've given up trying to get this in. Getting a consistent message would be nice, but it seems impossible. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-10 14:14 ` Russell King (Oracle) @ 2022-11-10 14:21 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-10 14:21 UTC (permalink / raw) To: Russell King (Oracle) Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 15:14, Russell King (Oracle) wrote: > On Thu, Nov 10, 2022 at 03:00:16PM +0100, Krzysztof Kozlowski wrote: >> On 10/11/2022 12:48, Russell King (Oracle) wrote: >>> On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: >>>> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: >>>>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >>>>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>>>>> Add a DT binding for the Apple Mac System Management Controller. >>>>>> >>>>>> Drop the second, redundant "binding" from subject. It's already in prefix. >>>>> >>>>> Yet another thing that's been there from the start... how many more >>>>> things are you going to pick up in subsequent versions of the patch? >>>>> When does this stop? >>>>> >>>>> In any case, taking your comment literally, >>>>> >>>>> "dt-bindings: mfd: add for Apple Mac System Management Controller" >>>>> >>>>> makes no sense, so presumably you want something more than that. >>>>> >>>>> In any case, I see several recent cases already merged which follow >>>>> the pattern that I've used and that you've reviewed. >>>>> >>>>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>>>>> --- >>>>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>>>>>> 1 file changed, 67 insertions(+) >>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>>>> new file mode 100644 >>>>>>> index 000000000000..014eba5a1bbc >>>>>>> --- /dev/null >>>>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>>>> @@ -0,0 +1,67 @@ >>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>>>> +%YAML 1.2 >>>>>>> +--- >>>>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>> + >>>>>>> +title: Apple Mac System Management Controller >>>>>>> + >>>>>>> +maintainers: >>>>>>> + - Hector Martin <marcan@marcan.st> >>>>>>> + >>>>>>> +description: >>>>>>> + Apple Mac System Management Controller implements various functions >>>>>>> + such as GPIO, RTC, power, reboot. >>>>>>> + >>>>>>> +properties: >>>>>>> + compatible: >>>>>>> + items: >>>>>>> + - enum: >>>>>>> + - apple,t6000-smc >>>>>>> + - apple,t8103-smc >>>>>>> + - apple,t8112-smc >>>>>>> + - const: apple,smc >>>>>>> + >>>>>>> + reg: >>>>>>> + items: >>>>>>> + - description: SMC area >>>>>>> + - description: SRAM area >>>>>>> + >>>>>>> + reg-names: >>>>>>> + items: >>>>>>> + - const: smc >>>>>>> + - const: sram >>>>>>> + >>>>>>> + mboxes: >>>>>>> + maxItems: 1 >>>>>>> + >>>>>>> + gpio: >>>>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml >>>>>> >>>>>> So this depends on other patch, so: >>>>>> 1. You need mention the dependency in cover letter (nothing there), >>>>>> 2. Re-order patches. >>>>>> >>>>>> The GPIO cannot go separate tree and this must be explicitly communicated. >>>>> >>>>> Sigh, getting an order that is sensible is really bloody difficult. >>>> >>>> It's not. Sub-devices before the MFD. The only time that doesn't work is >>>> when the sub-devices put the parent MFD in their example. The solution >>>> there is don't do that. Just 1 complete example in the MFD schema and no >>>> examples in the sub-devices. >>> >>> Meanwhile, I was told by Krzysztof that DT schemas must always have an >>> example. So, different person, different story. >> >> Hm, where do you see a message I told you to always have examples? Maybe >> in some discussion I mentioned that examples are desired, but not >> always. There is no point in having example in MFD child device schema >> if it is already part of the parent MFD binding, where it is actually >> required for complete picture. > > 35ed6e48-40e6-eb14-72de-9a0a4f5b38f8@linaro.org > > and That was independent schema, no references to MFD, thus my comment. If you post such stuff alone without indication it is part of MFD, what do you expect from reviewers? > > 2e2356f2-ded1-3cbf-4456-20054a8defda@linaro.org Which was comment about MFD, right? It is expected to have example for MFD. I never said it is mandatory for every schema, which you implied in previous mailing. > > For the GPIO macsec binding. So I'm getting contradictory information. > First you say that I need an example in the gpio macsec DT binding > yaml document. First you split patches making reviewers life difficult. Then reviewers don't get entire concept and they answer based what they got. > > Now I'm told it should go in the parent. After posting entire patchset with context you can get better review, yes, that's right. > > Make up your bloody minds and stop pissing me about. This is why I've > given up trying to get this in. I don't think it is constructive to discuss this with you anymore. > > Getting a consistent message would be nice, but it seems impossible. > Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 14:21 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-10 14:21 UTC (permalink / raw) To: Russell King (Oracle) Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 15:14, Russell King (Oracle) wrote: > On Thu, Nov 10, 2022 at 03:00:16PM +0100, Krzysztof Kozlowski wrote: >> On 10/11/2022 12:48, Russell King (Oracle) wrote: >>> On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: >>>> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: >>>>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: >>>>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>>>>> Add a DT binding for the Apple Mac System Management Controller. >>>>>> >>>>>> Drop the second, redundant "binding" from subject. It's already in prefix. >>>>> >>>>> Yet another thing that's been there from the start... how many more >>>>> things are you going to pick up in subsequent versions of the patch? >>>>> When does this stop? >>>>> >>>>> In any case, taking your comment literally, >>>>> >>>>> "dt-bindings: mfd: add for Apple Mac System Management Controller" >>>>> >>>>> makes no sense, so presumably you want something more than that. >>>>> >>>>> In any case, I see several recent cases already merged which follow >>>>> the pattern that I've used and that you've reviewed. >>>>> >>>>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>>>>> --- >>>>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ >>>>>>> 1 file changed, 67 insertions(+) >>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>>>> new file mode 100644 >>>>>>> index 000000000000..014eba5a1bbc >>>>>>> --- /dev/null >>>>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml >>>>>>> @@ -0,0 +1,67 @@ >>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>>>> +%YAML 1.2 >>>>>>> +--- >>>>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>> + >>>>>>> +title: Apple Mac System Management Controller >>>>>>> + >>>>>>> +maintainers: >>>>>>> + - Hector Martin <marcan@marcan.st> >>>>>>> + >>>>>>> +description: >>>>>>> + Apple Mac System Management Controller implements various functions >>>>>>> + such as GPIO, RTC, power, reboot. >>>>>>> + >>>>>>> +properties: >>>>>>> + compatible: >>>>>>> + items: >>>>>>> + - enum: >>>>>>> + - apple,t6000-smc >>>>>>> + - apple,t8103-smc >>>>>>> + - apple,t8112-smc >>>>>>> + - const: apple,smc >>>>>>> + >>>>>>> + reg: >>>>>>> + items: >>>>>>> + - description: SMC area >>>>>>> + - description: SRAM area >>>>>>> + >>>>>>> + reg-names: >>>>>>> + items: >>>>>>> + - const: smc >>>>>>> + - const: sram >>>>>>> + >>>>>>> + mboxes: >>>>>>> + maxItems: 1 >>>>>>> + >>>>>>> + gpio: >>>>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml >>>>>> >>>>>> So this depends on other patch, so: >>>>>> 1. You need mention the dependency in cover letter (nothing there), >>>>>> 2. Re-order patches. >>>>>> >>>>>> The GPIO cannot go separate tree and this must be explicitly communicated. >>>>> >>>>> Sigh, getting an order that is sensible is really bloody difficult. >>>> >>>> It's not. Sub-devices before the MFD. The only time that doesn't work is >>>> when the sub-devices put the parent MFD in their example. The solution >>>> there is don't do that. Just 1 complete example in the MFD schema and no >>>> examples in the sub-devices. >>> >>> Meanwhile, I was told by Krzysztof that DT schemas must always have an >>> example. So, different person, different story. >> >> Hm, where do you see a message I told you to always have examples? Maybe >> in some discussion I mentioned that examples are desired, but not >> always. There is no point in having example in MFD child device schema >> if it is already part of the parent MFD binding, where it is actually >> required for complete picture. > > 35ed6e48-40e6-eb14-72de-9a0a4f5b38f8@linaro.org > > and That was independent schema, no references to MFD, thus my comment. If you post such stuff alone without indication it is part of MFD, what do you expect from reviewers? > > 2e2356f2-ded1-3cbf-4456-20054a8defda@linaro.org Which was comment about MFD, right? It is expected to have example for MFD. I never said it is mandatory for every schema, which you implied in previous mailing. > > For the GPIO macsec binding. So I'm getting contradictory information. > First you say that I need an example in the gpio macsec DT binding > yaml document. First you split patches making reviewers life difficult. Then reviewers don't get entire concept and they answer based what they got. > > Now I'm told it should go in the parent. After posting entire patchset with context you can get better review, yes, that's right. > > Make up your bloody minds and stop pissing me about. This is why I've > given up trying to get this in. I don't think it is constructive to discuss this with you anymore. > > Getting a consistent message would be nice, but it seems impossible. > Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-10 14:21 ` Krzysztof Kozlowski @ 2022-11-10 14:23 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 14:23 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Thu, Nov 10, 2022 at 03:21:35PM +0100, Krzysztof Kozlowski wrote: > On 10/11/2022 15:14, Russell King (Oracle) wrote: > > On Thu, Nov 10, 2022 at 03:00:16PM +0100, Krzysztof Kozlowski wrote: > >> On 10/11/2022 12:48, Russell King (Oracle) wrote: > >>> On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: > >>>> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > >>>>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > >>>>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: > >>>>>>> Add a DT binding for the Apple Mac System Management Controller. > >>>>>> > >>>>>> Drop the second, redundant "binding" from subject. It's already in prefix. > >>>>> > >>>>> Yet another thing that's been there from the start... how many more > >>>>> things are you going to pick up in subsequent versions of the patch? > >>>>> When does this stop? > >>>>> > >>>>> In any case, taking your comment literally, > >>>>> > >>>>> "dt-bindings: mfd: add for Apple Mac System Management Controller" > >>>>> > >>>>> makes no sense, so presumably you want something more than that. > >>>>> > >>>>> In any case, I see several recent cases already merged which follow > >>>>> the pattern that I've used and that you've reviewed. > >>>>> > >>>>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >>>>>>> --- > >>>>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > >>>>>>> 1 file changed, 67 insertions(+) > >>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>>>> > >>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>>>> new file mode 100644 > >>>>>>> index 000000000000..014eba5a1bbc > >>>>>>> --- /dev/null > >>>>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>>>> @@ -0,0 +1,67 @@ > >>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>>>>>> +%YAML 1.2 > >>>>>>> +--- > >>>>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>>>> + > >>>>>>> +title: Apple Mac System Management Controller > >>>>>>> + > >>>>>>> +maintainers: > >>>>>>> + - Hector Martin <marcan@marcan.st> > >>>>>>> + > >>>>>>> +description: > >>>>>>> + Apple Mac System Management Controller implements various functions > >>>>>>> + such as GPIO, RTC, power, reboot. > >>>>>>> + > >>>>>>> +properties: > >>>>>>> + compatible: > >>>>>>> + items: > >>>>>>> + - enum: > >>>>>>> + - apple,t6000-smc > >>>>>>> + - apple,t8103-smc > >>>>>>> + - apple,t8112-smc > >>>>>>> + - const: apple,smc > >>>>>>> + > >>>>>>> + reg: > >>>>>>> + items: > >>>>>>> + - description: SMC area > >>>>>>> + - description: SRAM area > >>>>>>> + > >>>>>>> + reg-names: > >>>>>>> + items: > >>>>>>> + - const: smc > >>>>>>> + - const: sram > >>>>>>> + > >>>>>>> + mboxes: > >>>>>>> + maxItems: 1 > >>>>>>> + > >>>>>>> + gpio: > >>>>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml > >>>>>> > >>>>>> So this depends on other patch, so: > >>>>>> 1. You need mention the dependency in cover letter (nothing there), > >>>>>> 2. Re-order patches. > >>>>>> > >>>>>> The GPIO cannot go separate tree and this must be explicitly communicated. > >>>>> > >>>>> Sigh, getting an order that is sensible is really bloody difficult. > >>>> > >>>> It's not. Sub-devices before the MFD. The only time that doesn't work is > >>>> when the sub-devices put the parent MFD in their example. The solution > >>>> there is don't do that. Just 1 complete example in the MFD schema and no > >>>> examples in the sub-devices. > >>> > >>> Meanwhile, I was told by Krzysztof that DT schemas must always have an > >>> example. So, different person, different story. > >> > >> Hm, where do you see a message I told you to always have examples? Maybe > >> in some discussion I mentioned that examples are desired, but not > >> always. There is no point in having example in MFD child device schema > >> if it is already part of the parent MFD binding, where it is actually > >> required for complete picture. > > > > 35ed6e48-40e6-eb14-72de-9a0a4f5b38f8@linaro.org > > > > and > > That was independent schema, no references to MFD, thus my comment. If > you post such stuff alone without indication it is part of MFD, what do > you expect from reviewers? > > > > > 2e2356f2-ded1-3cbf-4456-20054a8defda@linaro.org > > Which was comment about MFD, right? It is expected to have example for > MFD. I never said it is mandatory for every schema, which you implied in > previous mailing. > > > > > > For the GPIO macsec binding. So I'm getting contradictory information. > > First you say that I need an example in the gpio macsec DT binding > > yaml document. > > First you split patches making reviewers life difficult. Then reviewers > don't get entire concept and they answer based what they got. > > > > > Now I'm told it should go in the parent. > > After posting entire patchset with context you can get better review, > yes, that's right. > > > > > Make up your bloody minds and stop pissing me about. This is why I've > > given up trying to get this in. > > I don't think it is constructive to discuss this with you anymore. > > > > > Getting a consistent message would be nice, but it seems impossible. > > > In which case you CLEARLY didn't read the cover message to that two patch series. Again, YOU are giving contradictory information. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 14:23 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 14:23 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Thu, Nov 10, 2022 at 03:21:35PM +0100, Krzysztof Kozlowski wrote: > On 10/11/2022 15:14, Russell King (Oracle) wrote: > > On Thu, Nov 10, 2022 at 03:00:16PM +0100, Krzysztof Kozlowski wrote: > >> On 10/11/2022 12:48, Russell King (Oracle) wrote: > >>> On Wed, Nov 09, 2022 at 04:17:23PM -0600, Rob Herring wrote: > >>>> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > >>>>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > >>>>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: > >>>>>>> Add a DT binding for the Apple Mac System Management Controller. > >>>>>> > >>>>>> Drop the second, redundant "binding" from subject. It's already in prefix. > >>>>> > >>>>> Yet another thing that's been there from the start... how many more > >>>>> things are you going to pick up in subsequent versions of the patch? > >>>>> When does this stop? > >>>>> > >>>>> In any case, taking your comment literally, > >>>>> > >>>>> "dt-bindings: mfd: add for Apple Mac System Management Controller" > >>>>> > >>>>> makes no sense, so presumably you want something more than that. > >>>>> > >>>>> In any case, I see several recent cases already merged which follow > >>>>> the pattern that I've used and that you've reviewed. > >>>>> > >>>>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >>>>>>> --- > >>>>>>> .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > >>>>>>> 1 file changed, 67 insertions(+) > >>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>>>> > >>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>>>> new file mode 100644 > >>>>>>> index 000000000000..014eba5a1bbc > >>>>>>> --- /dev/null > >>>>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > >>>>>>> @@ -0,0 +1,67 @@ > >>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>>>>>> +%YAML 1.2 > >>>>>>> +--- > >>>>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>>>> + > >>>>>>> +title: Apple Mac System Management Controller > >>>>>>> + > >>>>>>> +maintainers: > >>>>>>> + - Hector Martin <marcan@marcan.st> > >>>>>>> + > >>>>>>> +description: > >>>>>>> + Apple Mac System Management Controller implements various functions > >>>>>>> + such as GPIO, RTC, power, reboot. > >>>>>>> + > >>>>>>> +properties: > >>>>>>> + compatible: > >>>>>>> + items: > >>>>>>> + - enum: > >>>>>>> + - apple,t6000-smc > >>>>>>> + - apple,t8103-smc > >>>>>>> + - apple,t8112-smc > >>>>>>> + - const: apple,smc > >>>>>>> + > >>>>>>> + reg: > >>>>>>> + items: > >>>>>>> + - description: SMC area > >>>>>>> + - description: SRAM area > >>>>>>> + > >>>>>>> + reg-names: > >>>>>>> + items: > >>>>>>> + - const: smc > >>>>>>> + - const: sram > >>>>>>> + > >>>>>>> + mboxes: > >>>>>>> + maxItems: 1 > >>>>>>> + > >>>>>>> + gpio: > >>>>>>> + $ref: /schemas/gpio/gpio-macsmc.yaml > >>>>>> > >>>>>> So this depends on other patch, so: > >>>>>> 1. You need mention the dependency in cover letter (nothing there), > >>>>>> 2. Re-order patches. > >>>>>> > >>>>>> The GPIO cannot go separate tree and this must be explicitly communicated. > >>>>> > >>>>> Sigh, getting an order that is sensible is really bloody difficult. > >>>> > >>>> It's not. Sub-devices before the MFD. The only time that doesn't work is > >>>> when the sub-devices put the parent MFD in their example. The solution > >>>> there is don't do that. Just 1 complete example in the MFD schema and no > >>>> examples in the sub-devices. > >>> > >>> Meanwhile, I was told by Krzysztof that DT schemas must always have an > >>> example. So, different person, different story. > >> > >> Hm, where do you see a message I told you to always have examples? Maybe > >> in some discussion I mentioned that examples are desired, but not > >> always. There is no point in having example in MFD child device schema > >> if it is already part of the parent MFD binding, where it is actually > >> required for complete picture. > > > > 35ed6e48-40e6-eb14-72de-9a0a4f5b38f8@linaro.org > > > > and > > That was independent schema, no references to MFD, thus my comment. If > you post such stuff alone without indication it is part of MFD, what do > you expect from reviewers? > > > > > 2e2356f2-ded1-3cbf-4456-20054a8defda@linaro.org > > Which was comment about MFD, right? It is expected to have example for > MFD. I never said it is mandatory for every schema, which you implied in > previous mailing. > > > > > > For the GPIO macsec binding. So I'm getting contradictory information. > > First you say that I need an example in the gpio macsec DT binding > > yaml document. > > First you split patches making reviewers life difficult. Then reviewers > don't get entire concept and they answer based what they got. > > > > > Now I'm told it should go in the parent. > > After posting entire patchset with context you can get better review, > yes, that's right. > > > > > Make up your bloody minds and stop pissing me about. This is why I've > > given up trying to get this in. > > I don't think it is constructive to discuss this with you anymore. > > > > > Getting a consistent message would be nice, but it seems impossible. > > > In which case you CLEARLY didn't read the cover message to that two patch series. Again, YOU are giving contradictory information. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-10 14:23 ` Russell King (Oracle) @ 2022-11-10 14:36 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-10 14:36 UTC (permalink / raw) To: Russell King (Oracle) Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 15:23, Russell King (Oracle) wrote: >>> >>> Make up your bloody minds and stop pissing me about. This is why I've >>> given up trying to get this in. >> >> I don't think it is constructive to discuss this with you anymore. >> >>> >>> Getting a consistent message would be nice, but it seems impossible. >>> >> > > In which case you CLEARLY didn't read the cover message to that two > patch series. I have every day 100-200 new patches, so not every cover letter gets enough attention. Your did not say this is part of MFD, just mentioned some build dependency. Anyway, job of submitter is to make the patch and its context readable to the reviewers. There is literally nothing about including in parent MFD node in DT. Just take a look: https://lore.kernel.org/all/Y1q5jW8ff0aUdjPd@shell.armlinux.org.uk/ Or maybe you refer to this: "previously posted before the last merge window." Yes, so I will go through hundreds of emails from a week or months to satisfy you? "this driver is dependent on the Apple SMC driver in order to be buildable and usable." The only hint... it's about driver, not MFD. Make it obvious for readers, not obvious for you. "It is expected that this Apple SMC driver will be merged via Lee's MFD tree." Maybe there is dependency, maybe not, who the heck knows. > Again, YOU are giving contradictory information. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 14:36 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-10 14:36 UTC (permalink / raw) To: Russell King (Oracle) Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 10/11/2022 15:23, Russell King (Oracle) wrote: >>> >>> Make up your bloody minds and stop pissing me about. This is why I've >>> given up trying to get this in. >> >> I don't think it is constructive to discuss this with you anymore. >> >>> >>> Getting a consistent message would be nice, but it seems impossible. >>> >> > > In which case you CLEARLY didn't read the cover message to that two > patch series. I have every day 100-200 new patches, so not every cover letter gets enough attention. Your did not say this is part of MFD, just mentioned some build dependency. Anyway, job of submitter is to make the patch and its context readable to the reviewers. There is literally nothing about including in parent MFD node in DT. Just take a look: https://lore.kernel.org/all/Y1q5jW8ff0aUdjPd@shell.armlinux.org.uk/ Or maybe you refer to this: "previously posted before the last merge window." Yes, so I will go through hundreds of emails from a week or months to satisfy you? "this driver is dependent on the Apple SMC driver in order to be buildable and usable." The only hint... it's about driver, not MFD. Make it obvious for readers, not obvious for you. "It is expected that this Apple SMC driver will be merged via Lee's MFD tree." Maybe there is dependency, maybe not, who the heck knows. > Again, YOU are giving contradictory information. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-10 14:36 ` Krzysztof Kozlowski @ 2022-11-10 14:43 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 14:43 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Thu, Nov 10, 2022 at 03:36:17PM +0100, Krzysztof Kozlowski wrote: > On 10/11/2022 15:23, Russell King (Oracle) wrote: > >>> > >>> Make up your bloody minds and stop pissing me about. This is why I've > >>> given up trying to get this in. > >> > >> I don't think it is constructive to discuss this with you anymore. > >> > >>> > >>> Getting a consistent message would be nice, but it seems impossible. > >>> > >> > > > > In which case you CLEARLY didn't read the cover message to that two > > patch series. > > I have every day 100-200 new patches, so not every cover letter gets > enough attention. Your did not say this is part of MFD, just mentioned > some build dependency. > > Anyway, job of submitter is to make the patch and its context readable > to the reviewers. > > There is literally nothing about including in parent MFD node in DT. > Just take a look: > > https://lore.kernel.org/all/Y1q5jW8ff0aUdjPd@shell.armlinux.org.uk/ > > Or maybe you refer to this: > "previously posted before the last merge window." > Yes, so I will go through hundreds of emails from a week or months to > satisfy you? > > "this driver is dependent on the > Apple SMC driver in order to be buildable and usable." > > The only hint... it's about driver, not MFD. Make it obvious for > readers, not obvious for you. > > "It is expected > that this Apple SMC driver will be merged via Lee's MFD tree." > > Maybe there is dependency, maybe not, who the heck knows. Everything that needed to be said was said in the cover message. I'm not going to bother continuing with this thread because there is nothing more to be said. This is getting utterly idiotic. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-10 14:43 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-10 14:43 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Thu, Nov 10, 2022 at 03:36:17PM +0100, Krzysztof Kozlowski wrote: > On 10/11/2022 15:23, Russell King (Oracle) wrote: > >>> > >>> Make up your bloody minds and stop pissing me about. This is why I've > >>> given up trying to get this in. > >> > >> I don't think it is constructive to discuss this with you anymore. > >> > >>> > >>> Getting a consistent message would be nice, but it seems impossible. > >>> > >> > > > > In which case you CLEARLY didn't read the cover message to that two > > patch series. > > I have every day 100-200 new patches, so not every cover letter gets > enough attention. Your did not say this is part of MFD, just mentioned > some build dependency. > > Anyway, job of submitter is to make the patch and its context readable > to the reviewers. > > There is literally nothing about including in parent MFD node in DT. > Just take a look: > > https://lore.kernel.org/all/Y1q5jW8ff0aUdjPd@shell.armlinux.org.uk/ > > Or maybe you refer to this: > "previously posted before the last merge window." > Yes, so I will go through hundreds of emails from a week or months to > satisfy you? > > "this driver is dependent on the > Apple SMC driver in order to be buildable and usable." > > The only hint... it's about driver, not MFD. Make it obvious for > readers, not obvious for you. > > "It is expected > that this Apple SMC driver will be merged via Lee's MFD tree." > > Maybe there is dependency, maybe not, who the heck knows. Everything that needed to be said was said in the cover message. I'm not going to bother continuing with this thread because there is nothing more to be said. This is getting utterly idiotic. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-09 22:17 ` Rob Herring @ 2022-11-14 10:05 ` Lee Jones -1 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-14 10:05 UTC (permalink / raw) To: Rob Herring Cc: Russell King (Oracle), Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Wed, 09 Nov 2022, Rob Herring wrote: > On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > > > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Drop the second, redundant "binding" from subject. It's already in prefix. > > > > Yet another thing that's been there from the start... how many more > > things are you going to pick up in subsequent versions of the patch? > > When does this stop? > > > > In any case, taking your comment literally, > > > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > > > makes no sense, so presumably you want something more than that. > > > > In any case, I see several recent cases already merged which follow > > the pattern that I've used and that you've reviewed. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > --- > > > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > > > 1 file changed, 67 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > new file mode 100644 > > > > index 000000000000..014eba5a1bbc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > @@ -0,0 +1,67 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Apple Mac System Management Controller > > > > + > > > > +maintainers: > > > > + - Hector Martin <marcan@marcan.st> > > > > + > > > > +description: > > > > + Apple Mac System Management Controller implements various functions > > > > + such as GPIO, RTC, power, reboot. > > > > + > > > > +properties: > > > > + compatible: > > > > + items: > > > > + - enum: > > > > + - apple,t6000-smc > > > > + - apple,t8103-smc > > > > + - apple,t8112-smc > > > > + - const: apple,smc > > > > + > > > > + reg: > > > > + items: > > > > + - description: SMC area > > > > + - description: SRAM area > > > > + > > > > + reg-names: > > > > + items: > > > > + - const: smc > > > > + - const: sram > > > > + > > > > + mboxes: > > > > + maxItems: 1 > > > > + > > > > + gpio: > > > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > > > > > So this depends on other patch, so: > > > 1. You need mention the dependency in cover letter (nothing there), > > > 2. Re-order patches. > > > > > > The GPIO cannot go separate tree and this must be explicitly communicated. > > > > Sigh, getting an order that is sensible is really bloody difficult. > > It's not. Sub-devices before the MFD. The only time that doesn't work is > when the sub-devices put the parent MFD in their example. The solution > there is don't do that. Just 1 complete example in the MFD schema and no > examples in the sub-devices. > > > I'm quite sure Lee is only going to want to apply the mfd bits. > > Indeed. I can't seem to make Lee care... All the schemas should really > be applied together. I care about drivers. Happy to take the set as a whole if it helps. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-14 10:05 ` Lee Jones 0 siblings, 0 replies; 342+ messages in thread From: Lee Jones @ 2022-11-14 10:05 UTC (permalink / raw) To: Rob Herring Cc: Russell King (Oracle), Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Wed, 09 Nov 2022, Rob Herring wrote: > On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote: > > On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote: > > > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > > > Add a DT binding for the Apple Mac System Management Controller. > > > > > > Drop the second, redundant "binding" from subject. It's already in prefix. > > > > Yet another thing that's been there from the start... how many more > > things are you going to pick up in subsequent versions of the patch? > > When does this stop? > > > > In any case, taking your comment literally, > > > > "dt-bindings: mfd: add for Apple Mac System Management Controller" > > > > makes no sense, so presumably you want something more than that. > > > > In any case, I see several recent cases already merged which follow > > the pattern that I've used and that you've reviewed. > > > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > > > --- > > > > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > > > > 1 file changed, 67 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > new file mode 100644 > > > > index 000000000000..014eba5a1bbc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml > > > > @@ -0,0 +1,67 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Apple Mac System Management Controller > > > > + > > > > +maintainers: > > > > + - Hector Martin <marcan@marcan.st> > > > > + > > > > +description: > > > > + Apple Mac System Management Controller implements various functions > > > > + such as GPIO, RTC, power, reboot. > > > > + > > > > +properties: > > > > + compatible: > > > > + items: > > > > + - enum: > > > > + - apple,t6000-smc > > > > + - apple,t8103-smc > > > > + - apple,t8112-smc > > > > + - const: apple,smc > > > > + > > > > + reg: > > > > + items: > > > > + - description: SMC area > > > > + - description: SRAM area > > > > + > > > > + reg-names: > > > > + items: > > > > + - const: smc > > > > + - const: sram > > > > + > > > > + mboxes: > > > > + maxItems: 1 > > > > + > > > > + gpio: > > > > + $ref: /schemas/gpio/gpio-macsmc.yaml > > > > > > So this depends on other patch, so: > > > 1. You need mention the dependency in cover letter (nothing there), > > > 2. Re-order patches. > > > > > > The GPIO cannot go separate tree and this must be explicitly communicated. > > > > Sigh, getting an order that is sensible is really bloody difficult. > > It's not. Sub-devices before the MFD. The only time that doesn't work is > when the sub-devices put the parent MFD in their example. The solution > there is don't do that. Just 1 complete example in the MFD schema and no > examples in the sub-devices. > > > I'm quite sure Lee is only going to want to apply the mfd bits. > > Indeed. I can't seem to make Lee care... All the schemas should really > be applied together. I care about drivers. Happy to take the set as a whole if it helps. -- Lee Jones [李琼斯] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller 2022-11-08 16:33 ` Russell King (Oracle) @ 2022-11-08 22:30 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-11-08 22:30 UTC (permalink / raw) To: Russell King (Oracle) Cc: Steven Rostedt, Rasmus Villemoes, Linus Walleij, Jonathan Corbet, linux-gpio, linux-doc, Sven Peter, Alyssa Rosenzweig, Rob Herring, Krzysztof Kozlowski, Andy Shevchenko, Lee Jones, Hector Martin, asahi, linux-arm-kernel, Petr Mladek, devicetree, Bartosz Golaszewski, Sergey Senozhatsky On Tue, 08 Nov 2022 16:33:27 +0000, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/mfd/apple,smc.yaml: Unable to find schema file matching $id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: gpio: False schema does not allow {'gpio-controller': True, '#gpio-cells': [[2]]} From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/apple,smc.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller @ 2022-11-08 22:30 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-11-08 22:30 UTC (permalink / raw) To: Russell King (Oracle) Cc: Steven Rostedt, Rasmus Villemoes, Linus Walleij, Jonathan Corbet, linux-gpio, linux-doc, Sven Peter, Alyssa Rosenzweig, Rob Herring, Krzysztof Kozlowski, Andy Shevchenko, Lee Jones, Hector Martin, asahi, linux-arm-kernel, Petr Mladek, devicetree, Bartosz Golaszewski, Sergey Senozhatsky On Tue, 08 Nov 2022 16:33:27 +0000, Russell King (Oracle) wrote: > Add a DT binding for the Apple Mac System Management Controller. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../devicetree/bindings/mfd/apple,smc.yaml | 67 +++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/mfd/apple,smc.yaml: Unable to find schema file matching $id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: gpio: False schema does not allow {'gpio-controller': True, '#gpio-cells': [[2]]} From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/apple,smc.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 4/7] platform/apple: Add new Apple Mac SMC driver 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements support for the SMC (System Management Controller) in Apple Macs. In contrast to the existing applesmc driver, it uses pluggable backends that allow it to support different SMC implementations, and uses the MFD subsystem to expose the core SMC functionality so that specific features (gpio, hwmon, battery, etc.) can be implemented by separate drivers in their respective downstream subsystems. The initial RTKit backend adds support for Apple Silicon Macs (M1 et al). We hope a backend for T2 Macs will be written in the future (since those are not supported by applesmc), and eventually an x86 backend would allow us to fully deprecate applesmc in favor of this driver. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 34 ++ drivers/platform/apple/Makefile | 7 + drivers/platform/apple/macsmc-rtkit.c | 455 ++++++++++++++++++++++++++ 5 files changed, 499 insertions(+) create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/macsmc-rtkit.c diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index dbd327712205..31a361ecfc5e 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -15,4 +15,6 @@ source "drivers/platform/olpc/Kconfig" source "drivers/platform/surface/Kconfig" +source "drivers/platform/apple/Kconfig" + source "drivers/platform/x86/Kconfig" diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 41640172975a..d2baa4eb4f13 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig new file mode 100644 index 000000000000..35963c348d05 --- /dev/null +++ b/drivers/platform/apple/Kconfig @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Apple Platform-Specific Drivers +# + +menuconfig APPLE_PLATFORMS + bool "Apple Mac Platform-Specific Device Drivers" + depends on ARCH_APPLE || X86 || COMPILE_TEST + default ARCH_APPLE + help + Say Y here to get to see options for platform-specific device drivers + for Apple devices. This option alone does not add any kernel code. + + If you say N, all options in this submenu will be skipped and disabled. + +if APPLE_PLATFORMS + +config APPLE_SMC_RTKIT + tristate "Apple SMC RTKit backend" + depends on ARCH_APPLE || (COMPILE_TEST && 64BIT) + depends on APPLE_RTKIT + default ARCH_APPLE + select MFD_MACSMC + help + Build support for the Apple System Management Controller found in + Apple Macs, communicated with via the RTKit backend. This is required + for Apple Silicon Macs. + + Say Y here if you have an Apple Silicon Mac. + + To compile this driver as a module, choose M here: the module will + be called macsmc-rtkit. + +endif diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile new file mode 100644 index 000000000000..16cce9061ee8 --- /dev/null +++ b/drivers/platform/apple/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for linux/drivers/platform/apple +# Apple Platform-Specific Drivers +# + +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o diff --git a/drivers/platform/apple/macsmc-rtkit.c b/drivers/platform/apple/macsmc-rtkit.c new file mode 100644 index 000000000000..81560fb73e06 --- /dev/null +++ b/drivers/platform/apple/macsmc-rtkit.c @@ -0,0 +1,455 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC RTKit backend + * Copyright The Asahi Linux Contributors + */ + +#include <linux/bitfield.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/io.h> +#include <linux/ioport.h> +#include <linux/mfd/macsmc.h> +#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/soc/apple/rtkit.h> +#include <asm/unaligned.h> + +#define SMC_ENDPOINT 0x20 + +/* Guess */ +#define SMC_SHMEM_SIZE 0x1000 +#define SMC_MAX_SIZE 255 + +#define SMC_MSG_READ_KEY 0x10 +#define SMC_MSG_WRITE_KEY 0x11 +#define SMC_MSG_GET_KEY_BY_INDEX 0x12 +#define SMC_MSG_GET_KEY_INFO 0x13 +#define SMC_MSG_INITIALIZE 0x17 +#define SMC_MSG_NOTIFICATION 0x18 +#define SMC_MSG_RW_KEY 0x20 + +#define SMC_DATA GENMASK(63, 32) +#define SMC_WSIZE GENMASK(31, 24) +#define SMC_SIZE GENMASK(23, 16) +#define SMC_ID GENMASK(15, 12) +#define SMC_MSG GENMASK(7, 0) +#define SMC_RESULT SMC_MSG + +#define SMC_RECV_TIMEOUT 500 + +struct apple_smc_rtkit { + struct device *dev; + struct apple_smc *core; + struct apple_rtkit *rtk; + + struct completion init_done; + bool initialized; + bool alive; + + struct resource *sram; + void __iomem *sram_base; + struct apple_rtkit_shmem shmem; + + unsigned int msg_id; + + bool atomic_pending; + struct completion cmd_done; + u64 cmd_ret; +}; + +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + u64 msg; + u8 result; + + if (size > SMC_MAX_SIZE || size == 0) + return -EINVAL; + + if (!smc->alive) + return -EIO; + + memcpy_toio(smc->shmem.iomem, buf, size); + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, key)); + smc->atomic_pending = true; + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, true); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command (%d)\n", ret); + return ret; + } + + while (smc->atomic_pending) { + ret = apple_rtkit_poll(smc->rtk); + if (ret < 0) { + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); + return ret; + } + udelay(100); + } + + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + return -EIO; + } + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int apple_smc_cmd(struct apple_smc_rtkit *smc, u64 cmd, u64 arg, + u64 size, u64 wsize, u32 *ret_data) +{ + int ret; + u64 msg; + u8 result; + + if (!smc->alive) + return -EIO; + + reinit_completion(&smc->cmd_done); + + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, cmd) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_WSIZE, wsize) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, arg)); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, false); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command\n"); + return ret; + } + + do { + if (wait_for_completion_timeout(&smc->cmd_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + dev_err(smc->dev, "Command timed out (%llx)", msg); + return -ETIMEDOUT; + } + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) + break; + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + } while(1); + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + if (ret_data) + *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int _apple_smc_rtkit_read_key(struct apple_smc_rtkit *smc, smc_key key, + void *buf, size_t size, size_t wsize) +{ + int ret; + u32 rdata; + u64 cmd; + + if (size > SMC_MAX_SIZE || size == 0) + return -EINVAL; + + cmd = wsize ? SMC_MSG_RW_KEY : SMC_MSG_READ_KEY; + + ret = apple_smc_cmd(smc, cmd, key, size, wsize, &rdata); + if (ret < 0) + return ret; + + if (size <= 4) + memcpy(buf, &rdata, size); + else + memcpy_fromio(buf, smc->shmem.iomem, size); + + return ret; +} + +static int apple_smc_rtkit_read_key(void *cookie, smc_key key, void *buf, size_t size) +{ + return _apple_smc_rtkit_read_key(cookie, key, buf, size, 0); +} + +static int apple_smc_rtkit_write_key(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + + if (size > SMC_MAX_SIZE || size == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, buf, size); + return apple_smc_cmd(smc, SMC_MSG_WRITE_KEY, key, size, 0, NULL); +} + +static int apple_smc_rtkit_rw_key(void *cookie, smc_key key, + void *wbuf, size_t wsize, void *rbuf, size_t rsize) +{ + struct apple_smc_rtkit *smc = cookie; + + if (wsize > SMC_MAX_SIZE || wsize == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, wbuf, wsize); + return _apple_smc_rtkit_read_key(smc, key, rbuf, rsize, wsize); +} + +static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, smc_key *key) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); + + *key = swab32(*key); + return ret; +} + +static int apple_smc_rtkit_get_key_info(void *cookie, smc_key key, struct apple_smc_key_info *info) +{ + struct apple_smc_rtkit *smc = cookie; + u8 key_info[6]; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_INFO, key, 0, 0, NULL); + if (ret >= 0 && info) { + memcpy_fromio(key_info, smc->shmem.iomem, sizeof(key_info)); + info->size = key_info[0]; + info->type_code = get_unaligned_be32(&key_info[1]); + info->flags = key_info[5]; + } + return ret; +} + +static const struct apple_smc_backend_ops apple_smc_rtkit_be_ops = { + .read_key = apple_smc_rtkit_read_key, + .write_key = apple_smc_rtkit_write_key, + .write_key_atomic = apple_smc_rtkit_write_key_atomic, + .rw_key = apple_smc_rtkit_rw_key, + .get_key_by_index = apple_smc_rtkit_get_key_by_index, + .get_key_info = apple_smc_rtkit_get_key_info, +}; + +static void apple_smc_rtkit_crashed(void *cookie) +{ + struct apple_smc_rtkit *smc = cookie; + + dev_err(smc->dev, "SMC crashed! Your system will reboot in a few seconds...\n"); + smc->alive = false; +} + +static int apple_smc_rtkit_shmem_setup(void *cookie, struct apple_rtkit_shmem *bfr) +{ + struct apple_smc_rtkit *smc = cookie; + struct resource res = { + .start = bfr->iova, + .end = bfr->iova + bfr->size - 1, + .name = "rtkit_map", + .flags = smc->sram->flags, + }; + + if (!bfr->iova) { + dev_err(smc->dev, "RTKit wants a RAM buffer\n"); + return -EIO; + } + + if (res.end < res.start || !resource_contains(smc->sram, &res)) { + dev_err(smc->dev, + "RTKit buffer request outside SRAM region: %pR", &res); + return -EFAULT; + } + + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); + bfr->is_mapped = true; + + return 0; +} + +static void apple_smc_rtkit_shmem_destroy(void *cookie, struct apple_rtkit_shmem *bfr) +{ + // no-op +} + +static bool apple_smc_rtkit_recv_early(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return false; + } + + if (!smc->initialized) { + int ret; + + smc->shmem.iova = message; + smc->shmem.size = SMC_SHMEM_SIZE; + ret = apple_smc_rtkit_shmem_setup(smc, &smc->shmem); + if (ret < 0) + dev_err(smc->dev, "Failed to initialize shared memory\n"); + else + smc->alive = true; + smc->initialized = true; + complete(&smc->init_done); + } else if (FIELD_GET(SMC_MSG, message) == SMC_MSG_NOTIFICATION) { + /* Handle these in the RTKit worker thread */ + return false; + } else { + smc->cmd_ret = message; + if (smc->atomic_pending) { + smc->atomic_pending = false; + } else { + complete(&smc->cmd_done); + } + } + + return true; +} + +static void apple_smc_rtkit_recv(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return; + } + + if (FIELD_GET(SMC_MSG, message) != SMC_MSG_NOTIFICATION) { + dev_err(smc->dev, "Received unknown message from worker: 0x%llx\n", message); + return; + } + + apple_smc_event_received(smc->core, FIELD_GET(SMC_DATA, message)); +} + +static const struct apple_rtkit_ops apple_smc_rtkit_ops = { + .crashed = apple_smc_rtkit_crashed, + .recv_message = apple_smc_rtkit_recv, + .recv_message_early = apple_smc_rtkit_recv_early, + .shmem_setup = apple_smc_rtkit_shmem_setup, + .shmem_destroy = apple_smc_rtkit_shmem_destroy, +}; + +static int apple_smc_rtkit_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct apple_smc_rtkit *smc; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return -ENOMEM; + + smc->dev = dev; + + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); + if (!smc->sram) + return dev_err_probe(dev, EIO, + "No SRAM region"); + + smc->sram_base = devm_ioremap_resource(dev, smc->sram); + if (IS_ERR(smc->sram_base)) + return dev_err_probe(dev, PTR_ERR(smc->sram_base), + "Failed to map SRAM region"); + + smc->rtk = + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); + if (IS_ERR(smc->rtk)) + return dev_err_probe(dev, PTR_ERR(smc->rtk), + "Failed to intialize RTKit"); + + ret = apple_rtkit_wake(smc->rtk); + if (ret != 0) + return dev_err_probe(dev, ret, + "Failed to wake up SMC"); + + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); + if (ret != 0) { + dev_err(dev, "Failed to start endpoint"); + goto cleanup; + } + + init_completion(&smc->init_done); + init_completion(&smc->cmd_done); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); + if (ret < 0) { + ret = dev_err_probe(dev, ret, "Failed to send init message"); + goto cleanup; + } + + if (wait_for_completion_timeout(&smc->init_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + ret = -ETIMEDOUT; + dev_err(dev, "Timed out initializing SMC"); + goto cleanup; + } + + if (!smc->alive) { + ret = -EIO; + goto cleanup; + } + + smc->core = apple_smc_probe(dev, &apple_smc_rtkit_be_ops, smc); + if (IS_ERR(smc->core)) { + ret = PTR_ERR(smc->core); + goto cleanup; + } + + return 0; + +cleanup: + /* Try to shut down RTKit, if it's not completely wedged */ + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return ret; +} + +static int apple_smc_rtkit_remove(struct platform_device *pdev) +{ + struct apple_smc *core = platform_get_drvdata(pdev); + struct apple_smc_rtkit *smc = apple_smc_get_cookie(core); + + apple_smc_remove(core); + + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return 0; +} + +static const struct of_device_id apple_smc_rtkit_of_match[] = { + { .compatible = "apple,smc" }, + {}, +}; +MODULE_DEVICE_TABLE(of, apple_smc_rtkit_of_match); + +static struct platform_driver apple_smc_rtkit_driver = { + .driver = { + .name = "macsmc-rtkit", + .owner = THIS_MODULE, + .of_match_table = apple_smc_rtkit_of_match, + }, + .probe = apple_smc_rtkit_probe, + .remove = apple_smc_rtkit_remove, +}; +module_platform_driver(apple_smc_rtkit_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC RTKit backend driver"); -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 4/7] platform/apple: Add new Apple Mac SMC driver @ 2022-11-08 16:33 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements support for the SMC (System Management Controller) in Apple Macs. In contrast to the existing applesmc driver, it uses pluggable backends that allow it to support different SMC implementations, and uses the MFD subsystem to expose the core SMC functionality so that specific features (gpio, hwmon, battery, etc.) can be implemented by separate drivers in their respective downstream subsystems. The initial RTKit backend adds support for Apple Silicon Macs (M1 et al). We hope a backend for T2 Macs will be written in the future (since those are not supported by applesmc), and eventually an x86 backend would allow us to fully deprecate applesmc in favor of this driver. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/platform/Kconfig | 2 + drivers/platform/Makefile | 1 + drivers/platform/apple/Kconfig | 34 ++ drivers/platform/apple/Makefile | 7 + drivers/platform/apple/macsmc-rtkit.c | 455 ++++++++++++++++++++++++++ 5 files changed, 499 insertions(+) create mode 100644 drivers/platform/apple/Kconfig create mode 100644 drivers/platform/apple/Makefile create mode 100644 drivers/platform/apple/macsmc-rtkit.c diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index dbd327712205..31a361ecfc5e 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -15,4 +15,6 @@ source "drivers/platform/olpc/Kconfig" source "drivers/platform/surface/Kconfig" +source "drivers/platform/apple/Kconfig" + source "drivers/platform/x86/Kconfig" diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 41640172975a..d2baa4eb4f13 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_OLPC_EC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ obj-$(CONFIG_SURFACE_PLATFORMS) += surface/ +obj-$(CONFIG_APPLE_PLATFORMS) += apple/ diff --git a/drivers/platform/apple/Kconfig b/drivers/platform/apple/Kconfig new file mode 100644 index 000000000000..35963c348d05 --- /dev/null +++ b/drivers/platform/apple/Kconfig @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Apple Platform-Specific Drivers +# + +menuconfig APPLE_PLATFORMS + bool "Apple Mac Platform-Specific Device Drivers" + depends on ARCH_APPLE || X86 || COMPILE_TEST + default ARCH_APPLE + help + Say Y here to get to see options for platform-specific device drivers + for Apple devices. This option alone does not add any kernel code. + + If you say N, all options in this submenu will be skipped and disabled. + +if APPLE_PLATFORMS + +config APPLE_SMC_RTKIT + tristate "Apple SMC RTKit backend" + depends on ARCH_APPLE || (COMPILE_TEST && 64BIT) + depends on APPLE_RTKIT + default ARCH_APPLE + select MFD_MACSMC + help + Build support for the Apple System Management Controller found in + Apple Macs, communicated with via the RTKit backend. This is required + for Apple Silicon Macs. + + Say Y here if you have an Apple Silicon Mac. + + To compile this driver as a module, choose M here: the module will + be called macsmc-rtkit. + +endif diff --git a/drivers/platform/apple/Makefile b/drivers/platform/apple/Makefile new file mode 100644 index 000000000000..16cce9061ee8 --- /dev/null +++ b/drivers/platform/apple/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for linux/drivers/platform/apple +# Apple Platform-Specific Drivers +# + +obj-$(CONFIG_APPLE_SMC_RTKIT) += macsmc-rtkit.o diff --git a/drivers/platform/apple/macsmc-rtkit.c b/drivers/platform/apple/macsmc-rtkit.c new file mode 100644 index 000000000000..81560fb73e06 --- /dev/null +++ b/drivers/platform/apple/macsmc-rtkit.c @@ -0,0 +1,455 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC RTKit backend + * Copyright The Asahi Linux Contributors + */ + +#include <linux/bitfield.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/io.h> +#include <linux/ioport.h> +#include <linux/mfd/macsmc.h> +#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/soc/apple/rtkit.h> +#include <asm/unaligned.h> + +#define SMC_ENDPOINT 0x20 + +/* Guess */ +#define SMC_SHMEM_SIZE 0x1000 +#define SMC_MAX_SIZE 255 + +#define SMC_MSG_READ_KEY 0x10 +#define SMC_MSG_WRITE_KEY 0x11 +#define SMC_MSG_GET_KEY_BY_INDEX 0x12 +#define SMC_MSG_GET_KEY_INFO 0x13 +#define SMC_MSG_INITIALIZE 0x17 +#define SMC_MSG_NOTIFICATION 0x18 +#define SMC_MSG_RW_KEY 0x20 + +#define SMC_DATA GENMASK(63, 32) +#define SMC_WSIZE GENMASK(31, 24) +#define SMC_SIZE GENMASK(23, 16) +#define SMC_ID GENMASK(15, 12) +#define SMC_MSG GENMASK(7, 0) +#define SMC_RESULT SMC_MSG + +#define SMC_RECV_TIMEOUT 500 + +struct apple_smc_rtkit { + struct device *dev; + struct apple_smc *core; + struct apple_rtkit *rtk; + + struct completion init_done; + bool initialized; + bool alive; + + struct resource *sram; + void __iomem *sram_base; + struct apple_rtkit_shmem shmem; + + unsigned int msg_id; + + bool atomic_pending; + struct completion cmd_done; + u64 cmd_ret; +}; + +static int apple_smc_rtkit_write_key_atomic(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + u64 msg; + u8 result; + + if (size > SMC_MAX_SIZE || size == 0) + return -EINVAL; + + if (!smc->alive) + return -EIO; + + memcpy_toio(smc->shmem.iomem, buf, size); + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, key)); + smc->atomic_pending = true; + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, true); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command (%d)\n", ret); + return ret; + } + + while (smc->atomic_pending) { + ret = apple_rtkit_poll(smc->rtk); + if (ret < 0) { + dev_err(smc->dev, "RTKit poll failed (%llx)", msg); + return ret; + } + udelay(100); + } + + if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) { + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + return -EIO; + } + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int apple_smc_cmd(struct apple_smc_rtkit *smc, u64 cmd, u64 arg, + u64 size, u64 wsize, u32 *ret_data) +{ + int ret; + u64 msg; + u8 result; + + if (!smc->alive) + return -EIO; + + reinit_completion(&smc->cmd_done); + + smc->msg_id = (smc->msg_id + 1) & 0xf; + msg = (FIELD_PREP(SMC_MSG, cmd) | + FIELD_PREP(SMC_SIZE, size) | + FIELD_PREP(SMC_WSIZE, wsize) | + FIELD_PREP(SMC_ID, smc->msg_id) | + FIELD_PREP(SMC_DATA, arg)); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, false); + if (ret < 0) { + dev_err(smc->dev, "Failed to send command\n"); + return ret; + } + + do { + if (wait_for_completion_timeout(&smc->cmd_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + dev_err(smc->dev, "Command timed out (%llx)", msg); + return -ETIMEDOUT; + } + if (FIELD_GET(SMC_ID, smc->cmd_ret) == smc->msg_id) + break; + dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n", + smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret)); + } while(1); + + result = FIELD_GET(SMC_RESULT, smc->cmd_ret); + if (result != 0) + return -result; + + if (ret_data) + *ret_data = FIELD_GET(SMC_DATA, smc->cmd_ret); + + return FIELD_GET(SMC_SIZE, smc->cmd_ret); +} + +static int _apple_smc_rtkit_read_key(struct apple_smc_rtkit *smc, smc_key key, + void *buf, size_t size, size_t wsize) +{ + int ret; + u32 rdata; + u64 cmd; + + if (size > SMC_MAX_SIZE || size == 0) + return -EINVAL; + + cmd = wsize ? SMC_MSG_RW_KEY : SMC_MSG_READ_KEY; + + ret = apple_smc_cmd(smc, cmd, key, size, wsize, &rdata); + if (ret < 0) + return ret; + + if (size <= 4) + memcpy(buf, &rdata, size); + else + memcpy_fromio(buf, smc->shmem.iomem, size); + + return ret; +} + +static int apple_smc_rtkit_read_key(void *cookie, smc_key key, void *buf, size_t size) +{ + return _apple_smc_rtkit_read_key(cookie, key, buf, size, 0); +} + +static int apple_smc_rtkit_write_key(void *cookie, smc_key key, void *buf, size_t size) +{ + struct apple_smc_rtkit *smc = cookie; + + if (size > SMC_MAX_SIZE || size == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, buf, size); + return apple_smc_cmd(smc, SMC_MSG_WRITE_KEY, key, size, 0, NULL); +} + +static int apple_smc_rtkit_rw_key(void *cookie, smc_key key, + void *wbuf, size_t wsize, void *rbuf, size_t rsize) +{ + struct apple_smc_rtkit *smc = cookie; + + if (wsize > SMC_MAX_SIZE || wsize == 0) + return -EINVAL; + + memcpy_toio(smc->shmem.iomem, wbuf, wsize); + return _apple_smc_rtkit_read_key(smc, key, rbuf, rsize, wsize); +} + +static int apple_smc_rtkit_get_key_by_index(void *cookie, int index, smc_key *key) +{ + struct apple_smc_rtkit *smc = cookie; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_BY_INDEX, index, 0, 0, key); + + *key = swab32(*key); + return ret; +} + +static int apple_smc_rtkit_get_key_info(void *cookie, smc_key key, struct apple_smc_key_info *info) +{ + struct apple_smc_rtkit *smc = cookie; + u8 key_info[6]; + int ret; + + ret = apple_smc_cmd(smc, SMC_MSG_GET_KEY_INFO, key, 0, 0, NULL); + if (ret >= 0 && info) { + memcpy_fromio(key_info, smc->shmem.iomem, sizeof(key_info)); + info->size = key_info[0]; + info->type_code = get_unaligned_be32(&key_info[1]); + info->flags = key_info[5]; + } + return ret; +} + +static const struct apple_smc_backend_ops apple_smc_rtkit_be_ops = { + .read_key = apple_smc_rtkit_read_key, + .write_key = apple_smc_rtkit_write_key, + .write_key_atomic = apple_smc_rtkit_write_key_atomic, + .rw_key = apple_smc_rtkit_rw_key, + .get_key_by_index = apple_smc_rtkit_get_key_by_index, + .get_key_info = apple_smc_rtkit_get_key_info, +}; + +static void apple_smc_rtkit_crashed(void *cookie) +{ + struct apple_smc_rtkit *smc = cookie; + + dev_err(smc->dev, "SMC crashed! Your system will reboot in a few seconds...\n"); + smc->alive = false; +} + +static int apple_smc_rtkit_shmem_setup(void *cookie, struct apple_rtkit_shmem *bfr) +{ + struct apple_smc_rtkit *smc = cookie; + struct resource res = { + .start = bfr->iova, + .end = bfr->iova + bfr->size - 1, + .name = "rtkit_map", + .flags = smc->sram->flags, + }; + + if (!bfr->iova) { + dev_err(smc->dev, "RTKit wants a RAM buffer\n"); + return -EIO; + } + + if (res.end < res.start || !resource_contains(smc->sram, &res)) { + dev_err(smc->dev, + "RTKit buffer request outside SRAM region: %pR", &res); + return -EFAULT; + } + + bfr->iomem = smc->sram_base + (res.start - smc->sram->start); + bfr->is_mapped = true; + + return 0; +} + +static void apple_smc_rtkit_shmem_destroy(void *cookie, struct apple_rtkit_shmem *bfr) +{ + // no-op +} + +static bool apple_smc_rtkit_recv_early(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return false; + } + + if (!smc->initialized) { + int ret; + + smc->shmem.iova = message; + smc->shmem.size = SMC_SHMEM_SIZE; + ret = apple_smc_rtkit_shmem_setup(smc, &smc->shmem); + if (ret < 0) + dev_err(smc->dev, "Failed to initialize shared memory\n"); + else + smc->alive = true; + smc->initialized = true; + complete(&smc->init_done); + } else if (FIELD_GET(SMC_MSG, message) == SMC_MSG_NOTIFICATION) { + /* Handle these in the RTKit worker thread */ + return false; + } else { + smc->cmd_ret = message; + if (smc->atomic_pending) { + smc->atomic_pending = false; + } else { + complete(&smc->cmd_done); + } + } + + return true; +} + +static void apple_smc_rtkit_recv(void *cookie, u8 endpoint, u64 message) +{ + struct apple_smc_rtkit *smc = cookie; + + if (endpoint != SMC_ENDPOINT) { + dev_err(smc->dev, "Received message for unknown endpoint 0x%x\n", endpoint); + return; + } + + if (FIELD_GET(SMC_MSG, message) != SMC_MSG_NOTIFICATION) { + dev_err(smc->dev, "Received unknown message from worker: 0x%llx\n", message); + return; + } + + apple_smc_event_received(smc->core, FIELD_GET(SMC_DATA, message)); +} + +static const struct apple_rtkit_ops apple_smc_rtkit_ops = { + .crashed = apple_smc_rtkit_crashed, + .recv_message = apple_smc_rtkit_recv, + .recv_message_early = apple_smc_rtkit_recv_early, + .shmem_setup = apple_smc_rtkit_shmem_setup, + .shmem_destroy = apple_smc_rtkit_shmem_destroy, +}; + +static int apple_smc_rtkit_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct apple_smc_rtkit *smc; + int ret; + + smc = devm_kzalloc(dev, sizeof(*smc), GFP_KERNEL); + if (!smc) + return -ENOMEM; + + smc->dev = dev; + + smc->sram = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram"); + if (!smc->sram) + return dev_err_probe(dev, EIO, + "No SRAM region"); + + smc->sram_base = devm_ioremap_resource(dev, smc->sram); + if (IS_ERR(smc->sram_base)) + return dev_err_probe(dev, PTR_ERR(smc->sram_base), + "Failed to map SRAM region"); + + smc->rtk = + devm_apple_rtkit_init(dev, smc, NULL, 0, &apple_smc_rtkit_ops); + if (IS_ERR(smc->rtk)) + return dev_err_probe(dev, PTR_ERR(smc->rtk), + "Failed to intialize RTKit"); + + ret = apple_rtkit_wake(smc->rtk); + if (ret != 0) + return dev_err_probe(dev, ret, + "Failed to wake up SMC"); + + ret = apple_rtkit_start_ep(smc->rtk, SMC_ENDPOINT); + if (ret != 0) { + dev_err(dev, "Failed to start endpoint"); + goto cleanup; + } + + init_completion(&smc->init_done); + init_completion(&smc->cmd_done); + + ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, + FIELD_PREP(SMC_MSG, SMC_MSG_INITIALIZE), NULL, false); + if (ret < 0) { + ret = dev_err_probe(dev, ret, "Failed to send init message"); + goto cleanup; + } + + if (wait_for_completion_timeout(&smc->init_done, + msecs_to_jiffies(SMC_RECV_TIMEOUT)) == 0) { + ret = -ETIMEDOUT; + dev_err(dev, "Timed out initializing SMC"); + goto cleanup; + } + + if (!smc->alive) { + ret = -EIO; + goto cleanup; + } + + smc->core = apple_smc_probe(dev, &apple_smc_rtkit_be_ops, smc); + if (IS_ERR(smc->core)) { + ret = PTR_ERR(smc->core); + goto cleanup; + } + + return 0; + +cleanup: + /* Try to shut down RTKit, if it's not completely wedged */ + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return ret; +} + +static int apple_smc_rtkit_remove(struct platform_device *pdev) +{ + struct apple_smc *core = platform_get_drvdata(pdev); + struct apple_smc_rtkit *smc = apple_smc_get_cookie(core); + + apple_smc_remove(core); + + if (apple_rtkit_is_running(smc->rtk)) + apple_rtkit_quiesce(smc->rtk); + + return 0; +} + +static const struct of_device_id apple_smc_rtkit_of_match[] = { + { .compatible = "apple,smc" }, + {}, +}; +MODULE_DEVICE_TABLE(of, apple_smc_rtkit_of_match); + +static struct platform_driver apple_smc_rtkit_driver = { + .driver = { + .name = "macsmc-rtkit", + .owner = THIS_MODULE, + .of_match_table = apple_smc_rtkit_of_match, + }, + .probe = apple_smc_rtkit_probe, + .remove = apple_smc_rtkit_remove, +}; +module_platform_driver(apple_smc_rtkit_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC RTKit backend driver"); -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 5/7] arm64: dts: apple: Add SMC node to t8103 devicetrees 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- arch/arm64/boot/dts/apple/t8103.dtsi | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi index 51a63b29d404..e44ba4e541f6 100644 --- a/arch/arm64/boot/dts/apple/t8103.dtsi +++ b/arch/arm64/boot/dts/apple/t8103.dtsi @@ -336,6 +336,33 @@ wdt: watchdog@23d2b0000 { interrupts = <AIC_IRQ 338 IRQ_TYPE_LEVEL_HIGH>; }; + smc: smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + + smc_gpio: gpio { + compatible = "apple,smc-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; + }; + + smc_mbox: mbox@23e408000 { + compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox-v4"; + reg = <0x2 0x3e408000 0x0 0x4000>; + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 400 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 401 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 402 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 403 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "send-empty", "send-not-empty", + "recv-empty", "recv-not-empty"; + #mbox-cells = <0>; + }; + pinctrl_smc: pinctrl@23e820000 { compatible = "apple,t8103-pinctrl", "apple,pinctrl"; reg = <0x2 0x3e820000 0x0 0x4000>; -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 5/7] arm64: dts: apple: Add SMC node to t8103 devicetrees @ 2022-11-08 16:33 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- arch/arm64/boot/dts/apple/t8103.dtsi | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi index 51a63b29d404..e44ba4e541f6 100644 --- a/arch/arm64/boot/dts/apple/t8103.dtsi +++ b/arch/arm64/boot/dts/apple/t8103.dtsi @@ -336,6 +336,33 @@ wdt: watchdog@23d2b0000 { interrupts = <AIC_IRQ 338 IRQ_TYPE_LEVEL_HIGH>; }; + smc: smc@23e400000 { + compatible = "apple,t8103-smc", "apple,smc"; + reg = <0x2 0x3e400000 0x0 0x4000>, + <0x2 0x3fe00000 0x0 0x100000>; + reg-names = "smc", "sram"; + mboxes = <&smc_mbox>; + + smc_gpio: gpio { + compatible = "apple,smc-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; + }; + + smc_mbox: mbox@23e408000 { + compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox-v4"; + reg = <0x2 0x3e408000 0x0 0x4000>; + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 400 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 401 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 402 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 403 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "send-empty", "send-not-empty", + "recv-empty", "recv-not-empty"; + #mbox-cells = <0>; + }; + pinctrl_smc: pinctrl@23e820000 { compatible = "apple,t8103-pinctrl", "apple,pinctrl"; reg = <0x2 0x3e820000 0x0 0x4000>; -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter Add the DT binding for the Apple Mac System Management Controller GPIOs. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml new file mode 100644 index 000000000000..1a415b78760b --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller GPIO + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller GPIO block. + +properties: + compatible: + const: apple,smc-gpio + + gpio-controller: true + + '#gpio-cells': + const: 2 + +required: + - compatible + - gpio-controller + - '#gpio-cells' + +additionalProperties: false + +examples: + - | + gpio { + compatible = "apple,smc-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-08 16:33 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter Add the DT binding for the Apple Mac System Management Controller GPIOs. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml new file mode 100644 index 000000000000..1a415b78760b --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mac System Management Controller GPIO + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: + Apple Mac System Management Controller GPIO block. + +properties: + compatible: + const: apple,smc-gpio + + gpio-controller: true + + '#gpio-cells': + const: 2 + +required: + - compatible + - gpio-controller + - '#gpio-cells' + +additionalProperties: false + +examples: + - | + gpio { + compatible = "apple,smc-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-08 16:33 ` Russell King (Oracle) @ 2022-11-08 20:56 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-08 20:56 UTC (permalink / raw) To: Russell King (Oracle), Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 17:33, Russell King (Oracle) wrote: > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > new file mode 100644 > index 000000000000..1a415b78760b > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > @@ -0,0 +1,37 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# Does not look like you tested the bindings. Please run `make dt_binding_check` (see Documentation/devicetree/bindings/writing-schema.rst for instructions). > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller GPIO > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller GPIO block. > + Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-08 20:56 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-08 20:56 UTC (permalink / raw) To: Russell King (Oracle), Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 17:33, Russell King (Oracle) wrote: > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > new file mode 100644 > index 000000000000..1a415b78760b > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > @@ -0,0 +1,37 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# Does not look like you tested the bindings. Please run `make dt_binding_check` (see Documentation/devicetree/bindings/writing-schema.rst for instructions). > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple Mac System Management Controller GPIO > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: > + Apple Mac System Management Controller GPIO block. > + Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-08 20:56 ` Krzysztof Kozlowski @ 2022-11-08 22:09 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 22:09 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > > 1 file changed, 37 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > > > diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > new file mode 100644 > > index 000000000000..1a415b78760b > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > @@ -0,0 +1,37 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# > > Does not look like you tested the bindings. Please run `make > dt_binding_check` (see > Documentation/devicetree/bindings/writing-schema.rst for instructions). Oh ffs. DT bindings are utterly impossible to get correct. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-08 22:09 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-08 22:09 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: > On 08/11/2022 17:33, Russell King (Oracle) wrote: > > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > > 1 file changed, 37 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > > > diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > new file mode 100644 > > index 000000000000..1a415b78760b > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > > @@ -0,0 +1,37 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# > > Does not look like you tested the bindings. Please run `make > dt_binding_check` (see > Documentation/devicetree/bindings/writing-schema.rst for instructions). Oh ffs. DT bindings are utterly impossible to get correct. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-08 22:09 ` Russell King (Oracle) @ 2022-11-09 7:31 ` Hector Martin -1 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-11-09 7:31 UTC (permalink / raw) To: Russell King (Oracle), Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 09/11/2022 07.09, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>> Add the DT binding for the Apple Mac System Management Controller GPIOs. >>> >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>> --- >>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> new file mode 100644 >>> index 000000000000..1a415b78760b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> @@ -0,0 +1,37 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# >> >> Does not look like you tested the bindings. Please run `make >> dt_binding_check` (see >> Documentation/devicetree/bindings/writing-schema.rst for instructions). > > Oh ffs. DT bindings are utterly impossible to get correct. I'd be happy to wrap the bindings up in another cycle & take them via asahi-soc, if you want. That will also allow us to add the nodes to the t6000 DTs which are on that tree for this cycle, and unblock merging the driver bits of this series. Bindings updates are not a hard dependency for drivers, only for the DTs themselves. That is: 1-2,4 via mfd tree (if Lee agrees to merging the RTKit driver platform bits that way) 3,5-6 via asahi-soc 7 via GPIO (I think) - Hector ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-09 7:31 ` Hector Martin 0 siblings, 0 replies; 342+ messages in thread From: Hector Martin @ 2022-11-09 7:31 UTC (permalink / raw) To: Russell King (Oracle), Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 09/11/2022 07.09, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>> Add the DT binding for the Apple Mac System Management Controller GPIOs. >>> >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>> --- >>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> new file mode 100644 >>> index 000000000000..1a415b78760b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> @@ -0,0 +1,37 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# >> >> Does not look like you tested the bindings. Please run `make >> dt_binding_check` (see >> Documentation/devicetree/bindings/writing-schema.rst for instructions). > > Oh ffs. DT bindings are utterly impossible to get correct. I'd be happy to wrap the bindings up in another cycle & take them via asahi-soc, if you want. That will also allow us to add the nodes to the t6000 DTs which are on that tree for this cycle, and unblock merging the driver bits of this series. Bindings updates are not a hard dependency for drivers, only for the DTs themselves. That is: 1-2,4 via mfd tree (if Lee agrees to merging the RTKit driver platform bits that way) 3,5-6 via asahi-soc 7 via GPIO (I think) - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-08 22:09 ` Russell King (Oracle) @ 2022-11-09 8:36 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-09 8:36 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 23:09, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>> Add the DT binding for the Apple Mac System Management Controller GPIOs. >>> >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>> --- >>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> new file mode 100644 >>> index 000000000000..1a415b78760b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> @@ -0,0 +1,37 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# >> >> Does not look like you tested the bindings. Please run `make >> dt_binding_check` (see >> Documentation/devicetree/bindings/writing-schema.rst for instructions). > > Oh ffs. DT bindings are utterly impossible to get correct. Why? You write, you test and then you see the error. Srsly... Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-09 8:36 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-09 8:36 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 08/11/2022 23:09, Russell King (Oracle) wrote: > On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>> Add the DT binding for the Apple Mac System Management Controller GPIOs. >>> >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>> --- >>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> new file mode 100644 >>> index 000000000000..1a415b78760b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>> @@ -0,0 +1,37 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# >> >> Does not look like you tested the bindings. Please run `make >> dt_binding_check` (see >> Documentation/devicetree/bindings/writing-schema.rst for instructions). > > Oh ffs. DT bindings are utterly impossible to get correct. Why? You write, you test and then you see the error. Srsly... Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-09 8:36 ` Krzysztof Kozlowski @ 2022-11-09 9:12 ` Russell King (Oracle) -1 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-09 9:12 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Wed, Nov 09, 2022 at 09:36:12AM +0100, Krzysztof Kozlowski wrote: > On 08/11/2022 23:09, Russell King (Oracle) wrote: > > On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: > >> On 08/11/2022 17:33, Russell King (Oracle) wrote: > >>> Add the DT binding for the Apple Mac System Management Controller GPIOs. > >>> > >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >>> --- > >>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > >>> 1 file changed, 37 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > >>> > >>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > >>> new file mode 100644 > >>> index 000000000000..1a415b78760b > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > >>> @@ -0,0 +1,37 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# > >> > >> Does not look like you tested the bindings. Please run `make > >> dt_binding_check` (see > >> Documentation/devicetree/bindings/writing-schema.rst for instructions). > > > > Oh ffs. DT bindings are utterly impossible to get correct. > > Why? You write, you test and then you see the error. Srsly... It's utterly impossible for me to remember the dependencies. It's utterly impossible for me to remember the make incantation to test this bloody things - especially as I need to limit it otherwise it takes a very long time to test. The whole bloody thing is just too sodding difficult. I'm not going to bother with this patch set any more. Too frustrated with this piecemeal approach and the crappy slow tooling and the idiotic incomprehensible error messages it spits out. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-09 9:12 ` Russell King (Oracle) 0 siblings, 0 replies; 342+ messages in thread From: Russell King (Oracle) @ 2022-11-09 9:12 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On Wed, Nov 09, 2022 at 09:36:12AM +0100, Krzysztof Kozlowski wrote: > On 08/11/2022 23:09, Russell King (Oracle) wrote: > > On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: > >> On 08/11/2022 17:33, Russell King (Oracle) wrote: > >>> Add the DT binding for the Apple Mac System Management Controller GPIOs. > >>> > >>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > >>> --- > >>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > >>> 1 file changed, 37 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > >>> > >>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > >>> new file mode 100644 > >>> index 000000000000..1a415b78760b > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > >>> @@ -0,0 +1,37 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# > >> > >> Does not look like you tested the bindings. Please run `make > >> dt_binding_check` (see > >> Documentation/devicetree/bindings/writing-schema.rst for instructions). > > > > Oh ffs. DT bindings are utterly impossible to get correct. > > Why? You write, you test and then you see the error. Srsly... It's utterly impossible for me to remember the dependencies. It's utterly impossible for me to remember the make incantation to test this bloody things - especially as I need to limit it otherwise it takes a very long time to test. The whole bloody thing is just too sodding difficult. I'm not going to bother with this patch set any more. Too frustrated with this piecemeal approach and the crappy slow tooling and the idiotic incomprehensible error messages it spits out. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-09 9:12 ` Russell King (Oracle) @ 2022-11-09 9:19 ` Krzysztof Kozlowski -1 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-09 9:19 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 09/11/2022 10:12, Russell King (Oracle) wrote: > On Wed, Nov 09, 2022 at 09:36:12AM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 23:09, Russell King (Oracle) wrote: >>> On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: >>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>>> Add the DT binding for the Apple Mac System Management Controller GPIOs. >>>>> >>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>>> --- >>>>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ >>>>> 1 file changed, 37 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>>>> new file mode 100644 >>>>> index 000000000000..1a415b78760b >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>>>> @@ -0,0 +1,37 @@ >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# >>>> >>>> Does not look like you tested the bindings. Please run `make >>>> dt_binding_check` (see >>>> Documentation/devicetree/bindings/writing-schema.rst for instructions). >>> >>> Oh ffs. DT bindings are utterly impossible to get correct. >> >> Why? You write, you test and then you see the error. Srsly... > > It's utterly impossible for me to remember the dependencies. It's > utterly impossible for me to remember the make incantation to test > this bloody things - especially as I need to limit it otherwise it > takes a very long time to test. Then this is where I can help - you can test just one, specific binding or few of them: make dt_binding_check DT_SCHEMA_FILES=apple,smc-gpio.yaml make dt_binding_check DT_SCHEMA_FILES=apple,smc So before you format patches, just do `git rebase -i HEAD~7`, change to re-word or edit and go one-by-one testing your bisectability. The same we are always doing for regular kernel builds when having a big patchset, right? Each commit must compile, not just the last one in patchset. Or push each of the commit to a service which can do it for you. For example, for kernel building (not yet ready for DT binding check) I am using something like: https://github.com/krzk/tools/tree/master/git-build-kernel > > The whole bloody thing is just too sodding difficult. > > I'm not going to bother with this patch set any more. Too frustrated > with this piecemeal approach and the crappy slow tooling and the > idiotic incomprehensible error messages it spits out. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-09 9:19 ` Krzysztof Kozlowski 0 siblings, 0 replies; 342+ messages in thread From: Krzysztof Kozlowski @ 2022-11-09 9:19 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones, Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter On 09/11/2022 10:12, Russell King (Oracle) wrote: > On Wed, Nov 09, 2022 at 09:36:12AM +0100, Krzysztof Kozlowski wrote: >> On 08/11/2022 23:09, Russell King (Oracle) wrote: >>> On Tue, Nov 08, 2022 at 09:56:40PM +0100, Krzysztof Kozlowski wrote: >>>> On 08/11/2022 17:33, Russell King (Oracle) wrote: >>>>> Add the DT binding for the Apple Mac System Management Controller GPIOs. >>>>> >>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> >>>>> --- >>>>> .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ >>>>> 1 file changed, 37 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>>>> new file mode 100644 >>>>> index 000000000000..1a415b78760b >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml >>>>> @@ -0,0 +1,37 @@ >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/gpio/gpio-macsmc.yaml# >>>> >>>> Does not look like you tested the bindings. Please run `make >>>> dt_binding_check` (see >>>> Documentation/devicetree/bindings/writing-schema.rst for instructions). >>> >>> Oh ffs. DT bindings are utterly impossible to get correct. >> >> Why? You write, you test and then you see the error. Srsly... > > It's utterly impossible for me to remember the dependencies. It's > utterly impossible for me to remember the make incantation to test > this bloody things - especially as I need to limit it otherwise it > takes a very long time to test. Then this is where I can help - you can test just one, specific binding or few of them: make dt_binding_check DT_SCHEMA_FILES=apple,smc-gpio.yaml make dt_binding_check DT_SCHEMA_FILES=apple,smc So before you format patches, just do `git rebase -i HEAD~7`, change to re-word or edit and go one-by-one testing your bisectability. The same we are always doing for regular kernel builds when having a big patchset, right? Each commit must compile, not just the last one in patchset. Or push each of the commit to a service which can do it for you. For example, for kernel building (not yet ready for DT binding check) I am using something like: https://github.com/krzk/tools/tree/master/git-build-kernel > > The whole bloody thing is just too sodding difficult. > > I'm not going to bother with this patch set any more. Too frustrated > with this piecemeal approach and the crappy slow tooling and the > idiotic incomprehensible error messages it spits out. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC 2022-11-08 16:33 ` Russell King (Oracle) @ 2022-11-08 22:30 ` Rob Herring -1 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-11-08 22:30 UTC (permalink / raw) To: Russell King (Oracle) Cc: Rasmus Villemoes, asahi, Krzysztof Kozlowski, Bartosz Golaszewski, Steven Rostedt, Alyssa Rosenzweig, Petr Mladek, Andy Shevchenko, Rob Herring, Lee Jones, Sven Peter, Hector Martin, linux-arm-kernel, devicetree, Jonathan Corbet, linux-gpio, Sergey Senozhatsky, linux-doc, Linus Walleij On Tue, 08 Nov 2022 16:33:42 +0000, Russell King (Oracle) wrote: > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/gpio/apple,smc-gpio.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ^ permalink raw reply [flat|nested] 342+ messages in thread
* Re: [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC @ 2022-11-08 22:30 ` Rob Herring 0 siblings, 0 replies; 342+ messages in thread From: Rob Herring @ 2022-11-08 22:30 UTC (permalink / raw) To: Russell King (Oracle) Cc: Rasmus Villemoes, asahi, Krzysztof Kozlowski, Bartosz Golaszewski, Steven Rostedt, Alyssa Rosenzweig, Petr Mladek, Andy Shevchenko, Rob Herring, Lee Jones, Sven Peter, Hector Martin, linux-arm-kernel, devicetree, Jonathan Corbet, linux-gpio, Sergey Senozhatsky, linux-doc, Linus Walleij On Tue, 08 Nov 2022 16:33:42 +0000, Russell King (Oracle) wrote: > Add the DT binding for the Apple Mac System Management Controller GPIOs. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > .../bindings/gpio/apple,smc-gpio.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/gpio/apple,smc-gpio.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 342+ messages in thread
* [PATCH v3 7/7] gpio: Add new gpio-macsmc driver for Apple Macs 2022-11-08 16:32 ` Russell King (Oracle) @ 2022-11-08 16:33 ` Russell King -1 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements the GPIO service on top of the SMC framework on Apple Mac machines. In particular, these are the GPIOs present in the PMU IC which are used to control power to certain on-board devices. Although the underlying hardware supports various pin config settings (input/output, open drain, etc.), this driver does not implement that functionality and leaves it up to the firmware to configure things properly. We also don't yet support interrupts/events. This is sufficient for device power control, which is the only thing we need to support at this point. More features will be implemented when needed. To our knowledge, only Apple Silicon Macs implement this SMC feature. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/gpio/Kconfig | 11 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 245 +++++++++++++++++++++++++++++++++++++ 3 files changed, 257 insertions(+) create mode 100644 drivers/gpio/gpio-macsmc.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index a01af1180616..08138322010a 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -1283,6 +1283,17 @@ config GPIO_LP87565 This driver can also be built as a module. If so, the module will be called gpio-lp87565. +config GPIO_MACSMC + tristate "Apple Mac SMC GPIO" + depends on MFD_MACSMC + default ARCH_APPLE + help + Support for GPIOs controlled by the SMC microcontroller on Apple Mac + systems. + + This driver can also be built as a module. If so, the module will be + called gpio-macsmc. + config GPIO_MADERA tristate "Cirrus Logic Madera class codecs" depends on PINCTRL_MADERA diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 29e3beb6548c..467833cc9a9d 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o +obj-$(CONFIG_GPIO_MACSMC) += gpio-macsmc.o obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o diff --git a/drivers/gpio/gpio-macsmc.c b/drivers/gpio/gpio-macsmc.c new file mode 100644 index 000000000000..24ec98ad18f7 --- /dev/null +++ b/drivers/gpio/gpio-macsmc.c @@ -0,0 +1,245 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC GPIO driver + * Copyright The Asahi Linux Contributors + * + * This driver implements basic SMC PMU GPIO support that can read inputs + * and write outputs. Mode changes and IRQ config are not yet implemented. + */ + +#include <linux/bitmap.h> +#include <linux/device.h> +#include <linux/gpio/driver.h> +#include <linux/mfd/core.h> +#include <linux/mfd/macsmc.h> + +#define MAX_GPIO 64 + +/* + * Commands 0-6 are, presumably, the intended API. + * Command 0xff lets you get/set the pin configuration in detail directly, + * but the bit meanings seem not to be stable between devices/PMU hardware + * versions. + * + * We're going to try to make do with the low commands for now. + * We don't implement pin mode changes at this time. + */ + +#define CMD_ACTION (0 << 24) +#define CMD_OUTPUT (1 << 24) +#define CMD_INPUT (2 << 24) +#define CMD_PINMODE (3 << 24) +#define CMD_IRQ_ENABLE (4 << 24) +#define CMD_IRQ_ACK (5 << 24) +#define CMD_IRQ_MODE (6 << 24) +#define CMD_CONFIG (0xff << 24) + +#define MODE_INPUT 0 +#define MODE_OUTPUT 1 +#define MODE_VALUE_0 0 +#define MODE_VALUE_1 2 + +#define IRQ_MODE_HIGH 0 +#define IRQ_MODE_LOW 1 +#define IRQ_MODE_RISING 2 +#define IRQ_MODE_FALLING 3 +#define IRQ_MODE_BOTH 4 + +#define CONFIG_MASK GENMASK(23, 16) +#define CONFIG_VAL GENMASK(7, 0) + +#define CONFIG_OUTMODE GENMASK(7, 6) +#define CONFIG_IRQMODE GENMASK(5, 3) +#define CONFIG_PULLDOWN BIT(2) +#define CONFIG_PULLUP BIT(1) +#define CONFIG_OUTVAL BIT(0) + +/* + * Output modes seem to differ depending on the PMU in use... ? + * j274 / M1 (Sera PMU): + * 0 = input + * 1 = output + * 2 = open drain + * 3 = disable + * j314 / M1Pro (Maverick PMU): + * 0 = input + * 1 = open drain + * 2 = output + * 3 = ? + */ + +struct macsmc_gpio { + struct device *dev; + struct apple_smc *smc; + struct gpio_chip gc; + + int first_index; +}; + +static int macsmc_gpio_nr(smc_key key) +{ + int low = hex_to_bin(key & 0xff); + int high = hex_to_bin((key >> 8) & 0xff); + + if (low < 0 || high < 0) + return -1; + + return low | (high << 4); +} + +static int macsmc_gpio_key(unsigned int offset) +{ + return _SMC_KEY("gP\0\0") | hex_asc_hi(offset) << 8 | hex_asc_lo(offset); +} + +static int macsmc_gpio_get_direction(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 val; + int ret; + + /* First try reading the explicit pin mode register */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); + if (!ret) + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; + + /* + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. + * Fall back to reading IRQ mode, which will only succeed for inputs. + */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); + return ret ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; +} + +static int macsmc_gpio_get(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 cmd, val; + int ret; + + ret = macsmc_gpio_get_direction(gc, offset); + if (ret < 0) + return ret; + + if (ret == GPIO_LINE_DIRECTION_OUT) + cmd = CMD_OUTPUT; + else + cmd = CMD_INPUT; + + ret = apple_smc_rw_u32(smcgp->smc, key, cmd, &val); + if (ret < 0) + return ret; + + return val ? 1 : 0; +} + +static void macsmc_gpio_set(struct gpio_chip *gc, unsigned int offset, int value) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + int ret; + + value |= CMD_OUTPUT; + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); + if (ret < 0) + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); +} + +static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, + unsigned long *valid_mask, unsigned int ngpios) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + int count; + int i; + + count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; + if (count > MAX_GPIO) + count = MAX_GPIO; + + bitmap_zero(valid_mask, ngpios); + + for (i = 0; i < count; i++) { + int ret, gpio_nr; + smc_key key; + + ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); + if (ret < 0) + return ret; + + if (key > SMC_KEY(gPff)) + break; + + gpio_nr = macsmc_gpio_nr(key); + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); + continue; + } + + set_bit(gpio_nr, valid_mask); + } + + return 0; +} + +static int macsmc_gpio_probe(struct platform_device *pdev) +{ + struct macsmc_gpio *smcgp; + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent); + smc_key key; + int ret; + + smcgp = devm_kzalloc(&pdev->dev, sizeof(*smcgp), GFP_KERNEL); + if (!smcgp) + return -ENOMEM; + + smcgp->dev = &pdev->dev; + smcgp->smc = smc; + smcgp->first_index = apple_smc_find_first_key_index(smc, SMC_KEY(gP00)); + + if (smcgp->first_index >= apple_smc_get_key_count(smc)) + return -ENODEV; + + ret = apple_smc_get_key_by_index(smc, smcgp->first_index, &key); + if (ret < 0) + return ret; + + if (key > macsmc_gpio_key(MAX_GPIO - 1)) + return -ENODEV; + + dev_info(smcgp->dev, "First GPIO key: %p4ch\n", &key); + + smcgp->gc.label = "macsmc-pmu-gpio"; + smcgp->gc.owner = THIS_MODULE; + smcgp->gc.get = macsmc_gpio_get; + smcgp->gc.set = macsmc_gpio_set; + smcgp->gc.get_direction = macsmc_gpio_get_direction; + smcgp->gc.init_valid_mask = macsmc_gpio_init_valid_mask; + smcgp->gc.can_sleep = true; + smcgp->gc.ngpio = MAX_GPIO; + smcgp->gc.base = -1; + smcgp->gc.parent = &pdev->dev; + + return devm_gpiochip_add_data(&pdev->dev, &smcgp->gc, smcgp); +} + +static const struct of_device_id macsmc_gpio_of_table[] = { + { .compatible = "apple,smc-gpio", }, + {} +}; +MODULE_DEVICE_TABLE(of, macsmc_gpio_of_table); + +static struct platform_driver macsmc_gpio_driver = { + .driver = { + .name = "macsmc-gpio", + .of_match_table = macsmc_gpio_of_table, + }, + .probe = macsmc_gpio_probe, +}; +module_platform_driver(macsmc_gpio_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC GPIO driver"); +MODULE_ALIAS("platform:macsmc-gpio"); -- 2.30.2 ^ permalink raw reply related [flat|nested] 342+ messages in thread
* [PATCH v3 7/7] gpio: Add new gpio-macsmc driver for Apple Macs @ 2022-11-08 16:33 ` Russell King 0 siblings, 0 replies; 342+ messages in thread From: Russell King @ 2022-11-08 16:33 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski, Rob Herring, Lee Jones Cc: Alyssa Rosenzweig, Andy Shevchenko, asahi, devicetree, Hector Martin, Jonathan Corbet, Krzysztof Kozlowski, linux-arm-kernel, linux-doc, linux-gpio, Petr Mladek, Rasmus Villemoes, Sergey Senozhatsky, Steven Rostedt, Sven Peter From: Hector Martin <marcan@marcan.st> This driver implements the GPIO service on top of the SMC framework on Apple Mac machines. In particular, these are the GPIOs present in the PMU IC which are used to control power to certain on-board devices. Although the underlying hardware supports various pin config settings (input/output, open drain, etc.), this driver does not implement that functionality and leaves it up to the firmware to configure things properly. We also don't yet support interrupts/events. This is sufficient for device power control, which is the only thing we need to support at this point. More features will be implemented when needed. To our knowledge, only Apple Silicon Macs implement this SMC feature. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- drivers/gpio/Kconfig | 11 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-macsmc.c | 245 +++++++++++++++++++++++++++++++++++++ 3 files changed, 257 insertions(+) create mode 100644 drivers/gpio/gpio-macsmc.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index a01af1180616..08138322010a 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -1283,6 +1283,17 @@ config GPIO_LP87565 This driver can also be built as a module. If so, the module will be called gpio-lp87565. +config GPIO_MACSMC + tristate "Apple Mac SMC GPIO" + depends on MFD_MACSMC + default ARCH_APPLE + help + Support for GPIOs controlled by the SMC microcontroller on Apple Mac + systems. + + This driver can also be built as a module. If so, the module will be + called gpio-macsmc. + config GPIO_MADERA tristate "Cirrus Logic Madera class codecs" depends on PINCTRL_MADERA diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 29e3beb6548c..467833cc9a9d 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o +obj-$(CONFIG_GPIO_MACSMC) += gpio-macsmc.o obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o diff --git a/drivers/gpio/gpio-macsmc.c b/drivers/gpio/gpio-macsmc.c new file mode 100644 index 000000000000..24ec98ad18f7 --- /dev/null +++ b/drivers/gpio/gpio-macsmc.c @@ -0,0 +1,245 @@ +// SPDX-License-Identifier: GPL-2.0-only OR MIT +/* + * Apple SMC GPIO driver + * Copyright The Asahi Linux Contributors + * + * This driver implements basic SMC PMU GPIO support that can read inputs + * and write outputs. Mode changes and IRQ config are not yet implemented. + */ + +#include <linux/bitmap.h> +#include <linux/device.h> +#include <linux/gpio/driver.h> +#include <linux/mfd/core.h> +#include <linux/mfd/macsmc.h> + +#define MAX_GPIO 64 + +/* + * Commands 0-6 are, presumably, the intended API. + * Command 0xff lets you get/set the pin configuration in detail directly, + * but the bit meanings seem not to be stable between devices/PMU hardware + * versions. + * + * We're going to try to make do with the low commands for now. + * We don't implement pin mode changes at this time. + */ + +#define CMD_ACTION (0 << 24) +#define CMD_OUTPUT (1 << 24) +#define CMD_INPUT (2 << 24) +#define CMD_PINMODE (3 << 24) +#define CMD_IRQ_ENABLE (4 << 24) +#define CMD_IRQ_ACK (5 << 24) +#define CMD_IRQ_MODE (6 << 24) +#define CMD_CONFIG (0xff << 24) + +#define MODE_INPUT 0 +#define MODE_OUTPUT 1 +#define MODE_VALUE_0 0 +#define MODE_VALUE_1 2 + +#define IRQ_MODE_HIGH 0 +#define IRQ_MODE_LOW 1 +#define IRQ_MODE_RISING 2 +#define IRQ_MODE_FALLING 3 +#define IRQ_MODE_BOTH 4 + +#define CONFIG_MASK GENMASK(23, 16) +#define CONFIG_VAL GENMASK(7, 0) + +#define CONFIG_OUTMODE GENMASK(7, 6) +#define CONFIG_IRQMODE GENMASK(5, 3) +#define CONFIG_PULLDOWN BIT(2) +#define CONFIG_PULLUP BIT(1) +#define CONFIG_OUTVAL BIT(0) + +/* + * Output modes seem to differ depending on the PMU in use... ? + * j274 / M1 (Sera PMU): + * 0 = input + * 1 = output + * 2 = open drain + * 3 = disable + * j314 / M1Pro (Maverick PMU): + * 0 = input + * 1 = open drain + * 2 = output + * 3 = ? + */ + +struct macsmc_gpio { + struct device *dev; + struct apple_smc *smc; + struct gpio_chip gc; + + int first_index; +}; + +static int macsmc_gpio_nr(smc_key key) +{ + int low = hex_to_bin(key & 0xff); + int high = hex_to_bin((key >> 8) & 0xff); + + if (low < 0 || high < 0) + return -1; + + return low | (high << 4); +} + +static int macsmc_gpio_key(unsigned int offset) +{ + return _SMC_KEY("gP\0\0") | hex_asc_hi(offset) << 8 | hex_asc_lo(offset); +} + +static int macsmc_gpio_get_direction(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 val; + int ret; + + /* First try reading the explicit pin mode register */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_PINMODE, &val); + if (!ret) + return (val & MODE_OUTPUT) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; + + /* + * Less common IRQ configs cause CMD_PINMODE to fail, and so does open drain mode. + * Fall back to reading IRQ mode, which will only succeed for inputs. + */ + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val); + return ret ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; +} + +static int macsmc_gpio_get(struct gpio_chip *gc, unsigned int offset) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + u32 cmd, val; + int ret; + + ret = macsmc_gpio_get_direction(gc, offset); + if (ret < 0) + return ret; + + if (ret == GPIO_LINE_DIRECTION_OUT) + cmd = CMD_OUTPUT; + else + cmd = CMD_INPUT; + + ret = apple_smc_rw_u32(smcgp->smc, key, cmd, &val); + if (ret < 0) + return ret; + + return val ? 1 : 0; +} + +static void macsmc_gpio_set(struct gpio_chip *gc, unsigned int offset, int value) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + smc_key key = macsmc_gpio_key(offset); + int ret; + + value |= CMD_OUTPUT; + ret = apple_smc_write_u32(smcgp->smc, key, CMD_OUTPUT | value); + if (ret < 0) + dev_err(smcgp->dev, "GPIO set failed %p4ch = 0x%x\n", &key, value); +} + +static int macsmc_gpio_init_valid_mask(struct gpio_chip *gc, + unsigned long *valid_mask, unsigned int ngpios) +{ + struct macsmc_gpio *smcgp = gpiochip_get_data(gc); + int count; + int i; + + count = apple_smc_get_key_count(smcgp->smc) - smcgp->first_index; + if (count > MAX_GPIO) + count = MAX_GPIO; + + bitmap_zero(valid_mask, ngpios); + + for (i = 0; i < count; i++) { + int ret, gpio_nr; + smc_key key; + + ret = apple_smc_get_key_by_index(smcgp->smc, smcgp->first_index + i, &key); + if (ret < 0) + return ret; + + if (key > SMC_KEY(gPff)) + break; + + gpio_nr = macsmc_gpio_nr(key); + if (gpio_nr < 0 || gpio_nr > MAX_GPIO) { + dev_err(smcgp->dev, "Bad GPIO key %p4ch\n", &key); + continue; + } + + set_bit(gpio_nr, valid_mask); + } + + return 0; +} + +static int macsmc_gpio_probe(struct platform_device *pdev) +{ + struct macsmc_gpio *smcgp; + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent); + smc_key key; + int ret; + + smcgp = devm_kzalloc(&pdev->dev, sizeof(*smcgp), GFP_KERNEL); + if (!smcgp) + return -ENOMEM; + + smcgp->dev = &pdev->dev; + smcgp->smc = smc; + smcgp->first_index = apple_smc_find_first_key_index(smc, SMC_KEY(gP00)); + + if (smcgp->first_index >= apple_smc_get_key_count(smc)) + return -ENODEV; + + ret = apple_smc_get_key_by_index(smc, smcgp->first_index, &key); + if (ret < 0) + return ret; + + if (key > macsmc_gpio_key(MAX_GPIO - 1)) + return -ENODEV; + + dev_info(smcgp->dev, "First GPIO key: %p4ch\n", &key); + + smcgp->gc.label = "macsmc-pmu-gpio"; + smcgp->gc.owner = THIS_MODULE; + smcgp->gc.get = macsmc_gpio_get; + smcgp->gc.set = macsmc_gpio_set; + smcgp->gc.get_direction = macsmc_gpio_get_direction; + smcgp->gc.init_valid_mask = macsmc_gpio_init_valid_mask; + smcgp->gc.can_sleep = true; + smcgp->gc.ngpio = MAX_GPIO; + smcgp->gc.base = -1; + smcgp->gc.parent = &pdev->dev; + + return devm_gpiochip_add_data(&pdev->dev, &smcgp->gc, smcgp); +} + +static const struct of_device_id macsmc_gpio_of_table[] = { + { .compatible = "apple,smc-gpio", }, + {} +}; +MODULE_DEVICE_TABLE(of, macsmc_gpio_of_table); + +static struct platform_driver macsmc_gpio_driver = { + .driver = { + .name = "macsmc-gpio", + .of_match_table = macsmc_gpio_of_table, + }, + .probe = macsmc_gpio_probe, +}; +module_platform_driver(macsmc_gpio_driver); + +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>"); +MODULE_LICENSE("Dual MIT/GPL"); +MODULE_DESCRIPTION("Apple SMC GPIO driver"); +MODULE_ALIAS("platform:macsmc-gpio"); -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 342+ messages in thread
end of thread, other threads:[~2022-11-22 14:50 UTC | newest]
Thread overview: 342+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
2022-09-01 13:54 ` Russell King (Oracle)
2022-09-01 13:54 ` [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller Russell King (Oracle)
2022-09-01 13:54 ` Russell King (Oracle)
2022-09-01 15:06 ` Krzysztof Kozlowski
2022-09-01 15:06 ` Krzysztof Kozlowski
2022-09-01 15:12 ` Russell King (Oracle)
2022-09-01 15:12 ` Russell King (Oracle)
2022-09-01 15:15 ` Krzysztof Kozlowski
2022-09-01 15:15 ` Krzysztof Kozlowski
2022-09-01 15:24 ` Russell King (Oracle)
2022-09-01 15:24 ` Russell King (Oracle)
2022-09-01 15:45 ` Krzysztof Kozlowski
2022-09-01 15:45 ` Krzysztof Kozlowski
2022-09-01 15:56 ` Russell King (Oracle)
2022-09-01 15:56 ` Russell King (Oracle)
2022-09-01 16:25 ` Krzysztof Kozlowski
2022-09-01 16:25 ` Krzysztof Kozlowski
2022-09-01 16:47 ` Russell King (Oracle)
2022-09-01 16:47 ` Russell King (Oracle)
2022-09-01 22:33 ` Rob Herring
2022-09-01 22:33 ` Rob Herring
2022-09-02 15:06 ` Mark Kettenis
2022-09-02 15:06 ` Mark Kettenis
2022-09-02 17:28 ` Rob Herring
2022-09-02 17:28 ` Rob Herring
2022-09-05 10:24 ` Russell King (Oracle)
2022-09-05 10:24 ` Russell King (Oracle)
2022-09-06 9:04 ` Russell King (Oracle)
2022-09-06 9:04 ` Russell King (Oracle)
2022-09-06 9:31 ` Mark Kettenis
2022-09-06 9:31 ` Mark Kettenis
2022-09-06 11:22 ` Linus Walleij
2022-09-06 11:22 ` Linus Walleij
2022-09-06 11:36 ` Hector Martin
2022-09-06 11:36 ` Hector Martin
2022-09-06 11:57 ` Linus Walleij
2022-09-06 11:57 ` Linus Walleij
2022-09-06 13:28 ` Hector Martin
2022-09-06 13:28 ` Hector Martin
2022-09-06 13:43 ` Russell King (Oracle)
2022-09-06 13:43 ` Russell King (Oracle)
2022-09-06 13:53 ` Hector Martin
2022-09-06 13:53 ` Hector Martin
2022-09-06 14:25 ` Mark Kettenis
2022-09-06 14:25 ` Mark Kettenis
2022-09-06 14:54 ` Russell King (Oracle)
2022-09-06 14:54 ` Russell King (Oracle)
2022-09-06 15:38 ` Mark Kettenis
2022-09-06 15:38 ` Mark Kettenis
2022-09-06 15:55 ` Rob Herring
2022-09-06 15:55 ` Rob Herring
2022-09-06 13:46 ` Linus Walleij
2022-09-06 13:46 ` Linus Walleij
2022-09-06 15:34 ` Rob Herring
2022-09-06 15:34 ` Rob Herring
2022-09-06 16:10 ` Rob Herring
2022-09-06 16:10 ` Rob Herring
2022-09-06 17:00 ` Hector Martin
2022-09-06 17:00 ` Hector Martin
2022-09-06 17:35 ` Rob Herring
2022-09-06 17:35 ` Rob Herring
2022-09-06 17:40 ` Sven Peter
2022-09-06 17:40 ` Sven Peter
2022-09-06 18:38 ` Hector Martin
2022-09-06 18:38 ` Hector Martin
2022-09-07 9:39 ` Mark Kettenis
2022-09-07 9:39 ` Mark Kettenis
2022-09-01 22:26 ` Rob Herring
2022-09-01 22:26 ` Rob Herring
2022-09-02 14:49 ` Mark Kettenis
2022-09-02 14:49 ` Mark Kettenis
2022-09-02 17:04 ` Rob Herring
2022-09-02 17:04 ` Rob Herring
2022-09-01 19:14 ` Rob Herring
2022-09-01 19:14 ` Rob Herring
2022-09-01 13:54 ` [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC Russell King (Oracle)
2022-09-01 13:54 ` Russell King (Oracle)
2022-09-01 15:11 ` Krzysztof Kozlowski
2022-09-01 15:11 ` Krzysztof Kozlowski
2022-09-01 15:14 ` Russell King (Oracle)
2022-09-01 15:14 ` Russell King (Oracle)
2022-09-01 13:54 ` [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll Russell King
2022-09-01 13:54 ` Russell King
2022-09-01 17:00 ` Sven Peter
2022-09-01 17:00 ` Sven Peter
2022-09-01 17:25 ` Eric Curtin
2022-09-01 17:25 ` Eric Curtin
2022-09-01 13:54 ` [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver Russell King
2022-09-01 13:54 ` Russell King
2022-09-01 17:50 ` Sven Peter
2022-09-01 17:50 ` Sven Peter
2022-09-05 10:55 ` Russell King (Oracle)
2022-09-05 10:55 ` Russell King (Oracle)
2022-09-05 16:53 ` Hector Martin
2022-09-05 16:53 ` Hector Martin
2022-09-01 19:26 ` Andy Shevchenko
2022-09-01 19:26 ` Andy Shevchenko
2022-09-02 6:45 ` Sven Peter
2022-09-02 6:45 ` Sven Peter
2022-09-05 14:45 ` Hector Martin
2022-09-05 14:45 ` Hector Martin
2022-09-05 15:00 ` Andy Shevchenko
2022-09-05 15:00 ` Andy Shevchenko
2022-09-08 10:58 ` Lee Jones
2022-09-08 10:58 ` Lee Jones
2022-09-08 11:28 ` Hector Martin
2022-09-08 11:28 ` Hector Martin
2022-09-08 12:31 ` Lee Jones
2022-09-08 12:31 ` Lee Jones
2022-09-08 12:58 ` Hector Martin
2022-09-08 12:58 ` Hector Martin
2022-09-08 13:29 ` Linus Walleij
2022-09-08 13:29 ` Linus Walleij
2022-09-08 13:36 ` Lee Jones
2022-09-08 13:36 ` Lee Jones
2022-09-08 13:58 ` Hector Martin
2022-09-08 13:58 ` Hector Martin
2022-09-09 7:50 ` Lee Jones
2022-09-09 7:50 ` Lee Jones
2022-09-12 10:03 ` Russell King (Oracle)
2022-09-12 10:03 ` Russell King (Oracle)
2022-09-12 10:55 ` Lee Jones
2022-09-12 10:55 ` Lee Jones
2022-10-28 15:36 ` Russell King (Oracle)
2022-10-28 15:36 ` Russell King (Oracle)
2022-10-31 8:46 ` Lee Jones
2022-10-31 8:46 ` Lee Jones
2022-10-31 9:03 ` Hector Martin
2022-10-31 9:03 ` Hector Martin
2022-10-31 9:44 ` Russell King (Oracle)
2022-10-31 9:44 ` Russell King (Oracle)
2022-10-31 17:24 ` Lee Jones
2022-10-31 17:24 ` Lee Jones
2022-10-31 19:47 ` Russell King (Oracle)
2022-10-31 19:47 ` Russell King (Oracle)
2022-11-01 9:59 ` Lee Jones
2022-11-01 9:59 ` Lee Jones
2022-10-29 6:40 ` Hector Martin
2022-10-29 6:40 ` Hector Martin
2022-10-31 8:48 ` Lee Jones
2022-10-31 8:48 ` Lee Jones
2022-10-31 8:58 ` Hector Martin
2022-10-31 8:58 ` Hector Martin
2022-10-31 9:29 ` Lee Jones
2022-10-31 9:29 ` Lee Jones
2022-10-31 9:44 ` Hector Martin
2022-10-31 9:44 ` Hector Martin
2022-10-31 17:23 ` Lee Jones
2022-10-31 17:23 ` Lee Jones
2022-10-31 19:34 ` Russell King (Oracle)
2022-10-31 19:34 ` Russell King (Oracle)
2022-11-02 13:12 ` Lee Jones
2022-11-02 13:12 ` Lee Jones
2022-11-02 15:54 ` Russell King (Oracle)
2022-11-02 15:54 ` Russell King (Oracle)
2022-09-01 13:54 ` [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs Russell King
2022-09-01 13:54 ` Russell King
2022-09-01 18:55 ` Andy Shevchenko
2022-09-01 18:55 ` Andy Shevchenko
2022-09-01 21:51 ` Martin Povišer
2022-09-01 21:51 ` Martin Povišer
2022-09-02 6:31 ` Andy Shevchenko
2022-09-02 6:31 ` Andy Shevchenko
[not found] ` <3B649A66-8116-432D-B88A-B5CE493EF930@cutebit.org>
[not found] ` <CAHp75VeB3_sZ2vsSxMSsLeJSkyemDh9iOPHXJCN1mhodA13LNQ@mail.gmail.com>
2022-09-02 11:12 ` Martin Povišer
2022-09-02 11:12 ` Martin Povišer
2022-09-02 13:33 ` Andy Shevchenko
2022-09-02 13:33 ` Andy Shevchenko
2022-09-02 13:36 ` Andy Shevchenko
2022-09-02 13:36 ` Andy Shevchenko
2022-09-02 13:37 ` Martin Povišer
2022-09-02 13:37 ` Martin Povišer
2022-09-02 14:41 ` Andy Shevchenko
2022-09-02 14:41 ` Andy Shevchenko
2022-09-02 14:45 ` Russell King (Oracle)
2022-09-02 14:45 ` Russell King (Oracle)
2022-09-02 10:05 ` Russell King (Oracle)
2022-09-02 10:05 ` Russell King (Oracle)
2022-09-02 10:37 ` Andy Shevchenko
2022-09-02 10:37 ` Andy Shevchenko
2022-09-02 11:32 ` Russell King (Oracle)
2022-09-02 11:32 ` Russell King (Oracle)
2022-09-02 13:39 ` Andy Shevchenko
2022-09-02 13:39 ` Andy Shevchenko
2022-09-02 14:46 ` Russell King (Oracle)
2022-09-02 14:46 ` Russell King (Oracle)
2022-09-02 14:53 ` Andy Shevchenko
2022-09-02 14:53 ` Andy Shevchenko
2022-09-02 15:34 ` Russell King (Oracle)
2022-09-02 15:34 ` Russell King (Oracle)
2022-09-02 15:43 ` Andy Shevchenko
2022-09-02 15:43 ` Andy Shevchenko
2022-09-05 10:20 ` Russell King (Oracle)
2022-09-05 10:20 ` Russell King (Oracle)
2022-09-05 10:32 ` Andy Shevchenko
2022-09-05 10:32 ` Andy Shevchenko
2022-09-05 13:10 ` Russell King (Oracle)
2022-09-05 13:10 ` Russell King (Oracle)
2022-09-05 13:16 ` Andy Shevchenko
2022-09-05 13:16 ` Andy Shevchenko
2022-09-05 14:01 ` Russell King (Oracle)
2022-09-05 14:01 ` Russell King (Oracle)
2022-09-05 14:02 ` Russell King (Oracle)
2022-09-05 14:02 ` Russell King (Oracle)
2022-09-05 14:42 ` Andy Shevchenko
2022-09-05 14:42 ` Andy Shevchenko
2022-09-05 14:53 ` Russell King (Oracle)
2022-09-05 14:53 ` Russell King (Oracle)
2022-09-05 14:50 ` Andy Shevchenko
2022-09-05 14:50 ` Andy Shevchenko
2022-09-05 15:52 ` Hector Martin
2022-09-05 15:52 ` Hector Martin
2022-09-05 15:56 ` Russell King (Oracle)
2022-09-05 15:56 ` Russell King (Oracle)
2022-09-05 15:32 ` Russell King (Oracle)
2022-09-05 15:32 ` Russell King (Oracle)
2022-09-05 15:44 ` Martin Povišer
2022-09-05 15:44 ` Martin Povišer
2022-09-05 15:58 ` Hector Martin
2022-09-05 15:58 ` Hector Martin
2022-09-05 16:13 ` Russell King (Oracle)
2022-09-05 16:13 ` Russell King (Oracle)
2022-09-05 19:10 ` Linus Walleij
2022-09-05 19:10 ` Linus Walleij
2022-09-06 6:51 ` Hector Martin
2022-09-06 6:51 ` Hector Martin
2022-09-05 15:47 ` Hector Martin
2022-09-05 15:47 ` Hector Martin
2022-09-05 15:39 ` Hector Martin
2022-09-05 15:39 ` Hector Martin
2022-09-05 15:16 ` Hector Martin
2022-09-05 15:16 ` Hector Martin
2022-09-05 15:04 ` Hector Martin
2022-09-05 15:04 ` Hector Martin
2022-09-02 9:42 ` Linus Walleij
2022-09-02 9:42 ` Linus Walleij
2022-09-01 13:54 ` [PATCH 6/6] gpio: macsmc: Add IRQ support Russell King
2022-09-01 13:54 ` Russell King
2022-09-01 18:03 ` Andy Shevchenko
2022-09-01 18:03 ` Andy Shevchenko
2022-09-05 11:54 ` Russell King (Oracle)
2022-09-05 11:54 ` Russell King (Oracle)
[not found] ` <CAHp75VeDGCp8J6wnmCqGpV++vs2Zur9Mfp71Dk8dVXcuHFnCrQ@mail.gmail.com>
2022-09-05 13:21 ` Andy Shevchenko
2022-09-05 13:21 ` Andy Shevchenko
2022-09-02 13:21 ` Linus Walleij
2022-09-02 13:21 ` Linus Walleij
2022-09-05 12:47 ` Russell King (Oracle)
2022-09-05 12:47 ` Russell King (Oracle)
2022-09-05 13:19 ` Fwd: " Andy Shevchenko
2022-09-05 13:19 ` Andy Shevchenko
2022-09-05 21:43 ` Russell King (Oracle)
2022-09-05 21:43 ` Russell King (Oracle)
2022-09-05 13:27 ` Linus Walleij
2022-09-05 13:27 ` Linus Walleij
2022-09-06 7:00 ` Hector Martin
2022-09-06 7:00 ` Hector Martin
2022-09-06 7:47 ` Russell King (Oracle)
2022-09-06 7:47 ` Russell King (Oracle)
2022-09-06 8:00 ` Hector Martin
2022-09-06 8:00 ` Hector Martin
2022-09-01 15:12 ` [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Krzysztof Kozlowski
2022-09-01 15:12 ` Krzysztof Kozlowski
2022-10-27 15:35 ` Russell King (Oracle)
2022-10-27 15:35 ` Russell King (Oracle)
2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
2022-11-08 16:32 ` Russell King (Oracle)
2022-11-08 16:33 ` [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver Russell King
2022-11-08 16:33 ` Russell King
2022-11-14 9:52 ` Lee Jones
2022-11-14 9:52 ` Lee Jones
2022-11-14 10:35 ` Andy Shevchenko
2022-11-14 10:35 ` Andy Shevchenko
2022-11-08 16:33 ` [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc Russell King
2022-11-08 16:33 ` Russell King
2022-11-14 15:34 ` Petr Mladek
2022-11-14 15:34 ` Petr Mladek
2022-11-14 15:46 ` Andy Shevchenko
2022-11-14 15:46 ` Andy Shevchenko
2022-11-14 16:18 ` Petr Mladek
2022-11-14 16:18 ` Petr Mladek
2022-11-14 16:15 ` Russell King (Oracle)
2022-11-14 16:15 ` Russell King (Oracle)
2022-11-14 16:46 ` Russell King (Oracle)
2022-11-14 16:46 ` Russell King (Oracle)
2022-11-22 12:43 ` Petr Mladek
2022-11-22 12:43 ` Petr Mladek
2022-11-22 14:49 ` Petr Mladek
2022-11-22 14:49 ` Petr Mladek
2022-11-08 16:33 ` [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller Russell King (Oracle)
2022-11-08 16:33 ` Russell King (Oracle)
2022-11-08 20:42 ` Linus Walleij
2022-11-08 20:42 ` Linus Walleij
2022-11-08 20:55 ` Krzysztof Kozlowski
2022-11-08 20:55 ` Krzysztof Kozlowski
2022-11-08 22:22 ` Russell King (Oracle)
2022-11-08 22:22 ` Russell King (Oracle)
2022-11-09 8:35 ` Krzysztof Kozlowski
2022-11-09 8:35 ` Krzysztof Kozlowski
2022-11-09 22:17 ` Rob Herring
2022-11-09 22:17 ` Rob Herring
2022-11-10 11:35 ` Hector Martin
2022-11-10 11:35 ` Hector Martin
2022-11-10 11:48 ` Russell King (Oracle)
2022-11-10 11:48 ` Russell King (Oracle)
2022-11-10 14:00 ` Krzysztof Kozlowski
2022-11-10 14:00 ` Krzysztof Kozlowski
2022-11-10 14:14 ` Russell King (Oracle)
2022-11-10 14:14 ` Russell King (Oracle)
2022-11-10 14:21 ` Krzysztof Kozlowski
2022-11-10 14:21 ` Krzysztof Kozlowski
2022-11-10 14:23 ` Russell King (Oracle)
2022-11-10 14:23 ` Russell King (Oracle)
2022-11-10 14:36 ` Krzysztof Kozlowski
2022-11-10 14:36 ` Krzysztof Kozlowski
2022-11-10 14:43 ` Russell King (Oracle)
2022-11-10 14:43 ` Russell King (Oracle)
2022-11-14 10:05 ` Lee Jones
2022-11-14 10:05 ` Lee Jones
2022-11-08 22:30 ` Rob Herring
2022-11-08 22:30 ` Rob Herring
2022-11-08 16:33 ` [PATCH v3 4/7] platform/apple: Add new Apple Mac SMC driver Russell King
2022-11-08 16:33 ` Russell King
2022-11-08 16:33 ` [PATCH v3 5/7] arm64: dts: apple: Add SMC node to t8103 devicetrees Russell King
2022-11-08 16:33 ` Russell King
2022-11-08 16:33 ` [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC Russell King (Oracle)
2022-11-08 16:33 ` Russell King (Oracle)
2022-11-08 20:56 ` Krzysztof Kozlowski
2022-11-08 20:56 ` Krzysztof Kozlowski
2022-11-08 22:09 ` Russell King (Oracle)
2022-11-08 22:09 ` Russell King (Oracle)
2022-11-09 7:31 ` Hector Martin
2022-11-09 7:31 ` Hector Martin
2022-11-09 8:36 ` Krzysztof Kozlowski
2022-11-09 8:36 ` Krzysztof Kozlowski
2022-11-09 9:12 ` Russell King (Oracle)
2022-11-09 9:12 ` Russell King (Oracle)
2022-11-09 9:19 ` Krzysztof Kozlowski
2022-11-09 9:19 ` Krzysztof Kozlowski
2022-11-08 22:30 ` Rob Herring
2022-11-08 22:30 ` Rob Herring
2022-11-08 16:33 ` [PATCH v3 7/7] gpio: Add new gpio-macsmc driver for Apple Macs Russell King
2022-11-08 16:33 ` Russell King
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.