linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/6] Add Apple Mac System Management Controller GPIOs
@ 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)
                   ` (8 more replies)
  0 siblings, 9 replies; 171+ 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] 171+ messages in thread

* [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  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 15:06   ` Krzysztof Kozlowski
  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)
                   ` (7 subsequent siblings)
  8 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs 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:11   ` Krzysztof Kozlowski
  2022-09-01 13:54 ` [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll Russell King
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 171+ 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] 171+ messages in thread

* [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs 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 ` [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
  2022-09-01 17:00   ` Sven Peter
  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
                   ` (5 subsequent siblings)
  8 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
                   ` (2 preceding siblings ...)
  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:50   ` Sven Peter
                     ` (2 more replies)
  2022-09-01 13:54 ` [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs Russell King
                   ` (4 subsequent siblings)
  8 siblings, 3 replies; 171+ 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] 171+ messages in thread

* [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
                   ` (3 preceding siblings ...)
  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 18:55   ` Andy Shevchenko
  2022-09-02  9:42   ` Linus Walleij
  2022-09-01 13:54 ` [PATCH 6/6] gpio: macsmc: Add IRQ support Russell King
                   ` (3 subsequent siblings)
  8 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [PATCH 6/6] gpio: macsmc: Add IRQ support
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
                   ` (4 preceding siblings ...)
  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:03   ` Andy Shevchenko
  2022-09-02 13:21   ` Linus Walleij
  2022-09-01 15:12 ` [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Krzysztof Kozlowski
                   ` (2 subsequent siblings)
  8 siblings, 2 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  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 15:06   ` Krzysztof Kozlowski
  2022-09-01 15:12     ` Russell King (Oracle)
  2022-09-01 19:14   ` Rob Herring
  1 sibling, 1 reply; 171+ 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] 171+ 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 ` [PATCH 2/6] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC Russell King (Oracle)
@ 2022-09-01 15:11   ` Krzysztof Kozlowski
  2022-09-01 15:14     ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [PATCH 0/6] Add Apple Mac System Management Controller GPIOs
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
                   ` (5 preceding siblings ...)
  2022-09-01 13:54 ` [PATCH 6/6] gpio: macsmc: Add IRQ support Russell King
@ 2022-09-01 15:12 ` Krzysztof Kozlowski
  2022-10-27 15:35 ` Russell King (Oracle)
  2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
  8 siblings, 0 replies; 171+ 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] 171+ 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)
  2022-09-01 15:15       ` Krzysztof Kozlowski
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  0 siblings, 0 replies; 171+ 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] 171+ 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
  2022-09-01 15:24         ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-01 15:45           ` Krzysztof Kozlowski
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-01 15:56             ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-01 16:25               ` Krzysztof Kozlowski
  2022-09-01 22:26               ` Rob Herring
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-01 16:47                 ` Russell King (Oracle)
  2022-09-01 22:26               ` Rob Herring
  1 sibling, 1 reply; 171+ 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] 171+ 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)
  2022-09-01 22:33                   ` Rob Herring
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll
  2022-09-01 13:54 ` [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll Russell King
@ 2022-09-01 17:00   ` Sven Peter
  2022-09-01 17:25   ` Eric Curtin
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll
  2022-09-01 13:54 ` [PATCH 3/6] soc: apple: rtkit: Add apple_rtkit_poll Russell King
  2022-09-01 17:00   ` Sven Peter
@ 2022-09-01 17:25   ` Eric Curtin
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver
  2022-09-01 13:54 ` [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver Russell King
@ 2022-09-01 17:50   ` Sven Peter
  2022-09-05 10:55     ` Russell King (Oracle)
  2022-09-01 19:26   ` Andy Shevchenko
  2022-09-08 10:58   ` Lee Jones
  2 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support
  2022-09-01 13:54 ` [PATCH 6/6] gpio: macsmc: Add IRQ support Russell King
@ 2022-09-01 18:03   ` Andy Shevchenko
  2022-09-05 11:54     ` Russell King (Oracle)
  2022-09-02 13:21   ` Linus Walleij
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs
  2022-09-01 13:54 ` [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs Russell King
@ 2022-09-01 18:55   ` Andy Shevchenko
  2022-09-01 21:51     ` Martin Povišer
                       ` (2 more replies)
  2022-09-02  9:42   ` Linus Walleij
  1 sibling, 3 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  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 15:06   ` Krzysztof Kozlowski
@ 2022-09-01 19:14   ` Rob Herring
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver
  2022-09-01 13:54 ` [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver Russell King
  2022-09-01 17:50   ` Sven Peter
@ 2022-09-01 19:26   ` Andy Shevchenko
  2022-09-02  6:45     ` Sven Peter
  2022-09-05 14:45     ` Hector Martin
  2022-09-08 10:58   ` Lee Jones
  2 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-02  6:31       ` Andy Shevchenko
  2022-09-02 10:05     ` Russell King (Oracle)
  2022-09-05 15:04     ` Hector Martin
  2 siblings, 1 reply; 171+ 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] 171+ 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
@ 2022-09-01 22:26               ` Rob Herring
  2022-09-02 14:49                 ` Mark Kettenis
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-09-02 15:06                     ` Mark Kettenis
  0 siblings, 1 reply; 171+ 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] 171+ 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
       [not found]         ` <3B649A66-8116-432D-B88A-B5CE493EF930@cutebit.org>
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-05 14:45     ` Hector Martin
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs
  2022-09-01 13:54 ` [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs Russell King
  2022-09-01 18:55   ` Andy Shevchenko
@ 2022-09-02  9:42   ` Linus Walleij
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-02 10:05     ` Russell King (Oracle)
  2022-09-02 10:37       ` Andy Shevchenko
  2022-09-05 15:16       ` Hector Martin
  2022-09-05 15:04     ` Hector Martin
  2 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-02 11:32         ` Russell King (Oracle)
  2022-09-05 15:16       ` Hector Martin
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* 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
  2022-09-02 13:33               ` Andy Shevchenko
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-02 13:39           ` Andy Shevchenko
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support
  2022-09-01 13:54 ` [PATCH 6/6] gpio: macsmc: Add IRQ support Russell King
  2022-09-01 18:03   ` Andy Shevchenko
@ 2022-09-02 13:21   ` Linus Walleij
  2022-09-05 12:47     ` Russell King (Oracle)
  2022-09-06  7:00     ` Hector Martin
  1 sibling, 2 replies; 171+ 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] 171+ 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
  2022-09-02 13:36                 ` Andy Shevchenko
  2022-09-02 13:37                 ` Martin Povišer
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-02 13:37                 ` Martin Povišer
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-02 13:37                 ` Martin Povišer
  2022-09-02 14:41                   ` Andy Shevchenko
  2022-09-02 14:45                   ` Russell King (Oracle)
  1 sibling, 2 replies; 171+ 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] 171+ 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
  2022-09-02 14:46             ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-02 14:45                   ` Russell King (Oracle)
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-02 14:45                   ` Russell King (Oracle)
  1 sibling, 0 replies; 171+ 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] 171+ 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)
  2022-09-02 14:53               ` Andy Shevchenko
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-02 17:04                   ` Rob Herring
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-02 15:34                 ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-02 17:28                       ` Rob Herring
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-02 15:43                   ` Andy Shevchenko
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-05 10:20                     ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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
  2022-09-05 10:24                         ` Russell King (Oracle)
  2022-09-06  9:04                         ` Russell King (Oracle)
  0 siblings, 2 replies; 171+ 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] 171+ 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)
  2022-09-05 10:32                       ` Andy Shevchenko
  2022-09-05 15:39                       ` Hector Martin
  0 siblings, 2 replies; 171+ 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] 171+ 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)
  2022-09-06  9:04                         ` Russell King (Oracle)
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-09-05 13:10                         ` Russell King (Oracle)
  2022-09-05 15:39                       ` Hector Martin
  1 sibling, 1 reply; 171+ 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] 171+ 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)
  2022-09-05 16:53       ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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)
       [not found]       ` <CAHp75VeDGCp8J6wnmCqGpV++vs2Zur9Mfp71Dk8dVXcuHFnCrQ@mail.gmail.com>
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-05 13:19       ` Fwd: " Andy Shevchenko
  2022-09-05 13:27       ` Linus Walleij
  2022-09-06  7:00     ` Hector Martin
  1 sibling, 2 replies; 171+ 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] 171+ 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)
  2022-09-05 13:16                           ` Andy Shevchenko
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-05 14:01                             ` Russell King (Oracle)
                                               ` (2 more replies)
  0 siblings, 3 replies; 171+ 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] 171+ 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
  2022-09-05 21:43         ` Russell King (Oracle)
  2022-09-05 13:27       ` Linus Walleij
  1 sibling, 1 reply; 171+ 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] 171+ messages in thread

* 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; 171+ 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] 171+ messages in thread

* Re: [PATCH 6/6] gpio: macsmc: Add IRQ support
  2022-09-05 12:47     ` Russell King (Oracle)
  2022-09-05 13:19       ` Fwd: " Andy Shevchenko
@ 2022-09-05 13:27       ` Linus Walleij
  1 sibling, 0 replies; 171+ 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] 171+ 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)
  2022-09-05 14:02                               ` Russell King (Oracle)
                                                 ` (2 more replies)
  2022-09-05 15:32                             ` Russell King (Oracle)
  2022-09-05 15:47                             ` Hector Martin
  2 siblings, 3 replies; 171+ 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] 171+ 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)
  2022-09-05 14:42                                 ` Andy Shevchenko
  2022-09-05 14:50                               ` Andy Shevchenko
  2022-09-05 15:52                               ` Hector Martin
  2 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-05 14:53                                   ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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
@ 2022-09-05 14:45     ` Hector Martin
  2022-09-05 15:00       ` Andy Shevchenko
  1 sibling, 1 reply; 171+ 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] 171+ 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)
@ 2022-09-05 14:50                               ` Andy Shevchenko
  2022-09-05 15:52                               ` Hector Martin
  2 siblings, 0 replies; 171+ 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] 171+ 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)
  0 siblings, 0 replies; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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
  2022-09-02 10:05     ` Russell King (Oracle)
