* 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 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 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
* [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 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 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 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
* 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 08/11] ARM: mach-lpc: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 16:00 UTC (permalink / raw)
To: Frank.Li; +Cc: imx, conor+dt, Frank.Li, devicetree, robh
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-8-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Incorrect removal of an active MMU platform (LPC32xx) under the false premise of removing NOMMU platforms.
- [High] Incomplete Kconfig cleanup leaves dangling dependencies across the kernel, violating Kconfig subsystem rules.
Pre-existing issues:
- [High] Forcing the fallback stub for `lpc32xx_return_iram()` exposes a NULL pointer dereference and a zero-sized DMA allocation bug in `lpc_eth.c`.
--
commit 19639a4680fe193e3e1ece890c77d5f80c446705
Author: Frank Li <Frank.Li@nxp.com>
ARM: mach-lpc: Remove NOMMU platform support
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
NXP/Freescale platform code.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9187240a02db5..fe67d41f4a107 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
[ ... ]
> @@ -401,8 +401,6 @@ source "arch/arm/mach-ixp4xx/Kconfig"
>
> source "arch/arm/mach-keystone/Kconfig"
>
> -source "arch/arm/mach-lpc32xx/Kconfig"
> -
[Severity: High]
Does this removal leave dangling dependencies in other subsystems?
For example, drivers/net/ethernet/nxp/Kconfig has:
depends on ARCH_LPC32XX || COMPILE_TEST
And arch/arm/Kconfig.debug has:
depends on ARCH_LPC32XX
Since this patch deletes ARCH_LPC18XX and ARCH_LPC32XX but doesn't clean
up the references to them, will these become dead code that violate Kconfig
subsystem rules?
> source "arch/arm/mach-mediatek/Kconfig"
>
> source "arch/arm/mach-meson/Kconfig"
[ ... ]
> diff --git a/arch/arm/mach-lpc32xx/Kconfig b/arch/arm/mach-lpc32xx/Kconfig
> deleted file mode 100644
> index 138599545c24c..0000000000000
> --- a/arch/arm/mach-lpc32xx/Kconfig
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> -
> -config ARCH_LPC32XX
> - bool "NXP LPC32XX"
> - depends on ARCH_MULTI_V5
> - depends on CPU_LITTLE_ENDIAN
> - select ARM_AMBA
> - select CLKSRC_LPC32XX
> - select CPU_ARM926T
[Severity: High]
Is LPC32XX actually a NOMMU platform?
Looking at the definition being removed here, it selects CPU_ARM926T and
depends on ARCH_MULTI_V5.
Since ARM926EJ-S features an MMU and runs standard Linux, does removing this
under the premise of removing NOMMU platforms accidentally delete an active,
MMU-equipped SoC?
[ ... ]
> diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
> deleted file mode 100644
> index 304ea61a07160..0000000000000
> --- a/arch/arm/mach-lpc32xx/common.c
> +++ /dev/null
[ ... ]
> -static u32 iram_size;
> -u32 lpc32xx_return_iram(void __iomem **mapbase, dma_addr_t *dmaaddr)
> -{
[Severity: High]
This is a pre-existing issue, but does removing ARCH_LPC32XX permanently
expose a bug in the lpc32xx_return_iram() fallback stub?
When the platform is removed, include/linux/soc/nxp/lpc32xx-misc.h
forces the use of the dummy implementation:
static inline u32 lpc32xx_return_iram(void __iomem **mapbase,
dma_addr_t *dmaaddr)
{
*mapbase = NULL;
*dmaaddr = 0;
return 0;
}
This unconditionally dereferences the pointer arguments.
In drivers/net/ethernet/nxp/lpc_eth.c:lpc_eth_drv_remove(), the driver
passes NULL for these arguments:
if (!use_iram_for_net(&pldat->pdev->dev) ||
pldat->dma_buff_size > lpc32xx_return_iram(NULL, NULL))
Will forcing the fallback stub cause a NULL pointer dereference here?
Additionally, since the stub returns 0, lpc_eth_drv_probe() sets the
buffer size to 0:
if (pldat->dma_buff_size >
lpc32xx_return_iram(&pldat->dma_buff_base_v, &dma_handle)) {
pldat->dma_buff_base_v = NULL;
pldat->dma_buff_size = 0;
Could this result in a zero-sized DMA allocation being used as an array
for descriptors?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=8
^ permalink raw reply
* Re: [PATCH v6 16/23] phy: rockchip: usbdp: Drop DP HPD handling
From: sashiko-bot @ 2026-06-19 16:00 UTC (permalink / raw)
To: Sebastian Reichel
Cc: conor+dt, olteanv, neil.armstrong, linux-phy, vkoul, devicetree,
robh
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-16-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Potential Use-After-Free of the `udphy` struct when the driver is unbound, triggered by active Type-C consumers.
--
commit 709452eb1097435563d2642eb88ed81ae54361f2
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Drop DP HPD handling
This patch drops the HPD handling logic from the USBDP PHY. The registers
involved require the display controller power domain being enabled and thus
the HPD signal should be handled by the displayport controller itself.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index b75c190a4311f..383e68b245060 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -1333,6 +1291,14 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
> struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
> u8 mode;
>
> + /*
> + * Ignore mux events not involving DP AltMode, because
> + * the mode field is being reused, e.g. state->mode == 4
> + * could be either TYPEC_MODE_USB4 or TYPEC_DP_STATE_C.
> + */
> + if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
> + return 0;
> +
> mutex_lock(&udphy->mutex);
[Severity: High]
This is a pre-existing issue, but could this code lead to a use-after-free
of the udphy struct when the driver is unbound?
The udphy structure is allocated using devm_kzalloc() in rk_udphy_probe(),
tying its lifetime to the device's binding lifecycle.
On driver unbind, devres calls typec_mux_unregister() and
typec_switch_unregister(), which run device_unregister(), and then frees
udphy.
However, device_unregister() only drops the core reference. If a Type-C
consumer (like the tcpm port driver) holds a reference to these Type-C
devices via fwnode_typec_mux_get(), the mux_dev and sw_dev objects stay
alive.
The consumer can still asynchronously invoke rk_udphy_typec_mux_set() or
rk_udphy_orien_sw_set() after the phy driver has been unbound.
Because udphy has already been freed by devres, does this mean any
subsequent call will dereference the freed udphy pointer when attempting to
lock udphy->mutex here, potentially resulting in memory corruption?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=16
^ permalink raw reply
* Re: [PATCH 10/11] clk: nxp: lpc: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 15:58 UTC (permalink / raw)
To: Frank.Li; +Cc: robh, imx, conor+dt, devicetree, Frank.Li
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-10-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Mischaracterized platform deletion: LPC32xx is an MMU-enabled platform, not NOMMU.
- [Low] Incomplete architecture removal leaves orphaned peripheral drivers as dead code.
--
commit 6253e432d16195a0666c33f89bdf6509acf7cdf3
Author: Frank Li <Frank.Li@nxp.com>
clk: nxp: lpc: Remove NOMMU platform support
This commit removes the NXP LPC clock drivers to reduce maintenance burden,
stating that the NOMMU platform support is obsolete, unused, and
unmaintained as users have migrated to other RTOS solutions.
> clk: nxp: lpc: Remove NOMMU platform support
>
> Commercial users and hardware vendors migrated to Zephyr or other RTOS
> solutions years ago, leaving the NOMMU platform support effectively
> unused and unmaintained.
[ ... ]
> diff --git a/drivers/clk/nxp/Makefile b/drivers/clk/nxp/Makefile
> deleted file mode 100644
> index 2cf6317d28531..0000000000000
> --- a/drivers/clk/nxp/Makefile
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> -obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-cgu.o
> -obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-ccu.o
> -obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-creg.o
> -obj-$(CONFIG_ARCH_LPC32XX) += clk-lpc32xx.o
[Severity: High]
Is this justification accurate for all removed platforms? The commit message
states this is removing NOMMU platform support, but the LPC32xx platform
uses an ARM926EJ-S core. This core features a full Memory Management Unit
(MMU) and runs standard virtual-memory Linux.
Was LPC32xx swept up by mistake because it resided in the same directory as
the NOMMU LPC18xx platform, or is the commit message mischaracterizing an
MMU platform deletion?
[ ... ]
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index cc108a75a9008..23b14a934635d 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -136,7 +136,6 @@ obj-y += mstar/
> obj-y += mvebu/
> obj-$(CONFIG_ARCH_MXS) += mxs/
> obj-$(CONFIG_ARCH_MA35) += nuvoton/
> -obj-$(CONFIG_COMMON_CLK_NXP) += nxp/
[Severity: Low]
Does this incomplete architecture removal leave orphaned peripheral drivers
as dead code elsewhere in the tree?
Because the ARCH_LPC18XX and ARCH_LPC32XX Kconfig symbols have been deleted,
their associated peripheral drivers (e.g., in drivers/gpio, drivers/pwm,
drivers/net, drivers/iio) can now only be built when COMPILE_TEST is
enabled and will never be executed. Could these peripheral drivers be
removed atomically alongside the platform deletion?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=10
^ permalink raw reply
* Re: [PATCH v6 21/23] phy: rockchip: usbdp: Support going from DP-only mode to USB mode
From: sashiko-bot @ 2026-06-19 15:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-phy, olteanv, devicetree, conor+dt, neil.armstrong, robh,
vkoul
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-21-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The `usb_in_use` flag is bypassed if `phy_init` is called while the PHY is in a DP-only mode, permanently breaking USB functionality for subsequent adapter swaps.
- [High] The fix fails to restore USB functionality when transitioning from a DP-only adapter to a pure USB Type-C device.
- [High] The `!(old_mode & UDPHY_MODE_USB)` check in `rk_udphy_typec_mux_set()` erroneously fails because `rk_udphy_orien_sw_set()` preemptively modifies the mode during unplug/replug.
- [Medium] If `rk_udphy_power_on()` fails during a type-C mux transition, `udphy->mode` remains permanently updated, preventing future retries from restoring USB power.
--
commit fe9deaf95e7e3b871d382c46e07c07e56534ca4d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Support going from DP-only mode to USB mode
This patch adds support for restoring USB functionality when a DP-only
adapter is unplugged and replaced with an adapter supporting USB, working
around the USB controller keeping the PHY enabled.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 81aae3bc57476..7f26b74cb5151 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -1287,7 +1293,13 @@ static int rk_udphy_usb3_phy_init(struct phy *phy)
> return 0;
> }
>
> - return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
> + ret = rk_udphy_power_on(udphy, UDPHY_MODE_USB);
> + if (ret)
> + return ret;
> +
> + udphy->usb_in_use = true;
[Severity: High]
Does this early return logic introduce a regression that prevents the flag
from being set if the system boots with a DP-only adapter?
If phy_init is called when the current mode lacks USB, it takes the early
return visible in the context above and skips executing
udphy->usb_in_use = true.
When a DP+USB adapter is later plugged in, udphy->usb_in_use will be false,
and the newly added restoration logic in rk_udphy_typec_mux_set() will
silently skip powering on the USB PHY.
> +
> + return 0;
> }
[ ... ]
> @@ -1315,6 +1329,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
> struct typec_mux_state *state)
> {
> struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
> + u8 old_mode;
>
> /*
> * Ignore mux events not involving DP AltMode, because
[Severity: High]
Is there a regression here where pure USB adapters bypass this restoration
logic entirely?
The code just below this in rk_udphy_typec_mux_set() aborts for non-DP
events:
if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
return 0;
If a pure USB Type-C device is connected after a DP-only adapter,
rk_udphy_orien_sw_set() updates the default mapping to UDPHY_MODE_DP_USB,
but rk_udphy_typec_mux_set() is never triggered. Since the USB controller
keeps the PHY logically enabled without calling phy_init again, the USB PHY
would remain powered off.
> @@ -1326,8 +1341,20 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>
> guard(mutex)(&udphy->mutex);
>
> + old_mode = udphy->mode;
> +
> rk_udphy_set_typec_state(udphy, state->mode);
>
> + /*
> + * If the new mode includes USB but the old one didn't (e.g. leaving
> + * DP-only), and the USB PHY was already initialized by the USB
> + * controller, we need to power on the USB side now since no
> + * subsequent phy_init call will come from the controller.
> + */
> + if ((udphy->mode & UDPHY_MODE_USB) && !(old_mode & UDPHY_MODE_USB) &&
[Severity: High]
Does this introduce a regression where old_mode already includes
UDPHY_MODE_USB during an unplug/replug sequence?
When unplugging a DP-only adapter and plugging in a DP+USB adapter,
rk_udphy_orien_sw_set() is called first and unconditionally sets
udphy->mode to UDPHY_MODE_DP_USB.
When rk_udphy_typec_mux_set() is called moments later, old_mode = udphy->mode
will capture UDPHY_MODE_DP_USB. The check !(old_mode & UDPHY_MODE_USB)
would then evaluate to false, causing the USB PHY restoration to be skipped.
> + udphy->usb_in_use && !udphy->hs)
> + return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
[Severity: Medium]
If rk_udphy_power_on() fails here, does it leave udphy->mode permanently
updated without a rollback?
rk_udphy_set_typec_state() modifies udphy->mode before this power-on
attempt. If rk_udphy_power_on() returns an error, the mode retains the USB
bit. If the Type-C subsystem retries the switch later, old_mode will now
include the USB bit, which would permanently prevent future retries from
passing the restoration check.
> +
> return 0;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=21
^ permalink raw reply
* Re: [PATCH 06/11] ARM: imxrt_defconfig: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 15:55 UTC (permalink / raw)
To: Frank.Li; +Cc: imx, devicetree, Frank.Li, robh, conor+dt
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-6-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Leftover references, platform-specific structures, compatible strings, and early console declarations for the removed i.MXRT and VF610M4 platforms remain in multiple drivers and DT bindings.
- [Low] Deleted clock dt-binding header is still included in the `imxrt1050-clock.yaml` dt-binding YAML example, breaking `dt_binding_check`.
--
commit 3968f192513e74f4358aed03401b5e2ab20e266b
Author: Frank Li <Frank.Li@nxp.com>
ARM: imxrt_defconfig: Remove NOMMU platform support
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
> i.MX platform code.
[Severity: Medium]
Since this series removes the NOMMU platform support for i.MXRT and VF610M4,
should the remaining platform-specific structures and references also be
cleaned up?
There are leftover configurations such as usdhc_imxrt1050_data in
drivers/mmc/host/sdhci-esdhc-imx.c:
static struct esdhc_soc_data usdhc_imxrt1050_data = {
imxrt1050_data in drivers/tty/serial/fsl_lpuart.c:
static const struct lpuart_soc_data imxrt1050_data = {
early console declarations in drivers/tty/serial/fsl_lpuart.c:
OF_EARLYCON_DECLARE(lpuart32, "fsl,imxrt1050-lpuart", lpuart32_imx_early_console_setup);
and the fsl,vf610m4 compatibility string in arch/arm/mach-imx/mach-vf610.c:
"fsl,vf610m4",
Because the core architecture files and Kconfigs are removed, these remnants
become unreachable orphaned dead code.
[Severity: Low]
Does this series also need to update the dt-binding examples?
The deleted include/dt-bindings/clock/imxrt1050-clock.h header is still
included in the Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml
example block:
#include <dt-bindings/clock/imxrt1050-clock.h>
When the dt_binding_check target attempts to preprocess this YAML example,
the C preprocessor fails with a "No such file or directory" error.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=6
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: gaokun3: describe rear camera module information as musch as possible
From: Konrad Dybcio @ 2026-06-19 15:55 UTC (permalink / raw)
To: Vladimir Zapolskiy, Pengyu Luo
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Martin Kepplinger-Novakovic, Sakari Ailus,
Mauro Carvalho Chehab, Hans Verkuil, Martin Kepplinger,
linux-arm-msm, devicetree, linux-kernel, linux-media
In-Reply-To: <9da6d544-97f6-4915-8d53-e3fde7339695@linaro.org>
On 5/5/26 8:55 PM, Vladimir Zapolskiy wrote:
> On 5/2/26 15:55, Pengyu Luo wrote:
>> On Thu, Apr 30, 2026 at 7:00 PM Vladimir Zapolskiy
>> <vladimir.zapolskiy@linaro.org> wrote:
>>>
>>> On 4/25/26 13:53, Pengyu Luo wrote:
>>>> The rear sensor is S5K3L6, describing it but dropping compatible
>>>> string, since there is no upstream driver. A funcitonal downstream
>>>> driver is in comment.
>>>>
>>>> The VCM is dw9714, describe it.
>>>>
>>>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>>>> ---
>>>> Please take this patch as a RFC, I am not sure, how much I am allowed
>>>> to add without a sensor driver.
>>>> ---
>>>> .../boot/dts/qcom/sc8280xp-huawei-gaokun3.dts | 129 +++++++++++++++++-
>>>> 1 file changed, 123 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts b/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
>>>> index 39e559e91289..76b1ecb3819d 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
>>>> @@ -22,12 +22,18 @@
>>>> #include "sc8280xp.dtsi"
>>>> #include "sc8280xp-pmics.dtsi"
>>>>
>>>> +/* remove due to gpio pins collision, skip 2nd instance won't break things */
>>>> +/delete-node/ &cci1_i2c1;
>>>> +/delete-node/ &cci1_i2c1_default;
>>>> +/delete-node/ &cci1_i2c1_sleep;
>>>
>>> Instead of removal 'cci1_default' and 'cci1_sleep' nodes shall be rewritten
>>> by excluding 'cci1_i2c1_default' and 'cci1_i2c1_sleep' from them.
>>>
>>
>> Should we register an unused node?
>>
>
> I believe unused nodes are found everywhere marked by status = "disabled"
> or if they do not produce a conflict for resources. I understand that a CCI
> IP with two ports are special, but likely (not always though) it should be
> acceptable to keep its device tree node as is.
I wanted the pins to move to the sub-buses as well, but that doesn't seem
trivial - we would either have to alter some obscure core code, or manage
the pinctrl states manually from within the CCI driver
(contributions welcome)
Konrad
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: dma: sun50i-a64-dma: Update device tree bindings documentation for A733
From: Frank Li @ 2026-06-19 15:55 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-5-da4b649fc72a@gmail.com>
On Fri, Jun 19, 2026 at 04:53:34AM +0000, Yuanshen Cao wrote:
>
> To complete the support for the A733 DMA controller, added
> `allwinner,sun60i-a733-dma` to the list of compatible strings for
> `allwinner,sun50i-a64-dma` dt-binding documentations..
>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
Sorry, this patch should be moved to where before your driver, which use it
Frank
> Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> index c3e14eb6cfff..1cc3304b7414 100644
> --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> @@ -25,6 +25,7 @@ properties:
> - allwinner,sun50i-a64-dma
> - allwinner,sun50i-a100-dma
> - allwinner,sun50i-h6-dma
> + - allwinner,sun60i-a733-dma
> - items:
> - const: allwinner,sun8i-r40-dma
> - const: allwinner,sun50i-a64-dma
> @@ -70,6 +71,7 @@ if:
> - allwinner,sun20i-d1-dma
> - allwinner,sun50i-a100-dma
> - allwinner,sun50i-h6-dma
> + - allwinner,sun60i-a733-dma
>
> then:
> properties:
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH 04/11] clk: imx: imxrt1050: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 15:54 UTC (permalink / raw)
To: Frank.Li; +Cc: imx, robh, conor+dt, devicetree, Frank.Li
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-4-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Deleting the `include/dt-bindings/clock/imxrt1050-clock.h` header breaks `make dt_binding_check` because the header is still included in the YAML binding example.
- [Low] Incomplete cleanup: Defconfig for the removed vf610m4 platform was left behind.
--
commit 19efb4118fc745b70a599c1f992b0e4fad42b13c
Author: Frank Li <Frank.Li@nxp.com>
clk: imx: imxrt1050: Remove NOMMU platform support
This commit removes the IMXRT1050 CCM clock driver and its device tree
binding header. This is part of dropping unused NOMMU platform support
from the kernel.
> diff --git a/include/dt-bindings/clock/imxrt1050-clock.h b/include/dt-bindings/clock/imxrt1050-clock.h
> deleted file mode 100644
> index 93bef0832d16d..0000000000000
> --- a/include/dt-bindings/clock/imxrt1050-clock.h
> +++ /dev/null
> @@ -1,72 +0,0 @@
> -/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
> -/*
> - * Copyright(C) 2019
> - * Author(s): Giulio Benetti <giulio.benetti@benettiengineering.com>
> - */
> -
> -#ifndef __DT_BINDINGS_CLOCK_IMXRT1050_H
> -#define __DT_BINDINGS_CLOCK_IMXRT1050_H
[Severity: Low]
Does deleting this header break make dt_binding_check?
The Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml file
still includes this header in its examples section:
Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml:examples()
examples:
- |
#include <dt-bindings/clock/imxrt1050-clock.h>
If the YAML file is not removed or updated, make dt_binding_check will fail
with a missing file error when extracting and building the example.
[ ... ]
[Severity: Low]
Does this series miss cleaning up the vf610m4_defconfig file?
Since the patch series removes NOMMU platform support, including the
vf610m4 device tree files, should arch/arm/configs/vf610m4_defconfig
also be removed? It configures the kernel for the vf610m4 NOMMU platform
and appears to be left behind as an unused configuration.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=4
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: dma: sun50i-a64-dma: Update device tree bindings documentation for A733
From: Frank Li @ 2026-06-19 15:53 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-5-da4b649fc72a@gmail.com>
On Fri, Jun 19, 2026 at 04:53:34AM +0000, Yuanshen Cao wrote:
Subject needn't talk about binding twice
dma: sun50i-a64-dma: Add a733 support
>
> To complete the support for the A733 DMA controller, added
> `allwinner,sun60i-a733-dma` to the list of compatible strings for
> `allwinner,sun50i-a64-dma` dt-binding documentations..
Add allwinner,sun60i-a733-dma compatible string. And list some differene
here to show why need it.
Frank
>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> index c3e14eb6cfff..1cc3304b7414 100644
> --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> @@ -25,6 +25,7 @@ properties:
> - allwinner,sun50i-a64-dma
> - allwinner,sun50i-a100-dma
> - allwinner,sun50i-h6-dma
> + - allwinner,sun60i-a733-dma
> - items:
> - const: allwinner,sun8i-r40-dma
> - const: allwinner,sun50i-a64-dma
> @@ -70,6 +71,7 @@ if:
> - allwinner,sun20i-d1-dma
> - allwinner,sun50i-a100-dma
> - allwinner,sun50i-h6-dma
> + - allwinner,sun60i-a733-dma
>
> then:
> properties:
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v6 18/23] phy: rockchip: usbdp: Re-init the PHY on orientation change
From: sashiko-bot @ 2026-06-19 15:53 UTC (permalink / raw)
To: Sebastian Reichel
Cc: vkoul, olteanv, devicetree, linux-phy, neil.armstrong, robh,
conor+dt
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-18-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing Hardware Initialization
--
commit 2a50b346fcf7d166779e0cb198d3572f5bdd300c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Re-init the PHY on orientation change
This commit updates the cable orientation configuration to re-initialize
the PHY when the orientation changes. It sets a flag to trigger the
re-initialization to prevent DisplayPort functionality from breaking on
reverse cable plugs.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index c210aaeb283a5..402f3cafcf0ae 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -622,6 +622,7 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
> enum typec_orientation orien)
> {
> struct rk_udphy *udphy = typec_switch_get_drvdata(sw);
> + bool flipped = orien == TYPEC_ORIENTATION_REVERSE;
>
> mutex_lock(&udphy->mutex);
>
> @@ -633,7 +634,10 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
> goto unlock_ret;
> }
>
> - udphy->flip = orien == TYPEC_ORIENTATION_REVERSE;
> + if (udphy->flip != flipped)
> + udphy->phy_needs_reinit = true;
[Severity: High]
This is a pre-existing issue, but does setting udphy->phy_needs_reinit = true
here actually trigger a hardware update for pure USB3 connections?
When a device is plugged in, the hardware lane muxing is typically updated
inside rk_udphy_init(), which is called conditionally by rk_udphy_power_on().
However, looking at the phy_ops struct for USB3:
static const struct phy_ops rk_udphy_usb3_phy_ops = {
.init = rk_udphy_usb3_phy_init,
.exit = rk_udphy_usb3_phy_exit,
.owner = THIS_MODULE,
};
Because rk_udphy_usb3_phy_ops omits the .power_on callback, and the DWC3
controller only calls .init once during probe, the USB subsystem won't
trigger the PHY re-initialization required to apply the orientation changes.
Will the phy_needs_reinit flag remain set indefinitely, causing pure USB3
devices to fail to link at SuperSpeed if plugged in the reverse orientation?
> +
> + udphy->flip = flipped;
> rk_udphy_set_typec_default_mapping(udphy);
> rk_udphy_usb_bvalid_enable(udphy, true);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=18
^ permalink raw reply
* Re: [PATCH 09/11] ARM: configs: lpc*: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 15:53 UTC (permalink / raw)
To: Frank.Li; +Cc: Frank.Li, imx, robh, devicetree, conor+dt
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-9-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The commit message incorrectly categorizes LPC32xx as a NOMMU platform, using this false premise to justify deleting its defconfig and support.
--
commit dd95b6d6b05d88a43de62ac58a8d3da5f10168ac
Author: Frank Li <Frank.Li@nxp.com>
ARM: configs: lpc*: Remove NOMMU platform support
This commit removes the lpc18xx and lpc32xx default configurations,
justifying the removal by stating that commercial users of these NOMMU
platforms have migrated to RTOS solutions.
> Commercial users and hardware vendors migrated to Zephyr or other RTOS
> solutions years ago, leaving the NOMMU platform support effectively
> unused and unmaintained.
[ ... ]
> diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
> deleted file mode 100644
> index b9e2e603cd95e..0000000000000
> --- a/arch/arm/configs/lpc32xx_defconfig
> +++ /dev/null
> @@ -1,192 +0,0 @@
> -CONFIG_SYSVIPC=y
[ ... ]
> -CONFIG_EXPERT=y
> -# CONFIG_ARCH_MULTI_V7 is not set
> -CONFIG_ARCH_LPC32XX=y
[Severity: High]
Is the commit message description accurate for LPC32xx?
While LPC18xx is a NOMMU platform, LPC32xx is based on the ARM926EJ-S
processor which features a Memory Management Unit (MMU) and runs standard
Linux rather than an RTOS.
Unlike lpc18xx_defconfig which explicitly unsets CONFIG_MMU, this
configuration leaves CONFIG_MMU enabled by default and relies on standard
Linux features like CONFIG_SYSVIPC.
Could removing an MMU-capable platform under the assumption that it is a
deprecated NOMMU target bypass the proper evaluation process for standard
Linux platforms?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=9
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-19 15:54 UTC (permalink / raw)
To: Conor Dooley
Cc: Janani Sunil, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260619-concierge-doozy-9c161533c369@spud>
On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > >
> > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > >
> > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > integrated precision reference.
> > > > > > > > ...
> > > > > > > > Probably others may comment on that, but...
> > > > > > > >
> > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > >
> > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > +
> > > > > > > > > +patternProperties:
> > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > + type: object
> > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > +
> > > > > > > > > + properties:
> > > > > > > > > + reg:
> > > > > > > > > + description: Channel number.
> > > > > > > > > + minimum: 0
> > > > > > > > > + maximum: 15
> > > > > > > > > +
> > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > + description: |
> > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > + oneOf:
> > > > > > > > > + - items:
> > > > > > > > > + - const: 0
> > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > + - items:
> > > > > > > > > + - const: -5000000
> > > > > > > > > + - const: 5000000
> > > > > > > > > + - items:
> > > > > > > > > + - const: -10000000
> > > > > > > > > + - const: 10000000
> > > > > > > > > + - items:
> > > > > > > > > + - const: -15000000
> > > > > > > > > + - const: 15000000
> > > > > > > > > + - items:
> > > > > > > > > + - const: -20000000
> > > > > > > > > + - const: 20000000
> > > > > > > > > +
> > > > > > > > > + required:
> > > > > > > > > + - reg
> > > > > > > > > +
> > > > > > > > > + additionalProperties: false
> > > > > > > > > +
> > > > > > > > > +required:
> > > > > > > > > + - compatible
> > > > > > > > > + - reg
> > > > > > > > > + - vdd-supply
> > > > > > > > > + - avdd-supply
> > > > > > > > > + - hvdd-supply
> > > > > > > > > +
> > > > > > > > > +dependencies:
> > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > +
> > > > > > > > > +allOf:
> > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > +
> > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > +
> > > > > > > > > +examples:
> > > > > > > > > + - |
> > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > +
> > > > > > > > > + spi {
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <0>;
> > > > > > > > > +
> > > > > > > > > + dac@0 {
> > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > + reg = <0>;
> > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > +
> > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > +
> > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > +
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <0>;
> > > > > > > > > +
> > > > > > > > > + channel@0 {
> > > > > > > > > + reg = <0>;
> > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + channel@1 {
> > > > > > > > > + reg = <1>;
> > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + channel@2 {
> > > > > > > > > + reg = <2>;
> > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > ...
> > > > > > > >
> > > > > > > > spi {
> > > > > > > > #address-cells = <1>;
> > > > > > > > #size-cells = <0>;
> > > > > > > >
> > > > > > > > multi-dac@0 {
> > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > reg = <0>;
> > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > >
> > > > > > > > #address-cells = <1>;
> > > > > > > > #size-cells = <0>;
> > > > > > > >
> > > > > > > > dac@0 {
> > > > > > > > reg = <0>;
> > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > >
> > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > >
> > > > > > > > #address-cells = <1>;
> > > > > > > > #size-cells = <0>;
> > > > > > > >
> > > > > > > > channel@0 {
> > > > > > > > reg = <0>;
> > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > };
> > > > > > > >
> > > > > > > > channel@1 {
> > > > > > > > reg = <1>;
> > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > };
> > > > > > > >
> > > > > > > > channel@2 {
> > > > > > > > reg = <2>;
> > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > };
> > > > > > > > }
> > > > > > > >
> > > > > > > > dac@1 {
> > > > > > > > reg = <1>;
> > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > >
> > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > >
> > > > > > > > #address-cells = <1>;
> > > > > > > > #size-cells = <0>;
> > > > > > > >
> > > > > > > > channel@0 {
> > > > > > > > reg = <0>;
> > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > };
> > > > > > > >
> > > > > > > > channel@1 {
> > > > > > > > reg = <1>;
> > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > };
> > > > > > > > }
> > > > > > > > };
> > > > > > > > };
> > > > > > > >
> > > > > > > > then you might need something like:
> > > > > > > >
> > > > > > > > patternProperties:
> > > > > > > > "^dac@[0-3]$":
> > > > > > > >
> > > > > > > > and put most of the things under this node pattern.
> > > > > > > >
> > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > >
> > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > Hi Rodrigo,
> > > > > > >
> > > > > > > Thank you for looking at this.
> > > > > > >
> > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > speculatively without a validating use case.
> > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > >
> > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > in all devices in the chain as one big SPI message.
> > > > > >
> > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > longer term how to support it cleanly in SPI.
> > > >
> > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > see if I can find what I am thinking of...
> > >
> > >
> > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > slightly different properties.
> > >
> > > microchip,device-addr:
> > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > $ref: /schemas/types.yaml#/definitions/uint32
> > > enum: [0, 1, 2, 3]
> > > default: 0
> > >
> > > and
> > >
> > >
> > > microchip,hw-device-address:
> > > $ref: /schemas/types.yaml#/definitions/uint32
> > > minimum: 0
> > > maximum: 3
> > > description:
> > > The address is set on a per-device basis by fuses in the factory,
> > > configured on request. If not requested, the fuses are set for 0x1.
> > > The device address is part of the device markings to avoid
> > > potential confusion. This address is coded on two bits, so four possible
> > > addresses are available when multiple devices are present on the same
> > > SPI bus with only one Chip Select line for all devices.
> > > Each device communication starts by a CS falling edge, followed by the
> > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > which is first one on the wire).
> > >
> > > This sounds exactly like the sort of feature that you're dealing with
> > > here?
> > >
> >
> > The core idea yes but for this chip, things are a bit more annoying (but
> > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > have it's own supplies, pins and at the very least, channels with maybe
> > different scales. That is why Janani is proposing dac nodes. Given I
> > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > about solving this at the spi level.
> >
> > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > together in the same bus.
>
> I'm definitely missing something, because that property for the
> microchip devices is not impacted what else is on the bus. AFAICT, you
> could have an mcp3911 and an mcp3564 on the same bus even though both
> are completely different devices with different drivers. They have
> individual device nodes and their own supplies etc etc. These aren't
> per-channel properties on an adc or dac, they're per child device on a
> spi bus.
Maybe I'm the one missing something :). IIRC, spi would not allow two
devices on the same CS right? Because for this chip we would need
something like:
spi {
dac@0 {
reg = <0>;
adi,pin-id = <0>;
};
dac@1 {
reg = <0>; // which seems already problematic?
adi,pin-id <1>;
};
...
//up to 4
};
- Nuno Sá
^ permalink raw reply
* Re: [PATCH 01/11] ARM: dts: vf610m4: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 15:52 UTC (permalink / raw)
To: Frank.Li; +Cc: conor+dt, imx, Frank.Li, devicetree, robh
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-1-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incomplete removal of VF610 Cortex-M4 NOMMU platform support leaves orphaned code and configuration.
--
commit 47df1414ffdd1b53077023f0d62226535c747e2a
Author: Frank Li <Frank.Li@nxp.com>
ARM: dts: vf610m4: Remove NOMMU platform support
This commit removes the device tree files for the obsolete Vybrid M4 NOMMU
platform to reduce maintenance burden.
> Remove the obsolete support to reduce maintenance burden and simplify the
> code.
[Severity: Medium]
Since the goal is to fully remove the VF610 Cortex-M4 NOMMU platform
support, does this patch leave behind orphaned configurations and code?
There appear to be several remaining references that might need cleaning up
to completely simplify the codebase:
- The dedicated arch/arm/configs/vf610m4_defconfig file
- The fsl,vf610m4 compatible string in the vf610_dt_compat array in
arch/arm/mach-imx/mach-vf610.c
- The fsl,vf610m4 binding in Documentation/devicetree/bindings/arm/fsl.yaml
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=1
^ permalink raw reply
* Re: [PATCH 07/11] ARM: dts: lpc: Remove NOMMU platform support
From: sashiko-bot @ 2026-06-19 15:50 UTC (permalink / raw)
To: Frank.Li; +Cc: Frank.Li, robh, conor+dt, devicetree, imx
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-7-0101795a2662@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unintended removal of the MMU-capable LPC32xx platform under the false premise of removing NOMMU support, along with an inaccurate commit message.
--
commit d19b47e78b74813c8413198ab7ec32784181d8d8
Author: Frank Li <Frank.Li@nxp.com>
Subject: ARM: dts: lpc: Remove NOMMU platform support
This commit removes the arch/arm/boot/dts/nxp/lpc directory, stating the
intention is to remove unused NOMMU platform support. It drops the build
targets for LPC platforms to simplify the codebase.
> ARM: dts: lpc: Remove NOMMU platform support
>
> 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
> i.MX platform code.
[Severity: High]
Does this commit unintentionally remove the MMU-capable LPC32xx platform?
While the LPC18xx and LPC43xx series are Cortex-M NOMMU parts, the LPC32xx
series uses an ARM926EJ-S processor, which features a full MMU and runs a
standard Linux kernel.
This mistake appears to cascade through the rest of the patch series, where
mach-lpc32xx is also deleted under the same 'NOMMU' premise.
Also, this isn't a bug, but there appears to be a copy-paste error in the
commit message where it mentions simplifying the "i.MX platform code" instead
of LPC.
> diff --git a/arch/arm/boot/dts/nxp/lpc/Makefile b/arch/arm/boot/dts/nxp/lpc/Makefile
> deleted file mode 100644
> index 56b9a0ebb9179..0000000000000
> --- a/arch/arm/boot/dts/nxp/lpc/Makefile
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0
> -dtb-$(CONFIG_ARCH_LPC18XX) += \
> - lpc4337-ciaa.dtb \
> - lpc4350-hitex-eval.dtb \
> - lpc4357-ea4357-devkit.dtb \
> - lpc4357-myd-lpc4357.dtb
> -dtb-$(CONFIG_ARCH_LPC32XX) += \
> - lpc3250-ea3250.dtb \
> - lpc3250-phy3250.dtb
[Severity: High]
Does the removal of these targets improperly disable the LPC32XX platform,
which relies on an MMU-capable core?
> diff --git a/arch/arm/boot/dts/nxp/lpc/lpc32xx.dtsi b/arch/arm/boot/dts/nxp/lpc/lpc32xx.dtsi
> deleted file mode 100644
> index e94df78def18a..0000000000000
> --- a/arch/arm/boot/dts/nxp/lpc/lpc32xx.dtsi
> +++ /dev/null
> @@ -1,540 +0,0 @@
[ ... ]
> - cpus {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - cpu@0 {
> - compatible = "arm,arm926ej-s";
> - device_type = "cpu";
> - reg = <0x0>;
> - };
> - };
[Severity: High]
Since this node defines cpu@0 as an ARM926EJ-S, a core that features a full
MMU, does this contradict the commit's justification for removing this
platform as 'NOMMU'?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dts_cleanup_arm_mcore-v1-0-0101795a2662@nxp.com?part=7
^ permalink raw reply
* Re: [PATCH v6 07/23] phy: rockchip: usbdp: Keep clocks running on PHY re-init
From: sashiko-bot @ 2026-06-19 15:50 UTC (permalink / raw)
To: Sebastian Reichel
Cc: devicetree, neil.armstrong, robh, vkoul, olteanv, linux-phy,
conor+dt
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-7-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The Type-C mux callback completely ignores non-DP AltMode events, failing to reset lane mapping on AltMode exit.
- [High] Asynchronous `udphy->mode` updates cause `phy_exit` and `phy_power_off` to skip teardown, resulting in permanent clock and reset leaks.
--
commit ea283780e749d528861fc2fe55f998d22454a53b
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Keep clocks running on PHY re-init
When a mode change is required rk_udphy_power_on() disables
the clocks and then calls rk_udphy_setup(), which then enables
all the clocks again before continuing with rk_udphy_init().
Considering that rk_udphy_init() does assert the reset lines,
re-enabling the clocks is just delaying things. Avoid it by
directly calling rk_udphy_init().
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 6dff4dfc9363e..c05ee65a9f73a 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1011,8 +1011,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> if (udphy->mode == UDPHY_MODE_DP)
> rk_udphy_u3_port_disable(udphy, true);
>
> - rk_udphy_disable(udphy);
> - ret = rk_udphy_setup(udphy);
> + ret = rk_udphy_init(udphy);
[Severity: High]
This is a pre-existing issue, but the Type-C mux callback completely ignores
non-DP AltMode events, failing to reset lane mapping on AltMode exit.
When exiting DP AltMode (e.g., via sysfs or renegotiation without a physical
cable unplug), the Type-C subsystem calls typec_mux_set() with state->mode =
TYPEC_STATE_SAFE or TYPEC_STATE_USB and state->alt = NULL.
However, rk_udphy_typec_mux_set() immediately returns 0 if !state->alt:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_typec_mux_set() {
...
if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
return 0;
...
}
Does this leave udphy->mode stuck in the previous DP configuration (e.g.,
UDPHY_MODE_DP with 4 DP lanes), which breaks subsequent USB3 initialization
because rk_udphy_usb3_phy_init() checks udphy->mode and skips powering on
the U3 port?
[Severity: High]
This is a pre-existing issue, but asynchronous udphy->mode updates cause
phy_exit() and phy_power_off() to skip teardown, resulting in permanent clock
and reset leaks.
udphy->mode tracks the target hardware mux state and is updated asynchronously
by Type-C events. However, rk_udphy_usb3_phy_exit() checks this current
udphy->mode rather than the initialized state (udphy->status) to decide
whether to power off:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_usb3_phy_exit() {
...
/* DP only or high-speed */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
return 0;
...
}
The phy_power_off() implementation also suffers from this flaw,
short-circuiting before it can update udphy->status and tear down resources:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_off() {
...
if (!(udphy->mode & mode)) {
dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
return;
}
...
}
If the Type-C mux switches from a DP+USB mode to a DP-only mode while USB3
is active, UDPHY_MODE_USB is cleared from udphy->mode. When the USB3
controller later shuts down and calls phy_exit(), rk_udphy_usb3_phy_exit()
sees the bit missing and returns 0 early, skipping rk_udphy_power_off().
This prevents UDPHY_MODE_USB from being cleared from udphy->status. When the
DP controller subsequently calls phy_power_off(), udphy->status remains
non-zero, skipping rk_udphy_disable().
Since there is no driver removal cleanup fallback, do the clock enable
references get permanently leaked?
> if (ret)
> return ret;
> udphy->mode_change = false;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=7
^ permalink raw reply
* Re: [PATCH v6 02/23] phy: rockchip: usbdp: Update mode_change after error handling
From: sashiko-bot @ 2026-06-19 15:49 UTC (permalink / raw)
To: Sebastian Reichel
Cc: vkoul, robh, devicetree, neil.armstrong, linux-phy, conor+dt,
olteanv
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-2-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] System crash due to concurrent MMIO access after PHY reinitialization failure.
- [High] State desync and resource leak in PHY mode tracking during Type-C role transitions.
--
commit e7082d92230eb75aff8a9e06c20d96b4d548e34c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: phy: rockchip: usbdp: Update mode_change after error handling
If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.
Link: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index fba35510d88ce..a5ffdf7a6e76b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> }
>
> if (udphy->status == UDPHY_MODE_NONE) {
[Severity: High]
This isn't a bug introduced by this patch, but I have a question about how
PHY mode transitions are tracked when the Type-C mux switches from a state
with USB (like DP+USB) to a state without it (like DP-only).
In this scenario, the mode variable gets updated, but the USB flag is not
cleared from the status field. Later, when the USB subsystem calls
rk_udphy_usb3_phy_exit(), it sees that the current mode lacks the USB flag
and returns early. This bypasses rk_udphy_power_off().
Does this mean the USB flag is permanently leaked in the status field? If
the remaining DP consumer subsequently powers off, it seems the status would
still contain the USB flag, preventing the driver from properly shutting
down the hardware and leaving APB clocks active.
> ret = rk_udphy_setup(udphy);
> if (ret)
> return ret;
>
> if (udphy->mode & UDPHY_MODE_USB)
> rk_udphy_u3_port_disable(udphy, false);
> - } else if (udphy->mode_change) {
> udphy->mode_change = false;
> + } else if (udphy->mode_change) {
> udphy->status = UDPHY_MODE_NONE;
> if (udphy->mode == UDPHY_MODE_DP)
> rk_udphy_u3_port_disable(udphy, true);
> @@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> ret = rk_udphy_setup(udphy);
> if (ret)
> return ret;
[Severity: Critical]
This is a pre-existing issue, but what happens if the setup or init fails
here during a Type-C orientation change?
If rk_udphy_init() fails due to something like an LCPLL lock timeout, it
asserts all resets, including the APB resets, before returning the error.
This function then propagates that error, but it doesn't restore the prior
state of sibling PHYs (like DP) which might already be active.
Since the DP framework would still consider the PHY active, could it
subsequently invoke rk_udphy_dp_phy_configure()? If that happens and it
attempts MMIO access to the PMA regmap while the APB bus reset is still
asserted, would this trigger a bus hang and a kernel panic?
> + udphy->mode_change = false;
> }
>
> udphy->status |= mode;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=2
^ permalink raw reply
* Re: [PATCH v6 11/23] phy: rockchip: usbdp: Support single-lane DP
From: sashiko-bot @ 2026-06-19 15:48 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-phy, robh, devicetree, conor+dt, vkoul, neil.armstrong,
olteanv
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-11-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The devicetree bindings schema for 'rockchip,dp-lane-mux' was not updated to allow single-item arrays, which will cause dtbs_check validation errors when using the newly added single-lane DP feature.
--
commit 1f02bccf35aefcbe053f784a52330f63bbd49988
Author: Zhang Yubing <yubing.zhang@rock-chips.com>
phy: rockchip: usbdp: Support single-lane DP
This commit implements support for using a single DisplayPort lane in the
Rockchip USB/DP PHY driver. It updates the lane configuration and devicetree
parsing logic to handle single-lane setups.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 2ff05ef6eeacd..a87cb5c0596e7 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -897,7 +884,7 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
> return 0;
> }
>
> - if (num_lanes != 2 && num_lanes != 4)
> + if (num_lanes != 1 && num_lanes != 2 && num_lanes != 4)
> return dev_err_probe(udphy->dev, -EINVAL,
> "invalid number of lane mux\n");
[Severity: Low]
Does this change also require an update to the devicetree bindings schema?
It looks like Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
still restricts rockchip,dp-lane-mux to a minimum of 2 items:
rockchip,dp-lane-mux:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 4
Could this cause dtbs_check validation errors when valid device trees start
using the new 1-lane configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=11
^ 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