* [PATCH v2 0/2] input: misc: Add PixArt PAJ7620 gesture sensor
From: Harpreet Saini @ 2026-04-17 5:25 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: David Lechner, Harpreet Saini, devicetree, linux-input,
linux-kernel
In-Reply-To: <20260417052527.62535-1-sainiharpreet29.ref@yahoo.com>
This series adds support for the PixArt PAJ7620 gesture sensor.
Following review feedback on v1, the driver has been moved from IIO
to the Input subsystem as gestures are user-interaction events.
The bindings have been updated to include mandatory power supplies
and GPIO controller properties.
Changes in v2:
- Moved driver from drivers/iio/light to drivers/input/misc
- Updated DT bindings to include mandatory vdd, vbus, and vled supplies
- Added Runtime PM support with autosuspend logic
- Combined bindings and driver into a single series
Harpreet Saini (2):
dt-bindings: input: Add PixArt PAJ7620 gesture sensor
input: misc: Add PixArt PAJ7620 gesture sensor driver
.../bindings/input/pixart,paj7620.yaml | 70 ++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/paj7620.c | 350 ++++++++++++++++++
5 files changed, 435 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/pixart,paj7620.yaml
create mode 100644 drivers/input/misc/paj7620.c
--
2.43.0
^ permalink raw reply
* Re: [PATCH 2/2] spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5
From: Fenglin Wu @ 2026-04-17 5:24 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <c5d1578d-729d-4c09-b761-c67e6d3be745@oss.qualcomm.com>
On 4/2/2026 12:18 PM, Fenglin Wu wrote:
>
> On 4/1/2026 7:22 PM, Dmitry Baryshkov wrote:
>> On Wed, Apr 01, 2026 at 02:41:24AM -0700, Fenglin Wu wrote:
>>> PMIC arbiter v8.5 is an extension of PMIC arbiter v8 that updated
>>> the definition of the channel status register bit fields. Add support
>>> to handle this difference.
>>>
>>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>>> ---
>>> drivers/spmi/spmi-pmic-arb.c | 69
>>> ++++++++++++++++++++++++++++++++++++++------
>>> 1 file changed, 60 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/spmi/spmi-pmic-arb.c
>>> b/drivers/spmi/spmi-pmic-arb.c
>>> index 69f8d456324a..deeaa39bb647 100644
>>> --- a/drivers/spmi/spmi-pmic-arb.c
>>> +++ b/drivers/spmi/spmi-pmic-arb.c
>>> @@ -28,6 +28,7 @@
>>> #define PMIC_ARB_VERSION_V5_MIN 0x50000000
>>> #define PMIC_ARB_VERSION_V7_MIN 0x70000000
>>> #define PMIC_ARB_VERSION_V8_MIN 0x80000000
>>> +#define PMIC_ARB_VERSION_V8P5_MIN 0x80050000
>>> #define PMIC_ARB_INT_EN 0x0004
>>> #define PMIC_ARB_FEATURES 0x0004
>>> @@ -63,11 +64,34 @@
>>> #define SPMI_OWNERSHIP_PERIPH2OWNER(X) ((X) & 0x7)
>>> /* Channel Status fields */
>>> -enum pmic_arb_chnl_status {
>>> - PMIC_ARB_STATUS_DONE = BIT(0),
>>> - PMIC_ARB_STATUS_FAILURE = BIT(1),
>>> - PMIC_ARB_STATUS_DENIED = BIT(2),
>>> - PMIC_ARB_STATUS_DROPPED = BIT(3),
>>> +struct pmic_arb_chnl_status_mask {
>>> + u8 done;
>>> + u8 failure;
>>> + u8 crc;
>>> + u8 parity;
>>> + u8 nack;
>>> + u8 denied;
>>> + u8 dropped;
>>> +};
>>> +
>>> +static const struct pmic_arb_chnl_status_mask chnl_status_mask = {
>>> + .done = BIT(0),
>>> + .failure = BIT(1),
>>> + .crc = 0,
>>> + .parity = 0,
>>> + .nack = 0,
>>> + .denied = BIT(2),
>>> + .dropped = BIT(3),
>>> +};
>>> +
>>> +static const struct pmic_arb_chnl_status_mask chnl_status_mask_v8p5
>>> = {
>>> + .done = BIT(0),
>>> + .failure = BIT(1),
>>> + .crc = BIT(2),
>>> + .parity = BIT(3),
>>> + .nack = BIT(4),
>>> + .denied = BIT(5),
>>> + .dropped = BIT(6),
>> Would it be better to extract generation-specific callback to decode the
>> error rather than defining the list of masks?
>
> Are you proposing to add a callback in pmic_arb_ver_ops, like
> '*check_chnl_status', and create separate implementations for PMIC
> arbiter versions before and after v8.5?
>
> This approach would add more extensive code changes with some code
> duplication, especially for handling common error bits shared across
> all versions—even if they only print error messages and return an
> error code. Is that a concern?
>
> Fenglin
Hi Dmitry,
Please let me know if this your preferred way and if you are fine with
the concern that I mentioned.
I can come up with this approach and post a new patch.
Thanks
Fenglin
^ permalink raw reply
* [net-next v2 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
Add default disable split header flag in all the starfive
soc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 91698c763dac..9146b498658d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -145,7 +145,7 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
}
dwmac->dev = &pdev->dev;
- plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+ plat_dat->flags |= (STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | STMMAC_FLAG_SPH_DISABLE);
plat_dat->bsp_priv = dwmac;
plat_dat->dma_cfg->dche = true;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-17 5:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAABR9nF131G3K3-vUdaDwHuQ7MCCLd-VO5syLApE_qsn+J49kA@mail.gmail.com>
Hi Geert,
Thanks you for your review and suggestion.
I think this approach looks very good.
> clock-names:
> minItems: 1
> maxItems: 8
> items:
> - fck # Main FSI module clock
> - spu # optional SPU bus/bridge clock [...]
> - icka # optional CPG DIV6 functional clocks for FSI port A
> - ickb # optional CPG DIV6 functional clocks for FSI port B
> [...]
Just to confirm: using this approach with a fixed order and optional
entries as described would not be
considered "flexible" in the sense that Krzysztof objected to, right?
Best regards,
Phuc
^ permalink raw reply
* Re: [net-next v2 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Rob Herring (Arm) @ 2026-04-17 4:36 UTC (permalink / raw)
To: Minda Chen
Cc: Paolo Abeni, Jakub Kicinski, Alexandre Torgue, Maxime Coquelin,
Emil Renner Berthing, Andrew Lunn, David S . Miller, linux-stm32,
devicetree, netdev, Krzysztof Kozlowski, Rob Herring,
linux-kernel, Eric Dumazet, Conor Dooley
In-Reply-To: <20260417024523.107786-4-minda.chen@starfivetech.com>
On Fri, 17 Apr 2026 10:45:21 +0800, Minda Chen wrote:
> JHB100 SGMII interface tx/rx mac clock is split and require to
> set clock rate in 10M/100M/1000M speed. So dts need to add a
> new rx clock in code, dts and dt binding doc.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> .../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
> 1 file changed, 36 insertions(+), 6 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml:56:8: [warning] wrong indentation: expected 8 but found 7 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260417024523.107786-4-minda.chen@starfivetech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: cdns: Convert xtfpga I2S to dt-schema
From: Max Filippov @ 2026-04-17 4:11 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260416152329.6016-1-chaitanya.msabnis@gmail.com>
On Thu, Apr 16, 2026 at 8:25 AM Chaitanya Sabnis
<chaitanya.msabnis@gmail.com> wrote:
>
> Convert the Cadence XTensa FPGA I2S controller plain-text binding
> documentation to standard dt-schema (YAML).
>
> The hardware requires exactly one memory region, one interrupt line,
> and one phandle to the master clock. Verified these constraints against
> the driver source in sound/soc/xtensa/xtfpga-i2s.c.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
> ---
> .../bindings/sound/cdns,xtfpga-i2s.txt | 18 -------
> .../bindings/sound/cdns,xtfpga-i2s.yaml | 48 +++++++++++++++++++
> 2 files changed, 48 insertions(+), 18 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
> create mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
> deleted file mode 100644
> index 860fc0da39c0..000000000000
> --- a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
> +++ /dev/null
> @@ -1,18 +0,0 @@
> -Bindings for I2S controller built into xtfpga Xtensa bitstreams.
> -
> -Required properties:
> -- compatible: shall be "cdns,xtfpga-i2s".
> -- reg: memory region (address and length) with device registers.
> -- interrupts: interrupt for the device.
> -- clocks: phandle to the clk used as master clock. I2S bus clock
> - is derived from it.
> -
> -Examples:
> -
> - i2s0: xtfpga-i2s@d080000 {
> - #sound-dai-cells = <0>;
> - compatible = "cdns,xtfpga-i2s";
> - reg = <0x0d080000 0x40>;
> - interrupts = <2 1>;
> - clocks = <&cdce706 4>;
> - };
> diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
> new file mode 100644
> index 000000000000..9a4a9db3c159
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/cdns,xtfpga-i2s.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence XTensa FPGA I2S Controller
When put like this it looks like an official name, but it's not and it misses an
important bit: 'xtfpga' is a group name for very specific FPGAs bitstreams
generated for xtensa cores, spelling it as XTensa FPGA makes it less
obvious what it is. I'd suggest keeping the original description.
For other changes:
Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>
> +
> +maintainers:
> + - Max Filippov <jcmvbkbc@gmail.com>
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +properties:
> + compatible:
> + const: cdns,xtfpga-i2s
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> + description: phandle to the clk used as master clock. I2S bus clock is derived from it.
> +
> + "#sound-dai-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + i2s@d080000 {
> + compatible = "cdns,xtfpga-i2s";
> + reg = <0x0d080000 0x40>;
> + interrupts = <2 1>;
> + clocks = <&cdce706 4>;
> + #sound-dai-cells = <0>;
> + };
> --
> 2.43.0
>
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v5 12/14] ASoC: rsnd: src: Add SRC reset and clock support for RZ/G3E
From: Kuninori Morimoto @ 2026-04-17 3:53 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <20260415124731.3684773-13-john.madieu.xa@bp.renesas.com>
Hi John
> The RZ/G3E SoC requires explicit SCU (Sampling Rate Converter Unit)
> reset and clock management unlike previous R-Car generations:
>
> - scu_clk: SCU module clock
> - scu_clkx2: SCU double-rate clock
> - scu_supply_clk: SCU supply clock
>
> Without these clocks enabled, the SRC module cannot operate on RZ/G3E.
> Add support for the shared SCU reset controller used by the SRC modules
> on the Renesas RZ/G3E SoC. All SRC instances are gated by the same "scu"
> reset line.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
(snip)
> +struct rsnd_src_ctrl {
> + struct clk *scu;
> + struct clk *scu_x2;
> + struct clk *scu_supply;
> +};
I noticed that "scu_supply" is used in init/quit, but scu/scu_x2 are
enabled when probe time only ?
I guess this is because it is needed for whole SRC ?
If so, it need to count whole SRC user and enable/disable it when
1st/last user.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v5 13/14] ASoC: rsnd: Support unprefixed DT node names for RZ/G3E
From: Kuninori Morimoto @ 2026-04-17 3:44 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <20260415124731.3684773-14-john.madieu.xa@bp.renesas.com>
Hi John
Thank you for your patch
> The RZ/G3E device tree binding uses standard unprefixed node names
> ('ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu', 'dai') instead of the
> legacy 'rcar_sound,' prefixed names used by R-Car bindings.
>
> Convert rsnd_parse_of_node() from a macro into a function that tries
> the legacy prefixed name first, then falls back to the unprefixed
> name by stripping the "rcar_sound," prefix. This makes the driver
> work transparently with both old and new bindings.
>
> While at it, update the of_node_name_eq() calls in core.c which compare
> against RSND_NODE_DAI directly (bypassing rsnd_parse_of_node()),
> and fix the related comments in ssiu.c, ssi.c, and dma.c that
> reference hardcoded "rcar_sound,ssiu" / "rcar_sound,ssi" names.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
(snip)
> +struct device_node *rsnd_parse_of_node(struct rsnd_priv *priv, const char *name)
> +{
> + struct device_node *np = rsnd_priv_to_dev(priv)->of_node;
> + struct device_node *node;
> + const char *unprefixed;
> +
> + node = of_get_child_by_name(np, name);
> + if (node)
> + return node;
> +
> + /*
> + * RZ/G3E binding uses unprefixed node names (e.g. "ssi" instead
> + * of "rcar_sound,ssi"). Try stripping the "rcar_sound," prefix.
> + */
> + unprefixed = strchr(name, ',');
> + if (unprefixed)
> + node = of_get_child_by_name(np, unprefixed + 1);
> +
> + return node;
> +}
I think it is better to have name get function, and use it on parse func ?
char *rsnd_xx_name(node, name)
{
char *sub_name;
/* name = "rcar_sound,ssi" */
ret = of_node_name_eq(node, name);
if (ret == 0)
return name;
/* sub_name = "ssi" */
sub_name = strchr(name, ",");
ret = of_node_name_eq(node, sub_name);
if (ret == 0)
return sub_name;
return NULL;
}
> @@ -1273,7 +1294,8 @@ static int rsnd_dai_of_node(struct rsnd_priv *priv, int *is_graph)
> of_node_put(node);
>
> for_each_child_of_node_scoped(np, node) {
> - if (!of_node_name_eq(node, RSND_NODE_DAI))
> + if (!of_node_name_eq(node, RSND_NODE_DAI) &&
> + !of_node_name_eq(node, "dai"))
> continue;
If driver is handling almost same things individually and/or randomly in per
each places, it will eventually lose consistency.
rsnd_xx_name() can keep consistency ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-17 3:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAMuHMdVPbcz4rF8ojEcvxp1NaM2mbQ2o+HZLwnnjNnX8uHf4HA@mail.gmail.com>
Hi Geert,
Thanks for your feedback.
> Where does this match the driver?
> Usually the functional clock is called "fck".
Regarding the clock name "own", I used it because of the following
implementation in the current driver:
clock->own = devm_clk_get(dev, NULL);
if (IS_ERR(clock->own))
return -EINVAL;
The driver currently fetches the first clock in the list (index 0) and
stores it in a variable named own.
That is why I named it "own" in the DT bindings to match.
However, I have noticed that other DTS files commonly use "fck" for
the functional clock.
Are you suggesting that I should also rename the variable from "own"
to "fck" in the driver code ??
For example:
clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
clock-names = "fck";
But from the hardware manual, MSTP refers to a "Module Stop Clock",
not a "functional clock".
So I'm not sure if using "fck" here is appropriate. Could you explain
the reasoning behind calling this clock "fck"?
Regarding the FSI clocks, they can be categorized into two types:
audio clocks and module clocks (which may include bus/bridge clocks).
The driver itself does not explicitly handle the enabling/disabling of
the module clock; it only manages the audio clocks.
From my code tracing:
At boot: The kernel automatically attaches the PM domain and
prepares the clocks during device initialization.
During playback (aplay): The FSI driver doesn't enable the module
clock directly. Instead, it is handled via:
genpd_runtime_resume -> pm_clk_resume -> clk_core_enable ->
cpg_mstp_clock_endisable.
Since this module clock is essential for register access, it must
always be the first entry in the clocks property (index 0) so
devm_clk_get(dev, NULL)
can fetch it correctly, right?
Please let me know if my understanding is incorrect.
Best regards,
Phuc
^ permalink raw reply
* RE: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Torreno, Alexis Czezar @ 2026-04-17 3:32 UTC (permalink / raw)
To: Guenter Roeck, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <a142d5ce-e4a3-4f50-8009-f796609fb13c@roeck-us.net>
> >>
> >> It's an output on this device seemingly. I don't care if the driver
> >> ignores it, but for completeness (and we like completeness with
> >> bindings) I think it should be documented as an interrupt or gpio.
> >
> > Alright, I'll add it as an interrupt: optional power-good signal
> >
>
> Uuh, that really doesn't make any sense. Please at least make it a gpio pin,
> matching pwr-good-gpios of ti,tps65185.yaml.
>
I see, will do.
^ permalink raw reply
* Re: [PATCH v5 11/14] ASoC: rsnd: adg: Add per-SSI ADG and SSIF supply clock management
From: Kuninori Morimoto @ 2026-04-17 3:32 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <20260415124731.3684773-12-john.madieu.xa@bp.renesas.com>
Hi John
Thank you for the patch
> RZ/G3E's ADG module requires explicit clock management for SSI audio
> interfaces that differs from R-Car Gen2/Gen3/Gen4:
>
> - Per-SSI ADG clocks (adg.ssi.N) for each SSI module
> - A shared SSIF supply clock for the SSI subsystem
>
> These clocks are acquired using optional APIs, making them transparent
> to platforms that do not require them.
>
> Clock prepare/unprepare is handled in rsnd_adg_clk_control(), which
> is called from probe, remove, suspend and resume (all sleepable
> contexts). The trigger path (atomic context) only calls
> clk_enable/clk_disable, which is atomic-safe and requires no
> additional splitting.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
(snip)
> @@ -424,9 +455,35 @@ int rsnd_adg_clk_control(struct rsnd_priv *priv, int enable)
> if (ret < 0)
> rsnd_adg_clk_disable(priv);
>
> + /* RZ/G3E: per-SSI ADG and SSIF supply clocks */
> + if (enable) {
> + for (i = 0; i < ADG_SSI_MAX; i++) {
> + ret = clk_prepare(adg->clk_adg_ssi[i]);
> + if (ret < 0) {
> + while (--i >= 0)
> + clk_unprepare(adg->clk_adg_ssi[i]);
> + rsnd_adg_clk_disable(priv);
> + return ret;
> + }
> + }
> + ret = clk_prepare(adg->clk_ssif_supply);
> + if (ret < 0) {
> + for (i = 0; i < ADG_SSI_MAX; i++)
> + clk_unprepare(adg->clk_adg_ssi[i]);
> + rsnd_adg_clk_disable(priv);
> + return ret;
> + }
> + }
> +
> /* disable adg */
> - if (!enable)
> + if (!enable) {
> + /* RZ/G3E: unprepare per-SSI and supply clocks */
> + clk_unprepare(adg->clk_ssif_supply);
> + for (i = 0; i < ADG_SSI_MAX; i++)
> + clk_unprepare(adg->clk_adg_ssi[i]);
> +
> clk_disable_unprepare(adg->adg);
> + }
>
> return ret;
> }
As mentioned in comment, to avoid duplicate code (like above), it will
call rsnd_adg_clk_disable() in case of rollback, too.
/*
* rsnd_adg_clk_enable() might return error (_disable() will not).
* We need to rollback in such case
*/
if (ret < 0)
rsnd_adg_clk_disable(priv);
Because of this style, I guess "enable" need to call clk_prepare() for *all*
clk without loop break, even though it returuns error. And call clk_unprepare()
for *all* clk when "rollback" and/or "disable".
Enable
for (i = 0; i < ADG_SSI_MAX; i++)
ret |= clk_prepare(...);
^^
ret |= clk_prepare(...);
^^
...
if (ret < 0)
rsnd_adg_clk_disable(priv);
Disable
clk_unprepare(...);
for (i = 0; i < ADG_SSI_MAX; i++)
clk_unprepare(...);
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Guenter Roeck @ 2026-04-17 3:22 UTC (permalink / raw)
To: Torreno, Alexis Czezar, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <PH0PR03MB635166088B7C473CF59F17D1F1202@PH0PR03MB6351.namprd03.prod.outlook.com>
On 4/16/26 18:04, Torreno, Alexis Czezar wrote:
>
>>>>
>>>> On the previous version, you got an LLM comment about not having the
>>>> interrupts property amongst other things.
>>>> I think the other things got implemented, but I didn't see any reply
>>>> to the bot about that?
>
> I wasn't sure if it was that type of bot. I'll try replying on the other patch review.
> I just added a note in the cover letter change log about the lacking smbalert.
>
>>>> I think the answer is that it shouldn't because the pin it
>>>> referenced doesn't exist, but when looking at the schematic I have
>>>> to wonder if
>>>
>>> I had to look this up in the datasheet. A SMBus chip with no alert pin
>>> is a bit odd, but you are correct.
>>>
>>>> there should be an interrupts property for dealing with "pgood"?
>>>>
>>> FWIW, I have never seen that. Normally such pins are used to take
>>> devices out of reset.
>>
>> It's an output on this device seemingly. I don't care if the driver ignores it, but
>> for completeness (and we like completeness with
>> bindings) I think it should be documented as an interrupt or gpio.
>
> Alright, I'll add it as an interrupt: optional power-good signal
>
Uuh, that really doesn't make any sense. Please at least make it a gpio pin,
matching pwr-good-gpios of ti,tps65185.yaml.
Guenter
^ permalink raw reply
* [net-next v2 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
Remove JH8100 dt-bindings because do not support it now.
StarFive have stopped JH8100 developing and will release it
outside.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 ++++---------------
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 313a15331661..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -30,10 +30,6 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
- - items:
- - const: starfive,jh8100-dwmac
- - const: starfive,jh7110-dwmac
- - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -120,25 +116,11 @@ allOf:
minItems: 3
maxItems: 3
- if:
- properties:
- compatible:
- contains:
- const: starfive,jh8100-dwmac
- then:
- properties:
- resets:
- maxItems: 1
-
- reset-names:
- const: stmmaceth
- else:
- properties:
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
2.17.1
^ permalink raw reply related
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-17 3:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260416203905.GA29913@bhelgaas>
> On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > Introduce generic helper functions to parse Root Port device tree
> > nodes and extract common properties like reset GPIOs. This allows
> > multiple PCI host controller drivers to share the same parsing logic.
> >
> > Define struct pci_host_port to hold common Root Port properties
> > (currently only reset GPIO descriptor) and add
> > pci_host_common_parse_ports() to parse Root Port nodes from device
> tree.
>
> Are the Root Port and the RC the only possible places for 'reset' GPIO
> descriptions in DT? I think PERST# routing is outside the PCIe spec, so it
> seems like a system could provide a PERST# GPIO routed to any Switch
> Upstream Port or Endpoint (I assume a PERST# connected to a switch would
> apply to both the upstream port and the downstream ports).
Hi Bjorn,
Thanks for the feedback. You're right that PERST# routing could theoretically be
connected to any device in the hierarchy. However, for this patch series, I've focused
on the most common use case in practice: use Root Port level PERST# instead of the
legacy Root Complex level PERST#.
Root Port level PERST# - This is the primary target, where each Root Port has individual
control over devices connected to it.
RC level PERST# - Legacy binding support, where a single GPIO controls all ports.
We can extend this framework later if real hardware emerges that needs Switch or
EP-level PERST# control. I can add a comment documenting this limitation if needed.
BTW, Mani and Rob had some great discussions in dt-schema about PERST# and WAKE#
sideband signals settings.
You can check here:
https://github.com/devicetree-org/dt-schema/issues/168
https://github.com/devicetree-org/dt-schema/pull/126
https://github.com/devicetree-org/dt-schema/pull/170
Best Regards
Sherry
^ permalink raw reply
* Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Xuyang Dong @ 2026-04-17 3:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel, linux-pwm,
devicetree, linux-kernel, ningyu, linmin, xuxiang, wangguosheng,
pinkesh.vaghela
In-Reply-To: <aeE-D5vC453uqtm6@monoceros>
>
> Hello,
>
> I suggest
>
> dt-bindings: pwm: dwc: Add optional reset
>
> as shortlog.
>
Hi Uwe,
Thanks, I'll address this in the next version.
Best regards,
Xuyang Dong
^ permalink raw reply
* Re: Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Xuyang Dong @ 2026-04-17 3:11 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, ukleinek, robh, krzk+dt, conor+dt, ben-linux,
ben.dooks, p.zabel, linux-pwm, devicetree, linux-kernel, ningyu,
linmin, xuxiang, wangguosheng, pinkesh.vaghela
In-Reply-To: <20260416-flashcard-shadily-a0ddd2f12ff8@spud>
> > > > >
> > > > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > > > domain:
> > > > > The presetn signal resets logic in pclk domain.
> > > > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > > > The resets are active-low.
> > > > >
> > > > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> > > >
> > > > This commit implies that your hardware differs from existing devices,
> > > > I think you should add a device-specific compatible.
> > > >
> >
> > Hi Conor and Krzysztof,
> >
> > The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
> > separate reset signals dedicated to each clock domain". They are:
> > The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
> > The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
> > the timer clock in DT).
> >
> > These reset signals are optional; it is up to the designer's
> > implementation.
>
> Right, and it's that "designer's implementation" that warrants a
> device-specific compatible.
>
Hi Conor,
The YAML update for the new device-specific compatible is as follows:
properties:
compatible:
oneOf:
- const: snps,dw-apb-timers-pwm2
- items:
- enum:
- snps,dw-apb-timers-pwm-2.13a
- const: snps,dw-apb-timers-pwm2
reg:
maxItems: 1
"#pwm-cells":
const: 3
clocks:
items:
- description: Interface bus clock
- description: PWM reference clock
clock-names:
items:
- const: bus
- const: timer
resets:
items:
- description: Interface bus reset
- description: PWM timer logic reset
snps,pwm-number:
$ref: /schemas/types.yaml#/definitions/uint32
description: The number of PWM channels configured for this instance
enum: [1, 2, 3, 4, 5, 6, 7, 8]
required:
- compatible
- reg
- clocks
- clock-names
allOf:
- $ref: pwm.yaml#
- if:
properties:
compatible:
contains:
const: snps,dw-apb-timers-pwm-2.13a
then:
required:
- resets
In your opinion, is this modification accurate?
Best regards,
Xuyang Dong
> >
> > According to [1], the applied YAML is also based on 2.13a, so our
> > hardware is the same as the existing devices. It's just that these two
> > reset signals were missing from the original YAML binding.
> >
> > [1] https://lore.kernel.org/linux-pwm/8bb5103d-803e-90d2-fd93-132bb2aac2d6@sifive.com/
> >
> > > > > ---
> > > > > .../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > > index 7523a89a1773..a8bbad0360f8 100644
> > > > > --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > > +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > > @@ -43,6 +43,9 @@ properties:
> > > > > - const: bus
> > > > > - const: timer
> > > > >
> > > > > + resets:
> > > > > + maxItems: 2
> > >
> > > And this should really be listed with description, because order is
> > > fixed.
> > >
> >
> > The description of resets will be listed in next version.
> >
> > Best regards,
> > Xuyang Dong
^ permalink raw reply
* Re: [PATCH 1/2] drivers/of: validate live-tree string properties before string use
From: Pengpeng Hou @ 2026-04-17 3:06 UTC (permalink / raw)
To: Rob Herring; +Cc: Saravana Kannan, devicetree, linux-kernel, pengpeng
In-Reply-To: <20260403183501.1-drivers-of-live-tree-pengpeng@iscas.ac.cn>
Hi Rob,
Thanks, I'll respin this.
I'll switch the `device_type` match to `of_property_match_string()`,
rework `of_prop_next_string()` so the `cur == NULL` case flows through a
cleaner iterator path without validating each returned string twice, and
add a unittest for that first-iteration case.
Thanks,
Pengpeng
^ permalink raw reply
* [net-next v2 4/5] net: stmmac: starfive: Add JHB100 SGMII interface
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
Add JHB100 compatible and SGMII support. JHB100 soc contains
2 SGMII interfaces and integrated with serdes PHY. SGMII with
split TX/RX MAC clock and need to set 2.5M/25M/125M TX/RX clock
rate in 10M/100M/1000M speed mode.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 54 ++++++++++++++-----
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 16b955a6d77b..91698c763dac 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -26,6 +26,7 @@ struct starfive_dwmac_data {
struct starfive_dwmac {
struct device *dev;
const struct starfive_dwmac_data *data;
+ struct clk *sgmii_rx;
};
static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
@@ -68,6 +69,24 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
return 0;
}
+static int stmmac_starfive_sgmii_set_clk_rate(void *bsp_priv, struct clk *clk_tx_i,
+ phy_interface_t interface, int speed)
+{
+ struct starfive_dwmac *dwmac = (void *)bsp_priv;
+ long rate = rgmii_clock(speed);
+ int ret;
+
+ /* MAC clock rate the same as RGMII */
+ if (rate < 0)
+ return 0;
+
+ ret = clk_set_rate(clk_tx_i, rate);
+ if (ret)
+ return ret;
+
+ return clk_set_rate(dwmac->sgmii_rx, rate);
+}
+
static int starfive_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -102,24 +121,34 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, PTR_ERR(clk_gtx),
"error getting gtx clock\n");
- /* Generally, the rgmii_tx clock is provided by the internal clock,
- * which needs to match the corresponding clock frequency according
- * to different speeds. If the rgmii_tx clock is provided by the
- * external rgmii_rxin, there is no need to configure the clock
- * internally, because rgmii_rxin will be adaptively adjusted.
- */
- if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk"))
- plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+ if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ dwmac->sgmii_rx = devm_clk_get_enabled(&pdev->dev, "sgmii_rx");
+ if (IS_ERR(dwmac->sgmii_rx))
+ return dev_err_probe(&pdev->dev,
+ PTR_ERR(dwmac->sgmii_rx),
+ "error getting sgmii rx clock\n");
+ plat_dat->set_clk_tx_rate = stmmac_starfive_sgmii_set_clk_rate;
+ } else {
+ /*
+ * Generally, the rgmii_tx clock is provided by the internal clock,
+ * which needs to match the corresponding clock frequency according
+ * to different speeds. If the rgmii_tx clock is provided by the
+ * external rgmii_rxin, there is no need to configure the clock
+ * internally, because rgmii_rxin will be adaptively adjusted.
+ */
+ if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk"))
+ plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+
+ err = starfive_dwmac_set_mode(plat_dat);
+ if (err)
+ return err;
+ }
dwmac->dev = &pdev->dev;
plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
plat_dat->bsp_priv = dwmac;
plat_dat->dma_cfg->dche = true;
- err = starfive_dwmac_set_mode(plat_dat);
- if (err)
- return err;
-
return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
}
@@ -130,6 +159,7 @@ static const struct starfive_dwmac_data jh7100_data = {
static const struct of_device_id starfive_dwmac_match[] = {
{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
{ .compatible = "starfive,jh7110-dwmac" },
+ { .compatible = "starfive,jhb100-dwmac" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
--
2.17.1
^ permalink raw reply related
* [net-next v2 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
JHB100 SGMII interface tx/rx mac clock is split and require to
set clock rate in 10M/100M/1000M speed. So dts need to add a
new rx clock in code, dts and dt binding doc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index edc246a71ce3..3802cdbf1848 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -39,20 +39,26 @@ properties:
maxItems: 1
clocks:
+ minItems: 5
items:
- description: GMAC main clock
- description: GMAC AHB clock
- description: PTP clock
- description: TX clock
- description: GTX clock
+ - description: SGMII RX clock
clock-names:
- items:
- - const: stmmaceth
- - const: pclk
- - const: ptp_ref
- - const: tx
- - const: gtx
+ minItems: 5
+ maxItems: 6
+ contains:
+ enum:
+ - stmmaceth
+ - pclk
+ - ptp_ref
+ - tx
+ - gtx
+ - sgmii_rx
starfive,tx-use-rgmii-clk:
description:
@@ -99,6 +105,14 @@ allOf:
minItems: 2
maxItems: 2
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
maxItems: 1
@@ -120,6 +134,14 @@ allOf:
minItems: 3
maxItems: 3
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
minItems: 2
@@ -139,6 +161,14 @@ allOf:
interrupt-names:
const: macirq
+ clocks:
+ minItems: 5
+ maxItems: 6
+
+ clock-names:
+ minItems: 5
+ maxItems: 6
+
resets:
maxItems: 1
--
2.17.1
^ permalink raw reply related
* [net-next v2 2/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
Add StarFive JHB100 dwmac support and compatible.
The JHB100 dwmac shares the same driver code as the JH7110 dwmac,
which contains 2 SGMII interfaces, 1 RGMII/RMII interface and
1 RMII interface.
JHB100 dwmac has only one reset signal and one main interrupt
line.
Please refer to below:
JHB100: reset-names = "stmmaceth";
Example usage of JHB100 in the device tree:
gmac0: ethernet@11b80000 {
compatible = "starfive,jhb100-dwmac",
"snps,dwmac-5.20";
interrupts = <225>;
interrupt-names = "macirq";
...
};
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 38bc34dc4f09..85cd3252e8b1 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -115,6 +115,7 @@ properties:
- sophgo,sg2044-dwmac
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
- tesla,fsd-ethqos
- thead,th1520-gmac
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 0d1962980f57..edc246a71ce3 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -18,6 +18,7 @@ select:
enum:
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
required:
- compatible
@@ -30,6 +31,9 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jhb100-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -122,6 +126,25 @@ allOf:
reset-names:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jhb100-dwmac
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+
unevaluatedProperties: false
examples:
--
2.17.1
^ permalink raw reply related
* [net-next v2 0/5] Add StarFive JHB100 soc SGMII GMAC support
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
Managent Controller). Similar with Aspeed 27x0.
The JHB100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
JHB100 GMAC still using designware GMAC core like JH7100 and JH7110,
and contains 2 SGMII interfaces, 1 RGMII/RMII interface, 1 RMII
interface. In JH7100/JH7110 dwmac-starfive.c have supported RGMII/RMII
interface. So require to add SGMII support to dwmac-starfive.c for JHB100.
SGMII serdes PHY has been intergrated in JHB100 and do not have driver
setting.
In JHB100 EVB board, SGMII connect with motorcomm YT8531s external PHY
and support RJ45 ethernet port.
The patch base in 7.0-rc5
changes
v2:
1. patch1 Add the remove reason
2. patch2 rename rx clock to sgmii_rx
3. patch4 confirm sgmii rx clock exist, or will probe error
sgmii will not call starfive_dwmac_set_mode()
Minda Chen (5):
dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
net: stmmac: starfive: Add JHB100 SGMII interface
net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 89 +++++++++++++------
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 56 +++++++++---
3 files changed, 106 insertions(+), 40 deletions(-)
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* [PATCH] PCI: amd-mdb: Assert PERST# on shutdown
From: Sai Krishna Musham @ 2026-04-17 2:38 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, mani, robh, krzk+dt, conor+dt, cassel
Cc: linux-pci, devicetree, linux-kernel, michal.simek,
bharat.kumar.gogada, thippeswamy.havalige, sai.krishna.musham
Add a shutdown handler for the AMD MDB PCIe host controller that
asserts the PERST# signal via GPIO before the system powers off or
reboots. This ensures the connected PCIe endpoint is held in reset
during shutdown.
Signed-off-by: Sai Krishna Musham <sai.krishna.musham@amd.com>
---
drivers/pci/controller/dwc/pcie-amd-mdb.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-amd-mdb.c b/drivers/pci/controller/dwc/pcie-amd-mdb.c
index 7e50e11fbffd..69d21b4727e4 100644
--- a/drivers/pci/controller/dwc/pcie-amd-mdb.c
+++ b/drivers/pci/controller/dwc/pcie-amd-mdb.c
@@ -507,6 +507,14 @@ static int amd_mdb_pcie_probe(struct platform_device *pdev)
return amd_mdb_add_pcie_port(pcie, pdev);
}
+static void amd_mdb_pcie_shutdown(struct platform_device *pdev)
+{
+ struct amd_mdb_pcie *pcie = platform_get_drvdata(pdev);
+
+ if (pcie->perst_gpio)
+ gpiod_set_value_cansleep(pcie->perst_gpio, 1);
+}
+
static const struct of_device_id amd_mdb_pcie_of_match[] = {
{
.compatible = "amd,versal2-mdb-host",
@@ -521,6 +529,7 @@ static struct platform_driver amd_mdb_pcie_driver = {
.suppress_bind_attrs = true,
},
.probe = amd_mdb_pcie_probe,
+ .shutdown = amd_mdb_pcie_shutdown,
};
builtin_platform_driver(amd_mdb_pcie_driver);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Billy Tsai @ 2026-04-17 2:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260416-brutishly-saga-ba7168a4cd14@spud>
> > + properties:
> > + function:
> > + enum:
> > + - EMMC
> > + - JTAGDDR
> > + - JTAGM0
> > + - JTAGPCIEA
> > + - JTAGPCIEB
> > + - JTAGPSP
> > + - JTAGSSP
> > + - JTAGTSP
> > + - JTAGUSB3A
> > + - JTAGUSB3B
> > + - PCIERC0PERST
> > + - PCIERC1PERST
> > + - TSPRSTN
> > + - UFSCLKI
> > + - USB2AD0
> > + - USB2AD1
> > + - USB2AH
> > + - USB2AHP
> > + - USB2AHPD0
> > + - USB2AXH
> > + - USB2AXH2B
> > + - USB2AXHD1
> > + - USB2AXHP
> > + - USB2AXHP2B
> > + - USB2AXHPD1
> > + - USB2BD0
> > + - USB2BD1
> > + - USB2BH
> > + - USB2BHP
> > + - USB2BHPD0
> > + - USB2BXH
> > + - USB2BXH2A
> > + - USB2BXHD1
> > + - USB2BXHP
> > + - USB2BXHP2A
> > + - USB2BXHPD1
> > + - USB3AXH
> > + - USB3AXH2B
> > + - USB3AXHD
> > + - USB3AXHP
> > + - USB3AXHP2B
> > + - USB3AXHPD
> > + - USB3BXH
> > + - USB3BXH2A
> > + - USB3BXHD
> > + - USB3BXHP
> > + - USB3BXHP2A
> > + - USB3BXHPD
> > + - VB
> > + - VGADDC
> > +
> > + groups:
> > + enum:
> > + - EMMCCDN
> > + - EMMCG1
> > + - EMMCG4
> > + - EMMCG8
> > + - EMMCWPN
> > + - JTAG0
> > + - PCIERC0PERST
> > + - PCIERC1PERST
> > + - TSPRSTN
> > + - UFSCLKI
> > + - USB2A
> > + - USB2AAP
> > + - USB2ABP
> > + - USB2ADAP
> > + - USB2AH
> > + - USB2AHAP
> > + - USB2B
> > + - USB2BAP
> > + - USB2BBP
> > + - USB2BDBP
> > + - USB2BH
> > + - USB2BHBP
> > + - USB3A
> > + - USB3AAP
> > + - USB3ABP
> > + - USB3B
> > + - USB3BAP
> > + - USB3BBP
> > + - VB0
> > + - VB1
> > + - VGADDC
> > + pins:
> > + enum:
> > + - AB13
> > + - AB14
> > + - AC13
> > + - AC14
> > + - AD13
> > + - AD14
> > + - AE13
> > + - AE14
> > + - AE15
> > + - AF13
> > + - AF14
> > + - AF15
> Why do you have groups and pins?
> Is it valid in your device to have groups and pins in the same node?
The intent is to support both group-based mux selection and
configuration, as well as per-pin configuration.
In our hardware:
- `function` + `groups` are used for pinmux selection.
- `pins` is used for per-pin configuration (e.g. drive strength,
bias settings).
- `groups` may also be used for group-level configuration.
As a result, both `groups` and `pins` may appear in the same node,
but they serve different purposes and do not conflict:
- `groups` selects the mux function and may apply configuration to
the entire group.
- `pins` allows overriding or specifying configuration for individual
pins.
In most cases, only one of them is needed, but both are allowed when
both group-level and per-pin configuration are required.
Thanks
Billy Tsai
^ permalink raw reply
* [PATCH] dt-bindings: Remove the redundant 'type: boolean'
From: phucduc.bui @ 2026-04-17 2:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt
Cc: nick, dmitry.torokhov, nicolas.ferre, alexandre.belloni,
claudiu.beznea, lee, heiko, gregkh, linusw, zyw, zhangqing,
gene_chen, linux-input, devicetree, linux-arm-kernel, linux-usb,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
The 'wakeup-source' property already has its type defined in the core
schema. Remove the redundant 'type: boolean' from the binding file to
clean up the binding files.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 3 +--
Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml | 3 +--
Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index 9bf07acea599..26ea78df27c4 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -88,8 +88,7 @@ properties:
- 2 # ATMEL_MXT_WAKEUP_GPIO
default: 0
- wakeup-source:
- type: boolean
+ wakeup-source: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
index 0676890f101e..a58d9455a1a5 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
@@ -44,8 +44,7 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- wakeup-source:
- type: boolean
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
index ae611f7e57ca..ec0d83220527 100644
--- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
@@ -33,8 +33,7 @@ properties:
vbus-supply:
description: VBUS power supply
- wakeup-source:
- type: boolean
+ wakeup-source: true
connector:
type: object
--
2.43.0
^ permalink raw reply related
* RE: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Torreno, Alexis Czezar @ 2026-04-17 1:04 UTC (permalink / raw)
To: Conor Dooley, Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <20260416-scoring-secluding-c7a7235b181a@spud>
> > >
> > > On the previous version, you got an LLM comment about not having the
> > > interrupts property amongst other things.
> > > I think the other things got implemented, but I didn't see any reply
> > > to the bot about that?
I wasn't sure if it was that type of bot. I'll try replying on the other patch review.
I just added a note in the cover letter change log about the lacking smbalert.
> > > I think the answer is that it shouldn't because the pin it
> > > referenced doesn't exist, but when looking at the schematic I have
> > > to wonder if
> >
> > I had to look this up in the datasheet. A SMBus chip with no alert pin
> > is a bit odd, but you are correct.
> >
> > > there should be an interrupts property for dealing with "pgood"?
> > >
> > FWIW, I have never seen that. Normally such pins are used to take
> > devices out of reset.
>
> It's an output on this device seemingly. I don't care if the driver ignores it, but
> for completeness (and we like completeness with
> bindings) I think it should be documented as an interrupt or gpio.
Alright, I'll add it as an interrupt: optional power-good signal
Regards,
Alexis
^ 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