* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Bryan O'Donoghue @ 2026-06-13 9:52 UTC (permalink / raw)
To: Atanas Filipov, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <3d4e0147-8e62-4872-b881-1452f5e09e85@oss.qualcomm.com>
On 13/06/2026 10:24, Atanas Filipov wrote:
> Thank you for the feedback. I understand the reasoning, but I
> respectfully disagree with this approach for the following reasons.
>
> While it is true that the JPEG encoder shares the same camera NOC and
> power domain infrastructure as CAMSS, that is a hardware topology detail
> — not a sufficient justification for imposing a software dependency. The
> driver is a fully
> self-contained V4L2 mem2mem encoder, implemented like every other JPEG
> encoder driver currently in the kernel (imx-jpeg, s5p-jpeg, mtk-jpeg,
> nxp-jpeg). None of those are sub-nodes of a parent ISP or camera
> subsystem driver.
That's a backwards understanding of the ethos of DT, which is to
describe hardware architecture, to describe hardware, not to subscribe
to or proscribe a particular software architecture.
Those jpeg blocks are standalone, whereas the CAMSS jpeg encoder lives
inside of the CAMSS power-island.
> Making the JPEG encoder a sub-node of camss would introduce an
> unnecessary and artificial coupling: the JPEG encoder cannot be probed,
> built, or used independently of the CAMSS driver, even on platforms
> where CAMSS is disabled. This directly contradicts the kernel's
> principle of independent, single-purpose drivers.
- Probed true
- Built true
- Used untrue
Once probed your current driver can chug along pretty much unperturbed,
however I don't believe that statement can hold true as more of the
camera hardware gets enabled.
> The shared hardware resources (clocks, interconnects, IOMMU stream IDs,
> power domain) are already fully described in the device tree node and
> handled by the standard kernel frameworks — there is no functional
> reason to nest the node under camss.
Except that it is a real description of the hardware. "We can model it
separately != we have modeled it correctly".
And at least one thing you are leaving out here is the cam noc - which
eventually we will have to start to enable and will almost certainly
have to be controlled by the core driver which also owns the
power-collapse and muxes, the thing that will also program CPAs - the
core CAMSS driver.
Perhaps we choose to model that NOC as a separate driver or perhaps we
expose an API in CAMSS to vote, either way its an intrinsic part of the
voltage and clocks in this block.
Either way sure we could model it as a fully separate node but, that is
not really how/where the block lives. It lives inside of a defined CAMSS
block, which is its own power-island.
Switching on the JPEG part of it by inference switches on the top-level
of the island so, its not separate at all.
> For these reasons I would prefer to keep the JPEG encoder as a
> standalone platform device with its own DT node, consistent with how all
> comparable JPEG encoder drivers are structured in the kernel today.
>
> afilipov
>
> On 6/13/2026 2:14 AM, Bryan O'Donoghue wrote:
>> On 12/06/2026 20:44, Atanas Filipov wrote:
>>> + qcom_jpeg_enc: jpeg-encoder@ac4e000 {
>>
>> One key bit of review feedback I gave in the previous leaked version of
>> this driver is that since the jpeg-encoder is part of the CAMSS block it
>> should be a sub-node of camss as OPE, CSIPHY and other blocks will be.
>>
>> Please take that feedback onboard in your v2.
>>
>> ---
>> bod
>
>
And please no top posting !
---
bod
^ permalink raw reply
* Re: [PATCH v2 8/9] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Jun Yan @ 2026-06-13 9:53 UTC (permalink / raw)
To: conor
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101, krzk+dt,
linux-input, linux-kernel, robh
In-Reply-To: <20260612-plethora-debatable-d00cb679277b@spud>
> On Fri, Jun 12, 2026 at 03:22:14PM +0800, Jun Yan wrote:
> > CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> > and hardware reset support.
> >=20
> > Add the compatible string for CAP1114, add its datasheet URL,
> > update the maximum of LED channel reg, and add constraint for
> > linux,keycodes.
> >=20
> > Previously, the LED reg property had a default maximum of 7 for CAP1188.
> > With the addition of CAP1114, the default maximum is now 11.
> > An if-then constraint is added to limit the LED count for CAP1188.
> >=20
> > Update description for microchip,input-threshold: CAP1114 only provides
> > eight threshold entries, which does not match its total channel count.
> >=20
> > CAP1114 does not support microchip,signal-guard and
> > microchip,calib-sensitivity.
> >=20
> > Add CAP1114 to the unsupported enum list.
> >=20
> > Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> > ---
> > .../bindings/input/microchip,cap11xx.yaml | 32 ++++++++++++++++++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >=20
> > diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.ya=
> ml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > index 778ec6d659a8..0e9a1a8a3f3e 100644
> > --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > @@ -12,6 +12,7 @@ description: |
> > =20
> > For more product information please see the links below:
> > CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.=
> pdf
> > + CAP1114: https://ww1.microchip.com/downloads/en/DeviceDoc/00002444A.=
> pdf
> > CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.=
> pdf
> > CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.=
> pdf
> > CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.=
> pdf
> > @@ -26,6 +27,7 @@ properties:
> > compatible:
> > enum:
> > - microchip,cap1106
> > + - microchip,cap1114
> > - microchip,cap1126
> > - microchip,cap1188
> > - microchip,cap1203
> > @@ -122,6 +124,8 @@ properties:
> > is required for a touch to be registered, making the touch sensor =
> less
> > sensitive.
> > The number of entries must correspond to the number of channels.
> > + CAP1114 is an exception where channels 8~14 reuse the eighth entry=
> 's
> > + threshold, so counts differ.
> > =20
> > microchip,calib-sensitivity:
> > $ref: /schemas/types.yaml#/definitions/uint32-array
> > @@ -149,7 +153,7 @@ patternProperties:
> > reg:
> > description: LED channel number
> > minimum: 0
> > - maximum: 7
> > + maximum: 10
> > =20
> > label: true
> > =20
> > @@ -178,6 +182,18 @@ allOf:
> > properties:
> > reset-gpios: false
> > =20
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - microchip,cap1114
> > + then:
> > + properties:
> > + linux,keycodes:
> > + minItems: 14
> > + maxItems: 14
>
> Sashiko complaint here is valid.
> You need to increase the outer constraint to max 14, and only set the
> min here.
> Then you need to add an else that sets maxitems to 8.
Thanks for the review. I'll fix this in v3.
> pw-bot: changes-requested
>
> Cheers,
> Conor.
^ permalink raw reply
* Re: [PATCH v2 2/2] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Krzysztof Kozlowski @ 2026-06-13 10:02 UTC (permalink / raw)
To: Denzeel Oliva
Cc: Sylwester Nawrocki, Chanwoo Choi, Peter Griffin, Alim Akhtar,
Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Conor Dooley, linux-samsung-soc, linux-clk, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260613-exynos990-peris-fix-v2-v2-2-3dff7ade75b3@gmail.com>
On Sat, Jun 13, 2026 at 12:19:52AM -0500, Denzeel Oliva wrote:
> Correct eight PERIS gate clock parents to match the hardware clock
> tree, reorder the GIC mux parents, and add the missing TMU_SUB_PCLK
> gate.
Separate commit. Fixing clock parents is something completely different
than adding new clock gate.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [net-next 8/9] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
From: Krzysztof Kozlowski @ 2026-06-13 10:04 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <20260610102432.3538432-9-niklas.soderlund+renesas@ragnatech.se>
On Wed, Jun 10, 2026 at 12:24:31PM +0200, Niklas Söderlund wrote:
> The RAVB module on Gen4 have no gPTP clock as part of the RAVB module
> itself, instead it relies on an external system wide gPTP clock. The
> gPTP clock is shared with RTSN on V4H and RSWITCH on S4.
>
> Add an optional phandle so that the RAVB driver can find and use the
> gPTP clock. Ideally this should have been an mandatory property but for
> backward compatible it is optional. The RAVB module is capable of
> functioning without it, but can in such cases not provided PTP
> functionality.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> .../bindings/net/renesas,etheravb.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> index 1e00ef5b3acd..7bc910ab3ae0 100644
> --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> @@ -122,6 +122,13 @@ properties:
> Specify when the AVB_LINK signal is active-low instead of normal
> active-high.
>
> + renesas,gptp:
Aren't you duplicating existing timestamper property? Aren't purpose of
both the same?
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + A phandle to an external gPTP clock for Gen4 platforms. The property is
Explain the purpose of this in the hardware.
> + optional for backwards compatibility, but without it gPTP timestamps are
> + disabled as Gen4 have no gPTP as part of the RAVB module itself.
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [net-next 8/9] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
From: Niklas Söderlund @ 2026-06-13 10:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Geert Uytterhoeven, Magnus Damm,
Sergei Shtylyov, netdev, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <20260613-caped-ferret-of-philosophy-acae13@quoll>
On 2026-06-13 12:04:09 +0200, Krzysztof Kozlowski wrote:
> On Wed, Jun 10, 2026 at 12:24:31PM +0200, Niklas Söderlund wrote:
> > The RAVB module on Gen4 have no gPTP clock as part of the RAVB module
> > itself, instead it relies on an external system wide gPTP clock. The
> > gPTP clock is shared with RTSN on V4H and RSWITCH on S4.
> >
> > Add an optional phandle so that the RAVB driver can find and use the
> > gPTP clock. Ideally this should have been an mandatory property but for
> > backward compatible it is optional. The RAVB module is capable of
> > functioning without it, but can in such cases not provided PTP
> > functionality.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > ---
> > .../bindings/net/renesas,etheravb.yaml | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> > index 1e00ef5b3acd..7bc910ab3ae0 100644
> > --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> > +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> > @@ -122,6 +122,13 @@ properties:
> > Specify when the AVB_LINK signal is active-low instead of normal
> > active-high.
> >
> > + renesas,gptp:
>
> Aren't you duplicating existing timestamper property? Aren't purpose of
> both the same?
Yes I am. I will switch to using the existing ptp-timer property. Thank
you.
>
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + A phandle to an external gPTP clock for Gen4 platforms. The property is
>
> Explain the purpose of this in the hardware.
>
> > + optional for backwards compatibility, but without it gPTP timestamps are
> > + disabled as Gen4 have no gPTP as part of the RAVB module itself.
> > +
>
> Best regards,
> Krzysztof
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v2 6/9] Input: cap11xx - add reset gpio support
From: Jun Yan @ 2026-06-13 10:17 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260612073150.185DB1F000E9@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(=
> s) to consider:
>
> New issues:
> - [Medium] Unintended glitch on the reset line during probe due to GPIOD_OU=
> T_LOW initialization.
>
> Pre-existing issues:
> - [High] Unvalidated keycodes from Device Tree cause an out-of-bounds heap =
> write.
> --
>
> commit 5befbfbb7019f474fe2d2d2e0e3da23976b75ada
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> Input: cap11xx - add reset gpio support
>
> Some CAP11xx devices (CAP1126/CAP1188) have a dedicated RESET pin. Add
> hardware reset operation to improve device reliability and ensure proper
> initialization on probe.
>
> > diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/ca=
> p11xx.c
> > index 686174722204c..75746a8a22332 100644
> > --- a/drivers/input/keyboard/cap11xx.c
> > +++ b/drivers/input/keyboard/cap11xx.c
>
> [ ... ]
>
> > @@ -452,6 +457,17 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_=
> client)
> > if (IS_ERR(priv->regmap))
> > return PTR_ERR(priv->regmap);
> > =20
> > + priv->reset_gpio =3D devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LO=
> W);
> > + if (IS_ERR(priv->reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> > + "Failed to get 'reset' GPIO\n");
> > + if (priv->reset_gpio) {
> > + gpiod_set_value_cansleep(priv->reset_gpio, 1);
>
> [Severity: Medium]
> Does initializing the reset GPIO with GPIOD_OUT_LOW cause an unintended
> glitch on the reset line?
>
> When devm_gpiod_get_optional() is called with GPIOD_OUT_LOW, the GPIO line
> is immediately driven to its logical low (inactive) state. If the hardware
> or bootloader previously left the device in a reset state, this prematurely
> pulls it out of reset.
>
> The driver then immediately calls gpiod_set_value_cansleep() to assert
> the reset. This sequence creates an extremely short, unintended
> de-assert/assert glitch on the reset pin, which could violate hardware
> timing requirements.
>
> Would it be safer to request the reset GPIO with GPIOD_OUT_HIGH (or
> GPIOD_ASIS) to guarantee it starts in the logically asserted state before
> we hold it for the required minimum duration?
Agreed, this also makes the code cleaner.
>
> [Severity: High]
> This is a pre-existing issue, but does this code overflow the keybit array
> if a device tree provides unvalidated keycodes?
>
> Later in cap11xx_i2c_probe(), the driver loops over the keycodes read from
> the device tree:
>
> for (i =3D 0; i < cap->num_channels; i++)
> __set_bit(priv->keycodes[i], priv->idev->keybit);
>
> Since __set_bit() does not perform bounds checking, if a device tree
> specifies a keycode value greater than or equal to KEY_MAX, this will
> write outside the bounds of the keybit array in the input_dev structure,
> clobbering adjacent memory in the kernel heap.
>
> Should we add a check against KEY_MAX before setting the bit?
>
> > + usleep_range(CAP11XX_T_RST_FILT_MIN_US, CAP11XX_T_RST_FILT_MIN_US * 2);
> > + gpiod_set_value_cansleep(priv->reset_gpio, 0);
> > + msleep(CAP11XX_T_RST_ON_MIN_MS);
> > + }
> > +
> > error =3D regmap_read(priv->regmap, CAP11XX_REG_PRODUCT_ID, &val);
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260612072237.1177=
> 304-1-jerrysteve1101@gmail.com?part=3D6
>
^ permalink raw reply
* Re: [PATCH v8 6/6] pinctrl: mediatek: Add MT6735 pinctrl driver
From: Yassine Oudjana @ 2026-06-13 10:20 UTC (permalink / raw)
To: Linus Walleij
Cc: Yassine Oudjana, Sean Wang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Andy Teng, linux-mediatek, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <CAD++jLkA3v0RD1skaanqqG2eN8JLivUQPrYdK+hbX1YhQBgKqw@mail.gmail.com>
On Monday, June 8th, 2026 at 9:41 PM, Linus Walleij <linusw@kernel.org> wrote:
> Hi Yassine,
>
> thanks for your patch!
>
> On Sat, May 30, 2026 at 4:58 PM Yassine Oudjana
> <yassine.oudjana@gmail.com> wrote:
>
> > From: Yassine Oudjana <y.oudjana@protonmail.com>
> >
> > Add a driver for the MediaTek MT6735 SoC pin controller. This driver
> > also supports the pin controller on MT6735M, which lacks 6 physical
> > pins (198-203) used for MSDC2 on MT6735.
> >
> > Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
>
> Sashiko has good comments on this driver, look into them!
Didn't receive any comments and I don't see anything on the mailing list
archives either. Am I missing something?
>
> > +config PINCTRL_MT6735
> > + bool "MediaTek MT6735(M) pin control"
> > + depends on OF
> > + default ARM64 && ARCH_MEDIATEK
> > + select PINCTRL_MTK_PARIS
>
> There are in-flight patches to make MTK drivers tristate for
> the Android GKI. Do you want to use tristate for this driver too?
Sure, doesn't matter much to me since I'm always compiling it as built-in.
^ permalink raw reply
* Re: [PATCH v1 1/2] ASoC: dt-bindings: qcom,sm8250: add Shikra sound card compatibles
From: Krzysztof Kozlowski @ 2026-06-13 10:34 UTC (permalink / raw)
To: Ajay Kumar Nandam
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel, Mohammad Rafi Shaik
In-Reply-To: <20260611112946.954172-2-ajay.nandam@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 04:59:45PM +0530, Ajay Kumar Nandam wrote:
> Add Shikra sound-card compatible strings to the Qualcomm sound card
> binding so DT can describe board-specific audio topologies:
>
> - qcom,shikra-cqm-sndcard
> - qcom,shikra-cqs-sndcard
> - qcom,shikra-iqs-sndcard
>
> Shikra EVK variants use different codec/interface combinations and DSP
> processing paths. Describing these variants explicitly in DT allows the
> machine driver to select the correct DAPM routes, controls, and clocking
> behavior for each board.
>
> Co-developed-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
From: Krzysztof Kozlowski @ 2026-06-13 10:40 UTC (permalink / raw)
To: Biju
Cc: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, devicetree,
linux-kernel, linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260612143048.317907-2-biju.das.jz@bp.renesas.com>
On Fri, Jun 12, 2026 at 03:30:29PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add device tree binding support for the RZ/G3L (r9a08g046) USB PHY
> controller. The RZ/G3L USB PHY block is similar to RZ/G3S, but each port
> has an OTG controller, unlike RZ/G3S, which has an OTG controller only on
> port 1.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> .../reset/renesas,rzg2l-usbphy-ctrl.yaml | 20 ++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> index c83469a1b379..788e467b38db 100644
> --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> @@ -23,6 +23,7 @@ properties:
> - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
> - const: renesas,rzg2l-usbphy-ctrl
> - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
> + - const: renesas,r9a08g046-usbphy-ctrl # RZ/G3L
These last two should be just enum, by convention.
>
> reg:
> maxItems: 1
> @@ -50,6 +51,12 @@ properties:
> $ref: /schemas/regulator/regulator.yaml#
> unevaluatedProperties: false
>
> + regulator1-vbus:
> + type: object
> + description: Port 2 USB VBUS regulator
> + $ref: /schemas/regulator/regulator.yaml#
> + unevaluatedProperties: false
Instead group them under 'regulators' node and use names matching the
datasheet.
> +
> renesas,sysc-pwrrdy:
> description:
> The system controller PWRRDY indicates to the USB PHY if the power supply
> @@ -78,7 +85,9 @@ allOf:
> properties:
> compatible:
> contains:
> - const: renesas,r9a08g045-usbphy-ctrl
> + enum:
> + - renesas,r9a08g045-usbphy-ctrl
> + - renesas,r9a08g046-usbphy-ctrl
> then:
> required:
> - renesas,sysc-pwrrdy
> @@ -86,6 +95,15 @@ allOf:
> properties:
> renesas,sysc-pwrrdy: false
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r9a08g046-usbphy-ctrl
> + then:
> + required:
> + - regulator1-vbus
else:
properties:
regulators: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 02/11] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3L PHY bindings
From: Krzysztof Kozlowski @ 2026-06-13 10:40 UTC (permalink / raw)
To: Biju
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Neil Armstrong,
Yoshihiro Shimoda, linux-phy, devicetree, linux-kernel,
linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260612143048.317907-3-biju.das.jz@bp.renesas.com>
On Fri, Jun 12, 2026 at 03:30:30PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add device tree binding support for the RZ/G3L (r9a08g046) USB2 PHY.
> The RZ/G3L USB PHY is almost identical to the RZ/G3S USB PHY, the
> difference being 2 OTG blocks on RZ/G3L compared to 1 on RZ/G3S.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mfd: Add UGREEN NASync DH2300 MCU
From: Krzysztof Kozlowski @ 2026-06-13 10:44 UTC (permalink / raw)
To: Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Heiko Stuebner, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260612-dh2300-mcu-v1-2-ab8db1617bc0@flipper.net>
On Fri, Jun 12, 2026 at 07:34:15PM +0400, Alexey Charkov wrote:
> Document the UGREEN NASync DH2300 embedded controller (HC32F005 MCU),
> which is responsible for gating the SATA drive-bay power rail and
> providing a hardware watchdog.
>
> This is based on disassebly of a GPL binary from vendor firmware for which
> no source code could be found, so parts of it can be inaccurate. Only
> the power gating function is confirmed.
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> .../devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml | 62 ++++++++++++++++++++++
> MAINTAINERS | 5 ++
> 2 files changed, 67 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml b/Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
> new file mode 100644
> index 000000000000..847970c609cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
Place it in embedded-controller
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ugreen,dh2300-mcu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: UGREEN NASync DH2300 embedded controller
> +
> +maintainers:
> + - Alexey Charkov <alchark@flipper.net>
> +
> +description:
> + The UGREEN NASync DH2300 NAS carries a HC32F005 microcontroller on I2C that
> + acts as a board embedded controller. It gates power to the SATA drive bays
> + through an internal register and apparently also serves as a watchdog
> + (unconfirmed, as vendor kernel sources are unavailable, works without it)
> +
> +properties:
> + compatible:
> + const: ugreen,dh2300-mcu
> +
> + reg:
> + maxItems: 1
> +
> + regulator:
This should have specific name matching the actual regulator name, e.g.
pin.
> + type: object
> + $ref: /schemas/regulator/regulator.yaml#
> + unevaluatedProperties: false
> + description:
> + The SATA drive-bay power gate controlled by the MCU.
> +
> + watchdog-gpios:
> + description:
> + Optional GPIO line used to ping the hardware watchdog function of the MCU
> + maxItems: 1
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/4] dt-bindings: wire style checker into dt_binding_check
From: Nicolas Schier @ 2026-06-13 9:58 UTC (permalink / raw)
To: Daniel Golle
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Saravana Kannan, Ping-Ke Shih, Andy Shevchenko, David Sterba,
Bryan O'Donoghue, Hariharan Basuthkar, Jeff Hugo,
Filipe Manana, Bitterblue Smith, Wei Yang, Takashi Iwai,
Aurabindo Pillai, Chih-Kang Chang, David Lechner, Miguel Ojeda,
Gary Guo, Tamir Duberstein, Thomas Weißschuh,
Pagadala Yesu Anjaneyulu, Bartosz Golaszewski,
Jorge Ramirez-Ortiz, Masahiro Yamada, Guenter Roeck,
Aleksander Jan Bajkowski, Boris Burkov, Blake Jones,
Jonathan Corbet, Mauro Carvalho Chehab, devicetree, linux-kernel,
linux-kbuild
In-Reply-To: <a14fdbded0acdc4fef1c1278100f2f4c6a93a488.1779908995.git.daniel@makrotopia.org>
On Wed, May 27, 2026 at 08:32:26PM +0100, Daniel Golle wrote:
> Run dt-check-style as part of dt_binding_check_one. The recipe wraps
> the tool with scripts/jobserver-exec so worker count follows the GNU
> make jobserver -- `make -j N dt_binding_check` constrains the checker
> to N workers rather than spawning one per CPU.
>
> Default mode (relaxed) is zero-violation on the current tree, so this
> does not introduce new warnings into make dt_binding_check. Stricter
> rules are available via --mode=strict (eg. for use by checkpatch.pl in
> a future series).
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v5:
> - no change; depends on the new jobserver-exec fix in 2/4 so
> style failures stay visible instead of being cached
>
> v4:
> - build the @argfile with f=$(mktemp) and remove it with rm -f
> (matching cmd_mk_schema), instead of Kbuild's $(tmp-target)
> which leaves a stale .tmp_.dt-style.checked in the build tree
>
> v3:
> - use Kbuild's $(tmp-target) instead of mktemp so build output
> stays inside the build folder (Nathan)
> - collapse the conditional cleanup tail into the familiar
> "&& touch $@ || true" pattern, matching cmd_chk_bindings;
> keeps future warnings non-fatal (Rob, Nathan)
> - retained the explicit $(PYTHON3) prefix (Rob asked why it
> differs from the rest of this Makefile): per
> Documentation/kbuild/makefiles.rst "Script invocation",
> in-tree scripts should be called through their interpreter so
> the executable bit and shebang are not relied on and the
> user's $(PYTHON3) override is respected. The neighbouring
> recipes invoke their Python helpers directly because those
> come from external packages (dtschema's dt-extract-*,
> dt-check-compatible, dt-doc-validate), which is the case Rob
> asked about and which sits outside that rule.
>
> v2:
> - dropped xargs -n200 -P$(nproc) sharding; single Python invocation
> with file list via @argfile
> - dropped `|| true`: relaxed mode is zero-output today
> - wrapped under scripts/jobserver-exec so worker count follows the
> make jobserver
>
> Documentation/devicetree/bindings/Makefile | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
> index 7b668f7fd400..00149e824261 100644
> --- a/Documentation/devicetree/bindings/Makefile
> +++ b/Documentation/devicetree/bindings/Makefile
> @@ -46,6 +46,18 @@ quiet_cmd_chk_bindings = CHKDT $(src)
> xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(src)) \
> && touch $@ || true
>
> +DT_CHK_STYLE = $(srctree)/scripts/dtc/dt-check-style
> +
> +# Feed the file list to the checker via @argfile in a single Python
> +# process so the ruamel.yaml import is paid once. scripts/jobserver-exec
> +# claims slots from the GNU make jobserver and exposes the count via
> +# $PARALLELISM, which dt-check-style picks up to size its worker pool.
> +quiet_cmd_chk_style = STYLE $(src)
> + cmd_chk_style = f=$$(mktemp) && $(find_cmd) > $$f && \
> + $(PYTHON3) $(srctree)/scripts/jobserver-exec \
> + $(PYTHON3) $(DT_CHK_STYLE) @$$f \
> + && touch $@ || true; rm -f $$f
As usage of $(mktemp) requires an unconditional 'rm -f $$f', too, I'd
like to repeat Nathans suggestion to use Kbuild's $(tmp-target) instead.
The rationale, as Nathan wrote, is to keep generated files within the
build tree.
--
Nicolas
^ permalink raw reply
* Re: [PATCH v4 7/7] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Jernej Škrabec @ 2026-06-13 11:01 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-8-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:21 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> Add initial support for both the Helper and Core boards, including UART,
> PMU, eMMC, USB, Ethernet, LRADC-connected buttons.
>
> UART1 can only be used for Bluetooth module, but BT-WiFi combo Allwinner
> AW869A chip has no mainline driver currently.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Schema validation passes, so:
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
From: Jernej Škrabec @ 2026-06-13 11:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Maxime Ripard, Lukas Schmid
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260606205452.2386930-4-lukas.schmid@netcube.li>
Dne sobota, 6. junij 2026 ob 22:54:43 Srednjeevropski poletni čas je Lukas Schmid napisal(a):
> NetCube Systems OpenNMC is an open replacement for APC SmartSlot Management
> Cards. It is based on the Nagami System-on-Module. It breaks out the
> following interfaces:
>
> - 10/100 Mbps Ethernet
> - USB Type-C OTG using a TUSB320 (usb0)
> - USB Type-C Console Port using a CH340 (uart3)
> - USB Type-A Host with internal CH334 USB-Hub (usb1)
> - MicroSD Slot with Card-Detect (mmc0)
> - WiFi/Bluetooth using the modules built-in ESP32
> - SmartSlot serial interface (uart4)
> - DS3232 RTC with CR1220 Battery Backup
> - Extension connector providing SPI,I2C,USB,CAN,UART for future use.
>
> Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
DT Check passes, so:
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Gaurav Kohli @ 2026-06-13 11:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <fcf93e0f-a2f0-4070-86ec-8a34e9344b76@kernel.org>
On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
> On 12/06/2026 15:52, Gaurav Kohli wrote:
>>
>>
>> On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
>>> On 11/06/2026 13:12, Gaurav Kohli wrote:
>>>>> Why? And where is this generic property defined? You cannot just
>>>>> sprinkle generic properties in random bindings.
>>>>>
>>>>
>>>> Ack, will add why part.
>>>> These names are matched with the thermal mitigation device identifiers
>>>> populated by remote firmware over QMI and define mitigation devices are
>>>> exposed as cooling devices.
>>>
>>> No, -names correspond to values passed via DT, not some remote firmware.
>>> The remote firmware should give you interface which is explicit and does
>>> not need such properties.
>>
>> thanks Krzysztof for review, We need tmd-names because of following reasons:
>>
>> Following Daniel's series [1], the thermal framework supports
>> mapping multiple cooling devices per remoteproc/device via indexed
>> cooling-cells.
>>
>> 1) The thermal framework's cooling-maps reference
>> cooling devices by index (for #cooling-cells = <3>). Without tmd-names,
>> there's no way to know which index corresponds to which TMD, as firmware
>> may return tmd-names in any order.
>>
>> below are the changes post new thermal mapping changes:
>> DT: tmd-names = "cdsp_sw", "xyz";
>> Firmware: ["cdsp_sw", "xyz1", "xyz2",]
>> Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
>
> names property are not to instruct drivers to register or not to
> register something.
>
> I don't understand the problem and explanation in the binding is
> basically non-existing.
>
> Remember that all lists and indices ARE FIXED, so driver knows exactly
> which index means what.
>
thanks for review, shall i use driver data, which is basically pas data
structure like below:
static const struct qcom_pas_data {
.crash_reason_smem = 601,
.firmware_name = "cdsp.mdt",
.tmd_names = (const char *[]){"xyz", NULL},
.num_tmds = 1,
Is something like above acceptable? and this will also help to filter
tmd names as well?
>
>>
>> This allows cooling-maps like below:
>> cooling-device = <&remoteproc 0 ...> // "cdsp_sw"
>> cooling-device = <&remoteproc 1 ...> // "xyz"
>>
>> 2) Not all firmware-provided TMDs should be
>> exposed as cooling devices. The tmd-names property acts as a filter,
>> allowing board-specific DT to select only the relevant TMDs for that
>> platform.
>
> And driver filters, no need for DT property.
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 9/9] Input: cap11xx - add support for CAP1114
From: Jun Yan @ 2026-06-13 11:12 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260612074238.4C3371F000E9@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 4 potential issue(=
> s) to consider:
> - [High] Buffer overflow when parsing the 'microchip,calib-sensitivity' dev=
> ice tree property for devices with more than 8 channels.
> - [Medium] Integer truncation silently drops signal guard configurations fo=
> r channels 8-13.
> - [Low] Out-of-bounds `GENMASK` generates an 11-bit mask for an 8-bit LED c=
> ontrol register.
> - [Low] Unnecessary 9th threshold register added to regmap defaults.
> --
>
> commit a843fc20f78c2766e479b33ffb3dcd6238d1f3f0
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> Input: cap11xx - add support for CAP1114
>
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support. The CAP1114 uses two control registers
> for LED output management and requires two button status registers
> for touch input state reporting.
>
> > diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/ca=
> p11xx.c
> > index d45bb231d7a1f..e4da0e26c34a8 100644
> > --- a/drivers/input/keyboard/cap11xx.c
> > +++ b/drivers/input/keyboard/cap11xx.c
> [ ... ]
> > @@ -98,6 +105,9 @@ static const struct reg_default cap11xx_reg_defaults[]=
> =3D {
> > { CAP11XX_REG_SENSOR_THRESH(3), 0x40 },
> > { CAP11XX_REG_SENSOR_THRESH(4), 0x40 },
> > { CAP11XX_REG_SENSOR_THRESH(5), 0x40 },
> > + { CAP11XX_REG_SENSOR_THRESH(6), 0x40 },
> > + { CAP11XX_REG_SENSOR_THRESH(7), 0x40 },
> > + { CAP11XX_REG_SENSOR_THRESH(8), 0x40 },
>
> [Severity: Low]
> Does this code inadvertently add a 9th threshold register?
>
> Since the indexing is 0-based, an 8-threshold device should only need indic=
> es
> 0 through 7.
>
> Register index 8 appears to map to an unused register.
Good catch, CAP11XX_REG_SENSOR_THRESH(8) should be dropped.
>
> > { CAP11XX_REG_CONFIG2, 0x40 },
> > };
> [ ... ]
> > @@ -394,6 +442,14 @@ static int cap11xx_init_leds(struct device *dev,
> > if (error)
> > return error;
> > =20
> > + if (num_leds > 8) {
> > + error =3D regmap_update_bits(priv->regmap,
> > + priv->model->led_output_control_reg_base + 1,
> > + GENMASK(num_leds - 8 - 1, 0), 0);
>
> [Severity: Low]
> Can this result in an out-of-bounds mask generation when num_leds > 8?
>
> In cap11xx_init_leds() just prior to this addition, the code calls:
>
> error =3D regmap_update_bits(priv->regmap,
> priv->model->led_output_control_reg_base,
> GENMASK(num_leds - 1, 0), 0);
>
> When num_leds is 11 for the CAP1114 model, this generates an 11-bit mask
> to update an 8-bit register.
>
> While the regmap core safely masks this, should the mask be clamped to
> min(num_leds, 8) to accurately reflect the hardware register's capacity?
Agreed, thanks for the correction.
>
> > + if (error)
> > + return error;
> > + }
> [ ... ]
> > @@ -572,6 +628,14 @@ static const struct cap11xx_hw_model cap1106_model =
> =3D {
> > .has_repeat_en =3D true,
> > };
> > =20
> > +static const struct cap11xx_hw_model cap1114_model =3D {
> > + .product_id =3D 0x3a,
> > + .num_channels =3D 14, .num_leds =3D 11, .num_sensor_thresholds =3D 8,
>
> [Severity: High]
> Does this code overflow the calib_sensitivities array during initialization?
>
> In struct cap11xx_priv, the array is rigidly sized to 8 elements:
>
> u32 calib_sensitivities[8];
> u32 keycodes[];
>
> During cap11xx_init_keys(), when parsing "microchip,calib-sensitivity", the
> driver reads priv->model->num_channels elements:
>
> of_property_read_u32_array(node, "microchip,calib-sensitivity",
> priv->calib_sensitivities,
> priv->model->num_channels)
>
> With num_channels set to 14, won't this write 14 elements into an 8-element
> array, clobbering the adjacent keycodes flexible array member and potential=
> ly
> causing memory corruption or a kernel panic?
Good point, I'll fix that in v3.
>
>
> [Severity: Medium]
> Will this configuration lead to integer truncation when parsing the
> "microchip,signal-guard" property?
>
> In struct cap11xx_priv, the mask is defined as an 8-bit value:
>
> u8 signal_guard_inputs_mask;
>
> During cap11xx_init_keys(), a loop iterates up to num_channels (14) and shi=
> fts
> the bits:
>
> priv->signal_guard_inputs_mask |=3D 0x01 << i;
>
> For channels 8 to 13, won't this bitwise shift exceed the 8-bit variable wi=
> dth
> and silently truncate to 0?
Good point, I'll fix that in v3.
>
> Even if the CAP1114 doesn't support signal guards, this drops the bitmask f=
> or
> the upper channels, bypassing the capability check and failing to emit the
> intended 'unsupported' warning.
>
> > + .led_output_control_reg_base =3D CAP1114_REG_LED_OUTPUT_CONTROL1,
> > + .sensor_input_reg_base =3D CAP1114_REG_BUTTON_STATUS1,
> > + .has_grouped_sensors =3D true,
> > +};
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260612072237.1177=
> 304-1-jerrysteve1101@gmail.com?part=3D9
>
^ permalink raw reply
* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Atanas Filipov @ 2026-06-13 11:16 UTC (permalink / raw)
To: Bryan O'Donoghue, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <f754c28c-2d0f-4e10-b542-37eca70b091e@kernel.org>
Thank you for the detailed explanation. Let me share my understanding of
the shared upper-level blocks. They are exactly the reason we have
frameworks like ICC with aggregate bandwidth voting, reference counting
in the clock framework, and so on — the same applies to power domains. I
do not think using shared resources is a problem when the drivers are
correctly designed.
We have actually validated this: we got CAMSS working alongside the
Qualcomm downstream camera stack after fixing the shared resource
management — something everyone considered nearly impossible at the time.
On the CAMNOC and CPAS concern: if that coordination becomes necessary,
the right fix is to address the resource management in both drivers
independently, using the aggregate capabilities of the existing
frameworks — not to introduce a
hierarchical dependency between them. Moving JPEG under CAMSS does not
solve the CAMNOC, clock and power domain coordination problems, it just
papers over them.
IMO the problem you are pointing at is more general than just CAMNOC — I
would add priorities, QoS and other shared resources to the list as
well. The answer to all of them is the same: correct use of the existing
frameworks, not driver
merging.
On the idea of putting JPEG inside CAMSS with an external API: CAMSS has
no engine or pipeline that produces YUV output, which is what the JPEG
encoder needs as input. If JPEG moves into CAMSS without an external
API, it becomes
inaccessible to userspace. If it does expose one, we end up with a
standalone interface anyway, just with an extra layer of indirection on top.
afilipov
On 6/13/2026 12:52 PM, Bryan O'Donoghue wrote:
> On 13/06/2026 10:24, Atanas Filipov wrote:
>> Thank you for the feedback. I understand the reasoning, but I
>> respectfully disagree with this approach for the following reasons.
>>
>> While it is true that the JPEG encoder shares the same camera NOC and
>> power domain infrastructure as CAMSS, that is a hardware topology detail
>> — not a sufficient justification for imposing a software dependency. The
>> driver is a fully
>> self-contained V4L2 mem2mem encoder, implemented like every other JPEG
>> encoder driver currently in the kernel (imx-jpeg, s5p-jpeg, mtk-jpeg,
>> nxp-jpeg). None of those are sub-nodes of a parent ISP or camera
>> subsystem driver.
>
> That's a backwards understanding of the ethos of DT, which is to
> describe hardware architecture, to describe hardware, not to subscribe
> to or proscribe a particular software architecture.
>
> Those jpeg blocks are standalone, whereas the CAMSS jpeg encoder lives
> inside of the CAMSS power-island.
>> Making the JPEG encoder a sub-node of camss would introduce an
>> unnecessary and artificial coupling: the JPEG encoder cannot be probed,
>> built, or used independently of the CAMSS driver, even on platforms
>> where CAMSS is disabled. This directly contradicts the kernel's
>> principle of independent, single-purpose drivers.
>
> - Probed true
> - Built true
> - Used untrue
>
> Once probed your current driver can chug along pretty much unperturbed,
> however I don't believe that statement can hold true as more of the
> camera hardware gets enabled.
>> The shared hardware resources (clocks, interconnects, IOMMU stream IDs,
>> power domain) are already fully described in the device tree node and
>> handled by the standard kernel frameworks — there is no functional
>> reason to nest the node under camss.
>
> Except that it is a real description of the hardware. "We can model it
> separately != we have modeled it correctly".
>
> And at least one thing you are leaving out here is the cam noc - which
> eventually we will have to start to enable and will almost certainly
> have to be controlled by the core driver which also owns the power-
> collapse and muxes, the thing that will also program CPAs - the core
> CAMSS driver.
>
> Perhaps we choose to model that NOC as a separate driver or perhaps we
> expose an API in CAMSS to vote, either way its an intrinsic part of the
> voltage and clocks in this block.
>
> Either way sure we could model it as a fully separate node but, that is
> not really how/where the block lives. It lives inside of a defined CAMSS
> block, which is its own power-island.
>
> Switching on the JPEG part of it by inference switches on the top-level
> of the island so, its not separate at all.
>> For these reasons I would prefer to keep the JPEG encoder as a
>> standalone platform device with its own DT node, consistent with how all
>> comparable JPEG encoder drivers are structured in the kernel today.
>>
>> afilipov
>>
>> On 6/13/2026 2:14 AM, Bryan O'Donoghue wrote:
>>> On 12/06/2026 20:44, Atanas Filipov wrote:
>>>> + qcom_jpeg_enc: jpeg-encoder@ac4e000 {
>>>
>>> One key bit of review feedback I gave in the previous leaked version of
>>> this driver is that since the jpeg-encoder is part of the CAMSS block it
>>> should be a sub-node of camss as OPE, CSIPHY and other blocks will be.
>>>
>>> Please take that feedback onboard in your v2.
>>>
>>> ---
>>> bod
>>
>>
>
> And please no top posting !
>
> ---
> bod
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: Jonathan Cameron @ 2026-06-13 11:18 UTC (permalink / raw)
To: Sirat
Cc: robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy, linux-iio,
devicetree, linux-kernel
In-Reply-To: <CANn+LW+OSfo3u+7wZu11j7tQd-PGyhrz3a9+st-FwjOLbT4NBw@mail.gmail.com>
On Sat, 13 Jun 2026 14:57:42 +0600
Sirat <email@sirat.me> wrote:
> On Fri, Jun 12, 2026 at 10:30 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Fri, 12 Jun 2026 18:45:26 +0600
> > Siratul Islam <email@sirat.me> wrote:
> >
> > > Add devicetree binding for the QST QMC5883L 3-Axis Magnetic Sensor
> > > connected via i2c.
> > > Interrupt not implemented in driver but kept in the binding for future
> > > addition.
> > No need to mention that
> Got it. In the past I was advised to mention certain choices in the
> commit message. I am still looking for the balance.
Sure. Generally dt-bindings should never mention the driver.
Despite being in the kernel tree they are not tightly coupled with
the drivers and indeed are pulled into other projects.
Jonathan
> >
> > The rest looks good to me.
> >
> > Thanks,
> >
> > Jonathan
> >
> Thanks
> Sirat
^ permalink raw reply
* [PATCH net-next 0/8] net: mdio: realtek-rtl9300: Add RTL83xx support
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
The Realtek Otto switch platform consists of four different series
- RTL838x aka maple : 28 port 1G Switches
- RTL839x aka cypress : 52 port 1G Switches
- RTL930x aka longan : 28 port 1G/2.5G/10G Switches
- RTL931x aka mango : 56 port 1G/2.5G/10G Switches
While there always was a good knowledge about the MDIO hardware
polling unit and its necessity for the MAC layer, there was no
detailed documentation available. For this series the MDIO bus was
inspected with a logic analyzer for a better understanding how
polling and kernel access interact on the bus. All this is now
explained in the driver comments.
This patch series adds support for the RTL83xx devices. For this
- Enhance device tree binding.
- Add special handling for limitations enforced by hardware polling.
These already have minor side effects on RTL93xx devices but are even
more critical for the RTL83xx hardware.
- Add RTL83xx coding.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
Markus Stockhausen (8):
dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series
net: mdio: realtek-rtl9300: Add polling documentation
net: mdio: realtek-rtl9300: Add page tracking
net: mdio: realtek-rtl9300: Configure hardware polling during probing
net: mdio: realtek-rtl9300: Add c45 over c22 mitigation
net: mdio: realtek-rtl9300: Increase MDIO timeout
net: mdio: realtek-rtl9300: Add support for RTL838x
net: mdio: realtek-rtl9300: Add support for RTL839x
.../bindings/net/realtek,rtl9301-mdio.yaml | 12 +
drivers/net/mdio/mdio-realtek-rtl9300.c | 399 +++++++++++++++++-
2 files changed, 398 insertions(+), 13 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH net-next 3/8] net: mdio: realtek-rtl9300: Add page tracking
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
In-Reply-To: <20260613112946.1071411-1-markus.stockhausen@gmx.de>
The hardware polling unit of the Realtek switches has a very special
handling for PHY register 31 (aka Realtek page register) in place.
- On the RTL838x it is permanently reset to zero.
- On other devices there is some magic saving/restoring (aka parking)
in the background in place.
This makes access to PHYs a gamble.
As of now all known existing hardware designs have Realtek based 1G PHYs.
Otherwise the polling engine and the MAC status update will not work at
all and the vendor SDK would fail totally.
This driver differentiates clearly between c22 and c45 buses. During
probing it enables only one of the protocols for a bus. So it is safe
to assume that any c22 access will only target a Realtek based 1G PHY.
Intercept access to register 31 and store the desired value for each port
in the driver. When issuing access to other registers add the saved page.
This given, the hardware will run two consecutive c22 commands that are
not interrupted by polling.
... hardware poll ...
phy_write(phy, 31, page)
phy_write(phy, reg, value)
... hardware poll ...
Remark! To keep this simple, writes to register 31 are only accepted
if they are lower than the device specific raw page - 0..4094/8190.
Otherwise -EINVAL is returned. Under the above assumption (Only 1G
Realtek PHYs on c22 bus) this is no limitation.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
drivers/net/mdio/mdio-realtek-rtl9300.c | 32 +++++++++++++++++--------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
index da2864c94d2c..c3a9eeca3154 100644
--- a/drivers/net/mdio/mdio-realtek-rtl9300.c
+++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
@@ -193,6 +193,7 @@ struct otto_emdio_priv {
struct regmap *regmap;
struct mutex lock; /* protect HW access */
DECLARE_BITMAP(valid_ports, MAX_PORTS);
+ u16 page[MAX_PORTS];
u8 smi_bus[MAX_PORTS];
u8 smi_addr[MAX_PORTS];
bool smi_bus_is_c45[MAX_SMI_BUSSES];
@@ -337,7 +338,7 @@ static int otto_emdio_9300_read_c22(struct mii_bus *bus, int port, int regnum, u
struct otto_emdio_cmd_regs cmd_data = {
.c22_data = FIELD_PREP(RTL9300_PHY_CTRL_REG_ADDR, regnum) |
FIELD_PREP(RTL9300_PHY_CTRL_PARK_PAGE, 0x1f) |
- FIELD_PREP(RTL9300_PHY_CTRL_MAIN_PAGE, RAW_PAGE(priv)),
+ FIELD_PREP(RTL9300_PHY_CTRL_MAIN_PAGE, priv->page[port]),
.io_data = FIELD_PREP(RTL9300_PHY_CTRL_INDATA, port),
};
@@ -351,7 +352,7 @@ static int otto_emdio_9300_write_c22(struct mii_bus *bus, int port, int regnum,
struct otto_emdio_cmd_regs cmd_data = {
.c22_data = FIELD_PREP(RTL9300_PHY_CTRL_REG_ADDR, regnum) |
FIELD_PREP(RTL9300_PHY_CTRL_PARK_PAGE, 0x1f) |
- FIELD_PREP(RTL9300_PHY_CTRL_MAIN_PAGE, RAW_PAGE(priv)),
+ FIELD_PREP(RTL9300_PHY_CTRL_MAIN_PAGE, priv->page[port]),
.io_data = FIELD_PREP(RTL9300_PHY_CTRL_INDATA, value),
.port_mask_low = BIT(port),
};
@@ -391,7 +392,7 @@ static int otto_emdio_9310_read_c22(struct mii_bus *bus, int port, int regnum, u
struct otto_emdio_cmd_regs cmd_data = {
.broadcast = FIELD_PREP(RTL9310_BC_PORT_ID, port),
.c22_data = FIELD_PREP(RTL9310_PHY_CTRL_REG_ADDR, regnum) |
- FIELD_PREP(RTL9310_PHY_CTRL_MAIN_PAGE, RAW_PAGE(priv)),
+ FIELD_PREP(RTL9310_PHY_CTRL_MAIN_PAGE, priv->page[port]),
};
return otto_emdio_read_cmd(bus, RTL9310_PHY_CTRL_TYPE_C22, &cmd_data,
@@ -403,7 +404,7 @@ static int otto_emdio_9310_write_c22(struct mii_bus *bus, int port, int regnum,
struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
struct otto_emdio_cmd_regs cmd_data = {
.c22_data = FIELD_PREP(RTL9310_PHY_CTRL_REG_ADDR, regnum) |
- FIELD_PREP(RTL9310_PHY_CTRL_MAIN_PAGE, RAW_PAGE(priv)),
+ FIELD_PREP(RTL9310_PHY_CTRL_MAIN_PAGE, priv->page[port]),
.io_data = FIELD_PREP(RTL9310_PHY_CTRL_INDATA, value),
.port_mask_high = (u32)(BIT_ULL(port) >> 32),
.port_mask_low = (u32)(BIT_ULL(port)),
@@ -442,15 +443,19 @@ static int otto_emdio_9310_write_c45(struct mii_bus *bus, int port,
static int otto_emdio_read_c22(struct mii_bus *bus, int phy_id, int regnum)
{
struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
- int ret, port;
+ int port, ret = 0;
u32 value;
port = otto_emdio_phy_to_port(bus, phy_id);
if (port < 0)
return port;
- scoped_guard(mutex, &priv->lock)
+ scoped_guard(mutex, &priv->lock) {
+ if (regnum == 31)
+ return priv->page[port];
+
ret = priv->info->read_c22(bus, port, regnum, &value);
+ }
return ret ? ret : value;
}
@@ -458,16 +463,23 @@ static int otto_emdio_read_c22(struct mii_bus *bus, int phy_id, int regnum)
static int otto_emdio_write_c22(struct mii_bus *bus, int phy_id, int regnum, u16 value)
{
struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
- int ret, port;
+ int port;
port = otto_emdio_phy_to_port(bus, phy_id);
if (port < 0)
return port;
- scoped_guard(mutex, &priv->lock)
- ret = priv->info->write_c22(bus, port, regnum, value);
+ scoped_guard(mutex, &priv->lock) {
+ if (regnum == 31) {
+ if (value >= RAW_PAGE(priv))
+ return -EINVAL;
- return ret;
+ priv->page[port] = value;
+ return 0;
+ }
+
+ return priv->info->write_c22(bus, port, regnum, value);
+ }
}
static int otto_emdio_read_c45(struct mii_bus *bus, int phy_id, int dev_addr, int regnum)
--
2.54.0
^ permalink raw reply related
* [PATCH net-next 7/8] net: mdio: realtek-rtl9300: Add support for RTL838x
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
In-Reply-To: <20260613112946.1071411-1-markus.stockhausen@gmx.de>
The MDIO driver has been prepared for multiple device support. Add all
required bits for the RTL838x (aka maple) series. This is straightforward
but some things are worth mentioning.
- The device has a lot in common with the RTL930x series. 28 ports, 4096
(Realtek) pages, 4 MMIO registers
- The MDIO engine has no fail bit. Thus the mask is set to zero
- There is only one SMI bus for 1G PHYs. No bus_map_base register exists.
- The setup_controller() function needs no c45 setup but must activate
the PHY access.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
drivers/net/mdio/mdio-realtek-rtl9300.c | 109 ++++++++++++++++++++++++
1 file changed, 109 insertions(+)
diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
index 244af5fdeaf3..d9ff0b0aecbb 100644
--- a/drivers/net/mdio/mdio-realtek-rtl9300.c
+++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
@@ -117,6 +117,28 @@
#include <linux/property.h>
#include <linux/regmap.h>
+#define RTL8380_NUM_BUSES 1
+#define RTL8380_NUM_PAGES 4096
+#define RTL8380_NUM_PORTS 28
+#define RTL8380_SMI_GLB_CTRL 0xa100
+#define RTL8380_SMI_PHY_PATCH_DONE BIT(15)
+#define RTL8380_SMI_ACCESS_PHY_CTRL_0 0xa1b8
+#define RTL8380_SMI_ACCESS_PHY_CTRL_1 0xa1bc
+#define RTL8380_PHY_CTRL_REG_ADDR GENMASK(24, 20)
+#define RTL8380_PHY_CTRL_PARK_PAGE GENMASK(19, 15)
+#define RTL8380_PHY_CTRL_MAIN_PAGE GENMASK(14, 3)
+#define RTL8380_PHY_CTRL_WRITE BIT(2)
+#define RTL8380_PHY_CTRL_READ 0
+#define RTL8380_PHY_CTRL_TYPE_C45 BIT(1)
+#define RTL8380_PHY_CTRL_TYPE_C22 0
+#define RTL8380_PHY_CTRL_FAIL 0 /* no fail indicator */
+#define RTL8380_SMI_ACCESS_PHY_CTRL_2 0xa1c0
+#define RTL8380_PHY_CTRL_INDATA GENMASK(31, 16)
+#define RTL8380_PHY_CTRL_DATA GENMASK(15, 0)
+#define RTL8380_SMI_ACCESS_PHY_CTRL_3 0xa1c4
+#define RTL8380_SMI_POLL_CTRL 0xa17c
+#define RTL8380_SMI_PORT0_5_ADDR_CTRL 0xa1c8
+
#define RTL9300_NUM_BUSES 4
#define RTL9300_NUM_PAGES 4096
#define RTL9300_NUM_PORTS 28
@@ -381,6 +403,60 @@ static int otto_emdio_write_cmd(struct mii_bus *bus, u32 cmd,
return otto_emdio_run_cmd(bus, cmd | priv->info->cmd_write, cmd_data);
}
+static int otto_emdio_8380_read_c22(struct mii_bus *bus, int port, int regnum, u32 *value)
+{
+ struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
+ struct otto_emdio_cmd_regs cmd_data = {
+ .c22_data = FIELD_PREP(RTL8380_PHY_CTRL_REG_ADDR, regnum) |
+ FIELD_PREP(RTL8380_PHY_CTRL_PARK_PAGE, 0x1f) |
+ FIELD_PREP(RTL8380_PHY_CTRL_MAIN_PAGE, priv->page[port]),
+ .io_data = FIELD_PREP(RTL8380_PHY_CTRL_INDATA, port),
+ };
+
+ return otto_emdio_read_cmd(bus, RTL8380_PHY_CTRL_TYPE_C22, &cmd_data,
+ RTL8380_PHY_CTRL_DATA, value);
+}
+
+static int otto_emdio_8380_write_c22(struct mii_bus *bus, int port, int regnum, u16 value)
+{
+ struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
+ struct otto_emdio_cmd_regs cmd_data = {
+ .c22_data = FIELD_PREP(RTL8380_PHY_CTRL_REG_ADDR, regnum) |
+ FIELD_PREP(RTL8380_PHY_CTRL_PARK_PAGE, 0x1f) |
+ FIELD_PREP(RTL8380_PHY_CTRL_MAIN_PAGE, priv->page[port]),
+ .io_data = FIELD_PREP(RTL8380_PHY_CTRL_INDATA, value),
+ .port_mask_low = BIT(port),
+ };
+
+ return otto_emdio_write_cmd(bus, RTL8380_PHY_CTRL_TYPE_C22, &cmd_data);
+}
+
+static int otto_emdio_8380_read_c45(struct mii_bus *bus, int port,
+ int dev_addr, int regnum, u32 *value)
+{
+ struct otto_emdio_cmd_regs cmd_data = {
+ .c45_data = FIELD_PREP(PHY_CTRL_MMD_DEVAD, dev_addr) |
+ FIELD_PREP(PHY_CTRL_MMD_REG, regnum),
+ .io_data = FIELD_PREP(RTL8380_PHY_CTRL_INDATA, port),
+ };
+
+ return otto_emdio_read_cmd(bus, RTL8380_PHY_CTRL_TYPE_C45, &cmd_data,
+ RTL8380_PHY_CTRL_DATA, value);
+}
+
+static int otto_emdio_8380_write_c45(struct mii_bus *bus, int port,
+ int dev_addr, int regnum, u16 value)
+{
+ struct otto_emdio_cmd_regs cmd_data = {
+ .c45_data = FIELD_PREP(PHY_CTRL_MMD_DEVAD, dev_addr) |
+ FIELD_PREP(PHY_CTRL_MMD_REG, regnum),
+ .io_data = FIELD_PREP(RTL8380_PHY_CTRL_INDATA, value),
+ .port_mask_low = BIT(port),
+ };
+
+ return otto_emdio_write_cmd(bus, RTL8380_PHY_CTRL_TYPE_C45, &cmd_data);
+}
+
static int otto_emdio_9300_read_c22(struct mii_bus *bus, int port, int regnum, u32 *value)
{
struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
@@ -615,6 +691,16 @@ static int otto_emdio_setup_topology(struct otto_emdio_priv *priv)
return 0;
}
+static int otto_emdio_8380_setup_controller(struct otto_emdio_priv *priv)
+{
+ /*
+ * PHY_PATCH_DONE enables PHY control via SoC. This is required for PHY access, including
+ * patching and must be set before the PHYs are probed.
+ */
+ return regmap_set_bits(priv->regmap, RTL8380_SMI_GLB_CTRL,
+ RTL8380_SMI_PHY_PATCH_DONE);
+}
+
static int otto_emdio_9300_setup_controller(struct otto_emdio_priv *priv)
{
u32 glb_ctrl_mask = 0, glb_ctrl_val = 0;
@@ -855,6 +941,28 @@ static int otto_emdio_probe(struct platform_device *pdev)
return 0;
}
+static const struct otto_emdio_info otto_emdio_8380_info = {
+ .addr_map_base = RTL8380_SMI_PORT0_5_ADDR_CTRL,
+ .cmd_fail = RTL8380_PHY_CTRL_FAIL,
+ .cmd_read = RTL8380_PHY_CTRL_READ,
+ .cmd_write = RTL8380_PHY_CTRL_WRITE,
+ .cmd_regs = {
+ .c22_data = RTL8380_SMI_ACCESS_PHY_CTRL_1,
+ .c45_data = RTL8380_SMI_ACCESS_PHY_CTRL_3,
+ .io_data = RTL8380_SMI_ACCESS_PHY_CTRL_2,
+ .port_mask_low = RTL8380_SMI_ACCESS_PHY_CTRL_0,
+ },
+ .num_buses = RTL8380_NUM_BUSES,
+ .num_pages = RTL8380_NUM_PAGES,
+ .num_ports = RTL8380_NUM_PORTS,
+ .poll_ctrl = RTL8380_SMI_POLL_CTRL,
+ .setup_controller = otto_emdio_8380_setup_controller,
+ .read_c22 = otto_emdio_8380_read_c22,
+ .read_c45 = otto_emdio_8380_read_c45,
+ .write_c22 = otto_emdio_8380_write_c22,
+ .write_c45 = otto_emdio_8380_write_c45,
+};
+
static const struct otto_emdio_info otto_emdio_9300_info = {
.addr_map_base = RTL9300_SMI_PORT0_5_ADDR_CTRL,
.bus_map_base = RTL9300_SMI_PORT0_15_POLLING_SEL,
@@ -905,6 +1013,7 @@ static const struct otto_emdio_info otto_emdio_9310_info = {
};
static const struct of_device_id otto_emdio_ids[] = {
+ { .compatible = "realtek,rtl8380-mdio", .data = &otto_emdio_8380_info },
{ .compatible = "realtek,rtl9301-mdio", .data = &otto_emdio_9300_info },
{ .compatible = "realtek,rtl9311-mdio", .data = &otto_emdio_9310_info },
{}
--
2.54.0
^ permalink raw reply related
* [PATCH net-next 1/8] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
In-Reply-To: <20260613112946.1071411-1-markus.stockhausen@gmx.de>
The lower end Realtek Otto switches provide 1G only and are divided into
two series:
- Maple : RTL838x up to 28 ports
- Cypress: RTL839x up to 56 ports
The Maple based devices have 3 different SoCs: RTL8380, RTL8381 and
RTL8382. The Cypress series consists of the RTL8391, RTL8392 and
RTL8393 SoCs. The MDIO controller of these switches works like the
existing RTL93xx logic but has different characteristics and different
registers. Add new compatibles in the device tree.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
.../bindings/net/realtek,rtl9301-mdio.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
index 271e05bae9c5..de33364b67ef 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
@@ -12,6 +12,16 @@ maintainers:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - realtek,rtl8381-mdio
+ - realtek,rtl8382-mdio
+ - const: realtek,rtl8380-mdio
+ - items:
+ - enum:
+ - realtek,rtl8392-mdio
+ - realtek,rtl8393-mdio
+ - const: realtek,rtl8391-mdio
- items:
- enum:
- realtek,rtl9302b-mdio
@@ -24,6 +34,8 @@ properties:
- realtek,rtl9313-mdio
- const: realtek,rtl9311-mdio
- enum:
+ - realtek,rtl8380-mdio
+ - realtek,rtl8391-mdio
- realtek,rtl9301-mdio
- realtek,rtl9311-mdio
--
2.54.0
^ permalink raw reply related
* [PATCH net-next 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
In-Reply-To: <20260613112946.1071411-1-markus.stockhausen@gmx.de>
During bus probing the PHYs are initialized and firmware might be
loaded. This often requires complex access sequences where the switch
hardware polling might interfere badly.
The polling can be configured with one or two 32 bit mask registers.
Each bit enables (=1) or disables (=0) the polling of the corresponding
port.
Provide a helper to enable/disable polling for a specific port. With
this disable hardware polling temporarily during bus probing and enable
it afterwards according to the device tree topology. Nice side effect:
This patch brings the hardware polling into a consistent state for
devices where U-Boot does not take care.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
drivers/net/mdio/mdio-realtek-rtl9300.c | 26 ++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
index c3a9eeca3154..a7fd075947b6 100644
--- a/drivers/net/mdio/mdio-realtek-rtl9300.c
+++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
@@ -137,6 +137,7 @@
#define RTL9300_PHY_CTRL_INDATA GENMASK(31, 16)
#define RTL9300_PHY_CTRL_DATA GENMASK(15, 0)
#define RTL9300_SMI_ACCESS_PHY_CTRL_3 0xcb7c
+#define RTL9300_SMI_POLL_CTRL 0xca90
#define RTL9300_SMI_PORT0_5_ADDR_CTRL 0xcb80
#define RTL9310_NUM_BUSES 4
@@ -162,6 +163,7 @@
#define RTL9310_PHY_CTRL_INDATA GENMASK(15, 0)
#define RTL9310_SMI_INDRT_ACCESS_MMD_CTRL 0x0c18
#define RTL9310_SMI_PORT_ADDR_CTRL 0x0c74
+#define RTL9310_SMI_PORT_POLLING_CTRL 0x0ccc
#define RTL9310_SMI_PORT_POLLING_SEL 0x0c9c
#define PHY_CTRL_CMD BIT(0)
@@ -210,6 +212,7 @@ struct otto_emdio_info {
u8 num_buses;
u8 num_ports;
u16 num_pages;
+ u32 poll_ctrl;
int (*setup_controller)(struct otto_emdio_priv *priv);
int (*read_c22)(struct mii_bus *bus, int port, int regnum, u32 *value);
int (*read_c45)(struct mii_bus *bus, int port, int dev_addr, int regnum, u32 *value);
@@ -245,6 +248,12 @@ static struct otto_emdio_priv *otto_emdio_bus_to_priv(struct mii_bus *bus)
return chan->priv;
}
+static int otto_emdio_set_port_polling(struct otto_emdio_priv *priv, int port, bool active)
+{
+ return regmap_assign_bits(priv->regmap, priv->info->poll_ctrl + (port / 32) * 4,
+ BIT(port % 32), active);
+}
+
static int otto_emdio_run_cmd(struct mii_bus *bus, u32 cmd,
struct otto_emdio_cmd_regs *cmd_data)
{
@@ -735,7 +744,7 @@ static int otto_emdio_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct otto_emdio_priv *priv;
- int err;
+ int port, err;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -750,6 +759,13 @@ static int otto_emdio_probe(struct platform_device *pdev)
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
+ /* Avoid issues with complex firmware loads. */
+ for (port = 0; port < priv->info->num_ports; port++) {
+ err = otto_emdio_set_port_polling(priv, port, false);
+ if (err)
+ return err;
+ }
+
platform_set_drvdata(pdev, priv);
err = otto_emdio_map_ports(dev);
@@ -772,6 +788,12 @@ static int otto_emdio_probe(struct platform_device *pdev)
return err;
}
+ for_each_set_bit(port, priv->valid_ports, priv->info->num_ports) {
+ err = otto_emdio_set_port_polling(priv, port, true);
+ if (err)
+ return err;
+ }
+
return 0;
}
@@ -790,6 +812,7 @@ static const struct otto_emdio_info otto_emdio_9300_info = {
.num_buses = RTL9300_NUM_BUSES,
.num_ports = RTL9300_NUM_PORTS,
.num_pages = RTL9300_NUM_PAGES,
+ .poll_ctrl = RTL9300_SMI_POLL_CTRL,
.setup_controller = otto_emdio_9300_setup_controller,
.read_c22 = otto_emdio_9300_read_c22,
.read_c45 = otto_emdio_9300_read_c45,
@@ -815,6 +838,7 @@ static const struct otto_emdio_info otto_emdio_9310_info = {
.num_buses = RTL9310_NUM_BUSES,
.num_pages = RTL9310_NUM_PAGES,
.num_ports = RTL9310_NUM_PORTS,
+ .poll_ctrl = RTL9310_SMI_PORT_POLLING_CTRL,
.setup_controller = otto_emdio_9310_setup_controller,
.read_c22 = otto_emdio_9310_read_c22,
.read_c45 = otto_emdio_9310_read_c45,
--
2.54.0
^ permalink raw reply related
* [PATCH net-next 2/8] net: mdio: realtek-rtl9300: Add polling documentation
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
In-Reply-To: <20260613112946.1071411-1-markus.stockhausen@gmx.de>
Add a detailed explanation how the hardware polling unit in the
Realtek Otto switches works. This simplifies developing future
patches and reviewing them.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
drivers/net/mdio/mdio-realtek-rtl9300.c | 66 +++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
index 892ed3780a65..da2864c94d2c 100644
--- a/drivers/net/mdio/mdio-realtek-rtl9300.c
+++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
@@ -35,6 +35,72 @@
*
* The driver works out the mapping based on the MDIO bus described in device tree and phandles on
* the ethernet-ports property.
+ *
+ * The devices have a hardware polling unit that runs in the background without any CPU load. It
+ * constantly scans the MDIO bus and the attached PHYs and updates the MAC status registers.
+ *
+ * How does the polling work?
+ *
+ * Each device has a SMI_POLL_CTRL register. A per-port bitmask decides if the hardware polling of
+ * the associated bus/address is active or not. The hardware runs a tight loop over this and for
+ * each set polling bit it issues a status check for the PHY. Attaching a logic analyzer to the
+ * MDIO bus of an RTL8380 and RTL8393 gives the following commands (in kernel notation):
+ *
+ * RTL8380 RTL8393
+ * --------------------------- ---------------------------
+ * phy_write(phy, 31, 0x0); phy_read(phy, 0);
+ * phy_write(phy, 13, 0x7); phy_read(phy, 1);
+ * phy_write(phy, 14, 0x3c); phy_read(phy, 4);
+ * phy_write(phy, 13, 0x8007); phy_read(phy, 5);
+ * phy_read(phy, 14); phy_read(phy, 6);
+ * phy_write(phy, 13, 0x7); phy_read(phy, 9);
+ * phy_write(phy, 14, 0x3d); phy_read(phy, 10);
+ * phy_write(phy, 13, 0x8007); phy_read(phy, 15);
+ * phy_read(phy, 14); phy_write(phy, 13, 0x7);
+ * phy_read(phy, 9); phy_write(phy, 14, 0x3c);
+ * phy_read(phy, 10); phy_write(phy, 13, 0x4007);
+ * phy_read(phy, 15); phy_read(phy, 14);
+ * phy_read(phy, 0); phy_write(phy, 13, 0x7);
+ * phy_read(phy, 1); phy_write(phy, 14, 0x3d);
+ * phy_read(phy, 4); phy_write(phy, 13, 0x4007);
+ * phy_read(phy, 5); phy_read(phy, 14);
+ * phy_read(phy, 6);
+ *
+ * The c22 over c45 register 13/14 sequences read MDIO_AN_EEE_ADV and MDIO_AN_EEE_LPABLE. As soon
+ * as one PHY status is read, the polling engine goes over to the next PHY. Basically the bus is
+ * always busy and the MAC status is updated in realtime.
+ *
+ * How does MDIO access from kernel work?
+ *
+ * When issuing MDIO accesses via an MMIO based interface the final write to the command register
+ * sets a "run command now" bit. Between two polling sequences for different PHYs the hardware
+ * checks if a user command needs to run and sends it onto the bus. Afterwards it simply continues
+ * its polling work. Inspecting the command sequence for a paged read on the logic analyzer gives:
+ *
+ * RTL8380 RTL8393
+ * --------------------------- ---------------------------
+ * phy_write(phy, 31, page); phy_write(phy, 31, page);
+ * phy_write(phy, reg, value); phy_write(phy, reg, value);
+ * phy_write(phy, 31, 0);
+ *
+ * What does this mean?
+ *
+ * There are slight differences in polling and PHY access between the models but the challenge
+ * stays the same. On the one hand that greatly simplifies the MAC layer, on the other hand it
+ * has some implications for the kernel PHY subsystem.
+ *
+ * - Without the polling and a proper MAC status, some of the link handling features do not work.
+ * Especially an unpopulated MAC_LINK_STS register cancels operations to other MAC registers.
+ * - The Realtek page register 31 is magically modified in the background. On the RTL838x it is
+ * simply reset. Other devices have hardware mitigations for this in place.
+ * - A c45 over c22 kernel access sequence is most likely to fail because chances are high that
+ * the polling engine overwrites registers 13/14 in between.
+ * - PHY firmware loading can have issues. Especially if a PHY is designed to expect a clean
+ * sequence of registers and values without deviation.
+ * - An access to one PHY will need to wait for the next free slot of the polling engine.
+ *
+ * Conclusion: Kernel access to the PHYs must know and handle any interference that arises from
+ * the above described hardware polling.
*/
#include <linux/bitfield.h>
--
2.54.0
^ permalink raw reply related
* [PATCH net-next 5/8] net: mdio: realtek-rtl9300: Add c45 over c22 mitigation
From: Markus Stockhausen @ 2026-06-13 11:29 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
Cc: Markus Stockhausen
In-Reply-To: <20260613112946.1071411-1-markus.stockhausen@gmx.de>
When reading the PHY state on c22 based buses the hardware polling unit
reads the EEE status with a sequence similar to this:
...
phy_write(phy, 31, 0x0);
phy_write(phy, 13, 0x7); /* c22 over c45 MDIO_AN_EEE_ADV */
phy_write(phy, 14, 0x3c);
phy_write(phy, 13, 0x8007);
phy_read(phy, 14);
phy_write(phy, 13, 0x7); /* c22 over c45 MDIO_AN_EEE_LPABLE */
phy_write(phy, 14, 0x3d);
phy_write(phy, 13, 0x8007);
...
If the Linux kernel wants to do the same in mmd_phy_read() via a call to
mmd_phy_indirect() this most likely fails. The commands are issued in a
straight sequence but between two of them the hardware polling might run
a status check for the same PHY. This effectively breaks the kernel access
and makes use of c45 over c22 unusable.
Detailed analysis shows that for RTL838x, RTL839x and RTL931x polling
can be safely deactivated during operation. The MAC layer will continue
to show the last known state. RTL839x is an exception from this. As soon
as polling is disabled the MAC link status register shows "port down".
Enhance the driver to detect this register 13/14/13/14 access sequence.
Before the first access to register 13 of a PHY disable polling for the
corresponding port. Reenable polling as soon as the sequence is finished
or any other unexpected input is detected. Some details about the stop
and start timing:
- The stopping is issued inflight while the polling engine is working.
After it is finished no new polling for the port will be issued (tested
with only one port with active polling).
- Reenabling the polling engine happens within ~25us after the last
command of the MMD sequence. This is mostly due to MMIO overhead.
Technically speaking, add a simple state machine that increments a
per-port MMD counter for each successful step of the sequence. When the
first command starts (counter=1) stop polling. When the last command
finishes (counter=4) or unexpected data is sent start polling.
Additionally:
- Add a global "initialization done" tracker that stops the mechanism
from kicking in during bus probing.
- Add a global "link flapping" option that allows to disable the state
tracker for the to-be-added RTL839x series completely.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
drivers/net/mdio/mdio-realtek-rtl9300.c | 62 ++++++++++++++++++++++++-
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
index a7fd075947b6..e206ee3e2b1c 100644
--- a/drivers/net/mdio/mdio-realtek-rtl9300.c
+++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
@@ -196,10 +196,12 @@ struct otto_emdio_priv {
struct mutex lock; /* protect HW access */
DECLARE_BITMAP(valid_ports, MAX_PORTS);
u16 page[MAX_PORTS];
+ u8 mmd_state[MAX_PORTS];
u8 smi_bus[MAX_PORTS];
u8 smi_addr[MAX_PORTS];
bool smi_bus_is_c45[MAX_SMI_BUSSES];
struct mii_bus *bus[MAX_SMI_BUSSES];
+ bool init_done;
};
struct otto_emdio_info {
@@ -209,6 +211,7 @@ struct otto_emdio_info {
u32 cmd_read;
u32 cmd_write;
struct otto_emdio_cmd_regs cmd_regs;
+ bool link_flap;
u8 num_buses;
u8 num_ports;
u16 num_pages;
@@ -254,6 +257,43 @@ static int otto_emdio_set_port_polling(struct otto_emdio_priv *priv, int port, b
BIT(port % 32), active);
}
+static int otto_emdio_mmd_prefix(struct otto_emdio_priv *priv, int port, int regnum)
+{
+ u8 newstate, *state = &priv->mmd_state[port];
+ int expected, ret = 0;
+
+ if (!priv->init_done)
+ return 0;
+ /*
+ * Disabled polling might produce link flapping and false notification interrupts on the
+ * MAC layer. In this case disable c45 over c22 MMD access because chances are high that
+ * the register 13/14/13/14 sequence is intercepted by a parallel hardware access. As
+ * a workaround the PHY must provide its own mmd read/write() callbacks and redirect to
+ * normal c22 registers. See rtlgen_read_mmd().
+ */
+ if (priv->info->link_flap)
+ return (regnum == MII_MMD_DATA || regnum == MII_MMD_CTRL) ? -EIO : 0;
+
+ expected = (*state & 1) ? MII_MMD_DATA : MII_MMD_CTRL;
+ newstate = regnum == expected ? *state + 1 : 0;
+
+ if (newstate == 1 || newstate < *state)
+ ret = otto_emdio_set_port_polling(priv, port, !newstate);
+ *state = newstate;
+
+ return ret;
+}
+
+static int otto_emdio_mmd_postfix(struct otto_emdio_priv *priv, int port, int regnum)
+{
+ if (priv->mmd_state[port] != 4)
+ return 0;
+
+ priv->mmd_state[port] = 0;
+
+ return otto_emdio_set_port_polling(priv, port, true);
+}
+
static int otto_emdio_run_cmd(struct mii_bus *bus, u32 cmd,
struct otto_emdio_cmd_regs *cmd_data)
{
@@ -463,7 +503,15 @@ static int otto_emdio_read_c22(struct mii_bus *bus, int phy_id, int regnum)
if (regnum == 31)
return priv->page[port];
+ ret = otto_emdio_mmd_prefix(priv, port, regnum);
+ if (ret)
+ return ret;
+
ret = priv->info->read_c22(bus, port, regnum, &value);
+ if (ret)
+ return ret;
+
+ ret = otto_emdio_mmd_postfix(priv, port, regnum);
}
return ret ? ret : value;
@@ -472,7 +520,7 @@ static int otto_emdio_read_c22(struct mii_bus *bus, int phy_id, int regnum)
static int otto_emdio_write_c22(struct mii_bus *bus, int phy_id, int regnum, u16 value)
{
struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
- int port;
+ int port, ret;
port = otto_emdio_phy_to_port(bus, phy_id);
if (port < 0)
@@ -487,7 +535,15 @@ static int otto_emdio_write_c22(struct mii_bus *bus, int phy_id, int regnum, u16
return 0;
}
- return priv->info->write_c22(bus, port, regnum, value);
+ ret = otto_emdio_mmd_prefix(priv, port, regnum);
+ if (ret)
+ return ret;
+
+ ret = priv->info->write_c22(bus, port, regnum, value);
+ if (ret)
+ return ret;
+
+ return otto_emdio_mmd_postfix(priv, port, regnum);
}
}
@@ -794,6 +850,8 @@ static int otto_emdio_probe(struct platform_device *pdev)
return err;
}
+ priv->init_done = true;
+
return 0;
}
--
2.54.0
^ permalink raw reply related
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