@ 2022-09-05 15:04     ` Hector Martin
  2 siblings, 0 replies; 171+ 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] 171+ 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
@ 2022-09-05 15:16       ` Hector Martin
  1 sibling, 0 replies; 171+ 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] 171+ 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)
@ 2022-09-05 15:32                             ` Russell King (Oracle)
  2022-09-05 15:44                               ` Martin Povišer
  2022-09-05 15:47                             ` Hector Martin
  2 siblings, 1 reply; 171+ 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] 171+ 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
@ 2022-09-05 15:39                       ` Hector Martin
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-09-05 15:58                                 ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-05 15:32                             ` Russell King (Oracle)
@ 2022-09-05 15:47                             ` Hector Martin
  2 siblings, 0 replies; 171+ 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] 171+ 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)
  2022-09-05 14:50                               ` Andy Shevchenko
@ 2022-09-05 15:52                               ` Hector Martin
  2022-09-05 15:56                                 ` Russell King (Oracle)
  2 siblings, 1 reply; 171+ 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] 171+ 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)
  0 siblings, 0 replies; 171+ 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] 171+ 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
  2022-09-05 16:13                                   ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-05 19:10                                     ` Linus Walleij
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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
  2022-09-06  6:51                                       ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: Fwd: [PATCH 6/6] gpio: macsmc: Add IRQ support
  2022-09-05 13:19       ` Fwd: " Andy Shevchenko
@ 2022-09-05 21:43         ` Russell King (Oracle)
  0 siblings, 0 replies; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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)
