* [PATCH v2 2/2] hwmon: raspberrypi: Add voltage input support
From: Shubham Chakraborty @ 2026-05-16 19:15 UTC (permalink / raw)
To: Guenter Roeck, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Shubham Chakraborty
In-Reply-To: <20260516191555.17978-1-chakrabortyshubham66@gmail.com>
Extend the raspberrypi-hwmon driver to expose firmware-provided
voltage measurements through the hwmon subsystem.
The driver now exports the following voltage inputs:
- in0_input (core)
- in1_input (sdram_c)
- in2_input (sdram_i)
- in3_input (sdram_p)
Voltage values returned by firmware are converted from microvolts
to millivolts as expected by the hwmon subsystem.
Update the documentation related to it.
The existing undervoltage sticky alarm handling is preserved and
associated with the first voltage channel.
Tested in -
- Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT
Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
Documentation/hwmon/raspberrypi-hwmon.rst | 15 ++-
drivers/hwmon/raspberrypi-hwmon.c | 134 +++++++++++++++++++++-
2 files changed, 144 insertions(+), 5 deletions(-)
diff --git a/Documentation/hwmon/raspberrypi-hwmon.rst b/Documentation/hwmon/raspberrypi-hwmon.rst
index 8038ade36490..db315184b861 100644
--- a/Documentation/hwmon/raspberrypi-hwmon.rst
+++ b/Documentation/hwmon/raspberrypi-hwmon.rst
@@ -20,6 +20,17 @@ undervoltage conditions.
Sysfs entries
-------------
-======================= ==================
+======================= ======================================================
+in0_input Core voltage in millivolts
+in1_input SDRAM controller voltage in millivolts
+in2_input SDRAM I/O voltage in millivolts
+in3_input SDRAM PHY voltage in millivolts
+in0_label "core"
+in1_label "sdram_c"
+in2_label "sdram_i"
+in3_label "sdram_p"
in0_lcrit_alarm Undervoltage alarm
-======================= ==================
+======================= ======================================================
+
+The voltage inputs and labels are only exposed if the firmware reports support
+for the corresponding voltage ID.
diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
index a2938881ccd2..4f96f37116f3 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -5,6 +5,7 @@
* Based on firmware/raspberrypi.c by Noralf Trønnes
*
* Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
+ * Copyright (C) 2026 Shubham Chakraborty <chakrabortyshubham66@gmail.com>
*/
#include <linux/device.h>
#include <linux/devm-helpers.h>
@@ -18,13 +19,26 @@
#define UNDERVOLTAGE_STICKY_BIT BIT(16)
+struct rpi_firmware_get_value {
+ __le32 id;
+ __le32 val;
+} __packed;
+
struct rpi_hwmon_data {
struct device *hwmon_dev;
struct rpi_firmware *fw;
+ u32 valid_inputs;
u32 last_throttled;
struct delayed_work get_values_poll_work;
};
+static const char * const rpi_hwmon_labels[] = {
+ "core",
+ "sdram_c",
+ "sdram_i",
+ "sdram_p",
+};
+
static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
{
u32 new_uv, old_uv, value;
@@ -56,6 +70,23 @@ static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
hwmon_notify_event(data->hwmon_dev, hwmon_in, hwmon_in_lcrit_alarm, 0);
}
+static int rpi_firmware_get_voltage(struct rpi_hwmon_data *data, u32 id,
+ long *val)
+{
+ struct rpi_firmware_get_value packet;
+ int ret;
+
+ packet.id = cpu_to_le32(id);
+ packet.val = 0;
+ ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_VOLTAGE,
+ &packet, sizeof(packet));
+ if (ret)
+ return ret;
+
+ *val = le32_to_cpu(packet.val) / 1000;
+ return 0;
+}
+
static void get_values_poll(struct work_struct *work)
{
struct rpi_hwmon_data *data;
@@ -77,19 +108,94 @@ static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
{
struct rpi_hwmon_data *data = dev_get_drvdata(dev);
- *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
+ if (type == hwmon_in) {
+ switch (attr) {
+ case hwmon_in_input:
+ switch (channel) {
+ case 0:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_CORE,
+ val);
+ case 1:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_C,
+ val);
+ case 2:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_I,
+ val);
+ case 3:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_P,
+ val);
+ default:
+ return -EOPNOTSUPP;
+ }
+ case hwmon_in_lcrit_alarm:
+ if (channel == 0) {
+ *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
+ return 0;
+ }
+ return -EOPNOTSUPP;
+ default:
+ return -EOPNOTSUPP;
+ }
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static int rpi_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ if (type == hwmon_in && attr == hwmon_in_label) {
+ if (channel >= ARRAY_SIZE(rpi_hwmon_labels))
+ return -EOPNOTSUPP;
+
+ *str = rpi_hwmon_labels[channel];
+ return 0;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static umode_t rpi_is_visible(const void *_data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct rpi_hwmon_data *data = _data;
+
+ if (type == hwmon_in) {
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ if (!(data->valid_inputs & BIT(channel)))
+ return 0;
+ return 0444;
+ case hwmon_in_lcrit_alarm:
+ if (channel == 0)
+ return 0444;
+ return 0;
+ default:
+ return 0;
+ }
+ }
+
return 0;
}
static const struct hwmon_channel_info * const rpi_info[] = {
HWMON_CHANNEL_INFO(in,
- HWMON_I_LCRIT_ALARM),
+ HWMON_I_INPUT | HWMON_I_LABEL | HWMON_I_LCRIT_ALARM,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL),
NULL
};
static const struct hwmon_ops rpi_hwmon_ops = {
- .visible = 0444,
+ .is_visible = rpi_is_visible,
.read = rpi_read,
+ .read_string = rpi_read_string,
};
static const struct hwmon_chip_info rpi_chip_info = {
@@ -101,6 +207,7 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct rpi_hwmon_data *data;
+ long voltage;
int ret;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
@@ -110,6 +217,26 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
/* Parent driver assure that firmware is correct */
data->fw = dev_get_drvdata(dev->parent);
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_CORE,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(0);
+
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_C,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(1);
+
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_I,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(2);
+
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_P,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(3);
+
data->hwmon_dev = devm_hwmon_device_register_with_info(dev, "rpi_volt",
data,
&rpi_chip_info,
@@ -159,6 +286,7 @@ static struct platform_driver rpi_hwmon_driver = {
module_platform_driver(rpi_hwmon_driver);
MODULE_AUTHOR("Stefan Wahren <wahrenst@gmx.net>");
+MODULE_AUTHOR("Shubham Chakraborty <chakrabortyshubham66@gmail.com>");
MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:raspberrypi-hwmon");
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
From: Guenter Roeck @ 2026-05-16 23:09 UTC (permalink / raw)
To: Shubham Chakraborty, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260516191555.17978-2-chakrabortyshubham66@gmail.com>
On 5/16/26 12:15, Shubham Chakraborty wrote:
> Add firmware voltage domain identifiers for the Raspberry Pi
> mailbox property interface.
>
> These IDs are used by firmware clients to query voltage rails
> through the RPI_FIRMWARE_GET_VOLTAGE property.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> ---
> include/soc/bcm2835/raspberrypi-firmware.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index e1f87fbfe554..fd2e051ce05b 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -156,6 +156,14 @@ enum rpi_firmware_clk_id {
> RPI_FIRMWARE_NUM_CLK_ID,
> };
>
> +enum rpi_firmware_volt_id {
> + RPI_FIRMWARE_VOLT_ID_RESERVED = 0,
Is that needed ?
> + RPI_FIRMWARE_VOLT_ID_CORE = 1,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_C = 2,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_I = 3,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_P = 4,
Regarding Sashiko's feedback: I don't know where it got the
information from, but a web search suggests that it has a point;
RPI_FIRMWARE_VOLT_ID_SDRAM_I and RPI_FIRMWARE_VOLT_ID_SDRAM_P appear
to be swapped. If that is not the case, please provide evidence.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: raspberrypi: Add voltage input support
From: Guenter Roeck @ 2026-05-16 23:20 UTC (permalink / raw)
To: Shubham Chakraborty, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260516191555.17978-3-chakrabortyshubham66@gmail.com>
On 5/16/26 12:15, Shubham Chakraborty wrote:
> Extend the raspberrypi-hwmon driver to expose firmware-provided
> voltage measurements through the hwmon subsystem.
>
> The driver now exports the following voltage inputs:
>
> - in0_input (core)
> - in1_input (sdram_c)
> - in2_input (sdram_i)
> - in3_input (sdram_p)
>
> Voltage values returned by firmware are converted from microvolts
> to millivolts as expected by the hwmon subsystem.
>
> Update the documentation related to it.
>
> The existing undervoltage sticky alarm handling is preserved and
> associated with the first voltage channel.
>
> Tested in -
> - Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT
> Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> ---
> Documentation/hwmon/raspberrypi-hwmon.rst | 15 ++-
> drivers/hwmon/raspberrypi-hwmon.c | 134 +++++++++++++++++++++-
> 2 files changed, 144 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/hwmon/raspberrypi-hwmon.rst b/Documentation/hwmon/raspberrypi-hwmon.rst
> index 8038ade36490..db315184b861 100644
> --- a/Documentation/hwmon/raspberrypi-hwmon.rst
> +++ b/Documentation/hwmon/raspberrypi-hwmon.rst
> @@ -20,6 +20,17 @@ undervoltage conditions.
> Sysfs entries
> -------------
>
> -======================= ==================
> +======================= ======================================================
> +in0_input Core voltage in millivolts
> +in1_input SDRAM controller voltage in millivolts
> +in2_input SDRAM I/O voltage in millivolts
> +in3_input SDRAM PHY voltage in millivolts
> +in0_label "core"
> +in1_label "sdram_c"
> +in2_label "sdram_i"
> +in3_label "sdram_p"
> in0_lcrit_alarm Undervoltage alarm
> -======================= ==================
> +======================= ======================================================
> +
> +The voltage inputs and labels are only exposed if the firmware reports support
> +for the corresponding voltage ID.
> diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
> index a2938881ccd2..4f96f37116f3 100644
> --- a/drivers/hwmon/raspberrypi-hwmon.c
> +++ b/drivers/hwmon/raspberrypi-hwmon.c
> @@ -5,6 +5,7 @@
> * Based on firmware/raspberrypi.c by Noralf Trønnes
> *
> * Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
> + * Copyright (C) 2026 Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> */
> #include <linux/device.h>
> #include <linux/devm-helpers.h>
> @@ -18,13 +19,26 @@
>
> #define UNDERVOLTAGE_STICKY_BIT BIT(16)
>
> +struct rpi_firmware_get_value {
> + __le32 id;
> + __le32 val;
> +} __packed;
My earlier comment is still valid: This should be defined in
the include file, and it should be query-specific, just like
struct rpi_firmware_clk_rate_request.
> +
> struct rpi_hwmon_data {
> struct device *hwmon_dev;
> struct rpi_firmware *fw;
> + u32 valid_inputs;
> u32 last_throttled;
> struct delayed_work get_values_poll_work;
> };
>
> +static const char * const rpi_hwmon_labels[] = {
> + "core",
> + "sdram_c",
> + "sdram_i",
> + "sdram_p",
> +};
> +
> static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> {
> u32 new_uv, old_uv, value;
> @@ -56,6 +70,23 @@ static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> hwmon_notify_event(data->hwmon_dev, hwmon_in, hwmon_in_lcrit_alarm, 0);
> }
>
> +static int rpi_firmware_get_voltage(struct rpi_hwmon_data *data, u32 id,
> + long *val)
> +{
> + struct rpi_firmware_get_value packet;
> + int ret;
> +
> + packet.id = cpu_to_le32(id);
> + packet.val = 0;
> + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_VOLTAGE,
> + &packet, sizeof(packet));
> + if (ret)
> + return ret;
> +
> + *val = le32_to_cpu(packet.val) / 1000;
I would suggest to use DIV_ROUND_CLOSEST().
> + return 0;
> +}
> +
> static void get_values_poll(struct work_struct *work)
> {
> struct rpi_hwmon_data *data;
> @@ -77,19 +108,94 @@ static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
> {
> struct rpi_hwmon_data *data = dev_get_drvdata(dev);
>
> - *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
> + if (type == hwmon_in) {
> + switch (attr) {
> + case hwmon_in_input:
> + switch (channel) {
> + case 0:
> + return rpi_firmware_get_voltage(data,
> + RPI_FIRMWARE_VOLT_ID_CORE,
> + val);
> + case 1:
> + return rpi_firmware_get_voltage(data,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_C,
> + val);
> + case 2:
> + return rpi_firmware_get_voltage(data,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_I,
> + val);
> + case 3:
> + return rpi_firmware_get_voltage(data,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_P,
> + val);
> + default:
> + return -EOPNOTSUPP;
With
static const int voltage_regs[] = {
RPI_FIRMWARE_VOLT_ID_CORE, RPI_FIRMWARE_VOLT_ID_SDRAM_C, RPI_FIRMWARE_VOLT_ID_SDRAM_I,
RPI_FIRMWARE_VOLT_ID_SDRAM_P };
this can be simplified to
return rpi_firmware_get_voltage(data, voltage_regs[channel];
> + }
> + case hwmon_in_lcrit_alarm:
> + if (channel == 0) {
> + *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
> + return 0;
> + }
The channel check is not really necessary.
> + return -EOPNOTSUPP;
> + default:
> + return -EOPNOTSUPP;
> + }
> + }
> +
> + return -EOPNOTSUPP;
> +}
> +
> +static int rpi_read_string(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, const char **str)
> +{
> + if (type == hwmon_in && attr == hwmon_in_label) {
> + if (channel >= ARRAY_SIZE(rpi_hwmon_labels))
> + return -EOPNOTSUPP;
Unnecessary check.
> +
> + *str = rpi_hwmon_labels[channel];
> + return 0;
> + }
> +
> + return -EOPNOTSUPP;
> +}
> +
> +static umode_t rpi_is_visible(const void *_data, enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + const struct rpi_hwmon_data *data = _data;
> +
> + if (type == hwmon_in) {
> + switch (attr) {
> + case hwmon_in_input:
> + case hwmon_in_label:
> + if (!(data->valid_inputs & BIT(channel)))
> + return 0;
> + return 0444;
> + case hwmon_in_lcrit_alarm:
> + if (channel == 0)
> + return 0444;
> + return 0;
> + default:
> + return 0;
> + }
> + }
> +
> return 0;
> }
>
> static const struct hwmon_channel_info * const rpi_info[] = {
> HWMON_CHANNEL_INFO(in,
> - HWMON_I_LCRIT_ALARM),
> + HWMON_I_INPUT | HWMON_I_LABEL | HWMON_I_LCRIT_ALARM,
> + HWMON_I_INPUT | HWMON_I_LABEL,
> + HWMON_I_INPUT | HWMON_I_LABEL,
> + HWMON_I_INPUT | HWMON_I_LABEL),
> NULL
> };
>
> static const struct hwmon_ops rpi_hwmon_ops = {
> - .visible = 0444,
> + .is_visible = rpi_is_visible,
> .read = rpi_read,
> + .read_string = rpi_read_string,
> };
>
> static const struct hwmon_chip_info rpi_chip_info = {
> @@ -101,6 +207,7 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct rpi_hwmon_data *data;
> + long voltage;
> int ret;
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> @@ -110,6 +217,26 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
> /* Parent driver assure that firmware is correct */
> data->fw = dev_get_drvdata(dev->parent);
>
> + ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_CORE,
> + &voltage);
> + if (!ret)
> + data->valid_inputs |= BIT(0);
> +
> + ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_C,
> + &voltage);
> + if (!ret)
> + data->valid_inputs |= BIT(1);
> +
> + ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_I,
> + &voltage);
> + if (!ret)
> + data->valid_inputs |= BIT(2);
> +
> + ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_P,
> + &voltage);
> + if (!ret)
> + data->valid_inputs |= BIT(3);
> +
This can be implemented in a loop, using the above voltage_regs array.
Thanks,
Guenter
> data->hwmon_dev = devm_hwmon_device_register_with_info(dev, "rpi_volt",
> data,
> &rpi_chip_info,
> @@ -159,6 +286,7 @@ static struct platform_driver rpi_hwmon_driver = {
> module_platform_driver(rpi_hwmon_driver);
>
> MODULE_AUTHOR("Stefan Wahren <wahrenst@gmx.net>");
> +MODULE_AUTHOR("Shubham Chakraborty <chakrabortyshubham66@gmail.com>");
> MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("platform:raspberrypi-hwmon");
^ permalink raw reply
* [PATCH] crypto: atmel-sha - use memcpy_and_pad to simplify hmac_setup
From: Thorsten Blum @ 2026-05-16 23:42 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Use memcpy_and_pad() instead of memcpy() followed by memset() to
simplify atmel_sha_hmac_setup().
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 1f1341a16c42..f60c7c8cf912 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -1731,8 +1731,7 @@ static int atmel_sha_hmac_setup(struct atmel_sha_dev *dd,
return atmel_sha_hmac_prehash_key(dd, key, keylen);
/* Prepare ipad. */
- memcpy((u8 *)hmac->ipad, key, keylen);
- memset((u8 *)hmac->ipad + keylen, 0, bs - keylen);
+ memcpy_and_pad(hmac->ipad, bs, key, keylen, 0);
return atmel_sha_hmac_compute_ipad_hash(dd);
}
^ permalink raw reply related
* Re: [PATCH] ASoC: sun4i-spdif: Use guard() for spin locks
From: Bui Duc Phuc @ 2026-05-16 23:50 UTC (permalink / raw)
To: sashiko-reviews, Mark Brown
Cc: linux-sunxi, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Marcus Cooper,
Chen Ni, linux-sound, linux-arm-kernel, linux-kernel
In-Reply-To: <CAABR9nGZM3Bnb3DnObdp2nOJmW6ezmXqRSBtgS00Ps2ve4zsbg@mail.gmail.com>
Hi all
I would like to make a small correction to my previous email, and
also confirm one additional point before preparing another patch.
Correction:
> However, I also looked at a similar case in the
> micfil_rate_set() function from the fsl_micfil driver:
> https://elixir.bootlin.com/linux/v7.1-rc3/source/sound/soc/fsl/fsl_micfil.c
In my previous email, I referred to the function as
micfil_rate_set(), but the correct name is
micfil_range_set().
Additional point for confirmation:
Currently, in sun4i_spdif_runtime_suspend(), the clocks are
disabled in the following order:
clk_disable_unprepare(host->spdif_clk);
clk_disable_unprepare(host->apb_clk);
Meanwhile, in sun4i_spdif_runtime_resume(), the clocks are
enabled in this order:
clk_prepare_enable(host->spdif_clk);
ret = clk_prepare_enable(host->apb_clk);
I checked the binding documentation here:
https://elixir.bootlin.com/linux/v7.1-rc3/source/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml
It describes the clocks as:
properties:
clocks:
items:
- description: Bus Clock
- description: Module Clock
clock-names:
items:
- const: apb
- const: spdif
From my understanding, apb_clk is the bus clock, while
spdif_clk is the module clock.
If that understanding is correct, then the suspend path seems
reasonable since the module clock is disabled before the bus
clock.
However, in the resume path, the module clock is currently
enabled before the bus clock. It may make more sense to enable
the bus clock first, followed by the module clock.
If my understanding is correct, I would like to prepare an
additional patch to reorder the clock enable sequence.
Please let me know if this interpretation makes sense.
Best Regard,
Phuc
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: stm: stm32_i2s: Use guard() for spin locks
From: Bui Duc Phuc @ 2026-05-17 0:18 UTC (permalink / raw)
To: Mark Brown
Cc: Olivier Moysan, Arnaud Pouliquen, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Maxime Coquelin, Alexandre Torgue, linux-sound,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <agfd4gvQ_m3Zt8GP@sirena.co.uk>
Hi Mark,
> There are likely to be different considerations for different drivers,
> on some systems the power savings from managing the clocks may not be
> meaingful or we may need the clocks for register access. In general
> it's nicer to actively manage the clocks but it's not super urgent to do
> so from a framework point of view, it's more a how much work the people
> working on the individual drivers want to do and if there's a use case
> for specific hardware.
Understood, and thank you for the clarification.
That gives me a better understanding of the considerations around PM/clock
handling in these drivers.
Best Regard,
Phuc
^ permalink raw reply
* [PATCH] iommu/arm-smmu: pass smmu->dev to report_iommu_fault
From: Shyam Saini @ 2026-05-17 0:50 UTC (permalink / raw)
To: iommu
Cc: linux-arm-kernel, linux-arm-msm, robin.clark, will, robin.murphy,
joro, stable
report_iommu_fault() passes the dev argument to trace_io_page_fault(),
which dereferences it via dev_name() and dev_driver_string(). Passing
NULL causes a kernel crash when the io_page_fault tracepoint is
enabled.
In arm-smmu.c, 'commit f8f934c180f6 ("iommu/arm-smmu: Add support for driver IOMMU fault handlers")'
replaced a dev_err_ratelimited() call that correctly used smmu->dev with
report_iommu_fault() but passed NULL instead.
In arm-smmu-qcom-debug.c, 'commit d374555ef993 ("iommu/arm-smmu-qcom: Use a custom context fault handler for sdm845")'
introduced two report_iommu_fault() calls also with NULL.
Pass smmu->dev to all three call sites.
Fixes: f8f934c180f629bb ("iommu/arm-smmu: Add support for driver IOMMU fault handlers")
Fixes: d374555ef993433f ("iommu/arm-smmu-qcom: Use a custom context fault handler for sdm845")
Cc: stable@vger.kernel.org
Assisted-by: GitHub_Copilot:claude-opus-4.6
Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 4 ++--
drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index 65e0ef6539fe7..8eb9f7831de07 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -399,7 +399,7 @@ irqreturn_t qcom_smmu_context_fault(int irq, void *dev)
return IRQ_NONE;
if (list_empty(&tbu_list)) {
- ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
+ ret = report_iommu_fault(&smmu_domain->domain, smmu->dev, cfi.iova,
cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
if (ret == -ENOSYS)
@@ -417,7 +417,7 @@ irqreturn_t qcom_smmu_context_fault(int irq, void *dev)
phys_soft = ops->iova_to_phys(ops, cfi.iova);
- tmp = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
+ tmp = report_iommu_fault(&smmu_domain->domain, smmu->dev, cfi.iova,
cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
if (!tmp || tmp == -EBUSY) {
ret = IRQ_HANDLED;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 0bd21d206eb3e..92d8fa2100adb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -467,7 +467,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT))
return IRQ_NONE;
- ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
+ ret = report_iommu_fault(&smmu_domain->domain, smmu->dev, cfi.iova,
cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
if (ret == -ENOSYS && __ratelimit(&rs))
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM: riscpc: remove always-true GCC 6 requirement
From: Ethan Nelson-Moore @ 2026-05-17 2:45 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Russell King, Ethan Nelson-Moore
The minimum version of GCC required to compile the kernel has been GCC
8 since commit 118c40b7b503 ("kbuild: require gcc-8 and
binutils-2.30"). Therefore, checking for older GCC versions is
unnecessary. Remove code enforcing a requirement of GCC 6 in
mach-rpc/Kconfig.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/mach-rpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/Kconfig b/arch/arm/mach-rpc/Kconfig
index 55f6d829b677..fea08f20b9cf 100644
--- a/arch/arm/mach-rpc/Kconfig
+++ b/arch/arm/mach-rpc/Kconfig
@@ -2,7 +2,7 @@ config ARCH_RPC
bool "RiscPC"
depends on ARCH_MULTI_V4 && !(ARCH_MULTI_V4T || ARCH_MULTI_V5)
depends on !(ARCH_FOOTBRIDGE || ARCH_SA1100 || ARCH_MOXART || ARCH_GEMINI)
- depends on !CC_IS_CLANG && GCC_VERSION < 90100 && GCC_VERSION >= 60000
+ depends on !CC_IS_CLANG && GCC_VERSION < 90100
depends on CPU_LITTLE_ENDIAN
depends on ATAGS
depends on MMU
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM64: remove unnecessary architecture-specific <asm/device.h>
From: Ethan Nelson-Moore @ 2026-05-17 2:53 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Ethan Nelson-Moore, Catalin Marinas, Will Deacon
arch/arm64/include/asm/device.h is identical to
include/asm-generic/device.h, and therefore the ARM64-specific version
is unnecessary. Remove it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm64/include/asm/device.h | 14 --------------
1 file changed, 14 deletions(-)
delete mode 100644 arch/arm64/include/asm/device.h
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
deleted file mode 100644
index 996498751318..000000000000
--- a/arch/arm64/include/asm/device.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) 2012 ARM Ltd.
- */
-#ifndef __ASM_DEVICE_H
-#define __ASM_DEVICE_H
-
-struct dev_archdata {
-};
-
-struct pdev_archdata {
-};
-
-#endif
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM: remove unnecessary architecture-specific <asm/asm-offsets.h>
From: Ethan Nelson-Moore @ 2026-05-17 3:04 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ethan Nelson-Moore, Russell King
arch/arm/include/asm/asm-offsets.h is identical to
include/asm-generic/asm-offsets.h, and therefore the ARM-specific
version is unnecessary. Remove it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/include/asm/asm-offsets.h | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 arch/arm/include/asm/asm-offsets.h
diff --git a/arch/arm/include/asm/asm-offsets.h b/arch/arm/include/asm/asm-offsets.h
deleted file mode 100644
index d370ee36a182..000000000000
--- a/arch/arm/include/asm/asm-offsets.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <generated/asm-offsets.h>
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ARM: remove unnecessary architecture-specific <asm/asm-offsets.h>
From: Ethan Nelson-Moore @ 2026-05-17 3:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Russell King
In-Reply-To: <20260517030408.100043-1-enelsonmoore@gmail.com>
On Sat, May 16, 2026 at 8:04 PM Ethan Nelson-Moore
<enelsonmoore@gmail.com> wrote:
>
> arch/arm/include/asm/asm-offsets.h is identical to
> include/asm-generic/asm-offsets.h, and therefore the ARM-specific
> version is unnecessary. Remove it.
Please ignore this patch - I did not compile test it (because it
seemed so trivial... lesson learned!) and I didn't realize
asm-offsets.h was required to exist in each architecture.
Sorry for the noise!
Ethan
^ permalink raw reply
* [PATCH] ARM: clean up machine-specific PCI code and move it into mach-footbridge
From: Ethan Nelson-Moore @ 2026-05-17 4:24 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ethan Nelson-Moore, Russell King
arch/arm/include/asm/mach/pci.h contains function definitions specific
to Intel IOP3xx and the DC21285 Footbridge chip. This machine-specific
code should not be in a global include file. The last IOP3xx platform
supported was removed in commit b91a69d162aa ("ARM: iop32x: remove the
platform"), so the IOP3xx definitions are unused. Remove them and move
the DC21285 definitions into mach-footbridge.
Tested by compiling footbridge_defconfig and netwinder_defconfig.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/include/asm/mach/pci.h | 13 -------------
| 2 ++
| 2 ++
| 2 ++
| 12 ++++++++++++
5 files changed, 18 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/mach-footbridge/pci.h
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index ea9bd08895b7..ece5283bdaec 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -70,17 +70,4 @@ extern void pci_map_io_early(unsigned long pfn);
static inline void pci_map_io_early(unsigned long pfn) {}
#endif
-/*
- * PCI controllers
- */
-extern struct pci_ops iop3xx_ops;
-extern int iop3xx_pci_setup(int nr, struct pci_sys_data *);
-extern void iop3xx_pci_preinit(void);
-extern void iop3xx_pci_preinit_cond(void);
-
-extern struct pci_ops dc21285_ops;
-extern int dc21285_setup(int nr, struct pci_sys_data *);
-extern void dc21285_preinit(void);
-extern void dc21285_postinit(void);
-
#endif /* __ASM_MACH_PCI_H */
--git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
index e1b336624883..5a68b6739ecf 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -21,6 +21,8 @@
#include <asm/mach/pci.h>
#include <asm/hardware/dec21285.h>
+#include "pci.h"
+
#define MAX_SLOTS 21
#define PCICMD_ABORT ((PCI_STATUS_REC_MASTER_ABORT| \
--git a/arch/arm/mach-footbridge/ebsa285-pci.c b/arch/arm/mach-footbridge/ebsa285-pci.c
index c3f280d08fa7..797485249d0c 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -14,6 +14,8 @@
#include <asm/mach/pci.h>
#include <asm/mach-types.h>
+#include "pci.h"
+
static int irqmap_ebsa285[] = { IRQ_IN3, IRQ_IN1, IRQ_IN0, IRQ_PCI };
static int ebsa285_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
--git a/arch/arm/mach-footbridge/netwinder-pci.c b/arch/arm/mach-footbridge/netwinder-pci.c
index e8304392074b..66fedf182744 100644
--- a/arch/arm/mach-footbridge/netwinder-pci.c
+++ b/arch/arm/mach-footbridge/netwinder-pci.c
@@ -14,6 +14,8 @@
#include <asm/mach/pci.h>
#include <asm/mach-types.h>
+#include "pci.h"
+
/*
* We now use the slot ID instead of the device identifiers to select
* which interrupt is routed where.
--git a/arch/arm/mach-footbridge/pci.h b/arch/arm/mach-footbridge/pci.h
new file mode 100644
index 000000000000..8616e9fe6c8c
--- /dev/null
+++ b/arch/arm/mach-footbridge/pci.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __FOOTBRIDGE_PCI_H
+#define __FOOTBRIDGE_PCI_H
+
+/* PCI controller-related definitions for the DC21285 Footbridge chip */
+extern struct pci_ops dc21285_ops;
+extern int dc21285_setup(int nr, struct pci_sys_data *sys);
+extern void dc21285_preinit(void);
+extern void dc21285_postinit(void);
+
+#endif /* __FOOTBRIDGE_PCI_H */
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM: Move Footbridge-specific header into mach-footbridge
From: Ethan Nelson-Moore @ 2026-05-17 4:57 UTC (permalink / raw)
To: linux-arm-kernel, linux-serial, linux-watchdog
Cc: Ethan Nelson-Moore, Russell King, Arnd Bergmann,
Greg Kroah-Hartman, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Jiri Slaby, Wim Van Sebroeck, Guenter Roeck
arch/arm/include/asm/hardware/dec21285.h is specific to the DC21285
Footbridge chip and should not be in the global ARM include directory.
Move it into mach-footbridge where it belongs. It was included twice in
arch/arm/mach-footbridge/common.c; remove one of the includes.
Also remove the file path from the header (it is bad style and would
become outdated) and add missing include guards.
Tested by compiling footbridge_defconfig and netwinder_defconfig,
modified to additionally enable CONFIG_MTD_DC21285 and
CONFIG_DEBUG_FOOTBRIDGE_COM1 or CONFIG_DEBUG_DC21285_PORT, respectively
(these are the only Footbridge-related options not enabled by the
defconfigs).
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
This patch depends on my previous patch "ARM: clean up machine-specific
PCI code and move it into mach-footbridge" because it touches the same
area of arch/arm/mach-footbridge/dc21285.c.
MAINTAINERS | 1 -
arch/arm/include/debug/dc21285.S | 2 +-
| 3 +--
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 8 +++++---
| 2 +-
| 2 +-
| 2 +-
drivers/char/nwflash.c | 2 +-
drivers/mtd/maps/dc21285.c | 2 +-
drivers/tty/serial/21285.c | 2 +-
drivers/watchdog/wdt285.c | 2 +-
15 files changed, 18 insertions(+), 18 deletions(-)
rename arch/arm/{include/asm/hardware => mach-footbridge/include/mach}/dec21285.h (98%)
diff --git a/MAINTAINERS b/MAINTAINERS
index c2c6d79275c6..37ecfe4bc4e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2811,7 +2811,6 @@ M: Russell King <linux@armlinux.org.uk>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
W: http://www.armlinux.org.uk/
-F: arch/arm/include/asm/hardware/dec21285.h
F: arch/arm/mach-footbridge/
ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
diff --git a/arch/arm/include/debug/dc21285.S b/arch/arm/include/debug/dc21285.S
index 4ec0e5e31704..c0eb58ba7d7e 100644
--- a/arch/arm/include/debug/dc21285.S
+++ b/arch/arm/include/debug/dc21285.S
@@ -7,7 +7,7 @@
* Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
*/
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <mach/hardware.h>
/* For EBSA285 debugging */
--git a/arch/arm/mach-footbridge/common.c b/arch/arm/mach-footbridge/common.c
index 85c598708c10..d3076bf03875 100644
--- a/arch/arm/mach-footbridge/common.c
+++ b/arch/arm/mach-footbridge/common.c
@@ -20,7 +20,6 @@
#include <asm/mach-types.h>
#include <asm/setup.h>
#include <asm/system_misc.h>
-#include <asm/hardware/dec21285.h>
#include <asm/mach/irq.h>
#include <asm/mach/map.h>
@@ -30,7 +29,7 @@
#include <mach/hardware.h>
#include <mach/irqs.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
static int dc21285_get_irq(void)
{
--git a/arch/arm/mach-footbridge/dc21285-timer.c b/arch/arm/mach-footbridge/dc21285-timer.c
index 2908c9ef3c9b..f5d0024783e3 100644
--- a/arch/arm/mach-footbridge/dc21285-timer.c
+++ b/arch/arm/mach-footbridge/dc21285-timer.c
@@ -14,7 +14,7 @@
#include <asm/irq.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <asm/mach/time.h>
#include <asm/system_info.h>
--git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
index 5a68b6739ecf..923c808e8ba1 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -19,7 +19,7 @@
#include <asm/irq.h>
#include <asm/mach/pci.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include "pci.h"
--git a/arch/arm/mach-footbridge/dma-isa.c b/arch/arm/mach-footbridge/dma-isa.c
index 937f5376d5e7..300cdf6ef223 100644
--- a/arch/arm/mach-footbridge/dma-isa.c
+++ b/arch/arm/mach-footbridge/dma-isa.c
@@ -19,7 +19,7 @@
#include <asm/dma.h>
#include <asm/mach/dma.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#define ISA_DMA_MASK 0
#define ISA_DMA_MODE 1
--git a/arch/arm/mach-footbridge/ebsa285.c b/arch/arm/mach-footbridge/ebsa285.c
index 1cb7d674bc81..93ab333e3027 100644
--- a/arch/arm/mach-footbridge/ebsa285.c
+++ b/arch/arm/mach-footbridge/ebsa285.c
@@ -10,7 +10,7 @@
#include <linux/slab.h>
#include <linux/leds.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/include/asm/hardware/dec21285.h b/arch/arm/mach-footbridge/include/mach/dec21285.h
similarity index 98%
rename from arch/arm/include/asm/hardware/dec21285.h
rename to arch/arm/mach-footbridge/include/mach/dec21285.h
index 894f2a635cbb..35d10e2dcade 100644
--- a/arch/arm/include/asm/hardware/dec21285.h
+++ b/arch/arm/mach-footbridge/include/mach/dec21285.h
@@ -1,11 +1,13 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
- * arch/arm/include/asm/hardware/dec21285.h
- *
* Copyright (C) 1998 Russell King
*
* DC21285 registers
*/
+
+#ifndef __MACH_DEC21285_H
+#define __MACH_DEC21285_H
+
#define DC21285_PCI_IACK 0x79000000
#define DC21285_ARMCSR_BASE 0x42000000
#define DC21285_PCI_TYPE_0_CONFIG 0x7b000000
@@ -135,4 +137,4 @@
#define TIMER_CNTL_DIV256 (2 << 2)
#define TIMER_CNTL_CNTEXT (3 << 2)
-
+#endif /* __MACH_DEC21285_H */
--git a/arch/arm/mach-footbridge/isa-irq.c b/arch/arm/mach-footbridge/isa-irq.c
index 842ddb4121ef..f9231e84028d 100644
--- a/arch/arm/mach-footbridge/isa-irq.c
+++ b/arch/arm/mach-footbridge/isa-irq.c
@@ -21,7 +21,7 @@
#include <asm/mach/irq.h>
#include <mach/hardware.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <asm/irq.h>
#include <asm/mach-types.h>
--git a/arch/arm/mach-footbridge/isa.c b/arch/arm/mach-footbridge/isa.c
index 84caccddce44..a028920e8f12 100644
--- a/arch/arm/mach-footbridge/isa.c
+++ b/arch/arm/mach-footbridge/isa.c
@@ -8,7 +8,7 @@
#include <linux/serial_8250.h>
#include <asm/irq.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include "common.h"
--git a/arch/arm/mach-footbridge/netwinder-hw.c b/arch/arm/mach-footbridge/netwinder-hw.c
index c024eefd4978..bd21c455a495 100644
--- a/arch/arm/mach-footbridge/netwinder-hw.c
+++ b/arch/arm/mach-footbridge/netwinder-hw.c
@@ -16,7 +16,7 @@
#include <linux/slab.h>
#include <linux/leds.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <asm/mach-types.h>
#include <asm/setup.h>
#include <asm/system_misc.h>
diff --git a/drivers/char/nwflash.c b/drivers/char/nwflash.c
index 9f52f0306ef7..21ac9b2df42e 100644
--- a/drivers/char/nwflash.c
+++ b/drivers/char/nwflash.c
@@ -29,7 +29,7 @@
#include <linux/mutex.h>
#include <linux/jiffies.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <asm/io.h>
#include <asm/mach-types.h>
#include <linux/uaccess.h>
diff --git a/drivers/mtd/maps/dc21285.c b/drivers/mtd/maps/dc21285.c
index 70a3db3ab856..8bcb40489f4f 100644
--- a/drivers/mtd/maps/dc21285.c
+++ b/drivers/mtd/maps/dc21285.c
@@ -17,7 +17,7 @@
#include <linux/mtd/partitions.h>
#include <asm/io.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <asm/mach-types.h>
diff --git a/drivers/tty/serial/21285.c b/drivers/tty/serial/21285.c
index 4de0c975ebdc..f20c2092e4a5 100644
--- a/drivers/tty/serial/21285.c
+++ b/drivers/tty/serial/21285.c
@@ -18,7 +18,7 @@
#include <asm/irq.h>
#include <asm/mach-types.h>
#include <asm/system_info.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
#include <mach/hardware.h>
#define BAUD_BASE (mem_fclk_21285/64)
diff --git a/drivers/watchdog/wdt285.c b/drivers/watchdog/wdt285.c
index 78681d9f7d53..347cb2892833 100644
--- a/drivers/watchdog/wdt285.c
+++ b/drivers/watchdog/wdt285.c
@@ -30,7 +30,7 @@
#include <asm/mach-types.h>
#include <asm/system_info.h>
-#include <asm/hardware/dec21285.h>
+#include <mach/dec21285.h>
/*
* Define this to stop the watchdog actually rebooting the machine.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 00/13] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jiri Pirko @ 2026-05-17 6:19 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260512090408.794195-1-aneesh.kumar@kernel.org>
Tue, May 12, 2026 at 11:03:55AM +0200, aneesh.kumar@kernel.org wrote:
>This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
>dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
>are handled consistently.
>
>Today, the direct DMA path mostly relies on force_dma_unencrypted() for
>shared/decrypted buffer handling. This series consolidates the
>force_dma_unencrypted() checks in the top-level functions and ensures
>that the remaining DMA interfaces use DMA attributes to make the correct
>decisions.
FWIW, the patchset in general looks good to me. I tested this with my
system_cc_shared dmabuf flow, works flawlessly.
Thanks!
^ permalink raw reply
* Re: [PATCH] ARM: remove unnecessary architecture-specific <asm/asm-offsets.h>
From: kernel test robot @ 2026-05-17 6:25 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-arm-kernel, linux-kernel
Cc: llvm, oe-kbuild-all, Ethan Nelson-Moore, Russell King
In-Reply-To: <20260517030408.100043-1-enelsonmoore@gmail.com>
Hi Ethan,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm/for-next]
[also build test ERROR on arm/fixes arm64/for-next/core clk/clk-next kvmarm/next rockchip/for-next soc/for-next linus/master shawnguo/for-next v7.1-rc3 next-20260508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Ethan-Nelson-Moore/ARM-remove-unnecessary-architecture-specific-asm-asm-offsets-h/20260517-110530
base: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
patch link: https://lore.kernel.org/r/20260517030408.100043-1-enelsonmoore%40gmail.com
patch subject: [PATCH] ARM: remove unnecessary architecture-specific <asm/asm-offsets.h>
config: arm-allnoconfig (https://download.01.org/0day-ci/archive/20260517/202605171414.zrSQqMbq-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260517/202605171414.zrSQqMbq-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605171414.zrSQqMbq-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/arm/lib/ashldi3.S:30:
>> arch/arm/include/asm/assembler.h:22:10: fatal error: 'asm/asm-offsets.h' file not found
22 | #include <asm/asm-offsets.h>
| ^~~~~~~~~~~~~~~~~~~
1 error generated.
vim +22 arch/arm/include/asm/assembler.h
^1da177e4c3f41 include/asm-arm/assembler.h Linus Torvalds 2005-04-16 19
^1da177e4c3f41 include/asm-arm/assembler.h Linus Torvalds 2005-04-16 20 #include <asm/ptrace.h>
80c59dafb1a9a8 arch/arm/include/asm/assembler.h Dave Martin 2012-02-09 21 #include <asm/opcodes-virt.h>
0b1f68e836bcf1 arch/arm/include/asm/assembler.h Catalin Marinas 2014-04-02 @22 #include <asm/asm-offsets.h>
9a2b51b6ca93fc arch/arm/include/asm/assembler.h Andrey Ryabinin 2014-06-18 23 #include <asm/page.h>
7af5b901e84743 arch/arm/include/asm/assembler.h Linus Walleij 2024-03-25 24 #include <asm/pgtable.h>
9a2b51b6ca93fc arch/arm/include/asm/assembler.h Andrey Ryabinin 2014-06-18 25 #include <asm/thread_info.h>
747ffc2fcf969e arch/arm/include/asm/assembler.h Russell King 2020-05-03 26 #include <asm/uaccess-asm.h>
^1da177e4c3f41 include/asm-arm/assembler.h Linus Torvalds 2005-04-16 27
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] ARM: remove unnecessary architecture-specific <asm/asm-offsets.h>
From: kernel test robot @ 2026-05-17 6:56 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-arm-kernel, linux-kernel
Cc: oe-kbuild-all, Ethan Nelson-Moore, Russell King
In-Reply-To: <20260517030408.100043-1-enelsonmoore@gmail.com>
Hi Ethan,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm/for-next]
[also build test ERROR on arm/fixes arm64/for-next/core clk/clk-next kvmarm/next rockchip/for-next soc/for-next linus/master nferre-at91/at91-next shawnguo/for-next v7.1-rc3 next-20260508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Ethan-Nelson-Moore/ARM-remove-unnecessary-architecture-specific-asm-asm-offsets-h/20260517-110530
base: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
patch link: https://lore.kernel.org/r/20260517030408.100043-1-enelsonmoore%40gmail.com
patch subject: [PATCH] ARM: remove unnecessary architecture-specific <asm/asm-offsets.h>
config: arm-ixp4xx_defconfig (https://download.01.org/0day-ci/archive/20260517/202605171438.l6sZ9CCp-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260517/202605171438.l6sZ9CCp-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605171438.l6sZ9CCp-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/arm/lib/ashldi3.S:30:
>> arch/arm/include/asm/assembler.h:22:10: fatal error: asm/asm-offsets.h: No such file or directory
22 | #include <asm/asm-offsets.h>
| ^~~~~~~~~~~~~~~~~~~
compilation terminated.
--
>> arch/arm/kernel/sleep.S:4:10: fatal error: asm/asm-offsets.h: No such file or directory
4 | #include <asm/asm-offsets.h>
| ^~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +22 arch/arm/include/asm/assembler.h
^1da177e4c3f41 include/asm-arm/assembler.h Linus Torvalds 2005-04-16 19
^1da177e4c3f41 include/asm-arm/assembler.h Linus Torvalds 2005-04-16 20 #include <asm/ptrace.h>
80c59dafb1a9a8 arch/arm/include/asm/assembler.h Dave Martin 2012-02-09 21 #include <asm/opcodes-virt.h>
0b1f68e836bcf1 arch/arm/include/asm/assembler.h Catalin Marinas 2014-04-02 @22 #include <asm/asm-offsets.h>
9a2b51b6ca93fc arch/arm/include/asm/assembler.h Andrey Ryabinin 2014-06-18 23 #include <asm/page.h>
7af5b901e84743 arch/arm/include/asm/assembler.h Linus Walleij 2024-03-25 24 #include <asm/pgtable.h>
9a2b51b6ca93fc arch/arm/include/asm/assembler.h Andrey Ryabinin 2014-06-18 25 #include <asm/thread_info.h>
747ffc2fcf969e arch/arm/include/asm/assembler.h Russell King 2020-05-03 26 #include <asm/uaccess-asm.h>
^1da177e4c3f41 include/asm-arm/assembler.h Linus Torvalds 2005-04-16 27
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 0/3] raspberrypi-hwmon voltage support and teardown fix
From: Shubham Chakraborty @ 2026-05-17 8:04 UTC (permalink / raw)
To: Guenter Roeck, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Shubham Chakraborty
In-Reply-To: <20260516164407.25255-1-chakrabortyshubham66@gmail.com>
This series adds firmware-backed voltage inputs to raspberrypi-hwmon and
includes a separate fix for the delayed polling work teardown path.
Patch 1 adds the firmware voltage IDs and the shared voltage request
structure to the Raspberry Pi firmware API header.
Patch 2 extends raspberrypi-hwmon to expose the firmware-provided core
and SDRAM voltage inputs through hwmon and documents the new sysfs
entries.
Patch 3 addresses the delayed polling work teardown concern raised
during review.
Changes in v3:
- corrected the SDRAM_P and SDRAM_I voltage ID mapping
- moved the voltage request structure into the firmware API header
- made the voltage request structure voltage-specific
- split the delayed-work teardown change into a separate patch
Tested on:
- Raspberry Pi 3B+ running Linux 6.12.75+rpt-rpi-v8
Shubham Chakraborty (3):
soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
hwmon: raspberrypi: Add voltage input support
hwmon: raspberrypi: Fix delayed-work teardown race
Documentation/hwmon/raspberrypi-hwmon.rst | 15 ++-
drivers/hwmon/raspberrypi-hwmon.c | 139 ++++++++++++++++++++-
include/soc/bcm2835/raspberrypi-firmware.h | 25 ++++
3 files changed, 171 insertions(+), 8 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v3 1/3] soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
From: Shubham Chakraborty @ 2026-05-17 8:04 UTC (permalink / raw)
To: Guenter Roeck, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Shubham Chakraborty
In-Reply-To: <20260517080445.103962-1-chakrabortyshubham66@gmail.com>
Add Raspberry Pi firmware voltage domain identifiers for the mailbox
property interface.
Also add the voltage request structure used with
RPI_FIRMWARE_GET_VOLTAGE so firmware clients can share the common API
definition from the firmware header.
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
include/soc/bcm2835/raspberrypi-firmware.h | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe554..975bef529854 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -156,6 +156,31 @@ enum rpi_firmware_clk_id {
RPI_FIRMWARE_NUM_CLK_ID,
};
+enum rpi_firmware_volt_id {
+ RPI_FIRMWARE_VOLT_ID_CORE = 1,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_C = 2,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_P = 3,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_I = 4,
+ RPI_FIRMWARE_NUM_VOLT_ID,
+};
+
+/**
+ * struct rpi_firmware_get_voltage_request - Firmware request for a voltage
+ * @id: ID of the voltage being queried
+ * @value: Voltage in microvolts. Set by the firmware.
+ *
+ * Used by @RPI_FIRMWARE_GET_VOLTAGE.
+ */
+struct rpi_firmware_get_voltage_request {
+ __le32 id;
+ __le32 value;
+} __packed;
+
+#define RPI_FIRMWARE_GET_VOLTAGE_REQUEST(_id) \
+ { \
+ .id = cpu_to_le32(_id), \
+ }
+
/**
* struct rpi_firmware_clk_rate_request - Firmware Request for a rate
* @id: ID of the clock being queried
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/3] hwmon: raspberrypi: Add voltage input support
From: Shubham Chakraborty @ 2026-05-17 8:04 UTC (permalink / raw)
To: Guenter Roeck, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Shubham Chakraborty
In-Reply-To: <20260517080445.103962-1-chakrabortyshubham66@gmail.com>
Extend the raspberrypi-hwmon driver to expose firmware-provided
voltage measurements through the hwmon subsystem.
The driver now exports the following voltage inputs:
- in0_input (core)
- in1_input (sdram_c)
- in2_input (sdram_i)
- in3_input (sdram_p)
Voltage values returned by firmware are converted from microvolts
to millivolts as expected by the hwmon subsystem.
Update the documentation related to it.
The existing undervoltage sticky alarm handling is preserved and
associated with the first voltage channel.
Tested in -
- Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT
Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
Documentation/hwmon/raspberrypi-hwmon.rst | 15 ++-
drivers/hwmon/raspberrypi-hwmon.c | 127 +++++++++++++++++++++-
2 files changed, 137 insertions(+), 5 deletions(-)
diff --git a/Documentation/hwmon/raspberrypi-hwmon.rst b/Documentation/hwmon/raspberrypi-hwmon.rst
index 8038ade36490..db315184b861 100644
--- a/Documentation/hwmon/raspberrypi-hwmon.rst
+++ b/Documentation/hwmon/raspberrypi-hwmon.rst
@@ -20,6 +20,17 @@ undervoltage conditions.
Sysfs entries
-------------
-======================= ==================
+======================= ======================================================
+in0_input Core voltage in millivolts
+in1_input SDRAM controller voltage in millivolts
+in2_input SDRAM I/O voltage in millivolts
+in3_input SDRAM PHY voltage in millivolts
+in0_label "core"
+in1_label "sdram_c"
+in2_label "sdram_i"
+in3_label "sdram_p"
in0_lcrit_alarm Undervoltage alarm
-======================= ==================
+======================= ======================================================
+
+The voltage inputs and labels are only exposed if the firmware reports support
+for the corresponding voltage ID.
diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
index a2938881ccd2..8ce6dacc19b0 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -5,6 +5,7 @@
* Based on firmware/raspberrypi.c by Noralf Trønnes
*
* Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
+ * Copyright (C) 2026 Shubham Chakraborty <chakrabortyshubham66@gmail.com>
*/
#include <linux/device.h>
#include <linux/devm-helpers.h>
@@ -21,10 +22,18 @@
struct rpi_hwmon_data {
struct device *hwmon_dev;
struct rpi_firmware *fw;
+ u32 valid_inputs;
u32 last_throttled;
struct delayed_work get_values_poll_work;
};
+static const char * const rpi_hwmon_labels[] = {
+ "core",
+ "sdram_c",
+ "sdram_i",
+ "sdram_p",
+};
+
static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
{
u32 new_uv, old_uv, value;
@@ -56,6 +65,21 @@ static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
hwmon_notify_event(data->hwmon_dev, hwmon_in, hwmon_in_lcrit_alarm, 0);
}
+static int rpi_firmware_get_voltage(struct rpi_hwmon_data *data, u32 id,
+ long *val)
+{
+ struct rpi_firmware_get_voltage_request packet =
+ RPI_FIRMWARE_GET_VOLTAGE_REQUEST(id);
+ int ret;
+ ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_VOLTAGE,
+ &packet, sizeof(packet));
+ if (ret)
+ return ret;
+
+ *val = le32_to_cpu(packet.value) / 1000;
+ return 0;
+}
+
static void get_values_poll(struct work_struct *work)
{
struct rpi_hwmon_data *data;
@@ -77,19 +101,94 @@ static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
{
struct rpi_hwmon_data *data = dev_get_drvdata(dev);
- *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
+ if (type == hwmon_in) {
+ switch (attr) {
+ case hwmon_in_input:
+ switch (channel) {
+ case 0:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_CORE,
+ val);
+ case 1:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_C,
+ val);
+ case 2:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_I,
+ val);
+ case 3:
+ return rpi_firmware_get_voltage(data,
+ RPI_FIRMWARE_VOLT_ID_SDRAM_P,
+ val);
+ default:
+ return -EOPNOTSUPP;
+ }
+ case hwmon_in_lcrit_alarm:
+ if (channel == 0) {
+ *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
+ return 0;
+ }
+ return -EOPNOTSUPP;
+ default:
+ return -EOPNOTSUPP;
+ }
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static int rpi_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ if (type == hwmon_in && attr == hwmon_in_label) {
+ if (channel >= ARRAY_SIZE(rpi_hwmon_labels))
+ return -EOPNOTSUPP;
+
+ *str = rpi_hwmon_labels[channel];
+ return 0;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static umode_t rpi_is_visible(const void *_data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct rpi_hwmon_data *data = _data;
+
+ if (type == hwmon_in) {
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ if (!(data->valid_inputs & BIT(channel)))
+ return 0;
+ return 0444;
+ case hwmon_in_lcrit_alarm:
+ if (channel == 0)
+ return 0444;
+ return 0;
+ default:
+ return 0;
+ }
+ }
+
return 0;
}
static const struct hwmon_channel_info * const rpi_info[] = {
HWMON_CHANNEL_INFO(in,
- HWMON_I_LCRIT_ALARM),
+ HWMON_I_INPUT | HWMON_I_LABEL | HWMON_I_LCRIT_ALARM,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL),
NULL
};
static const struct hwmon_ops rpi_hwmon_ops = {
- .visible = 0444,
+ .is_visible = rpi_is_visible,
.read = rpi_read,
+ .read_string = rpi_read_string,
};
static const struct hwmon_chip_info rpi_chip_info = {
@@ -101,6 +200,7 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct rpi_hwmon_data *data;
+ long voltage;
int ret;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
@@ -110,6 +210,26 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
/* Parent driver assure that firmware is correct */
data->fw = dev_get_drvdata(dev->parent);
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_CORE,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(0);
+
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_C,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(1);
+
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_I,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(2);
+
+ ret = rpi_firmware_get_voltage(data, RPI_FIRMWARE_VOLT_ID_SDRAM_P,
+ &voltage);
+ if (!ret)
+ data->valid_inputs |= BIT(3);
+
data->hwmon_dev = devm_hwmon_device_register_with_info(dev, "rpi_volt",
data,
&rpi_chip_info,
@@ -159,6 +279,7 @@ static struct platform_driver rpi_hwmon_driver = {
module_platform_driver(rpi_hwmon_driver);
MODULE_AUTHOR("Stefan Wahren <wahrenst@gmx.net>");
+MODULE_AUTHOR("Shubham Chakraborty <chakrabortyshubham66@gmail.com>");
MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:raspberrypi-hwmon");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/3] hwmon: raspberrypi: Fix delayed-work teardown race
From: Shubham Chakraborty @ 2026-05-17 8:04 UTC (permalink / raw)
To: Guenter Roeck, Florian Fainelli, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Shubham Chakraborty
In-Reply-To: <20260517080445.103962-1-chakrabortyshubham66@gmail.com>
The delayed polling work rearms itself from the work function, so use
explicit delayed-work setup and cleanup instead of
devm_delayed_work_autocancel().
Initialize the delayed work with INIT_DELAYED_WORK() and register a
devres cleanup action that calls disable_delayed_work_sync() during
teardown.
This addresses the concern raised during review about the polling work
being able to requeue itself while the driver is being removed.
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
drivers/hwmon/raspberrypi-hwmon.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
index 8ce6dacc19b0..0bbc735f74a4 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -8,7 +8,6 @@
* Copyright (C) 2026 Shubham Chakraborty <chakrabortyshubham66@gmail.com>
*/
#include <linux/device.h>
-#include <linux/devm-helpers.h>
#include <linux/err.h>
#include <linux/hwmon.h>
#include <linux/module.h>
@@ -96,6 +95,13 @@ static void get_values_poll(struct work_struct *work)
schedule_delayed_work(&data->get_values_poll_work, 2 * HZ);
}
+static void rpi_hwmon_cancel_poll_work(void *res)
+{
+ struct rpi_hwmon_data *data = res;
+
+ disable_delayed_work_sync(&data->get_values_poll_work);
+}
+
static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
u32 attr, int channel, long *val)
{
@@ -237,8 +243,8 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
if (IS_ERR(data->hwmon_dev))
return PTR_ERR(data->hwmon_dev);
- ret = devm_delayed_work_autocancel(dev, &data->get_values_poll_work,
- get_values_poll);
+ INIT_DELAYED_WORK(&data->get_values_poll_work, get_values_poll);
+ ret = devm_add_action_or_reset(dev, rpi_hwmon_cancel_poll_work, data);
if (ret)
return ret;
platform_set_drvdata(pdev, data);
--
2.54.0
^ permalink raw reply related
* Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte
From: Karel Balej @ 2026-05-17 8:14 UTC (permalink / raw)
To: Johannes Berg
Cc: Brian Norris, Francesco Dolcini, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Duje Mihanović, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Ulf Hansson, Frank Li, linux-wireless,
devicetree, linux-kernel, linux-arm-kernel, linux-mmc,
~postmarketos/upstreaming, phone-devel, Jeff Chen, Peng Fan,
david
In-Reply-To: <DI5L100Q1RKO.1A68EJIPWYSRC@matfyz.cz>
Johannes,
Karel Balej, 2026-04-29T12:55:23+02:00:
> Brian, what are the options here now? Would it be possible to make an
> exception and accept the patches without the firmware being in
> linux-firmware? This is an old device with no mainstream audience so I
> expect everyone who will want to use it will be able to supply the
> firmware themselves and it would be great to not have to keep the
> patches in a fork, especially when trying to build on top of them
> further (such as to fix the driver-firmware incompatibilities discussed
> in one of the patches of this series).
would you please let us know whether there is any chance an exception
could be made for this chip regarding the firmware or whether there is
any other way to upstream the support?
Thank you and best regards,
Karel
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-17 8:45 UTC (permalink / raw)
To: Matthew Wilcox, surenb
Cc: akpm, linux-mm, david, ljs, liam, vbabka, rppt, mhocko, jack,
pfalcato, wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1,
chrisl, kasong, shikemeng, nphamcs, bhe, youngjun.park,
linux-arm-kernel, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <afTpoL3FklpQZNMM@casper.infradead.org>
On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > both the hardware and the software stack (bio/request queues and the
> > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > be quite long. In such cases, a high-priority thread performing operations
> > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > for an unpredictable amount of time.
> > >
> > > But does that actually happen? I find it hard to believe that thread A
> > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > it still seems really unlikely to me.
> >
> > It doesn’t have to involve unmapping or applying mprotect to
> > the entire VMA—just a portion of it is sufficient.
>
> Yes, but that still fails to answer "does this actually happen". How much
> performance is all this complexity in the page fault handler buying us?
> If you don't answer this question, I'm just going to go in and rip it
> all out.
>
Hi Matthew (and Lorenzo, Jan, and anyone else who may be
waiting for answers),
As promised during LSF/MM/BPF, we conducted thorough
testing on Android phones to determine whether performing
I/O in `filemap_fault()` can block `vma_start_write()`.
I wanted to give a quick update on this question.
Nanzhe at Xiaomi created tracing scripts and ran various
applications on Android devices with I/O performed under
the VMA lock in `filemap_fault()`. We found that:
1. There are very few cases where unmap() is blocked by
page faults. I assume this is due to buggy user code
or poor synchronization between reads and unmap().
So I assume it is not a problem.
2. We observed many cases where `vma_start_write()`
is blocked by page-fault I/O in some applications.
The blocking occurs in the `dup_mmap()` path during
fork().
With Suren's commit fb49c455323ff ("fork: lock VMAs of
the parent process when forking"), we now always hold
`vma_write_lock()` for each VMA. Note that the
`mmap_lock` write lock is also held, which could lead to
chained waiting if page-fault I/O is performed without
releasing the VMA lock.
My gut feeling is that Suren's commit may be overshooting,
so my rough idea is that we might want to do something like
the following (we haven't tested it yet and it might be
wrong):
diff --git a/mm/mmap.c b/mm/mmap.c
index 2311ae7c2ff4..5ddaf297f31a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
*mm, struct mm_struct *oldmm)
for_each_vma(vmi, mpnt) {
struct file *file;
- retval = vma_start_write_killable(mpnt);
+ /*
+ * For anonymous or writable private VMAs, prevent
+ * concurrent CoW faults.
+ */
+ if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
+ (mpnt->vm_flags & VM_WRITE)))
+ retval = vma_start_write_killable(mpnt);
if (retval < 0)
goto loop_out;
if (mpnt->vm_flags & VM_DONTCOPY) {
Based on the above, we may want to re-check whether fork()
can be blocked by page faults. At the same time, if Suren,
you, or anyone else has any comments, please feel free to
share them.
Best Regards
Barry
^ permalink raw reply related
* [PATCH v2] spi: atmel: fix DMA channel and bounce buffer leaks
From: Felix Gu @ 2026-05-17 10:39 UTC (permalink / raw)
To: Ryan Wanner, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Radu Pirea, Richard Genoud, Wenyou Yang
Cc: linux-spi, linux-arm-kernel, linux-kernel, Mark Brown, Felix Gu
The original code set use_dma to false when dma_alloc_coherent() for
bounce buffers failed, but DMA channels acquired earlier via
atmel_spi_configure_dma() were never freed.
When devm_request_irq() or clk_prepare_enable() failed later in probe,
the driver also did not release DMA channels or bounce buffers already
allocated.
And in the following error path, the driver released DMA channels but
did not free the bounce buffers.
Fix by moving bounce buffer allocation into atmel_spi_configure_dma()
and switching both DMA channels and bounce buffers to their devm-
managed variants. Any allocation failure in the DMA configuration path
now correctly rolls back through devres cleanup, and thenow-unnecessary
atmel_spi_release_dma() function is removed.
Fixes: a9889ed62d06 ("spi: atmel: Implements transfers with bounce buffer")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Switch to devm-managed variants to fix Claudiu Beznea's comment.
- Link to v1: https://patch.msgid.link/20260516-atmel-v1-0-674fb4707af6@gmail.com
To: Ryan Wanner <ryan.wanner@microchip.com>
To: Mark Brown <broonie@kernel.org>
To: Nicolas Ferre <nicolas.ferre@microchip.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Claudiu Beznea <claudiu.beznea@tuxon.dev>
To: Radu Pirea <radu.pirea@microchip.com>
Cc: linux-spi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c | 94 ++++++++++++++-----------------------------------
1 file changed, 27 insertions(+), 67 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 25aa294631c8..23022665c3a4 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -565,14 +565,15 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
struct device *dev = &as->pdev->dev;
int err;
- host->dma_tx = dma_request_chan(dev, "tx");
+ host->dma_tx = devm_dma_request_chan(dev, "tx");
if (IS_ERR(host->dma_tx)) {
err = PTR_ERR(host->dma_tx);
dev_dbg(dev, "No TX DMA channel, DMA is disabled\n");
- goto error_clear;
+ host->dma_tx = NULL;
+ return err;
}
- host->dma_rx = dma_request_chan(dev, "rx");
+ host->dma_rx = devm_dma_request_chan(dev, "rx");
if (IS_ERR(host->dma_rx)) {
err = PTR_ERR(host->dma_rx);
/*
@@ -580,12 +581,27 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
* requested tx channel.
*/
dev_dbg(dev, "No RX DMA channel, DMA is disabled\n");
- goto error;
+ host->dma_rx = NULL;
+ return err;
}
err = atmel_spi_dma_slave_config(as, 8);
if (err)
- goto error;
+ return err;
+
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ as->addr_tx_bbuf = dmam_alloc_coherent(dev, SPI_MAX_DMA_XFER,
+ &as->dma_addr_tx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_tx_bbuf)
+ return -ENOMEM;
+
+ as->addr_rx_bbuf = dmam_alloc_coherent(dev, SPI_MAX_DMA_XFER,
+ &as->dma_addr_rx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_rx_bbuf)
+ return -ENOMEM;
+ }
dev_info(&as->pdev->dev,
"Using %s (tx) and %s (rx) for DMA transfers\n",
@@ -593,14 +609,7 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
dma_chan_name(host->dma_rx));
return 0;
-error:
- if (!IS_ERR(host->dma_rx))
- dma_release_channel(host->dma_rx);
- if (!IS_ERR(host->dma_tx))
- dma_release_channel(host->dma_tx);
-error_clear:
- host->dma_tx = host->dma_rx = NULL;
- return err;
+
}
static void atmel_spi_stop_dma(struct spi_controller *host)
@@ -611,18 +620,6 @@ static void atmel_spi_stop_dma(struct spi_controller *host)
dmaengine_terminate_all(host->dma_tx);
}
-static void atmel_spi_release_dma(struct spi_controller *host)
-{
- if (host->dma_rx) {
- dma_release_channel(host->dma_rx);
- host->dma_rx = NULL;
- }
- if (host->dma_tx) {
- dma_release_channel(host->dma_tx);
- host->dma_tx = NULL;
- }
-}
-
/* This function is called by the DMA driver from tasklet context */
static void dma_callback(void *data)
{
@@ -1581,30 +1578,6 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->use_pdc = true;
}
- if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
- as->addr_rx_bbuf = dma_alloc_coherent(&pdev->dev,
- SPI_MAX_DMA_XFER,
- &as->dma_addr_rx_bbuf,
- GFP_KERNEL | GFP_DMA);
- if (!as->addr_rx_bbuf) {
- as->use_dma = false;
- } else {
- as->addr_tx_bbuf = dma_alloc_coherent(&pdev->dev,
- SPI_MAX_DMA_XFER,
- &as->dma_addr_tx_bbuf,
- GFP_KERNEL | GFP_DMA);
- if (!as->addr_tx_bbuf) {
- as->use_dma = false;
- dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
- as->addr_rx_bbuf,
- as->dma_addr_rx_bbuf);
- }
- }
- if (!as->use_dma)
- dev_info(host->dev.parent,
- " can not allocate dma coherent memory\n");
- }
-
if (as->caps.has_dma_support && !as->use_dma)
dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
@@ -1652,7 +1625,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
ret = spi_register_controller(host);
if (ret)
- goto out_free_dma;
+ goto out_disable_rpm;
/* go! */
dev_info(&pdev->dev, "Atmel SPI Controller version 0x%x at 0x%08lx (irq %d)\n",
@@ -1661,16 +1634,13 @@ static int atmel_spi_probe(struct platform_device *pdev)
return 0;
-out_free_dma:
+out_disable_rpm:
pm_runtime_disable(&pdev->dev);
pm_runtime_set_suspended(&pdev->dev);
-
- if (as->use_dma)
- atmel_spi_release_dma(host);
-
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
- clk_disable_unprepare(as->gclk);
+ if (as->gclk)
+ clk_disable_unprepare(as->gclk);
out_disable_clk:
clk_disable_unprepare(clk);
@@ -1687,18 +1657,8 @@ static void atmel_spi_remove(struct platform_device *pdev)
spi_unregister_controller(host);
/* reset the hardware and block queue progress */
- if (as->use_dma) {
+ if (as->use_dma)
atmel_spi_stop_dma(host);
- atmel_spi_release_dma(host);
- if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
- dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
- as->addr_tx_bbuf,
- as->dma_addr_tx_bbuf);
- dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
- as->addr_rx_bbuf,
- as->dma_addr_rx_bbuf);
- }
- }
spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260516-atmel-6d6b0150eb7e
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH v4 00/15] SCMI Clock rates discovery rework
From: Sudeep Holla @ 2026-05-17 11:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, arm-scmi, linux-clk,
linux-renesas-soc, Cristian Marussi
Cc: Sudeep Holla, philip.radford, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
geert+renesas, kuninori.morimoto.gx, marek.vasut+renesas
In-Reply-To: <20260508153300.2224715-1-cristian.marussi@arm.com>
On Fri, 08 May 2026 16:32:45 +0100, Cristian Marussi wrote:
> it was a known limitation, in the SCMI Clock protocol support, the lack of
> dynamic allocation around per-clock rates discovery: fixed size statically
> per-clock rates arrays did not scale and was increasingly a waste of memory
> (see [1]).
>
> This series aim at solving this in successive steps:
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[01/15] clk: scmi: Fix clock rate rounding
https://git.kernel.org/sudeep.holla/c/d0c81a38d06d
[02/15] firmware: arm_scmi: Add clock determine_rate operation
https://git.kernel.org/sudeep.holla/c/ecde921eb460
[03/15] clk: scmi: Use new determine_rate clock operation
https://git.kernel.org/sudeep.holla/c/af86c99170b7
[04/15] firmware: arm_scmi: Simplify clock rates exposed interface
https://git.kernel.org/sudeep.holla/c/0d76f62613ca
[05/15] clk: scmi: Use new simplified per-clock rate properties
https://git.kernel.org/sudeep.holla/c/cdcd2fc94936
[06/15] firmware: arm_scmi: Drop unused clock rate interfaces
https://git.kernel.org/sudeep.holla/c/2e757f71a5ab
[07/15] firmware: arm_scmi: Make clock rates allocation dynamic
https://git.kernel.org/sudeep.holla/c/62ba967595e0
[08/15] firmware: arm_scmi: Harden clock parents discovery
https://git.kernel.org/sudeep.holla/c/bda40491e0ce
[09/15] firmware: arm_scmi: Refactor iterators internal allocation
https://git.kernel.org/sudeep.holla/c/e99ed7267263
[10/15] firmware: arm_scmi: Add bound iterators support
https://git.kernel.org/sudeep.holla/c/4848d07ea9fc
[11/15] firmware: arm_scmi: Fix bound iterators returning too many items
https://git.kernel.org/sudeep.holla/c/ae4a088f13de
[12/15] firmware: arm_scmi: Use proper iter_response_bound_cleanup() name
https://git.kernel.org/sudeep.holla/c/3065e26dac52
[13/15] firmware: arm_scmi: Use bound iterators to minimize discovered rates
https://git.kernel.org/sudeep.holla/c/26d04d592a47
[14/15] firmware: arm_scmi: Fix OOB in scmi_clock_describe_rates_get_lazy()
https://git.kernel.org/sudeep.holla/c/4a07036d6159
[15/15] firmware: arm_scmi: Introduce all_rates_get clock operation
https://git.kernel.org/sudeep.holla/c/d2488ff1a257
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 0/4] firmware: arm_ffa: Move core init to platform driver probe
From: Sudeep Holla @ 2026-05-17 11:36 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, Sudeep Holla
Cc: Yeoreum Yun
In-Reply-To: <20260508-b4-ffa_plat_dev-v1-0-c5a30f8cf7b8@kernel.org>
On Fri, 08 May 2026 18:54:14 +0100, Sudeep Holla wrote:
> This series moves the Arm FF-A core initialisation into the driver model by
> converting the core bring-up path to a platform driver probe/remove flow.
>
> The first patch reverts the earlier rootfs_initcall change. That initcall
> ordering workaround is not a proper solution and potentially conflicts with
> pKVM FF-A proxy requirement.
>
> [...]
Applied to sudeep.holla/linux (for-next/ffa/updates), thanks!
[1/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
https://git.kernel.org/sudeep.holla/c/1b4c1c4d75a8
[2/4] firmware: arm_ffa: Register core as a platform driver
https://git.kernel.org/sudeep.holla/c/d10175dd517a
[3/4] firmware: arm_ffa: Set the core device as FF-A device parent
https://git.kernel.org/sudeep.holla/c/8bdff2dda405
[4/4] firmware: arm_ffa: Defer probe until pKVM is initialized
https://git.kernel.org/sudeep.holla/c/216d4772b411
--
Regards,
Sudeep
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox