[PATCH v6 08/11] input: raspberrypi-ts: Release firmware handle when not needed

[Nicolas Saenz Julienne]

There is no use for the firmware interface after getting the touch
buffer address, so release it.

Signed-off-by: Nicolas Saenz Julienne 
Acked-by: Dmitry Torokhov 
---

Changes since v5:
 - Correct commit message

Changes since v3:
 - Release firmware handle in probe function

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/raspberrypi-ts.c 
b/drivers/input/touchscreen/raspberrypi-ts.c
index ef6aaed217cf..5000f5fd9ec3 100644
--- a/drivers/input/touchscreen/raspberrypi-ts.c
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -160,7 +160,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
touchbuf = (u32)ts->fw_regs_phys;
error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
  , sizeof(touchbuf));
-
+   rpi_firmware_put(fw);
if (error || touchbuf != 0) {
dev_warn(dev, "Failed to set touchbuf, %d\n", error);
return error;
-- 
2.29.2

[PATCH v6 05/11] reset: raspberrypi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Florian Fainelli 
---
 drivers/reset/reset-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-raspberrypi.c 
b/drivers/reset/reset-raspberrypi.c
index 02f59c06f69b..fa23db554bcf 100644
--- a/drivers/reset/reset-raspberrypi.c
+++ b/drivers/reset/reset-raspberrypi.c
@@ -82,7 +82,7 @@ static int rpi_reset_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(np);
+   fw = devm_rpi_firmware_get(>dev, np);
of_node_put(np);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v6 07/11] staging: vchiq: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Florian Fainelli 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index f500a7043805..6c196cade4a0 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2732,7 +2732,7 @@ static int vchiq_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   drvdata->fw = rpi_firmware_get(fw_node);
+   drvdata->fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!drvdata->fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v6 11/11] pwm: Add Raspberry Pi Firmware based PWM bus

[Nicolas Saenz Julienne]

Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v3:
 - Rename compatible string to be more explicit WRT to bus's limitations

Changes since v2:
 - Use devm_rpi_firmware_get()
 - Rename driver
 - Small cleanups

Changes since v1:
 - Use default pwm bindings and get rid of xlate() function
 - Correct spelling errors
 - Correct apply() function
 - Round values
 - Fix divisions in arm32 mode
 - Small cleanups

 drivers/pwm/Kconfig   |   9 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047ac..75e2344703b3 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -423,6 +423,15 @@ config PWM_PXA
  To compile this driver as a module, choose M here: the module
  will be called pwm-pxa.
 
+config PWM_RASPBERRYPI_POE
+   tristate "Raspberry Pi Firwmware PoE Hat PWM support"
+   # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+   # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+   depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
+   help
+ Enable Raspberry Pi firmware controller PWM bus used to control the
+ official RPI PoE hat
+
 config PWM_RCAR
tristate "Renesas R-Car PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092..ed28d7bd4c64 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
+obj-$(CONFIG_PWM_RASPBERRYPI_POE)  += pwm-raspberrypi-poe.o
 obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
diff --git a/drivers/pwm/pwm-raspberrypi-poe.c 
b/drivers/pwm/pwm-raspberrypi-poe.c
new file mode 100644
index ..24b498839fcc
--- /dev/null
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Nicolas Saenz Julienne 
+ * For more information on Raspberry Pi's PoE hat see:
+ * https://www.raspberrypi.org/products/poe-hat/
+ *
+ * Limitations:
+ *  - No disable bit, so a disabled PWM is simulated by duty_cycle 0
+ *  - Only normal polarity
+ *  - Fixed 12.5 kHz period
+ *
+ * The current period is completed when HW is reconfigured.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define RPI_PWM_MAX_DUTY   255
+#define RPI_PWM_PERIOD_NS  8 /* 12.5 kHz */
+
+#define RPI_PWM_CUR_DUTY_REG   0x0
+#define RPI_PWM_DEF_DUTY_REG   0x1
+
+struct raspberrypi_pwm {
+   struct rpi_firmware *firmware;
+   struct pwm_chip chip;
+   unsigned int duty_cycle;
+};
+
+struct raspberrypi_pwm_prop {
+   __le32 reg;
+   __le32 val;
+   __le32 ret;
+} __packed;
+
+static inline struct raspberrypi_pwm *to_raspberrypi_pwm(struct pwm_chip *chip)
+{
+   return container_of(chip, struct raspberrypi_pwm, chip);
+}
+
+static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
+   u32 reg, u32 val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = cpu_to_le32(reg),
+   .val = cpu_to_le32(val),
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
+   u32 reg, u32 *val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = reg
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   *val = le32_to_cpu(msg.val);
+
+   return 0;
+}
+
+static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct raspberrypi_pwm *rpipwm = to_raspberrypi_pwm(chip);
+
+   state->period = RPI_PWM_PERIOD_NS;
+   state->duty_cycle = DI

[PATCH v6 02/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

It'll simplify the firmware handling for most consumers.

Suggested-by: Bartosz Golaszewski 
Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Florian Fainelli 
---

Changes since v4:
 - Rearrange function calls for clarity, same functionality

Changes since v2:
- Create devm_rpi_firmware_get()

 drivers/firmware/raspberrypi.c | 29 ++
 include/soc/bcm2835/raspberrypi-firmware.h |  8 ++
 2 files changed, 37 insertions(+)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index b65e4c495772..250e01680742 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -243,6 +243,13 @@ void rpi_firmware_put(struct rpi_firmware *fw)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_put);
 
+static void devm_rpi_firmware_put(void *data)
+{
+   struct rpi_firmware *fw = data;
+
+   rpi_firmware_put(fw);
+}
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -331,6 +338,28 @@ struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
+/**
+ * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
+ * @firmware_node:Pointer to the firmware Device Tree node.
+ *
+ * Returns NULL is the firmware device is not ready.
+ */
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node)
+{
+   struct rpi_firmware *fw;
+
+   fw = rpi_firmware_get(firmware_node);
+   if (!fw)
+   return NULL;
+
+   if (devm_add_action_or_reset(dev, devm_rpi_firmware_put, fw))
+   return NULL;
+
+   return fw;
+}
+EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
+
 static const struct of_device_id rpi_firmware_of_match[] = {
{ .compatible = "raspberrypi,bcm2835-firmware", },
{},
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index fdfef7fe40df..73ad784fca96 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -142,6 +142,8 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
 void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
void *data, size_t len)
@@ -160,6 +162,12 @@ static inline struct rpi_firmware *rpi_firmware_get(struct 
device_node *firmware
 {
return NULL;
 }
+
+static inline struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+   struct device_node *firmware_node)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __SOC_RASPBERRY_FIRMWARE_H__ */
-- 
2.29.2

[PATCH v6 04/11] gpio: raspberrypi-exp: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Florian Fainelli 
Acked-by: Bartosz Golaszewski 
---
 drivers/gpio/gpio-raspberrypi-exp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-raspberrypi-exp.c 
b/drivers/gpio/gpio-raspberrypi-exp.c
index bb100e0124e6..64a552ecc2ad 100644
--- a/drivers/gpio/gpio-raspberrypi-exp.c
+++ b/drivers/gpio/gpio-raspberrypi-exp.c
@@ -208,7 +208,7 @@ static int rpi_exp_gpio_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(fw_node);
+   fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v6 01/11] firmware: raspberrypi: Keep count of all consumers

[Nicolas Saenz Julienne]

When unbinding the firmware device we need to make sure it has no
consumers left. Otherwise we'd leave them with a firmware handle
pointing at freed memory.

Keep a reference count of all consumers and introduce rpi_firmware_put()
which will permit automatically decrease the reference count upon
unbinding consumer drivers.

Suggested-by: Uwe Kleine-König 
Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Florian Fainelli 

---
Changes since v5:
 - Add comment to avoid people blindly switching the memory allocation
   to the devm variant.
 - Fix function documentation as per Florian's comment.

 Changes since v3:
- Use kref instead of waiting on refcount

 drivers/firmware/raspberrypi.c | 40 --
 include/soc/bcm2835/raspberrypi-firmware.h |  2 ++
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 30259dc9b805..b65e4c495772 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,8 @@ struct rpi_firmware {
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+
+   struct kref consumers;
 };
 
 static DEFINE_MUTEX(transaction_lock);
@@ -225,12 +228,31 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
 }
 
+static void rpi_firmware_delete(struct kref *kref)
+{
+   struct rpi_firmware *fw = container_of(kref, struct rpi_firmware,
+  consumers);
+
+   mbox_free_channel(fw->chan);
+   kfree(fw);
+}
+
+void rpi_firmware_put(struct rpi_firmware *fw)
+{
+   kref_put(>consumers, rpi_firmware_delete);
+}
+EXPORT_SYMBOL_GPL(rpi_firmware_put);
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct rpi_firmware *fw;
 
-   fw = devm_kzalloc(dev, sizeof(*fw), GFP_KERNEL);
+   /*
+* Memory will be freed by rpi_firmware_delete() once all users have
+* released their firmware handles. Don't use devm_kzalloc() here.
+*/
+   fw = kzalloc(sizeof(*fw), GFP_KERNEL);
if (!fw)
return -ENOMEM;
 
@@ -247,6 +269,7 @@ static int rpi_firmware_probe(struct platform_device *pdev)
}
 
init_completion(>c);
+   kref_init(>consumers);
 
platform_set_drvdata(pdev, fw);
 
@@ -275,7 +298,8 @@ static int rpi_firmware_remove(struct platform_device *pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
-   mbox_free_channel(fw->chan);
+
+   rpi_firmware_put(fw);
 
return 0;
 }
@@ -284,16 +308,26 @@ static int rpi_firmware_remove(struct platform_device 
*pdev)
  * rpi_firmware_get - Get pointer to rpi_firmware structure.
  * @firmware_node:Pointer to the firmware Device Tree node.
  *
+ * The reference to rpi_firmware has to be released with rpi_firmware_put().
+ *
  * Returns NULL is the firmware device is not ready.
  */
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
 {
struct platform_device *pdev = of_find_device_by_node(firmware_node);
+   struct rpi_firmware *fw;
 
if (!pdev)
return NULL;
 
-   return platform_get_drvdata(pdev);
+   fw = platform_get_drvdata(pdev);
+   if (!fw)
+   return NULL;
+
+   if (!kref_get_unless_zero(>consumers))
+   return NULL;
+
+   return fw;
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index cc9cdbc66403..fdfef7fe40df 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -140,6 +140,7 @@ int rpi_firmware_property(struct rpi_firmware *fw,
  u32 tag, void *data, size_t len);
 int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
+void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
@@ -154,6 +155,7 @@ static inline int rpi_firmware_property_list(struct 
rpi_firmware *fw,
return -ENOSYS;
 }
 
+static inline void rpi_firmware_put(struct rpi_firmware *fw) { }
 static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 {
return NULL;
-- 
2.29.2

[PATCH v6 00/11] Raspberry Pi PoE HAT fan support

[Nicolas Saenz Julienne]

The aim of this series is to add support to the fan found on RPi's PoE
HAT. Some commentary on the design can be found below. But the imporant
part to the people CC'd here not involved with PWM is that, in order to
achieve this properly, we also have to fix the firmware interface the
driver uses to communicate with the PWM bus (and many other low level
functions). Specifically, we have to make sure the firmware interface
isn't unbound while consumers are still up. So, patch #1 & #2 introduce
reference counting in the firwmware interface driver and patches #3 to
#8 update all firmware users. Patches #9 to #11 introduce the new PWM
driver.

I sent everything as a single series as the final version of the PWM
drivers depends on the firwmare fixes, but I'll be happy to split this
into two separate series if you think it's better.

--- Original cover letter below ---

This series aims at adding support to RPi's official PoE HAT fan[1].

The HW setup is the following:

| Raspberry Pi   | PoE HAT|
 arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN

The arm cores have only access to the mailbox interface, as i2c0, even if
physically accessible, is to be used solely by the co-processor
(VideoCore 4/6).

This series implements a PWM bus, and has pwm-fan sitting on top of it as per
this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has a
series of shortcomings:

- It depends on a DT binding: it's not flexible if a new hat shows up with new
  functionality, we're not 100% sure we'll be able to expand it without
  breaking backwards compatibility. But without it we can't make use of DT
  thermal-zones, which IMO is overkill.

- We're using pwm-fan, writing a hwmon driver would, again, give us more
  flexibility, but it's not really needed at the moment.

I personally think that it's not worth the effort, it's unlikely we'll get
things right in advance. And ultimately, if the RPi people come up with
something new, we can always write a new driver/bindings from scratch (as in
not reusing previous code).

That said, I'm more than happy to change things if there is a consensus that
another design will do the trick.

[1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/

---

Changes since v5:
 - Small cleanups
 - Add extra code comments

Changes since v4:
 - Cleanup devm calls
 - Rename compatible string so it's unique to the PoE HAT

Changes since v3:
 - Split first patch, #1 introduces refcount, then #2 the devm function
 - Fix touchscreen function
 - Use kref

Changes since v2:
 - Introduce devm_rpi_firmware_get()
 - Small cleanups in PWM driver

Changes since v1:
 - Address PWM driver changes
 - Fix binding, now with 2 cells

Nicolas Saenz Julienne (11):
  firmware: raspberrypi: Keep count of all consumers
  firmware: raspberrypi: Introduce devm_rpi_firmware_get()
  clk: bcm: rpi: Release firmware handle on unbind
  gpio: raspberrypi-exp: Release firmware handle on unbind
  reset: raspberrypi: Release firmware handle on unbind
  soc: bcm: raspberrypi-power: Release firmware handle on unbind
  staging: vchiq: Release firmware handle on unbind
  input: raspberrypi-ts: Release firmware handle when not needed
  dt-bindings: pwm: Add binding for RPi firmware PWM bus
  DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support
  pwm: Add Raspberry Pi Firmware based PWM bus

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml |  20 ++
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  54 +
 drivers/clk/bcm/clk-raspberrypi.c |   2 +-
 drivers/firmware/raspberrypi.c|  69 +-
 drivers/gpio/gpio-raspberrypi-exp.c   |   2 +-
 drivers/input/touchscreen/raspberrypi-ts.c|   2 +-
 drivers/pwm/Kconfig   |   9 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 drivers/reset/reset-raspberrypi.c |   2 +-
 drivers/soc/bcm/raspberrypi-power.c   |   2 +-
 .../interface/vchiq_arm/vchiq_arm.c   |   2 +-
 .../pwm/raspberrypi,firmware-poe-pwm.h|  13 ++
 include/soc/bcm2835/raspberrypi-firmware.h|  10 +
 14 files changed, 395 insertions(+), 9 deletions(-)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h

-- 
2.29.2

Re: [PATCH -next] thermal: broadcom: simplify the return expression of bcm2711_thermal_probe()

[Nicolas Saenz Julienne]

On Thu, 2020-12-10 at 21:54 +0800, Zheng Yongjun wrote:
> Simplify the return expression.
> 
> Signed-off-by: Zheng Yongjun 

Reviewed-by: Nicolas Saenz Julienne 

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 11/11] pwm: Add Raspberry Pi Firmware based PWM bus

[Nicolas Saenz Julienne]

Hi All,

On Mon, 2020-11-23 at 19:38 +0100, Nicolas Saenz Julienne wrote:
> Adds support to control the PWM bus available in official Raspberry Pi
> PoE HAT. Only RPi's co-processor has access to it, so commands have to
> be sent through RPi's firmware mailbox interface.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> 

I'll soon send a v6 of this series and was wondering if there is any more
feedback for this patch.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 08/11] input: raspberrypi-ts: Release firmware handle when not needed

[Nicolas Saenz Julienne]

On Tue, 2020-12-01 at 22:03 -0800, Dmitry Torokhov wrote:
> Hi Nicolas,
> 
> On Mon, Nov 23, 2020 at 07:38:29PM +0100, Nicolas Saenz Julienne wrote:
> > Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> > interface when unbinding the device.
> 
> I do not believe this comment is correct any longer. Otherwise:
> 
> Acked-by: Dmitry Torokhov 

Yes, sorry for that. I'll update it.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 01/11] firmware: raspberrypi: Keep count of all consumers

[Nicolas Saenz Julienne]

On Thu, 2020-12-03 at 09:05 +0100, Bartosz Golaszewski wrote:
> On Mon, Nov 23, 2020 at 7:38 PM Nicolas Saenz Julienne
>  wrote:
> > 
> > When unbinding the firmware device we need to make sure it has no
> > consumers left. Otherwise we'd leave them with a firmware handle
> > pointing at freed memory.
> > 
> > Keep a reference count of all consumers and introduce rpi_firmware_put()
> > which will permit automatically decrease the reference count upon
> > unbinding consumer drivers.
> > 
> > Suggested-by: Uwe Kleine-König 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> > 
> > Changes since v3:
> > - Use kref instead of waiting on refcount
> > 
> >  drivers/firmware/raspberrypi.c | 37 +++---
> >  include/soc/bcm2835/raspberrypi-firmware.h |  2 ++
> >  2 files changed, 35 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> > index 30259dc9b805..ed793aef7851 100644
> > --- a/drivers/firmware/raspberrypi.c
> > +++ b/drivers/firmware/raspberrypi.c
> > @@ -7,6 +7,7 @@
> >   */
> > 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -27,6 +28,8 @@ struct rpi_firmware {
> > struct mbox_chan *chan; /* The property channel. */
> > struct completion c;
> > u32 enabled;
> > +
> > +   struct kref consumers;
> >  };
> > 
> >  static DEFINE_MUTEX(transaction_lock);
> > @@ -225,12 +228,27 @@ static void rpi_register_clk_driver(struct device 
> > *dev)
> > -1, NULL, 0);
> >  }
> > 
> > +static void rpi_firmware_delete(struct kref *kref)
> > +{
> > +   struct rpi_firmware *fw = container_of(kref, struct rpi_firmware,
> > +  consumers);
> > +
> > +   mbox_free_channel(fw->chan);
> > +   kfree(fw);
> > +}
> > +
> > +void rpi_firmware_put(struct rpi_firmware *fw)
> > +{
> > +   kref_put(>consumers, rpi_firmware_delete);
> > +}
> > +EXPORT_SYMBOL_GPL(rpi_firmware_put);
> > +
> >  static int rpi_firmware_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = >dev;
> > struct rpi_firmware *fw;
> > 
> > -   fw = devm_kzalloc(dev, sizeof(*fw), GFP_KERNEL);
> 
> One nit from my side: maybe add a comment here saying that you really
> want to use non-managed kzalloc() because you're going to get people
> blindly converting it to devm_kzalloc() very soon.

Good point, I'll change it.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

[PATCH] clk: bcm: dvp: Add MODULE_DEVICE_TABLE()

[Nicolas Saenz Julienne]

Add MODULE_DEVICE_TABLE() so as to be able to use the driver as a
module. More precisely, for the driver to be loaded automatically at
boot.

Fixes: 1bc95972715a ("clk: bcm: Add BCM2711 DVP driver")
Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/clk/bcm/clk-bcm2711-dvp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c 
b/drivers/clk/bcm/clk-bcm2711-dvp.c
index 8333e20dc9d2..69e2f85f7029 100644
--- a/drivers/clk/bcm/clk-bcm2711-dvp.c
+++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
@@ -108,6 +108,7 @@ static const struct of_device_id clk_dvp_dt_ids[] = {
{ .compatible = "brcm,brcm2711-dvp", },
{ /* sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, clk_dvp_dt_ids);
 
 static struct platform_driver clk_dvp_driver = {
.probe  = clk_dvp_probe,
-- 
2.29.2

[PATCH v5 04/11] gpio: raspberrypi-exp: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
Acked-by: Bartosz Golaszewski 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/gpio/gpio-raspberrypi-exp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-raspberrypi-exp.c 
b/drivers/gpio/gpio-raspberrypi-exp.c
index bb100e0124e6..64a552ecc2ad 100644
--- a/drivers/gpio/gpio-raspberrypi-exp.c
+++ b/drivers/gpio/gpio-raspberrypi-exp.c
@@ -208,7 +208,7 @@ static int rpi_exp_gpio_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(fw_node);
+   fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v5 05/11] reset: raspberrypi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/reset/reset-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-raspberrypi.c 
b/drivers/reset/reset-raspberrypi.c
index 02f59c06f69b..fa23db554bcf 100644
--- a/drivers/reset/reset-raspberrypi.c
+++ b/drivers/reset/reset-raspberrypi.c
@@ -82,7 +82,7 @@ static int rpi_reset_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(np);
+   fw = devm_rpi_firmware_get(>dev, np);
of_node_put(np);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v5 08/11] input: raspberrypi-ts: Release firmware handle when not needed

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v3:
 - Release firmware handle in probe function

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/raspberrypi-ts.c 
b/drivers/input/touchscreen/raspberrypi-ts.c
index ef6aaed217cf..5000f5fd9ec3 100644
--- a/drivers/input/touchscreen/raspberrypi-ts.c
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -160,7 +160,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
touchbuf = (u32)ts->fw_regs_phys;
error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
  , sizeof(touchbuf));
-
+   rpi_firmware_put(fw);
if (error || touchbuf != 0) {
dev_warn(dev, "Failed to set touchbuf, %d\n", error);
return error;
-- 
2.29.2

[PATCH v5 09/11] dt-bindings: pwm: Add binding for RPi firmware PWM bus

[Nicolas Saenz Julienne]

The PWM bus controlling the fan in RPi's official PoE hat can only be
controlled by the board's co-processor.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---

Changes since v4:
 - Rename compatible string to be more explicit with the bus' limitations

Changes since v3:
 - Fix example

Changes since v1:
 - Update bindings to use 2 #pwm-cells

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 +++
 .../pwm/raspberrypi,firmware-poe-pwm.h| 13 
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a2c63c8b1d10..e3664eab0f6a 100644
--- 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -64,6 +64,21 @@ properties:
   - compatible
   - "#reset-cells"
 
+  pwm:
+type: object
+
+properties:
+  compatible:
+const: raspberrypi,firmware-poe-pwm
+
+  "#pwm-cells":
+# See pwm.yaml in this directory for a description of the cells format.
+const: 2
+
+required:
+  - compatible
+  - "#pwm-cells"
+
 additionalProperties: false
 
 required:
@@ -87,5 +102,10 @@ examples:
 compatible = "raspberrypi,firmware-reset";
 #reset-cells = <1>;
 };
+
+pwm: pwm {
+compatible = "raspberrypi,firmware-poe-pwm";
+#pwm-cells = <2>;
+};
 };
 ...
diff --git a/include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h 
b/include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h
new file mode 100644
index ..27c5ce68847b
--- /dev/null
+++ b/include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne 
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+
+#define RASPBERRYPI_FIRMWARE_PWM_POE   0
+#define RASPBERRYPI_FIRMWARE_PWM_NUM   1
+
+#endif
-- 
2.29.2

[PATCH v5 11/11] pwm: Add Raspberry Pi Firmware based PWM bus

[Nicolas Saenz Julienne]

Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v3:
 - Rename compatible string to be more explicit WRT to bus's limitations

Changes since v2:
 - Use devm_rpi_firmware_get()
 - Rename driver
 - Small cleanups

Changes since v1:
 - Use default pwm bindings and get rid of xlate() function
 - Correct spelling errors
 - Correct apply() function
 - Round values
 - Fix divisions in arm32 mode
 - Small cleanups

 drivers/pwm/Kconfig   |   9 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047ac..75e2344703b3 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -423,6 +423,15 @@ config PWM_PXA
  To compile this driver as a module, choose M here: the module
  will be called pwm-pxa.
 
+config PWM_RASPBERRYPI_POE
+   tristate "Raspberry Pi Firwmware PoE Hat PWM support"
+   # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+   # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+   depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
+   help
+ Enable Raspberry Pi firmware controller PWM bus used to control the
+ official RPI PoE hat
+
 config PWM_RCAR
tristate "Renesas R-Car PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092..ed28d7bd4c64 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
+obj-$(CONFIG_PWM_RASPBERRYPI_POE)  += pwm-raspberrypi-poe.o
 obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
diff --git a/drivers/pwm/pwm-raspberrypi-poe.c 
b/drivers/pwm/pwm-raspberrypi-poe.c
new file mode 100644
index ..24b498839fcc
--- /dev/null
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Nicolas Saenz Julienne 
+ * For more information on Raspberry Pi's PoE hat see:
+ * https://www.raspberrypi.org/products/poe-hat/
+ *
+ * Limitations:
+ *  - No disable bit, so a disabled PWM is simulated by duty_cycle 0
+ *  - Only normal polarity
+ *  - Fixed 12.5 kHz period
+ *
+ * The current period is completed when HW is reconfigured.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define RPI_PWM_MAX_DUTY   255
+#define RPI_PWM_PERIOD_NS  8 /* 12.5 kHz */
+
+#define RPI_PWM_CUR_DUTY_REG   0x0
+#define RPI_PWM_DEF_DUTY_REG   0x1
+
+struct raspberrypi_pwm {
+   struct rpi_firmware *firmware;
+   struct pwm_chip chip;
+   unsigned int duty_cycle;
+};
+
+struct raspberrypi_pwm_prop {
+   __le32 reg;
+   __le32 val;
+   __le32 ret;
+} __packed;
+
+static inline struct raspberrypi_pwm *to_raspberrypi_pwm(struct pwm_chip *chip)
+{
+   return container_of(chip, struct raspberrypi_pwm, chip);
+}
+
+static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
+   u32 reg, u32 val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = cpu_to_le32(reg),
+   .val = cpu_to_le32(val),
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
+   u32 reg, u32 *val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = reg
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   *val = le32_to_cpu(msg.val);
+
+   return 0;
+}
+
+static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct raspberrypi_pwm *rpipwm = to_raspberrypi_pwm(chip);
+
+   state->period = RPI_PWM_PERIOD_NS;
+   state->duty_cycle = DI

[PATCH v5 10/11] DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support

[Nicolas Saenz Julienne]

This is an example on how to enable the fan on top of RPi's official PoE
hat.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v1:
 - Update patch to use 2 pwm cells

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 403bacf986eb..9ae44620c5b8 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -5,6 +5,7 @@
 #include "bcm283x-rpi-usb-peripheral.dtsi"
 
 #include 
+#include 
 
 / {
compatible = "raspberrypi,4-model-b", "brcm,bcm2711";
@@ -68,6 +69,54 @@ sd_vcc_reg: sd_vcc_reg {
enable-active-high;
gpio = < 6 GPIO_ACTIVE_HIGH>;
};
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 50 150 255>;
+   #cooling-cells = <2>;
+   pwms = < RASPBERRYPI_FIRMWARE_PWM_POE 8>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   trips {
+   threshold: trip-point@0 {
+   temperature = <45000>;
+   hysteresis = <5000>;
+   type = "active";
+   };
+
+   target: trip-point@1 {
+   temperature = <5>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+
+   cpu_hot: cpu_hot@0 {
+   temperature = <55000>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 0 1>;
+   };
+
+   map1 {
+   trip = <>;
+   cooling-device = < 1 2>;
+   };
+
+   map2 {
+   trip = <_hot>;
+   cooling-device = < 2 3>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -103,6 +152,11 @@ reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
};
+
+   fwpwm: pwm {
+   compatible = "raspberrypi,firmware-poe-pwm";
+   #pwm-cells = <2>;
+   };
 };
 
  {
-- 
2.29.2

[PATCH v5 07/11] staging: vchiq: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index f500a7043805..6c196cade4a0 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2732,7 +2732,7 @@ static int vchiq_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   drvdata->fw = rpi_firmware_get(fw_node);
+   drvdata->fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!drvdata->fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v5 03/11] clk: bcm: rpi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/clk/bcm/clk-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index f89b9cfc4309..dd3b71eafabf 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -314,7 +314,7 @@ static int raspberrypi_clk_probe(struct platform_device 
*pdev)
return -ENOENT;
}
 
-   firmware = rpi_firmware_get(firmware_node);
+   firmware = devm_rpi_firmware_get(>dev, firmware_node);
of_node_put(firmware_node);
if (!firmware)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v5 02/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

It'll simplify the firmware handling for most consumers.

Suggested-by: Bartosz Golaszewski 
Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v4:
 - Rearrange function calls for clarity, same functionality

Changes since v2:
- Create devm_rpi_firmware_get()

 drivers/firmware/raspberrypi.c | 29 ++
 include/soc/bcm2835/raspberrypi-firmware.h |  8 ++
 2 files changed, 37 insertions(+)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index ed793aef7851..e2a5f6f59357 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -243,6 +243,13 @@ void rpi_firmware_put(struct rpi_firmware *fw)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_put);
 
+static void devm_rpi_firmware_put(void *data)
+{
+   struct rpi_firmware *fw = data;
+
+   rpi_firmware_put(fw);
+}
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -326,6 +333,28 @@ struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
+/**
+ * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
+ * @firmware_node:Pointer to the firmware Device Tree node.
+ *
+ * Returns NULL is the firmware device is not ready.
+ */
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node)
+{
+   struct rpi_firmware *fw;
+
+   fw = rpi_firmware_get(firmware_node);
+   if (!fw)
+   return NULL;
+
+   if (devm_add_action_or_reset(dev, devm_rpi_firmware_put, fw))
+   return NULL;
+
+   return fw;
+}
+EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
+
 static const struct of_device_id rpi_firmware_of_match[] = {
{ .compatible = "raspberrypi,bcm2835-firmware", },
{},
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index fdfef7fe40df..73ad784fca96 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -142,6 +142,8 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
 void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
void *data, size_t len)
@@ -160,6 +162,12 @@ static inline struct rpi_firmware *rpi_firmware_get(struct 
device_node *firmware
 {
return NULL;
 }
+
+static inline struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+   struct device_node *firmware_node)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __SOC_RASPBERRY_FIRMWARE_H__ */
-- 
2.29.2

[PATCH v5 06/11] soc: bcm: raspberrypi-power: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/soc/bcm/raspberrypi-power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/bcm/raspberrypi-power.c 
b/drivers/soc/bcm/raspberrypi-power.c
index 5d1aacdd84ef..068715d6e66d 100644
--- a/drivers/soc/bcm/raspberrypi-power.c
+++ b/drivers/soc/bcm/raspberrypi-power.c
@@ -177,7 +177,7 @@ static int rpi_power_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   rpi_domains->fw = rpi_firmware_get(fw_np);
+   rpi_domains->fw = devm_rpi_firmware_get(>dev, fw_np);
of_node_put(fw_np);
if (!rpi_domains->fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v5 00/11] Raspberry Pi PoE HAT fan support

[Nicolas Saenz Julienne]

The aim of this series is to add support to the fan found on RPi's PoE
HAT. Some commentary on the design can be found below. But the imporant
part to the people CC'd here not involved with PWM is that, in order to
achieve this properly, we also have to fix the firmware interface the
driver uses to communicate with the PWM bus (and many other low level
functions). Specifically, we have to make sure the firmware interface
isn't unbound while consumers are still up. So, patch #1 & #2 introduce
reference counting in the firwmware interface driver and patches #3 to
#8 update all firmware users. Patches #9 to #11 introduce the new PWM
driver.

I sent everything as a single series as the final version of the PWM
drivers depends on the firwmare fixes, but I'll be happy to split this
into two separate series if you think it's better.

--- Original cover letter below ---

This series aims at adding support to RPi's official PoE HAT fan[1].

The HW setup is the following:

| Raspberry Pi   | PoE HAT|
 arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN

The arm cores have only access to the mailbox interface, as i2c0, even if
physically accessible, is to be used solely by the co-processor
(VideoCore 4/6).

This series implements a PWM bus, and has pwm-fan sitting on top of it as per
this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has a
series of shortcomings:

- It depends on a DT binding: it's not flexible if a new hat shows up with new
  functionality, we're not 100% sure we'll be able to expand it without
  breaking backwards compatibility. But without it we can't make use of DT
  thermal-zones, which IMO is overkill.

- We're using pwm-fan, writing a hwmon driver would, again, give us more
  flexibility, but it's not really needed at the moment.

I personally think that it's not worth the effort, it's unlikely we'll get
things right in advance. And ultimately, if the RPi people come up with
something new, we can always write a new driver/bindings from scratch (as in
not reusing previous code).

That said, I'm more than happy to change things if there is a consensus that
another design will do the trick.

[1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/

---

Changes since v4:
 - Cleanup devm calls
 - Rename compatible string so it's unique to the PoE HAT

Changes since v3:
 - Split first patch, #1 introduces refcount, then #2 the devm function
 - Fix touchscreen function
 - Use kref

Changes since v2:
 - Introduce devm_rpi_firmware_get()
 - Small cleanups in PWM driver

Changes since v1:
 - Address PWM driver changes
 - Fix binding, now with 2 cells

Nicolas Saenz Julienne (11):
  firmware: raspberrypi: Keep count of all consumers
  firmware: raspberrypi: Introduce devm_rpi_firmware_get()
  clk: bcm: rpi: Release firmware handle on unbind
  gpio: raspberrypi-exp: Release firmware handle on unbind
  reset: raspberrypi: Release firmware handle on unbind
  soc: bcm: raspberrypi-power: Release firmware handle on unbind
  staging: vchiq: Release firmware handle on unbind
  input: raspberrypi-ts: Release firmware handle when not needed
  dt-bindings: pwm: Add binding for RPi firmware PWM bus
  DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support
  pwm: Add Raspberry Pi Firmware based PWM bus

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml |  20 ++
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  54 +
 drivers/clk/bcm/clk-raspberrypi.c |   2 +-
 drivers/firmware/raspberrypi.c|  66 +-
 drivers/gpio/gpio-raspberrypi-exp.c   |   2 +-
 drivers/input/touchscreen/raspberrypi-ts.c|   2 +-
 drivers/pwm/Kconfig   |   9 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 drivers/reset/reset-raspberrypi.c |   2 +-
 drivers/soc/bcm/raspberrypi-power.c   |   2 +-
 .../interface/vchiq_arm/vchiq_arm.c   |   2 +-
 .../pwm/raspberrypi,firmware-poe-pwm.h|  13 ++
 include/soc/bcm2835/raspberrypi-firmware.h|  10 +
 14 files changed, 391 insertions(+), 10 deletions(-)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h

-- 
2.29.2

[PATCH v5 01/11] firmware: raspberrypi: Keep count of all consumers

[Nicolas Saenz Julienne]

When unbinding the firmware device we need to make sure it has no
consumers left. Otherwise we'd leave them with a firmware handle
pointing at freed memory.

Keep a reference count of all consumers and introduce rpi_firmware_put()
which will permit automatically decrease the reference count upon
unbinding consumer drivers.

Suggested-by: Uwe Kleine-König 
Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v3:
- Use kref instead of waiting on refcount

 drivers/firmware/raspberrypi.c | 37 +++---
 include/soc/bcm2835/raspberrypi-firmware.h |  2 ++
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 30259dc9b805..ed793aef7851 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,8 @@ struct rpi_firmware {
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+
+   struct kref consumers;
 };
 
 static DEFINE_MUTEX(transaction_lock);
@@ -225,12 +228,27 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
 }
 
+static void rpi_firmware_delete(struct kref *kref)
+{
+   struct rpi_firmware *fw = container_of(kref, struct rpi_firmware,
+  consumers);
+
+   mbox_free_channel(fw->chan);
+   kfree(fw);
+}
+
+void rpi_firmware_put(struct rpi_firmware *fw)
+{
+   kref_put(>consumers, rpi_firmware_delete);
+}
+EXPORT_SYMBOL_GPL(rpi_firmware_put);
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct rpi_firmware *fw;
 
-   fw = devm_kzalloc(dev, sizeof(*fw), GFP_KERNEL);
+   fw = kzalloc(sizeof(*fw), GFP_KERNEL);
if (!fw)
return -ENOMEM;
 
@@ -247,6 +265,7 @@ static int rpi_firmware_probe(struct platform_device *pdev)
}
 
init_completion(>c);
+   kref_init(>consumers);
 
platform_set_drvdata(pdev, fw);
 