@ 2022-09-06  7:00     ` Hector Martin
  2022-09-06  7:47       ` Russell King (Oracle)
  1 sibling, 1 reply; 171+ 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] 171+ 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)
  2022-09-06  8:00         ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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)
@ 2022-09-06  9:04                         ` Russell King (Oracle)
  2022-09-06  9:31                           ` Mark Kettenis
  2022-09-06 16:10                           ` Rob Herring
  1 sibling, 2 replies; 171+ 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] 171+ 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
  2022-09-06 11:22                             ` Linus Walleij
  2022-09-06 16:10                           ` Rob Herring
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-09-06 11:36                               ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-06 11:57                                 ` Linus Walleij
  2022-09-06 15:34                                 ` Rob Herring
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-06 13:28                                   ` Hector Martin
  2022-09-06 15:34                                 ` Rob Herring
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-09-06 13:43                                     ` Russell King (Oracle)
  2022-09-06 13:46                                     ` Linus Walleij
  0 siblings, 2 replies; 171+ 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] 171+ 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)
  2022-09-06 13:53                                       ` Hector Martin
  2022-09-06 13:46                                     ` Linus Walleij
  1 sibling, 1 reply; 171+ 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] 171+ 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)
@ 2022-09-06 13:46                                     ` Linus Walleij
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-09-06 14:25                                         ` Mark Kettenis
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-06 14:54                                           ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-09-06 15:38                                             ` Mark Kettenis
  2022-09-06 15:55                                             ` Rob Herring
  0 siblings, 2 replies; 171+ 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] 171+ 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
@ 2022-09-06 15:34                                 ` Rob Herring
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-09-06 15:55                                             ` Rob Herring
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-06 15:55                                             ` Rob Herring
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-06 16:10                           ` Rob Herring
  2022-09-06 17:00                             ` Hector Martin
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-09-06 17:35                               ` Rob Herring
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-06 17:40                                 ` Sven Peter
  2022-09-06 18:38                                 ` Hector Martin
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-06 18:38                                 ` Hector Martin
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-06 18:38                                 ` Hector Martin
  2022-09-07  9:39                                   ` Mark Kettenis
  1 sibling, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver
  2022-09-01 13:54 ` [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver Russell King
  2022-09-01 17:50   ` Sven Peter
  2022-09-01 19:26   ` Andy Shevchenko
@ 2022-09-08 10:58   ` Lee Jones
  2022-09-08 11:28     ` Hector Martin
  2 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-08 12:31       ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-08 12:58         ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-08 13:29           ` Linus Walleij
  2022-09-08 13:36           ` Lee Jones
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2022-09-08 13:36           ` Lee Jones
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-09-08 13:36           ` Lee Jones
  2022-09-08 13:58             ` Hector Martin
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-09-09  7:50               ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-09-12 10:03                 ` Russell King (Oracle)
  2022-10-29  6:40                 ` Hector Martin
  0 siblings, 2 replies; 171+ 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] 171+ 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)
  2022-09-12 10:55                   ` Lee Jones
  2022-10-29  6:40                 ` Hector Martin
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-10-28 15:36                     ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ messages in thread

