* [PATCH v2 2/3] hwmon: ina2xx: support ina232
From: Loic Poulain @ 2026-06-11 14:05 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-hwmon, devicetree, linux-kernel,
linux-arm-msm, Loic Poulain, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com>
From: Martino Facchin <m.facchin@arduino.cc>
The INA232 is a current/power monitor. It shares the same register
layout as the INA2xx and uses the INA226 default configuration, but
differs in its electrical characteristics:
Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/hwmon/ina2xx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 613ffb622b7c42b8b6090d3b4ec7b2fa412e24a4..fc2319ad99fc398a50e97ee617f67255bd0b3038 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -122,6 +122,7 @@ static const struct regmap_config ina2xx_regmap_config = {
enum ina2xx_ids {
ina219,
ina226,
+ ina232,
ina234,
ina260,
sy24655
@@ -196,6 +197,20 @@ static const struct ina2xx_config ina2xx_config[] = {
.current_shift = 4,
.has_update_interval = true,
},
+ [ina232] = {
+ .config_default = INA226_CONFIG_DEFAULT,
+ .calibration_value = 2048,
+ .shunt_div = 400,
+ .shunt_voltage_shift = 0,
+ .bus_voltage_shift = 0,
+ .bus_voltage_lsb = 1600,
+ .power_lsb_factor = 32,
+ .has_alerts = true,
+ .has_ishunt = false,
+ .has_power_average = false,
+ .current_shift = 0,
+ .has_update_interval = true,
+ },
[ina260] = {
.config_default = INA260_CONFIG_DEFAULT,
.shunt_div = 400,
@@ -1005,6 +1020,7 @@ static const struct i2c_device_id ina2xx_id[] = {
{ "ina226", ina226 },
{ "ina230", ina226 },
{ "ina231", ina226 },
+ { "ina232", ina232 },
{ "ina234", ina234 },
{ "ina260", ina260 },
{ "sy24655", sy24655 },
@@ -1037,6 +1053,10 @@ static const struct of_device_id __maybe_unused ina2xx_of_match[] = {
.compatible = "ti,ina231",
.data = (void *)ina226
},
+ {
+ .compatible = "ti,ina232",
+ .data = (void *)ina232
+ },
{
.compatible = "ti,ina234",
.data = (void *)ina234
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: qcom: monaco-arduino-monza: add ina232 power sensor
From: Loic Poulain @ 2026-06-11 14:05 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-hwmon, devicetree, linux-kernel,
linux-arm-msm, Loic Poulain
In-Reply-To: <20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com>
The Arduino Monza board has a TI INA232 current/power monitor connected
on I2C12 at address 0x40. It is used to measure the board supply current
through a 2 milliohms shunt resistor.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
index 379b796f261f4c8f6b7712c5d340b20be1b9217c..a526c8a07b30c22820f54b54644916b268496209 100644
--- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
@@ -291,6 +291,12 @@ adv7535_out: endpoint {
};
};
};
+
+ power-sensor@40 {
+ compatible = "ti,ina232";
+ reg = <0x40>;
+ shunt-resistor = <2000>;
+ };
};
&mdss {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: qcom: monaco-arduino-monza: add ina232 power sensor
From: sashiko-bot @ 2026-06-11 14:09 UTC (permalink / raw)
To: Loic Poulain; +Cc: devicetree, conor+dt, linux-hwmon, robh
In-Reply-To: <20260611-monza-ina232-v2-3-e4375ce652d0@oss.qualcomm.com>
> The Arduino Monza board has a TI INA232 current/power monitor connected
> on I2C12 at address 0x40. It is used to measure the board supply current
> through a 2 milliohms shunt resistor.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: hwmon: ina2xx: add ina232 compatible
From: sashiko-bot @ 2026-06-11 14:13 UTC (permalink / raw)
To: Loic Poulain; +Cc: robh, conor+dt, linux-hwmon, devicetree
In-Reply-To: <20260611-monza-ina232-v2-1-e4375ce652d0@oss.qualcomm.com>
> From: Martino Facchin <m.facchin@arduino.cc>
>
> The INA232 is a current/power monitor from Texas Instruments sharing
> the same register map as the other INA2xx.
>
> Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-06-11 14:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, bvanassche, beanhuo, peter.wang,
martin.petersen, mani
Cc: linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Zhaoming Luo,
Ram Kumar Dwivedi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <b62e7f1a-bc13-442c-ad7b-0969e3b9073d@kernel.org>
On 6/11/2026 9:32 PM, Krzysztof Kozlowski wrote:
> On 10/06/2026 09:15, Can Guo wrote:
>> UFS v5.0/UFSHCI v5.0 add HS-G6 support via UniPro v3.0 and M-PHY v6.0.
>> These specs define TX Equalization for all High Speed Gears, and HS-G6 may
>> also require TX precode depending on channel characteristics.
>>
>> Document vendor-neutral DT properties in ufs-common.yaml:
>>
>> - patternProperties for txeq-preshoot-g[1-6] and txeq-deemphasis-g[1-6]
>> - tx-precode-g6-host-lanes
>> - tx-precode-g6-device-lanes
>>
>> txeq-preshoot-g[1-6] and txeq-deemphasis-g[1-6] accept per-lane tuples:
>> <Host_Lane0 Device_Lane0>, [<Host_Lane1 Device_Lane1>]
> Instead of repeating the diff, you should explain why these properties
> are needed. Insufficient explanation was also pointed out at v1.
>
> Why this cannot be deduced from the IP compatible? Does it depend on the
> device memory? Who determines the values here and what do they depend
> on? Also here you explain lack of auto tuning for example.
I will give more explanations in next version.
>
>> PreShoot and DeEmphasis values are 0..7 and accept 2 or 4 values for x1/x2
>> lane configurations.
>>
> ...
>
>
>> + Lane indices for static Host-side TX precode enable settings for HS-G6
>> + only. Listed lanes have precode enabled; unlisted lanes are disabled.
>> +
>> + tx-precode-g6-device-lanes:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 1
>> + maxItems: 2
>> + uniqueItems: true
>> + items:
>> + minimum: 0
>> + maximum: 1
>> + description: |
>> + Lane indices for static Device-side TX precode enable settings for HS-G6
>> + only. Listed lanes have precode enabled; unlisted lanes are disabled.
>
> I need to reverse my opinion and let's go to v6 implementation. These
> properties look more consistent in v6 with respect to preshoot and
> deepmhasis properties.
>
> You want actually matrix, so:
>
> tx-precode-enable-g6:
> $ref: /schemas/types.yaml#/definitions/uint32-matrix
> oneOf:
> - items:
> - description: Host_Lane0 precode
> - description: Device_Lane0 precode
> - items:
> - description: Host_Lane0 precode
> - description: Device_Lane0 precode
> - description: Host_Lane1 precode
> - description: Device_Lane1 precode
> items:
> enum: [0, 1]
> description:
> Static TX Precode enable values for HS-G6 only.
>
> And similar style with items also for preshoot and deepmhasis.
Thanks for the suggestions. Will update in next version and come back.
Best Regards,
Can Guo.
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] hwmon: ina2xx: support ina232
From: sashiko-bot @ 2026-06-11 14:19 UTC (permalink / raw)
To: Loic Poulain; +Cc: robh, devicetree, linux-hwmon, conor+dt
In-Reply-To: <20260611-monza-ina232-v2-2-e4375ce652d0@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Power alert limit calculation always evaluates to 0 on 32-bit systems due to `UINT_MAX` underflow when cast to a signed long.
- [High] Setting a high bus voltage alert limit on 32-bit systems causes signed integer overflow for chips with a high `bus_voltage_shift`.
- [High] Arithmetic overflow and truncation in power and current reading calculations due to 32-bit signed integer limits.
--
commit 1860bedc8e47e2aefaa388ad7ade74649ff17da9
Author: Martino Facchin <m.facchin@arduino.cc>
hwmon: ina2xx: support ina232
The INA232 is a current/power monitor. It shares the same register
layout as the INA2xx and uses the INA226 default configuration, but
differs in its electrical characteristics.
> diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
> index 613ffb622b7c4..fc2319ad99fc3 100644
> --- a/drivers/hwmon/ina2xx.c
> +++ b/drivers/hwmon/ina2xx.c
> @@ -196,6 +197,20 @@ static const struct ina2xx_config ina2xx_config[] = {
> .current_shift = 4,
> .has_update_interval = true,
> },
> + [ina232] = {
> + .config_default = INA226_CONFIG_DEFAULT,
> + .calibration_value = 2048,
> + .shunt_div = 400,
> + .shunt_voltage_shift = 0,
> + .bus_voltage_shift = 0,
> + .bus_voltage_lsb = 1600,
> + .power_lsb_factor = 32,
> + .has_alerts = true,
> + .has_ishunt = false,
> + .has_power_average = false,
> + .current_shift = 0,
> + .has_update_interval = true,
> + },
[Severity: High]
This is a pre-existing issue, but does power alert configuration work correctly
on 32-bit systems?
In ina226_alert_to_reg() for INA2XX_POWER, the limit is clamped using:
val = clamp_val(val, 0, UINT_MAX - data->power_lsb_uW);
val = DIV_ROUND_CLOSEST(val, data->power_lsb_uW);
return clamp_val(val, 0, USHRT_MAX);
The clamp_val() macro casts its limit arguments to the type of val, which is
a signed long. On 32-bit systems, UINT_MAX - data->power_lsb_uW evaluates to
a negative value.
Because the maximum limit is negative, clamp_val() forces any positive input
to this negative limit, and the final clamp_val(..., 0, USHRT_MAX) will
unconditionally return 0, silently disabling or instantly triggering alerts.
[Severity: High]
This isn't a bug introduced by this patch, but could setting high bus voltage
alerts on 32-bit systems cause an integer overflow?
In ina226_alert_to_reg() for INA2XX_BUS_VOLTAGE, the value is calculated as:
val = clamp_val(val, 0, 200000);
val = (val * 1000) << data->config->bus_voltage_shift;
For chips with a high bus_voltage_shift like the INA234 (shift = 4), a valid
high input limit such as 150,000 mV evaluates to (150,000 * 1000) << 4,
which equals 2,400,000,000.
On 32-bit architectures, this exceeds the maximum positive value for a
signed long, overflowing into a negative number. The subsequent clamp to
USHRT_MAX then limits this to 0, converting legitimate high voltage limits
to 0.
[Severity: High]
This is a pre-existing issue, but does this calculation overflow for systems
measuring high loads with low-value shunt resistors?
In ina2xx_get_value(), the calculation is stored in a 32-bit signed integer:
static int ina2xx_get_value(struct ina2xx_data *data, u8 reg,
unsigned int regval)
{
int val;
...
case INA2XX_POWER:
val = regval * data->power_lsb_uW;
break;
For a system using a 1 mOhm shunt, power_lsb_uW might be 80,000. If regval
is large (e.g., 65535), the product exceeds INT_MAX.
This overflows on 32-bit systems or truncates when assigned to the 32-bit
integer val on 64-bit systems, causing the driver to report completely
incorrect and often large negative values.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-monza-ina232-v2-0-e4375ce652d0@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Maxwell Doose @ 2026-06-11 14:20 UTC (permalink / raw)
To: Tomasz Duszyński
Cc: Andy Shevchenko, Krzysztof Kozlowski, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CAObtm8zDk4s3+pmGSxRoVHq7ef1y=_cHdC8YRH6ycRNbjzaNkg@mail.gmail.com>
On Thu, Jun 11, 2026 at 8:41 AM Tomasz Duszyński <tduszyns@gmail.com> wrote:
>
> Hi,
>
> I've been trying to catch up on the recent discussion. A few things I
> want to address:
>
> 1. My email is active and I do read patches (when CCd), but by the
> time I have a proper slot to sit down and review something, it's
> usually already gone through several rounds.
> Chiming in at that point just for the sake of it doesn't add much value imo.
>
> 2. I get the impression you're thinking that since I'm not actively
> maintaining these drivers, you can step in and take ownership. I'm
> broadly fine with that, but I'd want to see more work and patches
> coming from you first. If that happens, we can revisit the ownership
> question. That said, do you actually have these sensors on hand to
> test more invasive changes? If you've already answered that just skip
> it as I'll probably stumble upon it whilst going through overdue
> mails.
>
I don't have sps30 or pms7003 but I should be able to get my hands on
them pretty easily. I did get an scd30 though to do more extensive
testing with that.
> 3. I've managed to carve out some extra time lately, so I'm happy to
> be more involved with reviews going forward if that's useful.
>
> In the meantime I'll go through the remaining emails to get better context.
>
Ok then, sorry about prematurely trying this. I'll see about doing
some more patches for sps30 though (I've taken some interest into it).
--
best regards,
max
^ permalink raw reply
* RE: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low, level triggered
From: Selvamani Rajagopal @ 2026-06-11 14:22 UTC (permalink / raw)
To: Parthiban.Veerasooran@microchip.com, andrew@lunn.ch,
conor@kernel.org
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, Piergiorgio Beruto,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Conor.Dooley@microchip.com, devicetree@vger.kernel.org
In-Reply-To: <56e6c9ea-2e2a-406d-b7d0-ec484e3170e6@microchip.com>
> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> level triggered
>
>
> Hi Selvamani,
>
> On 10/06/26 1:32 am, Selvamani Rajagopal wrote:
>
> Thank you for the update. I will test your v4 submission and share the
> feedback as soon as possible.
Parthiban,
I think it is better to wait for v5 to test. v4 failed in AI code review. It raised some important race conditions related
questions. I have some more changes to address those. Will submit v5 soon. You will have it by Monday, if not today.
>
> Best regards,
> Parthiban V
> >
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Frank Li @ 2026-06-11 14:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mathieu Poirier, Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <562096a5-6601-42ae-9d88-90a72ee075fc@kernel.org>
On Thu, Jun 11, 2026 at 03:47:00PM +0200, Krzysztof Kozlowski wrote:
> On 10/06/2026 16:29, Frank Li wrote:
> > For example:
> >
> > rsc_table: rsc-table@90000000
> > { ret = <0x90000000>;
> > no-map;
> > }
> >
> > m4 {
> > ...
> > memory-region = <&rsc_table>;
> > }
> >
> > If you change node name "rsc-table" to "memory", driver will failure
> > because it parse node name "rsc-table", which phandle point to. but no
> > binding to restrict node name to "rsc-table". So rsc-table became hidden
> > ABI.
>
> Then you need to fix the driver to not parse the node names. Node names
> are not supposed to be ABI.
Yes, that is this patch set's purpose. Just need below steps to do smooth
migration.
1. allow memory-region-name as options for binding
2. update driver to parse memory-region-names
3. update all dts to add memory-region-names
4. remove old Node name code and change binding to force memory-region-names
Frank
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH V11 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Chris Morgan @ 2026-06-11 14:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner, jic23,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh
In-Reply-To: <aiplVZRI-0TCDnjL@ashevche-desk.local>
On Thu, Jun 11, 2026 at 10:35:49AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 10, 2026 at 12:54:47PM -0500, Chris Morgan wrote:
>
> > Add the core component of a new inv_icm42607 driver. This includes
> > a few setup functions and the full register definition in the
> > header file.
>
> ...
>
> > 2 files changed, 531 insertions(+)
> > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> I'm not sure this is correct split by files. These files are not:
> - being build
> - being mentioned in MAINTAINERS
I can merge patches v3 and v4. Early on they were pretty big but now
that they've been paired down some I think it may be manageable.
Early on I was told to try and keep each patch around ~750 lines.
I can add these to together and get it to about ~850 lines, but
it will be compileable at that commit rather than waiting on a
second one.
>
> ...
>
> > +#ifndef INV_ICM42607_H_
> > +#define INV_ICM42607_H_
> > +
> > +#include <linux/bits.h>
> > +#include <linux/iio/iio.h>
> > +#include <linux/mutex.h>
>
> mutex_types.h ?
>
I'm not sure I understand this, can you elaborate why I'd need it?
> > +#include <linux/regmap.h>
> > +#include <linux/types.h>
>
> Do you need forward declaration for regulator data type?
>
I think earlier I had regulator-consumer and stripped it out, but I
might have cut a bit too deep so I can add that back.
> ...
>
> > +#define INV_ICM42607_POWER_UP_TIME_US 100000
>
> 100 * USEC_PER_MSEC (will require time.h)?
>
Understood.
> ...
>
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> + bitfields.h
>
Understood.
> > +#include <linux/delay.h>
> > +#include <linux/dev_printk.h>
>
> + device/devres.h
> + err.h
>
Understood.
> > +#include <linux/iio/iio.h>
> > +#include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/time.h>
>
> Also check if you need types.h.
>
I'll add it, I'm honestly not sure. I never got iwyu working it seems.
> ...
>
> > + fsleep(INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC);
> > +
> > + /*
> > + * No polling interval specified in datasheet, so use reset time as
> > + * polling interval and 10x reset time as timeout period.
> > + */
> > + ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> > + val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC),
> > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC * 10));
>
> Besides too many parentheses, this can be switched to regular patter of "num * what".
> Also, TBH, the plain values would be better here
I'll switch to plain numbers and let the comment above do the explaining.
>
> fsleep(1 * USEC_PER_MSEC);
>
> /*
> * No polling interval specified in datasheet, so use reset time as
> * polling interval and 10x reset time as timeout period.
> */
> ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> 1 * USEC_PER_MSEC, 10 * USEC_PER_MSEC);
>
> And in the similar way in other fsleep() / _read_poll_timeout() cases.
>
Plain numbers, gotcha.
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "reset error, reset done bit not set\n");
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH V11 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Chris Morgan @ 2026-06-11 14:32 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260611120943.7119975b@jic23-huawei>
On Thu, Jun 11, 2026 at 12:09:43PM +0100, Jonathan Cameron wrote:
> On Wed, 10 Jun 2026 12:54:47 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
>
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Add the core component of a new inv_icm42607 driver. This includes
> > a few setup functions and the full register definition in the
> > header file.
> >
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> Hi Chris,
>
> A couple more minor things from a fresh read.
>
> Thanks
>
> Jonathan
>
> > ---
> > drivers/iio/imu/inv_icm42607/inv_icm42607.h | 334 ++++++++++++++++++
> > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 197 +++++++++++
> > 2 files changed, 531 insertions(+)
> > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> >
> > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > new file mode 100644
> > index 000000000000..716fc0f1c3fd
> > --- /dev/null
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
>
> > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > new file mode 100644
> > index 000000000000..334264120b42
> > --- /dev/null
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> > +
> > +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> > + inv_icm42607_bus_setup inv_icm42607_bus_setup)
> > +{
> > + const struct device *dev = regmap_get_device(st->map);
> > + unsigned int val;
> > + int ret;
> > +
> > + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> > + if (ret)
> > + return ret;
> > +
> > + /* Warn, but don't fail. */
> > + if (val != st->hw->whoami)
> > + dev_warn(dev, "Unknown whoami %#02x expected %#02x (%s)\n",
> > + val, st->hw->whoami, st->hw->name);
> > +
> > + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> > + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> > + if (ret)
> > + return ret;
> > +
> > + fsleep(INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC);
> > +
> > + /*
> > + * No polling interval specified in datasheet, so use reset time as
> > + * polling interval and 10x reset time as timeout period.
> > + */
> > + ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> > + val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC),
> > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC * 10));
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "reset error, reset done bit not set\n");
> > +
> > + /* Sync the regcache again after a reset. */
> > + regcache_mark_dirty(st->map);
> > + ret = regcache_sync(st->map);
>
> Sashiko raised the point that you don't have a writeable register list for the regmap
> and so potentially we at very least write a bunch of stuff that isn't needed.
> I doubt it's actually a problem or you would have seen it, but nice little optimization
> to reduce what is written.
I will add such a list, I'd put it in patch 4 unless you think I should
merge patch 3 and 4 to make the driver compileable at the first commit
of code (will push the number of lines to the ~850/900 range though).
>
> > + if (ret)
> > + return ret;
> > +
> > + ret = inv_icm42607_bus_setup(st);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_set_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> > + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> > + INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
> > + INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL);
>
> That should have a FIELD_PREP() to save us having to got check that
> the MASK includes the LSB.
Okay.
>
> > + if (ret)
> > + return ret;
> > +
> > + return inv_icm42607_set_conf(st, st->hw->conf);
> > +}
>
> > +
> > +MODULE_AUTHOR("InvenSense, Inc.");
> > +MODULE_DESCRIPTION("InvenSense ICM-42607x device driver");
>
> Why does it have a trailing x? Whilst a wild card is less harmful
> here than in many places I'd still drop it.
I think I missed it from the very beginning. I'll drop.
>
> > +MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("IIO_INV_SENSORS_TIMESTAMP");
>
> Do we need this yet? I think it only gets used later, in which case
> move it to the first patch that needs this.
>
>
No, we don't need it at all anymore. I think I can safely drop this now
that I'm no longer calling that code. Was a vestige from the buffers
code.
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
From: Frank Li @ 2026-06-11 14:33 UTC (permalink / raw)
To: sashiko-reviews
Cc: Stefano Radaelli, Frank.Li, devicetree, robh, conor+dt, imx
In-Reply-To: <20260610091334.3126C1F00893@smtp.kernel.org>
On Wed, Jun 10, 2026 at 09:13:33AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [High] Contradictory GPIO polarity in fixed regulator `reg_eth_phy` between `enable-active-high` and `GPIO_ACTIVE_LOW`.
> - [High] Simultaneous deassertion of power enable and reset in `wifi_pwrseq` violates hardware sequencing requirements.
> - [Medium] The audio card hardcodes carrier-board-specific jacks in the SOM .dtsi, violating the module separation described in the commit message.
> - [Low] The `bluetooth` node is missing the necessary GPIO property assignments (`device-wakeup-gpios`, etc.) required to control the Bluetooth chip, despite the pins being configured in `pinctrl_bt`.
> --
>
> commit 9e70fb8b6cc043ee758ca5e7801e30846eec594b
> Author: Stefano Radaelli <stefano.r@variscite.com>
>
> arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
>
> Add device tree support for the Variscite DART-MX8MM system on module.
> This SOM is designed to be used with various carrier boards.
>
> Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-mini/dart-mx8m-mini/
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
> > @@ -0,0 +1,559 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Common dtsi for Variscite DART-MX8M-MINI
> [ ... ]
> > + reg_eth_phy: regulator-eth-phy {
> > + compatible = "regulator-fixed";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_reg_eth_phy>;
> > + regulator-name = "eth_phy_pwr";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-enable-ramp-delay = <20000>;
> > + gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
> > + enable-active-high;
> > + };
>
> [Severity: High]
> Does the PHY power switch require an active-low or active-high signal?
>
> The reg_eth_phy node uses GPIO_ACTIVE_LOW but also specifies
> enable-active-high. Under the regulator framework, enable-active-high forces
> the GPIO to be treated as active-high, overriding the GPIO_ACTIVE_LOW flag.
This one make sense, please fix it.
Frank
>
> If the power switch requires an active-low signal, it might fail to enable
> the PHY. If it requires an active-high signal, the GPIO_ACTIVE_LOW flag
> seems misleading.
>
> [ ... ]
> > + sound-wm8904 {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,bitclock-master = <&codec_dai>;
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,frame-master = <&codec_dai>;
> > + simple-audio-card,mclk-fs = <256>;
> > + simple-audio-card,name = "wm8904-audio";
> > + simple-audio-card,routing =
> > + "Headphone Jack", "HPOUTL",
> > + "Headphone Jack", "HPOUTR",
> > + "IN2L", "Line In Jack",
> > + "IN2R", "Line In Jack",
> > + "IN1L", "Microphone Jack",
> > + "IN1R", "Microphone Jack";
> > + simple-audio-card,widgets =
> > + "Microphone", "Microphone Jack",
> > + "Headphone", "Headphone Jack",
> > + "Line", "Line In Jack";
>
> [Severity: Medium]
> Should this routing and widget configuration be moved to the carrier board
> device tree instead?
>
> The commit message states that carrier board specific interfaces are left
> disabled to be enabled in respective carrier board device trees. However,
> this sound-wm8904 node hardcodes routing for physical jacks (Headphone, Line
> In, Microphone) which normally reside on the carrier board.
>
> Including this directly in the module's .dtsi forces all carrier boards to
> inherit this exact jack topology.
>
> [ ... ]
> > + wifi_pwrseq: wifi-pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + post-power-on-delay-ms = <100>;
> > + power-off-delay-us = <10000>;
> > + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
> > + <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
> > + };
>
> [Severity: High]
> Does toggling these GPIOs simultaneously violate the hardware sequencing
> requirements for the Wi-Fi chip?
>
> Grouping both WIFI_RESET and WIFI_PWR_EN in the reset-gpios property of
> mmc-pwrseq-simple causes the driver to toggle both lines at the exact same
> moment.
>
> Would it be safer to model the power enable signal as a vmmc-supply with a
> startup-delay-us? This would allow the power rail to fully stabilize before
> the reset line is released.
>
> [ ... ]
> > +/* BT module */
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>, <&pinctrl_bt>;
> > + assigned-clocks = <&clk IMX8MM_CLK_UART4>;
> > + assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
> > + uart-has-rtscts;
> > + status = "okay";
> > +
> > + bluetooth_iw61x: bluetooth {
> > + compatible = "nxp,88w8987-bt";
> > + };
> > +};
>
> [ ... ]
> > +&iomuxc {
> > + pinctrl_bt: btgrp {
> > + fsl,pins = <
> > + MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6 0xc1
> > + MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0xc1
> > + >;
> > + };
>
> [Severity: Low]
> Are we missing driver property assignments for these Bluetooth pins?
>
> The pinctrl_bt group configures GPIO2_IO6 and GPIO5_IO5 with pull-ups
> disabled (0xc1), and assigns them to the uart4 node. However, the
> bluetooth_iw61x node does not assign these pins to any driver properties
> (like device-wakeup-gpios).
>
> Because the driver cannot manage them, does this leave the pins physically
> floating, which could cause spurious wakeups or increased power consumption?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781024557.git.stefano.r@variscite.com?part=2
^ permalink raw reply
* Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper
From: Ahmed Tiba @ 2026-06-11 14:22 UTC (permalink / raw)
To: Jonathan Cameron
Cc: will, xueshuai, saket.dumbre, mchehab, dave, djbw, bp, tony.luck,
guohanjun, lenb, skhan, vishal.l.verma, rafael, corbet, ira.weiny,
dave.jiang, krzk+dt, robh, catalin.marinas, alison.schofield,
conor+dt, linux-arm-kernel, Michael.Zhao2, linux-doc,
linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree, linux-acpi,
linux-edac, acpica-devel
In-Reply-To: <20260529174407.7081ad0b@jic23-huawei>
On 29/05/2026 17:44, Jonathan Cameron wrote:
> On Fri, 29 May 2026 10:50:49 +0100
> Ahmed Tiba<ahmed.tiba@arm.com> wrote:
>> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 54 ++++++++++++++++++++++
>> MAINTAINERS | 5 ++
>> 2 files changed, 59 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>> new file mode 100644
>> index 000000000000..3d4de096093f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>> @@ -0,0 +1,54 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id:http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Arm RAS CPER provider
>> +
>> +maintainers:
>> + - Ahmed Tiba<ahmed.tiba@arm.com>
>> +
>> +description:
>> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
>> + a firmware-first CPER error source directly via DeviceTree. Firmware
>> + provides the CPER Generic Error Status block and notifies the OS through
>> + an interrupt.
> I'd like some spec references in here if possible.
I can add a reference to the UEFI CPER specification for the Generic
Error Status record format.
For the firmware-first DT description itself I do not have a more
specific public reference to cite.
>> +
>> +properties:
>> + compatible:
>> + const: arm,ras-cper
>> +
>> + memory-region:
>> + minItems: 1
>> + items:
>> + - description:
>> + CPER Generic Error Status block exposed by firmware.
>> + - description:
>> + Optional firmware-owned ack buffer used on platforms
>> + where firmware needs an explicit "ack" handshake before overwriting
>> + the CPER buffer. Firmware watches bit 0 and expects the OS to set it
>> + once the current status block has been consumed.
> Does the arm spec really make this optional? Can we constraint it to not be
> just to make our lives easier? I've never been sure how you would actually
> make a working platform without the ack support.
I will update the binding to require both memory-region entries.
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH V11 0/9] Add Invensense ICM42607
From: Chris Morgan @ 2026-06-11 14:36 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260611115938.27712b66@jic23-huawei>
On Thu, Jun 11, 2026 at 11:59:38AM +0100, Jonathan Cameron wrote:
> On Wed, 10 Jun 2026 12:54:44 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
>
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Add support for the ICM42607 IMU. This sensor shares the same
> > functionality but a different register layout with the existing
> > ICM42600.
> >
> > This driver should work with the ICM42607 and ICM42607P over both I2C
> > and SPI, however only the ICM42607P over I2C could be tested.
> Hi Chris,
>
> Just a quick reminder to check if there is useful feedback at:
> https://sashiko.dev/#/patchset/20260610175455.19006-1-macroalpha82%40gmail.com
>
> I didn't look into most of the but the last one about no avail mask bits
> being set for gyro channels was easy to verify as correct and suggests
> a testing gap.
>
> Jonathan
>
Thanks, I've been checking sashiko on every patch and trying to address
what it says to the best of my ability. Honestly I wish there was a way
to simply push to that bot first and *then* push to the mailing list
once I've resolved all of its comments.
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Bryan O'Donoghue @ 2026-06-11 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Nihal Kumar Gupta
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bjorn Andersson,
Konrad Dybcio, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-msm, linux-media, devicetree,
linux-kernel, linux-i2c, imx, linux-arm-kernel, Suresh Vankadara,
Vikram Sharma
In-Reply-To: <20260608-reliable-vivid-stork-f4ea6c@quoll>
On 08/06/2026 21:46, Krzysztof Kozlowski wrote:
> On Mon, Jun 08, 2026 at 07:36:38PM +0530, Nihal Kumar Gupta wrote:
>> Shikra contains the same Camera Subsystem IP as QCM2290. Document the
>> platform-specific compatible string, using qcom,qcm2290-camss as
>> fallback.
>>
>> Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
>> single IOMMU context bank instead of four.
>>
>> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
>> ---
>> .../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 16 +++++++++++++---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
>> index 391d0f6f67ef5fdfea31dd3683477561516b1556..4f39eefb4898ebc22117407f26cfb4f41deb111b 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
>> @@ -14,8 +14,11 @@ description:
>>
>> properties:
>> compatible:
>> - const: qcom,qcm2290-camss
>> -
>
> Do not remove blank lines.
>
>> + oneOf:
>> + - items:
>> + - const: qcom,shikra-camss
>> + - const: qcom,qcm2290-camss
>> + - const: qcom,qcm2290-camss
>> reg:
>
> With this fixed:
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof
>
@Nihal.
If this is the only change you get asked to make, I will just fix this
up on application for you. There's no need to v3 the series for this.
---
bod
^ permalink raw reply
* Re: [PATCH v5 14/20] drm: renesas: rz-du: Add RZ/G3E support
From: Tommaso Merciai @ 2026-06-11 14:48 UTC (permalink / raw)
To: Laurent Pinchart
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260610212234.GA1632628@killaraus.ideasonboard.com>
Hi Laurent,
Thanks for your review.
On Thu, Jun 11, 2026 at 12:22:34AM +0300, Laurent Pinchart wrote:
> Hi Tommaso,
>
> On Wed, Mar 18, 2026 at 03:45:54PM +0100, Tommaso Merciai wrote:
> > On Fri, Feb 13, 2026 at 05:27:40PM +0100, Tommaso Merciai wrote:
> > > The RZ/G3E Soc has 2 LCD controller (LCDC), contain a Frame Compression
> > > Processor (FCPVD), a Video Signal Processor (VSPD), Video Signal
> > > Processor (VSPD), and Display Unit (DU).
> > >
> > > LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> > > LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> > >
> > > Depending on the selected output, the correct SMUX2 clock parent must be
> > > chosen based on the requested duty cycle:
> > >
> > > - Index 0 for LVDS -> CDIV7_DSIx_CLK (DUTY H/L=4/3, 4/7 duty cycle)
> > > - Index 1 for DSI/DPAD -> CSDIV_2to16_PLLDSIx (symmetric 50% duty cycle)
> > >
> > > To support this behavior, introduce the `RZG2L_DU_FEATURE_SMUX2_DSI_CLK`
> > > feature flag and extend the `rzg2l_du_device_info` structure to include a
> > > features field. Also, add a new helper function `rzg2l_du_has()` to check
> > > for feature flags.
> > >
> > > Add support for the RZ/G3E SoC by introducing:
> > > - `rzg2l_du_r9a09g047_du_info` structure
> > > - The `renesas,r9a09g047-du` compatible string
> > >
> > > Additionally, introduce the missing output definitions
> > > `RZG2L_DU_OUTPUT_LVDS{0,1}`.
> > >
> > > Introduce `rzg2l_du_crtc_atomic_check()` helper to store the routes from
> > > the CRTC output to the DU outputs.
> > >
> > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > > ---
> > > v4->v5:
> > > - Fixed RG2L_DU_FEATURE_SMUX2_DSI_CLK to RZG2L_DU_FEATURE_SMUX2_DSI_CLK,
> > > update commit body accordingly.
> > > - Added features field documentation.
> > >
> > > v3->v4:
> > > - No changes.
> > >
> > > v2->v3:
> > > - No changes.
> > >
> > > v1->v2:
> > > - Instead of using clk-provider API to select the right parent clock,
> > > based on the outputs. Just set the correct duty cycle based on the
> > > output, this reflects at CPG lvl to select the right parent.
> > > - Updated commit message accordingly.
> > >
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 48 +++++++++++++++++++
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 26 ++++++++++
> > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 12 +++++
> > > 3 files changed, 86 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > index 6e7aac6219be..cc35dd409e3e 100644
> > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > > @@ -64,11 +64,32 @@
> > > static void rzg2l_du_crtc_set_display_timing(struct rzg2l_du_crtc *rcrtc)
> > > {
> > > const struct drm_display_mode *mode = &rcrtc->crtc.state->adjusted_mode;
> > > + struct rzg2l_du_crtc_state *rstate =
> > > + to_rzg2l_crtc_state(rcrtc->crtc.state);
> > > unsigned long mode_clock = mode->clock * 1000;
> > > u32 ditr0, ditr1, ditr2, ditr3, ditr4, pbcr0;
> > > struct rzg2l_du_device *rcdu = rcrtc->dev;
> > >
> > > clk_prepare_enable(rcrtc->rzg2l_clocks.dclk);
> > > +
> > > + if (rzg2l_du_has(rcdu, RZG2L_DU_FEATURE_SMUX2_DSI_CLK)) {
> > > + struct clk *clk_parent;
> > > +
> > > + clk_parent = clk_get_parent(rcrtc->rzg2l_clocks.dclk);
> > > +
> > > + /*
> > > + * Request appropriate duty cycle to let clock driver select
> > > + * the correct parent:
> > > + * - CDIV7_DSIx_CLK (LVDS path) has DUTY H/L=4/3, 4/7 duty cycle.
> > > + * - CSDIV_2to16_PLLDSIx (DSI/RGB path) has symmetric 50% duty cycle.
> > > + */
> > > + if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS0) ||
> > > + rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS1))
> > > + clk_set_duty_cycle(clk_parent, 4, 7);
> > > + else
> > > + clk_set_duty_cycle(clk_parent, 1, 2);
> > > + }
> > > +
> >
> > I’d appreciate any feedback/suggestions regarding this.
> > Thank you in advance for your time.
>
> Sorry for the very late reply.
No worries, thanks for your time.
>
> I've taken time to analyse the clock tree, and I think the way you model
> it makes sense. As the SMUX2_DSI[01]_CLK clocks are used by the LCD,
> LVDS and DSI blocks, I may have selected the duty cycle in the LVDS and
> DSI drivers personally. I wonder if it would lead to simpler code (you
> wouldn't need to implement rzg2l_du_crtc_atomic_check()) here for
> instance. In any case, it does not affect the DT bindings, so it could
> be changed later too.
Agreed, we can change this later.
>
> Do you need further feedback on this ?
Right now the bottleneck of the series is the DT bindings design [1].
As discussed in our previous conversation, I've provided a clear explanation
of why we are using a single-DU DT design in [1]; let me know if I'm missing
something. Thanks.
[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ff8e401a0667970a42a55420dcb071e34730a923.1778141145.git.tommaso.merciai.xr@bp.renesas.com/
Kind Regards,
Tommaso
>
> > FYI this commit is related to [0]
> >
> > [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/53c8d9e7fde7b176e05503a72af81e74c7a8a1c1.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
> >
> > Kind Regards,
> > Tommaso
> >
> > > clk_set_rate(rcrtc->rzg2l_clocks.dclk, mode_clock);
> > >
> > > ditr0 = (DU_DITR0_DEMD_HIGH
> > > @@ -248,6 +269,32 @@ static void rzg2l_du_crtc_stop(struct rzg2l_du_crtc *rcrtc)
> > > * CRTC Functions
> > > */
> > >
> > > +static int rzg2l_du_crtc_atomic_check(struct drm_crtc *crtc,
> > > + struct drm_atomic_state *state)
> > > +{
> > > + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> > > + crtc);
> > > + struct rzg2l_du_crtc_state *rstate = to_rzg2l_crtc_state(crtc_state);
> > > + struct drm_encoder *encoder;
> > > +
> > > + /* Store the routes from the CRTC output to the DU outputs. */
> > > + rstate->outputs = 0;
> > > +
> > > + drm_for_each_encoder_mask(encoder, crtc->dev,
> > > + crtc_state->encoder_mask) {
> > > + struct rzg2l_du_encoder *renc;
> > > +
> > > + /* Skip the writeback encoder. */
> > > + if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
> > > + continue;
> > > +
> > > + renc = to_rzg2l_encoder(encoder);
> > > + rstate->outputs |= BIT(renc->output);
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static void rzg2l_du_crtc_atomic_enable(struct drm_crtc *crtc,
> > > struct drm_atomic_state *state)
> > > {
> > > @@ -296,6 +343,7 @@ static void rzg2l_du_crtc_atomic_flush(struct drm_crtc *crtc,
> > > }
> > >
> > > static const struct drm_crtc_helper_funcs crtc_helper_funcs = {
> > > + .atomic_check = rzg2l_du_crtc_atomic_check,
> > > .atomic_flush = rzg2l_du_crtc_atomic_flush,
> > > .atomic_enable = rzg2l_du_crtc_atomic_enable,
> > > .atomic_disable = rzg2l_du_crtc_atomic_disable,
> > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > index 0fef33a5a089..3c20471fdbea 100644
> > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > > @@ -51,6 +51,29 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
> > > }
> > > };
> > >
> > > +static const struct rzg2l_du_device_info rzg2l_du_r9a09g047_du_info = {
> > > + .features = RZG2L_DU_FEATURE_SMUX2_DSI_CLK,
> > > + .channels_mask = BIT(0),
> > > + .routes = {
> > > + [RZG2L_DU_OUTPUT_DSI0] = {
> > > + .possible_outputs = BIT(0),
> > > + .port = 0,
> > > + },
> > > + [RZG2L_DU_OUTPUT_LVDS0] = {
> > > + .possible_outputs = BIT(0),
> > > + .port = 1,
> > > + },
> > > + [RZG2L_DU_OUTPUT_LVDS1] = {
> > > + .possible_outputs = BIT(0),
> > > + .port = 2,
> > > + },
> > > + [RZG2L_DU_OUTPUT_DPAD0] = {
> > > + .possible_outputs = BIT(0),
> > > + .port = 3,
> > > + },
> > > + },
> > > +};
> > > +
> > > static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
> > > .channels_mask = BIT(0),
> > > .routes = {
> > > @@ -64,6 +87,7 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
> > > static const struct of_device_id rzg2l_du_of_table[] = {
> > > { .compatible = "renesas,r9a07g043u-du", .data = &rzg2l_du_r9a07g043u_info },
> > > { .compatible = "renesas,r9a07g044-du", .data = &rzg2l_du_r9a07g044_info },
> > > + { .compatible = "renesas,r9a09g047-du", .data = &rzg2l_du_r9a09g047_du_info },
> > > { .compatible = "renesas,r9a09g057-du", .data = &rzg2l_du_r9a09g057_info },
> > > { /* sentinel */ }
> > > };
> > > @@ -74,6 +98,8 @@ const char *rzg2l_du_output_name(enum rzg2l_du_output output)
> > > {
> > > static const char * const names[] = {
> > > [RZG2L_DU_OUTPUT_DSI0] = "DSI0",
> > > + [RZG2L_DU_OUTPUT_LVDS0] = "LVDS0",
> > > + [RZG2L_DU_OUTPUT_LVDS1] = "LVDS1",
> > > [RZG2L_DU_OUTPUT_DPAD0] = "DPAD0"
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > index 58806c2a8f2b..480a7bdfcd66 100644
> > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > @@ -20,8 +20,12 @@
> > > struct device;
> > > struct drm_property;
> > >
> > > +#define RZG2L_DU_FEATURE_SMUX2_DSI_CLK BIT(0) /* Per output mux */
> > > +
> > > enum rzg2l_du_output {
> > > RZG2L_DU_OUTPUT_DSI0,
> > > + RZG2L_DU_OUTPUT_LVDS0,
> > > + RZG2L_DU_OUTPUT_LVDS1,
> > > RZG2L_DU_OUTPUT_DPAD0,
> > > RZG2L_DU_OUTPUT_MAX,
> > > };
> > > @@ -42,10 +46,12 @@ struct rzg2l_du_output_routing {
> > >
> > > /*
> > > * struct rzg2l_du_device_info - DU model-specific information
> > > + * @features: device features (RZG2L_DU_FEATURE_*)
> > > * @channels_mask: bit mask of available DU channels
> > > * @routes: array of CRTC to output routes, indexed by output (RZG2L_DU_OUTPUT_*)
> > > */
> > > struct rzg2l_du_device_info {
> > > + unsigned int features;
> > > unsigned int channels_mask;
> > > struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
> > > };
> > > @@ -73,6 +79,12 @@ static inline struct rzg2l_du_device *to_rzg2l_du_device(struct drm_device *dev)
> > > return container_of(dev, struct rzg2l_du_device, ddev);
> > > }
> > >
> > > +static inline bool rzg2l_du_has(struct rzg2l_du_device *rcdu,
> > > + unsigned int feature)
> > > +{
> > > + return rcdu->info->features & feature;
> > > +}
> > > +
> > > const char *rzg2l_du_output_name(enum rzg2l_du_output output);
> > >
> > > #endif /* __RZG2L_DU_DRV_H__ */
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: pressure: Add MS5637
From: Louis Adamian @ 2026-06-11 14:48 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260610-broadness-unraveled-b5187dcb2fb8@spud>
On Wed, 10 Jun 2026 17:45:52 +0100
Conor Dooley <conor@kernel.org> wrote:
> I think this should be made clear by use of fallbacks, or being marked
> deprecated with a comment.
I will mark the generic compatibles as deprecated with a comment noting
that they previously all received the ms5637-02ba compensation
(following solomon,ssd1307fb.yaml).
Thanks,
Louis
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Frank Li @ 2026-06-11 14:53 UTC (permalink / raw)
To: Philipp Zabel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260611-imx8mp-frdm-hdmi-ddc-v1-1-b4e4c9bb0729@pengutronix.de>
On Thu, Jun 11, 2026 at 10:18:59AM +0200, Philipp Zabel wrote:
> Configure HDMI DDC SCL/SDA pins to support reading EDID.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
Fix tags here?
Frank
> arch/arm64/boot/dts/freescale/imx8mp-frdm.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
> index 5fb9714215bf..f43330d1ff8b 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
> @@ -562,6 +562,8 @@ MX8MP_IOMUXC_SAI1_RXD0__GPIO4_IO02 0x10
>
> pinctrl_hdmi: hdmigrp {
> fsl,pins = <
> + MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
> + MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c2
> MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x10
> >;
> };
>
> ---
> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> change-id: 20260609-imx8mp-frdm-hdmi-ddc-715a3cd5a9ff
>
> Best regards,
> --
> Philipp Zabel <p.zabel@pengutronix.de>
>
>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/3] Reserve eDMA channels 0-1 for V2X
From: Frank Li @ 2026-06-11 15:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
Ye Li, Joy Zou
Cc: Frank Li, devicetree, imx, linux-arm-kernel, linux-kernel,
Laurentiu Mihalcea
In-Reply-To: <178111844864.1088466.7414551932762014103.b4-ty@b4>
On Wed, Jun 10, 2026 at 03:08:29PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
>
> On Wed, 11 Feb 2026 17:28:23 +0800, Joy Zou wrote:
>
>
> Applied, thanks!
>
> [1/3] dt-bindings: dma: fsl-edma: add dma-channel-mask property description
> commit: edc448e785891cca747e21c6595e050d3d3fa434
>
> Vnod have not picked it for the long time. I picked it to make reflect the
> correct settings for i.mx
I saw vnod pick it, drop it from my side.
Frank
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v3 3/3] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi
From: Vinod Koul @ 2026-06-11 15:29 UTC (permalink / raw)
To: palash.kambar
Cc: neil.armstrong, robh, krzk+dt, conor+dt, mani, alim.akhtar,
bvanassche, andersson, dmitry.baryshkov, abel.vesa, luca.weiss,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat
In-Reply-To: <20260526090956.2340262-4-palash.kambar@oss.qualcomm.com>
On 26-05-26, 14:39, palash.kambar@oss.qualcomm.com wrote:
> From: Palash Kambar <palash.kambar@oss.qualcomm.com>
>
> Add the init sequence tables and config for the UFS QMP phy found in
> the Hawi SoC.
This fails to build for me on phy/next
In file included from drivers/phy/qualcomm/phy-qcom-qmp-ufs.c:24:
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c:1878:26: error: ‘QSERDES_V8_COM_PLL_IVCO_MODE1’ undeclared here (not in a function); did you mean ‘QSERDES_V6_COM_PLL_IVCO_MODE1’?
1878 | QMP_PHY_INIT_CFG(QSERDES_V8_COM_PLL_IVCO_MODE1, 0x1f),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/qualcomm/phy-qcom-qmp-common.h:22:27: note: in definition of macro ‘QMP_PHY_INIT_CFG’
22 | .offset = o, \
| ^
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c:1879:26: error: ‘QSERDES_V8_COM_CMN_IETRIM’ undeclared here (not in a function); did you mean ‘QSERDES_V6_COM_CMN_IETRIM’?
1879 | QMP_PHY_INIT_CFG(QSERDES_V8_COM_CMN_IETRIM, 0x07),
| ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/qualcomm/phy-qcom-qmp-common.h:22:27: note: in definition of macro ‘QMP_PHY_INIT_CFG’
22 | .offset = o, \
And so on. Looks like QSERDES_V8_COM_PLL_IVCO_MODE1 etc are not define.
Please rebase test and send again
--
~Vinod
^ permalink raw reply
* Copy of: I promised.
From: JCDT | Notification @ 2026-06-11 15:26 UTC (permalink / raw)
To: devicetree@vger.kernel.org
This is a copy of the following message you sent to Info via Jamaica Conservation and Development Trust
Photos for my escort application are uploaded.
Let me know if the quality is good.
Preview: https://tinyurl.com/5adbz2mn#aUz4yw
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski, YijieYang, Konrad Dybcio
In-Reply-To: <20260610-topic-purwa_phy_shutup_warning-v2-1-951c1fbfe9b2@oss.qualcomm.com>
On Wed, 10 Jun 2026 11:45:12 +0200, Konrad Dybcio wrote:
> Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation.
> The PHY is however physically laid out as if it were to, since there
> are two separate ports (A/B).
>
> Split out a new if-then block to un-require the bifurcation register
> handle to squash this warning:
>
> [...]
Applied, thanks!
[1/1] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
commit: b3ee497970c63cea37976aeaa84bac39611fe0eb
Best regards,
--
~Vinod
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] PCI: qcom: Add support for Eliza
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
Krishna Chaitanya Chundru
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com>
On Mon, 08 Jun 2026 14:18:12 +0530, Krishna Chaitanya Chundru wrote:
> This series adds PCIe support for the Qualcomm Eliza SoC. Eliza includes
> two PCIe root complex controllers capable of 8GT/s x1 and 8GT/s x2.
>
> The QMP PCIe PHY support adds a new Gen3x1 PHY configuration with
> Eliza-specific initialization tables, and reuses the existing SM8550
> Gen3x2 configuration for the x2 PHY instance.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: phy: sc8280xp-qmp-pcie: Document Eliza PCIe phy
commit: afdf104ec11681aacba0865863647f725f47ab90
[3/3] phy: qcom: qmp-pcie: Add QMP PCIe PHY support for Eliza
commit: fdd2913a4e505716dce5c9f89c268628d9a019d5
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 0/2] Add ipq5210 USB phy support
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: neil.armstrong, robh, krzk+dt, conor+dt, quic_wcheng,
linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan
In-Reply-To: <20260608103344.2740174-1-varadarajan.narayanan@oss.qualcomm.com>
On Mon, 08 Jun 2026 16:03:42 +0530, Varadarajan Narayanan wrote:
> The ipq5210 SoC has both USB2.0 and USB3.0 controllers. The USB3.0
> can connect to either of USB2.0 or USB3.0 phy and operate in the
> respective mode.
>
> v2: Use ipq6018 and ipq9574 as fallback compatibles for qusb2 and qmp
> phys respectively instead of introducing ipq5210 as a new compatible.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: phy: qcom,qusb2: Document IPQ5210 compatible
commit: a9a9bae2174bbad63fc73a0d445b7437f63b2498
[2/2] dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
commit: 609878c1b684ea3f77ab72237511eb9bec927102
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v6 0/2] phy: add basic support for NXPs TJA1145 CAN transceiver
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Dimitri Fedrau, Dimitri Fedrau
Cc: linux-phy, devicetree, linux-kernel, Conor Dooley, lee.lockhey,
Marc Kleine-Budde
In-Reply-To: <20260602-tja1145-support-v6-0-0e0ffc8ee63d@liebherr.com>
On Tue, 02 Jun 2026 10:25:36 +0200, Dimitri Fedrau wrote:
> Add basic driver support for NXPs TJA1145 CAN transceiver which brings the
> PHY up/down by switching to normal/standby mode using SPI commands.
>
>
Applied, thanks!
[1/2] dt-bindings: phy: add support for NXPs TJA1145 CAN transceiver
commit: baacd0af457c2505137c4774e71efe044c11b26d
[2/2] phy: add basic support for NXPs TJA1145 CAN transceiver
commit: e5a9c1c917b59a4aff066b9f317501834c6d5af2
Best regards,
--
~Vinod
^ 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