@@ -275,25 +294,35 @@ static int rpi_firmware_remove(struct platform_device 
*pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
-   mbox_free_channel(fw->chan);
+
+   rpi_firmware_put(fw);
 
return 0;
 }
 
 /**
- * rpi_firmware_get - Get pointer to rpi_firmware structure.
  * @firmware_node:Pointer to the firmware Device Tree node.
  *
+ * The reference to rpi_firmware has to be released with rpi_firmware_put().
+ *
  * Returns NULL is the firmware device is not ready.
  */
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
 {
struct platform_device *pdev = of_find_device_by_node(firmware_node);
+   struct rpi_firmware *fw;
 
if (!pdev)
return NULL;
 
-   return platform_get_drvdata(pdev);
+   fw = platform_get_drvdata(pdev);
+   if (!fw)
+   return NULL;
+
+   if (!kref_get_unless_zero(>consumers))
+   return NULL;
+
+   return fw;
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index cc9cdbc66403..fdfef7fe40df 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -140,6 +140,7 @@ int rpi_firmware_property(struct rpi_firmware *fw,
  u32 tag, void *data, size_t len);
 int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
+void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
@@ -154,6 +155,7 @@ static inline int rpi_firmware_property_list(struct 
rpi_firmware *fw,
return -ENOSYS;
 }
 
+static inline void rpi_firmware_put(struct rpi_firmware *fw) { }
 static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 {
return NULL;
-- 
2.29.2

Re: [PATCH v4 01/11] firmware: raspberrypi: Keep count of all consumers

[Nicolas Saenz Julienne]

On Thu, 2020-11-12 at 23:26 -0800, Dmitry Torokhov wrote:
> On Thu, Nov 12, 2020 at 07:52:14PM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 12, 2020 at 6:40 PM Nicolas Saenz Julienne
> >  wrote:
> > > 
> > > When unbinding the firmware device we need to make sure it has no
> > > consumers left. Otherwise we'd leave them with a firmware handle
> > > pointing at freed memory.
> > > 
> > > Keep a reference count of all consumers and introduce rpi_firmware_put()
> > > which will permit automatically decrease the reference count upon
> > > unbinding consumer drivers.
> > 
> > ...
> > 
> > >  /**
> > > - * rpi_firmware_get - Get pointer to rpi_firmware structure.
> > >   * @firmware_node:Pointer to the firmware Device Tree node.
> > >   *
> > > + * The reference to rpi_firmware has to be released with 
> > > rpi_firmware_put().
> > > + *
> > >   * Returns NULL is the firmware device is not ready.
> > >   */
> > >  struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
> > >  {
> > > struct platform_device *pdev = 
> > > of_find_device_by_node(firmware_node);
> > > +   struct rpi_firmware *fw;
> > > 
> > > if (!pdev)
> > > return NULL;
> > > 
> > > -   return platform_get_drvdata(pdev);
> > > +   fw = platform_get_drvdata(pdev);
> > > +   if (!fw)
> > > +   return NULL;
> > > +
> > > +   if (!kref_get_unless_zero(>consumers))
> > > +   return NULL;
> > 

Hi Andy, Dimitry,

> > Don't we have a more traditional way of doing this, i.e.
> > try_module_get() coupled with get_device() ?
> 
> get_device() will make sure that device is there, but gives no
> assurances that device is bound to a driver, so it will not help with
> the racy access to firmware via platform_get_drvdata() call.

I also looked at using get/put_device() just as a means for refcounting (i.e.
replacing fw->consumers), but I can't make it work either. I'd need a way to
hook up into one of the struct device_ktype release() functions. AFAIK it's not
possible for private uses like this.

IIUC the way to do this would be to bypass platform device and create a special
device class/bus for RPi's firmware dependent devices (I could pretty much copy
SCMI's implementation), but I fear that's overkill.

So, for now I'll stick with the kref based implementation, I'll be happy to
change it if you find a better solution. :)

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

[GIT PULL 1/1] bcm2835-dt-next-2020-11-20

[Nicolas Saenz Julienne]

Hi Florian,

The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/nsaenz/linux-rpi.git 
tags/bcm2835-dt-next-2020-11-20

for you to fetch changes up to 278407a53c3b33fb820332c4d39eb39316c3879a:

  ARM: dts: bcm283x: increase dwc2's RX FIFO size (2020-11-20 17:43:10 +0100)


- Maxime introduces a quirk to avoid EMI between WiFi and HDMI@1440p on
RPi4b.

- Pavel fixes dwc2's fifo size to properly support isochronous
transfers.


Maxime Ripard (1):
  ARM: dts: rpi-4: disable wifi frequencies

Pavel Hofman (1):
  ARM: dts: bcm283x: increase dwc2's RX FIFO size

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
 arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi| 2 +-
 arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

Re: [PATCH v5 2/2] spi: Add generic SPI multiplexer

[Nicolas Saenz Julienne]

On Tue, 2020-11-17 at 00:08 +, Chris Packham wrote:
> On 14/11/20 4:46 am, Nicolas Saenz Julienne wrote:
> > Upon registering spi-mux's devices through spi_add_device() the kernel gets
> > stuck waiting for the 'spi_add_lock' mutex to be released. The mutex 
> > happens to
> > be held by spi-mux's parent SPI bus, which unluckily, is waiting for 
> > spi-mux's
> > probe to finish before releasing it.
> 
> I just re-tested my system with v5.10.0-rc4 and didn't see any problem. 
> My dts is pretty similar to yours the only obvious thing missing is 
> `mux-control-names = "spi";` and I also set `#size-cells = <1>;` (let me 
> know if you want me to post the whole thing).
> 
> It might be dependent on the host spi controller. The re-test I just did 
> was on a board using the spi-orion.c driver and I tested my original 
> change on a board using spi-bcm-qspi.c (I haven't got the board handy 
> right now but I could go and find one if necessary).

Found the issue, something silly on my side. Sorry for the noise.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

[PATCH v7 2/7] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

[Nicolas Saenz Julienne]

zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
---
 arch/arm64/mm/init.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index fafdf992fd32..0954ea736987 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -190,6 +190,8 @@ static void __init zone_sizes_init(unsigned long min, 
unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
 
 #ifdef CONFIG_ZONE_DMA
+   zone_dma_bits = ARM64_ZONE_DMA_BITS;
+   arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
 #ifdef CONFIG_ZONE_DMA32
@@ -379,11 +381,6 @@ void __init arm64_memblock_init(void)
 
early_init_fdt_scan_reserved_mem();
 
-   if (IS_ENABLED(CONFIG_ZONE_DMA)) {
-   zone_dma_bits = ARM64_ZONE_DMA_BITS;
-   arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
-   }
-
if (IS_ENABLED(CONFIG_ZONE_DMA32))
arm64_dma32_phys_limit = max_zone_phys(32);
else
-- 
2.29.2

[PATCH v7 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

[Nicolas Saenz Julienne]

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

The DMA layer also needs to be able to allocate memory that is
guaranteed to meet those DMA constraints, for bounce buffering as well
as allocating the backing for consistent mappings. This is why the 1 GB
ZONE_DMA was introduced recently. Unfortunately, it turns out the having
a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and
potentially in other places where allocations cannot cross zone
boundaries. Therefore, we should avoid having two separate DMA zones
when possible.

So, with the help of of_dma_get_max_cpu_address() get the topmost
physical address accessible to all DMA masters in system and use that
information to fine-tune ZONE_DMA's size. In the absence of addressing
limited masters ZONE_DMA will span the whole 32-bit address space,
otherwise, in the case of the Raspberry Pi 4 it'll only span the 30-bit
address space, and have ZONE_DMA32 cover the rest of the 32-bit address
space.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v4:
 - Use fls64 as we're now using the max address (as opposed to the
   limit)

Changes since v3:
 - Simplify code for readability.

Changes since v2:
 - Updated commit log by shamelessly copying Ard's ACPI commit log

 arch/arm64/mm/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 0954ea736987..a96d3fbbd12c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -42,8 +42,6 @@
 #include 
 #include 
 
-#define ARM64_ZONE_DMA_BITS30
-
 /*
  * We need to be able to catch inadvertent references to memstart_addr
  * that occur (potentially in generic code) before arm64_memblock_init()
@@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int 
zone_bits)
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+   unsigned int __maybe_unused dt_zone_dma_bits;
 
 #ifdef CONFIG_ZONE_DMA
-   zone_dma_bits = ARM64_ZONE_DMA_BITS;
+   dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
+   zone_dma_bits = min(32U, dt_zone_dma_bits);
arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
-- 
2.29.2

[PATCH v7 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

crashkernel might reserve memory located in ZONE_DMA. We plan to delay
ZONE_DMA's initialization after unflattening the devicetree and ACPI's
boot table initialization, so move it later in the boot process.
Specifically into bootmem_init() since request_standard_resources()
depends on it.

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 

---

Changes since v6:
 - Move crashkernel reserve placement earlier, in bootmem_init()

 arch/arm64/mm/init.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 71d463544400..fafdf992fd32 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -389,8 +389,6 @@ void __init arm64_memblock_init(void)
else
arm64_dma32_phys_limit = PHYS_MASK + 1;
 
-   reserve_crashkernel();
-
reserve_elfcorehdr();
 
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
@@ -430,6 +428,12 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
 
+   /*
+* request_standard_resources() depends on crashkernel's memory being
+* reserved, so do it here.
+*/
+   reserve_crashkernel();
+
memblock_dump_all();
 }
 
-- 
2.29.2

[PATCH v7 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan

[Nicolas Saenz Julienne]

From: Ard Biesheuvel 

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

Instructing the DMA layer about these limitations is straight-forward,
even though we had to fix some issues regarding memory limits set in
the IORT for named components, and regarding the handling of ACPI _DMA
methods. However, the DMA layer also needs to be able to allocate
memory that is guaranteed to meet those DMA constraints, for bounce
buffering as well as allocating the backing for consistent mappings.

This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
problems with kdump, and potentially in other places where allocations
cannot cross zone boundaries. Therefore, we should avoid having two
separate DMA zones when possible.

So let's do an early scan of the IORT, and only create the ZONE_DMA
if we encounter any devices that need it. This puts the burden on
the firmware to describe such limitations in the IORT, which may be
redundant (and less precise) if _DMA methods are also being provided.
However, it should be noted that this situation is highly unusual for
arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
the _DMA method if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.

Cc: Jeremy Linton 
Cc: Lorenzo Pieralisi 
Cc: Nicolas Saenz Julienne 
Cc: Rob Herring 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: Hanjun Guo 
Cc: Sudeep Holla 
Cc: Anshuman Khandual 
Signed-off-by: Ard Biesheuvel 
[nsaenz: unified implementation with DT's counterpart]
Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
Acked-by: Lorenzo Pieralisi 
Acked-by: Hanjun Guo 

---

Changes since v3:
 - Use min_not_zero()
 - Check revision
 - Remove unnecessary #ifdef in zone_sizes_init()

 arch/arm64/mm/init.c  |  5 +++-
 drivers/acpi/arm64/iort.c | 55 +++
 include/linux/acpi_iort.h |  4 +++
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index a96d3fbbd12c..99741ba63cb8 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -186,11 +187,13 @@ static phys_addr_t __init max_zone_phys(unsigned int 
zone_bits)
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+   unsigned int __maybe_unused acpi_zone_dma_bits;
unsigned int __maybe_unused dt_zone_dma_bits;
 
 #ifdef CONFIG_ZONE_DMA
+   acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
-   zone_dma_bits = min(32U, dt_zone_dma_bits);
+   zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9929ff50c0c0..1787406684aa 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1718,3 +1718,58 @@ void __init acpi_iort_init(void)
 
iort_init_platform_devices();
 }
+
+#ifdef CONFIG_ZONE_DMA
+/*
+ * Extract the highest CPU physical address accessible to all DMA masters in
+ * the system. PHYS_ADDR_MAX is returned when no constrained device is found.
+ */
+phys_addr_t __init acpi_iort_dma_get_max_cpu_address(void)
+{
+   phys_addr_t limit = PHYS_ADDR_MAX;
+   struct acpi_iort_node *node, *end;
+   struct acpi_table_iort *iort;
+   acpi_status status;
+   int i;
+
+   if (acpi_disabled)
+   return limit;
+
+   status = acpi_get_table(ACPI_SIG_IORT, 0,
+   (struct acpi_table_header **));
+   if (ACPI_FAILURE(status))
+   return limit;
+
+   node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset);
+   end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length);
+
+   for (i = 0; i < iort->node_count; i++) {
+   if (node >= end)
+   break;
+
+   switch (node->type) {
+   struct acpi_iort_named_component *ncomp;
+   struct acpi_iort_root_complex *rc;
+   phys_addr_t local_limit;
+
+   case ACPI_IORT_NODE_NAMED_COMPONENT:
+   ncomp = (struct acpi_iort_named_component 
*)node->node_data;
+   local_limit = DMA_BIT_MASK(ncomp->memory_address_limit);
+   

[PATCH v7 4/7] of: unittest: Add test for of_dma_get_max_cpu_address()

[Nicolas Saenz Julienne]

Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---
Changes since v5:
- Update address expected by test

Changes since v3:
 - Remove HAS_DMA guards

 drivers/of/unittest.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 06cc988faf78..98cc0163301b 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -869,6 +869,23 @@ static void __init of_unittest_changeset(void)
 #endif
 }
 
+static void __init of_unittest_dma_get_max_cpu_address(void)
+{
+   struct device_node *np;
+   phys_addr_t cpu_addr;
+
+   np = of_find_node_by_path("/testcase-data/address-tests");
+   if (!np) {
+   pr_err("missing testcase data\n");
+   return;
+   }
+
+   cpu_addr = of_dma_get_max_cpu_address(np);
+   unittest(cpu_addr == 0x4fff,
+"of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting 
%x)\n",
+_addr, 0x4fff);
+}
+
 static void __init of_unittest_dma_ranges_one(const char *path,
u64 expect_dma_addr, u64 expect_paddr)
 {
@@ -3266,6 +3283,7 @@ static int __init of_unittest(void)
of_unittest_changeset();
of_unittest_parse_interrupts();
of_unittest_parse_interrupts_extended();
+   of_unittest_dma_get_max_cpu_address();
of_unittest_parse_dma_ranges();
of_unittest_pci_dma_ranges();
of_unittest_match_node();
-- 
2.29.2

[PATCH v7 3/7] of/address: Introduce of_dma_get_max_cpu_address()

[Nicolas Saenz Julienne]

Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---

Changes since v4:
 - Return max address, not address limit (one off difference)

Changes since v3:
 - use u64 with cpu_end

Changes since v2:
 - Use PHYS_ADDR_MAX
 - return phys_dma_t
 - Rename function
 - Correct subject
 - Add support to start parsing from an arbitrary device node in order
   for the function to work with unit tests

 drivers/of/address.c | 42 ++
 include/linux/of.h   |  7 +++
 2 files changed, 49 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 1c3257a2d4e3..73ddf2540f3f 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -1024,6 +1024,48 @@ int of_dma_get_range(struct device_node *np, const 
struct bus_dma_region **map)
 }
 #endif /* CONFIG_HAS_DMA */
 
+/**
+ * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
+ * @np: The node to start searching from or NULL to start from the root
+ *
+ * Gets the highest CPU physical address that is addressable by all DMA masters
+ * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
+ * DMA constrained device is found, it returns PHYS_ADDR_MAX.
+ */
+phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
+{
+   phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
+   struct of_range_parser parser;
+   phys_addr_t subtree_max_addr;
+   struct device_node *child;
+   struct of_range range;
+   const __be32 *ranges;
+   u64 cpu_end = 0;
+   int len;
+
+   if (!np)
+   np = of_root;
+
+   ranges = of_get_property(np, "dma-ranges", );
+   if (ranges && len) {
+   of_dma_range_parser_init(, np);
+   for_each_of_range(, )
+   if (range.cpu_addr + range.size > cpu_end)
+   cpu_end = range.cpu_addr + range.size - 1;
+
+   if (max_cpu_addr > cpu_end)
+   max_cpu_addr = cpu_end;
+   }
+
+   for_each_available_child_of_node(np, child) {
+   subtree_max_addr = of_dma_get_max_cpu_address(child);
+   if (max_cpu_addr > subtree_max_addr)
+   max_cpu_addr = subtree_max_addr;
+   }
+
+   return max_cpu_addr;
+}
+
 /**
  * of_dma_is_coherent - Check if device is coherent
  * @np:device node
diff --git a/include/linux/of.h b/include/linux/of.h
index 5d51891cbf1a..9ed5b8532c30 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u32 id,
   const char *map_name, const char *map_mask_name,
   struct device_node **target, u32 *id_out);
 
+phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
+
 #else /* CONFIG_OF */
 
 static inline void of_core_init(void)
@@ -995,6 +997,11 @@ static inline int of_map_id(struct device_node *np, u32 id,
return -EINVAL;
 }
 
+static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
+{
+   return PHYS_ADDR_MAX;
+}
+
 #define of_match_ptr(_ptr) NULL
 #define of_match_node(_matches, _node) NULL
 #endif /* CONFIG_OF */
-- 
2.29.2

[PATCH v7 7/7] mm: Remove examples from enum zone_type comment

[Nicolas Saenz Julienne]

We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Christoph Hellwig 
---
 include/linux/mmzone.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 8b074e2ba12c..15132adaa233 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -355,26 +355,6 @@ enum zone_type {
 * DMA mask is assumed when ZONE_DMA32 is defined. Some 64-bit
 * platforms may need both zones as they support peripherals with
 * different DMA addressing limitations.
-*
-* Some examples:
-*
-*  - i386 and x86_64 have a fixed 16M ZONE_DMA and ZONE_DMA32 for the
-*rest of the lower 4G.
-*
-*  - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
-*the specific device.
-*
-*  - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
-*lower 4G.
-*
-*  - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
-*depending on the specific device.
-*
-*  - s390 uses ZONE_DMA fixed to the lower 2G.
-*
-*  - ia64 and riscv only use ZONE_DMA32.
-*
-*  - parisc uses neither.
 */
 #ifdef CONFIG_ZONE_DMA
ZONE_DMA,
-- 
2.29.2

[PATCH v7 0/7] arm64: Default to 32-bit wide ZONE_DMA

[Nicolas Saenz Julienne]

Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.

I tested this on both a RPi4 and QEMU.

---

Changes since v6:
 - Update patch #1 so we reserve crashkernel before request_standard_resources()
 - Tested on top of Catalin's mem_init() patches.

Changes since v5:
 - Unify ACPI/DT functions

Changes since v4:
 - Fix of_dma_get_max_cpu_address() so it returns the last addressable
   addres, not the limit

Changes since v3:
 - Drop patch adding define in dma-mapping
 - Address small review changes
 - Update Ard's patch
 - Add new patch removing examples from mmzone.h

Changes since v2:
 - Introduce Ard's patch
 - Improve OF dma-ranges parsing function
 - Add unit test for OF function
 - Address small changes
 - Move crashkernel reservation later in boot process

Changes since v1:
 - Parse dma-ranges instead of using machine compatible string

Ard Biesheuvel (1):
  arm64: mm: Set ZONE_DMA size based on early IORT scan

Nicolas Saenz Julienne (6):
  arm64: mm: Move reserve_crashkernel() into mem_init()
  arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
  of/address: Introduce of_dma_get_max_cpu_address()
  of: unittest: Add test for of_dma_get_max_cpu_address()
  arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
  mm: Remove examples from enum zone_type comment

 arch/arm64/mm/init.c  | 22 +---
 drivers/acpi/arm64/iort.c | 55 +++
 drivers/of/address.c  | 42 ++
 drivers/of/unittest.c | 18 +
 include/linux/acpi_iort.h |  4 +++
 include/linux/mmzone.h| 20 --
 include/linux/of.h|  7 +
 7 files changed, 139 insertions(+), 29 deletions(-)

-- 
2.29.2

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

On Thu, 2020-11-19 at 17:10 +, Catalin Marinas wrote:
> On Thu, Nov 19, 2020 at 03:09:58PM +0100, Nicolas Saenz Julienne wrote:
> > On Fri, 2020-11-13 at 11:29 +, Catalin Marinas wrote:
> > [...]
> > > > > > Let me stress that knowing the DMA constraints in the system before 
> > > > > > reserving
> > > > > > crashkernel's regions is necessary if we ever want it to work 
> > > > > > seamlessly on all
> > > > > > platforms. Be it small stuff like the Raspberry Pi or huge servers 
> > > > > > with TB of
> > > > > > memory.
> > > > > 
> > > > > Indeed. So we have 3 options (so far):
> > > > > 
> > > > > 1. Allow the crashkernel reservation to go into the linear map but set
> > > > >it to invalid once allocated.
> > > > > 
> > > > > 2. Parse the flattened DT (not sure what we do with ACPI) before
> > > > >creating the linear map. We may have to rely on some SoC ID here
> > > > >instead of actual DMA ranges.
> > > > > 
> > > > > 3. Assume the smallest ZONE_DMA possible on arm64 (1GB) for 
> > > > > crashkernel
> > > > >reservations and not rely on arm64_dma_phys_limit in
> > > > >reserve_crashkernel().
> > > > > 
> > > > > I think (2) we tried hard to avoid. Option (3) brings us back to the
> > > > > issues we had on large crashkernel reservations regressing on some
> > > > > platforms (though it's been a while since, they mostly went quiet ;)).
> > > > > However, with Chen's crashkernel patches we end up with two
> > > > > reservations, one in the low DMA zone and one higher, potentially 
> > > > > above
> > > > > 4GB. Having a fixed 1GB limit wouldn't be any worse for crashkernel
> > > > > reservations than what we have now.
> > > > > 
> > > > > If (1) works, I'd go for it (James knows this part better than me),
> > > > > otherwise we can go for (3).
> > > > 
> > > > Overall, I'd prefer (1) as well, and I'd be happy to have a got at it. 
> > > > If not
> > > > I'll append (3) in this series.
> > > 
> > > I think for 1 we could also remove the additional KEXEC_CORE checks,
> > > something like below, untested:
> > > 
> > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > index 3e5a6913acc8..27ab609c1c0c 100644
> > > --- a/arch/arm64/mm/mmu.c
> > > +++ b/arch/arm64/mm/mmu.c
> > > @@ -477,7 +477,8 @@ static void __init map_mem(pgd_t *pgdp)
> > >   int flags = 0;
> > >   u64 i;
> > >  
> > > - if (rodata_full || debug_pagealloc_enabled())
> > > + if (rodata_full || debug_pagealloc_enabled() ||
> > > + IS_ENABLED(CONFIG_KEXEC_CORE))
> > >   flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> > >  
> > >   /*
> > > @@ -487,11 +488,6 @@ static void __init map_mem(pgd_t *pgdp)
> > >* the following for-loop
> > >*/
> > >   memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
> > > -#ifdef CONFIG_KEXEC_CORE
> > > - if (crashk_res.end)
> > > - memblock_mark_nomap(crashk_res.start,
> > > - resource_size(_res));
> > > -#endif
> > >  
> > >   /* map all the memory banks */
> > >   for_each_mem_range(i, , ) {
> > > @@ -518,21 +514,6 @@ static void __init map_mem(pgd_t *pgdp)
> > >   __map_memblock(pgdp, kernel_start, kernel_end,
> > >  PAGE_KERNEL, NO_CONT_MAPPINGS);
> > >   memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
> > > -
> > > -#ifdef CONFIG_KEXEC_CORE
> > > - /*
> > > -  * Use page-level mappings here so that we can shrink the region
> > > -  * in page granularity and put back unused memory to buddy system
> > > -  * through /sys/kernel/kexec_crash_size interface.
> > > -  */
> > > - if (crashk_res.end) {
> > > - __map_memblock(pgdp, crashk_res.start, crashk_res.end + 1,
> > > -PAGE_KERNEL,
> > > -NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
> > > - memblock_clear_nomap(crashk_res.start,
> > > -  resource_size(_res));
> > > - }
> > > -#endif
> > >  }
> > >  
> > >  void m

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

Hi Catalin, James,
sorry for the late reply but I got sidetracked.

On Fri, 2020-11-13 at 11:29 +, Catalin Marinas wrote:
[...]
> > > > Let me stress that knowing the DMA constraints in the system before 
> > > > reserving
> > > > crashkernel's regions is necessary if we ever want it to work 
> > > > seamlessly on all
> > > > platforms. Be it small stuff like the Raspberry Pi or huge servers with 
> > > > TB of
> > > > memory.
> > > 
> > > Indeed. So we have 3 options (so far):
> > > 
> > > 1. Allow the crashkernel reservation to go into the linear map but set
> > >it to invalid once allocated.
> > > 
> > > 2. Parse the flattened DT (not sure what we do with ACPI) before
> > >creating the linear map. We may have to rely on some SoC ID here
> > >instead of actual DMA ranges.
> > > 
> > > 3. Assume the smallest ZONE_DMA possible on arm64 (1GB) for crashkernel
> > >reservations and not rely on arm64_dma_phys_limit in
> > >reserve_crashkernel().
> > > 
> > > I think (2) we tried hard to avoid. Option (3) brings us back to the
> > > issues we had on large crashkernel reservations regressing on some
> > > platforms (though it's been a while since, they mostly went quiet ;)).
> > > However, with Chen's crashkernel patches we end up with two
> > > reservations, one in the low DMA zone and one higher, potentially above
> > > 4GB. Having a fixed 1GB limit wouldn't be any worse for crashkernel
> > > reservations than what we have now.
> > > 
> > > If (1) works, I'd go for it (James knows this part better than me),
> > > otherwise we can go for (3).
> > 
> > Overall, I'd prefer (1) as well, and I'd be happy to have a got at it. If 
> > not
> > I'll append (3) in this series.
> 
> I think for 1 we could also remove the additional KEXEC_CORE checks,
> something like below, untested:
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 3e5a6913acc8..27ab609c1c0c 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -477,7 +477,8 @@ static void __init map_mem(pgd_t *pgdp)
>   int flags = 0;
>   u64 i;
>  
> - if (rodata_full || debug_pagealloc_enabled())
> + if (rodata_full || debug_pagealloc_enabled() ||
> + IS_ENABLED(CONFIG_KEXEC_CORE))
>   flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
>  
>   /*
> @@ -487,11 +488,6 @@ static void __init map_mem(pgd_t *pgdp)
>* the following for-loop
>*/
>   memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
> -#ifdef CONFIG_KEXEC_CORE
> - if (crashk_res.end)
> - memblock_mark_nomap(crashk_res.start,
> - resource_size(_res));
> -#endif
>  
>   /* map all the memory banks */
>   for_each_mem_range(i, , ) {
> @@ -518,21 +514,6 @@ static void __init map_mem(pgd_t *pgdp)
>   __map_memblock(pgdp, kernel_start, kernel_end,
>  PAGE_KERNEL, NO_CONT_MAPPINGS);
>   memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
> -
> -#ifdef CONFIG_KEXEC_CORE
> - /*
> -  * Use page-level mappings here so that we can shrink the region
> -  * in page granularity and put back unused memory to buddy system
> -  * through /sys/kernel/kexec_crash_size interface.
> -  */
> - if (crashk_res.end) {
> - __map_memblock(pgdp, crashk_res.start, crashk_res.end + 1,
> -PAGE_KERNEL,
> -NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
> - memblock_clear_nomap(crashk_res.start,
> -  resource_size(_res));
> - }
> -#endif
>  }
>  
>  void mark_rodata_ro(void)

So as far as I'm concerned this is good enough for me. I took the time to
properly test crashkernel on RPi4 using the series, this patch, and another
small fix to properly update /proc/iomem.

I'll send v7 soon, but before, James (or anyone for that matter) any obvious
push-back to Catalin's solution?

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 2/2] spi: Add generic SPI multiplexer

[Nicolas Saenz Julienne]

Upon registering spi-mux's devices through spi_add_device() the kernel gets
stuck waiting for the 'spi_add_lock' mutex to be released. The mutex happens to
be held by spi-mux's parent SPI bus, which unluckily, is waiting for spi-mux's
probe to finish before releasing it.

I might aswell be doing something wrong. But so far I trust my DT
implementation:

 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_gpio7>;

spi@0 {
compatible = "spi-mux";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <1>;

mux-controls = <_mux>;

w5500@0 {
compatible = "wiznet,w5500";
reg = <0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
spi-max-frequency = <3000>;
};

spi-flash@1 {
compatible = "jedec,spi-nor";
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <1600>;
};
};
};

Regards,
Nicolas

Re: [PATCH v4 02/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

On Thu, 2020-11-12 at 18:25 +0100, Bartosz Golaszewski wrote:
> On Thu, Nov 12, 2020 at 5:44 PM Nicolas Saenz Julienne
>  wrote:
> > Itroduce devm_rpi_firmware_get(), it'll simplify the firmware handling
> > for most consumers.
> > 
> > Suggested-by: Bartosz Golaszewski 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> > 
> > Changes since v2:
> > - Introduce devm_rpi_firmware_get()
> > 
> >  drivers/firmware/raspberrypi.c | 31 +-
> >  include/soc/bcm2835/raspberrypi-firmware.h |  8 ++
> >  2 files changed, 38 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> > index 438e17074a97..4ab2dfdc82ad 100644
> > --- a/drivers/firmware/raspberrypi.c
> > +++ b/drivers/firmware/raspberrypi.c
> > @@ -237,10 +237,17 @@ static void rpi_firmware_delete(struct kref *kref)
> > kfree(fw);
> >  }
> > 
> > -void rpi_firmware_put(struct rpi_firmware *fw)
> > +static void __rpi_firmware_put(void *data)
> >  {
> 
> The '__' prefix is very vague and usually used for unlocked variants
> of functions. The casting to void * in rpi_firmware_put() is also
> unneeded. I would much prefer that the devres release callback be
> called devm_rpi_firmware_put() and that it call rpi_firmware_put()
> which would then call kref_put().

Yes, that's better. I'll change it.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

[PATCH v4 09/11] dt-bindings: pwm: Add binding for RPi firmware PWM bus

[Nicolas Saenz Julienne]

The PWM bus controlling the fan in RPi's official PoE hat can only be
controlled by the board's co-processor.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 
---

Changes since v3:
 - Fix example

Changes since v1:
 - Update bindings to use 2 #pwm-cells

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 +++
 .../pwm/raspberrypi,firmware-pwm.h| 13 
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-pwm.h

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a2c63c8b1d10..38be3ff69609 100644
--- 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -64,6 +64,21 @@ properties:
   - compatible
   - "#reset-cells"
 
+  pwm:
+type: object
+
+properties:
+  compatible:
+const: raspberrypi,firmware-pwm
+
+  "#pwm-cells":
+# See pwm.yaml in this directory for a description of the cells format.
+const: 2
+
+required:
+  - compatible
+  - "#pwm-cells"
+
 additionalProperties: false
 
 required:
@@ -87,5 +102,10 @@ examples:
 compatible = "raspberrypi,firmware-reset";
 #reset-cells = <1>;
 };
+
+pwm: pwm {
+compatible = "raspberrypi,firmware-pwm";
+#pwm-cells = <2>;
+};
 };
 ...
diff --git a/include/dt-bindings/pwm/raspberrypi,firmware-pwm.h 
b/include/dt-bindings/pwm/raspberrypi,firmware-pwm.h
new file mode 100644
index ..27c5ce68847b
--- /dev/null
+++ b/include/dt-bindings/pwm/raspberrypi,firmware-pwm.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne 
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+
+#define RASPBERRYPI_FIRMWARE_PWM_POE   0
+#define RASPBERRYPI_FIRMWARE_PWM_NUM   1
+
+#endif
-- 
2.29.2

[PATCH v4 11/11] pwm: Add Raspberry Pi Firmware based PWM bus

[Nicolas Saenz Julienne]

Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v2:
 - Use devm_rpi_firmware_get()
 - Rename driver
 - Small cleanups

Changes since v1:
 - Use default pwm bindings and get rid of xlate() function
 - Correct spelling errors
 - Correct apply() function
 - Round values
 - Fix divisions in arm32 mode
 - Small cleanups

 drivers/pwm/Kconfig   |   9 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b2a87fd7e8fb..3445984a5a50 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -409,6 +409,15 @@ config PWM_PXA
  To compile this driver as a module, choose M here: the module
  will be called pwm-pxa.
 
+config PWM_RASPBERRYPI_POE
+   tristate "Raspberry Pi Firwmware PoE Hat PWM support"
+   # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+   # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+   depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
+   help
+ Enable Raspberry Pi firmware controller PWM bus used to control the
+ official RPI PoE hat
+
 config PWM_RCAR
tristate "Renesas R-Car PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092..ed28d7bd4c64 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
+obj-$(CONFIG_PWM_RASPBERRYPI_POE)  += pwm-raspberrypi-poe.o
 obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
diff --git a/drivers/pwm/pwm-raspberrypi-poe.c 
b/drivers/pwm/pwm-raspberrypi-poe.c
new file mode 100644
index ..91cd826a36f3
--- /dev/null
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Nicolas Saenz Julienne 
+ * For more information on Raspberry Pi's PoE hat see:
+ * https://www.raspberrypi.org/products/poe-hat/
+ *
+ * Limitations:
+ *  - No disable bit, so a disabled PWM is simulated by duty_cycle 0
+ *  - Only normal polarity
+ *  - Fixed 12.5 kHz period
+ *
+ * The current period is completed when HW is reconfigured.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define RPI_PWM_MAX_DUTY   255
+#define RPI_PWM_PERIOD_NS  8 /* 12.5 kHz */
+
+#define RPI_PWM_CUR_DUTY_REG   0x0
+#define RPI_PWM_DEF_DUTY_REG   0x1
+
+struct raspberrypi_pwm {
+   struct rpi_firmware *firmware;
+   struct pwm_chip chip;
+   unsigned int duty_cycle;
+};
+
+struct raspberrypi_pwm_prop {
+   __le32 reg;
+   __le32 val;
+   __le32 ret;
+} __packed;
+
+static inline struct raspberrypi_pwm *to_raspberrypi_pwm(struct pwm_chip *chip)
+{
+   return container_of(chip, struct raspberrypi_pwm, chip);
+}
+
+static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
+   u32 reg, u32 val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = cpu_to_le32(reg),
+   .val = cpu_to_le32(val),
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
+   u32 reg, u32 *val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = reg
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   *val = le32_to_cpu(msg.val);
+
+   return 0;
+}
+
+static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct raspberrypi_pwm *rpipwm = to_raspberrypi_pwm(chip);
+
+   state->period = RPI_PWM_PERIOD_NS;
+   state->duty_cycle = DIV_ROUND_CLOSEST(rpipwm->duty_cycle * 
RPI_PWM_PERIOD_NS,
+

[PATCH v4 07/11] staging: vchiq: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index f500a7043805..6c196cade4a0 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2732,7 +2732,7 @@ static int vchiq_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   drvdata->fw = rpi_firmware_get(fw_node);
+   drvdata->fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!drvdata->fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v4 10/11] DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support

[Nicolas Saenz Julienne]

This is an example on how to enable the fan on top of RPi's official PoE
hat.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v1:
 - Update patch to use 2 pwm cells

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182c2936..361db82619a4 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -5,6 +5,7 @@
 #include "bcm283x-rpi-usb-peripheral.dtsi"
 
 #include 
+#include 
 
 / {
compatible = "raspberrypi,4-model-b", "brcm,bcm2711";
@@ -68,6 +69,54 @@ sd_vcc_reg: sd_vcc_reg {
enable-active-high;
gpio = < 6 GPIO_ACTIVE_HIGH>;
};
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 50 150 255>;
+   #cooling-cells = <2>;
+   pwms = < RASPBERRYPI_FIRMWARE_PWM_POE 8>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   trips {
+   threshold: trip-point@0 {
+   temperature = <45000>;
+   hysteresis = <5000>;
+   type = "active";
+   };
+
+   target: trip-point@1 {
+   temperature = <5>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+
+   cpu_hot: cpu_hot@0 {
+   temperature = <55000>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 0 1>;
+   };
+
+   map1 {
+   trip = <>;
+   cooling-device = < 1 2>;
+   };
+
+   map2 {
+   trip = <_hot>;
+   cooling-device = < 2 3>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -103,6 +152,11 @@ reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
};
+
+   fwpwm: pwm {
+   compatible = "raspberrypi,firmware-pwm";
+   #pwm-cells = <2>;
+   };
 };
 
  {
-- 
2.29.2

[PATCH v4 02/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

Itroduce devm_rpi_firmware_get(), it'll simplify the firmware handling
for most consumers.

Suggested-by: Bartosz Golaszewski 
Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v2:
- Introduce devm_rpi_firmware_get()

 drivers/firmware/raspberrypi.c | 31 +-
 include/soc/bcm2835/raspberrypi-firmware.h |  8 ++
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 438e17074a97..4ab2dfdc82ad 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -237,10 +237,17 @@ static void rpi_firmware_delete(struct kref *kref)
kfree(fw);
 }
 
-void rpi_firmware_put(struct rpi_firmware *fw)
+static void __rpi_firmware_put(void *data)
 {
+   struct rpi_firmware *fw = data;
+
kref_put(>consumers, rpi_firmware_delete);
 }
+
+void rpi_firmware_put(struct rpi_firmware *fw)
+{
+   __rpi_firmware_put(fw);
+}
 EXPORT_SYMBOL_GPL(rpi_firmware_put);
 
 static int rpi_firmware_probe(struct platform_device *pdev)
@@ -326,6 +333,28 @@ struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
+/**
+ * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
+ * @firmware_node:Pointer to the firmware Device Tree node.
+ *
+ * Returns NULL is the firmware device is not ready.
+ */
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node)
+{
+   struct rpi_firmware *fw;
+
+   fw = rpi_firmware_get(firmware_node);
+   if (!fw)
+   return NULL;
+
+   if (devm_add_action_or_reset(dev, __rpi_firmware_put, fw))
+   return NULL;
+
+   return fw;
+}
+EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
+
 static const struct of_device_id rpi_firmware_of_match[] = {
{ .compatible = "raspberrypi,bcm2835-firmware", },
{},
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index fdfef7fe40df..73ad784fca96 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -142,6 +142,8 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
 void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
void *data, size_t len)
@@ -160,6 +162,12 @@ static inline struct rpi_firmware *rpi_firmware_get(struct 
device_node *firmware
 {
return NULL;
 }
+
+static inline struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+   struct device_node *firmware_node)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __SOC_RASPBERRY_FIRMWARE_H__ */
-- 
2.29.2

[PATCH v4 05/11] reset: raspberrypi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/reset/reset-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-raspberrypi.c 
b/drivers/reset/reset-raspberrypi.c
index 02f59c06f69b..fa23db554bcf 100644
--- a/drivers/reset/reset-raspberrypi.c
+++ b/drivers/reset/reset-raspberrypi.c
@@ -82,7 +82,7 @@ static int rpi_reset_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(np);
+   fw = devm_rpi_firmware_get(>dev, np);
of_node_put(np);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v4 04/11] gpio: raspberrypi-exp: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
Acked-by: Bartosz Golaszewski 
---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/gpio/gpio-raspberrypi-exp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-raspberrypi-exp.c 
b/drivers/gpio/gpio-raspberrypi-exp.c
index bb100e0124e6..64a552ecc2ad 100644
--- a/drivers/gpio/gpio-raspberrypi-exp.c
+++ b/drivers/gpio/gpio-raspberrypi-exp.c
@@ -208,7 +208,7 @@ static int rpi_exp_gpio_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(fw_node);
+   fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v4 06/11] soc: bcm: raspberrypi-power: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/soc/bcm/raspberrypi-power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/bcm/raspberrypi-power.c 
b/drivers/soc/bcm/raspberrypi-power.c
index 5d1aacdd84ef..068715d6e66d 100644
--- a/drivers/soc/bcm/raspberrypi-power.c
+++ b/drivers/soc/bcm/raspberrypi-power.c
@@ -177,7 +177,7 @@ static int rpi_power_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   rpi_domains->fw = rpi_firmware_get(fw_np);
+   rpi_domains->fw = devm_rpi_firmware_get(>dev, fw_np);
of_node_put(fw_np);
if (!rpi_domains->fw)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v4 03/11] clk: bcm: rpi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/clk/bcm/clk-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index f89b9cfc4309..dd3b71eafabf 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -314,7 +314,7 @@ static int raspberrypi_clk_probe(struct platform_device 
*pdev)
return -ENOENT;
}
 
-   firmware = rpi_firmware_get(firmware_node);
+   firmware = devm_rpi_firmware_get(>dev, firmware_node);
of_node_put(firmware_node);
if (!firmware)
return -EPROBE_DEFER;
-- 
2.29.2

[PATCH v4 01/11] firmware: raspberrypi: Keep count of all consumers

[Nicolas Saenz Julienne]

When unbinding the firmware device we need to make sure it has no
consumers left. Otherwise we'd leave them with a firmware handle
pointing at freed memory.

Keep a reference count of all consumers and introduce rpi_firmware_put()
which will permit automatically decrease the reference count upon
unbinding consumer drivers.

Suggested-by: Uwe Kleine-König 
Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v3:
- Use kref instead of waiting on refcount

 drivers/firmware/raspberrypi.c | 37 +++---
 include/soc/bcm2835/raspberrypi-firmware.h |  2 ++
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 2371d08bdd17..438e17074a97 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,8 @@ struct rpi_firmware {
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+
+   struct kref consumers;
 };
 
 static DEFINE_MUTEX(transaction_lock);
@@ -225,12 +228,27 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
 }
 
+static void rpi_firmware_delete(struct kref *kref)
+{
+   struct rpi_firmware *fw = container_of(kref, struct rpi_firmware,
+  consumers);
+
+   mbox_free_channel(fw->chan);
+   kfree(fw);
+}
+
+void rpi_firmware_put(struct rpi_firmware *fw)
+{
+   kref_put(>consumers, rpi_firmware_delete);
+}
+EXPORT_SYMBOL_GPL(rpi_firmware_put);
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct rpi_firmware *fw;
 
-   fw = devm_kzalloc(dev, sizeof(*fw), GFP_KERNEL);
+   fw = kzalloc(sizeof(*fw), GFP_KERNEL);
if (!fw)
return -ENOMEM;
 
@@ -247,6 +265,7 @@ static int rpi_firmware_probe(struct platform_device *pdev)
}
 
init_completion(>c);
+   kref_init(>consumers);
 
platform_set_drvdata(pdev, fw);
 
@@ -275,25 +294,35 @@ static int rpi_firmware_remove(struct platform_device 
*pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
-   mbox_free_channel(fw->chan);
+
+   rpi_firmware_put(fw);
 
return 0;
 }
 
 /**
- * rpi_firmware_get - Get pointer to rpi_firmware structure.
  * @firmware_node:Pointer to the firmware Device Tree node.
  *
+ * The reference to rpi_firmware has to be released with rpi_firmware_put().
+ *
  * Returns NULL is the firmware device is not ready.
  */
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
 {
struct platform_device *pdev = of_find_device_by_node(firmware_node);
+   struct rpi_firmware *fw;
 
if (!pdev)
return NULL;
 
-   return platform_get_drvdata(pdev);
+   fw = platform_get_drvdata(pdev);
+   if (!fw)
+   return NULL;
+
+   if (!kref_get_unless_zero(>consumers))
+   return NULL;
+
+   return fw;
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index cc9cdbc66403..fdfef7fe40df 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -140,6 +140,7 @@ int rpi_firmware_property(struct rpi_firmware *fw,
  u32 tag, void *data, size_t len);
 int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
+void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
@@ -154,6 +155,7 @@ static inline int rpi_firmware_property_list(struct 
rpi_firmware *fw,
return -ENOSYS;
 }
 
+static inline void rpi_firmware_put(struct rpi_firmware *fw) { }
 static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 {
return NULL;
-- 
2.29.2

[PATCH v4 00/11] Raspberry Pi PoE HAT fan support

[Nicolas Saenz Julienne]

The aim of this series is to add support to the fan found on RPi's PoE
HAT. Some commentary on the design can be found below. But the imporant
part to the people CC'd here not involved with PWM is that, in order to
achieve this properly, we also have to fix the firmware interface the
driver uses to communicate with the PWM bus (and many other low level
functions). Specifically, we have to make sure the firmware interface
isn't unbound while consumers are still up. So, patch #1 & #2 introduce
reference counting in the firwmware interface driver and patches #3 to
#8 update all firmware users. Patches #9 to #11 introduce the new PWM
driver.

I sent everything as a single series as the final version of the PWM
drivers depends on the firwmare fixes, but I'll be happy to split this
into two separate series if you think it's better.

--- Original cover letter below ---

This series aims at adding support to RPi's official PoE HAT fan[1].

The HW setup is the following:

| Raspberry Pi   | PoE HAT|
 arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN

The arm cores have only access to the mailbox interface, as i2c0, even if
physically accessible, is to be used solely by the co-processor
(VideoCore 4/6).

This series implements a PWM bus, and has pwm-fan sitting on top of it as per
this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has a
series of shortcomings:

- It depends on a DT binding: it's not flexible if a new hat shows up with new
  functionality, we're not 100% sure we'll be able to expand it without
  breaking backwards compatibility. But without it we can't make use of DT
  thermal-zones, which IMO is overkill.

- We're using pwm-fan, writing a hwmon driver would, again, give us more
  flexibility, but it's not really needed at the moment.

I personally think that it's not worth the effort, it's unlikely we'll get
things right in advance. And ultimately, if the RPi people come up with
something new, we can always write a new driver/bindings from scratch (as in
not reusing previous code).

That said, I'm more than happy to change things if there is a consensus that
another design will do the trick.

[1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/

---

Changes since v3:
 - Split first patch, #1 introduces refcount, then #2 the devm function
 - Fix touchscreen function
 - Use kref

Changes since v2:
 - Introduce devm_rpi_firmware_get()
 - Small cleanups in PWM driver

Changes since v1:
 - Address PWM driver changes
 - Fix binding, now with 2 cells

Nicolas Saenz Julienne (11):
  firmware: raspberrypi: Keep count of all consumers
  firmware: raspberrypi: Introduce devm_rpi_firmware_get()
  clk: bcm: rpi: Release firmware handle on unbind
  gpio: raspberrypi-exp: Release firmware handle on unbind
  reset: raspberrypi: Release firmware handle on unbind
  soc: bcm: raspberrypi-power: Release firmware handle on unbind
  staging: vchiq: Release firmware handle on unbind
  input: raspberrypi-ts: Release firmware handle when not needed
  dt-bindings: pwm: Add binding for RPi firmware PWM bus
  DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support
  pwm: Add Raspberry Pi Firmware based PWM bus

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml |  20 ++
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  54 +
 drivers/clk/bcm/clk-raspberrypi.c |   2 +-
 drivers/firmware/raspberrypi.c|  66 +-
 drivers/gpio/gpio-raspberrypi-exp.c   |   2 +-
 drivers/input/touchscreen/raspberrypi-ts.c|   2 +-
 drivers/pwm/Kconfig   |   9 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 drivers/reset/reset-raspberrypi.c |   2 +-
 drivers/soc/bcm/raspberrypi-power.c   |   2 +-
 .../interface/vchiq_arm/vchiq_arm.c   |   2 +-
 .../pwm/raspberrypi,firmware-pwm.h|  13 ++
 include/soc/bcm2835/raspberrypi-firmware.h|  10 +
 14 files changed, 391 insertions(+), 10 deletions(-)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-pwm.h

-- 
2.29.2

[PATCH v4 08/11] input: raspberrypi-ts: Release firmware handle when not needed

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v3:
 - Release firmware handle in probe function

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/raspberrypi-ts.c 
b/drivers/input/touchscreen/raspberrypi-ts.c
index ef6aaed217cf..5000f5fd9ec3 100644
--- a/drivers/input/touchscreen/raspberrypi-ts.c
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -160,7 +160,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
touchbuf = (u32)ts->fw_regs_phys;
error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
  , sizeof(touchbuf));
-
+   rpi_firmware_put(fw);
if (error || touchbuf != 0) {
dev_warn(dev, "Failed to set touchbuf, %d\n", error);
return error;
-- 
2.29.2

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

Hi Catalin,

On Tue, 2020-11-10 at 18:17 +, Catalin Marinas wrote:
> On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote:
> > On Thu, 2020-11-05 at 16:11 +, James Morse wrote:
> > > On 03/11/2020 17:31, Nicolas Saenz Julienne wrote:
> > > > crashkernel might reserve memory located in ZONE_DMA. We plan to delay
> > > > ZONE_DMA's initialization after unflattening the devicetree and ACPI's
> > > > boot table initialization, so move it later in the boot process.
> > > > Specifically into mem_init(), this is the last place crashkernel will be
> > > > able to reserve the memory before the page allocator kicks in.
> > > > There
> > > > isn't any apparent reason for doing this earlier.
> > > 
> > > It's so that map_mem() can carve it out of the linear/direct map.
> > > This is so that stray writes from a crashing kernel can't accidentally 
> > > corrupt the kdump
> > > kernel. We depend on this if we continue with kdump, but failed to 
> > > offline all the other
> > > CPUs.
> > 
> > I presume here you refer to arch_kexec_protect_crashkres(), IIUC this will 
> > only
> > happen further down the line, after having loaded the kdump kernel image. 
> > But
> > it also depends on the mappings to be PAGE sized (flags == 
> > NO_BLOCK_MAPPINGS |
> > NO_CONT_MAPPINGS).
> 
> IIUC, arch_kexec_protect_crashkres() is only for the crashkernel image,
> not the whole reserved memory that the crashkernel will use. For the
> latter, we avoid the linear map by marking it as nomap in map_mem().

I'm not sure we're on the same page here, so sorry if this was already implied.

The crashkernel memory mapping is bypassed while preparing the linear mappings
but it is then mapped right away, with page granularity and !MTE.
See paging_init()->map_mem():

/*
 * Use page-level mappings here so that we can shrink the region
 * in page granularity and put back unused memory to buddy system
 * through /sys/kernel/kexec_crash_size interface.
 */
if (crashk_res.end) {
__map_memblock(pgdp, crashk_res.start, crashk_res.end + 1,
   PAGE_KERNEL,
   NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
memblock_clear_nomap(crashk_res.start,
 resource_size(_res));
}

IIUC the inconvenience here is that we need special mapping options for
crashkernel and updating those after having mapped that memory as regular
memory isn't possible/easy to do.

> > > We also depend on this when skipping the checksum code in purgatory, 
> > > which can be
> > > exceedingly slow.
> > 
> > This one I don't fully understand, so I'll lazily assume the prerequisite is
> > the same WRT how memory is mapped. :)
> > 
> > Ultimately there's also /sys/kernel/kexec_crash_size's handling. Same
> > prerequisite.
> > 
> > Keeping in mind acpi_table_upgrade() and unflatten_device_tree() depend on
> > having the linear mappings available.
> 
> So it looks like reserve_crashkernel() wants to reserve memory before
> setting up the linear map with the information about the DMA zones in
> place but that comes later when we can parse the firmware tables.
> 
> I wonder, instead of not mapping the crashkernel reservation, can we not
> do an arch_kexec_protect_crashkres() for the whole reservation after we
> created the linear map?

arch_kexec_protect_crashkres() depends on __change_memory_common() which
ultimately depends on the memory to be mapped with PAGE_SIZE pages. As I
comment above, the trick would work as long as there is as way to update the
linear mappings with whatever crashkernel needs later in the boot process.

> > Let me stress that knowing the DMA constraints in the system before 
> > reserving
> > crashkernel's regions is necessary if we ever want it to work seamlessly on 
> > all
> > platforms. Be it small stuff like the Raspberry Pi or huge servers with TB 
> > of
> > memory.
> 
> Indeed. So we have 3 options (so far):
> 
> 1. Allow the crashkernel reservation to go into the linear map but set
>it to invalid once allocated.
> 
> 2. Parse the flattened DT (not sure what we do with ACPI) before
>creating the linear map. We may have to rely on some SoC ID here
>instead of actual DMA ranges.
> 
> 3. Assume the smallest ZONE_DMA possible on arm64 (1GB) for crashkernel
>reservations and not rely on arm64_dma_phys_limit in
>reserve_crashkernel().
> 
> I think (2) we tried hard to avoid. Option (3) brings us back to the
> issues we had on large crashker

Re: [PATCH v3 07/11] input: raspberrypi-ts: Release firmware handle when not needed

[Nicolas Saenz Julienne]

On Wed, 2020-11-11 at 17:45 -0800, Dmitry Torokhov wrote:
> Hi Nicolas,
> 
> On Wed, Nov 04, 2020 at 11:39:33AM +0100, Nicolas Saenz Julienne wrote:
> > Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> > interface when unbinding the device.
> 
> Unless I am mistaken this driver does not really need the firmware
> structure past rpi_ts_probe(), and will be fine if it disappears earlier
> than unbind time.

Yes, I missed that. Will update it.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2] PCI: brcmstb: Fix race in removing chained IRQ handler

[Nicolas Saenz Julienne]

On Wed, 2020-11-11 at 22:53 +0100, Martin Kaiser wrote:
> Call irq_set_chained_handler_and_data() to clear the chained handler
> and the handler's data under irq_desc->lock.
> 
> See also 2cf5a03cb29d ("PCI/keystone: Fix race in installing chained
> IRQ handler").
> 
> Signed-off-by: Martin Kaiser 
> Acked-by: Florian Fainelli 
> ---

Acked-by: Nicolas Saenz Julienne 

Thanks!

> v2:
>  - rewrite the commit message to clarify that this is a bugfix
> 
>  drivers/pci/controller/pcie-brcmstb.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-brcmstb.c 
> b/drivers/pci/controller/pcie-brcmstb.c
> index bea86899bd5d..7c666f4deb47 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -606,8 +606,7 @@ static void brcm_msi_remove(struct brcm_pcie *pcie)
>  
>   if (!msi)
>   return;
> - irq_set_chained_handler(msi->irq, NULL);
> - irq_set_handler_data(msi->irq, NULL);
> + irq_set_chained_handler_and_data(msi->irq, NULL, NULL);
>   brcm_free_domains(msi);
>  }
>  



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 01/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

Hi Bartosz, thanks for the feedback.

On Thu, 2020-11-05 at 10:42 +0100, Bartosz Golaszewski wrote:
> On Thu, Nov 5, 2020 at 10:28 AM Nicolas Saenz Julienne
>  wrote:
> > Hi Bartosz, thanks for the review.
> > 
> > On Thu, 2020-11-05 at 10:13 +0100, Bartosz Golaszewski wrote:
> > > > +/**
> > > > + * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
> > > > + * @firmware_node:Pointer to the firmware Device Tree node.
> > > > + *
> > > > + * Returns NULL is the firmware device is not ready.
> > > > + */
> > > > +struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
> > > > +  struct device_node 
> > > > *firmware_node)
> > > > +{
> > > > +   struct platform_device *pdev = 
> > > > of_find_device_by_node(firmware_node);
> > > > +   struct rpi_firmware *fw;
> > > > +
> > > > +   if (!pdev)
> > > > +   return NULL;
> > > > +
> > > > +   fw = platform_get_drvdata(pdev);
> > > > +   if (!fw)
> > > > +   return NULL;
> > > > +
> > > > +   if (!refcount_inc_not_zero(>consumers))
> > > > +   return NULL;
> > > > +
> > > > +   if (devm_add_action_or_reset(dev, rpi_firmware_put, fw))
> > > > +   return NULL;
> > > > +
> > > > +   return fw;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
> > > 
> > > Usually I'd expect the devres variant to simply call
> > > rpi_firmware_get() and then schedule a release callback which would
> > > call whatever function is the release counterpart for it currently.
> > > Devres actions are for drivers which want to schedule some more
> > > unusual tasks at driver detach. Any reason for designing it this way?
> > 
> > Yes, see patch #8 where I get rid of rpi_firmware_get() altogether after
> > converting all users to devres. Since there is no use for the vanilla 
> > version
> > of the function anymore, I figured it'd be better to merge everything into
> > devm_rpi_firmware_get(). That said it's not something I have strong feelings
> > about.
> > 
> 
> I see. So the previous version didn't really have any reference
> counting and it leaked the reference returned by
> of_find_device_by_node(), got it. Could you just clarify for me the
> logic behind the wait_queue in rpi_firmware_remove()? If the firmware
> driver gets detached and remove() stops on the wait_queue - it will be
> stuck until the last user releases the firmware. I'm not sure this is
> correct.

Yes, that's what I meant to implement.

> I'd prefer to see a kref with a release callback and remove
> would simply decrease the kref and return. Each user would do the same
> and then after the last user is detached the firmware would be
> destroyed.

Sounds good to me. I'll update it.

> Don't we really have some centralized firmware subsystem that would handle 
> this?

Sadly no, this is an RPi specific thing, it doesn't live behind a standard like
other firmware based protocols (for ex. SCMI), and evolves as the needs arise.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] firmware: fix spelling typo of 'wtih'

[Nicolas Saenz Julienne]

On Sat, 2020-11-07 at 16:19 +0800, Wang Qing wrote:
> wtih -> with
> 
> Signed-off-by: Wang Qing 
> ---

Acked-by: Nicolas Saenz Julienne 

Thanks!

>  drivers/firmware/raspberrypi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 2371d08..30259dc
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Defines interfaces for interacting wtih the Raspberry Pi firmware's
> + * Defines interfaces for interacting with the Raspberry Pi firmware's
>   * property channel.
>   *
>   * Copyright © 2015 Broadcom



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

Hi James, thanks for the review. Some comments/questions below.

On Thu, 2020-11-05 at 16:11 +, James Morse wrote:
> Hi!
> 
> On 03/11/2020 17:31, Nicolas Saenz Julienne wrote:
> > crashkernel might reserve memory located in ZONE_DMA. We plan to delay
> > ZONE_DMA's initialization after unflattening the devicetree and ACPI's
> > boot table initialization, so move it later in the boot process.
> > Specifically into mem_init(), this is the last place crashkernel will be
> > able to reserve the memory before the page allocator kicks in.
> > There
> > isn't any apparent reason for doing this earlier.
> 
> It's so that map_mem() can carve it out of the linear/direct map.
> This is so that stray writes from a crashing kernel can't accidentally 
> corrupt the kdump
> kernel. We depend on this if we continue with kdump, but failed to offline 
> all the other
> CPUs.

I presume here you refer to arch_kexec_protect_crashkres(), IIUC this will only
happen further down the line, after having loaded the kdump kernel image. But
it also depends on the mappings to be PAGE sized (flags == NO_BLOCK_MAPPINGS |
NO_CONT_MAPPINGS).

> We also depend on this when skipping the checksum code in purgatory, which 
> can be
> exceedingly slow.

This one I don't fully understand, so I'll lazily assume the prerequisite is
the same WRT how memory is mapped. :)

Ultimately there's also /sys/kernel/kexec_crash_size's handling. Same
prerequisite.

Keeping in mind acpi_table_upgrade() and unflatten_device_tree() depend on
having the linear mappings available. I don't see any simple way of solving
this. Both moving the firmware description routines to use fixmap or correcting
the linear mapping further down the line so as to include kdump's regions, seem
excessive/impossible (feel free to correct me here). I'd be happy to hear
suggestions. Otherwise we're back to hard-coding the information as we
initially did.

Let me stress that knowing the DMA constraints in the system before reserving
crashkernel's regions is necessary if we ever want it to work seamlessly on all
platforms. Be it small stuff like the Raspberry Pi or huge servers with TB of
memory.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 01/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

Hi Bartosz, thanks for the review.

On Thu, 2020-11-05 at 10:13 +0100, Bartosz Golaszewski wrote:
> > +/**
> > + * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
> > + * @firmware_node:Pointer to the firmware Device Tree node.
> > + *
> > + * Returns NULL is the firmware device is not ready.
> > + */
> > +struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
> > +  struct device_node 
> > *firmware_node)
> > +{
> > +   struct platform_device *pdev = 
> > of_find_device_by_node(firmware_node);
> > +   struct rpi_firmware *fw;
> > +
> > +   if (!pdev)
> > +   return NULL;
> > +
> > +   fw = platform_get_drvdata(pdev);
> > +   if (!fw)
> > +   return NULL;
> > +
> > +   if (!refcount_inc_not_zero(>consumers))
> > +   return NULL;
> > +
> > +   if (devm_add_action_or_reset(dev, rpi_firmware_put, fw))
> > +   return NULL;
> > +
> > +   return fw;
> > +}
> > +EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
> 
> Usually I'd expect the devres variant to simply call
> rpi_firmware_get() and then schedule a release callback which would
> call whatever function is the release counterpart for it currently.
> Devres actions are for drivers which want to schedule some more
> unusual tasks at driver detach. Any reason for designing it this way?

Yes, see patch #8 where I get rid of rpi_firmware_get() altogether after
converting all users to devres. Since there is no use for the vanilla version
of the function anymore, I figured it'd be better to merge everything into
devm_rpi_firmware_get(). That said it's not something I have strong feelings
about.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 09/11] dt-bindings: pwm: Add binding for RPi firmware PWM bus

[Nicolas Saenz Julienne]

On Wed, 2020-11-04 at 13:06 -0600, Rob Herring wrote:
> On Wed, 04 Nov 2020 11:39:35 +0100, Nicolas Saenz Julienne wrote:
> > The PWM bus controlling the fan in RPi's official PoE hat can only be
> > controlled by the board's co-processor.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > Reviewed-by: Rob Herring 
> > 
> > ---
> > 
> > Changes since v1:
> >  - Update bindings to use 2 #pwm-cells
> > 
> >  .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 +++
> >  .../pwm/raspberrypi,firmware-pwm.h| 13 
> >  2 files changed, 33 insertions(+)
> >  create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-pwm.h
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.example.dt.yaml:
>  firmware: pwm:#pwm-cells:0:0: 2 was expected

Yes I forgot to update the example...

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

[PATCH v3 06/11] staging: vchiq: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 01125d9f991b..3c25e237e334 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2723,7 +2723,7 @@ static int vchiq_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   drvdata->fw = rpi_firmware_get(fw_node);
+   drvdata->fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!drvdata->fw)
return -EPROBE_DEFER;
-- 
2.29.1

[PATCH v3 09/11] dt-bindings: pwm: Add binding for RPi firmware PWM bus

[Nicolas Saenz Julienne]

The PWM bus controlling the fan in RPi's official PoE hat can only be
controlled by the board's co-processor.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---

Changes since v1:
 - Update bindings to use 2 #pwm-cells

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 +++
 .../pwm/raspberrypi,firmware-pwm.h| 13 
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-pwm.h

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a2c63c8b1d10..8029ce958c48 100644
--- 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -64,6 +64,21 @@ properties:
   - compatible
   - "#reset-cells"
 
+  pwm:
+type: object
+
+properties:
+  compatible:
+const: raspberrypi,firmware-pwm
+
+  "#pwm-cells":
+# See pwm.yaml in this directory for a description of the cells format.
+const: 2
+
+required:
+  - compatible
+  - "#pwm-cells"
+
 additionalProperties: false
 
 required:
@@ -87,5 +102,10 @@ examples:
 compatible = "raspberrypi,firmware-reset";
 #reset-cells = <1>;
 };
+
+pwm: pwm {
+compatible = "raspberrypi,firmware-pwm";
+#pwm-cells = <1>;
+};
 };
 ...
diff --git a/include/dt-bindings/pwm/raspberrypi,firmware-pwm.h 
b/include/dt-bindings/pwm/raspberrypi,firmware-pwm.h
new file mode 100644
index ..27c5ce68847b
--- /dev/null
+++ b/include/dt-bindings/pwm/raspberrypi,firmware-pwm.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne 
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+
+#define RASPBERRYPI_FIRMWARE_PWM_POE   0
+#define RASPBERRYPI_FIRMWARE_PWM_NUM   1
+
+#endif
-- 
2.29.1

[PATCH v3 11/11] pwm: Add Raspberry Pi Firmware based PWM bus

[Nicolas Saenz Julienne]

Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get()
 - Rename driver
 - Small cleanups as per Andy Shevchenko's comments

Changes since v1:
 - Use default pwm bindings and get rid of xlate() function
 - Correct spelling errors
 - Correct apply() function
 - Round values
 - Fix divisions in arm32 mode
 - Small cleanups

 drivers/pwm/Kconfig   |   9 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a..ab31615f07fc 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -379,6 +379,15 @@ config PWM_PXA
  To compile this driver as a module, choose M here: the module
  will be called pwm-pxa.
 
+config PWM_RASPBERRYPI_POE
+   tristate "Raspberry Pi Firwmware PoE Hat PWM support"
+   # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+   # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+   depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
+   help
+ Enable Raspberry Pi firmware controller PWM bus used to control the
+ official RPI PoE hat
+
 config PWM_RCAR
tristate "Renesas R-Car PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index cbdcd55d69ee..7ecbbbcb323a 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
+obj-$(CONFIG_PWM_RASPBERRYPI_POE)  += pwm-raspberrypi-poe.o
 obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
diff --git a/drivers/pwm/pwm-raspberrypi-poe.c 
b/drivers/pwm/pwm-raspberrypi-poe.c
new file mode 100644
index ..91cd826a36f3
--- /dev/null
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Nicolas Saenz Julienne 
+ * For more information on Raspberry Pi's PoE hat see:
+ * https://www.raspberrypi.org/products/poe-hat/
+ *
+ * Limitations:
+ *  - No disable bit, so a disabled PWM is simulated by duty_cycle 0
+ *  - Only normal polarity
+ *  - Fixed 12.5 kHz period
+ *
+ * The current period is completed when HW is reconfigured.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define RPI_PWM_MAX_DUTY   255
+#define RPI_PWM_PERIOD_NS  8 /* 12.5 kHz */
+
+#define RPI_PWM_CUR_DUTY_REG   0x0
+#define RPI_PWM_DEF_DUTY_REG   0x1
+
+struct raspberrypi_pwm {
+   struct rpi_firmware *firmware;
+   struct pwm_chip chip;
+   unsigned int duty_cycle;
+};
+
+struct raspberrypi_pwm_prop {
+   __le32 reg;
+   __le32 val;
+   __le32 ret;
+} __packed;
+
+static inline struct raspberrypi_pwm *to_raspberrypi_pwm(struct pwm_chip *chip)
+{
+   return container_of(chip, struct raspberrypi_pwm, chip);
+}
+
+static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
+   u32 reg, u32 val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = cpu_to_le32(reg),
+   .val = cpu_to_le32(val),
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
+   u32 reg, u32 *val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = reg
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   *val = le32_to_cpu(msg.val);
+
+   return 0;
+}
+
+static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct raspberrypi_pwm *rpipwm = to_raspberrypi_pwm(chip);
+
+   state->period = RPI_PWM_PERIOD_NS;
+   state->duty_cycle = DIV_ROUND_CLOSEST(rpipw

[PATCH v3 07/11] input: raspberrypi-ts: Release firmware handle when not needed

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/raspberrypi-ts.c 
b/drivers/input/touchscreen/raspberrypi-ts.c
index ef6aaed217cf..efed0efa91d9 100644
--- a/drivers/input/touchscreen/raspberrypi-ts.c
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -134,7 +134,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(fw_node);
+   fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.1

[PATCH v3 04/11] reset: raspberrypi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/reset/reset-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-raspberrypi.c 
b/drivers/reset/reset-raspberrypi.c
index 02f59c06f69b..fa23db554bcf 100644
--- a/drivers/reset/reset-raspberrypi.c
+++ b/drivers/reset/reset-raspberrypi.c
@@ -82,7 +82,7 @@ static int rpi_reset_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(np);
+   fw = devm_rpi_firmware_get(>dev, np);
of_node_put(np);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.1

[PATCH v3 08/11] firmware: raspberrypi: Get rid of rpi_firmware_get()

[Nicolas Saenz Julienne]

There a no users left to the function as they all converted to
devm_rpi_firmware_get(). Just get rid of it.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/firmware/raspberrypi.c | 17 -
 include/soc/bcm2835/raspberrypi-firmware.h |  6 --
 2 files changed, 23 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 74bdb3bde9dc..67f7105f3fd2 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -297,23 +297,6 @@ static void rpi_firmware_put(void *data)
wake_up(>wait);
 }
 
