* Re: [PATCH] docs: ABI: testing: minor cleanup
From: Brian Norris @ 2026-06-12 21:01 UTC (permalink / raw)
To: Manuel Ebner; +Cc: Tzung-Bi Shih, Julius Werner, chrome-platform
In-Reply-To: <20260612125111.187072-2-manuelebner@mailbox.org>
On Fri, Jun 12, 2026 at 02:51:12PM +0200, Manuel Ebner wrote:
> Add missing ')'.
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* [PATCH] docs: ABI: testing: minor cleanup
From: Manuel Ebner @ 2026-06-12 12:51 UTC (permalink / raw)
To: Tzung-Bi Shih, Brian Norris, Julius Werner, chrome-platform; +Cc: Manuel Ebner
Add missing ')'.
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/ABI/testing/sysfs-firmware-gsmi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-firmware-gsmi b/Documentation/ABI/testing/sysfs-firmware-gsmi
index 7a558354c1ee..3b3c3ae6f458 100644
--- a/Documentation/ABI/testing/sysfs-firmware-gsmi
+++ b/Documentation/ABI/testing/sysfs-firmware-gsmi
@@ -19,7 +19,7 @@ Description:
/sys/firmware/gsmi/vars:
This directory has the same layout (and
- underlying implementation as /sys/firmware/efi/vars.
+ underlying implementation) as /sys/firmware/efi/vars.
See `Documentation/ABI/*/sysfs-firmware-efi-vars`
for more information on how to interact with
this structure.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] Documentation: ABI: fix brackets and bracelets
From: Jonathan Cameron @ 2026-06-12 10:35 UTC (permalink / raw)
To: Manuel Ebner
Cc: David Lechner, Nuno Sa, Andy Shevchenko, Jason Gunthorpe,
Leon Romanovsky, linux-rdma, Jean Delvare, Tzung-Bi Shih,
Brian Norris, Julius Werner, chrome-platform, Greg Kroah-Hartman,
Rafael J . Wysocki, Danilo Krummrich, driver-core, open list,
linux-iio, Randy Dunlap
In-Reply-To: <20260612074916.169195-3-manuelebner@mailbox.org>
On Fri, 12 Jun 2026 09:49:18 +0200
Manuel Ebner <manuelebner@mailbox.org> wrote:
> Fix missing and needless brackets and bracelets.
> Fix minor grammar issues.
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
I guess I was unclear in my v1 review. This needs to be split up by subsystem
to which a patch applies. Each change will probably take a different route to
upstream as other changes in these files that may clash will generally be routed
via the appropriate subsystem.
The two IIO files can be one patch, but others should all be one
patch per file touched.
Thanks,
Jonathan
> ---
> [v1] -> [v2]
> change from removing single bracket to adding missing bracket
> add recipients
> Thanks Jonathan for researching the e-mail addresses.
> use proper english punctuation in changelog
> "is 64 bit counter" -> "is a 64-bit counter"
>
> ---
> Documentation/ABI/stable/sysfs-class-infiniband | 8 ++++----
> Documentation/ABI/testing/sysfs-bus-iio | 10 +++++-----
> Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 | 2 +-
> Documentation/ABI/testing/sysfs-firmware-dmi-entries | 2 +-
> Documentation/ABI/testing/sysfs-firmware-gsmi | 2 +-
> Documentation/ABI/testing/sysfs-uevent | 2 +-
> 6 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband
> index 694f23a03a28..7ba116103429 100644
> --- a/Documentation/ABI/stable/sysfs-class-infiniband
> +++ b/Documentation/ABI/stable/sysfs-class-infiniband
> @@ -148,17 +148,17 @@ Description:
> **Data info**:
>
> port_xmit_data: (RO) Total number of data octets, divided by 4
> - (lanes), transmitted on all VLs. This is 64 bit counter
> + (lanes), transmitted on all VLs. This is a 64-bit counter
>
> port_rcv_data: (RO) Total number of data octets, divided by 4
> - (lanes), received on all VLs. This is 64 bit counter.
> + (lanes), received on all VLs. This is a 64-bit counter.
>
> port_xmit_packets: (RO) Total number of packets transmitted on
> all VLs from this port. This may include packets with errors.
> - This is 64 bit counter.
> + This is a 64-bit counter.
>
> port_rcv_packets: (RO) Total number of packets (this may include
> - packets containing Errors. This is 64 bit counter.
> + packets containing Errors). This is a 64-bit counter.
>
> link_downed: (RO) Total number of times the Port Training state
> machine has failed the link error recovery process and downed
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index d8d6d85235b0..4ea5598e7cd2 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -917,7 +917,7 @@ Description:
>
> Note the driver will assume the last p events requested are
> to be enabled where p is how many it supports (which may vary
> - depending on the exact set requested. So if you want to be
> + depending on the exact set requested). So if you want to be
> sure you have set what you think you have, check the contents of
> these attributes after everything is configured. Drivers may
> have to buffer any parameters so that they are consistent when
> @@ -973,7 +973,7 @@ Description:
>
> Note the driver will assume the last p events requested are
> to be enabled where p is however many it supports (which may
> - vary depending on the exact set requested. So if you want to be
> + vary depending on the exact set requested). So if you want to be
> sure you have set what you think you have, check the contents of
> these attributes after everything is configured. Drivers may
> have to buffer any parameters so that they are consistent when
> @@ -1528,9 +1528,9 @@ Description:
> the unused bits, so to get a clean value the bits value must be
> used to mask the buffer output value appropriately. The storagebits
> value also specifies the data alignment. So s48/64>>2 will be a
> - signed 48 bit integer stored in a 64 bit location aligned to a 64
> - bit boundary. To obtain the clean value, shift right 2 and apply a
> - mask to zero the top 16 bits of the result.
> + signed 48-bit integer stored in a 64-bit location aligned to a
> + 64-bit boundary. To obtain the clean value, shift right 2 and apply
> + a mask to zero the top 16 bits of the result.
> For other storage combinations this attribute will be extended
> appropriately.
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
> index 28be1cabf112..d44eb5f8728b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
> @@ -16,7 +16,7 @@ Description:
> In bridge applications, such as strain gauges and load cells,
> the bridge itself consumes the majority of the current in the
> system. To minimize the current consumption of the system,
> - the bridge can be disconnected (when it is not being used
> + the bridge can be disconnected (when it is not being used)
> using the bridge_switch_en attribute.
>
> What: /sys/bus/iio/devices/iio:deviceX/in_voltage2-voltage2_shorted_raw
> diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-entries b/Documentation/ABI/testing/sysfs-firmware-dmi-entries
> index b6c23807b804..ed7d9d06a9ff 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-dmi-entries
> +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-entries
> @@ -93,7 +93,7 @@ Description:
> /sys/firmware/dmi/entries/15-0/system_event_log
>
> and has the following attributes (documented in the
> - SMBIOS / DMI specification under "System Event Log (Type 15)":
> + SMBIOS / DMI specification under "System Event Log (Type 15)"):
>
> - area_length
> - header_start_offset
> diff --git a/Documentation/ABI/testing/sysfs-firmware-gsmi b/Documentation/ABI/testing/sysfs-firmware-gsmi
> index 7a558354c1ee..3b3c3ae6f458 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-gsmi
> +++ b/Documentation/ABI/testing/sysfs-firmware-gsmi
> @@ -19,7 +19,7 @@ Description:
> /sys/firmware/gsmi/vars:
>
> This directory has the same layout (and
> - underlying implementation as /sys/firmware/efi/vars.
> + underlying implementation) as /sys/firmware/efi/vars.
> See `Documentation/ABI/*/sysfs-firmware-efi-vars`
> for more information on how to interact with
> this structure.
> diff --git a/Documentation/ABI/testing/sysfs-uevent b/Documentation/ABI/testing/sysfs-uevent
> index 0b6227706b35..c15e18c47a0e 100644
> --- a/Documentation/ABI/testing/sysfs-uevent
> +++ b/Documentation/ABI/testing/sysfs-uevent
> @@ -8,7 +8,7 @@ Description:
>
> Recognized extended format is::
>
> - ACTION [UUID [KEY=VALUE ...]
> + ACTION [UUID [KEY=VALUE ...]]
>
> The ACTION is compulsory - it is the name of the uevent
> action (``add``, ``change``, ``remove``). There is no change
^ permalink raw reply
* [PATCH v2] Documentation: ABI: fix brackets and bracelets
From: Manuel Ebner @ 2026-06-12 7:49 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sa, Andy Shevchenko,
Jason Gunthorpe, Leon Romanovsky, linux-rdma, Jean Delvare,
Tzung-Bi Shih, Brian Norris, Julius Werner, chrome-platform,
Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
driver-core, open list, linux-iio
Cc: Randy Dunlap, Manuel Ebner
Fix missing and needless brackets and bracelets.
Fix minor grammar issues.
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
[v1] -> [v2]
change from removing single bracket to adding missing bracket
add recipients
Thanks Jonathan for researching the e-mail addresses.
use proper english punctuation in changelog
"is 64 bit counter" -> "is a 64-bit counter"
---
Documentation/ABI/stable/sysfs-class-infiniband | 8 ++++----
Documentation/ABI/testing/sysfs-bus-iio | 10 +++++-----
Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 | 2 +-
Documentation/ABI/testing/sysfs-firmware-dmi-entries | 2 +-
Documentation/ABI/testing/sysfs-firmware-gsmi | 2 +-
Documentation/ABI/testing/sysfs-uevent | 2 +-
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband
index 694f23a03a28..7ba116103429 100644
--- a/Documentation/ABI/stable/sysfs-class-infiniband
+++ b/Documentation/ABI/stable/sysfs-class-infiniband
@@ -148,17 +148,17 @@ Description:
**Data info**:
port_xmit_data: (RO) Total number of data octets, divided by 4
- (lanes), transmitted on all VLs. This is 64 bit counter
+ (lanes), transmitted on all VLs. This is a 64-bit counter
port_rcv_data: (RO) Total number of data octets, divided by 4
- (lanes), received on all VLs. This is 64 bit counter.
+ (lanes), received on all VLs. This is a 64-bit counter.
port_xmit_packets: (RO) Total number of packets transmitted on
all VLs from this port. This may include packets with errors.
- This is 64 bit counter.
+ This is a 64-bit counter.
port_rcv_packets: (RO) Total number of packets (this may include
- packets containing Errors. This is 64 bit counter.
+ packets containing Errors). This is a 64-bit counter.
link_downed: (RO) Total number of times the Port Training state
machine has failed the link error recovery process and downed
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index d8d6d85235b0..4ea5598e7cd2 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -917,7 +917,7 @@ Description:
Note the driver will assume the last p events requested are
to be enabled where p is how many it supports (which may vary
- depending on the exact set requested. So if you want to be
+ depending on the exact set requested). So if you want to be
sure you have set what you think you have, check the contents of
these attributes after everything is configured. Drivers may
have to buffer any parameters so that they are consistent when
@@ -973,7 +973,7 @@ Description:
Note the driver will assume the last p events requested are
to be enabled where p is however many it supports (which may
- vary depending on the exact set requested. So if you want to be
+ vary depending on the exact set requested). So if you want to be
sure you have set what you think you have, check the contents of
these attributes after everything is configured. Drivers may
have to buffer any parameters so that they are consistent when
@@ -1528,9 +1528,9 @@ Description:
the unused bits, so to get a clean value the bits value must be
used to mask the buffer output value appropriately. The storagebits
value also specifies the data alignment. So s48/64>>2 will be a
- signed 48 bit integer stored in a 64 bit location aligned to a 64
- bit boundary. To obtain the clean value, shift right 2 and apply a
- mask to zero the top 16 bits of the result.
+ signed 48-bit integer stored in a 64-bit location aligned to a
+ 64-bit boundary. To obtain the clean value, shift right 2 and apply
+ a mask to zero the top 16 bits of the result.
For other storage combinations this attribute will be extended
appropriately.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
index 28be1cabf112..d44eb5f8728b 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
@@ -16,7 +16,7 @@ Description:
In bridge applications, such as strain gauges and load cells,
the bridge itself consumes the majority of the current in the
system. To minimize the current consumption of the system,
- the bridge can be disconnected (when it is not being used
+ the bridge can be disconnected (when it is not being used)
using the bridge_switch_en attribute.
What: /sys/bus/iio/devices/iio:deviceX/in_voltage2-voltage2_shorted_raw
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-entries b/Documentation/ABI/testing/sysfs-firmware-dmi-entries
index b6c23807b804..ed7d9d06a9ff 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi-entries
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi-entries
@@ -93,7 +93,7 @@ Description:
/sys/firmware/dmi/entries/15-0/system_event_log
and has the following attributes (documented in the
- SMBIOS / DMI specification under "System Event Log (Type 15)":
+ SMBIOS / DMI specification under "System Event Log (Type 15)"):
- area_length
- header_start_offset
diff --git a/Documentation/ABI/testing/sysfs-firmware-gsmi b/Documentation/ABI/testing/sysfs-firmware-gsmi
index 7a558354c1ee..3b3c3ae6f458 100644
--- a/Documentation/ABI/testing/sysfs-firmware-gsmi
+++ b/Documentation/ABI/testing/sysfs-firmware-gsmi
@@ -19,7 +19,7 @@ Description:
/sys/firmware/gsmi/vars:
This directory has the same layout (and
- underlying implementation as /sys/firmware/efi/vars.
+ underlying implementation) as /sys/firmware/efi/vars.
See `Documentation/ABI/*/sysfs-firmware-efi-vars`
for more information on how to interact with
this structure.
diff --git a/Documentation/ABI/testing/sysfs-uevent b/Documentation/ABI/testing/sysfs-uevent
index 0b6227706b35..c15e18c47a0e 100644
--- a/Documentation/ABI/testing/sysfs-uevent
+++ b/Documentation/ABI/testing/sysfs-uevent
@@ -8,7 +8,7 @@ Description:
Recognized extended format is::
- ACTION [UUID [KEY=VALUE ...]
+ ACTION [UUID [KEY=VALUE ...]]
The ACTION is compulsory - it is the name of the uevent
action (``add``, ``change``, ``remove``). There is no change
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 4/5] hwmon: (cros_ec) Add support for displaying fan curves
From: Guenter Roeck @ 2026-06-09 20:53 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Benson Leung, Shuah Khan, Guenter Roeck, chrome-platform,
linux-hwmon, linux-kernel
In-Reply-To: <20260529-cros_ec-hwmon-fan-curve-v1-4-da6792b3830f@weissschuh.net>
On Fri, May 29, 2026 at 10:31:55PM +0200, Thomas Weißschuh wrote:
> The automatic fan control mode of the embedded controller uses fan
> curves with two trigger points to calculate the target fan speed.
> All temperature sensors affect all fans.
>
> Expose these fan curves through the standard hwmon sysfs ABI.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 3/5] hwmon: (cros_ec) Split out cros_ec_hwmon_get_thermal_config()
From: Guenter Roeck @ 2026-06-09 20:52 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Benson Leung, Shuah Khan, Guenter Roeck, chrome-platform,
linux-hwmon, linux-kernel
In-Reply-To: <20260529-cros_ec-hwmon-fan-curve-v1-3-da6792b3830f@weissschuh.net>
On Fri, May 29, 2026 at 10:31:54PM +0200, Thomas Weißschuh wrote:
> Some upcoming changes require access to the raw
> 'struct ec_thermal_config'.
>
> Split out the logic to get it from the EC into a new helper.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 2/5] hwmon: (cros_ec) Prepare the addition of custom groups
From: Guenter Roeck @ 2026-06-09 20:51 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Benson Leung, Shuah Khan, Guenter Roeck, chrome-platform,
linux-hwmon, linux-kernel
In-Reply-To: <20260529-cros_ec-hwmon-fan-curve-v1-2-da6792b3830f@weissschuh.net>
On Fri, May 29, 2026 at 10:31:53PM +0200, Thomas Weißschuh wrote:
> An upcoming change will add a custom sysfs attribute group.
>
> Set up the scaffolding for that.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/5] hwmon: (cros_ec) Implement custom kelvin to celsius conversions
From: Guenter Roeck @ 2026-06-09 20:50 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Benson Leung, Shuah Khan, Guenter Roeck, chrome-platform,
linux-hwmon, linux-kernel
In-Reply-To: <20260529-cros_ec-hwmon-fan-curve-v1-1-da6792b3830f@weissschuh.net>
On Fri, May 29, 2026 at 10:31:52PM +0200, Thomas Weißschuh wrote:
> The ChromeOS EC APIs use integers representing degrees kelvin for
> temperatures. The default conversions from linux/units.h will then
> always convert these integer degrees celsius with a 150 millidegree
> offset. This is a bit confusing, as it also differs from other CrOS EC
> tooling. Internally the EC uses a kelvin to celsius offset of a round
> 273, so the current conversion is also not entirely accurate.
>
> Implement a custom conversion which preserves round values.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v2 2/2] mfd: cros_ec: Read EC features during probe to catch transfer error
From: Andrei Kuchynski @ 2026-06-08 21:15 UTC (permalink / raw)
To: Lee Jones, Benson Leung, Tzung-Bi Shih
Cc: Guenter Roeck, Gwendal Grignou, chrome-platform, linux-kernel,
Andrei Kuchynski
In-Reply-To: <20260608211518.2214740-1-akuchynski@chromium.org>
cros_ec_check_features() does not return an error if the underlying
EC_CMD_GET_FEATURES command fails. Consequently, when the Fingerprint
device fails to respond, the probe function ignores the failure and falls
back to installing it as 'cros_ec' device instead of 'cros_fp'.
This leads to a sysfs duplicate filename collision later when the real
'cros_ec' device attempts to register:
cros-ec-spi spi5.0: EC failed to respond in time
cros-ec-dev.19.auto: cannot get EC features: -110
sysfs : cannot create duplicate filename '/class/chromeos/cros_ec'
: sysfs_do_create_link_sd+0x94/0xdc
: ec_device_probe+0x150/0x4f0
Fix this by explicitly calling the newly introduced cros_ec_read_features()
function. If the transfer fails, abort the broken device initialization.
Move the initialization of class_dev before this call to prevent a missing
release() callback warning on the error path.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
---
drivers/mfd/cros_ec_dev.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 39430dd44e30c..a8c6300248d59 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -203,6 +203,17 @@ static int ec_device_probe(struct platform_device *pdev)
ec->features.flags[1] = -1U; /* Not cached yet */
device_initialize(&ec->class_dev);
+ /*
+ * Add the class device
+ */
+ ec->class_dev.class = &cros_class;
+ ec->class_dev.parent = dev;
+ ec->class_dev.release = cros_ec_class_release;
+
+ retval = cros_ec_read_features(ec);
+ if (retval < 0)
+ goto failed;
+
for (i = 0; i < ARRAY_SIZE(cros_mcu_devices); i++) {
/*
* Check whether this is actually a dedicated MCU rather
@@ -220,13 +231,6 @@ static int ec_device_probe(struct platform_device *pdev)
}
}
- /*
- * Add the class device
- */
- ec->class_dev.class = &cros_class;
- ec->class_dev.parent = dev;
- ec->class_dev.release = cros_ec_class_release;
-
retval = dev_set_name(&ec->class_dev, "%s", ec_platform->ec_name);
if (retval) {
dev_err(dev, "dev_set_name failed => %d\n", retval);
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [PATCH v2 1/2] platform/chrome: cros_ec_proto: Introduce cros_ec_read_features helper
From: Andrei Kuchynski @ 2026-06-08 21:15 UTC (permalink / raw)
To: Lee Jones, Benson Leung, Tzung-Bi Shih
Cc: Guenter Roeck, Gwendal Grignou, chrome-platform, linux-kernel,
Andrei Kuchynski
In-Reply-To: <20260608211518.2214740-1-akuchynski@chromium.org>
Extract the EC feature-reading logic from cros_ec_check_features() into
cros_ec_read_features() helper function.
Currently, cros_ec_check_features() swallows command transfer errors. By
isolating the transaction logic into an explicit helper that returns the
actual transfer error code, subsequent callers (such as the cros_ec_dev
driver during device probing) can catch a read error.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
---
drivers/platform/chrome/cros_ec_proto.c | 30 +++++++++++++++------
include/linux/platform_data/cros_ec_proto.h | 2 ++
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
index 1d8d9168ec1aa..724d1313f6b21 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -946,6 +946,27 @@ u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev)
}
EXPORT_SYMBOL(cros_ec_get_host_event);
+/**
+ * cros_ec_read_features() - Read EC features
+ *
+ * @ec: EC device.
+ *
+ * Return: >= 0 on success, negative error number on failure.
+ */
+int cros_ec_read_features(struct cros_ec_dev *ec)
+{
+ int ret = cros_ec_cmd(ec->ec_dev, 0, EC_CMD_GET_FEATURES + ec->cmd_offset,
+ NULL, 0, &ec->features, sizeof(ec->features));
+
+ if (ret < 0) {
+ dev_warn(ec->dev, "cannot get EC features: %d\n", ret);
+ memset(&ec->features, 0, sizeof(ec->features));
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_features);
+
/**
* cros_ec_check_features() - Test for the presence of EC features
*
@@ -960,17 +981,10 @@ EXPORT_SYMBOL(cros_ec_get_host_event);
bool cros_ec_check_features(struct cros_ec_dev *ec, int feature)
{
struct ec_response_get_features *features = &ec->features;
- int ret;
if (features->flags[0] == -1U && features->flags[1] == -1U) {
/* features bitmap not read yet */
- ret = cros_ec_cmd(ec->ec_dev, 0, EC_CMD_GET_FEATURES + ec->cmd_offset,
- NULL, 0, features, sizeof(*features));
- if (ret < 0) {
- dev_warn(ec->dev, "cannot get EC features: %d\n", ret);
- memset(features, 0, sizeof(*features));
- }
-
+ cros_ec_read_features(ec);
dev_dbg(ec->dev, "EC features %08x %08x\n",
features->flags[0], features->flags[1]);
}
diff --git a/include/linux/platform_data/cros_ec_proto.h b/include/linux/platform_data/cros_ec_proto.h
index 6ed1c4c5ce2ef..a1ccecf5e1f83 100644
--- a/include/linux/platform_data/cros_ec_proto.h
+++ b/include/linux/platform_data/cros_ec_proto.h
@@ -271,6 +271,8 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
+int cros_ec_read_features(struct cros_ec_dev *ec);
+
bool cros_ec_check_features(struct cros_ec_dev *ec, int feature);
int cros_ec_get_sensor_count(struct cros_ec_dev *ec);
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [PATCH v2 0/2] mfd: platform/chrome: Catch EC feature read errors during probe
From: Andrei Kuchynski @ 2026-06-08 21:15 UTC (permalink / raw)
To: Lee Jones, Benson Leung, Tzung-Bi Shih
Cc: Guenter Roeck, Gwendal Grignou, chrome-platform, linux-kernel,
Andrei Kuchynski
This series fixes a sysfs duplicate name collision that occurs when the
Fingerprint device fails to respond during probe, causing it to
incorrectly fall back to the generic 'cros_ec' name.
Changes in v2:
- Split into a 2-patch series.
- Carried over Acked-by from Tzung-Bi Shih for Patch 1.
- Fixed an ec->class_dev resource leak by utilizing 'goto failed;'.
- Moved class_dev initialization to prevent a missing release()
callback warning on the error path.
Andrei Kuchynski (2):
platform/chrome: cros_ec_proto: Introduce cros_ec_read_features helper
mfd: cros_ec: Read EC features during probe to catch transfer error
drivers/mfd/cros_ec_dev.c | 18 ++++++++-----
drivers/platform/chrome/cros_ec_proto.c | 30 +++++++++++++++------
include/linux/platform_data/cros_ec_proto.h | 2 ++
3 files changed, 35 insertions(+), 15 deletions(-)
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply
* Re: [PATCH 5/5] hwmon: (cros_ec) Allow modification of fan curves
From: Thomas Weißschuh @ 2026-06-08 15:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: Armin Wolf, Benson Leung, Shuah Khan, Guenter Roeck,
chrome-platform, linux-hwmon, linux-kernel
In-Reply-To: <243e6f71-b777-478c-802a-d8f3ed47b3fc@roeck-us.net>
On 2026-06-08 06:34:43-0700, Guenter Roeck wrote:
> On 6/4/26 03:33, Armin Wolf wrote:
> > Am 04.06.26 um 11:04 schrieb Thomas Weißschuh:
> > > On 2026-05-30 18:37:32+0200, Armin Wolf wrote:
> > > > Am 29.05.26 um 22:31 schrieb Thomas Weißschuh:
> > >
> > > (...)
> > >
> > > > > +static ssize_t temp_auto_point_temp_store(struct device *dev, struct device_attribute *attr,
> > > > > + const char *buf, size_t size)
> > > > > +{
> > > > > + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> > > > > + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
> > > > > + struct ec_thermal_config config;
> > > > > + u32 *temp_field;
> > > > > + s64 temp;
> > > > > + int ret;
> > > > > +
> > > > > + ret = kstrtos64(buf, 10, &temp);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + temp = cros_ec_hwmon_millicelsius_to_kelvin(temp);
> > > > > +
> > > > > + if (overflows_type(temp, config.temp_fan_off))
> > > > > + return -ERANGE;
> > > > > +
> > > > > + guard(hwmon_lock)(dev);
> > > > > +
> > > > > + ret = cros_ec_hwmon_get_thermal_config(priv->cros_ec, sattr->index, &config);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + if (cros_ec_hwmon_attr_is_temp_fan_off(sattr))
> > > > > + temp_field = &config.temp_fan_off;
> > > > > + else /* temp_fan_max */
> > > > > + temp_field = &config.temp_fan_max;
> > > > > +
> > > > > + /* Only allow values which are more aggressive than the current ones */
> > > > > + if (temp > *temp_field)
> > > > > + return -EINVAL;
> > > >
> > > > i think it would be more practical for users to increase and later decrease the fan curve values.
> > > > Could the driver copy the original fan curve configuration and use that instead? This would also
> > > > require to restore the original fan curve during shutdown and removal.
> > >
> > > That would be possible. We would would have to expose these limits
> > > through a new UAPI as otherwise the user has no way to know about them.
> > > Restoring the original on shutdown shouldn't be necessary, as the EC
> > > will reset the curves at shutdown anyways.
> >
> > (And what about kexec?)
> >
> > Ok, i myself would also interested in having a UAPI for communicating fan curve constraints to userspace as i am planning to add a similar feature to the uniwill-laptop driver.
> >
> > I can think of two approaches:
> >
> > 1. Clamp the values into the supported range, userspace will have to read back the written value to know the current setting.
> >
>
> ... which is widely used in hwmon drivers, so it is not special.
> We don't usually expect userspace to know the valid attribute range.
That works for me.
What should be clamp to, though?
The range active during probe or the currently active one?
> > 2. Introducing a new tempX_auto_pointY_temp_min attribute to communicate the constraint to userspace.
> >
> > Guenter, do you have a preference for one of the approaches? Personally
> > i would prefer approach number 2.
> >
>
> Again, we don't usually provide constraints for limit attributes
> to userspace. Otherwise we would need separate _min and _max attributes
> for literally every limit attribute. That would add a lot of complexity
> for little if any gain.
One constraint that exists today is the range accepted by kstrtol(),
which can return -ERANGE. Not that I want to argue that this is an
issue and requires change, just pointing it out.
> Worse, almost all attributes do not just have min/max constraints but
> step size constraints as well. Hardware does not typically accept values
> in millisecond/millivolt etc. but have varying step sizes. How would you
> express that ? The hardware won't accept a temperature of, say, 27.123
> degrees C. Hwmon drivers are expected to adjust that to the next supported
> value. That means userspace has to read the value back to know that value
> anyway. Or do you plan to provide the step size to userspace as well ?
> What would you do if the step size is non-linear ?
To me the step size argument is slightly different than the range one.
The difference between the values provided by the user and the one
actually used ones should be fairly small, while for the range it may be
much larger. Not that it makes a difference here.
> On top of that, _min and _max attributes are already associated with
> limits. I would find it confusing if new attributes would redefine that
> naming scheme to supported ranges.
Ack.
(...)
^ permalink raw reply
* Re: [PATCH] mfd: cros_ec: Read EC features during probe to catch transfer error
From: Andrei Kuchynski @ 2026-06-08 13:56 UTC (permalink / raw)
To: Lee Jones
Cc: Benson Leung, Tzung-Bi Shih, Guenter Roeck, Gwendal Grignou,
chrome-platform, linux-kernel
In-Reply-To: <20260604155747.GD4151951@google.com>
On Thu, Jun 4, 2026 at 5:57 PM Lee Jones <lee@kernel.org> wrote:
>
> On Fri, 22 May 2026, Andrei Kuchynski wrote:
>
> > cros_ec_check_features() does not return an error if the underlying
> > EC_CMD_GET_FEATURES command fails. Consequently, when the Fingerprint
> > device fails to respond, the probe function ignores the failure and falls
> > back to installing it as 'cros_ec' device instead of 'cros_fp'.
> > This leads to a sysfs duplicate filename collision later when the real
> > 'cros_ec' device attempts to register:
> >
> > cros-ec-spi spi5.0: EC failed to respond in time
> > cros-ec-dev.19.auto: cannot get EC features: -110
> > sysfs : cannot create duplicate filename '/class/chromeos/cros_ec'
> > : sysfs_do_create_link_sd+0x94/0xdc
> > : ec_device_probe+0x150/0x4f0
> >
> > Fix this by extracting the feature reading logic into a new helper function
> > cros_ec_read_features() and calling it during ec_device_probe().
> > If the transfer fails, abort the broken device initialization.
>
> You're doing 2 things here. Move the function first, then add the new
> call into MFD in a subsequent patch.
>
I will split this into 2-patch series for v2:
- Patch 1 introduces the helper function in platform/chrome.
- Patch 2 consumes the helper in the MFD driver to resolve the bug.
> > Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
> > ---
> > drivers/mfd/cros_ec_dev.c | 4 +++
> > drivers/platform/chrome/cros_ec_proto.c | 30 +++++++++++++++------
> > include/linux/platform_data/cros_ec_proto.h | 2 ++
> > 3 files changed, 28 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> > index 39430dd44e30c..7810b1c871849 100644
> > --- a/drivers/mfd/cros_ec_dev.c
> > +++ b/drivers/mfd/cros_ec_dev.c
> > @@ -203,6 +203,10 @@ static int ec_device_probe(struct platform_device *pdev)
> > ec->features.flags[1] = -1U; /* Not cached yet */
> > device_initialize(&ec->class_dev);
> >
> > + retval = cros_ec_read_features(ec);
> > + if (retval < 0)
> > + return retval;
>
> You just leaked ec->class_dev.
>
> goto failed; ?
>
You are completely right.
I will also change the initialization sequence so that the `class_dev`
fields (class, parent, and release callback) are fully assigned before
this to prevent the warning:
Device '(null)' does not have a release() function, it is broken and
must be fixed. See Documentation/core-api/kobject.rst.
WARNING: CPU: 6 PID: 132 at drivers/base/core.c:2569
device_release+0x9c/0xb0
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH 5/5] hwmon: (cros_ec) Allow modification of fan curves
From: Guenter Roeck @ 2026-06-08 13:34 UTC (permalink / raw)
To: Armin Wolf, Thomas Weißschuh
Cc: Benson Leung, Shuah Khan, Guenter Roeck, chrome-platform,
linux-hwmon, linux-kernel
In-Reply-To: <8b8f5a9f-4a44-4e93-9ff6-c2e13a6b8797@gmx.de>
On 6/4/26 03:33, Armin Wolf wrote:
> Am 04.06.26 um 11:04 schrieb Thomas Weißschuh:
>> On 2026-05-30 18:37:32+0200, Armin Wolf wrote:
>>> Am 29.05.26 um 22:31 schrieb Thomas Weißschuh:
>>
>> (...)
>>
>>>> +static ssize_t temp_auto_point_temp_store(struct device *dev, struct device_attribute *attr,
>>>> + const char *buf, size_t size)
>>>> +{
>>>> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
>>>> + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
>>>> + struct ec_thermal_config config;
>>>> + u32 *temp_field;
>>>> + s64 temp;
>>>> + int ret;
>>>> +
>>>> + ret = kstrtos64(buf, 10, &temp);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + temp = cros_ec_hwmon_millicelsius_to_kelvin(temp);
>>>> +
>>>> + if (overflows_type(temp, config.temp_fan_off))
>>>> + return -ERANGE;
>>>> +
>>>> + guard(hwmon_lock)(dev);
>>>> +
>>>> + ret = cros_ec_hwmon_get_thermal_config(priv->cros_ec, sattr->index, &config);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (cros_ec_hwmon_attr_is_temp_fan_off(sattr))
>>>> + temp_field = &config.temp_fan_off;
>>>> + else /* temp_fan_max */
>>>> + temp_field = &config.temp_fan_max;
>>>> +
>>>> + /* Only allow values which are more aggressive than the current ones */
>>>> + if (temp > *temp_field)
>>>> + return -EINVAL;
>>>
>>> i think it would be more practical for users to increase and later decrease the fan curve values.
>>> Could the driver copy the original fan curve configuration and use that instead? This would also
>>> require to restore the original fan curve during shutdown and removal.
>>
>> That would be possible. We would would have to expose these limits
>> through a new UAPI as otherwise the user has no way to know about them.
>> Restoring the original on shutdown shouldn't be necessary, as the EC
>> will reset the curves at shutdown anyways.
>
> (And what about kexec?)
>
> Ok, i myself would also interested in having a UAPI for communicating fan curve constraints to userspace as i am planning to add a similar feature to the uniwill-laptop driver.
>
> I can think of two approaches:
>
> 1. Clamp the values into the supported range, userspace will have to read back the written value to know the current setting.
>
... which is widely used in hwmon drivers, so it is not special.
We don't usually expect userspace to know the valid attribute range.
> 2. Introducing a new tempX_auto_pointY_temp_min attribute to communicate the constraint to userspace.
>
> Guenter, do you have a preference for one of the approaches? Personally
> i would prefer approach number 2.
>
Again, we don't usually provide constraints for limit attributes
to userspace. Otherwise we would need separate _min and _max attributes
for literally every limit attribute. That would add a lot of complexity
for little if any gain.
Worse, almost all attributes do not just have min/max constraints but
step size constraints as well. Hardware does not typically accept values
in millisecond/millivolt etc. but have varying step sizes. How would you
express that ? The hardware won't accept a temperature of, say, 27.123
degrees C. Hwmon drivers are expected to adjust that to the next supported
value. That means userspace has to read the value back to know that value
anyway. Or do you plan to provide the step size to userspace as well ?
What would you do if the step size is non-linear ?
On top of that, _min and _max attributes are already associated with
limits. I would find it confusing if new attributes would redefine that
naming scheme to supported ranges.
>>
>> I am not so sure that it would be generally useful though. Let's hear
>> what other people think about it.
>
> The uniwill-laptop driver will (likely) gain support for a similar feature in the future, so having such a UAPI would be beneficial.
>
FWIW, as long as it does not reside in drivers/hwmon/, you can add any attribute
you want, and even violate the documented UAPI. That is one of the "advantages"
of having hwmon drivers reside outside drivers/hwmon/.
Guenter
^ permalink raw reply
* Re: [PATCH v1 1/2] hwmon: cros_ec: Drop unused assignment of platform_device_id driver data
From: Guenter Roeck @ 2026-06-08 0:25 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Thomas Weißschuh, Benson Leung, chrome-platform, linux-hwmon,
linux-kernel
In-Reply-To: <972c9998054c7944f63266819d6fb08b36edb5c5.1779894738.git.u.kleine-koenig@baylibre.com>
On Wed, May 27, 2026 at 05:15:52PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The driver explicitly set the .driver_data member of struct
> platform_device_id to zero without relying on that value. Drop this
> unused assignments.
>
> While touching this array unify spacing and use named initializers for
> .name.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
> Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] mfd: cros_ec: Read EC features during probe to catch transfer error
From: Lee Jones @ 2026-06-04 15:57 UTC (permalink / raw)
To: Andrei Kuchynski
Cc: Benson Leung, Tzung-Bi Shih, Guenter Roeck, Gwendal Grignou,
chrome-platform, linux-kernel
In-Reply-To: <20260522154456.1448170-1-akuchynski@chromium.org>
On Fri, 22 May 2026, Andrei Kuchynski wrote:
> cros_ec_check_features() does not return an error if the underlying
> EC_CMD_GET_FEATURES command fails. Consequently, when the Fingerprint
> device fails to respond, the probe function ignores the failure and falls
> back to installing it as 'cros_ec' device instead of 'cros_fp'.
> This leads to a sysfs duplicate filename collision later when the real
> 'cros_ec' device attempts to register:
>
> cros-ec-spi spi5.0: EC failed to respond in time
> cros-ec-dev.19.auto: cannot get EC features: -110
> sysfs : cannot create duplicate filename '/class/chromeos/cros_ec'
> : sysfs_do_create_link_sd+0x94/0xdc
> : ec_device_probe+0x150/0x4f0
>
> Fix this by extracting the feature reading logic into a new helper function
> cros_ec_read_features() and calling it during ec_device_probe().
> If the transfer fails, abort the broken device initialization.
You're doing 2 things here. Move the function first, then add the new
call into MFD in a subsequent patch.
> Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
> ---
> drivers/mfd/cros_ec_dev.c | 4 +++
> drivers/platform/chrome/cros_ec_proto.c | 30 +++++++++++++++------
> include/linux/platform_data/cros_ec_proto.h | 2 ++
> 3 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 39430dd44e30c..7810b1c871849 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -203,6 +203,10 @@ static int ec_device_probe(struct platform_device *pdev)
> ec->features.flags[1] = -1U; /* Not cached yet */
> device_initialize(&ec->class_dev);
>
> + retval = cros_ec_read_features(ec);
> + if (retval < 0)
> + return retval;
You just leaked ec->class_dev.
goto failed; ?
> +
> for (i = 0; i < ARRAY_SIZE(cros_mcu_devices); i++) {
> /*
> * Check whether this is actually a dedicated MCU rather
> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
> index 1d8d9168ec1aa..724d1313f6b21 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -946,6 +946,27 @@ u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev)
> }
> EXPORT_SYMBOL(cros_ec_get_host_event);
>
> +/**
> + * cros_ec_read_features() - Read EC features
> + *
> + * @ec: EC device.
> + *
> + * Return: >= 0 on success, negative error number on failure.
> + */
> +int cros_ec_read_features(struct cros_ec_dev *ec)
> +{
> + int ret = cros_ec_cmd(ec->ec_dev, 0, EC_CMD_GET_FEATURES + ec->cmd_offset,
> + NULL, 0, &ec->features, sizeof(ec->features));
> +
> + if (ret < 0) {
> + dev_warn(ec->dev, "cannot get EC features: %d\n", ret);
> + memset(&ec->features, 0, sizeof(ec->features));
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_features);
> +
> /**
> * cros_ec_check_features() - Test for the presence of EC features
> *
> @@ -960,17 +981,10 @@ EXPORT_SYMBOL(cros_ec_get_host_event);
> bool cros_ec_check_features(struct cros_ec_dev *ec, int feature)
> {
> struct ec_response_get_features *features = &ec->features;
> - int ret;
>
> if (features->flags[0] == -1U && features->flags[1] == -1U) {
> /* features bitmap not read yet */
> - ret = cros_ec_cmd(ec->ec_dev, 0, EC_CMD_GET_FEATURES + ec->cmd_offset,
> - NULL, 0, features, sizeof(*features));
> - if (ret < 0) {
> - dev_warn(ec->dev, "cannot get EC features: %d\n", ret);
> - memset(features, 0, sizeof(*features));
> - }
> -
> + cros_ec_read_features(ec);
> dev_dbg(ec->dev, "EC features %08x %08x\n",
> features->flags[0], features->flags[1]);
> }
> diff --git a/include/linux/platform_data/cros_ec_proto.h b/include/linux/platform_data/cros_ec_proto.h
> index 6ed1c4c5ce2ef..a1ccecf5e1f83 100644
> --- a/include/linux/platform_data/cros_ec_proto.h
> +++ b/include/linux/platform_data/cros_ec_proto.h
> @@ -271,6 +271,8 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
>
> u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
>
> +int cros_ec_read_features(struct cros_ec_dev *ec);
> +
> bool cros_ec_check_features(struct cros_ec_dev *ec, int feature);
>
> int cros_ec_get_sensor_count(struct cros_ec_dev *ec);
> --
> 2.54.0.746.g67dd491aae-goog
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 5/5] hwmon: (cros_ec) Allow modification of fan curves
From: Armin Wolf @ 2026-06-04 10:33 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Guenter Roeck, Benson Leung, Shuah Khan, Guenter Roeck,
chrome-platform, linux-hwmon, linux-kernel
In-Reply-To: <6a4a2d2c-4717-4cc9-8dd3-05f8b0905865@t-8ch.de>
Am 04.06.26 um 11:04 schrieb Thomas Weißschuh:
> On 2026-05-30 18:37:32+0200, Armin Wolf wrote:
>> Am 29.05.26 um 22:31 schrieb Thomas Weißschuh:
>
> (...)
>
>>> +static ssize_t temp_auto_point_temp_store(struct device *dev, struct device_attribute *attr,
>>> + const char *buf, size_t size)
>>> +{
>>> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
>>> + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
>>> + struct ec_thermal_config config;
>>> + u32 *temp_field;
>>> + s64 temp;
>>> + int ret;
>>> +
>>> + ret = kstrtos64(buf, 10, &temp);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + temp = cros_ec_hwmon_millicelsius_to_kelvin(temp);
>>> +
>>> + if (overflows_type(temp, config.temp_fan_off))
>>> + return -ERANGE;
>>> +
>>> + guard(hwmon_lock)(dev);
>>> +
>>> + ret = cros_ec_hwmon_get_thermal_config(priv->cros_ec, sattr->index, &config);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (cros_ec_hwmon_attr_is_temp_fan_off(sattr))
>>> + temp_field = &config.temp_fan_off;
>>> + else /* temp_fan_max */
>>> + temp_field = &config.temp_fan_max;
>>> +
>>> + /* Only allow values which are more aggressive than the current ones */
>>> + if (temp > *temp_field)
>>> + return -EINVAL;
>>
>> i think it would be more practical for users to increase and later decrease the fan curve values.
>> Could the driver copy the original fan curve configuration and use that instead? This would also
>> require to restore the original fan curve during shutdown and removal.
>
> That would be possible. We would would have to expose these limits
> through a new UAPI as otherwise the user has no way to know about them.
> Restoring the original on shutdown shouldn't be necessary, as the EC
> will reset the curves at shutdown anyways.
(And what about kexec?)
Ok, i myself would also interested in having a UAPI for communicating
fan curve constraints to userspace as i am planning to add a similar
feature to the uniwill-laptop driver.
I can think of two approaches:
1. Clamp the values into the supported range, userspace will have to
read back the written value to know the current setting.
2. Introducing a new tempX_auto_pointY_temp_min attribute to communicate
the constraint to userspace.
Guenter, do you have a preference for one of the approaches? Personally
i would prefer approach number 2.
>
> I am not so sure that it would be generally useful though. Let's hear
> what other people think about it.
The uniwill-laptop driver will (likely) gain support for a similar
feature in the future, so having such a UAPI would be beneficial.
Thanks,
Armin Wolf
>> Thanks,
>> Armin Wolf
>>
>>> +
>>> + *temp_field = temp;
>>> +
>>> + if (config.temp_fan_off > config.temp_fan_max)
>>> + return -EINVAL;
>>> +
>>> + ret = cros_ec_hwmon_set_thermal_config(priv->cros_ec, sattr->index, &config);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return size;
>>> +}
>
> (...)
>
^ permalink raw reply
* Re: [PATCH 5/5] hwmon: (cros_ec) Allow modification of fan curves
From: Thomas Weißschuh @ 2026-06-04 9:04 UTC (permalink / raw)
To: Armin Wolf
Cc: Guenter Roeck, Benson Leung, Shuah Khan, Guenter Roeck,
chrome-platform, linux-hwmon, linux-kernel
In-Reply-To: <87825203-0bbb-46a4-8939-a904f5a546ab@gmx.de>
On 2026-05-30 18:37:32+0200, Armin Wolf wrote:
> Am 29.05.26 um 22:31 schrieb Thomas Weißschuh:
(...)
> > +static ssize_t temp_auto_point_temp_store(struct device *dev, struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> > + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
> > + struct ec_thermal_config config;
> > + u32 *temp_field;
> > + s64 temp;
> > + int ret;
> > +
> > + ret = kstrtos64(buf, 10, &temp);
> > + if (ret)
> > + return ret;
> > +
> > + temp = cros_ec_hwmon_millicelsius_to_kelvin(temp);
> > +
> > + if (overflows_type(temp, config.temp_fan_off))
> > + return -ERANGE;
> > +
> > + guard(hwmon_lock)(dev);
> > +
> > + ret = cros_ec_hwmon_get_thermal_config(priv->cros_ec, sattr->index, &config);
> > + if (ret)
> > + return ret;
> > +
> > + if (cros_ec_hwmon_attr_is_temp_fan_off(sattr))
> > + temp_field = &config.temp_fan_off;
> > + else /* temp_fan_max */
> > + temp_field = &config.temp_fan_max;
> > +
> > + /* Only allow values which are more aggressive than the current ones */
> > + if (temp > *temp_field)
> > + return -EINVAL;
>
> i think it would be more practical for users to increase and later decrease the fan curve values.
> Could the driver copy the original fan curve configuration and use that instead? This would also
> require to restore the original fan curve during shutdown and removal.
That would be possible. We would would have to expose these limits
through a new UAPI as otherwise the user has no way to know about them.
Restoring the original on shutdown shouldn't be necessary, as the EC
will reset the curves at shutdown anyways.
I am not so sure that it would be generally useful though. Let's hear
what other people think about it.
> Thanks,
> Armin Wolf
>
> > +
> > + *temp_field = temp;
> > +
> > + if (config.temp_fan_off > config.temp_fan_max)
> > + return -EINVAL;
> > +
> > + ret = cros_ec_hwmon_set_thermal_config(priv->cros_ec, sattr->index, &config);
> > + if (ret)
> > + return ret;
> > +
> > + return size;
> > +}
(...)
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: Add #{address,size}-cells to Chromium-based /firmware
From: Dmitry Baryshkov @ 2026-06-03 22:59 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Julius Werner, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260428200712.2660635-8-briannorris@chromium.org>
On Tue, Apr 28, 2026 at 01:06:59PM -0700, Brian Norris wrote:
> Chromium/Depthcharge bootloaders may dynamically add a few device nodes
> to a system's DTB under a /firmware node. A typical DT looks something
> like the following:
>
> / {
> firmware {
> ranges;
>
> coreboot {
> compatible = "coreboot";
> reg = <...>;
> ...;
> };
> };
> };
>
> Notably, the /firmware node has an empty 'ranges', but does not have
> address/size-cells.
>
> Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
> non-translatable addresses") started requiring #address-cells for a
> device's parent if we want to use the reg resource in a device node.
> This leads to errors like the following:
>
> [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> Add appropriate #{address,size}-cells to work around the problem.
>
> Note that Google has also patched the Depthcharge bootloader source to
> add {address,size}-cells [1], but bootloader updates are typically
> delivered only via Google OS updates. Not all users install Google
> software updates, and even if they do, Google may not produce updated
> binaries for all/older devices.
>
> [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/
> https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
> #size-cells for firmware node")
>
> Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
> Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 02/83] ASoC: codecs: framer-codec: don't use array if single pattarn
From: Kuninori Morimoto @ 2026-06-03 22:30 UTC (permalink / raw)
To: Herve Codina
Cc: Alvin Šipraga, J.M.B. Downing, Martin Povišer,
Nuno Sá, Uwe Kleine-König (The Capable Hub),
Alexandre Belloni, Alexandre Torgue, AngeloGioacchino Del Regno,
Arnaud Pouliquen, Baojun Xu, Bartosz Golaszewski, Ben Bright,
Benson Leung, Biju Das, Binbin Zhou, Bram Vlerick, Charles Keepax,
Chen-Yu Tsai, Cheng-Yi Chiang, Claudiu Beznea, Cristian Ciocaltea,
Daniel Mack, Dario Binacchi, David Rhodes, Fabio Estevam,
Florian Fainelli, Frank Li, Fred Treven, Geert Uytterhoeven,
Guenter Roeck, Guoqing Jiang, Haojian Zhuang, HariKrishna Sagala,
Heiko Stuebner, Hsieh Hung-En, James Ogletree, Jarkko Nikula,
Jaroslav Kysela, Jernej Skrabec, Jerome Brunet, Jihed Chaibi,
Jonathan Hunter, Kevin Cernekee, Kevin Hilman, Kevin Lu,
Kirill Marinushkin, Kiseok Jo, Krzysztof Kozlowski,
Kunihiko Hayashi, Lad Prabhakar, Lars-Peter Clausen,
Liam Girdwood, Luca Ceresoli, M R Swami Reddy, Mark Brown,
Martin Blumenstingl, Masami Hiramatsu, Matthias Brugger,
Max Filippov, Maxime Coquelin, Neil Armstrong, Nicolas Ferre,
Nicolas Frattaroli, Nicolin Chen, Oder Chiou, Olivier Moysan,
Paul Cercueil, Peter Rosin, Piotr Wojtaszczyk, Qianfeng Rong,
Ray Jui, Richard Fitzgerald, Robert Jarzmik, Samuel Holland,
Sascha Hauer, Scott Branden, Sen Wang, Sharique Mohammad,
Shenghao Ding, Shengjiu Wang, Steven Eckhoff, Support Opensource,
Sylwester Nawrocki, Takashi Iwai, Thierry Reding, Tim Bird,
Troy Mitchell, Tzung-Bi Shih, Venkata Prasad Potturu,
Vijendar Mukunda, Vishwas A Deshpande, Vladimir Zapolskiy,
Xiubo Li, Yixun Lan, Zhang Yi, chrome-platform, imx,
linux-arm-kernel, linux-mips, linux-renesas-soc, linux-riscv,
linux-sound, spacemit
In-Reply-To: <20260603140939.091f126f@bootlin.com>
Hi Herve
> > Because it is confusable during debugging ASoC FW update, tidyup
> > auto format style not to use array if single pattern case.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
(snip)
> Just a typo in the commit title:
> s/pattarn/pattern/
Oops, thank you for pointing it.
Will fix in v2
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: (subset) [PATCH v1 0/6] power: Use named initializers for platform_device_id arrays
From: Sebastian Reichel @ 2026-06-03 20:46 UTC (permalink / raw)
To: Sebastian Reichel, Uwe Kleine-König (The Capable Hub)
Cc: Kuan-Wei Chiu, Benson Leung, Guenter Roeck, Thomas Weißschuh,
Krzysztof Kozlowski, Matthias Brugger, AngeloGioacchino Del Regno,
linux-pm, linux-kernel, chrome-platform, linux-arm-kernel,
linux-mediatek, Hans de Goede, Marek Szyprowski,
Sebastian Krzyszkowiak, Purism Kernel Team, Yixun Lan,
Andreas Kemnade, Matti Vaittinen, Sven Peter, Janne Grunau,
Neal Gompa, Amit Sunil Dhamne, Samuel Kayode, linux-riscv,
spacemit, asahi, imx, Chen-Yu Tsai
In-Reply-To: <cover.1780048925.git.u.kleine-koenig@baylibre.com>
On Fri, 29 May 2026 12:18:15 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -610,4 +610,7 @@ struct dmi_system_id {
> struct platform_device_id {
> char name[PLATFORM_NAME_SIZE];
> - kernel_ulong_t driver_data;
> + union {
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
>
> [...]
Applied, thanks!
[1/6] power: Drop unused assignment of platform_device_id driver data
commit: 75a0e1e0b86078687c3c6a05107a98c7e59a65a8
[2/6] power: supply: max14577: Drop driver data in of and platform device id arrays
commit: 37258ad1f3a52ea442c32b3c92ad7146e74050c7
[4/6] power: Use named initializers for platform_device_id arrays
commit: e28f7498dd819878b8acacb89c4c073a646feea0
[5/6] power: supply: mt6360_charger: Use of match table unconditionally
commit: eb7ed650e5960fc303130704d1e29d18a7d0e1df
[6/6] power: Unify code style for platform_device_id arrays
commit: e3f669bed32287ae72c05a4ddab4a6687b0e62ca
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs
From: Brian Norris @ 2026-06-03 17:23 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson
Cc: devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, Julius Werner, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Chen-Yu Tsai
In-Reply-To: <20260428200712.2660635-1-briannorris@chromium.org>
(Trim address list)
Hi Bjorn, AngeloGioacchino,
On Tue, Apr 28, 2026 at 01:06:52PM -0700, Brian Norris wrote:
...
> The /firmware node has an empty 'ranges', but does not have
> address/size-cells.
>
> Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
> non-translatable addresses") started requiring #address-cells for a
> device's parent if we want to use the reg resource in a device node.
> This leads to errors like the following:
>
> [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> This series adds appropriate #{address,size}-cells to the device trees
> used on Arm Chromebooks to work around the problem.
...
> Brian Norris (7):
> arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based
> /firmware
> ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based
> /firmware
> ARM: dts: nvidia: Add #{address,size}-cells to Chromium-based
> /firmware
> ARM: dts: samsung: Add #{address,size}-cells to Chromium-based
> /firmware
> arm64: dts: mediatek: Add #{address,size}-cells to Chromium-based
> /firmware
> arm64: dts: nvidia: Add #{address,size}-cells to Chromium-based
> /firmware
> arm64: dts: qcom: Add #{address,size}-cells to Chromium-based
> /firmware
Patch 1 and 2 (Rockchip) and 3 and 6 (Nvidia) are applied to linux-next.
Patch 4 is obsolete / unnecessary. That leaves patch 5 (Mediatek) and 7
(Qualcomm).
Bjorn (Qualcomm) and AngeloGioacchino (Mediatek), any thoughts? I can
resend them separately if that helps somehow.
Regards,
Brian
^ permalink raw reply
* Re: [PATCH 04/83] ASoC: codecs: peb2466: don't use array if single pattarn
From: Herve Codina @ 2026-06-03 12:17 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Alvin Šipraga, J.M.B. Downing, Martin Povišer,
Nuno Sá, Uwe Kleine-König (The Capable Hub),
Alexandre Belloni, Alexandre Torgue, AngeloGioacchino Del Regno,
Arnaud Pouliquen, Baojun Xu, Bartosz Golaszewski, Ben Bright,
Benson Leung, Biju Das, Binbin Zhou, Bram Vlerick, Charles Keepax,
Chen-Yu Tsai, Cheng-Yi Chiang, Claudiu Beznea, Cristian Ciocaltea,
Daniel Mack, Dario Binacchi, David Rhodes, Fabio Estevam,
Florian Fainelli, Frank Li, Fred Treven, Geert Uytterhoeven,
Guenter Roeck, Guoqing Jiang, Haojian Zhuang, HariKrishna Sagala,
Heiko Stuebner, Hsieh Hung-En, James Ogletree, Jarkko Nikula,
Jaroslav Kysela, Jernej Skrabec, Jerome Brunet, Jihed Chaibi,
Jonathan Hunter, Kevin Cernekee, Kevin Hilman, Kevin Lu,
Kirill Marinushkin, Kiseok Jo, Krzysztof Kozlowski,
Kunihiko Hayashi, Lad Prabhakar, Lars-Peter Clausen,
Liam Girdwood, Luca Ceresoli, M R Swami Reddy, Mark Brown,
Martin Blumenstingl, Masami Hiramatsu, Matthias Brugger,
Max Filippov, Maxime Coquelin, Neil Armstrong, Nicolas Ferre,
Nicolas Frattaroli, Nicolin Chen, Oder Chiou, Olivier Moysan,
Paul Cercueil, Peter Rosin, Piotr Wojtaszczyk, Qianfeng Rong,
Ray Jui, Richard Fitzgerald, Robert Jarzmik, Samuel Holland,
Sascha Hauer, Scott Branden, Sen Wang, Sharique Mohammad,
Shenghao Ding, Shengjiu Wang, Steven Eckhoff, Support Opensource,
Sylwester Nawrocki, Takashi Iwai, Thierry Reding, Tim Bird,
Troy Mitchell, Tzung-Bi Shih, Venkata Prasad Potturu,
Vijendar Mukunda, Vishwas A Deshpande, Vladimir Zapolskiy,
Xiubo Li, Yixun Lan, Zhang Yi, chrome-platform, imx,
linux-arm-kernel, linux-mips, linux-renesas-soc, linux-riscv,
linux-sound, spacemit
In-Reply-To: <87wlwrhqxf.wl-kuninori.morimoto.gx@renesas.com>
Hi Kuninori,
On Tue, 26 May 2026 01:59:08 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
> Because it is confusable during debugging ASoC FW update, tidyup
> auto format style not to use array if single pattern case.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> sound/soc/codecs/peb2466.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
Same typo in the commit title as in patch 2:
s/pattarn/pattern/
Or even
s/pattarn/item/
With that fixed,
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 03/83] ASoC: codecs: idt821034: don't use array if single pattarn
From: Herve Codina @ 2026-06-03 12:11 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Alvin Šipraga, J.M.B. Downing, Martin Povišer,
Nuno Sá, Uwe Kleine-König (The Capable Hub),
Alexandre Belloni, Alexandre Torgue, AngeloGioacchino Del Regno,
Arnaud Pouliquen, Baojun Xu, Bartosz Golaszewski, Ben Bright,
Benson Leung, Biju Das, Binbin Zhou, Bram Vlerick, Charles Keepax,
Chen-Yu Tsai, Cheng-Yi Chiang, Claudiu Beznea, Cristian Ciocaltea,
Daniel Mack, Dario Binacchi, David Rhodes, Fabio Estevam,
Florian Fainelli, Frank Li, Fred Treven, Geert Uytterhoeven,
Guenter Roeck, Guoqing Jiang, Haojian Zhuang, HariKrishna Sagala,
Heiko Stuebner, Hsieh Hung-En, James Ogletree, Jarkko Nikula,
Jaroslav Kysela, Jernej Skrabec, Jerome Brunet, Jihed Chaibi,
Jonathan Hunter, Kevin Cernekee, Kevin Hilman, Kevin Lu,
Kirill Marinushkin, Kiseok Jo, Krzysztof Kozlowski,
Kunihiko Hayashi, Lad Prabhakar, Lars-Peter Clausen,
Liam Girdwood, Luca Ceresoli, M R Swami Reddy, Mark Brown,
Martin Blumenstingl, Masami Hiramatsu, Matthias Brugger,
Max Filippov, Maxime Coquelin, Neil Armstrong, Nicolas Ferre,
Nicolas Frattaroli, Nicolin Chen, Oder Chiou, Olivier Moysan,
Paul Cercueil, Peter Rosin, Piotr Wojtaszczyk, Qianfeng Rong,
Ray Jui, Richard Fitzgerald, Robert Jarzmik, Samuel Holland,
Sascha Hauer, Scott Branden, Sen Wang, Sharique Mohammad,
Shenghao Ding, Shengjiu Wang, Steven Eckhoff, Support Opensource,
Sylwester Nawrocki, Takashi Iwai, Thierry Reding, Tim Bird,
Troy Mitchell, Tzung-Bi Shih, Venkata Prasad Potturu,
Vijendar Mukunda, Vishwas A Deshpande, Vladimir Zapolskiy,
Xiubo Li, Yixun Lan, Zhang Yi, chrome-platform, imx,
linux-arm-kernel, linux-mips, linux-renesas-soc, linux-riscv,
linux-sound, spacemit
In-Reply-To: <87y0h7hqxo.wl-kuninori.morimoto.gx@renesas.com>
Hi Kuninori,
On Tue, 26 May 2026 01:58:59 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
> Because it is confusable during debugging ASoC FW update, tidyup
> auto format style not to use array if single pattern case.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> sound/soc/codecs/idt821034.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/sound/soc/codecs/idt821034.c b/sound/soc/codecs/idt821034.c
> index 39bafefa6a186..084090ccef77a 100644
> --- a/sound/soc/codecs/idt821034.c
> +++ b/sound/soc/codecs/idt821034.c
> @@ -860,18 +860,17 @@ static int idt821034_dai_startup(struct snd_pcm_substream *substream,
> return 0;
> }
>
> -static const u64 idt821034_dai_formats[] = {
> +static const u64 idt821034_dai_formats =
> SND_SOC_POSSIBLE_DAIFMT_DSP_A |
> - SND_SOC_POSSIBLE_DAIFMT_DSP_B,
> -};
> + SND_SOC_POSSIBLE_DAIFMT_DSP_B;
>
> static const struct snd_soc_dai_ops idt821034_dai_ops = {
> .startup = idt821034_dai_startup,
> .hw_params = idt821034_dai_hw_params,
> .set_tdm_slot = idt821034_dai_set_tdm_slot,
> .set_fmt = idt821034_dai_set_fmt,
> - .auto_selectable_formats = idt821034_dai_formats,
> - .num_auto_selectable_formats = ARRAY_SIZE(idt821034_dai_formats),
> + .auto_selectable_formats = &idt821034_dai_formats,
> + .num_auto_selectable_formats = 1,
> };
>
> static struct snd_soc_dai_driver idt821034_dai_driver = {
Same typo in the commit title as in patch 2:
s/pattarn/pattern/
Or even
s/pattarn/item/
With that fixed,
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 02/83] ASoC: codecs: framer-codec: don't use array if single pattarn
From: Herve Codina @ 2026-06-03 12:09 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Alvin Šipraga, J.M.B. Downing, Martin Povišer,
Nuno Sá, Uwe Kleine-König (The Capable Hub),
Alexandre Belloni, Alexandre Torgue, AngeloGioacchino Del Regno,
Arnaud Pouliquen, Baojun Xu, Bartosz Golaszewski, Ben Bright,
Benson Leung, Biju Das, Binbin Zhou, Bram Vlerick, Charles Keepax,
Chen-Yu Tsai, Cheng-Yi Chiang, Claudiu Beznea, Cristian Ciocaltea,
Daniel Mack, Dario Binacchi, David Rhodes, Fabio Estevam,
Florian Fainelli, Frank Li, Fred Treven, Geert Uytterhoeven,
Guenter Roeck, Guoqing Jiang, Haojian Zhuang, HariKrishna Sagala,
Heiko Stuebner, Hsieh Hung-En, James Ogletree, Jarkko Nikula,
Jaroslav Kysela, Jernej Skrabec, Jerome Brunet, Jihed Chaibi,
Jonathan Hunter, Kevin Cernekee, Kevin Hilman, Kevin Lu,
Kirill Marinushkin, Kiseok Jo, Krzysztof Kozlowski,
Kunihiko Hayashi, Lad Prabhakar, Lars-Peter Clausen,
Liam Girdwood, Luca Ceresoli, M R Swami Reddy, Mark Brown,
Martin Blumenstingl, Masami Hiramatsu, Matthias Brugger,
Max Filippov, Maxime Coquelin, Neil Armstrong, Nicolas Ferre,
Nicolas Frattaroli, Nicolin Chen, Oder Chiou, Olivier Moysan,
Paul Cercueil, Peter Rosin, Piotr Wojtaszczyk, Qianfeng Rong,
Ray Jui, Richard Fitzgerald, Robert Jarzmik, Samuel Holland,
Sascha Hauer, Scott Branden, Sen Wang, Sharique Mohammad,
Shenghao Ding, Shengjiu Wang, Steven Eckhoff, Support Opensource,
Sylwester Nawrocki, Takashi Iwai, Thierry Reding, Tim Bird,
Troy Mitchell, Tzung-Bi Shih, Venkata Prasad Potturu,
Vijendar Mukunda, Vishwas A Deshpande, Vladimir Zapolskiy,
Xiubo Li, Yixun Lan, Zhang Yi, chrome-platform, imx,
linux-arm-kernel, linux-mips, linux-renesas-soc, linux-riscv,
linux-sound, spacemit
In-Reply-To: <87zf1nhqxx.wl-kuninori.morimoto.gx@renesas.com>
Hi Kuninori,
On Tue, 26 May 2026 01:58:50 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
> Because it is confusable during debugging ASoC FW update, tidyup
> auto format style not to use array if single pattern case.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> sound/soc/codecs/framer-codec.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
Just a typo in the commit title:
s/pattarn/pattern/
Or even
s/pattarn/item/
With that fixed,
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Best regards,
Hervé
^ permalink raw reply
page: next (older)
- 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