* Re: [PATCH 0/6] Add Apple Mac System Management Controller GPIOs
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
                   ` (6 preceding siblings ...)
  2022-09-01 15:12 ` [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Krzysztof Kozlowski
@ 2022-10-27 15:35 ` Russell King (Oracle)
  2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
  8 siblings, 0 replies; 171+ 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] 171+ 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)
  2022-10-31  8:46                       ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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)
@ 2022-10-29  6:40                 ` Hector Martin
  2022-10-31  8:48                   ` Lee Jones
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-10-31  9:03                         ` Hector Martin
  2022-10-31  9:44                         ` Russell King (Oracle)
  0 siblings, 2 replies; 171+ 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] 171+ 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
  2022-10-31  8:58                     ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-10-31  9:29                       ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-10-31  9:44                         ` Russell King (Oracle)
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-10-31  9:44                         ` Hector Martin
  0 siblings, 1 reply; 171+ 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] 171+ 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
@ 2022-10-31  9:44                         ` Russell King (Oracle)
  2022-10-31 17:24                           ` Lee Jones
  1 sibling, 1 reply; 171+ 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] 171+ 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
  2022-10-31 17:23                           ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-10-31 19:34                             ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-10-31 19:47                             ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-11-02 13:12                               ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-11-01  9:59                               ` Lee Jones
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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
  2022-11-02 15:54                                 ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 0/7] Add Apple Mac System Management Controller GPIOs
  2022-09-01 13:54 [PATCH 0/6] Add Apple Mac System Management Controller GPIOs Russell King (Oracle)
                   ` (7 preceding siblings ...)
  2022-10-27 15:35 ` 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
                     ` (6 more replies)
  8 siblings, 7 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver
  2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
@ 2022-11-08 16:33   ` Russell King
  2022-11-14  9:52     ` Lee Jones
  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
                     ` (5 subsequent siblings)
  6 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc
  2022-11-08 16:32 ` [PATCH v3 0/7] " 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 15:34     ` 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)
                     ` (4 subsequent siblings)
  6 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  2022-11-08 16:32 ` [PATCH v3 0/7] " 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   ` [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc Russell King
@ 2022-11-08 16:33   ` Russell King (Oracle)
  2022-11-08 20:42     ` Linus Walleij
                       ` (2 more replies)
  2022-11-08 16:33   ` [PATCH v3 4/7] platform/apple: Add new Apple Mac SMC driver Russell King
                     ` (3 subsequent siblings)
  6 siblings, 3 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 4/7] platform/apple: Add new Apple Mac SMC driver
  2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
                     ` (2 preceding siblings ...)
  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
  2022-11-08 16:33   ` [PATCH v3 5/7] arm64: dts: apple: Add SMC node to t8103 devicetrees Russell King
                     ` (2 subsequent siblings)
  6 siblings, 0 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 5/7] arm64: dts: apple: Add SMC node to t8103 devicetrees
  2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
                     ` (3 preceding siblings ...)
  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 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC Russell King (Oracle)
  2022-11-08 16:33   ` [PATCH v3 7/7] gpio: Add new gpio-macsmc driver for Apple Macs Russell King
  6 siblings, 0 replies; 171+ 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] 171+ 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 ` [PATCH v3 0/7] " Russell King (Oracle)
                     ` (4 preceding siblings ...)
  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 (Oracle)
  2022-11-08 20:56     ` Krzysztof Kozlowski
  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
  6 siblings, 2 replies; 171+ 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] 171+ messages in thread

* [PATCH v3 7/7] gpio: Add new gpio-macsmc driver for Apple Macs
  2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
                     ` (5 preceding siblings ...)
  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
  6 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  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 20:42     ` Linus Walleij
  2022-11-08 20:55     ` Krzysztof Kozlowski
  2022-11-08 22:30     ` Rob Herring
  2 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  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 20:42     ` Linus Walleij
@ 2022-11-08 20:55     ` Krzysztof Kozlowski
  2022-11-08 22:22       ` Russell King (Oracle)
  2022-11-08 22:30     ` Rob Herring
  2 siblings, 1 reply; 171+ 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] 171+ 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   ` [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC Russell King (Oracle)
@ 2022-11-08 20:56     ` Krzysztof Kozlowski
  2022-11-08 22:09       ` Russell King (Oracle)
  2022-11-08 22:30     ` Rob Herring
  1 sibling, 1 reply; 171+ 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] 171+ 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)
  2022-11-09  7:31         ` Hector Martin
  2022-11-09  8:36         ` Krzysztof Kozlowski
  0 siblings, 2 replies; 171+ 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] 171+ 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)
  2022-11-09  8:35         ` Krzysztof Kozlowski
  2022-11-09 22:17         ` Rob Herring
  0 siblings, 2 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller
  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 20:42     ` Linus Walleij
  2022-11-08 20:55     ` Krzysztof Kozlowski
@ 2022-11-08 22:30     ` Rob Herring
  2 siblings, 0 replies; 171+ 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] 171+ 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   ` [PATCH v3 6/7] dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC Russell King (Oracle)
  2022-11-08 20:56     ` Krzysztof Kozlowski