-/**
- * rpi_firmware_get - Get pointer to rpi_firmware structure.
- * @firmware_node:Pointer to the firmware Device Tree node.
- *
- * Returns NULL is the firmware device is not ready.
- */
-struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
-{
-   struct platform_device *pdev = of_find_device_by_node(firmware_node);
-
-   if (!pdev)
-   return NULL;
-
-   return platform_get_drvdata(pdev);
-}
-EXPORT_SYMBOL_GPL(rpi_firmware_get);
-
 /**
  * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
  * @firmware_node:Pointer to the firmware Device Tree node.
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index 8fe64f53a394..eaa4e516e4c6 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -140,7 +140,6 @@ int rpi_firmware_property(struct rpi_firmware *fw,
  u32 tag, void *data, size_t len);
 int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
-struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
 struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
   struct device_node *firmware_node);
 #else
@@ -156,11 +155,6 @@ static inline int rpi_firmware_property_list(struct 
rpi_firmware *fw,
return -ENOSYS;
 }
 
-static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
-{
-   return NULL;
-}
-
 static inline struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
struct device_node *firmware_node)
 {
-- 
2.29.1

[PATCH v3 02/11] clk: bcm: rpi: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/clk/bcm/clk-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index f89b9cfc4309..dd3b71eafabf 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -314,7 +314,7 @@ static int raspberrypi_clk_probe(struct platform_device 
*pdev)
return -ENOENT;
}
 
-   firmware = rpi_firmware_get(firmware_node);
+   firmware = devm_rpi_firmware_get(>dev, firmware_node);
of_node_put(firmware_node);
if (!firmware)
return -EPROBE_DEFER;
-- 
2.29.1

[PATCH v3 10/11] DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support

[Nicolas Saenz Julienne]

This is an example on how to enable the fan on top of RPi's official PoE
hat.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v1:
 - Update patch to use 2 pwm cells

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182c2936..361db82619a4 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -5,6 +5,7 @@
 #include "bcm283x-rpi-usb-peripheral.dtsi"
 
 #include 
+#include 
 
 / {
compatible = "raspberrypi,4-model-b", "brcm,bcm2711";
@@ -68,6 +69,54 @@ sd_vcc_reg: sd_vcc_reg {
enable-active-high;
gpio = < 6 GPIO_ACTIVE_HIGH>;
};
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 50 150 255>;
+   #cooling-cells = <2>;
+   pwms = < RASPBERRYPI_FIRMWARE_PWM_POE 8>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   trips {
+   threshold: trip-point@0 {
+   temperature = <45000>;
+   hysteresis = <5000>;
+   type = "active";
+   };
+
+   target: trip-point@1 {
+   temperature = <5>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+
+   cpu_hot: cpu_hot@0 {
+   temperature = <55000>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 0 1>;
+   };
+
+   map1 {
+   trip = <>;
+   cooling-device = < 1 2>;
+   };
+
+   map2 {
+   trip = <_hot>;
+   cooling-device = < 2 3>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -103,6 +152,11 @@ reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
};
+
+   fwpwm: pwm {
+   compatible = "raspberrypi,firmware-pwm";
+   #pwm-cells = <2>;
+   };
 };
 
  {
-- 
2.29.1

[PATCH v3 05/11] soc: bcm: raspberrypi-power: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/soc/bcm/raspberrypi-power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/bcm/raspberrypi-power.c 
b/drivers/soc/bcm/raspberrypi-power.c
index 5d1aacdd84ef..068715d6e66d 100644
--- a/drivers/soc/bcm/raspberrypi-power.c
+++ b/drivers/soc/bcm/raspberrypi-power.c
@@ -177,7 +177,7 @@ static int rpi_power_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   rpi_domains->fw = rpi_firmware_get(fw_np);
+   rpi_domains->fw = devm_rpi_firmware_get(>dev, fw_np);
of_node_put(fw_np);
if (!rpi_domains->fw)
return -EPROBE_DEFER;
-- 
2.29.1

[PATCH v3 03/11] gpio: raspberrypi-exp: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/gpio/gpio-raspberrypi-exp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-raspberrypi-exp.c 
b/drivers/gpio/gpio-raspberrypi-exp.c
index bb100e0124e6..64a552ecc2ad 100644
--- a/drivers/gpio/gpio-raspberrypi-exp.c
+++ b/drivers/gpio/gpio-raspberrypi-exp.c
@@ -208,7 +208,7 @@ static int rpi_exp_gpio_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(fw_node);
+   fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.1

[PATCH v3 00/11] Raspberry Pi PoE HAT fan support

[Nicolas Saenz Julienne]

The aim of this series is to add support to the fan found on RPi's PoE
HAT. Some commentary on the design can be found below. But the imporant
part to the people CC'd here not involved with PWM is that, in order to
achieve this properly, we also have to fix the firmware interface the
driver uses to communicate with the PWM bus (and many other low level
functions). Specifically, we have to make sure the firmware interface
isn't unbound while consumers are still up. So, patch #1 introduces
reference counting in the firwmware interface driver and patches #2 to
#7 update all firmware users. Patches #8 to #10 introduce the new PWM
driver.

I sent everything as a single series as the final version of the PWM
drivers depends on the firwmare fixes, but I'll be happy to split this
into two separate series if you think it's better.

--- Original cover letter below ---

This series aims at adding support to RPi's official PoE HAT fan[1].

The HW setup is the following:

| Raspberry Pi   | PoE HAT|
 arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN

The arm cores have only access to the mailbox interface, as i2c0, even if
physically accessible, is to be used solely by the co-processor
(VideoCore 4/6).

This series implements a PWM bus, and has pwm-fan sitting on top of it as per
this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has a
series of shortcomings:

- It depends on a DT binding: it's not flexible if a new hat shows up with new
  functionality, we're not 100% sure we'll be able to expand it without
  breaking backwards compatibility. But without it we can't make use of DT
  thermal-zones, which IMO is overkill.

- We're using pwm-fan, writing a hwmon driver would, again, give us more
  flexibility, but it's not really needed at the moment.

I personally think that it's not worth the effort, it's unlikely we'll get
things right in advance. And ultimately, if the RPi people come up with
something new, we can always write a new driver/bindings from scratch (as in
not reusing previous code).

That said, I'm more than happy to change things if there is a consensus that
another design will do the trick.

[1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/

---

Changes since v2:
 - Introduce devm_rpi_firmware_get()
 - Small cleanups in PWM driver

Changes since v1:
 - Address PWM driver changes
 - Fix binding, now with 2 cells
 - Add reference count to rpi_firmware_get()

Nicolas Saenz Julienne (11):
  firmware: raspberrypi: Introduce devm_rpi_firmware_get()
  clk: bcm: rpi: Release firmware handle on unbind
  gpio: raspberrypi-exp: Release firmware handle on unbind
  reset: raspberrypi: Release firmware handle on unbind
  soc: bcm: raspberrypi-power: Release firmware handle on unbind
  staging: vchiq: Release firmware handle on unbind
  input: raspberrypi-ts: Release firmware handle when not needed
  firmware: raspberrypi: Get rid of rpi_firmware_get()
  dt-bindings: pwm: Add binding for RPi firmware PWM bus
  DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support
  pwm: Add Raspberry Pi Firmware based PWM bus

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml |  20 ++
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  54 +
 drivers/clk/bcm/clk-raspberrypi.c |   2 +-
 drivers/firmware/raspberrypi.c|  37 ++-
 drivers/gpio/gpio-raspberrypi-exp.c   |   2 +-
 drivers/input/touchscreen/raspberrypi-ts.c|   2 +-
 drivers/pwm/Kconfig   |   9 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 drivers/reset/reset-raspberrypi.c |   2 +-
 drivers/soc/bcm/raspberrypi-power.c   |   2 +-
 .../interface/vchiq_arm/vchiq_arm.c   |   2 +-
 .../pwm/raspberrypi,firmware-pwm.h|  13 ++
 include/soc/bcm2835/raspberrypi-firmware.h|   6 +-
 14 files changed, 356 insertions(+), 12 deletions(-)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-pwm.h

-- 
2.29.1

[PATCH v3 01/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

[Nicolas Saenz Julienne]

When unbinding the firmware device we need to make sure it has no
consumers left. Otherwise we'd leave them with a firmware handle
pointing at freed memory.

Keep a reference count of all consumers and introduce
devm_rpi_firmware_get() which will automatically decrease the reference
count upon unbinding consumer drivers.

Suggested-by: Uwe Kleine-König 
Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Create devm_rpi_firmware_get()

 drivers/firmware/raspberrypi.c | 46 ++
 include/soc/bcm2835/raspberrypi-firmware.h |  8 
 2 files changed, 54 insertions(+)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 2371d08bdd17..74bdb3bde9dc 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -11,7 +11,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #define MBOX_MSG(chan, data28) (((data28) & ~0xf) | ((chan) & 0xf))
@@ -27,6 +29,9 @@ struct rpi_firmware {
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+
+   refcount_t consumers;
+   wait_queue_head_t wait;
 };
 
 static DEFINE_MUTEX(transaction_lock);
@@ -247,6 +252,8 @@ static int rpi_firmware_probe(struct platform_device *pdev)
}
 
init_completion(>c);
+   refcount_set(>consumers, 1);
+   init_waitqueue_head(>wait);
 
platform_set_drvdata(pdev, fw);
 
@@ -275,11 +282,21 @@ static int rpi_firmware_remove(struct platform_device 
*pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
+
+   wait_event(fw->wait, refcount_dec_if_one(>consumers));
mbox_free_channel(fw->chan);
 
return 0;
 }
 
+static void rpi_firmware_put(void *data)
+{
+   struct rpi_firmware *fw = data;
+
+   refcount_dec(>consumers);
+   wake_up(>wait);
+}
+
 /**
  * rpi_firmware_get - Get pointer to rpi_firmware structure.
  * @firmware_node:Pointer to the firmware Device Tree node.
@@ -297,6 +314,35 @@ struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
+/**
+ * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
+ * @firmware_node:Pointer to the firmware Device Tree node.
+ *
+ * Returns NULL is the firmware device is not ready.
+ */
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node)
+{
+   struct platform_device *pdev = of_find_device_by_node(firmware_node);
+   struct rpi_firmware *fw;
+
+   if (!pdev)
+   return NULL;
+
+   fw = platform_get_drvdata(pdev);
+   if (!fw)
+   return NULL;
+
+   if (!refcount_inc_not_zero(>consumers))
+   return NULL;
+
+   if (devm_add_action_or_reset(dev, rpi_firmware_put, fw))
+   return NULL;
+
+   return fw;
+}
+EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
+
 static const struct of_device_id rpi_firmware_of_match[] = {
{ .compatible = "raspberrypi,bcm2835-firmware", },
{},
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index cc9cdbc66403..8fe64f53a394 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -141,6 +141,8 @@ int rpi_firmware_property(struct rpi_firmware *fw,
 int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
void *data, size_t len)
@@ -158,6 +160,12 @@ static inline struct rpi_firmware *rpi_firmware_get(struct 
device_node *firmware
 {
return NULL;
 }
+
+static inline struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+   struct device_node *firmware_node)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __SOC_RASPBERRY_FIRMWARE_H__ */
-- 
2.29.1

Re: [PATCH v1] PCI: brcmstb: variable is missing proper initialization

[Nicolas Saenz Julienne]

On Tue, 2020-11-03 at 13:38 -0600, Bjorn Helgaas wrote:
> On Mon, Nov 02, 2020 at 03:57:12PM -0500, Jim Quinlan wrote:
> > The variable 'tmp' is used multiple times in the brcm_pcie_setup()
> > function.  One such usage did not initialize 'tmp' to the current value of
> > the target register.  By luck the mistake does not currently affect
> > behavior;  regardless 'tmp' is now initialized properly.
> 
> This is so trivial that there's probably no reason to post this again,
> but if you post a v2 for some reason, please update the subject to
> match the convention ("PCI: brcmstb: Verb ..."), e.g.,
> 
>   PCI: brcmstb: Initialize "tmp" before use
> 
> The commit log does not say what the patch does, leaving it to the
> reader to infer it.
> 
> Lorenzo will likely fix this up when he applies it.
> 
> Incidental curiosity: where should I look to see what
> u32p_replace_bits() does?  "git grep u32p_replace_bits" shows several
> calls, but no definitions.

It's a bunch if defines in 'include/linux/bitfield.h'

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v1] PCI: brcmstb: variable is missing proper initialization

[Nicolas Saenz Julienne]

On Mon, 2020-11-02 at 13:07 -0800, Florian Fainelli wrote:
> 
> On 11/2/2020 12:57 PM, Jim Quinlan wrote:
> > The variable 'tmp' is used multiple times in the brcm_pcie_setup()
> > function.  One such usage did not initialize 'tmp' to the current value of
> > the target register.  By luck the mistake does not currently affect
> > behavior;  regardless 'tmp' is now initialized properly.
> > 
> > Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller 
> > driver")
> > Suggested-by: Rafał Miłecki 
> > Signed-off-by: Jim Quinlan 

Acked-by: Nicolas Saenz Julienne 



signature.asc
Description: This is a digitally signed message part

[PATCH v6 4/7] of: unittest: Add test for of_dma_get_max_cpu_address()

[Nicolas Saenz Julienne]

Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---
Changes since v5:
- Update address expected by test

Changes since v3:
 - Remove HAS_DMA guards

 drivers/of/unittest.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 06cc988faf78..98cc0163301b 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -869,6 +869,23 @@ static void __init of_unittest_changeset(void)
 #endif
 }
 
