* Re: [PATCH 2/5] dmaengine: sun6i-dma: Add set_addr function pointer for variable address widths
From: Frank Li @ 2026-06-19 16:02 UTC (permalink / raw)
To: Yuanshen Cao
Cc: Vinod Koul, Frank Li, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, dmaengine, linux-arm-kernel, linux-sunxi,
linux-kernel, devicetree
In-Reply-To: <20260619-sun60i-a733-dma-v1-2-da4b649fc72a@gmail.com>
On Fri, Jun 19, 2026 at 04:53:31AM +0000, Yuanshen Cao wrote:
>
> The A733 DMA controller supports higher address (up to 32G) compared to
> previous generations. The existing `sun6i_dma_set_addr` function uses a
> hardcoded logic for setting the high-address bits in the LLI parameters.
>
> By moving `set_addr` into the `sun6i_dma_config` structure, we can
> provide specialized implementations for different hardware. This allows
> the A733 to use a version of `set_addr` that correctly handles its
> specific `SRC_HIGH_ADDR_32G` and `DST_HIGH_ADDR_32G` in the `set_addr`
> register later in the series.
>
> Changes:
> - Added `set_addr` function pointer to `struct sun6i_dma_config`.
> - Refactored `sun6i_dma_set_addr` and introduced
> `sun6i_dma_set_addr_a100` (keeping the logic for high address
> support).
> - Updated all existing configuration structs to include the new
> `set_addr` pointer.
> - Removed `has_high_addr` since the logic is replaced by
> `sun6i_dma_set_addr_a100`.
>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 36 ++++++++++++++++++++++++++----------
> 1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index d92e702320d9..059455425e19 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -112,6 +112,7 @@
>
> /* forward declaration */
> struct sun6i_dma_dev;
> +struct sun6i_dma_lli;
>
> /*
> * Hardware channels / ports representation
> @@ -138,6 +139,8 @@ struct sun6i_dma_config {
> void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
> void (*set_drq)(u32 *p_cfg, s8 src_drq, s8 dst_drq);
> void (*set_mode)(u32 *p_cfg, s8 src_mode, s8 dst_mode);
> + void (*set_addr)(struct sun6i_dma_dev *sdev, struct sun6i_dma_lli *v_lli,
> + dma_addr_t src, dma_addr_t dst);
> void (*dump_com_regs)(struct sun6i_dma_dev *sdev);
> u32 (*read_irq_en)(struct sun6i_dma_dev *sdev, u32 chan_num);
> void (*write_irq_en)(struct sun6i_dma_dev *sdev, u32 chan_num, u32 irq_val);
> @@ -147,7 +150,6 @@ struct sun6i_dma_config {
> u32 dst_burst_lengths;
> u32 src_addr_widths;
> u32 dst_addr_widths;
> - bool has_high_addr;
> bool has_mbus_clk;
> };
>
> @@ -675,13 +677,20 @@ static int set_config(struct sun6i_dma_dev *sdev,
> static inline void sun6i_dma_set_addr(struct sun6i_dma_dev *sdev,
> struct sun6i_dma_lli *v_lli,
> dma_addr_t src, dma_addr_t dst)
> +{
> + v_lli->src = lower_32_bits(src);
> + v_lli->dst = lower_32_bits(dst);
> +}
> +
> +static inline void sun6i_dma_set_addr_a100(struct sun6i_dma_dev *sdev,
> + struct sun6i_dma_lli *v_lli,
> + dma_addr_t src, dma_addr_t dst)
> {
> v_lli->src = lower_32_bits(src);
> v_lli->dst = lower_32_bits(dst);
>
> - if (sdev->cfg->has_high_addr)
> - v_lli->para |= SRC_HIGH_ADDR(upper_32_bits(src)) |
> - DST_HIGH_ADDR(upper_32_bits(dst));
> + v_lli->para |= SRC_HIGH_ADDR(upper_32_bits(src)) |
> + DST_HIGH_ADDR(upper_32_bits(dst));
> }
>
> static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_memcpy(
> @@ -714,7 +723,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_memcpy(
>
> v_lli->len = len;
> v_lli->para = NORMAL_WAIT;
> - sun6i_dma_set_addr(sdev, v_lli, src, dest);
> + sdev->cfg->set_addr(sdev, v_lli, src, dest);
can you move sdev->cfg->set_addr into helper function sun6i_dma_set_addr())
so need't change other place.
Old sun6i_dma_set_addr() rename sun6i_dma_set_addr_<name>()
sun6i_dma_set_addr()
{
sdev->cfg->set_addr(sdev, v_lli, src, dest)
}
Frank
^ permalink raw reply
* RE: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Selvamani Rajagopal @ 2026-06-19 16:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Parthiban Veerasooran, Richard Cochran, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <ajVKfBKPuNk9zN7b@monoceros>
Thanks for your feedback. Will take care of all the three comments.
> -----Original Message-----
> Subject: Re: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500
> MAC-PHY
>
> On Sun, Jun 14, 2026 at 10:00:28AM -0700, Selvamani Rajagopal via B4 Relay wrote:
> > +static const struct of_device_id s2500_of_match[] = {
> > + { .compatible = "onnn,s2500" },
> > + {}
>
> s/{}/{ }/
>
> > +};
> > +
> > +static const struct spi_device_id s2500_ids[] = {
> > + { "s2500" },
> > + {}
> > +};
>
> Please make this:
>
> static const struct spi_device_id s2500_ids[] = {
> { .name = "s2500" },
> { }
> };
>
> > +MODULE_DEVICE_TABLE(spi, s2500_ids);
> > +
> > +static struct spi_driver s2500_driver = {
> > + .driver = {
> > + .name = DRV_NAME,
> > + .of_match_table = s2500_of_match,
> > + },
> > + .probe = s2500_probe,
> > + .remove = s2500_remove,
> > + .id_table = s2500_ids,
>
> Tastes are different, but the idea to align = is usually screwed by
> follow up patches. Here it's broken from the start. If you ask me: Use a
> single space before each =.
>
> > +};
> > +
> > +module_spi_driver(s2500_driver);
>
> Usually there is no empty line between the driver struct and the macro
> registering it.
>
>>
> Best regards
> Uwe
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: sm8250-xiaomi-elish: add ov8856 front camera
From: Xin Xu @ 2026-06-19 16:07 UTC (permalink / raw)
To: andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <20260619160738.107502-1-xxsemail@qq.com>
Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
powered by pm8008 LDOs and other supplies.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 2687a2a8dda4..6d2cbb0b9fa6 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/usb/pd.h>
@@ -531,6 +532,61 @@ vreg_l7f_1p8: ldo7 {
};
};
+&camss {
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+
+ status = "okay";
+
+ ports {
+ port@4 {
+ csiphy4_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&ov8856_front_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera_front: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ avdd-supply = <&vreg_l5p>;
+ dovdd-supply = <&vreg_l1c_1p8>;
+ dvdd-supply = <&vreg_l1p>;
+
+ clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ clock-names = "xvclk";
+ assigned-clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+
+ orientation = <0>; /* Front facing */
+ rotation = <270>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&mclk3_active &camera_front_active>;
+
+ port {
+ ov8856_front_ep: endpoint {
+ link-frequencies = /bits/ 64
+ <720000000 360000000>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
&cdsp {
firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
status = "okay";
@@ -877,6 +933,20 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ camera_front_active: camera-front-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ mclk3_active: mclk3-active-state {
+ pins = "gpio97";
+ function = "cam_mclk";
+ bias-disable;
+ drive-strength = <4>;
+ };
+
pm8008_default: pm8008-default-state {
int-pins {
pins = "gpio84";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/11] ARM: NXP: Drop NOMMU platform support
From: Vladimir Zapolskiy @ 2026-06-19 16:07 UTC (permalink / raw)
To: Frank.Li, Arnd Bergmann, Sascha Hauer, Pengutronix Kernel Team,
Stefan Agner, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Russell King, Abel Vesa, Peng Fan,
Michael Turquette, Stephen Boyd, Brian Masney, Dong Aisheng,
Jacky Bai, NXP S32 Linux Team, Linus Walleij, Piotr Wojtaszczyk,
Kees Cook, Gustavo A. R. Silva
Cc: linux-arm-kernel, imx, devicetree, linux-kernel, linux-clk,
linux-gpio, linux-hardening, Frank Li
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com>
Hello Frank.
On 6/19/26 18:40, Frank.Li@oss.nxp.com wrote:
> Commercial users and hardware vendors migrated to Zephyr or other RTOS
> solutions years ago, leaving the NOMMU platform support effectively
> unused and unmaintained.
>
> Remove the obsolete support to reduce maintenance burden and simplify the
> Freescale/nxp platform code.
>
> Some driver code still be kept and may clean up later since it is possible
> reused by other SoC.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
This change is a bit too early to happen, I prefer to get it orchestrated
by Arnd. So, as for today I NAK the change for its NXP LPC part.
> ---
> Frank Li (11):
> ARM: dts: vf610m4: Remove NOMMU platform support
> ARM: dts: imxrt1050: Remove NOMMU platform support
> ARM: imx: Remove NOMMU platform support
> clk: imx: imxrt1050: Remove NOMMU platform support
> pinctrl: freescale: IMXRT: Remove NOMMU platform support
> ARM: imxrt_defconfig: Remove NOMMU platform support
> ARM: dts: lpc: Remove NOMMU platform support
> ARM: mach-lpc: Remove NOMMU platform support
> ARM: configs: lpc*: Remove NOMMU platform support
> clk: nxp: lpc: Remove NOMMU platform support
> pinctrl: nxp: lpc: Remove NOMMU platform support
>
> .../devicetree/bindings/pinctrl/fsl,imxrt1050.yaml | 79 -
> .../devicetree/bindings/pinctrl/fsl,imxrt1170.yaml | 77 -
> arch/arm/Kconfig | 12 -
> arch/arm/Makefile | 2 -
> arch/arm/boot/dts/nxp/Makefile | 1 -
> arch/arm/boot/dts/nxp/imx/Makefile | 2 -
> arch/arm/boot/dts/nxp/imx/imxrt1050-evk.dts | 72 -
> arch/arm/boot/dts/nxp/imx/imxrt1050-pinfunc.h | 993 ------------
> arch/arm/boot/dts/nxp/imx/imxrt1050.dtsi | 160 --
> arch/arm/boot/dts/nxp/imx/imxrt1170-pinfunc.h | 1561 -------------------
> arch/arm/boot/dts/nxp/lpc/Makefile | 9 -
> arch/arm/boot/dts/nxp/lpc/lpc18xx.dtsi | 543 -------
> arch/arm/boot/dts/nxp/lpc/lpc3250-ea3250.dts | 273 ----
> arch/arm/boot/dts/nxp/lpc/lpc3250-phy3250.dts | 236 ---
> arch/arm/boot/dts/nxp/lpc/lpc32xx.dtsi | 540 -------
NXP LPC32xx is ARMv5 and it has MMU, hence it's plainly out of scope of
the proposed "dropping NOMMU platform support".
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-19 16:07 UTC (permalink / raw)
To: andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
Add the pm8008 PMIC node on i2c15 with seven LDOs,
using GPIO84 as interrupt and GPIO76 as reset.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 94 +++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 51b57c697a75..2687a2a8dda4 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -599,6 +599,82 @@ fuel-gauge@55 {
};
};
+&i2c15 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ pm8008: pmic@8 {
+ compatible = "qcom,pm8008";
+ reg = <0x8>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <84 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;
+
+ vdd-l1-l2-supply = <&vreg_s8c_1p35>;
+ vdd-l3-l4-supply = <&vreg_bob>;
+ vdd-l5-supply = <&vreg_bob>;
+ vdd-l6-supply = <&vreg_bob>;
+ vdd-l7-supply = <&vreg_bob>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pm8008_default>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8008 0 0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ regulators {
+ vreg_l1p: ldo1 {
+ regulator-name = "vreg_l1p";
+ regulator-min-microvolt = <1152000>;
+ regulator-max-microvolt = <1152000>;
+ };
+
+ vreg_l2p: ldo2 {
+ regulator-name = "vreg_l2p";
+ regulator-min-microvolt = <1152000>;
+ regulator-max-microvolt = <1152000>;
+ };
+
+ vreg_l3p: ldo3 {
+ regulator-name = "vreg_l3p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l4p: ldo4 {
+ regulator-name = "vreg_l4p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l5p: ldo5 {
+ regulator-name = "vreg_l5p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l6p: ldo6 {
+ regulator-name = "vreg_l6p";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vreg_l7p: ldo7 {
+ regulator-name = "vreg_l7p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2900000>;
+ };
+ };
+ };
+};
+
&mdss {
status = "okay";
};
@@ -801,6 +877,24 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ pm8008_default: pm8008-default-state {
+ int-pins {
+ pins = "gpio84";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ input-enable;
+ };
+
+ reset-pins {
+ pins = "gpio76";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <2>;
+ output-high;
+ };
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v6 00/10] ACPI: APEI: share GHES CPER helpers and add DT FFH provider
From: Borislav Petkov @ 2026-06-19 16:16 UTC (permalink / raw)
To: Ahmed Tiba
Cc: Rafael J. Wysocki, Tony Luck, Hanjun Guo, Mauro Carvalho Chehab,
Shuai Xue, Len Brown, Saket Dumbre, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-kernel,
linux-acpi, acpica-devel, linux-cxl, devicetree, linux-edac,
linux-doc, Dmitry.Lamerov
In-Reply-To: <eccbf574-a145-47af-889b-ca6dd80f98f2@arm.com>
On Fri, Jun 19, 2026 at 04:41:40PM +0100, Ahmed Tiba wrote:
> I will address the issues introduced by this series. Pre-existing
> behaviour is carried forward unchanged.
So you carve out that code, you use it for your use case while *knowing* there
are preexisting bugs. Wonderful.
Sorry, first bug fixes then features.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v3 12/12] iio: dac: ad5686: add gain control support
From: Rodrigo Alencar @ 2026-06-19 16:17 UTC (permalink / raw)
To: Andy Shevchenko, rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <ajEppnu-AWSbbihS@ashevche-desk.local>
On 16/06/26 13:47, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 09:21:18AM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> > Most of the supported devices rely on a GAIN pin to control a 2x
> > multiplier applied to the output voltage. Other devices, e.g. the
> > single-channel ones, provides a gain control through a bit field in
> > the control register. Some designs might have the GAIN pin hardwired
> > to VDD/VLOGIC or GND, which would have no "gain-gpios" device property,
> > being able to set "adi,range-double" if it is hardwired to VDD. The
> > vref_mv field is moved down in the struct ad5686_state, so that the
> > overall size increase is reduced.
>
> ...
>
> > +static void ad5686_init_scale_avail(struct ad5686_state *st)
> > +{
> > + int realbits = st->chip_info->channels[0].scan_type.realbits;
> > + s64 tmp = 2ULL * st->vref_mv * NANO >> realbits;
>
> As Nuno noticed in other patch review, this can probably use mul_u64_u32_shr().
This would be need in case the multiplication overflows, which is not the case
here.
> > + st->scale_avail[2] = div_s64_rem(tmp, NANO, &st->scale_avail[3]);
> > + st->scale_avail[0] = div_s64_rem(tmp >> 1, NANO, &st->scale_avail[1]);
> > +}
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH RFC 1/3] dt-bindings: iio: adc: Add reference-source property
From: Kurt Borja @ 2026-06-19 16:30 UTC (permalink / raw)
To: Conor Dooley, Kurt Borja
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260619-proton-distract-de92d6b9b600@spud>
Hi Conor,
On Fri Jun 19, 2026 at 9:14 AM -05, Conor Dooley wrote:
> On Thu, Jun 18, 2026 at 07:33:01PM -0500, Kurt Borja wrote:
>> Some ADCs have configurable voltage reference sources for each channel.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index b9bc02b5b07a4c..c74c2084fdb68c 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -73,6 +73,16 @@ properties:
>> device design and can interact with other characteristics such as
>> settling time.
>>
>> + reference-source:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + maxItems: 2
>> + minItems: 1
>> + description:
>> + Indicates the voltage reference source or sources for this channel.
>> +
>> + This array describes either a single reference source or a positive and
>> + negative reference sources.
>
> I have no idea from this description what this actually refers to. Is it
> a pin? A supply? A channel?
It can be pins but also can be internal vref sources. Not always a
supply though, in some applications a resistor is connected to the
reference source pins.
If there is a next version I'll clarify it.
>
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
>> --
>> 2.54.0
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-19 16:35 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <7b93cd3a-8aae-494a-a0fa-540bafcbccaf@baylibre.com>
On Fri Jun 19, 2026 at 9:23 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Hi all,
>>
>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>> I was made aware by David [2] that at least two more chip families,
>> ads1220 [3] and ads1x2c14, share very similar features (though these
>> chips are not really compatible between them). After that, I found one
>> more chip with the same features which is already upstream, the
>> AD4170-4.
>>
>> As David explained in [2], these chips are intended to be used with
>> RTDs, thermocouples or other resistive sensors so they share the
>> following per-channel features:
>>
>> - Configurable reference selection
>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>> - Excitation current sources (usually called IDACs TI) for sensor
>> current biasing
>>
>> Given that these three features are present in all four devices and
>> three of these drivers are still under review, my proposal is to have
>> these features be described in adc.yaml and have this series merged
>> before the three others [1] [2] [3].
>>
>> This series is sent as RFC because I still don't have much experience
>> with dt-bindings and I don't know if this approach or the properties are
>> general enough to be described like this.
>
> Generally, we don't propose bindings without users in the same series.
> I was going to wait to see what feedback Jonathan gave on my series
> before proposing this.
Makes sense. In this case I think it would be useful for the three
series to have this first, but not up to me.
>
>>
>> No dependencies between properties were provided because not all devices
>> may be able to configure each one of them.
>>
>> [1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
>> [2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
>> [3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Kurt Borja (3):
>> dt-bindings: iio: adc: Add reference-source property
>> dt-bindings: iio: adc: Add excitation current sources properties
>> dt-bindings: iio: adc: Add burn-out current properties
>>
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 47 ++++++++++++++++++++++
>> 1 file changed, 47 insertions(+)
>> ---
>> base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
>> change-id: 20260618-new-channel-props-4fbd52020da2
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 1/3] dt-bindings: iio: adc: Add reference-source property
From: Kurt Borja @ 2026-06-19 16:42 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <736962f9-50b9-4884-88b1-94bfd7cd8abf@baylibre.com>
On Fri Jun 19, 2026 at 9:24 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Some ADCs have configurable voltage reference sources for each channel.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index b9bc02b5b07a4c..c74c2084fdb68c 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -73,6 +73,16 @@ properties:
>> device design and can interact with other characteristics such as
>> settling time.
>>
>> + reference-source:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + maxItems: 2
>> + minItems: 1
>> + description:
>> + Indicates the voltage reference source or sources for this channel.
>> +
>> + This array describes either a single reference source or a positive and
>> + negative reference sources.
>
> Do you actually know of any devices that allow independently selecting
> the positive and negative sources? I don't think I've ever seen anything
> like that.
The ADS1262 allows it, check the REFMUX register. Only ADC1 allows it
though, ADC2 has a single reference select.
Maybe I can get away with only one for both ADCs without restricting too
much.
> Also, this should be string, not uint32.
Sure!
>
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 2/3] dt-bindings: iio: adc: Add excitation current sources properties
From: Kurt Borja @ 2026-06-19 16:44 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <073b0a89-65af-4a21-837d-851d35e3e294@baylibre.com>
On Fri Jun 19, 2026 at 9:27 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Some ADCs incorporate current sources that provide excitation current to
>> resistive temperature devices (RTDs), thermistors diodes and other
>> resistive sensors that require constant current biasing.
>>
>> The maxItems constraint of 16 is arbitrary but should be big enough for
>> most devices.
>
> I wouldn't put an arbitrary limit here. The bindings that include it
> can extend it to add a limit that makes sense instead.
I agree.
This was partly a misunderstanding. I thought -microamp properties fall
back to uint32 not uint32-array but it's the other way around right?
>
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index c74c2084fdb68c..106b1e317411d5 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -83,6 +83,29 @@ properties:
>> This array describes either a single reference source or a positive and
>> negative reference sources.
>>
>> + excitation-channels:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + maxItems: 16
>> + minItems: 1
>> + description:
>> + Excitation current sources provide current to resistive temperature
>> + devices (RTDs), thermistors diodes and other resistive sensors that
>> + require constant current biasing.
>> +
>> + This array describes the mux configuration of the excitation current
>> + sources.
>> +
>> + excitation-current-microamp:
>> + maxItems: 16
>> + minItems: 1
>> + description:
>> + Excitation current sources provide current to resistive temperature
>> + devices (RTDs), thermistors diodes and other resistive sensors that
>> + require constant current biasing.
>> +
>> + This array describes the current configuration of the excitation current
>> + sources or the single matched current for all sources.
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC 3/3] dt-bindings: iio: adc: Add burn-out current properties
From: Kurt Borja @ 2026-06-19 16:46 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <0831356f-76ff-4eed-befa-7a35ffce921d@baylibre.com>
On Fri Jun 19, 2026 at 9:28 AM -05, David Lechner wrote:
> On 6/18/26 7:33 PM, Kurt Borja wrote:
>> Some ADCs incorporate burn-out current sources that provide current to
>> the channel's input pins for open-circuit or short-circuit detection.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>> Documentation/devicetree/bindings/iio/adc/adc.yaml | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index 106b1e317411d5..6b63aac9ac04dd 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -106,6 +106,20 @@ properties:
>> This array describes the current configuration of the excitation current
>> sources or the single matched current for all sources.
>>
>> + burn-out-current-microamp:
>> + description:
>> + Burn-out current sources provide current to the channel's input pins for
>> + open-circuit or short-circuit detection.
>> +
>> + burn-out-current-polarity:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + Burn-out current sources provide current to the channel's input pins for
>> + open-circuit or short-circuit detection.
>> + enum:
>> + - pull-up
>> + - pull-down
>> +
>> anyOf:
>> - oneOf:
>> - required:
>>
>
> This doesn't really work with chips that just have and enable bit to
> enable or disable the feature.
Maybe those devices can use burn-out-current-microamp with a const
value? Is that okay or should another approach be taken?
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Eric Biggers @ 2026-06-19 16:45 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Andy Gross, Harshal Dev, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <53b1fa61-9692-42fd-a295-98bbeacbcd9a@oss.qualcomm.com>
On Fri, Jun 19, 2026 at 02:13:28PM +0530, Kuldeep Singh wrote:
> On 21-05-2026 18:47, Kuldeep Singh wrote:
> > This patchseries attempt to enable sdhc-ice, rng and qce on shikra
> > platform similar to other platforms.
> >
> > Previously, the 3 dt-bindigs/DT changes were sent as individual series
> > and with feedback received, clubbed them together as all belong to same
> > crypto subsystem.
> >
> > Here's link to old patchsets.
> > QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
>
> Hi Eric,
>
> As selftests issues for QCE are now fixed[1], so shikra series should be
> good to proceed? as your concerns[2] are now addressed.
> I am waiting for merge window to end and will send next rev post that.
>
> [1]
> https://lore.kernel.org/linux-arm-msm/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com/
> [2] https://lore.kernel.org/lkml/20260522024912.GC5937@quark/
If you think that then it sounds like you need to read what I actually
said. The fixes are appreciated but don't change the big picture.
- Eric
^ permalink raw reply
* Re: [PATCH 02/10] rust: driver: simplify `IdArray::new_without_index`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: devicetree, linux-pci, Alexandre Courbot, robh, ojeda, dri-devel,
Danilo Krummrich, conor+dt
In-Reply-To: <20260618-id_info-v1-2-96af1e559ef9@garyguo.net>
> This method can very easily construct the `IdArray` on its own without
> delegating to `Self::build`. Doing so also simplifies the phy device table
> macro because it does not need to construct tuples anymore.
>
> This also allows simplification of `new` and `build` which removes the
> `unsafe`.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=2
^ permalink raw reply
* Re: [PATCH 10/10] RFC: rust: driver: support map-like syntax for ID table
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: robh, dri-devel, conor+dt, ojeda, linux-pci, Danilo Krummrich,
Alexandre Courbot, devicetree
In-Reply-To: <20260618-id_info-v1-10-96af1e559ef9@garyguo.net>
> The device ID table and its associated info is really just a map. Add a
> syntax to `module_device_table` macro that reflects that.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=10
^ permalink raw reply
* Re: [PATCH 03/10] rust: pci: use `Option<&IdInfo>` for device ID info
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: ojeda, dri-devel, Danilo Krummrich, conor+dt, linux-pci,
devicetree, robh, Alexandre Courbot
In-Reply-To: <20260618-id_info-v1-3-96af1e559ef9@garyguo.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The dynamic ID matching in the PCI core returns a pointer to a dynamically allocated ID without holding a lock or reference, leading to a Use-After-Free if the ID is concurrently removed via sysfs.
--
commit d1889a1b7c5b08bca9b93c95bb95cf7a983ddfea
Author: Gary Guo <gary@garyguo.net>
rust: pci: use Option<&IdInfo> for device ID info
This commit updates the Rust PCI probe functions to accept an Option<&IdInfo>
instead of a direct reference. This allows the driver to handle situations
where the driver_data is 0, such as when driver_override is used.
[ ... ]
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index 5071cae6543fd..0e055e4df99ee 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
> @@ -113,7 +113,7 @@ extern "C" fn probe_callback(
> let info = T::ID_TABLE.info(id.index());
>
> from_result(|| {
> - let data = T::probe(pdev, info);
> + let data = T::probe(pdev, Some(info));
[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing
Use-After-Free in the C PCI core that impacts this callback.
In the C subsystem, pci_match_device() searches for dynamic IDs under
drv->dynids.lock and returns a pointer to the interior of dynid after
dropping the lock:
drivers/pci/pci-driver.c:pci_match_device() {
...
found_id = &dynid->id;
break;
}
}
spin_unlock(&drv->dynids.lock);
if (found_id)
return found_id;
}
Concurrently, if a user removes the ID via sysfs, remove_id_store() frees
it unconditionally:
drivers/pci/pci-driver.c:remove_id_store() {
...
list_del(&dynid->node);
kfree(dynid);
}
When local_pci_probe() calls the driver's probe callback, it passes this
potentially dangling id pointer. Since the Rust probe_callback() receives
this pointer from C, will dereferencing it (such as when calling id.index()
just above this change) trigger a Use-After-Free crash?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=3
^ permalink raw reply
* Re: [PATCH 09/10] rust: driver: remove duplicate ID table
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, conor+dt, dri-devel, linux-pci,
Alexandre Courbot, ojeda, robh, devicetree
In-Reply-To: <20260618-id_info-v1-9-96af1e559ef9@garyguo.net>
> Previously, `IdArray` contains both device ID table and info table so we
> keep a separate copy for MODULE_DEVICE_TABLE for hotplug (which needs to be
> just the device ID table). With the info being changed to be carried via
> pointers, `IdArray` is now layout compatible with raw ID table and hence
> there is no longer a need to keep the distinction.
>
> Deduplicate the code, and remove the redundant copy for hotplug purpose by
> just giving the `IdArray` instance a proper symbol name.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=9
^ permalink raw reply
* Re: [PATCH 08/10] rust: driver: remove open-coded matching logic
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Alexandre Courbot, linux-pci, devicetree, robh, Danilo Krummrich,
conor+dt, dri-devel, ojeda
In-Reply-To: <20260618-id_info-v1-8-96af1e559ef9@garyguo.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing `#[inline]` annotation on `id_info`.
- [Low] Leftover FFI wrapper `acpi_of_match_device` and its backing C helpers are unused.
--
commit 8ad64c5f4617fb456cb113763d7136737e7f51e2
Author: Gary Guo <gary@garyguo.net>
rust: driver: remove open-coded matching logic
This commit replaces the open-coded ACPI and OF matching logic with a single
call to device_get_match_data(), as device ID info now includes pointers
instead of indices.
> diff --git a/rust/kernel/driver.rs b/rust/kernel/driver.rs
> index 824899d76fed2..a881f5ef99ecf 100644
> --- a/rust/kernel/driver.rs
> +++ b/rust/kernel/driver.rs
[ ... ]
> @@ -325,117 +324,22 @@ pub trait Adapter {
[ ... ]
> - #[cfg(CONFIG_ACPI)]
> - {
> - use core::ptr;
> - use device::property::FwNode;
> -
> - let mut raw_id = ptr::null();
> -
> - let fwnode = dev.fwnode().map_or(ptr::null_mut(), FwNode::as_raw);
> -
> - // SAFETY: `fwnode` is a pointer to a valid `fwnode_handle`. A null pointer will be
> - // passed through the function.
> - let adev = unsafe { bindings::to_acpi_device_node(fwnode) };
> -
> - // SAFETY:
> - // - `adev` is a valid pointer to `acpi_device` or is null. It is guaranteed to be
> - // valid as long as `dev` is alive.
> - // - `table` has static lifetime, hence it's valid for read.
> - if unsafe { acpi_of_match_device(adev, table.as_ptr(), &raw mut raw_id) } {
[Severity: Low]
Since the manual ACPI matching is being removed here, are the FFI wrapper
acpi_of_match_device() and its backing C helpers (such as
rust_helper_acpi_of_match_device() and rust_helper_to_acpi_device_node()
in rust/helpers/acpi.c) now completely unused? Should they be removed
in this patch to avoid leaving dead code behind?
[ ... ]
> - fn id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> {
> - let id = Self::acpi_id_info(dev);
> - if id.is_some() {
> - return id;
> - }
> -
> - let id = Self::of_id_info(dev);
> - if id.is_some() {
> - return id;
> - }
> + ///
> + /// # Safety
> + ///
> + /// The caller must ensure that the `dev` matched data is of type `Self::IdInfo`.
> + unsafe fn id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> {
> + // SAFETY: `dev` is guaranteed to be valid while it's alive, and so is `dev.as_raw()`.
> + let data = unsafe { bindings::device_get_match_data(dev.as_raw()) };
[Severity: Low]
This isn't a bug, but according to the Rust subsystem coding guidelines,
functions in abstractions that are small or simply forward to a binding
call should be annotated with #[inline]. Since this function consists of a
single FFI call and a cast, should an #[inline] annotation be added here?
>
> - None
> + // SAFETY: Per safety requirement, `data` is of type `Self::IdInfo`.
> + unsafe { data.cast::<Self::IdInfo>().as_ref() }
> }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=8
^ permalink raw reply
* Re: [PATCH 04/10] rust: net/phy: remove expansion from doc
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: robh, devicetree, Alexandre Courbot, linux-pci, dri-devel,
conor+dt, Danilo Krummrich, ojeda
In-Reply-To: <20260618-id_info-v1-4-96af1e559ef9@garyguo.net>
> The expansion serves little purpose and it can easily diverge.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=4
^ permalink raw reply
* Re: [PATCH 05/10] rust: driver: centralize device ID handling
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, ojeda, robh, conor+dt, linux-pci, devicetree,
Alexandre Courbot, dri-devel
In-Reply-To: <20260618-id_info-v1-5-96af1e559ef9@garyguo.net>
> Move the `IdArray` creation from individual buses to be handled by shared
> code in `device_id.rs`.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=5
^ permalink raw reply
* Re: [PATCH 07/10] rust: driver: store pointers in `DeviceId`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: dri-devel, devicetree, conor+dt, robh, linux-pci,
Danilo Krummrich, ojeda, Alexandre Courbot
In-Reply-To: <20260618-id_info-v1-7-96af1e559ef9@garyguo.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Arbitrary Memory Dereference / Privilege Escalation via PCI dynamic IDs (`new_id`)
- [High] Undefined Behavior via unconditional null reference creation when `driver_data` is 0
--
commit 01871465d12a97f7be006ca329ebda24f458cf1e
Author: Gary Guo <gary@garyguo.net>
rust: driver: store pointers in `DeviceId`
This commit changes Rust device IDs to store pointers directly in the
driver_data field, matching the behavior of C drivers. It works around
the limitation of missing provenance during const evaluation by wrapping
raw IDs in MaybeUninit.
> diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
> index 84852a2d9ad78..59453588df0e7 100644
> --- a/rust/kernel/device_id.rs
> +++ b/rust/kernel/device_id.rs
[ ... ]
> @@ -47,15 +50,48 @@ pub unsafe trait RawDeviceIdIndex: RawDeviceId {
> /// The offset (in bytes) to the context/data field in the raw device ID.
> const DRIVER_DATA_OFFSET: usize;
>
> - /// The index stored at `DRIVER_DATA_OFFSET` of the implementor of the [`RawDeviceIdIndex`]
> - /// trait.
> - fn index(&self) -> usize;
> + /// Obtain the data pointer stored inside the device ID.
> + ///
> + /// # Safety
> + ///
> + /// `&Self` must be stored inside a `IdArray<Self, U>`.
> + unsafe fn info_unchecked<U>(&self) -> &'static U {
> + // SAFETY: By safety requirement of the trait, this is `self.driver_data as *const U` and by
> + // the safety requirement of the function, this is stored in `IdArray<Self, U>` so is
> + // convertible to `&'static U`.
> + unsafe {
> + core::ptr::from_ref(self)
> + .byte_add(Self::DRIVER_DATA_OFFSET)
> + .cast::<&U>()
> + .read()
> + }
> + }
[Severity: High]
Does this code create an unconditional null reference in Rust if the
driver_data or driver_info field is 0?
Creating a null reference is immediate undefined behavior in Rust, even for
zero-sized types. This 0 value can occur in paths like:
1. IdArray::new_without_index() leaving driver_data fields as 0.
2. When userspace adds a dynamic USB ID via the sysfs new_id interface using
fewer than 5 fields (omitting refVendor), USB core initializes driver_info
to 0.
[ ... ]
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index a3dd48f763532..a630c7fc6a853 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
[ ... ]
> @@ -110,10 +110,13 @@ extern "C" fn probe_callback(
> // SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `struct pci_device_id` and
> // does not add additional invariants, so it's safe to transmute.
> let id = unsafe { &*id.cast::<DeviceId>() };
> - let info = T::ID_TABLE.info(id.index());
> +
> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>` or
> + // `pci_device_id_any` which has 0 as driver_data.
> + let info = unsafe { id.info_unchecked_opt::<T::IdInfo>() };
[Severity: Critical]
Can this allow an arbitrary memory dereference or bypass kernel lockdown?
The PCI subsystem supports dynamic IDs via the sysfs new_id interface
(drivers/pci/pci-driver.c), which parses up to 7 arguments, the last being
driver_data (%lx).
This allows a privileged user (root) to supply an arbitrary pointer value.
The code here will blindly cast this integer to an Option<&'static U> via
info_unchecked_opt() and dereference it if non-zero, allowing arbitrary
kernel memory access.
[ ... ]
> diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
> index 500b5e0ba4ea9..8aeff50117552 100644
> --- a/rust/kernel/usb.rs
> +++ b/rust/kernel/usb.rs
[ ... ]
> @@ -89,7 +89,8 @@ extern "C" fn probe_callback(
> // does not add additional invariants, so it's safe to transmute.
> let id = unsafe { &*id.cast::<DeviceId>() };
>
> - let info = T::ID_TABLE.info(id.index());
> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>`.
> + let info = unsafe { id.info_unchecked::<T::IdInfo>() };
> let data = T::probe(intf, id, info);
[Severity: High]
Does this code trigger undefined behavior when the underlying USB device ID
driver_info field is 0?
When the id is constructed using IdArray::new_without_index() or when
dynamically added via sysfs new_id with fewer fields, the driver_info is 0.
This probe unconditionally expects a valid non-null reference and creates
one even for 0-initialized IDs via info_unchecked().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=7
^ permalink raw reply
* Re: [PATCH 01/10] rust: driver: remove `IdTable::id`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, Alexandre Courbot, linux-pci, devicetree,
conor+dt, dri-devel, ojeda, robh
In-Reply-To: <20260618-id_info-v1-1-96af1e559ef9@garyguo.net>
> This is unused.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=1
^ permalink raw reply
* Re: [PATCH 06/10] rust: driver: remove `$module_table_name` from `module_device_table`
From: sashiko-bot @ 2026-06-19 17:05 UTC (permalink / raw)
To: Gary Guo
Cc: conor+dt, ojeda, dri-devel, linux-pci, robh, Danilo Krummrich,
devicetree, Alexandre Courbot
In-Reply-To: <20260618-id_info-v1-6-96af1e559ef9@garyguo.net>
> Wrap the generated code in a `const _: ()` block to avoid symbol conflict.
> This removes the need of creating a new identifier.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-id_info-v1-0-96af1e559ef9@garyguo.net?part=6
^ permalink raw reply
* [PATCH v2 0/2] Add support for StarFive JHB100 SPI
From: Changhuang Liang @ 2026-06-19 14:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Mark Brown
Cc: linux-spi, linux-kernel, devicetree, Changhuang Liang
The StarFive JHB100 SPI is based on the Synopsys DesignWare SSI version 2.00.
changes since v1:
PATCH 1:
- Add "starfive,jhb100-spi" and support falling back to
"snps,dwc-ssi-2.00a" or "snps,dwc-ssi-1.01a".
- using subject lines reflecting the style for the
spi subsystem.
v1: https://lore.kernel.org/all/20260612125856.8530-1-changhuang.liang@starfivetech.com/
Changhuang Liang (2):
spi: dt-bindings: snps,dw-apb-ssi: Add starfive,jhb100-spi
spi: dw: Add support for snps,dwc-ssi-2.00a
Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 6 ++++++
drivers/spi/spi-dw-mmio.c | 1 +
2 files changed, 7 insertions(+)
--
2.25.1
^ permalink raw reply
* Re: [PATCH 07/10] rust: driver: store pointers in `DeviceId`
From: Gary Guo @ 2026-06-19 17:12 UTC (permalink / raw)
To: sashiko-reviews, Gary Guo
Cc: dri-devel, devicetree, conor+dt, robh, linux-pci,
Danilo Krummrich, ojeda, Alexandre Courbot
In-Reply-To: <20260619170508.8E9351F00A3E@smtp.kernel.org>
On Fri Jun 19, 2026 at 6:05 PM BST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Arbitrary Memory Dereference / Privilege Escalation via PCI dynamic IDs (`new_id`)
> - [High] Undefined Behavior via unconditional null reference creation when `driver_data` is 0
> --
>
> commit 01871465d12a97f7be006ca329ebda24f458cf1e
> Author: Gary Guo <gary@garyguo.net>
>
> rust: driver: store pointers in `DeviceId`
>
> This commit changes Rust device IDs to store pointers directly in the
> driver_data field, matching the behavior of C drivers. It works around
> the limitation of missing provenance during const evaluation by wrapping
> raw IDs in MaybeUninit.
>
>> diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
>> index 84852a2d9ad78..59453588df0e7 100644
>> --- a/rust/kernel/device_id.rs
>> +++ b/rust/kernel/device_id.rs
> [ ... ]
>> @@ -47,15 +50,48 @@ pub unsafe trait RawDeviceIdIndex: RawDeviceId {
>> /// The offset (in bytes) to the context/data field in the raw device ID.
>> const DRIVER_DATA_OFFSET: usize;
>>
>> - /// The index stored at `DRIVER_DATA_OFFSET` of the implementor of the [`RawDeviceIdIndex`]
>> - /// trait.
>> - fn index(&self) -> usize;
>> + /// Obtain the data pointer stored inside the device ID.
>> + ///
>> + /// # Safety
>> + ///
>> + /// `&Self` must be stored inside a `IdArray<Self, U>`.
>> + unsafe fn info_unchecked<U>(&self) -> &'static U {
>> + // SAFETY: By safety requirement of the trait, this is `self.driver_data as *const U` and by
>> + // the safety requirement of the function, this is stored in `IdArray<Self, U>` so is
>> + // convertible to `&'static U`.
>> + unsafe {
>> + core::ptr::from_ref(self)
>> + .byte_add(Self::DRIVER_DATA_OFFSET)
>> + .cast::<&U>()
>> + .read()
>> + }
>> + }
>
> [Severity: High]
> Does this code create an unconditional null reference in Rust if the
> driver_data or driver_info field is 0?
>
> Creating a null reference is immediate undefined behavior in Rust, even for
> zero-sized types. This 0 value can occur in paths like:
>
> 1. IdArray::new_without_index() leaving driver_data fields as 0.
>
> 2. When userspace adds a dynamic USB ID via the sysfs new_id interface using
> fewer than 5 fields (omitting refVendor), USB core initializes driver_info
> to 0.
>
> [ ... ]
>> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
>> index a3dd48f763532..a630c7fc6a853 100644
>> --- a/rust/kernel/pci.rs
>> +++ b/rust/kernel/pci.rs
> [ ... ]
>> @@ -110,10 +110,13 @@ extern "C" fn probe_callback(
>> // SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `struct pci_device_id` and
>> // does not add additional invariants, so it's safe to transmute.
>> let id = unsafe { &*id.cast::<DeviceId>() };
>> - let info = T::ID_TABLE.info(id.index());
>> +
>> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>` or
>> + // `pci_device_id_any` which has 0 as driver_data.
>> + let info = unsafe { id.info_unchecked_opt::<T::IdInfo>() };
>
> [Severity: Critical]
> Can this allow an arbitrary memory dereference or bypass kernel lockdown?
>
> The PCI subsystem supports dynamic IDs via the sysfs new_id interface
> (drivers/pci/pci-driver.c), which parses up to 7 arguments, the last being
> driver_data (%lx).
>
> This allows a privileged user (root) to supply an arbitrary pointer value.
> The code here will blindly cast this integer to an Option<&'static U> via
> info_unchecked_opt() and dereference it if non-zero, allowing arbitrary
> kernel memory access.
False positive because dyn ID requires the data to be matching one of the
existing data.
>
> [ ... ]
>> diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
>> index 500b5e0ba4ea9..8aeff50117552 100644
>> --- a/rust/kernel/usb.rs
>> +++ b/rust/kernel/usb.rs
> [ ... ]
>> @@ -89,7 +89,8 @@ extern "C" fn probe_callback(
>> // does not add additional invariants, so it's safe to transmute.
>> let id = unsafe { &*id.cast::<DeviceId>() };
>>
>> - let info = T::ID_TABLE.info(id.index());
>> + // SAFETY: `id` comes from `T::ID_TABLE` which is of type `IdArray<_, T::IdInfo>`.
>> + let info = unsafe { id.info_unchecked::<T::IdInfo>() };
>> let data = T::probe(intf, id, info);
>
> [Severity: High]
> Does this code trigger undefined behavior when the underlying USB device ID
> driver_info field is 0?
>
> When the id is constructed using IdArray::new_without_index() or when
> dynamically added via sysfs new_id with fewer fields, the driver_info is 0.
> /sys/bus/
> This probe unconditionally expects a valid non-null reference and creates
> one even for 0-initialized IDs via info_unchecked().
Looks like I need to convert USB code to use `Option<&Self::IdInfo>` too, like
what I did to PCI.
Best,
Gary
^ 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