* Re: [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Dmitry Baryshkov @ 2026-04-01 14:08 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <acua8Me0zo3v/CBi@hu-qianyu-lv.qualcomm.com>
On Tue, Mar 31, 2026 at 02:59:12AM -0700, Qiang Yu wrote:
> On Tue, Mar 24, 2026 at 11:23:19PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Mar 23, 2026 at 12:15:31AM -0700, Qiang Yu wrote:
> > > The third PCIe controller on Glymur SoC supports 8-lane operation via
> > > bifurcation of two PHYs (each requires separate power domian, resets and
> > > aux clk).
> > >
> > > Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
> > > clock ("phy_b_aux") required for 8-lane operation. Introduce new
> > > glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
> > >
> > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 30 +++++++++++++++++++++++++++++-
> > > 1 file changed, 29 insertions(+), 1 deletion(-)
> > >
> > > @@ -4705,6 +4713,23 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
> > > .phy_status = PHYSTATUS_4_20,
> > > };
> > >
> > > +static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
> > > + .lanes = 8,
> > > +
> > > + .offsets = &qmp_pcie_offsets_v8_50,
> > > +
> > > + .reset_list = glymur_pciephy_reset_l,
> > > + .num_resets = ARRAY_SIZE(glymur_pciephy_reset_l),
> > > + .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
> > > + .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
> >
> > Just for my understanding. If it was not the NOCSR case and had to
> > program the registers, would we have needed to program anything in the
> > PCIe3B space?
>
> The PCIe3B PHY registers need to be programmed.
> But we don't need to do it explicitly because there are also broadcast
> registers: writing to these registers will automatically write the same
> offset and value to both PHY ports simultaneously.
THanks.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
> - Qiang Yu
> >
> > > + .vreg_list = qmp_phy_vreg_l,
> > > + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> > > +
> > > + .regs = pciephy_v8_50_regs_layout,
> > > +
> > > + .phy_status = PHYSTATUS_4_20,
> > > +};
> > > +
> > > static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
> > > {
> > > const struct qmp_phy_cfg *cfg = qmp->cfg;
> > > @@ -5483,6 +5508,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
> > > }, {
> > > .compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
> > > .data = &glymur_qmp_gen5x4_pciephy_cfg,
> > > + }, {
> > > + .compatible = "qcom,glymur-qmp-gen5x8-pcie-phy",
> > > + .data = &glymur_qmp_gen5x8_pciephy_cfg,
> > > }, {
> > > .compatible = "qcom,ipq6018-qmp-pcie-phy",
> > > .data = &ipq6018_pciephy_cfg,
> > >
> > > --
> > > 2.34.1
> > >
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 0/8] i2c: rtl9300: support for RTL9607C I2C controller
From: Rustam Adilov @ 2026-04-01 14:09 UTC (permalink / raw)
To: Andi Shyti
Cc: Chris Packham, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <acxMeyVpRh9nts3d@zenone.zhora.eu>
Hello Andi,
On 2026-03-31 22:38, Andi Shyti wrote:
> Hi Rustam,
>
>> Rustam Adilov (8):
>> i2c: rtl9300: split data_reg into read and write reg
>> i2c: rtl9300: introduce max length property to driver data
>> i2c: rtl9300: introduce F_BUSY to the reg_fields struct
>> i2c: rtl9300: introduce a property for 8 bit width reg address
>> dt-bindings: i2c: realtek,rtl9301-i2c: extend for clocks and
>> RTL9607C
>> support
>> i2c: rtl9300: introduce clk struct for upcoming rtl9607 support
>> i2c: rtl9300: intoduce new function properties to driver data
>
> Patch 7 does not apply (not even in i2c-host-next, next,
> mainline). Which branch are you on? Can you please
> rebase on top of i2c/i2c-host, please?
>
> Thanks,
> Andi
>
>> i2c: rtl9300: add RTL9607C i2c controller support
As per the request of Chris Packham [1] this whole patch sets depends on
[2] to be applied
first before my patches.
I don't know if you have seen it yet cause Jan Kantert didn't include
you in the emails to
the send the patch to.
Although, i just now have noticed patch 7 has a typo in its commit
subject which i have to fix.
[1] -
https://lore.kernel.org/linux-i2c/c933a245-2b35-41a5-9eee-cb655c8231ae@alliedtelesis.co.nz/
[2] -
https://lore.kernel.org/all/20260227111134.2163701-1-jan-kernel@kantert.net/
Best,
Rustam
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur-crd: Enable DisplayPort support
From: Dmitry Baryshkov @ 2026-04-01 14:11 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260330-glymur-enable-displayport-v1-1-1543ad6dac3a@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 05:24:08PM +0300, Abel Vesa wrote:
> The two Type-C ports found on Glymur CRD are DisplayPort alternate mode
> capable. Everything is in place already for the USB, but for DisplayPort
> the controllers need to be enabled.
>
> So enable the related DisplayPort controller for each of these two
> ports. Also define the supported link frequencies for each output.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> SoCCP support is still missing, so DP altmode won't work until SoCCP
> support is added.
> ---
> arch/arm64/boot/dts/qcom/glymur-crd.dts | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/6] phy: realtek: usb2: add support for RTL9607C USB2 PHY
From: Rustam Adilov @ 2026-04-01 14:16 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel,
Michael Zavertkin
In-Reply-To: <20260331193647.nhaej266v4gudrek@skbuf>
On 2026-03-31 19:36, Vladimir Oltean wrote:
> On Tue, Mar 31, 2026 at 04:48:08PM +0000, Rustam Adilov wrote:
>> I am personally fine with removing the "force_host_disconnect = false" and other
>> falses in rtl9607_phy_cfg but i am debating because it wouldn't line up with the rest.
>
> You can also remove the other unnecessary initializations.
After thinking about it, removing other unnecessary initializations would be out of scope
for this patch series but i can remove unnecessary things introduced by my patch series,
i.e force_host_disconnect, and specifically things inside the rtl9607_phy_cfg.
Later on, someone else can clean up the rest as a separate patch.
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: soc: samsung: exynos-pmu: deprecate google,pmu-intr-gen-syscon
From: Krzysztof Kozlowski @ 2026-04-01 14:23 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-3-c5a760a3e259@linaro.org>
On 01/04/2026 06:51, Alexey Klimov wrote:
> The generic property samsung,pmu-intr-gen-syscon should be used
> by default for Samsung Exynos PMU hardware blocks. Update binding
> document to add deprecated flag for google,pmu-intr-gen-syscon
> property.
> While at this, also add dependency to not allow usage of both
> above mentioned properties in the same time.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
This should be squashed. Otherwise you add incorrect code - duplicated
property - which only later you adjust/correct.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 5/7] soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
From: Krzysztof Kozlowski @ 2026-04-01 14:26 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-5-c5a760a3e259@linaro.org>
On 01/04/2026 06:51, Alexey Klimov wrote:
> + regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
> + mask, (0 << cpu));
> +
> + regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
> +
> + regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR,
> + reg & mask);
> +
> + regmap_update_bits(pmu_context->pmureg,
> + EXYNOS850_CLUSTER_CPU_INT_EN(this_cluster, cluster_cpu),
> + 1 << 3, 0 << 3);
> + return 0;
> +}
> +
> +const struct exynos_pmu_data exynos850_pmu_data = {
> + .pmu_cpuhp = true,
> + .cpu_pmu_offline = exynos850_cpu_pmu_offline,
> + .cpu_pmu_online = exynos850_cpu_pmu_online,
> +};
> +
Unnecessary blank line.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] MAINTAINERS: add exynos850-pmu.c to Exynos850 entry
From: Krzysztof Kozlowski @ 2026-04-01 14:28 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-6-c5a760a3e259@linaro.org>
On 01/04/2026 06:51, Alexey Klimov wrote:
> Update Exynos850 entry to include new file
> drivers/soc/samsung/exynos850-pmu.c. Add myself as M
> there.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e14e6f874e05..4b28e92b4d9b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23601,6 +23601,7 @@ F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
>
> SAMSUNG EXYNOS850 SoC SUPPORT
> M: Sam Protsenko <semen.protsenko@linaro.org>
> +M: Alexey Klimov <alexey.klimov@linaro.org>
I am surprised to see this because I did not find many reviews from your
side before.
Please first engage in reviewing of this platform, before assigning
yourself as a maintainer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: exynos850: add PMU interrupt generation node
From: Krzysztof Kozlowski @ 2026-04-01 14:29 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-7-c5a760a3e259@linaro.org>
On 01/04/2026 06:52, Alexey Klimov wrote:
> Add pmu_intr_gen node for Exynos850. This hw block is required
> for different power management routines like CPU hotplug and
> different sleep and idle states.
> Also reference this node from main PMU node.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
I took a brief look at other patches and seemed fine. Anyway, my tree is
currently closed for new features till the end of the merge window so I
will probably take a more detailed look after it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-04-01 14:37 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <93a78bc2-4fd1-41bd-bf4a-b433b06fc218@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>
>
> On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
> > On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
> > > PSCI supports different types of resets like COLD reset, ARCH WARM
> > > reset, vendor-specific resets. Currently there is no common driver that
> > > handles all supported psci resets at one place. Additionally, there is
> > > no common mechanism to issue the supported psci resets from userspace.
> > >
> > > Add a PSCI reboot mode driver and define two types of PSCI resets in the
> > > driver as reboot-modes: predefined resets controlled by Linux
> > > reboot_mode and customizable resets defined by SoC vendors in their
> > > device tree under the psci:reboot-mode node.
> > >
> > > Register the driver with the reboot-mode framework to interface these
> > > resets to userspace. When userspace initiates a supported command, pass
> > > the reset arguments to the PSCI driver to enable command-based reset.
> > >
> > > This change allows userspace to issue supported PSCI reset commands
> > > using the standard reboot system calls while enabling SoC vendors to
> > > define their specific resets for PSCI.
> > >
> > > Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> > > ---
> > > drivers/power/reset/Kconfig | 10 +++
> > > drivers/power/reset/Makefile | 1 +
> > > drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
> > > 3 files changed, 130 insertions(+)
> > >
> > > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > > index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
> > > --- a/drivers/power/reset/Kconfig
> > > +++ b/drivers/power/reset/Kconfig
> > > @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
> > > then the bootloader can read it and take different
> > > action according to the mode.
> > > +config PSCI_REBOOT_MODE
> > > + bool "PSCI reboot mode driver"
> > > + depends on OF && ARM_PSCI_FW
> > > + select REBOOT_MODE
> > > + help
> > > + Say y here will enable PSCI reboot mode driver. This gets
> > > + the PSCI reboot mode arguments and passes them to psci
> > > + driver. psci driver uses these arguments for issuing
> > > + device reset into different boot states.
> > > +
> > > config POWER_MLXBF
> > > tristate "Mellanox BlueField power handling driver"
> > > depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
> > > diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> > > index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
> > > --- a/drivers/power/reset/Makefile
> > > +++ b/drivers/power/reset/Makefile
> > > @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
> > > obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> > > obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> > > obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
> > > +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
> > > obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
> > > diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
> > > --- /dev/null
> > > +++ b/drivers/power/reset/psci-reboot-mode.c
> > > @@ -0,0 +1,119 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > > + */
> > > +
> > > +#include <linux/device/faux.h>
> > > +#include <linux/device.h>
> >
> > Nit: swap the two.
>
> Ack. thanks.
>
>
> > > +#include <linux/err.h>
> > > +#include <linux/of.h>
> > > +#include <linux/psci.h>
> > > +#include <linux/reboot.h>
> > > +#include <linux/reboot-mode.h>
> > > +#include <linux/types.h>
> > > +
> > > +/*
> > > + * Predefined reboot-modes are defined as per the values
> > > + * of enum reboot_mode defined in the kernel: reboot.c.
> > > + */
> > > +static struct mode_info psci_resets[] = {
> > > + { .mode = "warm", .magic = REBOOT_WARM},
> > > + { .mode = "soft", .magic = REBOOT_SOFT},
> > > + { .mode = "cold", .magic = REBOOT_COLD},
These strings match the command userspace issue right ? I think that we
should make them match the corresponding PSCI reset types, the list above
maps command to reboot_mode values and those can belong to any reboot
mode driver to be honest they don't make much sense in a PSCI reboot
mode driver only.
It is a question for everyone here: would it make sense to make these
predefined resets a set of strings, eg:
psci-system-reset
psci-system-reset2-arch-warm-reset
and then vendor resets:
psci-system-reset2-vendor-reset
at least we know what a string maps to ?
We can export a function from the PSCI driver to detect whether PSCI
SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
instance that we can call from this driver to detect its presence.
> > > +};
> > > +
> > > +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
> > > +{
> > > + INIT_LIST_HEAD(&reboot->predefined_modes);
> > > + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
> > > + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
> > > + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
> >
> > This looks weird to me, why can't we just initialize the array with the values
> > directly ?
>
> Ack. The idea was to avoid Typecasting. Will check on this.
>
> > > + INIT_LIST_HEAD(&psci_resets[i].list);
> > > + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
> > > + }
> > > +}
> > > +
> > > +/*
> > > + * arg1 is reset_type(Low 32 bit of magic).
> > > + * arg2 is cookie(High 32 bit of magic).
> > > + * If reset_type is 0, cookie will be used to decide the reset command.
> > > + */
> > > +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
> > > +{
> > > + u32 reset_type = REBOOT_MODE_ARG1(magic);
> > > + u32 cookie = REBOOT_MODE_ARG2(magic);
> > > +
> > > + if (reset_type == 0) {
> > > + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
> > > + psci_set_reset_cmd(true, 0, 0);
> > > + else
> > > + psci_set_reset_cmd(false, 0, 0);
> > > + } else {
> > > + psci_set_reset_cmd(true, reset_type, cookie);
> > > + }
> >
> > I don't think that psci_set_reset_cmd() has the right interface (and this
> > nested if is too complicated for my taste). All we need to pass is reset-type
> > and cookie (and if the reset is one of the predefined ones, reset-type is 0
> > and cookie is the REBOOT_* cookie).
> >
> > Then the PSCI firmware driver will take the action according to what
> > resets are available.
> >
> > How does it sound ?
>
> So we mean these checks will move to the psci driver? Sorry for re-iterating
> the question.
Given what I say above, I believe that something we can do is mapping the magic
to an enum like:
PSCI_SYSTEM_RESET
PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET
PSCI_SYSTEM_RESET2_VENDOR_RESET
and can add a probe function into PSCI driver similar to psci_has_osi_support() but
to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly,
depending on its presence.
It is getting a bit hairy, agreed, but I am not sure there is cleaner ways
of pulling this off.
Lorenzo
>
> > > +
> > > + return NOTIFY_DONE;
> > > +}
> > > +
> > > +static int psci_reboot_mode_register_device(struct faux_device *fdev)
> > > +{
> > > + struct reboot_mode_driver *reboot;
> > > + int ret;
> > > +
> > > + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
> > > + if (!reboot)
> > > + return -ENOMEM;
> > > +
> > > + psci_reboot_mode_set_predefined_modes(reboot);
> > > + reboot->write = psci_reboot_mode_write;
> > > + reboot->dev = &fdev->dev;
> > > +
> > > + ret = devm_reboot_mode_register(&fdev->dev, reboot);
> > > + if (ret) {
> > > + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int __init psci_reboot_mode_init(void)
> > > +{
> > > + struct device_node *psci_np;
> > > + struct faux_device *fdev;
> > > + struct device_node *np;
> > > + int ret;
> > > +
> > > + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> > > + if (!psci_np)
> > > + return -ENODEV;
> > > + /*
> > > + * Look for reboot-mode in the psci node. Even if the reboot-mode
> > > + * node is not defined in psci, continue to register with the
> > > + * reboot-mode driver and let the dev.ofnode be set as NULL.
> > > + */
> > > + np = of_find_node_by_name(psci_np, "reboot-mode");
> > > +
> > > + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
> >
> > Same comment as Bartosz (have you picked up his work and working towards
> > a solution) ?
> Working on this via MFD. Some issue as again MFD framework does not allows a
> fwnode based driver registration. Will update.
>
> thanks,
> Shivendra
^ permalink raw reply
* Re: [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Bjorn Andersson @ 2026-04-01 14:41 UTC (permalink / raw)
To: Qiang Yu
Cc: Dmitry Baryshkov, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <acua8Me0zo3v/CBi@hu-qianyu-lv.qualcomm.com>
On Tue, Mar 31, 2026 at 02:59:12AM -0700, Qiang Yu wrote:
> On Tue, Mar 24, 2026 at 11:23:19PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Mar 23, 2026 at 12:15:31AM -0700, Qiang Yu wrote:
> > > The third PCIe controller on Glymur SoC supports 8-lane operation via
> > > bifurcation of two PHYs (each requires separate power domian, resets and
> > > aux clk).
> > >
> > > Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
> > > clock ("phy_b_aux") required for 8-lane operation. Introduce new
> > > glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
> > >
> > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 30 +++++++++++++++++++++++++++++-
> > > 1 file changed, 29 insertions(+), 1 deletion(-)
> > >
> > > @@ -4705,6 +4713,23 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
> > > .phy_status = PHYSTATUS_4_20,
> > > };
> > >
> > > +static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
> > > + .lanes = 8,
> > > +
> > > + .offsets = &qmp_pcie_offsets_v8_50,
> > > +
> > > + .reset_list = glymur_pciephy_reset_l,
> > > + .num_resets = ARRAY_SIZE(glymur_pciephy_reset_l),
> > > + .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
> > > + .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
> >
> > Just for my understanding. If it was not the NOCSR case and had to
> > program the registers, would we have needed to program anything in the
> > PCIe3B space?
>
> The PCIe3B PHY registers need to be programmed.
Why?
Regards,
Bjorn
> But we don't need to do it explicitly because there are also broadcast
> registers: writing to these registers will automatically write the same
> offset and value to both PHY ports simultaneously.
>
> - Qiang Yu
> >
> > > + .vreg_list = qmp_phy_vreg_l,
> > > + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> > > +
> > > + .regs = pciephy_v8_50_regs_layout,
> > > +
> > > + .phy_status = PHYSTATUS_4_20,
> > > +};
> > > +
> > > static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
> > > {
> > > const struct qmp_phy_cfg *cfg = qmp->cfg;
> > > @@ -5483,6 +5508,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
> > > }, {
> > > .compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
> > > .data = &glymur_qmp_gen5x4_pciephy_cfg,
> > > + }, {
> > > + .compatible = "qcom,glymur-qmp-gen5x8-pcie-phy",
> > > + .data = &glymur_qmp_gen5x8_pciephy_cfg,
> > > }, {
> > > .compatible = "qcom,ipq6018-qmp-pcie-phy",
> > > .data = &ipq6018_pciephy_cfg,
> > >
> > > --
> > > 2.34.1
> > >
> >
> > --
> > With best wishes
> > Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/4] Input: aw86938 - add driver for Awinic AW86938
From: Luca Weiss @ 2026-04-01 14:44 UTC (permalink / raw)
To: Dmitry Torokhov, Griffin Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Luca Weiss, linux-input, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <aae7fRYaoDHMptyu@google.com>
Hi Dmitry,
On Wed Mar 4, 2026 at 5:56 AM CET, Dmitry Torokhov wrote:
> On Mon, Mar 02, 2026 at 11:50:27AM +0100, Griffin Kroah-Hartman wrote:
>> Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
>>
>> The AW86938 has a similar but slightly different register layout. In
>> particular, the boost mode register values.
>> The AW86938 also has some extra features that aren't implemented
>> in this driver yet.
>>
>> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
>
> Applied, thank you.
I'm curious, where did you apply these patches? linux-next doesn't have
it and I don't see it in your kernel.org repo either.
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
Did this slip through the cracks or will these patches still appear
there?
Regards
Luca
^ permalink raw reply
* Re: [PATCH net-next v2 6/9] net: dsa: lan9645x: add vlan support
From: Jens Emil Schulz Ostergaard @ 2026-04-01 14:44 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195633.2789187-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: dsa: lan9645x: add vlan support
>
> Add support for vlanaware bridge. We reserve vid 4095 for standalone
> mode, to implement fdb-isolation. A vlan-unaware bridge uses vid 0.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > index 599e589c4ec3..046c95a72242 100644
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> [ ... ]
> > @@ -535,11 +536,54 @@ static void lan9645x_port_bridge_leave(struct dsa_switch *ds, int port,
> [ ... ]
> > +static int lan9645x_port_vlan_filtering(struct dsa_switch *ds, int port,
> > + bool enabled,
> > + struct netlink_ext_ack *extack)
> > +{
> > + struct lan9645x *lan9645x = ds->priv;
> > + struct lan9645x_port *p;
> > +
> > + p = lan9645x_to_port(lan9645x, port);
> > + p->vlan_aware = enabled;
> > + lan9645x_vlan_port_apply(p);
>
> In other places, the driver avoids calling egress functions on the npi
> port because it conflicts with cpu port header extraction. Since this
> unconditionally applies the vlan configuration to both ingress and egress,
> could this overwrite the npi port's configuration when the state is
> synchronized?
>
It is true we avoid this, but the vlan_filtering is not called by DSA core for
the cpu port, only user ports.
> > +
> > + return 0;
> > +}
> > +
> > +static int lan9645x_port_vlan_add(struct dsa_switch *ds, int port,
> [ ... ]
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_vlan.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_vlan.c
> > new file mode 100644
> > index 000000000000..0459932a626c
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_vlan.c
> [ ... ]
> > +static void lan9645x_vlan_hw_wr(struct lan9645x *lan9645x, u16 vid)
> > +{
> > + struct lan9645x_vlan *v = &lan9645x->vlans[vid];
> > + bool cpu_dis = !(v->portmask & BIT(CPU_PORT));
> > + u32 val;
> > +
> > + val = ANA_VLANTIDX_VLAN_PGID_CPU_DIS_SET(cpu_dis) |
> > + ANA_VLANTIDX_V_INDEX_SET(vid) |
> > + ANA_VLANTIDX_VLAN_SEC_FWD_ENA_SET(v->s_fwd_ena) |
> > + ANA_VLANTIDX_VLAN_FLOOD_DIS_SET(v->fld_dis) |
> > + ANA_VLANTIDX_VLAN_PRIV_VLAN_SET(v->prv_vlan) |
> > + ANA_VLANTIDX_VLAN_LEARN_DISABLED_SET(v->lrn_dis) |
> > + ANA_VLANTIDX_VLAN_MIRROR_SET(v->mir) |
> > + ANA_VLANTIDX_VLAN_SRC_CHK_SET(v->src_chk);
> > +
> > + lan_wr(val, lan9645x, ANA_VLANTIDX);
> > + lan_wr(v->portmask, lan9645x, ANA_VLAN_PORT_MASK);
> > + lan_wr(VLANACCESS_CMD_WRITE, lan9645x, ANA_VLANACCESS);
>
> Are these registers written with raw values rather than using their respective
> set macros? This circumvents the register abstraction and might risk failures
> if the hardware layout changes.
>
Yes, they are single field registers. I can add the macro.
> > +
> > + if (lan9645x_vlan_wait_for_completion(lan9645x))
> > + dev_err(lan9645x->dev, "Vlan set mask failed\n");
> > +}
> [ ... ]
> > +static void
> > +lan9645x_vlan_port_apply_egress(struct lan9645x_port *p,
> > + struct lan9645x_vlan_port_info *info)
> > +{
> [ ... ]
> > + lan_rmw(REW_TAG_CFG_TAG_TPID_CFG_SET(3) |
> > + REW_TAG_CFG_TAG_CFG_SET(tag_cfg),
> > + REW_TAG_CFG_TAG_TPID_CFG |
> > + REW_TAG_CFG_TAG_CFG,
> > + lan9645x, REW_TAG_CFG(p->chip_port));
> > +
> > + lan_rmw(REW_PORT_VLAN_CFG_PORT_TPID_SET(ETH_P_8021AD) |
> > + REW_PORT_VLAN_CFG_PORT_VID_SET(port_vid),
> > + REW_PORT_VLAN_CFG_PORT_TPID |
> > + REW_PORT_VLAN_CFG_PORT_VID,
> > + lan9645x, REW_PORT_VLAN_CFG(p->chip_port));
> > +}
>
> Setting the port tpid to 0x88a8 causes untagged ingress frames to egress trunk
> ports with 802.1ad tags. Could this break interoperability with standard
> networks that expect 0x8100 tags?
>
No that is not how it works. I think the comment which is left out explains this
clearly. 0x8100 tags are unaffected by this, but it means an stag is not rewritten
to a ctag.
> > +static void lan9645x_vlan_port_apply_ingress(struct lan9645x_port *p)
> > +{
> [ ... ]
> > + /* Drop frames with multicast source address */
> > + val = ANA_DROP_CFG_DROP_MC_SMAC_ENA_SET(1);
> > + if (p->vlan_aware && !pvid)
> > + /* If port is vlan-aware and tagged, drop untagged and priority
> > + * tagged frames.
> > + */
> > + val |= ANA_DROP_CFG_DROP_UNTAGGED_ENA_SET(1) |
> > + ANA_DROP_CFG_DROP_PRIO_S_TAGGED_ENA_SET(1) |
> > + ANA_DROP_CFG_DROP_PRIO_C_TAGGED_ENA_SET(1);
> > +
> > + lan_wr(val, lan9645x, ANA_DROP_CFG(p->chip_port));
> > +}
>
> Does this overwrite the entire 32-bit register and silently clear other
> initialized bitfields? Would it be safer to use a read-modify-write here
> instead?
>
Yes this is intentional. I prefer this over writing all fields with rmw which is
slower.
> [ ... ]
> > +static int lan9645x_vlan_cpu_add(struct lan9645x_port *p, u16 vid, bool pvid,
> > + bool untagged)
> > +{
> > + struct lan9645x_vlan *v;
> > +
> > + v = lan9645x_vlan_port_modify(p, vid, pvid, untagged);
>
> Is it intentional that this bypasses the bounds check on the vlan id?
>
No, I will move the cpu action below the bounds check.
> > + v->portmask |= BIT(CPU_PORT) | BIT(p->chip_port);
> > + lan9645x_vlan_hw_wr(p->lan9645x, vid);
> > + lan9645x_vlan_port_apply_ingress(p);
> > +
> > + return 0;
> > +}
> > +
> > +int lan9645x_vlan_port_add_vlan(struct lan9645x_port *p, u16 vid, bool pvid,
> > + bool untagged, struct netlink_ext_ack *extack)
> > +{
> [ ... ]
> > +void lan9645x_vlan_port_del_vlan(struct lan9645x_port *p, u16 vid)
> > +{
> > + struct lan9645x *lan9645x = p->lan9645x;
> > + struct lan9645x_vlan *v;
> > +
> > + if (!vid)
> > + return;
> > +
> > + v = lan9645x_vlan_port_modify(p, vid, false, false);
>
> There is a check for the maximum vlan id when adding a vlan, but no bounds
> check when deleting one. Could userspace use this to delete the reserved
> vid 4095 and break standalone forwarding?
>
I will add the bounds check for delete.
> > + v->portmask &= ~BIT(p->chip_port);
> > +
> > + if (p->chip_port == lan9645x->npi)
> > + v->portmask &= ~BIT(CPU_PORT);
> > +
> > + lan9645x_vlan_hw_wr(lan9645x, vid);
> [ ... ]
> > +void lan9645x_vlan_init(struct lan9645x *lan9645x)
> > +{
> [ ... ]
> > + for (vid = 1; vid < VLAN_N_VID; vid++)
> > + lan9645x_vlan_hw_wr(lan9645x, vid);
>
> If the indirect table access times out, the write function prints an error
> but does not return a status code. Will this cause the initialization loop
> to stall for the full timeout duration 4095 consecutive times if the
> hardware is unresponsive?
>
Yes, I can return the err from vlan_hw_wr and return it early from vlan_init.
> > +
> > + /* Set all the ports + cpu to be part of HOST_PVID and UNAWARE_PVID */
> > + lan9645x->vlans[HOST_PVID].portmask = all_ports;
^ permalink raw reply
* Re: [PATCH v5 0/2] Add support for Texas Instruments INA4230 power monitor
From: Guenter Roeck @ 2026-04-01 14:50 UTC (permalink / raw)
To: Rob Herring, Alexey Charkov
Cc: Krzysztof Kozlowski, Conor Dooley, linux-hwmon, devicetree,
linux-kernel, Krzysztof Kozlowski
In-Reply-To: <CAL_JsqJcqMM1LK1dEFvjRWdOc8g=7+G4VvF-jmzbSJ1ijBB=1A@mail.gmail.com>
On 4/1/26 07:03, Rob Herring wrote:
> On Tue, Mar 31, 2026 at 11:46 AM Alexey Charkov <alchark@flipper.net> wrote:
>>
>> On Tue, Mar 31, 2026 at 8:10 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>
>>> On 3/31/26 08:52, Rob Herring wrote:
>>>> On Mon, Mar 30, 2026 at 09:07:32AM -0700, Guenter Roeck wrote:
>>>>> On 3/30/26 08:14, Alexey Charkov wrote:
>>>>>> TI INA4230 is a 4-channel power monitor with I2C interface, similar in
>>>>>> operation to INA3221 (3-channel) and INA219 (single-channel) but with
>>>>>> a different register layout, different alerting mechanism and slightly
>>>>>> different support for directly reading calculated current/power/energy
>>>>>> values (pre-multiplied by the device itself and needing only to be scaled
>>>>>> by the driver depending on its selected LSB unit values).
>>>>>>
>>>>>> In this initial implementation, the driver supports reading voltage,
>>>>>> current, power and energy values, but does not yet support alerts, which
>>>>>> can be added separately if needed. Also the overflows during hardware
>>>>>> calculations are not yet handled, nor is the support for the device's
>>>>>> internal 32-bit energy counter reset.
>>>>>>
>>>>>> An example device tree using this binding and driver is available at [1]
>>>>>> (not currently upstreamed, as the device in question is in engineering
>>>>>> phase and not yet publicly available)
>>>>>>
>>>>>> [1] https://github.com/flipperdevices/flipper-linux-kernel/blob/flipper-devel/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts
>>>>>>
>>>>>> Signed-off-by: Alexey Charkov <alchark@flipper.net>
>>>>>> ---
>>>>>> Changes in v5:
>>>>>> - Reworded per-channel subnodes description in the binding for clarity (Sashiko)
>>>>>> - NB: Sashiko's suggestion to allow interrupts in the binding sounds premature,
>>>>>> as the alerts mechanism is not implemented yet and there are no known users
>>>>>> to test it. If anyone has hardware with the alert pins wired to an interrupt
>>>>>> line - please shout and we can test/extend it together
>>>>>
>>>>> The bindings are supposed to be complete, even if not implemented, so I am not sure
>>>>> if the DT maintainers will agree here. We'll see.
>>>>
>>>> Given ti,alert-polarity-active-high is added seems like the interrupt
>>>> should be too. And the interrupt can specify the polarity, so is that
>>>> property really needed? There's alway the possibility that you have some
>>>> inverter on the board too and the interrupt polarity is not enough, but
>>>> solve that problem when it actually exists.
>>>>
>>>
>>> The alert pin can be attached to a board interrupt, or (more likely) it can
>>> be attached to the I2C controller's alert pin. In the latter case there is
>>> no interrupt property.
>>
>> Alright, I will add the interrupt property and keep the dedicated flag
>> for alert polarity.
>>
>> Following the logic of binding completeness, should I add a flag for
>> the single-shot mode too, even though I dropped that functionality
>> from the driver in one of the prior iterations?
>
> I don't remember what that was exactly, but that sounds like a user
> selection which would be some sysfs or other runtime control rather
> than in DT. Unless the h/w design dictates what mode should be used.
>
I agree. I can not imagine that to be a hardware design constraint.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Andy Shevchenko @ 2026-04-01 14:56 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260401-dev_ad5706r-v4-2-a785184a8d53@analog.com>
On Wed, Apr 01, 2026 at 06:20:04PM +0800, Alexis Czezar Torreno wrote:
> Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> current output digital-to-analog converter with SPI interface.
>
> Features:
> - 4 independent DAC channels
> - Hardware and software LDAC trigger
> - Configurable output range
> - PWM-based LDAC control
> - Dither and toggle modes
> - Dynamically configurable SPI speed
...
> ---
> Changes since v1:
> - Removed PWM, GPIO, clock generator, debugfs, regmap, IIO_BUFFER
> - Removed all custom ext_info sysfs attributes
> - Simplified to basic raw read/write and read-only scale
> - SPI read/write can handle multibyte registers
> ---
A bit confusing to have this changelog w/o having v3..v4 ones.
...
> +config AD5706R
> + tristate "Analog Devices AD5706R DAC driver"
> + depends on SPI
Shouldn't you select REGMAP?
> + help
> + Say yes here to build support for Analog Devices AD5706R 4-channel,
> + 16-bit current output DAC.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad5706r.
...
> +#include <linux/array_size.h>
> +#include <linux/bits.h>
> +#include <linux/device.h>
Not used, but dev_printk.h is missing.
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
No need (in most cases) when err.h is included.
> +#include <linux/iio/iio.h>
> +#include <linux/minmax.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/spi/spi.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
Based on the above comments, please revisit the header block.
...
> +struct ad5706r_state {
> + struct spi_device *spi;
> + struct regmap *regmap;
> +
> + u8 tx_buf[4] __aligned(ARCH_DMA_MINALIGN);
Don't we have specific IIO macro for that?
> + u8 rx_buf[4];
> +};
...
> +static int ad5706r_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes;
Currently only 1 and 2 bytes are supported, right? Any updates are planned on
this in the future?
> + u16 reg;
> +
> + reg = get_unaligned_be16(data);
> + num_bytes = ad5706r_reg_len(reg);
> +
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .len = num_bytes + 2,
> + };
> +
> + memcpy(st->tx_buf, data, count);
> +
> + /* For single byte, copy the data to the correct position */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + st->tx_buf[2] = st->tx_buf[3];
> +
> + return spi_sync_transfer(st->spi, &xfer, 1);
> +}
> +
> +static int ad5706r_regmap_read(void *context, const void *reg_buf,
> + size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes;
> + u16 reg, cmd;
> + int ret;
> +
> + reg = get_unaligned_be16(reg_buf);
> + num_bytes = ad5706r_reg_len(reg);
> +
> + /* Full duplex, device responds immediately after command */
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .rx_buf = st->rx_buf,
> + .len = 2 + num_bytes,
> + };
> +
> + cmd = AD5706R_RD_MASK | (reg & AD5706R_ADDR_MASK);
> + put_unaligned_be16(cmd, st->tx_buf);
> + memset(st->tx_buf + 2, 0, num_bytes);
I would use &st->tx_buf[2] here and below for the sake of consistency with
put_unaligned_*().
> + ret = spi_sync_transfer(st->spi, &xfer, 1);
> + if (ret)
> + return ret;
> +
> + /* Ignore the first two bytes (echo during command) */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + put_unaligned_be16(st->rx_buf[2], val_buf);
The comment wants to explain why it's required to put 2 bytes anyway.
> + else
> + memcpy(val_buf, st->rx_buf + 2, num_bytes);
However with the above question in mind, if it's all about 1 or 2 bytes, can't
we simply use the same approach everywhere, like put_unaligned_*()?
> + return 0;
> +}
...
> +static int ad5706r_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
Better to use logical split (here and elsewhere where appropriate)
static int ad5706r_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val, int *val2, long mask)
...
> + st->regmap = devm_regmap_init(&spi->dev, &ad5706r_regmap_bus,
> + st, &ad5706r_regmap_config);
Use
struct device *dev = &spi->dev;
at the top of the function to make this look better.
> + if (IS_ERR(st->regmap))
> + return dev_err_probe(&spi->dev, PTR_ERR(st->regmap),
> + "Failed to init regmap");
Missing \n.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Arnd Bergmann @ 2026-04-01 14:56 UTC (permalink / raw)
To: Lorenzo Pieralisi, Shivendra Pratap
Cc: Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, André Draszik, Kathiravan Thirumoorthy,
linux-pm, linux-kernel, linux-arm-kernel, linux-arm-msm,
devicetree, Srinivas Kandagatla
In-Reply-To: <ac0trUGsRBLPS+ux@lpieralisi>
On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>
>> > > +#include <linux/err.h>
>> > > +#include <linux/of.h>
>> > > +#include <linux/psci.h>
>> > > +#include <linux/reboot.h>
>> > > +#include <linux/reboot-mode.h>
>> > > +#include <linux/types.h>
>> > > +
>> > > +/*
>> > > + * Predefined reboot-modes are defined as per the values
>> > > + * of enum reboot_mode defined in the kernel: reboot.c.
>> > > + */
>> > > +static struct mode_info psci_resets[] = {
>> > > + { .mode = "warm", .magic = REBOOT_WARM},
>> > > + { .mode = "soft", .magic = REBOOT_SOFT},
>> > > + { .mode = "cold", .magic = REBOOT_COLD},
>
> These strings match the command userspace issue right ? I think that we
> should make them match the corresponding PSCI reset types, the list above
> maps command to reboot_mode values and those can belong to any reboot
> mode driver to be honest they don't make much sense in a PSCI reboot
> mode driver only.
>
> It is a question for everyone here: would it make sense to make these
> predefined resets a set of strings, eg:
>
> psci-system-reset
> psci-system-reset2-arch-warm-reset
>
> and then vendor resets:
>
> psci-system-reset2-vendor-reset
>
> at least we know what a string maps to ?
>
> We can export a function from the PSCI driver to detect whether PSCI
> SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
> instance that we can call from this driver to detect its presence.
Sorry I've been out of the loop for this series for a while, but
can someone refresh me on why we got back to mixing in
the 'enum reboot_mode' from legacy i386 and arm32 into the new
interface?
I don't mind having whichever strings are defined for PSCI present
in the user interface, but this seems like a mistake to me.
If at all possible, lets define your own magic constants that
are not tied to "enum reboot_mode" or the legacy reboot= command
line argument.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v2 7/9] net: dsa: lan9645x: add mac table integration
From: Jens Emil Schulz Ostergaard @ 2026-04-01 15:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195635.2789227-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: dsa: lan9645x: add mac table integration
>
> Add MAC table support, and dsa fdb callback integration. The mactable is
> keyed on (vid,mac) and each bucket has 4 slots. A mac table entry typically
> points to a PGID index, the first 9 of which represent a front port.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_mac.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_mac.c
> > index 000000000000..6335714dca21
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_mac.c
> [ ... ]
> > +int lan9645x_mact_entry_add(struct lan9645x *lan9645x, int pgid,
> > + const unsigned char *mac, u16 vid)
> > +{
> > + struct lan9645x_mact_entry *entry;
> > + int err;
> > +
> > + mutex_lock(&lan9645x->mact_lock);
> > +
> > + /* Users can not move (vid,mac) to a different port, without removing
> > + * the original entry first. But we overwrite entry in HW, and update
> > + * software pgid for good measure.
> > + */
> > + entry = lan9645x_mact_entry_find(lan9645x, mac, vid);
> > + if (entry) {
> > + entry->common.pgid = pgid;
> > + goto mac_learn;
> > + }
> > +
> > + entry = lan9645x_mact_entry_alloc(lan9645x, mac, vid, pgid,
> > + ENTRYTYPE_LOCKED);
> > + if (!entry) {
> > + mutex_unlock(&lan9645x->mact_lock);
> > + return -ENOMEM;
> > + }
> > +
> > + list_add_tail(&entry->list, &lan9645x->mac_entries);
> > +
> > +mac_learn:
> > + err = __lan9645x_mact_learn(lan9645x, pgid, mac, vid, ENTRYTYPE_LOCKED);
> > + if (err)
> > + lan9645x_mact_entry_dealloc(lan9645x, entry);
>
> If a pre-existing entry is updated but the hardware learning command fails,
> will this inadvertently delete the valid software entry and cause the hardware
> and software tracking to become desynchronized?
>
I will rearrange so they stay synced.
> > +
> > + mutex_unlock(&lan9645x->mact_lock);
> > + return err;
> > +}
> > +
> > +int lan9645x_mact_entry_del(struct lan9645x *lan9645x, int pgid,
> > + const unsigned char *mac, u16 vid)
> > +{
> > + struct lan9645x_mact_entry *entry;
> > + int err;
> > +
> > + mutex_lock(&lan9645x->mact_lock);
> > +
> > + entry = lan9645x_mact_entry_find(lan9645x, mac, vid);
> > + if (!entry) {
> > + mutex_unlock(&lan9645x->mact_lock);
> > + return -ENOENT;
> > + }
> > +
> > + WARN_ON(entry->common.pgid != pgid);
> > + lan9645x_mact_entry_dealloc(lan9645x, entry);
> > + err = __lan9645x_mact_forget(lan9645x, mac, vid, ENTRYTYPE_LOCKED);
>
> Does this permanently remove the software entry even if the hardware
> command to forget the entry fails?
>
Same here, I can rearrange so they stay synced.
> > +
> > + mutex_unlock(&lan9645x->mact_lock);
> > + return err;
> > +}
> [ ... ]
> > +void lan9645x_mac_deinit(struct lan9645x *lan9645x)
> > +{
> > + mutex_destroy(&lan9645x->mact_lock);
> > +}
>
> Are the static MAC entries in the mac_entries list leaked here during driver
> teardown, or are they freed elsewhere?
>
I thought DSA core would have removed them for me, but it looks like that may not be
the case. I will add dealloc during deinit.
> > +
> > +int lan9645x_mact_dsa_dump(struct lan9645x *lan9645x, int port,
> > + dsa_fdb_dump_cb_t *cb, void *data)
> > +{
> > + struct lan9645x_mact_entry entry = {};
> > + u32 mach, macl, maca;
> > + int err = 0;
> > + u32 autoage;
> [ ... ]
> > + while (1) {
> > + /* NOTE: we rely on mach, macl and type being set correctly in
> > + * the registers from previous round, vis a vis the GET_NEXT
> > + * semantics, so locking entire loop is important.
> > + */
> > + lan_wr(ANA_MACACCESS_MAC_TABLE_CMD_SET(CMD_GET_NEXT) |
> > + ANA_MACACCESS_ENTRYTYPE_SET(entry.common.type),
> > + lan9645x, ANA_MACACCESS);
> > +
> > + if (lan9645x_mac_wait_for_completion(lan9645x, &maca))
> > + break;
>
> If the hardware completion times out, the loop breaks out and returns the
> local err variable which is initialized to 0. Will this suppress the hardware
> timeout error code and incorrectly report a successful dump?
>
Yes, I will return the error.
> > +
> > + if (ANA_MACACCESS_VALID_GET(maca) == 0)
> > + break;
> > +
> > + mach = lan_rd(lan9645x, ANA_MACHDATA);
> > + macl = lan_rd(lan9645x, ANA_MACLDATA);
> > +
> > + lan9645x_mact_parse(mach, macl, maca, &entry.common);
> > +
> > + if (ANA_MACACCESS_DEST_IDX_GET(maca) == port &&
> > + entry.common.type == ENTRYTYPE_NORMAL) {
>
> Since static FDB entries are programmed with ENTRYTYPE_LOCKED, will this
> condition exclude them from the FDB dump, preventing them from showing up
> during bridge FDB queries?
>
Yes that is intentional. This is for the dynamic entries which the bridge core does not
know about.
> > + if (entry.common.key.vid > VLAN_MAX)
> > + entry.common.key.vid = 0;
> > +
> > + err = cb(entry.common.key.mac, entry.common.key.vid,
> > + false, data);
> > + if (err)
> > + break;
> > + }
> > + }
> > +
> > + /* Remove aging filters and restore aging */
> > + lan_wr(0, lan9645x, ANA_ANAGEFIL);
> > + lan_rmw(ANA_AUTOAGE_AGE_PERIOD_SET(ANA_AUTOAGE_AGE_PERIOD_GET(autoage)),
> > + ANA_AUTOAGE_AGE_PERIOD,
> > + lan9645x, ANA_AUTOAGE);
>
> Does restoring the ANA_AUTOAGE register using the autoage value saved at the
> start of the function race with other operations setting the aging time?
>
> If the aging time is updated concurrently without taking mact_lock, its newly
> configured aging period might be overwritten here.
>
AFAIK both run under rtnl so we do not have a race. But I will take the mact_lock during
set_ageing_time.
> > +
> > + mutex_unlock(&lan9645x->mact_lock);
> > +
> > + return err;
> > +}
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > index 046c95a72242..32c0301030a4 100644
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> [ ... ]
> > +static int lan9645x_fdb_del(struct dsa_switch *ds, int port,
> > + const unsigned char *addr, u16 vid,
> > + struct dsa_db db)
> > +{
> > + struct net_device *br = lan9645x_db2bridge(db);
> > + struct dsa_port *dp = dsa_to_port(ds, port);
> > + struct lan9645x *lan9645x = ds->priv;
> > + int err;
> > +
> > + if (IS_ERR(br))
> > + return PTR_ERR(br);
> > +
> > + if (dsa_port_is_cpu(dp) && !br &&
> > + dsa_fdb_present_in_other_db(ds, port, addr, vid, db))
> > + return 0;
> > +
> > + if (!vid)
> > + vid = lan9645x_vlan_unaware_pvid(!!br);
> > +
> > + if (dsa_port_is_cpu(dp))
> > + return lan9645x_mact_forget(lan9645x, addr, vid,
> > + ENTRYTYPE_LOCKED);
> > +
> > + err = lan9645x_mact_entry_del(lan9645x, port, addr, vid);
> > + if (err == -ENOENT) {
> > + dev_dbg(lan9645x->dev,
> > + "fdb not found port=%d addr=%pM vid=%u\n", port, addr,
> > + vid);
> > + return 0;
> > + }
> > +
> > + return err;
> > +}
>
> Since lan9645x_mact_entry_del returns -ENOENT when a MAC address is not found
> in the software tracking list, and the software list only contains statically
> added entries, won't this intercept attempts to manually delete dynamically
> learned MAC addresses and return success without actually removing them from
> the hardware table?
No I do not think this is how it works. Dynamic entries are flushed with
.port_fast_age, and port_fdb_del is for static entries. We handle -ENOENT
because DSA core does not refcount fdbs for userports.
^ permalink raw reply
* Re: [RFC PATCH 05/15] libfdt: Introduce fdt_first_node()
From: Luca Ceresoli @ 2026-04-01 15:11 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <20260210173349.636766-6-herve.codina@bootlin.com>
Hi Hervé, David,
I'm trying to review the patches that have no feedback so far.
Being new to the dtc codebase I'm mostly pointing out things that are not
clear from a newcomer point of view. I hope this helps anyway.
On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> at the offset 0 of the structure block.
>
> This assumption is not correct. Indeed, a FDT_NOP can be present at the
> offset 0 and this is a legit case.
I wonder whether this can be proven by showing an example, or the specs, or
whatever use case that makes sense.
> Introduce fdt_first_node() in order to get the offset of the first node
> (first FDT_BEGIN_NODE tag) available in a fdt blob.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> libfdt/fdt.c | 25 +++++++++++++++++++++++++
> libfdt/libfdt_internal.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/libfdt/fdt.c b/libfdt/fdt.c
> index 56d4dcb..676c7d7 100644
> --- a/libfdt/fdt.c
> +++ b/libfdt/fdt.c
> @@ -252,6 +252,31 @@ int fdt_check_prop_offset_(const void *fdt, int offset)
> return offset;
> }
>
Even though this seems to be quite uncommon in this repository, I think
documenting new functions would be helpful, especially preconditions,
postconditions and parameter values when not obvious.
What about:
Find the initial node with content (FDT_BEGIN_NODE) in a fdt, skipping
FDT_NOP [and <other tags> is applicable].
*return: pointer to the first node into the fdt or e negative error value
> +int fdt_first_node(const void *fdt)
> +{
> + int nextoffset = 0;
> + int offset;
> + uint32_t tag;
> +
> + do {
> + offset = nextoffset;
> + tag = fdt_next_tag(fdt, offset, &nextoffset);
> + switch (tag) {
> + case FDT_END_NODE:
> + case FDT_PROP:
> + return -FDT_ERR_BADSTRUCTURE;
> +
> + case FDT_BEGIN_NODE:
> + return offset;
> +
> + default:
> + break;
> + }
> + } while (tag != FDT_END);
> +
> + return (nextoffset < 0) ? nextoffset : -FDT_ERR_NOTFOUND;
> +}
> +
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH 09/15] Introduce structured tag value definition
From: Luca Ceresoli @ 2026-04-01 15:11 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <20260210173349.636766-10-herve.codina@bootlin.com>
On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> The goal of structured tag values is to ease the introduction of new
> tags in future releases with the capability for an already existing
> release to ignore those structured tags. In order to do that data length
> related to the unknown tag needs to be identify.
^
identified
> Also a flag is present
"Also add a flag"
> to tell an old release if this tag can be simply skipped or must lead to
> an error.
>
> Structured tag value is defined on 32bit and is defined as follow:
>
> Bits | 31 | 30 | 29 28 | 27 0|
> ------+----+----------+-------------------+--------+
> Fields| 1 | CAN_SKIP | DATA_LNG_ENCODING | TAG_ID |
> ------+----+----------+-------------------+--------+
>
> Bit 31 is always set to 1 to identified a structured tag value.
^
identify
> Bit 30 (CAN_SKIP) is set to 1 if the tag can be safely ignore when its
^
ignored
> TAG_ID value is not a known value (unknown tag). If the CAN_SKIP bit is
> set to 0 this tag must not be ignored and an error should be reported
> when its TAG_ID value is not a known value (unknown tag).
>
> Bits 29..28 (DATA_LNG_ENCODING) indicates the length of the data related
I think "LEN" is more common than "LNG".
> to the tag. Following values are possible:
> - 0b00: No data.
> The tag is followed by the next tag value.
>
> - 0b01: 1 cell data
> The tag is followed by a 1 cell (u32) data. The next tag is
> available after this cell.
>
> - 0b10: 2 cells data
> The tag is followed by a 2 cells (2 * u32) data. The next tag
> is available after those two cells.
>
> - 0b11: Data length encoding
> The tag is followed by a cell (u32) indicating the size of the
> data. This size is given in bytes. Data are available right
> after this cell.
>
> The next tag is available after the data. Padding is present
> after the data in order to have the next tag aligned on 32bits.
> This padding is not included in the size of the data.
>
> Bits 27..0 (TAG_ID) is the tag identifier defining a specific tag.
>
> Introduce the structured tag values definition and some specific tags
> reserved for tests based on this structure definition.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> libfdt/fdt.h | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/libfdt/fdt.h b/libfdt/fdt.h
> index a07abfc..2e07599 100644
> --- a/libfdt/fdt.h
> +++ b/libfdt/fdt.h
> @@ -49,6 +49,7 @@ struct fdt_property {
>
> #define FDT_MAGIC 0xd00dfeed /* 4: version, 4: total size */
> #define FDT_TAGSIZE sizeof(fdt32_t)
> +#define FDT_CELLSIZE sizeof(fdt32_t)
>
> #define FDT_BEGIN_NODE 0x1 /* Start node: full name */
> #define FDT_END_NODE 0x2 /* End node */
> @@ -57,6 +58,28 @@ struct fdt_property {
> #define FDT_NOP 0x4 /* nop */
> #define FDT_END 0x9
>
> +/* Tag values flags */
> +#define FDT_TAG_STRUCTURED (1<<31)
> +#define FDT_TAG_SKIP_SAFE (1<<30)
This is called CAN_SKIP in the commit message and SKIP_SAFE here. Using a
consistent name would be better IMO.
> +#define FDT_TAG_DATA_MASK (3<<28)
> +#define FDT_TAG_DATA_NONE (0<<28)
> +#define FDT_TAG_DATA_1CELL (1<<28)
> +#define FDT_TAG_DATA_2CELLS (2<<28)
> +#define FDT_TAG_DATA_LNG (3<<28)
I find _LNG (or _LEN) misleading: this is not the length, but rather an
enum value telling you the length is stored in the next cell. What about
FDT_TAG_DATA_VARLEN?
Otherwise looks good.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH 06/15] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
From: Luca Ceresoli @ 2026-04-01 15:11 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <20260210173349.636766-7-herve.codina@bootlin.com>
On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> at the offset 0 of the structure block.
>
> This assumption is not correct. Indeed, a FDT_NOP can be present at the
> offset 0 and this is a legit case.
>
> fdt_first_node() has been introduce recently to get the offset of the
^
introduced
> first node (first FDT_BEGIN_NODE) in a fdt blob.
>
> Use this function to get the first node offset instead of looking for
> this node at offset 0.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> libfdt/fdt.c | 10 ++++++++--
> libfdt/fdt_ro.c | 16 +++++++++++++---
> libfdt/fdt_rw.c | 6 ++++++
> 3 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/libfdt/fdt.c b/libfdt/fdt.c
> index 676c7d7..ff2fa6c 100644
> --- a/libfdt/fdt.c
> +++ b/libfdt/fdt.c
> @@ -279,11 +279,17 @@ int fdt_first_node(const void *fdt)
>
> int fdt_next_node(const void *fdt, int offset, int *depth)
> {
> - int nextoffset = 0;
> + int nextoffset = offset;
> uint32_t tag;
>
> + if (offset <= 0) {
What is the difference between 0 and a engative value?
This is where the parameter value is not obvious to the newcomer and I'd
love seeing it concisely documented.
Otherwise this patch looks good to me.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH 10/15] fdtdump: Handle unknown tags
From: Luca Ceresoli @ 2026-04-01 15:15 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <20260210173349.636766-11-herve.codina@bootlin.com>
On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> The structured tag value definition introduced recently gives the
> ability to ignore unknown tags without any error when they are read.
>
> Handle those structured tag.
How? This sentence is vague, what about:
Allow dumping the unknown tags or not based on a command line flag.
> --- a/fdtdump.c
> +++ b/fdtdump.c
> @@ -44,7 +44,7 @@ static const char *tagname(uint32_t tag)
> #define dumpf(fmt, args...) \
> do { if (debug) printf("// " fmt, ## args); } while (0)
>
> -static void dump_blob(void *blob, bool debug)
> +static void dump_blob(void *blob, bool debug, int dump_unknown)
> {
> uintptr_t blob_off = (uintptr_t)blob;
> struct fdt_header *bph = blob;
> @@ -146,20 +146,55 @@ static void dump_blob(void *blob, bool debug)
> continue;
> }
>
> + if ((tag & FDT_TAG_STRUCTURED) && (tag & FDT_TAG_SKIP_SAFE)) {
> + sz = 0;
> + switch (tag & FDT_TAG_DATA_MASK) {
> + case FDT_TAG_DATA_NONE:
> + break;
> + case FDT_TAG_DATA_1CELL:
> + sz = FDT_CELLSIZE;
> + break;
> + case FDT_TAG_DATA_2CELLS:
> + sz = 2 * FDT_CELLSIZE;
> + break;
> + case FDT_TAG_DATA_LNG:
> + /* Get the length */
> + sz = fdt32_to_cpu(GET_CELL(p));
> + break;
> + }
> +
> + if (dump_unknown) {
> + printf("%*s// Unknown tag ignored: 0x%08"PRIx32", data lng %d",
As before, I'd use "len" instead of "lng".
> + depth * shift, "", tag, sz);
> + if (dump_unknown > 1 && sz != 0) {
> + printf(" ");
> + for (i = 0; i < sz; i++)
> + printf("%02hhx", *(p + i));
> + }
> + printf("\n");
> + }
> +
> + /* Skip the data bytes */
> + p = PALIGN(p + sz, 4);
> + continue;
> + }
> +
> die("** Unknown tag 0x%08"PRIx32"\n", tag);
> }
> }
>
> /* Usage related data. */
> static const char usage_synopsis[] = "fdtdump [options] <file>";
> -static const char usage_short_opts[] = "ds" USAGE_COMMON_SHORT_OPTS;
> +static const char usage_short_opts[] = "dus" USAGE_COMMON_SHORT_OPTS;
> static struct option const usage_long_opts[] = {
> {"debug", no_argument, NULL, 'd'},
> + {"unknown", no_argument, NULL, 'u'},
> {"scan", no_argument, NULL, 's'},
> USAGE_COMMON_LONG_OPTS
> };
> static const char * const usage_opts_help[] = {
> "Dump debug information while decoding the file",
> + "Dump unknown tags information while decoding the file (-uu to have data)",
^
dump
> --- a/tests/trees.S
> +++ b/tests/trees.S
> @@ -328,3 +328,113 @@ named_root_strings:
> named_root_strings_end:
>
> named_root_end:
> +
> +
> + /* Tree with "unknown" tags that can be skipped
> + * Use a really future dtb version to check version downgrade on
> + * modification.
> + */
> + treehdr_vers unknown_tags_can_skip 0xffffffff 0x10
> + empty_rsvmap unknown_tags_can_skip
> +
> +unknown_tags_can_skip_struct:
> + fdtlong FDT_TEST_1CELL_CAN_SKIP
> + fdtlong 0x1
> +
> + beginn ""
> + fdtlong FDT_TEST_NONE_CAN_SKIP
> +
> + propu32 unknown_tags_can_skip, prop_int, 1
> +
> + fdtlong FDT_TEST_1CELL_CAN_SKIP
> + fdtlong 0x11
> +
> + propstr unknown_tags_can_skip, prop_str, "abcd"
> +
> + fdtlong FDT_TEST_2CELLS_CAN_SKIP
> + fdtlong 0x12
> + fdtlong 0x12
Can you use different values here, just to make the test slightly more
robust? Just in case parsing ends up on the wrong cell, as unlikely as it
can be.
Same in various places below.
> +
> + fdtlong FDT_TEST_LNG_CAN_SKIP
> + fdtlong 3
> + .byte 0x13
> + .byte 0x13
> + .byte 0x13
> + .byte 0 /* padding */
> +
> + beginn "subnode1"
> + propu64 unknown_tags_can_skip, prop_int, 1, 2
> + fdtlong FDT_TEST_NONE_CAN_SKIP
> + endn
> +
> + beginn "subnode2"
> + fdtlong FDT_TEST_1CELL_CAN_SKIP
> + fdtlong 0x121
> + propu64 unknown_tags_can_skip, prop_int1, 1, 2
> + fdtlong FDT_TEST_1CELL_CAN_SKIP
> + fdtlong 0x122
> + propu64 unknown_tags_can_skip, prop_int2, 1, 2
> + beginn "subsubnode"
> + fdtlong FDT_TEST_1CELL_CAN_SKIP
> + fdtlong 0x123
> + propu64 unknown_tags_can_skip, prop_int, 1, 2
As before, you are using values 1 and 2 for all the properties, I'd use
different values, and possibly even with different amounts of cells in
properties.
Other than these two minor nits, this patch looks very good to me.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH 11/15] flattree: Handle unknown tags
From: Luca Ceresoli @ 2026-04-01 15:15 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <20260210173349.636766-12-herve.codina@bootlin.com>
On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> The structured tag value definition introduced recently gives the
> ability to ignore unknown tags without any error when they are read.
>
> Handle those structured tag.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> +++ b/tests/unknown_tags_can_skip.dtb.dts.expect
> @@ -0,0 +1,19 @@
> +/dts-v1/;
> +
> +/ {
> + prop-int = <0x01>;
> + prop-str = "abcd";
> +
> + subnode1 {
> + prop-int = <0x01 0x02>;
> + };
> +
> + subnode2 {
> + prop-int1 = <0x01 0x02>;
> + prop-int2 = <0x01 0x02>;
> +
> + subsubnode {
> + prop-int = <0x01 0x02>;
> + };
> + };
> +};
Of course this will need updating in case you adopt the changes to the
tests I suggested in patch 10.
With that done:
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v10 0/5] Add USB2.0 VBUS mux driver and extend rzv2h-usb2phy reset for RZ/G3E support
From: Tommaso Merciai @ 2026-04-01 15:16 UTC (permalink / raw)
To: tomm.merciai, peda, p.zabel
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai, Fabrizio Castro,
Lad Prabhakar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Arnd Bergmann, Ulf Hansson,
Josua Mayer, devicetree, linux-kernel
Dear All,
The series adds:
- A new mux driver for RZ/V2H USB VBENCTL VBUS_SEL
- Updates to the rzv2h-usb2phy reset driver/bindings to support RZ/G3E.
Merge strategy, if any:
- patches 1/5 can go through the MUX tree
- patches 2-5/5 can go through the Reset tree
Thanks & Regards,
Tommaso
v9->v10:
- Rebased on top of next-20260331
- PATCH 4/5: Use struct reg_sequence and regmap_multi_reg_write()
to handle initialization, assert and deassert sequences and drop
custom struct rzv2h_usb2phy_regval.
v8->v9
- Rebased on top of next-20260326
- PATCH 1/6: Fixed driver comment year (2025 -> 2026)
- Switch from devm_regmap_init_mmio() to dev_get_regmap().
- Drop unnecessasry include bitops.h, of.h, property.h and
drivers/reset/reset-rzv2h-usb2phy.h headers, driver is now based on
regmap.
- Collected PZabel tag.
- PATCH 4/6: Collected PZabel tag.
- PATCH 5/6: New patch.
- PATCH 6/6: Drop linux/reset/reset_rzv2h_usb2phy.h dependecy as the
driver is now based on regmap and does not need the
reset driver's private header, update driver accordingly.
- Collected PZabel tag.
- Update cover letter.
v7->v8:
- Rebased on top of next-20260311
- Updated series cover letter as part of the series was already merged.
v6->v7:
- Rebased on top of next-20260128
- Split series into per subsystem series, no changes.
v5->v6:
- Rebased on top of next-20251219
- Re-arranged series order per subsystem patches.
- Patch: 3/14: Collected tag.
- Patch: 4/14: Fixed commit message.
- Split from dts patches will send separate series.
- Added merge strategy in cover letter.
v4->v5:
- Rebased on top of next-20251127
- Patch 01/22: Added Reviewed-by tag from Conor Dooley.
- Patch 06/22: Changed file name to rzv2h-usb-vbenctl.c and Fixed
Makefile, Kconfig, function names accordingly.
Changed driver .name to "vbenctl" and fix auxiliary_device_id name.
Updated commit msg.
- Patch 07/22: Update mux_name to "vbenctl" to match the driver name.
Updated commit message.
- Patch 11/22: Fixed if statement for mux_state error check.
v3->v4:
- Rebased on top of next-20251121
- Added patch 01/22 to remove nodename pattern from mux-controller schema.
- Switch back to v2 implementation for mux controller in patches
5/22, 15/22, 16/22, 21/22.
- Improved commit bodies for patches 5/22, 15/22, 16/22, 21/22.
- Removed mux_chip->dev.of_node not needed in patch 06/22.
- Collected CDooley tag in patch 09/22.
- Added missing select MULTIPLEXER into Kconfig in patch 11/22.
v2->v3:
- Rebased on top of next-20251110 + [1] + [2]
- Add missing Cc: stable@vger.kernel.org in patch 03/21
- Patch 03/21: Added missing Cc: stable@vger.kernel.org.
Improved commit body describing the removal of rzv2h_usbphy_assert_helper()
from rzv2h_usb2phy_reset_probe().
- Patch 04/21: Manipulate mux-controller as an internal node.
Improved commit body.
- Patch 05/21: The main driver is using now __devm_auxiliary_device_create()
then update the aux driver accordingly.
- Patch 06/21: Use __devm_auxiliary_device_create() to create the aux device.
- Patch 08/21: Improved commit body and mux-states description.
- Patch 14/21: Manipulate the mux controller as an internal node,
and update commit body accordingly.
- Patch 15/21: Manipulate the mux controller as an internal node,
and update commit body accordingly.
- Patch 20/21: Manipulate the mux controller as an internal node.
v1->v2:
- Rebased on top of next-20251103 + [1] + [2]
- Reworked series to use mux-state for controlling VBUS_SEL
as suggested by PZabel added also mux bindings documentation
on phy and rst side.
- Collected Conor Dooley tags
- Dropped unnecessary rzv2h_usbphy_assert_helper() function from
rzv2h_usb2phy_reset_probe()
Tommaso Merciai (5):
mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux
dt-bindings: reset: renesas,rzv2h-usb2phy: Add '#mux-state-cells'
property
dt-bindings: reset: renesas,rzv2h-usb2phy: Document RZ/G3E USB2PHY
reset
reset: rzv2h-usb2phy: Convert to regmap API
reset: rzv2h-usb2phy: Add support for VBUS mux controller registration
.../reset/renesas,rzv2h-usb2phy-reset.yaml | 9 +-
drivers/mux/Kconfig | 11 ++
drivers/mux/Makefile | 2 +
drivers/mux/rzv2h-usb-vbenctl.c | 85 +++++++++++
drivers/reset/Kconfig | 2 +
drivers/reset/reset-rzv2h-usb2phy.c | 141 +++++++++++-------
6 files changed, 196 insertions(+), 54 deletions(-)
create mode 100644 drivers/mux/rzv2h-usb-vbenctl.c
--
2.43.0
^ permalink raw reply
* [PATCH v10 1/5] mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux
From: Tommaso Merciai @ 2026-04-01 15:16 UTC (permalink / raw)
To: tomm.merciai, peda, p.zabel
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai, Fabrizio Castro,
Lad Prabhakar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Arnd Bergmann, Ulf Hansson,
Josua Mayer, devicetree, linux-kernel
In-Reply-To: <cover.1775047175.git.tommaso.merciai.xr@bp.renesas.com>
As per the RZ/V2H(P) HW manual, VBUSEN can be controlled by the VBUS_SEL
bit of the VBENCTL Control Register. This register is mapped in the
reset framework. The reset driver expose this register as mux-controller
and instantiates this driver. The consumer will use the mux API to
control the VBUS_SEL bit.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v9->v10:
- No changes.
v8->v9:
- Fixed driver comment year (2025 -> 2026)
- Switch from devm_regmap_init_mmio() to dev_get_regmap().
- Drop unnecessasry include bitops.h, of.h, property.h and
drivers/reset/reset-rzv2h-usb2phy.h headers, driver is now based on regmap.
- Collected PZabel tag.
v7->v8:
- No changes.
v6->v7:
- No changes.
v5->v6:
- No changes.
v4->v5:
- Changed file name to rzv2h-usb-vbenctl.c and Fixed
Makefile, Kconfig, function names accordingly.
- Changed driver .name to "vbenctl" and fix auxiliary_device_id name.
- Updated commit msg.
v3->v4:
- Removed mux_chip->dev.of_node not needed.
v2->v3:
- Added mux_chip->dev.of_node = dev->of_node->child as the mux-controller
is an internal node.
- Fixed auxiliary_device_id name.
- Get rdev using from platform_data.
- Drop struct auxiliary_device adev from reset_rzv2h_usb2phy_adev
as it is needed.
- Drop to_reset_rzv2h_usb2phy_adev() as it is not needed.
v1->v2:
- New patch
drivers/mux/Kconfig | 11 +++++
drivers/mux/Makefile | 2 +
drivers/mux/rzv2h-usb-vbenctl.c | 85 +++++++++++++++++++++++++++++++++
3 files changed, 98 insertions(+)
create mode 100644 drivers/mux/rzv2h-usb-vbenctl.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 6d17dfa25dad..7f334540c189 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -70,6 +70,17 @@ config MUX_MMIO
To compile the driver as a module, choose M here: the module will
be called mux-mmio.
+config MUX_RZV2H_USB_VBENCTL
+ tristate "Renesas RZ/V2H USB VBENCTL VBUS_SEL mux driver"
+ depends on RESET_RZV2H_USB2PHY || COMPILE_TEST
+ depends on OF
+ select REGMAP
+ select AUXILIARY_BUS
+ default RESET_RZV2H_USB2PHY
+ help
+ Support for USB VBENCTL VBUS_SEL mux implemented on Renesas
+ RZ/V2H SoCs.
+
endmenu
endif # MULTIPLEXER
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 6e9fa47daf56..3bd9b3846835 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -8,9 +8,11 @@ mux-adg792a-objs := adg792a.o
mux-adgs1408-objs := adgs1408.o
mux-gpio-objs := gpio.o
mux-mmio-objs := mmio.o
+mux-rzv2h-usb-vbenctl-objs := rzv2h-usb-vbenctl.o
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_ADGS1408) += mux-adgs1408.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
+obj-$(CONFIG_MUX_RZV2H_USB_VBENCTL) += mux-rzv2h-usb-vbenctl.o
diff --git a/drivers/mux/rzv2h-usb-vbenctl.c b/drivers/mux/rzv2h-usb-vbenctl.c
new file mode 100644
index 000000000000..79197fddbf74
--- /dev/null
+++ b/drivers/mux/rzv2h-usb-vbenctl.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas RZ/V2H(P) USB VBENCTL VBUS_SEL mux driver
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mux/driver.h>
+#include <linux/regmap.h>
+
+#define RZV2H_VBENCTL 0xf0c
+
+struct mux_rzv2h_usb_vbenctl_priv {
+ struct regmap_field *field;
+};
+
+static int mux_rzv2h_usb_vbenctl_set(struct mux_control *mux, int state)
+{
+ struct mux_rzv2h_usb_vbenctl_priv *priv = mux_chip_priv(mux->chip);
+
+ return regmap_field_write(priv->field, state);
+}
+
+static const struct mux_control_ops mux_rzv2h_usb_vbenctl_ops = {
+ .set = mux_rzv2h_usb_vbenctl_set,
+};
+
+static int mux_rzv2h_usb_vbenctl_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
+{
+ struct mux_rzv2h_usb_vbenctl_priv *priv;
+ struct device *dev = &adev->dev;
+ struct mux_chip *mux_chip;
+ struct regmap *regmap;
+ struct reg_field reg_field = {
+ .reg = RZV2H_VBENCTL,
+ .lsb = 0,
+ .msb = 0,
+ };
+ int ret;
+
+ regmap = dev_get_regmap(adev->dev.parent, NULL);
+ if (!regmap)
+ return -ENODEV;
+
+ mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*priv));
+ if (IS_ERR(mux_chip))
+ return PTR_ERR(mux_chip);
+
+ priv = mux_chip_priv(mux_chip);
+
+ priv->field = devm_regmap_field_alloc(dev, regmap, reg_field);
+ if (IS_ERR(priv->field))
+ return PTR_ERR(priv->field);
+
+ mux_chip->ops = &mux_rzv2h_usb_vbenctl_ops;
+ mux_chip->mux[0].states = 2;
+ mux_chip->mux[0].idle_state = MUX_IDLE_AS_IS;
+
+ ret = devm_mux_chip_register(dev, mux_chip);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to register mux chip\n");
+
+ return 0;
+}
+
+static const struct auxiliary_device_id mux_rzv2h_usb_vbenctl_ids[] = {
+ { .name = "rzv2h_usb2phy_reset.vbenctl" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(auxiliary, mux_rzv2h_usb_vbenctl_ids);
+
+static struct auxiliary_driver mux_rzv2h_usb_vbenctl_driver = {
+ .name = "vbenctl",
+ .probe = mux_rzv2h_usb_vbenctl_probe,
+ .id_table = mux_rzv2h_usb_vbenctl_ids,
+};
+module_auxiliary_driver(mux_rzv2h_usb_vbenctl_driver);
+
+MODULE_DESCRIPTION("RZ/V2H USB VBENCTL VBUS_SEL mux driver");
+MODULE_AUTHOR("Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v10 2/5] dt-bindings: reset: renesas,rzv2h-usb2phy: Add '#mux-state-cells' property
From: Tommaso Merciai @ 2026-04-01 15:16 UTC (permalink / raw)
To: tomm.merciai, peda, p.zabel
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai, Fabrizio Castro,
Lad Prabhakar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Arnd Bergmann, Ulf Hansson,
Josua Mayer, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <cover.1775047175.git.tommaso.merciai.xr@bp.renesas.com>
Add the '#mux-state-cells' property to support describing the USB VBUS_SEL
multiplexer as a mux-controller in the Renesas RZ/V2H(P) USB2PHY binding.
The mux-controller cannot be integrated into the parent USB2PHY node
because the VBUS source selector is part of a separate hardware block,
not the USB2PHY block itself.
This is required to properly configure USB PHY power selection on
RZ/V2H(P) and RZ/G3E SoCs.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v9->v10:
- No changes
v8->v9:
- No changes
v7->v8:
- No changes
v6->v7:
- No changes
v5->v6:
- Collected KKrzysztof tag
v4->v5:
- No changes
v3->v4:
- Switch back to v2 implementation.
- Improve commit body.
v2->v3:
- Manipulate mux-controller as an internal node.
- Improved commit body.
v1->v2:
- New patch
.../bindings/reset/renesas,rzv2h-usb2phy-reset.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
index c1b800a10b53..7ed0980b9ee1 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
@@ -37,6 +37,9 @@ properties:
'#reset-cells':
const: 0
+ '#mux-state-cells':
+ const: 1
+
required:
- compatible
- reg
@@ -44,6 +47,7 @@ required:
- resets
- power-domains
- '#reset-cells'
+ - '#mux-state-cells'
additionalProperties: false
@@ -58,4 +62,5 @@ examples:
resets = <&cpg 0xaf>;
power-domains = <&cpg>;
#reset-cells = <0>;
+ #mux-state-cells = <1>;
};
--
2.43.0
^ permalink raw reply related
* [PATCH v10 3/5] dt-bindings: reset: renesas,rzv2h-usb2phy: Document RZ/G3E USB2PHY reset
From: Tommaso Merciai @ 2026-04-01 15:16 UTC (permalink / raw)
To: tomm.merciai, peda, p.zabel
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai, Fabrizio Castro,
Lad Prabhakar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Arnd Bergmann, Ulf Hansson,
Josua Mayer, devicetree, linux-kernel, Conor Dooley
In-Reply-To: <cover.1775047175.git.tommaso.merciai.xr@bp.renesas.com>
Document USB2PHY reset controller bindings for RZ/G3E ("R9A09G047") SoC.
The RZ/G3E USB2PHY reset controller is functionally identical to the one
found on the RZ/V2H(P), so no driver changes are needed. The existing
"renesas,r9a09g057-usb2phy-reset" will be used as a fallback compatible
for this IP.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v9->v10:
- No changes
v8->v9:
- No changes
v7->v8:
- No changes
v6->v7:
- No changes
v5->v6:
- Fixed commit msg
v4->v5:
- No changes
v3->v4:
- No changes
v2->v3:
- No changes
v1->v2:
- Collected CDooley tag
.../bindings/reset/renesas,rzv2h-usb2phy-reset.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
index 7ed0980b9ee1..66650ef8f772 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
@@ -17,7 +17,9 @@ properties:
compatible:
oneOf:
- items:
- - const: renesas,r9a09g056-usb2phy-reset # RZ/V2N
+ - enum:
+ - renesas,r9a09g047-usb2phy-reset # RZ/G3E
+ - renesas,r9a09g056-usb2phy-reset # RZ/V2N
- const: renesas,r9a09g057-usb2phy-reset
- const: renesas,r9a09g057-usb2phy-reset # RZ/V2H(P)
--
2.43.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