@ 2022-11-08 22:30     ` Rob Herring
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-11-09  8:36         ` Krzysztof Kozlowski
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-11-09 22:17         ` Rob Herring
  1 sibling, 0 replies; 171+ 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] 171+ 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
@ 2022-11-09  8:36         ` Krzysztof Kozlowski
  2022-11-09  9:12           ` Russell King (Oracle)
  1 sibling, 1 reply; 171+ 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] 171+ 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)
  2022-11-09  9:19             ` Krzysztof Kozlowski
  0 siblings, 1 reply; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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
@ 2022-11-09 22:17         ` Rob Herring
  2022-11-10 11:35           ` Hector Martin
                             ` (2 more replies)
  1 sibling, 3 replies; 171+ 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] 171+ 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
  2022-11-10 11:48           ` Russell King (Oracle)
  2022-11-14 10:05           ` Lee Jones
  2 siblings, 0 replies; 171+ 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] 171+ 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
@ 2022-11-10 11:48           ` Russell King (Oracle)
  2022-11-10 14:00             ` Krzysztof Kozlowski
  2022-11-14 10:05           ` Lee Jones
  2 siblings, 1 reply; 171+ 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] 171+ 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
  2022-11-10 14:14               ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-11-10 14:21                 ` Krzysztof Kozlowski
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-11-10 14:23                   ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  2022-11-10 14:36                     ` Krzysztof Kozlowski
  0 siblings, 1 reply; 171+ 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] 171+ 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
  2022-11-10 14:43                       ` Russell King (Oracle)
  0 siblings, 1 reply; 171+ 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] 171+ 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)
  0 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver
  2022-11-08 16:33   ` [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver Russell King
@ 2022-11-14  9:52     ` Lee Jones
  2022-11-14 10:35     ` Andy Shevchenko
  1 sibling, 0 replies; 171+ 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] 171+ 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
  2022-11-10 11:48           ` Russell King (Oracle)
@ 2022-11-14 10:05           ` Lee Jones
  2 siblings, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver
  2022-11-08 16:33   ` [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver Russell King
  2022-11-14  9:52     ` Lee Jones
@ 2022-11-14 10:35     ` Andy Shevchenko
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc
  2022-11-08 16:33   ` [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc Russell King
@ 2022-11-14 15:34     ` Petr Mladek
  2022-11-14 15:46       ` Andy Shevchenko
  2022-11-14 16:15       ` Russell King (Oracle)
  2022-11-22 14:49     ` Petr Mladek
  1 sibling, 2 replies; 171+ 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] 171+ 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
  2022-11-14 16:18         ` Petr Mladek
  2022-11-14 16:15       ` Russell King (Oracle)
  1 sibling, 1 reply; 171+ 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] 171+ 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
@ 2022-11-14 16:15       ` Russell King (Oracle)
  2022-11-14 16:46         ` Russell King (Oracle)
  2022-11-22 12:43         ` Petr Mladek
  1 sibling, 2 replies; 171+ 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] 171+ 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
  0 siblings, 0 replies; 171+ 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] 171+ 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)
  2022-11-22 12:43         ` Petr Mladek
  1 sibling, 0 replies; 171+ 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] 171+ 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)
@ 2022-11-22 12:43         ` Petr Mladek
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

* Re: [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc
  2022-11-08 16:33   ` [PATCH v3 2/7] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc Russell King
  2022-11-14 15:34     ` Petr Mladek
@ 2022-11-22 14:49     ` Petr Mladek
  1 sibling, 0 replies; 171+ 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] 171+ messages in thread

end of thread, other threads:[~2022-11-22 14:50 UTC | newest]