+static void __init of_unittest_dma_get_max_cpu_address(void)
+{
+   struct device_node *np;
+   phys_addr_t cpu_addr;
+
+   np = of_find_node_by_path("/testcase-data/address-tests");
+   if (!np) {
+   pr_err("missing testcase data\n");
+   return;
+   }
+
+   cpu_addr = of_dma_get_max_cpu_address(np);
+   unittest(cpu_addr == 0x4fff,
+"of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting 
%x)\n",
+_addr, 0x4fff);
+}
+
 static void __init of_unittest_dma_ranges_one(const char *path,
u64 expect_dma_addr, u64 expect_paddr)
 {
@@ -3266,6 +3283,7 @@ static int __init of_unittest(void)
of_unittest_changeset();
of_unittest_parse_interrupts();
of_unittest_parse_interrupts_extended();
+   of_unittest_dma_get_max_cpu_address();
of_unittest_parse_dma_ranges();
of_unittest_pci_dma_ranges();
of_unittest_match_node();
-- 
2.29.1

[PATCH v6 7/7] mm: Remove examples from enum zone_type comment

[Nicolas Saenz Julienne]

We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Christoph Hellwig 
---
 include/linux/mmzone.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e..9d0c454d23cd 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -354,26 +354,6 @@ enum zone_type {
 * DMA mask is assumed when ZONE_DMA32 is defined. Some 64-bit
 * platforms may need both zones as they support peripherals with
 * different DMA addressing limitations.
-*
-* Some examples:
-*
-*  - i386 and x86_64 have a fixed 16M ZONE_DMA and ZONE_DMA32 for the
-*rest of the lower 4G.
-*
-*  - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
-*the specific device.
-*
-*  - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
-*lower 4G.
-*
-*  - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
-*depending on the specific device.
-*
-*  - s390 uses ZONE_DMA fixed to the lower 2G.
-*
-*  - ia64 and riscv only use ZONE_DMA32.
-*
-*  - parisc uses neither.
 */
 #ifdef CONFIG_ZONE_DMA
ZONE_DMA,
-- 
2.29.1

[PATCH v6 2/7] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

[Nicolas Saenz Julienne]

zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
---
 arch/arm64/mm/init.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index fc4ab0d6d5d2..410721fc4fc0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -190,6 +190,8 @@ static void __init zone_sizes_init(unsigned long min, 
unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
 
 #ifdef CONFIG_ZONE_DMA
+   zone_dma_bits = ARM64_ZONE_DMA_BITS;
+   arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
 #ifdef CONFIG_ZONE_DMA32
@@ -376,11 +378,6 @@ void __init arm64_memblock_init(void)
 
early_init_fdt_scan_reserved_mem();
 
-   if (IS_ENABLED(CONFIG_ZONE_DMA)) {
-   zone_dma_bits = ARM64_ZONE_DMA_BITS;
-   arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
-   }
-
if (IS_ENABLED(CONFIG_ZONE_DMA32))
arm64_dma32_phys_limit = max_zone_phys(32);
else
-- 
2.29.1

[PATCH v6 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan

[Nicolas Saenz Julienne]

From: Ard Biesheuvel 

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

Instructing the DMA layer about these limitations is straight-forward,
even though we had to fix some issues regarding memory limits set in
the IORT for named components, and regarding the handling of ACPI _DMA
methods. However, the DMA layer also needs to be able to allocate
memory that is guaranteed to meet those DMA constraints, for bounce
buffering as well as allocating the backing for consistent mappings.

This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
problems with kdump, and potentially in other places where allocations
cannot cross zone boundaries. Therefore, we should avoid having two
separate DMA zones when possible.

So let's do an early scan of the IORT, and only create the ZONE_DMA
if we encounter any devices that need it. This puts the burden on
the firmware to describe such limitations in the IORT, which may be
redundant (and less precise) if _DMA methods are also being provided.
However, it should be noted that this situation is highly unusual for
arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
the _DMA method if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.

Cc: Jeremy Linton 
Cc: Lorenzo Pieralisi 
Cc: Nicolas Saenz Julienne 
Cc: Rob Herring 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: Hanjun Guo 
Cc: Sudeep Holla 
Cc: Anshuman Khandual 
Signed-off-by: Ard Biesheuvel 
[nsaenz: unified implementation with DT's counterpart]
Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
Acked-by: Lorenzo Pieralisi 
Acked-by: Hanjun Guo 

---

Changes since v5:
 - Unify with DT's counterpart, return phys_addr_t

Changes since v3:
 - Use min_not_zero()
 - Check revision
 - Remove unnecessary #ifdef in zone_sizes_init()

 arch/arm64/mm/init.c  |  5 +++-
 drivers/acpi/arm64/iort.c | 55 +++
 include/linux/acpi_iort.h |  4 +++
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index a2ce8a9a71a6..ca5d4b10679d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -186,11 +187,13 @@ static phys_addr_t __init max_zone_phys(unsigned int 
zone_bits)
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+   unsigned int __maybe_unused acpi_zone_dma_bits;
unsigned int __maybe_unused dt_zone_dma_bits;
 
 #ifdef CONFIG_ZONE_DMA
+   acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
-   zone_dma_bits = min(32U, dt_zone_dma_bits);
+   zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9929ff50c0c0..1787406684aa 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1718,3 +1718,58 @@ void __init acpi_iort_init(void)
 
iort_init_platform_devices();
 }
+
+#ifdef CONFIG_ZONE_DMA
+/*
+ * Extract the highest CPU physical address accessible to all DMA masters in
+ * the system. PHYS_ADDR_MAX is returned when no constrained device is found.
+ */
+phys_addr_t __init acpi_iort_dma_get_max_cpu_address(void)
+{
+   phys_addr_t limit = PHYS_ADDR_MAX;
+   struct acpi_iort_node *node, *end;
+   struct acpi_table_iort *iort;
+   acpi_status status;
+   int i;
+
+   if (acpi_disabled)
+   return limit;
+
+   status = acpi_get_table(ACPI_SIG_IORT, 0,
+   (struct acpi_table_header **));
+   if (ACPI_FAILURE(status))
+   return limit;
+
+   node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset);
+   end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length);
+
+   for (i = 0; i < iort->node_count; i++) {
+   if (node >= end)
+   break;
+
+   switch (node->type) {
+   struct acpi_iort_named_component *ncomp;
+   struct acpi_iort_root_complex *rc;
+   phys_addr_t local_limit;
+
+   case ACPI_IORT_NODE_NAMED_COMPONENT:
+   ncomp = (struct acpi_iort_named_component 
*)node->node_data;
+   local_limit

[PATCH v6 3/7] of/address: Introduce of_dma_get_max_cpu_address()

[Nicolas Saenz Julienne]

Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---

Changes since v4:
 - Return max address, not address limit (one off difference)

Changes since v3:
 - use u64 with cpu_end

Changes since v2:
 - Use PHYS_ADDR_MAX
 - return phys_dma_t
 - Rename function
 - Correct subject
 - Add support to start parsing from an arbitrary device node in order
   for the function to work with unit tests

 drivers/of/address.c | 42 ++
 include/linux/of.h   |  7 +++
 2 files changed, 49 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index eb9ab4f1e80b..09c0af7fd1c4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -1024,6 +1024,48 @@ int of_dma_get_range(struct device_node *np, const 
struct bus_dma_region **map)
 }
 #endif /* CONFIG_HAS_DMA */
 
+/**
+ * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
+ * @np: The node to start searching from or NULL to start from the root
+ *
+ * Gets the highest CPU physical address that is addressable by all DMA masters
+ * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
+ * DMA constrained device is found, it returns PHYS_ADDR_MAX.
+ */
+phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
+{
+   phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
+   struct of_range_parser parser;
+   phys_addr_t subtree_max_addr;
+   struct device_node *child;
+   struct of_range range;
+   const __be32 *ranges;
+   u64 cpu_end = 0;
+   int len;
+
+   if (!np)
+   np = of_root;
+
+   ranges = of_get_property(np, "dma-ranges", );
+   if (ranges && len) {
+   of_dma_range_parser_init(, np);
+   for_each_of_range(, )
+   if (range.cpu_addr + range.size > cpu_end)
+   cpu_end = range.cpu_addr + range.size - 1;
+
+   if (max_cpu_addr > cpu_end)
+   max_cpu_addr = cpu_end;
+   }
+
+   for_each_available_child_of_node(np, child) {
+   subtree_max_addr = of_dma_get_max_cpu_address(child);
+   if (max_cpu_addr > subtree_max_addr)
+   max_cpu_addr = subtree_max_addr;
+   }
+
+   return max_cpu_addr;
+}
+
 /**
  * of_dma_is_coherent - Check if device is coherent
  * @np:device node
diff --git a/include/linux/of.h b/include/linux/of.h
index 5d51891cbf1a..9ed5b8532c30 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u32 id,
   const char *map_name, const char *map_mask_name,
   struct device_node **target, u32 *id_out);
 
+phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
+
 #else /* CONFIG_OF */
 
 static inline void of_core_init(void)
@@ -995,6 +997,11 @@ static inline int of_map_id(struct device_node *np, u32 id,
return -EINVAL;
 }
 
+static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
+{
+   return PHYS_ADDR_MAX;
+}
+
 #define of_match_ptr(_ptr) NULL
 #define of_match_node(_matches, _node) NULL
 #endif /* CONFIG_OF */
-- 
2.29.1

[PATCH v6 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

[Nicolas Saenz Julienne]

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

The DMA layer also needs to be able to allocate memory that is
guaranteed to meet those DMA constraints, for bounce buffering as well
as allocating the backing for consistent mappings. This is why the 1 GB
ZONE_DMA was introduced recently. Unfortunately, it turns out the having
a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and
potentially in other places where allocations cannot cross zone
boundaries. Therefore, we should avoid having two separate DMA zones
when possible.

So, with the help of of_dma_get_max_cpu_address() get the topmost
physical address accessible to all DMA masters in system and use that
information to fine-tune ZONE_DMA's size. In the absence of addressing
limited masters ZONE_DMA will span the whole 32-bit address space,
otherwise, in the case of the Raspberry Pi 4 it'll only span the 30-bit
address space, and have ZONE_DMA32 cover the rest of the 32-bit address
space.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v4:
 - Use fls64 as we're now using the max address (as opposed to the
   limit)

Changes since v3:
 - Simplify code for readability.

Changes since v2:
 - Updated commit log by shamelessly copying Ard's ACPI commit log

 arch/arm64/mm/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 410721fc4fc0..a2ce8a9a71a6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -42,8 +42,6 @@
 #include 
 #include 
 
-#define ARM64_ZONE_DMA_BITS30
-
 /*
  * We need to be able to catch inadvertent references to memstart_addr
  * that occur (potentially in generic code) before arm64_memblock_init()
@@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int 
zone_bits)
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+   unsigned int __maybe_unused dt_zone_dma_bits;
 
 #ifdef CONFIG_ZONE_DMA
-   zone_dma_bits = ARM64_ZONE_DMA_BITS;
+   dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
+   zone_dma_bits = min(32U, dt_zone_dma_bits);
arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
-- 
2.29.1

[PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

crashkernel might reserve memory located in ZONE_DMA. We plan to delay
ZONE_DMA's initialization after unflattening the devicetree and ACPI's
boot table initialization, so move it later in the boot process.
Specifically into mem_init(), this is the last place crashkernel will be
able to reserve the memory before the page allocator kicks in. There
isn't any apparent reason for doing this earlier.

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
---
 arch/arm64/mm/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 095540667f0f..fc4ab0d6d5d2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -386,8 +386,6 @@ void __init arm64_memblock_init(void)
else
arm64_dma32_phys_limit = PHYS_MASK + 1;
 
-   reserve_crashkernel();
-
reserve_elfcorehdr();
 
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
@@ -508,6 +506,8 @@ void __init mem_init(void)
else
swiotlb_force = SWIOTLB_NO_FORCE;
 
+   reserve_crashkernel();
+
set_max_mapnr(max_pfn - PHYS_PFN_OFFSET);
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
-- 
2.29.1

[PATCH v6 0/7] arm64: Default to 32-bit wide ZONE_DMA

[Nicolas Saenz Julienne]

Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.

I tested this on both a RPi4 and QEMU.

---

Changes since v5:
 - Unify ACPI/DT functions

Changes since v4:
 - Fix of_dma_get_max_cpu_address() so it returns the last addressable
   addres, not the limit

Changes since v3:
 - Drop patch adding define in dma-mapping
 - Address small review changes
 - Update Ard's patch
 - Add new patch removing examples from mmzone.h

Changes since v2:
 - Introduce Ard's patch
 - Improve OF dma-ranges parsing function
 - Add unit test for OF function
 - Address small changes
 - Move crashkernel reservation later in boot process

Changes since v1:
 - Parse dma-ranges instead of using machine compatible string

Ard Biesheuvel (1):
  arm64: mm: Set ZONE_DMA size based on early IORT scan

Nicolas Saenz Julienne (6):
  arm64: mm: Move reserve_crashkernel() into mem_init()
  arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
  of/address: Introduce of_dma_get_max_cpu_address()
  of: unittest: Add test for of_dma_get_max_cpu_address()
  arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
  mm: Remove examples from enum zone_type comment

 arch/arm64/mm/init.c  | 18 ++---
 drivers/acpi/arm64/iort.c | 55 +++
 drivers/of/address.c  | 42 ++
 drivers/of/unittest.c | 18 +
 include/linux/acpi_iort.h |  4 +++
 include/linux/mmzone.h| 20 --
 include/linux/of.h|  7 +
 7 files changed, 135 insertions(+), 29 deletions(-)

-- 
2.29.1

Re: [PATCH v5 0/7] arm64: Default to 32-bit wide ZONE_DMA

[Nicolas Saenz Julienne]

On Fri, 2020-10-30 at 18:11 +, Catalin Marinas wrote:
> On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote:
> > Ard Biesheuvel (1):
> >   arm64: mm: Set ZONE_DMA size based on early IORT scan
> > 
> > Nicolas Saenz Julienne (6):
> >   arm64: mm: Move reserve_crashkernel() into mem_init()
> >   arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
> >   of/address: Introduce of_dma_get_max_cpu_address()
> >   of: unittest: Add test for of_dma_get_max_cpu_address()
> >   arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
> >   mm: Remove examples from enum zone_type comment
> 
> Thanks for putting this together. I had a minor comment but the patches
> look fine to me. We still need an ack from Rob on the DT patch and I can
> queue the series for 5.11.

I'm preparing a v6 unifying both functions as you suggested.

> Could you please also test the patch below on top of this series? It's
> the removal of the implied DMA offset in the max_zone_phys()
> calculation.

Yes, happily. Comments below.

> --8<-
> From 3ae252d888be4984a612236124f5b099e804c745 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas 
> Date: Fri, 30 Oct 2020 18:07:34 +
> Subject: [PATCH] arm64: Ignore any DMA offsets in the max_zone_phys()
>  calculation
> 
> Currently, the kernel assumes that if RAM starts above 32-bit (or
> zone_bits), there is still a ZONE_DMA/DMA32 at the bottom of the RAM and
> such constrained devices have a hardwired DMA offset. In practice, we
> haven't noticed any such hardware so let's assume that we can expand
> ZONE_DMA32 to the available memory if no RAM below 4GB. Similarly,
> ZONE_DMA is expanded to the 4GB limit if no RAM addressable by
> zone_bits.
> 
> Signed-off-by: Catalin Marinas 
> ---
>  arch/arm64/mm/init.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 095540667f0f..362160e16fb2 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -175,14 +175,21 @@ static void __init reserve_elfcorehdr(void)
>  #endif /* CONFIG_CRASH_DUMP */
>  
>  /*
> - * Return the maximum physical address for a zone with a given address size
> - * limit. It currently assumes that for memory starting above 4G, 32-bit
> - * devices will use a DMA offset.
> + * Return the maximum physical address for a zone accessible by the given 
> bits
> + * limit. If the DRAM starts above 32-bit, expand the zone to the maximum
> + * available memory, otherwise cap it at 32-bit.
>   */
>  static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
>  {
> - phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 
> zone_bits);
> - return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
> + phys_addr_t zone_mask = (1ULL << zone_bits) - 1;

Maybe use DMA_BIT_MASK(), instead of the manual calculation?

> + phys_addr_t phys_start = memblock_start_of_DRAM();
> +
> + if (!(phys_start & U32_MAX))

I'd suggest using 'bigger than' instead of masks. Just to cover ourselves
against memory starting at odd locations. Also it'll behaves properly when
phys_start is zero (this breaks things on RPi4).

> + zone_mask = PHYS_ADDR_MAX;
> + else if (!(phys_start & zone_mask))
> + zone_mask = U32_MAX;
> +
> + return min(zone_mask + 1, memblock_end_of_DRAM());

This + 1 isn't going to play well when zone_mask is PHYS_ADDR_MAX.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: Hard lockup on Raspberry Pi 4 after v5.10-rc1

[Nicolas Saenz Julienne]

On Mon, 2020-11-02 at 00:29 -0700, Nathan Chancellor wrote:
> Hi everyone,
> 
> Starting with v5.10-rc1, I appear to be experiencing hard lockups on my
> Raspberry Pi 4 when compiling LLVM. My standard workflow for testing the
> Raspberry Pi 4 has been compiling tip of tree LLVM (to catch host
> AArch64 issues), compiling linux-next ARCH=arm64 defconfig, then booting
> it with QEMU + KVM, which has caught a few issues so far. Starting with
> v5.10-rc1, compiling LLVM causes the serial console to print junk like
> 
>  |▒pp▒p▒p▒p
>  p|▒|▒|p▒p▒p|▒▒|▒|▒|p|▒▒|▒|▒|
>  p▒pp▒▒▒|▒▒
>  ▒
>  ▒|▒|
>  p▒
>  ▒
>  ▒▒
>  ▒
>  ▒p|p
> 
> then I lose my mosh connection and I see the lights on the front of the
> Pi stop blinking.
> 
> I have managed to narrow it down to a commit somewhere in the armsoc DT
> merge.
> 
> Good: 2e368dd2bbea ("Merge tag 'armsoc-drivers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> Bad: e533cda12d8f ("Merge tag 'armsoc-dt' of
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> 
> I have not been able to complete a full bisect due to a lack of time
> unfortunately, I am sending this email to hopefully get some more eyes
> on the issue.
> 
> $ head -n6 /boot/config.txt
> # My settings
> enable_uart=1
> core_freq_min=500
> kernel=Image
> os_prefix=custom-mainline-gcc-arm64/
> upstream_kernel=1
> 
> $ cat /boot/.firmware_revision
> e8ddac7cd34b179efd702d4dc1efd0ccf44559b9
> 
> I can reproduce the issue with:
> 
> $ git clone --depth=1 https://github.com/llvm/llvm-project
> 
> $ mkdir -p llvm-project/build && cd llvm-project/build
> 
> $ cmake \
> -G Ninja \
> -DCMAKE_BUILD_TYPE=Release \
> -DLLVM_ENABLE_PROJECTS="clang;lld" \
> ../llvm &&
> ninja
> 
> If you need any more information or testing, please let me know!

Thanks for the report! I'll have a look at it tomorrow.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

[PATCH v5 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan

[Nicolas Saenz Julienne]

From: Ard Biesheuvel 

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

Instructing the DMA layer about these limitations is straight-forward,
even though we had to fix some issues regarding memory limits set in
the IORT for named components, and regarding the handling of ACPI _DMA
methods. However, the DMA layer also needs to be able to allocate
memory that is guaranteed to meet those DMA constraints, for bounce
buffering as well as allocating the backing for consistent mappings.

This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
problems with kdump, and potentially in other places where allocations
cannot cross zone boundaries. Therefore, we should avoid having two
separate DMA zones when possible.

So let's do an early scan of the IORT, and only create the ZONE_DMA
if we encounter any devices that need it. This puts the burden on
the firmware to describe such limitations in the IORT, which may be
redundant (and less precise) if _DMA methods are also being provided.
However, it should be noted that this situation is highly unusual for
arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
the _DMA method if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.

Cc: Jeremy Linton 
Cc: Lorenzo Pieralisi 
Cc: Nicolas Saenz Julienne 
Cc: Rob Herring 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: Hanjun Guo 
Cc: Sudeep Holla 
Cc: Anshuman Khandual 
Signed-off-by: Ard Biesheuvel 
[nsaenz: Rebased, removed documentation change and add declaration in 
acpi_iort.h]
Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
Acked-by: Lorenzo Pieralisi 
Acked-by: Hanjun Guo 

---

Changes since v3:
 - Use min_not_zero()
 - Check revision
 - Remove unnecessary #ifdef in zone_sizes_init()
 
 arch/arm64/mm/init.c  |  3 ++-
 drivers/acpi/arm64/iort.c | 52 +++
 include/linux/acpi_iort.h |  4 +++
 3 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index a2ce8a9a71a6..b9dc3831dd6b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -190,7 +191,7 @@ static void __init zone_sizes_init(unsigned long min, 
unsigned long max)
 
 #ifdef CONFIG_ZONE_DMA
dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
-   zone_dma_bits = min(32U, dt_zone_dma_bits);
+   zone_dma_bits = min3(32U, dt_zone_dma_bits, 
acpi_iort_get_zone_dma_size());
arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9929ff50c0c0..05fe4a076bab 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1718,3 +1718,55 @@ void __init acpi_iort_init(void)
 
iort_init_platform_devices();
 }
+
+#ifdef CONFIG_ZONE_DMA
+/*
+ * Check the IORT whether any devices exist whose DMA mask is < 32 bits.
+ * If so, return the smallest value encountered, or 32 otherwise.
+ */
+unsigned int __init acpi_iort_get_zone_dma_size(void)
+{
+   struct acpi_table_iort *iort;
+   struct acpi_iort_node *node, *end;
+   acpi_status status;
+   u8 limit = 32;
+   int i;
+
+   if (acpi_disabled)
+   return limit;
+
+   status = acpi_get_table(ACPI_SIG_IORT, 0,
+   (struct acpi_table_header **));
+   if (ACPI_FAILURE(status))
+   return limit;
+
+   node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset);
+   end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length);
+
+   for (i = 0; i < iort->node_count; i++) {
+   if (node >= end)
+   break;
+
+   switch (node->type) {
+   struct acpi_iort_named_component *ncomp;
+   struct acpi_iort_root_complex *rc;
+
+   case ACPI_IORT_NODE_NAMED_COMPONENT:
+   ncomp = (struct acpi_iort_named_component 
*)node->node_data;
+   limit = min_not_zero(limit, 
ncomp->memory_address_limit);
+   break;
+
+   case ACPI_IORT_NODE_PCI_ROOT_COMPLEX:
+   if (node->revision < 1)
+   break;
+
+   rc = (struct acpi_iort_root_complex *)node->node_data;
+   limit = min_not_zero(limit, rc->memory_address_limit);
+   break;

[PATCH v5 2/7] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

[Nicolas Saenz Julienne]

zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
---
 arch/arm64/mm/init.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index fc4ab0d6d5d2..410721fc4fc0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -190,6 +190,8 @@ static void __init zone_sizes_init(unsigned long min, 
unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
 
 #ifdef CONFIG_ZONE_DMA
+   zone_dma_bits = ARM64_ZONE_DMA_BITS;
+   arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
 #ifdef CONFIG_ZONE_DMA32
@@ -376,11 +378,6 @@ void __init arm64_memblock_init(void)
 
early_init_fdt_scan_reserved_mem();
 
-   if (IS_ENABLED(CONFIG_ZONE_DMA)) {
-   zone_dma_bits = ARM64_ZONE_DMA_BITS;
-   arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
-   }
-
if (IS_ENABLED(CONFIG_ZONE_DMA32))
arm64_dma32_phys_limit = max_zone_phys(32);
else
-- 
2.29.0

[PATCH v5 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

[Nicolas Saenz Julienne]

crashkernel might reserve memory located in ZONE_DMA. We plan to delay
ZONE_DMA's initialization after unflattening the devicetree and ACPI's
boot table initialization, so move it later in the boot process.
Specifically into mem_init(), this is the last place crashkernel will be
able to reserve the memory before the page allocator kicks in. There
isn't any apparent reason for doing this earlier.

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Jeremy Linton 
---
 arch/arm64/mm/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 095540667f0f..fc4ab0d6d5d2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -386,8 +386,6 @@ void __init arm64_memblock_init(void)
else
arm64_dma32_phys_limit = PHYS_MASK + 1;
 
-   reserve_crashkernel();
-
reserve_elfcorehdr();
 
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
@@ -508,6 +506,8 @@ void __init mem_init(void)
else
swiotlb_force = SWIOTLB_NO_FORCE;
 
+   reserve_crashkernel();
+
set_max_mapnr(max_pfn - PHYS_PFN_OFFSET);
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
-- 
2.29.0

[PATCH v5 4/7] of: unittest: Add test for of_dma_get_max_cpu_address()

[Nicolas Saenz Julienne]

Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---
Changes since v3:
 - Remove HAS_DMA guards

 drivers/of/unittest.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 06cc988faf78..b9a4d047a95e 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -869,6 +869,23 @@ static void __init of_unittest_changeset(void)
 #endif
 }
 
+static void __init of_unittest_dma_get_max_cpu_address(void)
+{
+   struct device_node *np;
+   phys_addr_t cpu_addr;
+
+   np = of_find_node_by_path("/testcase-data/address-tests");
+   if (!np) {
+   pr_err("missing testcase data\n");
+   return;
+   }
+
+   cpu_addr = of_dma_get_max_cpu_address(np);
+   unittest(cpu_addr == 0x5000,
+"of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting 
%x)\n",
+_addr, 0x5000);
+}
+
 static void __init of_unittest_dma_ranges_one(const char *path,
u64 expect_dma_addr, u64 expect_paddr)
 {
@@ -3266,6 +3283,7 @@ static int __init of_unittest(void)
of_unittest_changeset();
of_unittest_parse_interrupts();
of_unittest_parse_interrupts_extended();
+   of_unittest_dma_get_max_cpu_address();
of_unittest_parse_dma_ranges();
of_unittest_pci_dma_ranges();
of_unittest_match_node();
-- 
2.29.0

[PATCH v5 7/7] mm: Remove examples from enum zone_type comment

[Nicolas Saenz Julienne]

We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Christoph Hellwig 
---
 include/linux/mmzone.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e..9d0c454d23cd 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -354,26 +354,6 @@ enum zone_type {
 * DMA mask is assumed when ZONE_DMA32 is defined. Some 64-bit
 * platforms may need both zones as they support peripherals with
 * different DMA addressing limitations.
-*
-* Some examples:
-*
-*  - i386 and x86_64 have a fixed 16M ZONE_DMA and ZONE_DMA32 for the
-*rest of the lower 4G.
-*
-*  - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
-*the specific device.
-*
-*  - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
-*lower 4G.
-*
-*  - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
-*depending on the specific device.
-*
-*  - s390 uses ZONE_DMA fixed to the lower 2G.
-*
-*  - ia64 and riscv only use ZONE_DMA32.
-*
-*  - parisc uses neither.
 */
 #ifdef CONFIG_ZONE_DMA
ZONE_DMA,
-- 
2.29.0

[PATCH v5 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

[Nicolas Saenz Julienne]

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

The DMA layer also needs to be able to allocate memory that is
guaranteed to meet those DMA constraints, for bounce buffering as well
as allocating the backing for consistent mappings. This is why the 1 GB
ZONE_DMA was introduced recently. Unfortunately, it turns out the having
a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and
potentially in other places where allocations cannot cross zone
boundaries. Therefore, we should avoid having two separate DMA zones
when possible.

So, with the help of of_dma_get_max_cpu_address() get the topmost
physical address accessible to all DMA masters in system and use that
information to fine-tune ZONE_DMA's size. In the absence of addressing
limited masters ZONE_DMA will span the whole 32-bit address space,
otherwise, in the case of the Raspberry Pi 4 it'll only span the 30-bit
address space, and have ZONE_DMA32 cover the rest of the 32-bit address
space.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v4:
 - Use fls64 as we're now using the max address (as opposed to the
   limit)

Changes since v3:
 - Simplify code for readability.

Changes since v2:
 - Updated commit log by shamelessly copying Ard's ACPI commit log

 arch/arm64/mm/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 410721fc4fc0..a2ce8a9a71a6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -42,8 +42,6 @@
 #include 
 #include 
 
-#define ARM64_ZONE_DMA_BITS30
-
 /*
  * We need to be able to catch inadvertent references to memstart_addr
  * that occur (potentially in generic code) before arm64_memblock_init()
@@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int 
zone_bits)
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+   unsigned int __maybe_unused dt_zone_dma_bits;
 
 #ifdef CONFIG_ZONE_DMA
-   zone_dma_bits = ARM64_ZONE_DMA_BITS;
+   dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
+   zone_dma_bits = min(32U, dt_zone_dma_bits);
arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
-- 
2.29.0

[PATCH v5 0/7] arm64: Default to 32-bit wide ZONE_DMA

[Nicolas Saenz Julienne]

Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.

I tested this on both a RPi4 and QEMU.

---

Changes since v4:
 - Fix of_dma_get_max_cpu_address() so it returns the last addressable
   addres, not the limit

Changes since v3:
 - Drop patch adding define in dma-mapping
 - Address small review changes
 - Update Ard's patch
 - Add new patch removing examples from mmzone.h

Changes since v2:
 - Introduce Ard's patch
 - Improve OF dma-ranges parsing function
 - Add unit test for OF function
 - Address small changes
 - Move crashkernel reservation later in boot process

Changes since v1:
 - Parse dma-ranges instead of using machine compatible string

Ard Biesheuvel (1):
  arm64: mm: Set ZONE_DMA size based on early IORT scan

Nicolas Saenz Julienne (6):
  arm64: mm: Move reserve_crashkernel() into mem_init()
  arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
  of/address: Introduce of_dma_get_max_cpu_address()
  of: unittest: Add test for of_dma_get_max_cpu_address()
  arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
  mm: Remove examples from enum zone_type comment

 arch/arm64/mm/init.c  | 16 ++--
 drivers/acpi/arm64/iort.c | 52 +++
 drivers/of/address.c  | 42 +++
 drivers/of/unittest.c | 18 ++
 include/linux/acpi_iort.h |  4 +++
 include/linux/mmzone.h| 20 ---
 include/linux/of.h|  7 ++
 7 files changed, 130 insertions(+), 29 deletions(-)

-- 
2.29.0

[PATCH v5 3/7] of/address: Introduce of_dma_get_max_cpu_address()

[Nicolas Saenz Julienne]

Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v4:
 - Return max address, not address limit (one-off difference)

Changes since v3:
 - use u64 with cpu_end

Changes since v2:
 - Use PHYS_ADDR_MAX
 - return phys_dma_t
 - Rename function
 - Correct subject
 - Add support to start parsing from an arbitrary device node in order
   for the function to work with unit tests

 drivers/of/address.c | 42 ++
 include/linux/of.h   |  7 +++
 2 files changed, 49 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index eb9ab4f1e80b..09c0af7fd1c4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -1024,6 +1024,48 @@ int of_dma_get_range(struct device_node *np, const 
struct bus_dma_region **map)
 }
 #endif /* CONFIG_HAS_DMA */
 
+/**
+ * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
+ * @np: The node to start searching from or NULL to start from the root
+ *
+ * Gets the highest CPU physical address that is addressable by all DMA masters
+ * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
+ * DMA constrained device is found, it returns PHYS_ADDR_MAX.
+ */
+phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
+{
+   phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
+   struct of_range_parser parser;
+   phys_addr_t subtree_max_addr;
+   struct device_node *child;
+   struct of_range range;
+   const __be32 *ranges;
+   u64 cpu_end = 0;
+   int len;
+
+   if (!np)
+   np = of_root;
+
+   ranges = of_get_property(np, "dma-ranges", );
+   if (ranges && len) {
+   of_dma_range_parser_init(, np);
+   for_each_of_range(, )
+   if (range.cpu_addr + range.size > cpu_end)
+   cpu_end = range.cpu_addr + range.size - 1;
+
+   if (max_cpu_addr > cpu_end)
+   max_cpu_addr = cpu_end;
+   }
+
+   for_each_available_child_of_node(np, child) {
+   subtree_max_addr = of_dma_get_max_cpu_address(child);
+   if (max_cpu_addr > subtree_max_addr)
+   max_cpu_addr = subtree_max_addr;
+   }
+
+   return max_cpu_addr;
+}
+
 /**
  * of_dma_is_coherent - Check if device is coherent
  * @np:device node
diff --git a/include/linux/of.h b/include/linux/of.h
index 5d51891cbf1a..9ed5b8532c30 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u32 id,
   const char *map_name, const char *map_mask_name,
   struct device_node **target, u32 *id_out);
 
+phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
+
 #else /* CONFIG_OF */
 
 static inline void of_core_init(void)
@@ -995,6 +997,11 @@ static inline int of_map_id(struct device_node *np, u32 id,
return -EINVAL;
 }
 
+static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
+{
+   return PHYS_ADDR_MAX;
+}
+
 #define of_match_ptr(_ptr) NULL
 #define of_match_node(_matches, _node) NULL
 #endif /* CONFIG_OF */
-- 
2.29.0

Re: [PATCH v4 0/7] arm64: Default to 32-bit wide ZONE_DMA

[Nicolas Saenz Julienne]

On Fri, 2020-10-23 at 14:05 -0500, Jeremy Linton wrote:
> Hi,
> 
> On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote:
> > Using two distinct DMA zones turned out to be problematic. Here's an
> > attempt go back to a saner default.
> > 
> > I tested this on both a RPi4 and QEMU.
> 
> I've tested this in ACPI mode on the rpi4 (4+8G with/without the 3G 
> limiter) as well, with Ard's IORT patch. Nothing seems to have regressed.
> 
> Thanks,
> 
> Tested-by: Jeremy Linton 

Thanks!



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 01/10] firmware: raspberrypi: Introduce rpi_firmware_put()

[Nicolas Saenz Julienne]

On Thu, 2020-10-22 at 21:46 +0300, Andy Shevchenko wrote:
> On Thu, Oct 22, 2020 at 9:06 PM Nicolas Saenz Julienne
>  wrote:
> > When unbinding the firmware device we need to make sure it has no
> > consumers left. Otherwise we'd leave them with a firmware handle
> > pointing at freed memory.
> > 
> > Keep a reference count of all consumers and make sure they all finished
> > unbinding before we do.
> 
> Wait, if it's a device, why do we need all these?
> get_device() / put_device() along with module_get() / module_put()
> should be sufficient, no?

Could you expand here a little, I do see how I could use get_device()'s
reference count. But it seems to me I'd be digging way too deep into kobj in
order to get the functionality I need.

If you meant to say that it should be automatically taken care by the platform
bus, just FYI we're using 'simple-mfd' in DT. Where firmware supplier is the
parent and all consumers are children.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 03/10] gpio: raspberrypi-exp: Release firmware handle on unbind

[Nicolas Saenz Julienne]

On Mon, 2020-10-26 at 15:40 +0100, Bartosz Golaszewski wrote:
> On Thu, Oct 22, 2020 at 5:59 PM Nicolas Saenz Julienne
>  wrote:
> > Upon unbinding the device make sure we release RPi's firmware interface.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> >  drivers/gpio/gpio-raspberrypi-exp.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpio/gpio-raspberrypi-exp.c 
> > b/drivers/gpio/gpio-raspberrypi-exp.c
> > index bb100e0124e6..c008336e1131 100644
> > --- a/drivers/gpio/gpio-raspberrypi-exp.c
> > +++ b/drivers/gpio/gpio-raspberrypi-exp.c
> > @@ -231,8 +231,19 @@ static int rpi_exp_gpio_probe(struct platform_device 
> > *pdev)
> > rpi_gpio->gc.get = rpi_exp_gpio_get;
> > rpi_gpio->gc.set = rpi_exp_gpio_set;
> > rpi_gpio->gc.can_sleep = true;
> > +   platform_set_drvdata(pdev, rpi_gpio);
> > 
> > -   return devm_gpiochip_add_data(dev, _gpio->gc, rpi_gpio);
> > +   return gpiochip_add_data(_gpio->gc, rpi_gpio);
> > +}
> > +
> > +static int rpi_exp_gpio_remove(struct platform_device *pdev)
> > +{
> > +   struct rpi_exp_gpio *rpi_gpio = platform_get_drvdata(pdev);
> > +
> > +   gpiochip_remove(_gpio->gc);
> > +   rpi_firmware_put(rpi_gpio->fw);
> > +
> > +   return 0;
> >  }
> > 
> >  static const struct of_device_id rpi_exp_gpio_ids[] = {
> > @@ -247,6 +258,7 @@ static struct platform_driver rpi_exp_gpio_driver = {
> > .of_match_table = of_match_ptr(rpi_exp_gpio_ids),
> > },
> > .probe  = rpi_exp_gpio_probe,
> > +   .remove = rpi_exp_gpio_remove,
> >  };
> >  module_platform_driver(rpi_exp_gpio_driver);
> > 
> > --
> > 2.28.0
> > 
> 
> Why not introduce devm_rpi_firmware_get()? That would allow you to
> keep the driver elegant without re-adding remove().

I like the idea, I'll look into it.

Thanks,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 05/10] soc: bcm: raspberrypi-power: Release firmware handle on unbind

[Nicolas Saenz Julienne]

On Thu, 2020-10-22 at 17:58 +0200, Nicolas Saenz Julienne wrote:
> Upon unbinding the device make sure we release RPi's firmware interface.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> ---
>  drivers/soc/bcm/raspberrypi-power.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/soc/bcm/raspberrypi-power.c 
> b/drivers/soc/bcm/raspberrypi-power.c
> index 5d1aacdd84ef..a0b38db5886c 100644
> --- a/drivers/soc/bcm/raspberrypi-power.c
> +++ b/drivers/soc/bcm/raspberrypi-power.c
> @@ -225,6 +225,20 @@ static int rpi_power_probe(struct platform_device *pdev)
>   return 0;
>  }
>  
> +static int rpi_power_remove(struct platform_device *pdev)
> +{
> + struct rpi_power_domains *rpi_domains = platform_get_drvdata(pdev);
> +
> + of_genpd_del_provider(dev->of_node);
> +
> + for (i = 0; i < RPI_POWER_DOMAIN_COUNT; i++)
> + pm_genpd_remove(_domains->domains[i].base);
> +
> + rpi_firmware_put(rpi_domaina->fw);

I Just realised I failed to squash a fix for this patch, so this will not
build. Sorry for that.

Regards,
Nicolas

> +
> + return 0;
> +}
> +
>  static const struct of_device_id rpi_power_of_match[] = {
>   { .compatible = "raspberrypi,bcm2835-power", },
>   {},
> @@ -237,6 +251,7 @@ static struct platform_driver rpi_power_driver = {
>   .of_match_table = rpi_power_of_match,
>   },
>   .probe  = rpi_power_probe,
> + .remove = rpi_power_remove,
>  };
>  builtin_platform_driver(rpi_power_driver);
>  



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 10/10] pwm: Add Raspberry Pi Firmware based PWM bus

[Nicolas Saenz Julienne]

Hi Andy, thanks for the review!

On Thu, 2020-10-22 at 21:53 +0300, Andy Shevchenko wrote:
> On Thu, Oct 22, 2020 at 9:05 PM Nicolas Saenz Julienne
>  wrote:
> > Adds support to control the PWM bus available in official Raspberry Pi
> > PoE HAT. Only RPi's co-processor has access to it, so commands have to
> > be sent through RPi's firmware mailbox interface.
> >  drivers/pwm/pwm-raspberrypi.c | 221 ++
> 
> Name is completely confusing.
> Please, make it unique enough to understand that this is exactly the
> device it serves for.
> 
> For example, pwm-rpi-poe is better.

Sounds reasonable, I'll change that.

> 
> ...
> 
> > + *  - Only normal polarity
> 
> Can't it be emulated? Isn't it 100% - duty cycle % ?

I guess it can, OTOH given the rather specific use case, I doubt it'll be
worth the effort.

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> ...
> 
> > +   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
> > +   , sizeof(msg));
> > +   if (ret)
> > +   return ret;
> > +   else if (msg.ret)
> 
> Redundant 'else'

Noted.

> > +   firmware_node = of_get_parent(dev->of_node);
> > +   if (!firmware_node) {
> > +   dev_err(dev, "Missing firmware node\n");
> > +   return -ENOENT;
> > +   }
> > +
> > +   firmware = rpi_firmware_get(firmware_node);
> > +   of_node_put(firmware_node);
> > +   if (!firmware)
> > +   return -EPROBE_DEFER;
> 
> Looks like a hack.

This is the pattern we've been using on all firmware dependent devices so far.
Feel free to suggest a better way, I'll be happy to look into it.

> 
> ...
> 
> > +   ret = pwmchip_remove(>chip);
> > +   if (!ret)
> > +   rpi_firmware_put(rpipwm->firmware);
> > +
> > +   return ret;
> 
> Can't you use the usual pattern?

Yes of course. Don't know why I went this way.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v4 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

[Nicolas Saenz Julienne]

Hi Catalin,

On Thu, 2020-10-22 at 19:06 +0100, Catalin Marinas wrote:
> On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int 
> > zone_bits)
> >  static void __init zone_sizes_init(unsigned long min, unsigned long max)
> >  {
> > unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
> > +   unsigned int __maybe_unused dt_zone_dma_bits;
> >  
> >  #ifdef CONFIG_ZONE_DMA
> > -   zone_dma_bits = ARM64_ZONE_DMA_BITS;
> > +   dt_zone_dma_bits = ilog2(of_dma_get_max_cpu_address(NULL));
> > +   zone_dma_bits = min(32U, dt_zone_dma_bits);
> 
> A thought: can we remove the min here and expand ZONE_DMA to whatever
> dt_zone_dma_bits says? More on this below.

On most platforms we'd get PHYS_ADDR_MAX, or something bigger than the actual
amount of RAM. Which would ultimately create a system wide ZONE_DMA. At first
sight, I don't see it breaking dma-direct in any way.

On the other hand, there is a big amount of MMIO devices out there that can
only handle 32-bit addressing. Be it PCI cards or actual IP cores. To make
things worse, this limitation is often expressed in the driver, not FW (with
dma_set_mask() and friends). If those devices aren't behind an IOMMU we have be
able to provide at least 32-bit addressable memory. See this comment from
dma_direct_supported():

/*
 * Because 32-bit DMA masks are so common we expect every architecture
 * to be able to satisfy them - either by not supporting more physical
 * memory, or by providing a ZONE_DMA32.  If neither is the case, the
 * architecture needs to use an IOMMU instead of the direct mapping.
 */

I think, for the common case, we're stuck with at least one zone spanning the
32-bit address space.

> > arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
> > max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
> >  #endif
> 
> I was talking earlier to Ard and Robin on the ZONE_DMA32 history and the
> need for max_zone_phys(). This was rather theoretical, the Seattle
> platform has all RAM starting above 4GB and that led to an empty
> ZONE_DMA32 originally. The max_zone_phys() hack was meant to lift
> ZONE_DMA32 into the bottom of the RAM, on the assumption that such
> 32-bit devices would have a DMA offset hardwired. We are not aware of
> any such case on arm64 systems and even on Seattle, IIUC 32-bit devices
> only work if they are behind an SMMU (so no hardwired offset).
> 
> In hindsight, it would have made more sense on platforms with RAM above
> 4GB to expand ZONE_DMA32 to cover the whole memory (so empty
> ZONE_NORMAL). Something like:
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index a53c1e0fb017..7d5e3dd85617 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -187,8 +187,12 @@ static void __init reserve_elfcorehdr(void)
>   */
>  static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
>  {
> - phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 
> zone_bits);
> - return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
> + phys_addr_t zone_mask = 1ULL << zone_bits;
> +
> + if (!(memblock_start_of_DRAM() & zone_mask))
> + zone_mask = PHYS_ADDR_MAX;
> +
> + return min(zone_mask, memblock_end_of_DRAM());
>  }
>  
>  static void __init zone_sizes_init(unsigned long min, unsigned long max)
> 
> I don't think this makes any difference for ZONE_DMA unless a
> broken DT or IORT reports the max CPU address below the start of DRAM.
> 
> There's a minor issue if of_dma_get_max_cpu_address() matches
> memblock_end_of_DRAM() but they are not a power of 2. We'd be left with
> a bit of RAM at the end in ZONE_NORMAL due to ilog2 truncation.

I agree it makes no sense to create more than one zone when the beginning of
RAM is located above the 32-bit address space. I'm all for disregarding the
possibility of hardwired offsets. As a bonus, as we already discussed some time
ago, this is something that never played well with current dma-direct code[1].

Regards,
Nicolas

[1] https://lkml.org/lkml/2020/9/8/377



signature.asc
Description: This is a digitally signed message part

[PATCH v2 06/10] staging: vchiq: Release firmware handle on unbind

[Nicolas Saenz Julienne]

Upon unbinding the device make sure we release RPi's firmware interface.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 01125d9f991b..dfa4d144faa8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2771,11 +2771,14 @@ static int vchiq_probe(struct platform_device *pdev)
 
 static int vchiq_remove(struct platform_device *pdev)
 {
+   struct vchiq_drvdata *drvdata = platform_get_drvdata(pdev);
+
platform_device_unregister(bcm2835_audio);
platform_device_unregister(bcm2835_camera);
vchiq_debugfs_deinit();
device_destroy(vchiq_class, vchiq_devid);
cdev_del(_cdev);
+   rpi_firmware_put(drvdata->fw);
 
return 0;
 }
-- 
2.28.0

[PATCH v2 09/10] DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support

[Nicolas Saenz Julienne]

This is an example on how to enable the fan on top of RPi's official PoE
hat.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v1:
 - Update patch to use 2 pwm cells

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182c2936..361db82619a4 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -5,6 +5,7 @@
 #include "bcm283x-rpi-usb-peripheral.dtsi"
 
 #include 
+#include 
 
 / {
compatible = "raspberrypi,4-model-b", "brcm,bcm2711";
@@ -68,6 +69,54 @@ sd_vcc_reg: sd_vcc_reg {
enable-active-high;
gpio = < 6 GPIO_ACTIVE_HIGH>;
};
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 50 150 255>;
+   #cooling-cells = <2>;
+   pwms = < RASPBERRYPI_FIRMWARE_PWM_POE 8>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   trips {
+   threshold: trip-point@0 {
+   temperature = <45000>;
+   hysteresis = <5000>;
+   type = "active";
+   };
+
+   target: trip-point@1 {
+   temperature = <5>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+
+   cpu_hot: cpu_hot@0 {
+   temperature = <55000>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 0 1>;
+   };
+
+   map1 {
+   trip = <>;
+   cooling-device = < 1 2>;
+   };
+
+   map2 {
+   trip = <_hot>;
+   cooling-device = < 2 3>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -103,6 +152,11 @@ reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
};
+
+   fwpwm: pwm {
+   compatible = "raspberrypi,firmware-pwm";
+   #pwm-cells = <2>;
+   };
 };
 
  {
-- 
2.28.0