Thread overview: 171+ 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 ` [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller Russell King (Oracle)
2022-09-01 15:06   ` Krzysztof Kozlowski
2022-09-01 15:12     ` Russell King (Oracle)
2022-09-01 15:15       ` Krzysztof Kozlowski
2022-09-01 15:24         ` Russell King (Oracle)
2022-09-01 15:45           ` Krzysztof Kozlowski
2022-09-01 15:56             ` Russell King (Oracle)
2022-09-01 16:25               ` Krzysztof Kozlowski
2022-09-01 16:47                 ` Russell King (Oracle)
2022-09-01 22:33                   ` Rob Herring
2022-09-02 15:06                     ` Mark Kettenis
2022-09-02 17:28                       ` Rob Herring
2022-09-05 10:24                         ` Russell King (Oracle)
2022-09-06  9:04                         ` Russell King (Oracle)
2022-09-06  9:31                           ` Mark Kettenis
2022-09-06 11:22                             ` Linus Walleij
2022-09-06 11:36                               ` Hector Martin
2022-09-06 11:57                                 ` Linus Walleij
2022-09-06 13:28                                   ` Hector Martin
2022-09-06 13:43                                     ` Russell King (Oracle)
2022-09-06 13:53                                       ` Hector Martin
2022-09-06 14:25                                         ` Mark Kettenis
2022-09-06 14:54                                           ` Russell King (Oracle)
2022-09-06 15:38                                             ` Mark Kettenis
2022-09-06 15:55                                             ` Rob Herring
2022-09-06 13:46                                     ` Linus Walleij
2022-09-06 15:34                                 ` Rob Herring
2022-09-06 16:10                           ` Rob Herring
2022-09-06 17:00                             ` Hector Martin
2022-09-06 17:35                               ` Rob Herring
2022-09-06 17:40                                 ` Sven Peter
2022-09-06 18:38                                 ` Hector Martin
2022-09-07  9:39                                   ` Mark Kettenis
2022-09-01 22:26               ` Rob Herring
2022-09-02 14:49                 ` Mark Kettenis
2022-09-02 17:04                   ` 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 15:11   ` Krzysztof Kozlowski
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 17:00   ` Sven Peter
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 17:50   ` Sven Peter
2022-09-05 10:55     ` Russell King (Oracle)
2022-09-05 16:53       ` Hector Martin
2022-09-01 19:26   ` Andy Shevchenko
2022-09-02  6:45     ` Sven Peter
2022-09-05 14:45     ` Hector Martin
2022-09-05 15:00       ` Andy Shevchenko
2022-09-08 10:58   ` Lee Jones
2022-09-08 11:28     ` Hector Martin
2022-09-08 12:31       ` Lee Jones
2022-09-08 12:58         ` Hector Martin
2022-09-08 13:29           ` Linus Walleij
2022-09-08 13:36           ` Lee Jones
2022-09-08 13:58             ` Hector Martin
2022-09-09  7:50               ` Lee Jones
2022-09-12 10:03                 ` Russell King (Oracle)
2022-09-12 10:55                   ` Lee Jones
2022-10-28 15:36                     ` Russell King (Oracle)
2022-10-31  8:46                       ` Lee Jones
2022-10-31  9:03                         ` Hector Martin
2022-10-31  9:44                         ` Russell King (Oracle)
2022-10-31 17:24                           ` Lee Jones
2022-10-31 19:47                             ` Russell King (Oracle)
2022-11-01  9:59                               ` Lee Jones
2022-10-29  6:40                 ` Hector Martin
2022-10-31  8:48                   ` Lee Jones
2022-10-31  8:58                     ` Hector Martin
2022-10-31  9:29                       ` Lee Jones
2022-10-31  9:44                         ` Hector Martin
2022-10-31 17:23                           ` Lee Jones
2022-10-31 19:34                             ` Russell King (Oracle)
2022-11-02 13:12                               ` Lee Jones
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 18:55   ` Andy Shevchenko
2022-09-01 21:51     ` Martin Povišer
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 13:33               ` Andy Shevchenko
2022-09-02 13:36                 ` Andy Shevchenko
2022-09-02 13:37                 ` Martin Povišer
2022-09-02 14:41                   ` Andy Shevchenko
2022-09-02 14:45                   ` Russell King (Oracle)
2022-09-02 10:05     ` Russell King (Oracle)
2022-09-02 10:37       ` Andy Shevchenko
2022-09-02 11:32         ` Russell King (Oracle)
2022-09-02 13:39           ` Andy Shevchenko
2022-09-02 14:46             ` Russell King (Oracle)
2022-09-02 14:53               ` Andy Shevchenko
2022-09-02 15:34                 ` Russell King (Oracle)
2022-09-02 15:43                   ` Andy Shevchenko
2022-09-05 10:20                     ` Russell King (Oracle)
2022-09-05 10:32                       ` Andy Shevchenko
2022-09-05 13:10                         ` Russell King (Oracle)
2022-09-05 13:16                           ` Andy Shevchenko
2022-09-05 14:01                             ` Russell King (Oracle)
2022-09-05 14:02                               ` Russell King (Oracle)
2022-09-05 14:42                                 ` Andy Shevchenko
2022-09-05 14:53                                   ` Russell King (Oracle)
2022-09-05 14:50                               ` Andy Shevchenko
2022-09-05 15:52                               ` Hector Martin
2022-09-05 15:56                                 ` Russell King (Oracle)
2022-09-05 15:32                             ` Russell King (Oracle)
2022-09-05 15:44                               ` Martin Povišer
2022-09-05 15:58                                 ` Hector Martin
2022-09-05 16:13                                   ` Russell King (Oracle)
2022-09-05 19:10                                     ` Linus Walleij
2022-09-06  6:51                                       ` Hector Martin
2022-09-05 15:47                             ` Hector Martin
2022-09-05 15:39                       ` Hector Martin
2022-09-05 15:16       ` Hector Martin
2022-09-05 15:04     ` Hector Martin
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 18:03   ` Andy Shevchenko
2022-09-05 11:54     ` Russell King (Oracle)
     [not found]       ` <CAHp75VeDGCp8J6wnmCqGpV++vs2Zur9Mfp71Dk8dVXcuHFnCrQ@mail.gmail.com>
2022-09-05 13:21         ` Andy Shevchenko
2022-09-02 13:21   ` Linus Walleij
2022-09-05 12:47     ` Russell King (Oracle)
2022-09-05 13:19       ` Fwd: " Andy Shevchenko
2022-09-05 21:43         ` Russell King (Oracle)
2022-09-05 13:27       ` Linus Walleij
2022-09-06  7:00     ` Hector Martin
2022-09-06  7:47       ` Russell King (Oracle)
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-10-27 15:35 ` Russell King (Oracle)
2022-11-08 16:32 ` [PATCH v3 0/7] " Russell King (Oracle)
2022-11-08 16:33   ` [PATCH v3 1/7] mfd: Add core Apple Mac SMC driver Russell King
2022-11-14  9:52     ` Lee Jones
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-14 15:34     ` Petr Mladek
2022-11-14 15:46       ` Andy Shevchenko
2022-11-14 16:18         ` Petr Mladek
2022-11-14 16:15       ` Russell King (Oracle)
2022-11-14 16:46         ` Russell King (Oracle)
2022-11-22 12:43         ` 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 20:42     ` Linus Walleij
2022-11-08 20:55     ` Krzysztof Kozlowski
2022-11-08 22:22       ` Russell King (Oracle)
2022-11-09  8:35         ` Krzysztof Kozlowski
2022-11-09 22:17         ` Rob Herring
2022-11-10 11:35           ` Hector Martin
2022-11-10 11:48           ` Russell King (Oracle)
2022-11-10 14:00             ` Krzysztof Kozlowski
2022-11-10 14:14               ` Russell King (Oracle)
2022-11-10 14:21                 ` Krzysztof Kozlowski
2022-11-10 14:23                   ` Russell King (Oracle)
2022-11-10 14:36                     ` Krzysztof Kozlowski
2022-11-10 14:43                       ` Russell King (Oracle)
2022-11-14 10:05           ` Lee Jones
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   ` [PATCH v3 5/7] arm64: dts: apple: Add SMC node to t8103 devicetrees 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 20:56     ` Krzysztof Kozlowski
2022-11-08 22:09       ` Russell King (Oracle)
2022-11-09  7:31         ` Hector Martin
2022-11-09  8:36         ` Krzysztof Kozlowski
2022-11-09  9:12           ` Russell King (Oracle)
2022-11-09  9:19             ` Krzysztof Kozlowski
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).