* RE: [PATCH v4 2/7] PCI: cadence: Add post-link delay for LGA and j721e glue driver
From: Manikandan Karunakaran Pillai @ 2026-05-18 2:38 UTC (permalink / raw)
To: Hans Zhang, bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
ryder.lee@mediatek.com, claudiu.beznea.uj@bp.renesas.com
Cc: robh@kernel.org, s-vadapalli@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, claudiu.beznea@tuxon.dev,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <c909a890-65cb-444f-9b4f-9482d2f71c6d@163.com>
>EXTERNAL MAIL
>
>
>
>
>On 5/18/26 10:12, Manikandan Karunakaran Pillai wrote:
>>
>>
>>> EXTERNAL MAIL
>>>
>>>
>>> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently
>>> lacks the mandatory 100 ms delay after link training completes for speeds
>>>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
>>>
>>> Add a 'max_link_speed' field to struct cdns_pcie. In the common host
>>> layer function cdns_pcie_host_start_link(), after the link has been
>>> successfully established, call pci_host_common_link_train_delay() to
>>> insert the required delay.
>>>
>>> For the j721e glue driver, set cdns_pcie.max_link_speed from the existing
>>> link speed logic. For other LGA-based glue drivers (sky1, sg2042), the
>>> common LGA host setup (pcie-cadence-host.c) provides a fallback reading
>>> of the device tree property "max-link-speed" when available. This ensures
>>> that the delay is not missed on those platforms once they enable the
>>> property.
>>>
>>> Signed-off-by: Hans Zhang <18255117159@163.com>
>>> ---
>>> drivers/pci/controller/cadence/pci-j721e.c | 1 +
>>> drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>>> drivers/pci/controller/cadence/pcie-cadence-host.c | 4 ++++
>>> drivers/pci/controller/cadence/pcie-cadence.h | 2 ++
>>> 4 files changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/pci/controller/cadence/pci-j721e.c
>>> b/drivers/pci/controller/cadence/pci-j721e.c
>>> index bfdfe98d5aba..ae916e7b1927 100644
>>> --- a/drivers/pci/controller/cadence/pci-j721e.c
>>> +++ b/drivers/pci/controller/cadence/pci-j721e.c
>>> @@ -206,6 +206,7 @@ static int j721e_pcie_set_link_speed(struct
>j721e_pcie
>>> *pcie,
>>> (pcie_get_link_speed(link_speed) == PCI_SPEED_UNKNOWN))
>>> link_speed = 2;
>>>
>>> + pcie->cdns_pcie->max_link_speed = link_speed;
>>> val = link_speed - 1;
>>> ret = regmap_update_bits(syscon, offset, GENERATION_SEL_MASK,
>>> val);
>>> if (ret)
>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>> index 2b0211870f02..18e4b6c760b5 100644
>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>> @@ -14,6 +14,7 @@
>>>
>>> #include "pcie-cadence.h"
>>> #include "pcie-cadence-host-common.h"
>>> +#include "../pci-host-common.h"
>>>
>>> #define LINK_RETRAIN_TIMEOUT HZ
>>>
>>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc
>*rc,
>>> if (!ret && rc->quirk_retrain_flag)
>>> ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>>
>>> + if (!ret)
>>> + pci_host_common_link_train_delay(pcie->max_link_speed);
>>> +
>>> return ret;
>>> }
>>> EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> index 0bc9e6e90e0e..058e4e619654 100644
>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> @@ -13,6 +13,7 @@
>>>
>>> #include "pcie-cadence.h"
>>> #include "pcie-cadence-host-common.h"
>>> +#include "../../pci.h"
>>>
>>> static u8 bar_aperture_mask[] = {
>>> [RP_BAR0] = 0x1F,
>>> @@ -397,6 +398,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>>> rc->device_id = 0xffff;
>>> of_property_read_u32(np, "device-id", &rc->device_id);
>>>
>>> + if (pcie->max_link_speed < 1)
>>> + pcie->max_link_speed = of_pci_get_max_link_speed(np);
>>> +
>> Why is the conditional if required here as during cdns_pcie_host_setup(), the
>value of
>> max_link_speed is expected to be '0', unless specifically initialized by the
>platform code separately.
>>
>> What happens if the max_link_speed is not defined in the corresponding dts
>? Would not the -EINVAL returned from the function create issues ?
>
>Hi Manikandan,
>
>Please see:
>
>https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/v7.1-
>rc4/drivers/pci/controller/dwc/pcie-
>designware.c*L191__;Iw!!EHscmS1ygiU1lA!EDHVakD3QN0gGza3V1__qzHgDG9
>RZlq7LzC5AFsYLV2i5FcoveNFsjWORRgRdHCAmOI-LizY5cJvGIWBOFJG$
>
>
>Best regards,
>Hans
>
That is how Designware has implemented it but that does not answer my query. Becos both these implementations do
not take care of the error returned, and it could well be the case for many of the current implementations.
>>
>>> pcie->reg_base = devm_platform_ioremap_resource_byname(pdev,
>>> "reg");
>>> if (IS_ERR(pcie->reg_base)) {
>>> dev_err(dev, "missing \"reg\"\n");
>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
>>> b/drivers/pci/controller/cadence/pcie-cadence.h
>>> index 574e9cf4d003..042a4c49bb9a 100644
>>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>> * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>>> * wrapper
>>> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>>> + * @max_link_speed: Maximum supported link speed
>>> */
>>> struct cdns_pcie {
>>> void __iomem *reg_base;
>>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>> struct device_link **link;
>>> const struct cdns_pcie_ops *ops;
>>> const struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>>> + int max_link_speed;
>>> };
>>>
>>> /**
>>> --
>>> 2.43.0
^ permalink raw reply
* [PATCH] ARM: remove the last few uses of do_bad_IRQ()
From: Ethan Nelson-Moore @ 2026-05-18 2:40 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Ethan Nelson-Moore, Russell King, Linus Walleij, Thomas Gleixner,
Bartosz Golaszewski, Greg Kroah-Hartman, Kees Cook, Arnd Bergmann,
Adrian Barnaś
The do_bad_IRQ() macro simply calls handle_bad_irq() with a lock around
it. It also carries a comment stating that uses of it should be
replaced. According to commit aec0095653cd ("irqchip: gic: Call
handle_bad_irq() directly"), which replaced another use of
do_bad_IRQ(), locking the IRQ descriptor is not necessary for error
reporting. Therefore, replace all uses of do_bad_IRQ() with calls to
handle_bad_irq() and remove do_bad_IRQ().
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/common/sa1111.c | 2 +-
arch/arm/include/asm/mach/irq.h | 10 ----------
| 2 +-
drivers/irqchip/irq-versatile-fpga.c | 2 +-
4 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
index 449c8bb86453..a0f854cf4748 100644
--- a/arch/arm/common/sa1111.c
+++ b/arch/arm/common/sa1111.c
@@ -221,7 +221,7 @@ static void sa1111_irq_handler(struct irq_desc *desc)
writel_relaxed(stat1, mapbase + SA1111_INTSTATCLR1);
if (stat0 == 0 && stat1 == 0) {
- do_bad_IRQ(desc);
+ handle_bad_irq(desc);
return;
}
diff --git a/arch/arm/include/asm/mach/irq.h b/arch/arm/include/asm/mach/irq.h
index dfe832a3bfc7..fdcd8388977d 100644
--- a/arch/arm/include/asm/mach/irq.h
+++ b/arch/arm/include/asm/mach/irq.h
@@ -17,14 +17,4 @@ struct seq_file;
extern void init_FIQ(int);
extern int show_fiq_list(struct seq_file *, int);
-/*
- * This is for easy migration, but should be changed in the source
- */
-#define do_bad_IRQ(desc) \
-do { \
- raw_spin_lock(&desc->lock); \
- handle_bad_irq(desc); \
- raw_spin_unlock(&desc->lock); \
-} while(0)
-
#endif
--git a/arch/arm/mach-footbridge/isa-irq.c b/arch/arm/mach-footbridge/isa-irq.c
index 842ddb4121ef..48c7b3efd555 100644
--- a/arch/arm/mach-footbridge/isa-irq.c
+++ b/arch/arm/mach-footbridge/isa-irq.c
@@ -89,7 +89,7 @@ static void isa_irq_handler(struct irq_desc *desc)
unsigned int isa_irq = *(unsigned char *)PCIIACK_BASE;
if (isa_irq < _ISA_IRQ(0) || isa_irq >= _ISA_IRQ(16)) {
- do_bad_IRQ(desc);
+ handle_bad_irq(desc);
return;
}
diff --git a/drivers/irqchip/irq-versatile-fpga.c b/drivers/irqchip/irq-versatile-fpga.c
index 034ce6afe170..6eaad836d9ff 100644
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -89,7 +89,7 @@ static void fpga_irq_handle(struct irq_desc *desc)
status = readl(f->base + IRQ_STATUS);
if (status == 0) {
- do_bad_IRQ(desc);
+ handle_bad_irq(desc);
goto out;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] ASoC: mediatek: mt8196: Fix probe resource cleanup
From: Cássio Gabriel @ 2026-05-18 2:41 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Matthias Brugger, AngeloGioacchino Del Regno, Darren Ye,
Cyril Chao
Cc: linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek,
Cássio Gabriel
The MT8196 AFE probe assigns reserved memory with
of_reserved_mem_device_init(), but never releases it.
This leaks the reserved memory assignment on driver
removal and on later probe failures.
The same probe path also uses unchecked pm_runtime_get_sync() calls.
A failure while resuming the device can leave the runtime PM usage
count in an unexpected state.
The regmap error path returns directly while the device is still
runtime active, and the remove path drops a runtime PM reference even
though successful probe has already released its temporary reference.
Register a devm cleanup action for the reserved memory assignment,
use pm_runtime_resume_and_get(), and only drop runtime PM references
on paths where they are actually held.
Fixes: 57513aabfe5b ("ASoC: mediatek: mt8196: add platform driver")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
sound/soc/mediatek/mt8196/mt8196-afe-pcm.c | 44 ++++++++++++++++++++----------
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/sound/soc/mediatek/mt8196/mt8196-afe-pcm.c b/sound/soc/mediatek/mt8196/mt8196-afe-pcm.c
index 511e888567be..a1ae8322d8b6 100644
--- a/sound/soc/mediatek/mt8196/mt8196-afe-pcm.c
+++ b/sound/soc/mediatek/mt8196/mt8196-afe-pcm.c
@@ -2242,13 +2242,16 @@ static int mt8196_afe_runtime_resume(struct device *dev)
static int mt8196_afe_component_probe(struct snd_soc_component *component)
{
struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component);
+ int ret;
+
+ /* enable clock for regcache get default value from hw */
+ ret = pm_runtime_resume_and_get(afe->dev);
+ if (ret)
+ return dev_err_probe(afe->dev, ret, "failed to resume device\n");
+
+ mtk_afe_add_sub_dai_control(component);
+ pm_runtime_put_sync(afe->dev);
- if (component) {
- /* enable clock for regcache get default value from hw */
- pm_runtime_get_sync(afe->dev);
- mtk_afe_add_sub_dai_control(component);
- pm_runtime_put_sync(afe->dev);
- }
return 0;
}
@@ -2306,6 +2309,11 @@ static const struct reg_sequence mt8196_cg_patch[] = {
{ AUDIO_TOP_CON4, 0x361c },
};
+static void mt8196_afe_release_reserved_mem(void *data)
+{
+ of_reserved_mem_device_release(data);
+}
+
static int mt8196_afe_pcm_dev_probe(struct platform_device *pdev)
{
int ret, i;
@@ -2320,8 +2328,13 @@ static int mt8196_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
ret = of_reserved_mem_device_init(dev);
- if (ret)
+ if (ret) {
dev_err(dev, "failed to assign memory region: %d\n", ret);
+ } else {
+ ret = devm_add_action_or_reset(dev, mt8196_afe_release_reserved_mem, dev);
+ if (ret)
+ return ret;
+ }
afe = devm_kzalloc(dev, sizeof(*afe), GFP_KERNEL);
if (!afe)
@@ -2422,18 +2435,22 @@ static int mt8196_afe_pcm_dev_probe(struct platform_device *pdev)
dev_pm_syscore_device(dev, true);
/* enable clock for regcache get default value from hw */
- pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to resume device\n");
afe->regmap = devm_regmap_init_mmio(dev, afe->base_addr,
&mt8196_afe_regmap_config);
- if (IS_ERR(afe->regmap))
- return PTR_ERR(afe->regmap);
+ if (IS_ERR(afe->regmap)) {
+ ret = PTR_ERR(afe->regmap);
+ goto err_pm_put;
+ }
ret = regmap_register_patch(afe->regmap, mt8196_cg_patch,
ARRAY_SIZE(mt8196_cg_patch));
if (ret < 0) {
dev_err(dev, "Failed to apply cg patch\n");
- goto err_pm_disable;
+ goto err_pm_put;
}
regmap_read(afe->regmap, AFE_IRQ_MCU_EN, &tmp_reg);
@@ -2452,12 +2469,12 @@ static int mt8196_afe_pcm_dev_probe(struct platform_device *pdev)
afe->num_dai_drivers);
if (ret) {
dev_err(dev, "afe component err\n");
- goto err_pm_disable;
+ return ret;
}
return 0;
-err_pm_disable:
+err_pm_put:
pm_runtime_put_sync(dev);
return ret;
}
@@ -2467,7 +2484,6 @@ static void mt8196_afe_pcm_dev_remove(struct platform_device *pdev)
struct mtk_base_afe *afe = platform_get_drvdata(pdev);
struct device *dev = &pdev->dev;
- pm_runtime_put_sync(dev);
if (!pm_runtime_status_suspended(dev))
mt8196_afe_runtime_suspend(dev);
---
base-commit: 2be19ed9535043fe6abd7ccfc9aac6b7ecaac842
change-id: 20260507-asoc-mt8196-probe-cleanup-222142d1000c
Best regards,
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
^ permalink raw reply related
* Re: [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Damon Ding @ 2026-05-18 2:44 UTC (permalink / raw)
To: Conor Dooley
Cc: Conor Dooley, hjc, heiko, andy.yan, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, nicolas.frattaroli, cristian.ciocaltea,
sebastian.reichel, dmitry.baryshkov, luca.ceresoli, dianders,
m.szyprowski, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260515-confess-hungrily-4f64ce0d8de2@wendy>
Hi Conor,
On 5/15/2026 5:04 PM, Conor Dooley wrote:
> On Fri, May 15, 2026 at 11:57:58AM +0800, Damon Ding wrote:
>> Hi Conor,
>>
>> On 5/15/2026 2:16 AM, Conor Dooley wrote:
>>> On Thu, May 14, 2026 at 03:01:31PM +0800, Damon Ding wrote:
>>>> Expose the inherited properties from the base analogix-dp schema
>>>> to satisfy unevaluatedProperties constraints.
>>>>
>>>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>>
>>> Given it's unevaluatedProperties, not addtionalProperties, this patch
>>> shouldn't be needed?
>>>
>>
>> When I remove both the top-level data-lanes property and those explicit
>> "xxx: true" property entries and run the dtbs check with:
>>
>> make CHECK_DTBS=y CROSS_COMPILE=aarch64-linux-gnu- LT0=none LLVM=1
>> LLVM_IAS=1 ARCH=arm64 rockchip/rk3588-evb1-v10.dtb
>> rockchip/rk3588s-evb1-v10.dtb rockchip/rk3399-sapphire-excavator.dtb
>> rockchip/rk3576-evb1-v10.dtb -j4
>>
>> It results in validation errors like these:
>>
>> /home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
>> edp@27dc0000: ports:port@1:endpoint: Unevaluated properties are not allowed
>> ('data-lanes' was unexpected)
>> from schema $id:
>> http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
>> /home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
>> edp@27dc0000: Unevaluated properties are not allowed ('force-hpd',
>> 'interrupts', 'phy-names', 'phys', 'ports', 'reg' were unexpected)
>> from schema $id:
>> http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
>>
>> I suspect that the properties defined in the child binding are
>> overriding/masking all the inherited properties from the parent Analogix DP
>> schema.
>>
>> Is there a better way to fix this issue without explicitly listing all
>> inherited properties as true?
>
> The example in this file uses most of the properties that you mention
> above:
> dp@ff970000 {
> compatible = "rockchip,rk3288-dp";
> reg = <0xff970000 0x4000>;
> interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
> clock-names = "dp", "pclk";
> phys = <&dp_phy>;
> phy-names = "dp";
> resets = <&cru 111>;
> reset-names = "dp";
> rockchip,grf = <&grf>;
> pinctrl-0 = <&edp_hpd>;
> pinctrl-names = "default";
>
> dt_binding_check reports no problems with this node, so I think the
> problem might lie elsewhere?
> There's no edp node in the dts you mention above, so this looks like an
> interaction with something that's not yet upstream.
Ah, I see.
I did add extra changes to the edp node on my local rk3576-evb1 board
DTS, which indeed caused this 'asymmetric information' issue and made
the validation fail incorrectly.
I will try adding the data-lanes property to the example in the binding
document to ensure dt_binding_check passes cleanly.
>
> If this is required for the rk3576 edp, then you should include this
> patch in the rk3576 edp support series rather than this one anyway where
> it can actually be evaluated alongside the node it apparently causes
> problems with.
The data-lanes property is actually applicable and useful for all
Rockchip eDP platforms, not just rk3576.
In the next version, I will modify the series to better separate this
common data-lanes change from the rk3576 specific eDP support patches.
>
> pw-bot: changes-requested
>
>>
>> Best regards,
>> Damon
>>
>>>> ---
>>>> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>>>> index bb75d898a5c5..896ded87880f 100644
>>>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>>>> @@ -50,6 +50,13 @@ properties:
>>>> aux-bus:
>>>> $ref: /schemas/display/dp-aux-bus.yaml#
>>>> + reg: true
>>>> + interrupts: true
>>>> + phys: true
>>>> + phy-names: true
>>>> + force-hpd: true
>>>> + ports: true
>>>> +
>>>> required:
>>>> - compatible
>>>> - clocks
>>>> --
>>>> 2.34.1
>>>>
>>>>
>>
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao @ 2026-05-18 2:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <agn2Yp3mzI7DcsyN@monoceros>
Hi Uwe,
Thanks for your review.
On 2026/5/18 01:12, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Apr 02, 2026 at 02:40:16AM +0000, Xianwei Zhao via B4 Relay wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add support for Amlogic S7 PWM. Amlogic S7 different from the
>> previous SoCs, a controller includes one pwm, at the same time,
>> the controller has only one input clock source.
>>
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> drivers/pwm/pwm-meson.c | 32 +++++++++++++++++++++++++++++---
>> 1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>> index 8c6bf3d49753..7a43c42ef3d6 100644
>> --- a/drivers/pwm/pwm-meson.c
>> +++ b/drivers/pwm/pwm-meson.c
>> @@ -113,6 +113,7 @@ struct meson_pwm_data {
>> int (*channels_init)(struct pwm_chip *chip);
>> bool has_constant;
>> bool has_polarity;
>> + bool single_pwm;
> Conceptually I'd prefer a `npwm` field here. That doesn't take more
> space in memory and simplifies the logic a bit. (At the cost of having
> to adapt all already existing meson_pwm_data instances, but that's fine
> in my book.)
>
I will use npwm(u8) instead of single_pwm.
>> };
>>
>> struct meson_pwm {
>> @@ -503,6 +504,18 @@ static void meson_pwm_s4_put_clk(void *data)
>> clk_put(clk);
>> }
>>
>> +static int meson_pwm_init_channels_s7(struct pwm_chip *chip)
>> +{
>> + struct device *dev = pwmchip_parent(chip);
>> + struct meson_pwm *meson = to_meson_pwm(chip);
>> +
>> + meson->channels[0].clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(meson->channels[0].clk))
>> + return dev_err_probe(dev, PTR_ERR(meson->channels[0].clk),
>> + "Failed to get clk\n");
>> + return 0;
>> +}
>> +
>> static int meson_pwm_init_channels_s4(struct pwm_chip *chip)
>> {
>> struct device *dev = pwmchip_parent(chip);
>> @@ -592,6 +605,13 @@ static const struct meson_pwm_data pwm_s4_data = {
>> .has_polarity = true,
>> };
>>
>> +static const struct meson_pwm_data pwm_s7_data = {
>> + .channels_init = meson_pwm_init_channels_s7,
>> + .has_constant = true,
>> + .has_polarity = true,
>> + .single_pwm = true,
>> +};
>> +
>> static const struct of_device_id meson_pwm_matches[] = {
>> {
>> .compatible = "amlogic,meson8-pwm-v2",
>> @@ -642,6 +662,10 @@ static const struct of_device_id meson_pwm_matches[] = {
>> .compatible = "amlogic,meson-s4-pwm",
>> .data = &pwm_s4_data
>> },
>> + {
>> + .compatible = "amlogic,s7-pwm",
>> + .data = &pwm_s7_data
>> + },
>> {},
> If you touch that array in the next revision, please make this line:
>
> { }
>
> (I.e. add a space and drop the comma.)
>
Will do.
> Best regards
> Uwe
^ permalink raw reply
* [PATCH] ARM: footbridge: resolve set-but-not-used variable warnings
From: Ethan Nelson-Moore @ 2026-05-18 2:55 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ethan Nelson-Moore, Russell King
In several functions in arch/arm/mach-footbridge/netwinder-hw.c, the
value of the variable i is only used if DEBUG is defined (because
dprintk() expands to nothing if it is not defined). This causes
compilation warnings when building with W=1 if DEBUG is not defined.
Resolve this issue by only defining the variable if DEBUG is defined.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
| 14 ++++++++++++++
1 file changed, 14 insertions(+)
--git a/arch/arm/mach-footbridge/netwinder-hw.c b/arch/arm/mach-footbridge/netwinder-hw.c
index 85367ea15c5c..a33f4c3b9505 100644
--- a/arch/arm/mach-footbridge/netwinder-hw.c
+++ b/arch/arm/mach-footbridge/netwinder-hw.c
@@ -469,13 +469,17 @@ static inline void rwa010_global_init(void)
static inline void rwa010_game_port_init(void)
{
+#ifdef DEBUG
int i;
+#endif
WRITE_RWA(7, 5);
dprintk("Slider base: ");
WRITE_RWA(0x61, 1);
+#ifdef DEBUG
i = inb(0x203);
+#endif
WRITE_RWA(0x60, 2);
dprintk("%02X%02X (201)\n", inb(0x203), i);
@@ -485,13 +489,17 @@ static inline void rwa010_game_port_init(void)
static inline void rwa010_waveartist_init(int base, int irq, int dma)
{
+#ifdef DEBUG
int i;
+#endif
WRITE_RWA(7, 0);
dprintk("WaveArtist base: ");
WRITE_RWA(0x61, base & 255);
+#ifdef DEBUG
i = inb(0x203);
+#endif
WRITE_RWA(0x60, base >> 8);
dprintk("%02X%02X (%X),", inb(0x203), i, base);
@@ -507,13 +515,17 @@ static inline void rwa010_waveartist_init(int base, int irq, int dma)
static inline void rwa010_soundblaster_init(int sb_base, int al_base, int irq, int dma)
{
+#ifdef DEBUG
int i;
+#endif
WRITE_RWA(7, 1);
dprintk("SoundBlaster base: ");
WRITE_RWA(0x61, sb_base & 255);
+#ifdef DEBUG
i = inb(0x203);
+#endif
WRITE_RWA(0x60, sb_base >> 8);
dprintk("%02X%02X (%X),", inb(0x203), i, sb_base);
@@ -528,7 +540,9 @@ static inline void rwa010_soundblaster_init(int sb_base, int al_base, int irq, i
dprintk("AdLib base: ");
WRITE_RWA(0x63, al_base & 255);
+#ifdef DEBUG
i = inb(0x203);
+#endif
WRITE_RWA(0x62, al_base >> 8);
dprintk("%02X%02X (%X)\n", inb(0x203), i, al_base);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] Add NXP FRDM-IMX95-PRO board support
From: Joseph Guo @ 2026-05-18 2:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang, Joseph Guo, Daniel Baluta, Conor Dooley
This patchset add Devicetree support for NXP FRDM-IMX95-PRO
development board based on i.MX95 19x19 SoC.
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Changes in v4:
- Correct underscores in node names
- Correct 'silent-gpio' of can_phy to GPIO_ACTIVE_HIGH
- Fix typo in pinctrl_pcal6416
- Link to v3: https://lore.kernel.org/r/20260509-imx95_frdm_pro-v3-0-96290b471396@nxp.com
Changes in v3:
- Change status of CAN1 to reserved
- Remove unused pinctrl
- Explain difference with i.MX95 15x15 FRDM in message
- Link to v2: https://lore.kernel.org/r/20260428-imx95_frdm_pro-v2-0-434240b652f4@nxp.com
Changes in v2:
- Run dt-format to reformat the node order
- Change compatible of mqs to audio-graph-card2
- Add imx95-19x19-frdm-pro in Makefile
- Link to v1: https://lore.kernel.org/r/20260318-imx95_frdm_pro-v1-0-8c00e59f0b1b@nxp.com
---
Joseph Guo (2):
dt-bindings: arm: fsl: Add i.MX95 19x19 FRDM PRO board
arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-19x19-frdm-pro.dts | 1021 ++++++++++++++++++++
3 files changed, 1023 insertions(+)
---
base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
change-id: 20260311-imx95_frdm_pro-7a8d03b50982
Best regards,
--
Joseph Guo <qijian.guo@nxp.com>
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX95 19x19 FRDM PRO board
From: Joseph Guo @ 2026-05-18 2:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang, Joseph Guo, Daniel Baluta, Conor Dooley
In-Reply-To: <20260518-imx95_frdm_pro-v4-0-975346555a9b@nxp.com>
Add the i.MX95 19x19 FRDM PRO board in the binding document.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index f5d3c08369b92987b2cb01e36c26f9f72937f557..9f50b4bf67bc2c0b0e11b1ae615151aa4d5f0d09 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1485,6 +1485,7 @@ properties:
- fsl,imx95-15x15-evk # i.MX95 15x15 EVK Board
- fsl,imx95-15x15-frdm # i.MX95 15x15 FRDM Board
- fsl,imx95-19x19-evk # i.MX95 19x19 EVK Board
+ - fsl,imx95-19x19-frdm-pro # i.MX95 19x19 FRDM PRO Board
- toradex,verdin-imx95-19x19-evk # i.MX95 Verdin Evaluation Kit (EVK)
- const: fsl,imx95
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Joseph Guo @ 2026-05-18 2:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang, Joseph Guo
In-Reply-To: <20260518-imx95_frdm_pro-v4-0-975346555a9b@nxp.com>
NXP i.MX95 19x19 FRDM PRO is cost-effective with extensive
expansion capabilities based on the i.MX95 19x19 SoC.
It is designed for AI and robotic situation.
Difference with i.MX95 15x15 FRDM:
- Use i.MX95 19x19 package
- Support 2 KEY-M M.2 PCIE
- 10G ETH interface
- Secure Element interface
Add device tree for this board. Including:
- LPUART1 and LPUART5
- NETC
- USB
- 2 M-Key M.2 PCIe
- uSDHC1, uSDHC2 and uSDHC3
- FlexCAN1 and FlexCAN3 (CAN1 is reserved by M7)
- LPI2C3, LPI2C4 and their child nodes
- Watchdog3
- SAI, MQS, MICFIL
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Changes in v2:
- Run dt-format to reformat the node order
- Change compatible of mqs to audio-graph-card2
- Add imx95-19x19-frdm-pro in Makefile
Changes in v3:
- Change status of CAN1 to reserved
- Remove unused pinctrl
- Explain difference with i.MX95 15x15 FRDM in message
Changes in v4:
- Correct underscores in node names
- Correct 'silent-gpio' of can_phy to GPIO_ACTIVE_HIGH
- Fix typo in pinctrl_pcal6416
- Change 'reg_ext_12v' to 'reg_exp_12v'
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-19x19-frdm-pro.dts | 1021 ++++++++++++++++++++
2 files changed, 1022 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index a6fe56bb93aa12040d184aa576623951515a8469..af22a5aa3e96fa24ebf2766a98fea4d0948c50f4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -462,6 +462,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
new file mode 100644
index 0000000000000000000000000000000000000000..b87a26b0d7fcf5790a8cb616833c6f27d633bca0
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
@@ -0,0 +1,1021 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95.dtsi"
+
+#define FALLING_EDGE 1
+#define RISING_EDGE 2
+
+#define BRD_SM_CTRL_SD3_WAKE 0x8000 /*!< PCAL6408A-0 */
+#define BRD_SM_CTRL_PCIE1_WAKE 0x8001 /*!< PCAL6408A-4 */
+#define BRD_SM_CTRL_BT_WAKE 0x8002 /*!< PCAL6408A-5 */
+#define BRD_SM_CTRL_PCIE2_WAKE 0x8003 /*!< PCAL6408A-6 */
+#define BRD_SM_CTRL_BUTTON 0x8004 /*!< PCAL6408A-7 */
+
+/ {
+ model = "NXP FRDM-IMX95-PRO";
+ compatible = "fsl,imx95-19x19-frdm-pro", "fsl,imx95";
+
+ aliases {
+ ethernet0 = &enetc_port0;
+ ethernet1 = &enetc_port1;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ gpio3 = &gpio4;
+ gpio4 = &gpio5;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial4 = &lpuart5;
+ };
+
+ bt_sco_codec: bt-sco-codec {
+ compatible = "linux,bt-sco";
+ #sound-dai-cells = <1>;
+ };
+
+ flexcan1_phy: can-phy0 {
+ compatible = "nxp,tja1057";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ silent-gpios = <&i2c4_gpio_expander_22 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ flexcan3_phy: can-phy2 {
+ compatible = "nxp,tja1057";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ silent-gpios = <&i2c4_gpio_expander_22 13 GPIO_ACTIVE_HIGH>;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ stdout-path = &lpuart1;
+ };
+
+ reg_vref_1v8: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V1.8_SW";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V3.3_SW";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reg_dcdc_3v3: regulator-dcdc-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "DCDC_3V3";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_dcdc_5v>;
+ gpio = <&i2c4_gpio_expander_22 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_dcdc_5v: regulator-dcdc-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "DCDC_5V";
+ regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&i2c4_gpio_expander_22 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_1v8: regulator-exp-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EXP_1V8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ gpio = <&i2c4_gpio_expander_22 10 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_3v3: regulator-exp-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "EXP_3V3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_dcdc_3v3>;
+ gpio = <&i2c4_gpio_expander_22 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_5v: regulator-exp-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "EXP_5V";
+ regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ vin-supply = <®_dcdc_5v>;
+ gpio = <&i2c4_gpio_expander_22 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_12v: regulator-exp-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCCEXP_12V";
+ regulator-always-on;
+ regulator-max-microvolt = <12000000>;
+ regulator-min-microvolt = <12000000>;
+ gpio = <&i2c4_gpio_expander_22 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_m2_mkey_1_pwr: regulator-m2-mkey-1-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power-mkey-1";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&i2c3_gpio_expander_20 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_m2_mkey_2_pwr: regulator-m2-mkey-2-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power-mkey-2";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&i2c3_gpio_expander_20 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_m2_ekey_pwr: regulator-m2-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power-ekey";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&i2c4_gpio_expander_22 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <12000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc3_vmmc: regulator-usdhc3 {
+ compatible = "regulator-fixed";
+ regulator-name = "WLAN_EN";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_m2_ekey_pwr>;
+ gpio = <&i2c4_gpio_expander_22 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * IW612 wifi chip needs more delay than other wifi chips to complete
+ * the host interface initialization after power up, otherwise the
+ * internal state of IW612 may be unstable, resulting in the failure of
+ * the SDIO3.0 switch voltage.
+ */
+ startup-delay-us = <20000>;
+ };
+
+ reg_usb_vbus: regulator-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_VBUS";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&i2c4_gpio_expander_22 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x80000000 0 0x7F000000>;
+ reusable;
+ size = <0 0x3c000000>;
+ linux,cma-default;
+ };
+ };
+
+ sound-bt-sco {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-inversion;
+ simple-audio-card,bitclock-master = <&btcpu>;
+ simple-audio-card,format = "dsp_a";
+ simple-audio-card,frame-master = <&btcpu>;
+ simple-audio-card,name = "bt-sco-audio";
+
+ simple-audio-card,codec {
+ sound-dai = <&bt_sco_codec 1>;
+ };
+
+ btcpu: simple-audio-card,cpu {
+ dai-tdm-slot-num = <2>;
+ dai-tdm-slot-width = <16>;
+ sound-dai = <&sai5>;
+ };
+ };
+
+ sound-micfil {
+ compatible = "fsl,imx-audio-card";
+ model = "micfil-audio";
+
+ pri-dai-link {
+ format = "i2s";
+ link-name = "micfil hifi";
+
+ cpu {
+ sound-dai = <&micfil>;
+ };
+ };
+ };
+
+ sound-mqs {
+ compatible = "audio-graph-card2";
+ links = <&sai1_port1>;
+ label = "mqs-audio";
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&i2c4_gpio_expander_22 9 GPIO_ACTIVE_LOW>;
+ };
+
+ memory@80000000 {
+ reg = <0x0 0x80000000 0 0x80000000>;
+ device_type = "memory";
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+&enetc_port0 {
+ phy-handle = <ðphy0>;
+ phy-mode = "rgmii-id";
+ pinctrl-0 = <&pinctrl_enetc0>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&enetc_port1 {
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+ pinctrl-0 = <&pinctrl_enetc1>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&flexcan1 {
+ phys = <&flexcan1_phy>;
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ pinctrl-names = "default";
+ status = "reserved";
+};
+
+&flexcan3 {
+ phys = <&flexcan3_phy>;
+ pinctrl-0 = <&pinctrl_flexcan3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ i2c3_gpio_expander_20: i2c3-gpio-expander@20 {
+ compatible = "nxp,pcal6416";
+ reg = <0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio5>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ pinctrl-0 = <&pinctrl_pcal6416>;
+ pinctrl-names = "default";
+ };
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&pinctrl_ptn5110>;
+ pinctrl-names = "default";
+
+ typec_con: connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ label = "USB-C";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb3_data_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb3_data_ss>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&lpi2c4 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c4>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ i2c4_gpio_expander_22: i2c4-gpio-expander@22 {
+ compatible = "nxp,pcal6524";
+ reg = <0x22>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names = "USB2 Power Enable",
+ "DCDC5V Enable",
+ "",
+ "SE Enable",
+ "",
+ "EXP 5V Enable",
+ "EXP 3V3 Enable",
+ "WIFI Power Enable",
+ "M2 DIS1 B",
+ "WIFI SD3 Reset",
+ "EXP 1V8 Enable",
+ "CAN1 Standby",
+ "M2 DIS2",
+ "CAN2 Standby",
+ "ETH 10G IO4",
+ "ETH 10G IO3",
+ "SPI3/GPIO select",
+ "EXP 12V Enable",
+ "DCDC 3V3 Enable",
+ "PCIE1 Reset",
+ "",
+ "ETH 10G CLK Enable",
+ "LVDS to HDMI converter IT6263 reset",
+ "";
+
+ /* When high, select lpspi; When low, select gpio. */
+ lpspi-gpio-sel-hog {
+ gpios = <16 GPIO_ACTIVE_HIGH>;
+ gpio-hog;
+ output-high;
+ };
+ };
+};
+
+&lpuart1 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&lpuart5 {
+ /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&micfil {
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_PDM>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <49152000>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <&pinctrl_pdm>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&mqs1 {
+ clocks = <&scmi_clk IMX95_CLK_SAI1>;
+ clock-names = "mclk";
+ pinctrl-0 = <&pinctrl_mqs1>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ mqs1_port: port {
+ mqs1_ep: endpoint {
+ dai-format = "left_j";
+ remote-endpoint = <&sai1_port1_ep>;
+ };
+ };
+};
+
+&netc_blk_ctrl {
+ status = "okay";
+};
+
+&netc_emdio {
+ pinctrl-0 = <&pinctrl_emdio>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ethphy0: ethernet-phy@1 {
+ reg = <1>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&i2c3_gpio_expander_20 1 GPIO_ACTIVE_LOW>;
+ };
+
+ ethphy1: ethernet-phy@2 {
+ reg = <2>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&i2c3_gpio_expander_20 2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&netc_timer {
+ status = "okay";
+};
+
+&netcmix_blk_ctrl {
+ status = "okay";
+};
+
+&pcie0 {
+ pinctrl-0 = <&pinctrl_pcie0>;
+ pinctrl-names = "default";
+ reset-gpio = <&i2c4_gpio_expander_22 19 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_m2_mkey_1_pwr>;
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-0 = <&pinctrl_pcie1>;
+ pinctrl-names = "default";
+ reset-gpio = <&i2c3_gpio_expander_20 9 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_m2_mkey_2_pwr>;
+ status = "okay";
+};
+
+&sai1 {
+ clocks = <&scmi_clk IMX95_CLK_BUSAON>, <&dummy>,
+ <&scmi_clk IMX95_CLK_SAI1>, <&dummy>,
+ <&dummy>, <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>;
+ clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI1>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <24576000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* leave unconnected - no RX in the context of MQS */
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ };
+ };
+
+ sai1_port1: port@1 {
+ reg = <1>;
+ mclk-fs = <512>;
+
+ sai1_port1_ep: endpoint {
+ dai-format = "left_j";
+ system-clock-direction-out;
+ bitclock-master;
+ frame-master;
+ remote-endpoint = <&mqs1_ep>;
+ };
+ };
+ };
+};
+
+&sai5 {
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI5>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <12288000>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <&pinctrl_sai5>;
+ pinctrl-names = "default";
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ pinctrl-0 = <&pinctrl_hog>;
+ pinctrl-names = "default";
+
+ pinctrl_emdio: emdiogrp {
+ fsl,pins = <
+ IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x50e
+ IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x90e
+ >;
+ };
+
+ pinctrl_enetc0: enetc0grp {
+ fsl,pins = <
+ IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x50e
+ IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x50e
+ IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x50e
+ IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x50e
+ IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x57e
+ IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x58e
+ IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x57e
+ IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x58e
+ IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x57e
+ IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x57e
+ IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x57e
+ IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x57e
+ >;
+ };
+
+ pinctrl_enetc1: enetc1grp {
+ fsl,pins = <
+ IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3 0x50e
+ IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2 0x50e
+ IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1 0x50e
+ IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0 0x50e
+ IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL 0x57e
+ IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK 0x58e
+ IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL 0x57e
+ IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK 0x58e
+ IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0 0x57e
+ IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1 0x57e
+ IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2 0x57e
+ IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3 0x57e
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ IMX95_PAD_SAI1_TXD0__AONMIX_TOP_CAN1_TX 0x39e
+ IMX95_PAD_SAI1_TXC__AONMIX_TOP_CAN1_RX 0x39e
+ >;
+ };
+
+ pinctrl_flexcan3: flexcan3grp {
+ fsl,pins = <
+ IMX95_PAD_CCM_CLKO3__CAN3_TX 0x39e
+ IMX95_PAD_CCM_CLKO4__CAN3_RX 0x39e
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ IMX95_PAD_XSPI1_SS1_B__GPIO5_IO_BIT11 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ IMX95_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c4: lpi2c4grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO30__LPI2C4_SDA 0x40000b9e
+ IMX95_PAD_GPIO_IO31__LPI2C4_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_mqs1: mqs1grp {
+ fsl,pins = <
+ IMX95_PAD_SAI1_TXFS__AONMIX_TOP_MQS1_LEFT 0x31e
+ IMX95_PAD_SAI1_RXD0__AONMIX_TOP_MQS1_RIGHT 0x31e
+ >;
+ };
+
+ pinctrl_pcal6416: pcal6416grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x31e
+ >;
+ };
+
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x4000031e
+ >;
+ };
+
+ pinctrl_pcie1: pcie1grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e
+ >;
+ };
+
+ pinctrl_pdm: pdmgrp {
+ fsl,pins = <
+ IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e
+ IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e
+ >;
+ };
+
+ pinctrl_ptn5110: ptn5110grp {
+ fsl,pins = <
+ IMX95_PAD_XSPI1_DQS__GPIO5_IO_BIT8 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x31e
+ >;
+ };
+
+ pinctrl_sai5: sai5grp {
+ fsl,pins = <
+ IMX95_PAD_XSPI1_DATA7__SAI5_RX_DATA_BIT0 0x31e
+ IMX95_PAD_XSPI1_DATA6__SAI5_TX_BCLK 0x31e
+ IMX95_PAD_XSPI1_DATA5__SAI5_TX_SYNC 0x31e
+ IMX95_PAD_XSPI1_DATA4__SAI5_TX_DATA_BIT0 0x31e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x31e
+ IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e
+ IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e
+ IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e
+ IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e
+ IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e
+ IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e
+ IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e
+ IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e
+ IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e
+ IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e
+ IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e
+ IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e
+ IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e
+ IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e
+ IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e
+ IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e
+ IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e
+ IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e
+ IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e
+ IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe
+ IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe
+ IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe
+ IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe
+ IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe
+ IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe
+ IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe
+ IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe
+ IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe
+ IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e
+ IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e
+ IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e
+ IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e
+ IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e
+ IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e
+ IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e
+ IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e
+ IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe
+ IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe
+ IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe
+ IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe
+ IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe
+ >;
+ };
+};
+
+&scmi_misc {
+ nxp,ctrl-ids = <BRD_SM_CTRL_SD3_WAKE FALLING_EDGE
+ BRD_SM_CTRL_PCIE1_WAKE FALLING_EDGE
+ BRD_SM_CTRL_BT_WAKE FALLING_EDGE
+ BRD_SM_CTRL_PCIE2_WAKE FALLING_EDGE
+ BRD_SM_CTRL_BUTTON FALLING_EDGE>;
+};
+
+&thermal_zones {
+ pf09-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 2>;
+
+ trips {
+ pf09_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf09_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pf53arm-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 4>;
+
+ cooling-maps {
+ map0 {
+ cooling-device = <&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ trip = <&pf5301_alert>;
+ };
+ };
+
+ trips {
+ pf5301_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf5301_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pf53soc-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 3>;
+
+ trips {
+ pf5302_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf5302_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+&usb2 {
+ disable-over-current;
+ dr_mode = "host";
+ vbus-supply = <®_usb_vbus>;
+ status = "okay";
+};
+
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ adp-disable;
+ dr_mode = "otg";
+ hnp-disable;
+ role-switch-default-mode = "peripheral";
+ srp-disable;
+ usb-role-switch;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ status = "okay";
+
+ port {
+ usb3_data_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+ fsl,phy-pcs-tx-deemph-3p5db-attenuation-db = <17>;
+ fsl,phy-pcs-tx-swing-full-percent = <100>;
+ fsl,phy-tx-preemp-amp-tune-microamp = <600>;
+ fsl,phy-tx-vboost-level-microvolt = <1156>;
+ fsl,phy-tx-vref-tune-percent = <100>;
+ status = "okay";
+
+ port {
+ usb3_data_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc1>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ status = "okay";
+};
+
+&usdhc2 {
+ bus-width = <4>;
+ cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&usdhc3 {
+ bus-width = <4>;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc3>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc3_vmmc>;
+ wakeup-source;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 2/7] PCI: cadence: Add post-link delay for LGA and j721e glue driver
From: Hans Zhang @ 2026-05-18 3:03 UTC (permalink / raw)
To: Manikandan Karunakaran Pillai, bhelgaas@google.com,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
vigneshr@ti.com, jingoohan1@gmail.com,
thomas.petazzoni@bootlin.com, ryder.lee@mediatek.com,
claudiu.beznea.uj@bp.renesas.com
Cc: robh@kernel.org, s-vadapalli@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, claudiu.beznea@tuxon.dev,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DM6PR07MB6716CC48016E6D44EC5FCAB3A2032@DM6PR07MB6716.namprd07.prod.outlook.com>
On 5/18/26 10:38, Manikandan Karunakaran Pillai wrote:
>
>
>> EXTERNAL MAIL
>>
>>
>>
>>
>> On 5/18/26 10:12, Manikandan Karunakaran Pillai wrote:
>>>
>>>
>>>> EXTERNAL MAIL
>>>>
>>>>
>>>> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently
>>>> lacks the mandatory 100 ms delay after link training completes for speeds
>>>>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
>>>>
>>>> Add a 'max_link_speed' field to struct cdns_pcie. In the common host
>>>> layer function cdns_pcie_host_start_link(), after the link has been
>>>> successfully established, call pci_host_common_link_train_delay() to
>>>> insert the required delay.
>>>>
>>>> For the j721e glue driver, set cdns_pcie.max_link_speed from the existing
>>>> link speed logic. For other LGA-based glue drivers (sky1, sg2042), the
>>>> common LGA host setup (pcie-cadence-host.c) provides a fallback reading
>>>> of the device tree property "max-link-speed" when available. This ensures
>>>> that the delay is not missed on those platforms once they enable the
>>>> property.
>>>>
>>>> Signed-off-by: Hans Zhang <18255117159@163.com>
>>>> ---
>>>> drivers/pci/controller/cadence/pci-j721e.c | 1 +
>>>> drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>>>> drivers/pci/controller/cadence/pcie-cadence-host.c | 4 ++++
>>>> drivers/pci/controller/cadence/pcie-cadence.h | 2 ++
>>>> 4 files changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/controller/cadence/pci-j721e.c
>>>> b/drivers/pci/controller/cadence/pci-j721e.c
>>>> index bfdfe98d5aba..ae916e7b1927 100644
>>>> --- a/drivers/pci/controller/cadence/pci-j721e.c
>>>> +++ b/drivers/pci/controller/cadence/pci-j721e.c
>>>> @@ -206,6 +206,7 @@ static int j721e_pcie_set_link_speed(struct
>> j721e_pcie
>>>> *pcie,
>>>> (pcie_get_link_speed(link_speed) == PCI_SPEED_UNKNOWN))
>>>> link_speed = 2;
>>>>
>>>> + pcie->cdns_pcie->max_link_speed = link_speed;
>>>> val = link_speed - 1;
>>>> ret = regmap_update_bits(syscon, offset, GENERATION_SEL_MASK,
>>>> val);
>>>> if (ret)
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> index 2b0211870f02..18e4b6c760b5 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> @@ -14,6 +14,7 @@
>>>>
>>>> #include "pcie-cadence.h"
>>>> #include "pcie-cadence-host-common.h"
>>>> +#include "../pci-host-common.h"
>>>>
>>>> #define LINK_RETRAIN_TIMEOUT HZ
>>>>
>>>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc
>> *rc,
>>>> if (!ret && rc->quirk_retrain_flag)
>>>> ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>>>
>>>> + if (!ret)
>>>> + pci_host_common_link_train_delay(pcie->max_link_speed);
>>>> +
>>>> return ret;
>>>> }
>>>> EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> index 0bc9e6e90e0e..058e4e619654 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> @@ -13,6 +13,7 @@
>>>>
>>>> #include "pcie-cadence.h"
>>>> #include "pcie-cadence-host-common.h"
>>>> +#include "../../pci.h"
>>>>
>>>> static u8 bar_aperture_mask[] = {
>>>> [RP_BAR0] = 0x1F,
>>>> @@ -397,6 +398,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>>>> rc->device_id = 0xffff;
>>>> of_property_read_u32(np, "device-id", &rc->device_id);
>>>>
>>>> + if (pcie->max_link_speed < 1)
>>>> + pcie->max_link_speed = of_pci_get_max_link_speed(np);
>>>> +
>>> Why is the conditional if required here as during cdns_pcie_host_setup(), the
>> value of
>>> max_link_speed is expected to be '0', unless specifically initialized by the
>> platform code separately.
>>>
>>> What happens if the max_link_speed is not defined in the corresponding dts
>> ? Would not the -EINVAL returned from the function create issues ?
>>
>> Hi Manikandan,
>>
>> Please see:
>>
>> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/v7.1-
>> rc4/drivers/pci/controller/dwc/pcie-
>> designware.c*L191__;Iw!!EHscmS1ygiU1lA!EDHVakD3QN0gGza3V1__qzHgDG9
>> RZlq7LzC5AFsYLV2i5FcoveNFsjWORRgRdHCAmOI-LizY5cJvGIWBOFJG$
>>
>>
>> Best regards,
>> Hans
>>
> That is how Designware has implemented it but that does not answer my query. Becos both these implementations do
> not take care of the error returned, and it could well be the case for many of the current implementations.
Hi Manikandan,
If "max-link-speed" is not defined in the DT, then:
of_pci_get_max_link_speed
of_property_read_u32
of_property_read_u32_array
of_property_read_variable_u32_array
return -EINVAL;
For patch 0001, no actions will be executed. I wonder if this answers
your question?
Best regards,
Hans
>
>>>
>>>> pcie->reg_base = devm_platform_ioremap_resource_byname(pdev,
>>>> "reg");
>>>> if (IS_ERR(pcie->reg_base)) {
>>>> dev_err(dev, "missing \"reg\"\n");
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
>>>> b/drivers/pci/controller/cadence/pcie-cadence.h
>>>> index 574e9cf4d003..042a4c49bb9a 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>>>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>>> * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>>>> * wrapper
>>>> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>>>> + * @max_link_speed: Maximum supported link speed
>>>> */
>>>> struct cdns_pcie {
>>>> void __iomem *reg_base;
>>>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>>> struct device_link **link;
>>>> const struct cdns_pcie_ops *ops;
>>>> const struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>>>> + int max_link_speed;
>>>> };
>>>>
>>>> /**
>>>> --
>>>> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao @ 2026-05-18 3:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <agn2Yp3mzI7DcsyN@monoceros>
Hi Uwe,
Thanks for your review.
On 2026/5/18 01:12, Uwe Kleine-König wrote:
> Subject:
> Re: [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
> From:
> Uwe Kleine-König <ukleinek@kernel.org>
> Date:
> 2026/5/18 01:12
>
> To:
> xianwei.zhao@amlogic.com
> CC:
> Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>,
> Conor Dooley <conor+dt@kernel.org>, Heiner Kallweit
> <hkallweit1@gmail.com>, Neil Armstrong <neil.armstrong@linaro.org>,
> Kevin Hilman <khilman@baylibre.com>, Jerome Brunet
> <jbrunet@baylibre.com>, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com>, linux-pwm@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org
>
>
>
> Hello,
>
> On Thu, Apr 02, 2026 at 02:40:16AM +0000, Xianwei Zhao via B4 Relay wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add support for Amlogic S7 PWM. Amlogic S7 different from the
>> previous SoCs, a controller includes one pwm, at the same time,
>> the controller has only one input clock source.
>>
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> drivers/pwm/pwm-meson.c | 32 +++++++++++++++++++++++++++++---
>> 1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>> index 8c6bf3d49753..7a43c42ef3d6 100644
>> --- a/drivers/pwm/pwm-meson.c
>> +++ b/drivers/pwm/pwm-meson.c
>> @@ -113,6 +113,7 @@ struct meson_pwm_data {
>> int (*channels_init)(struct pwm_chip *chip);
>> bool has_constant;
>> bool has_polarity;
>> + bool single_pwm;
> Conceptually I'd prefer a `npwm` field here. That doesn't take more
> space in memory and simplifies the logic a bit. (At the cost of having
> to adapt all already existing meson_pwm_data instances, but that's fine
> in my book.)
>
I will use npwm(u8 type) instead of single_pwm.
>> };
>>
>> struct meson_pwm {
>> @@ -503,6 +504,18 @@ static void meson_pwm_s4_put_clk(void *data)
>> clk_put(clk);
>> }
>>
>> +static int meson_pwm_init_channels_s7(struct pwm_chip *chip)
>> +{
>> + struct device *dev = pwmchip_parent(chip);
>> + struct meson_pwm *meson = to_meson_pwm(chip);
>> +
>> + meson->channels[0].clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(meson->channels[0].clk))
>> + return dev_err_probe(dev, PTR_ERR(meson->channels[0].clk),
>> + "Failed to get clk\n");
>> + return 0;
>> +}
>> +
>> static int meson_pwm_init_channels_s4(struct pwm_chip *chip)
>> {
>> struct device *dev = pwmchip_parent(chip);
>> @@ -592,6 +605,13 @@ static const struct meson_pwm_data pwm_s4_data = {
>> .has_polarity = true,
>> };
>>
>> +static const struct meson_pwm_data pwm_s7_data = {
>> + .channels_init = meson_pwm_init_channels_s7,
>> + .has_constant = true,
>> + .has_polarity = true,
>> + .single_pwm = true,
>> +};
>> +
>> static const struct of_device_id meson_pwm_matches[] = {
>> {
>> .compatible = "amlogic,meson8-pwm-v2",
>> @@ -642,6 +662,10 @@ static const struct of_device_id meson_pwm_matches[] = {
>> .compatible = "amlogic,meson-s4-pwm",
>> .data = &pwm_s4_data
>> },
>> + {
>> + .compatible = "amlogic,s7-pwm",
>> + .data = &pwm_s7_data
>> + },
>> {},
> If you touch that array in the next revision, please make this line:
>
> { }
>
> (I.e. add a space and drop the comma.)
>
Will do.
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH v2 6/9] iommu/arm-smmu-v3: Directly encode simple commands
From: Nicolin Chen @ 2026-05-18 3:15 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <6-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:45PM -0300, Jason Gunthorpe wrote:
> Add make functions to build commands for
>
> CMDQ_OP_TLBI_EL2_ALL
> CMDQ_OP_TLBI_NSNH_ALL
> CMDQ_OP_CFGI_ALL
> CMDQ_OP_PREFETCH_CFG
> CMDQ_OP_CFGI_STE
> CMDQ_OP_CFGI_CD
> CMDQ_OP_RESUME
> CMDQ_OP_PRI_RESP
>
> Convert all of these call sites to use the make function instead of
> going through arm_smmu_cmdq_build_cmd(). Use a #define so the general
> pattern is always:
>
> arm_smmu_cmdq_issue_cmd(smmu, arm_smmu_make_cmd_XX(..));
>
> Add arm_smmu_cmdq_batch_add_cmd() which takes struct arm_smmu_cmd
> directly to match the new flow.
>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> +static inline struct arm_smmu_cmd arm_smmu_make_cmd_cfgi_all(void)
> +{
> + struct arm_smmu_cmd cmd = arm_smmu_make_cmd_op(CMDQ_OP_CFGI_ALL);
> +
> + cmd.data[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31);
Optional, might retain the note:
/* Cover the entire SID range */
^ permalink raw reply
* RE: [PATCH v4 2/7] PCI: cadence: Add post-link delay for LGA and j721e glue driver
From: Manikandan Karunakaran Pillai @ 2026-05-18 3:17 UTC (permalink / raw)
To: Hans Zhang, bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
ryder.lee@mediatek.com, claudiu.beznea.uj@bp.renesas.com
Cc: robh@kernel.org, s-vadapalli@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, claudiu.beznea@tuxon.dev,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e7143078-0c0a-4c15-a192-081f2a5a5ff8@163.com>
>>>>>
>>>>> #include "pcie-cadence.h"
>>>>> #include "pcie-cadence-host-common.h"
>>>>> +#include "../pci-host-common.h"
>>>>>
>>>>> #define LINK_RETRAIN_TIMEOUT HZ
>>>>>
>>>>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc
>>> *rc,
>>>>> if (!ret && rc->quirk_retrain_flag)
>>>>> ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>>>>
>>>>> + if (!ret)
>>>>> + pci_host_common_link_train_delay(pcie->max_link_speed);
>>>>> +
>>>>> return ret;
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> index 0bc9e6e90e0e..058e4e619654 100644
>>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> @@ -13,6 +13,7 @@
>>>>>
>>>>> #include "pcie-cadence.h"
>>>>> #include "pcie-cadence-host-common.h"
>>>>> +#include "../../pci.h"
>>>>>
>>>>> static u8 bar_aperture_mask[] = {
>>>>> [RP_BAR0] = 0x1F,
>>>>> @@ -397,6 +398,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>>>>> rc->device_id = 0xffff;
>>>>> of_property_read_u32(np, "device-id", &rc->device_id);
>>>>>
>>>>> + if (pcie->max_link_speed < 1)
>>>>> + pcie->max_link_speed = of_pci_get_max_link_speed(np);
>>>>> +
>>>> Why is the conditional if required here as during cdns_pcie_host_setup(),
>the
>>> value of
>>>> max_link_speed is expected to be '0', unless specifically initialized by the
>>> platform code separately.
>>>>
>>>> What happens if the max_link_speed is not defined in the corresponding
>dts
>>> ? Would not the -EINVAL returned from the function create issues ?
>>>
>>> Hi Manikandan,
>>>
>>> Please see:
>>>
>>> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/v7.1-
>>> rc4/drivers/pci/controller/dwc/pcie-
>>>
>designware.c*L191__;Iw!!EHscmS1ygiU1lA!EDHVakD3QN0gGza3V1__qzHgDG9
>>> RZlq7LzC5AFsYLV2i5FcoveNFsjWORRgRdHCAmOI-LizY5cJvGIWBOFJG$
>>>
>>>
>>> Best regards,
>>> Hans
>>>
>> That is how Designware has implemented it but that does not answer my
>query. Becos both these implementations do
>> not take care of the error returned, and it could well be the case for many of
>the current implementations.
>
>Hi Manikandan,
>
>If "max-link-speed" is not defined in the DT, then:
>
>of_pci_get_max_link_speed
> of_property_read_u32
> of_property_read_u32_array
> of_property_read_variable_u32_array
> return -EINVAL;
>
>
>For patch 0001, no actions will be executed. I wonder if this answers
>your question?
>
Yes, got it. Thanks Hans.
>Best regards,
>Hans
>
>
>>
>>>>
>>>>> pcie->reg_base = devm_platform_ioremap_resource_byname(pdev,
>>>>> "reg");
>>>>> if (IS_ERR(pcie->reg_base)) {
>>>>> dev_err(dev, "missing \"reg\"\n");
>>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> b/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> index 574e9cf4d003..042a4c49bb9a 100644
>>>>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>>>> * @ops: Platform-specific ops to control various inputs from Cadence
>PCIe
>>>>> * wrapper
>>>>> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>>>>> + * @max_link_speed: Maximum supported link speed
>>>>> */
>>>>> struct cdns_pcie {
>>>>> void __iomem *reg_base;
>>>>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>>>> struct device_link **link;
>>>>> const struct cdns_pcie_ops *ops;
>>>>> const struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>>>>> + int max_link_speed;
>>>>> };
>>>>>
>>>>> /**
>>>>> --
>>>>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH v2 7/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_ATC_INV
From: Nicolin Chen @ 2026-05-18 3:27 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <7-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:46PM -0300, Jason Gunthorpe wrote:
> Add a new command make function and convert all the places using
> ATC_INV.
>
> Split out full invalidation to directly make the cmd instead of
> overloading size=0 to mean full invalidation.
>
> In section "3.9.1 ATS Interface" of F.b the specification says:
>
> When the SMMU returns an ATS Translation Completion for a request that
> had a PASID, the Global bit of the Translation Completion Data Entry
> must be zero.
>
> Even though it faithfully forwards the G bit through to the ATS
> invalidation command there is no way to create G mappings so there is
> never any need to send a G invalidation. Thus don't expose global in the
> new helpers and leave CMDQ_ATC_0_GLOBAL unused.
>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
With a nit ..
> -static void
> -arm_smmu_atc_inv_to_cmd(int ssid, unsigned long iova, size_t size,
> - struct arm_smmu_cmdq_ent *cmd)
> +static struct arm_smmu_cmd
> +arm_smmu_atc_inv_to_cmd(u32 sid, int ssid, unsigned long iova, size_t size)
> {
> size_t log2_span;
> size_t span_mask;
> @@ -2395,17 +2386,6 @@ arm_smmu_atc_inv_to_cmd(int ssid, unsigned long iova, size_t size,
> * This has the unpleasant side-effect of invalidating all PASID-tagged
> * ATC entries within the address range.
> */
> - *cmd = (struct arm_smmu_cmdq_ent) {
> - .opcode = CMDQ_OP_ATC_INV,
> - .substream_valid = (ssid != IOMMU_NO_PASID),
> - .atc.ssid = ssid,
> - };
> -
> - if (!size) {
> - cmd->atc.size = ATC_INV_SIZE_ALL;
> - return;
> - }
.. should !size jump to arm_smmu_make_cmd_atc_inv_all()?
Or maybe add a note to disallow this function being used with !size
and WARN_ON? The function name itself doesn't sound very restricted
though.
Nicolin
^ permalink raw reply
* Re: [PATCH v2 8/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_SYNC
From: Nicolin Chen @ 2026-05-18 3:30 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <8-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:47PM -0300, Jason Gunthorpe wrote:
> Change the flow so the caller controls the CS field and remove the
> weird u64p_replace_bits() thing to override it.
>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-05-18 3:30 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Andre Przywara, linux-sunxi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <14a7e289ff5ffed8fcd6dcb9b2e8455a1b2c9420.camel@gmail.com>
On Mon, May 18, 2026 at 4:37 AM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
>
> Hi Andre,
>
> thanks for the quick feedback!
>
> On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> > > @@ -0,0 +1,162 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +/*
> > > + * Copyright (c) 2025 Arm Ltd.
> >
> > Please put your own copyright here, even if that has been largely copied
> > from an existing file.
> >
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "sun50i-a100.dtsi"
> > > +#include "sun50i-a100-cpu-opp.dtsi"
> > > +
> > > +/{
> > > + compatible = "baijie,helper-a133-core",
> > > + "allwinner,sun50i-a100";
> > > +
> > > + aliases {
> > > + serial1 = &uart1; /* BT module */
> >
> > Do we really need an alias for the BT UART? And is the BT module
> > supported already? Then please add a child node to the UART node.
>
> That's the only thing I can do currently regarding BT: stabilize the
> serial enumeration, because UART1 cannot be used for anything else
> except BT module, because this is soldered inside "core" module.
> We can avoid different tty enumeration, should the support for
> BT be implemented in the future...
>
> > Isn't the WiFi/BT module on the SoM? Then please mention and enable MMC1
> > here. Provide the child node for the WiFi chip, even if there is no
> > upstream support in the kernel for it yet.
>
> So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> has neither upstream driver, nor [upstream] DT bindings. Even github
> driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> pointless to me at this point to specify anything in the DT for the
> chip which doesn't have the bindings idea even theoretically.
>
> Nothing in the current DT shall block any future work on the AW869A
> support though and the above "aliases" entry shall even guarantee
> unchanged serial enumeration shall such support arise.
>
> > > +®_aldo1 {
> >
> > What is aldo1 used for, actually? I don't see this referenced anywhere.
> > I guess the kernel turns that off after booting?
> > If you have access to the schematic, please check that. If that's for
> > some peripheral not yet supported, please note the user anyway, ideally
> > by an explaining regulator-name, or by a comment. Also if it's used for
> > any of the required SoC VDD pins. See the Liontron .dts for comparison.
> >
> > > + regulator-always-on;
> ^^^^^^^^^^^^^^^^^^^
> I suppose it's not being switcdhed of because of the above.
> It's used for both PLL supply for the whole SoC + as analog voltage reference
> for LRADC (the buttons you've noticed on the board are connected to
> this ADC via a resistor ladder).
>
> >
> > > +®_aldo2 {
> > > + regulator-always-on;
> >
> > For always-on regulators we definitely need an explanation. Does the
> > board stop booting if you remove this line?
> > Maybe it's for DRAM? Can you say what voltage it is, either from the
> > reset default, or set by the bootloader?
>
> Thanks for the hint! I'll put proper voltages into all regulators +
> comment all the always-on regulators.
Please also give them proper names. If you have the schematics, then use
the names from that; otherwise just make up names matching their use.
> >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> > > new file mode 100644
> > > index 000000000000..ccbca5d0a40c
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> > And you should provide a top level 5V regulator here, to be the root of
> > the regulator tree. Look at reg_vcc5v in the Liontron .dts.
>
> It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> have USB power control. The second issue with Helper/Core split is that
> all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> putting it in the DT would introduce wierd dependency of the core to the
> HelperBoard which carries it. Do you think it would make sense?
In that case I would probably put a 5v "fake root" regulator in the core
dtsi. And in combined dts, I'd then add the 12v "real root", and use that
as the supply for the 5v fake root.
Does that make sense?
ChenYu
> > So from the pictures I found online it looks like there is an USB-C port
> > labelled "OTG", so can you please add an &usbotg reference here and
> > describe that port.
>
> Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
> not host mode. Will rework!
>
> > > +&usbphy {
> >
> > Are the two USB ports always powered?
> >
> > And anyway, I see a *dual* USB-A socket on the pictures online, in
> > addition to the USB-OTG port. So where does the third USB come from? The
> > A133 only supports one host USB port plus the one OTG port. So is there
> > an USB hub chip on the board?
>
> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
> two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
> load switches.
> >
>
> --
> Alexander Sverdlin.
^ permalink raw reply
* [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Kohei Enju @ 2026-05-18 3:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Sami Mujawar, Gavin Shan, Steven Price, Suzuki K Poulose,
linux-arm-kernel, linux-kernel, Kohei Enju
With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of
debug_smp_processor_id(). This debug function complains when certain
conditions that ensure CPU ID stability are not met, specifically when
it's called from a preemptible context.
In arm_cca_report_new(), which runs in a preemptible context,
smp_processor_id() triggers a splat [0] due to this.
However, the CPU ID obtained here is used as the target CPU for
smp_call_function_single() to designate a specific CPU for subsequent
operations, not to assert that the current thread will continue to
execute on the same CPU. Therefore, snapshotting the CPU ID itself is
correct, and thus there's no actual harm except for the splat.
Use raw_smp_processor_id() instead, to directly retrieve the current CPU
ID without the debug checks, avoiding the unnecessary warning message
while preserving the correct functional behavior.
[0]
BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/134
caller is debug_smp_processor_id+0x20/0x2c
CPU: 0 UID: 0 PID: 134 Comm: cca-workload-at Not tainted 7.0.0-rc1-gc74a64d12073 #1 PREEMPT
Hardware name: linux,dummy-virt (DT)
Call trace:
[...]
check_preemption_disabled+0xf8/0x100
debug_smp_processor_id+0x20/0x2c
arm_cca_report_new+0x54/0x230
tsm_report_read+0x184/0x260
tsm_report_outblob_read+0x18/0x38
configfs_bin_read_iter+0xf4/0x1dc
vfs_read+0x230/0x31c
[...]
Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
---
drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
index 0c9ea24a200c..2d450caee3e4 100644
--- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
+++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
@@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
* allocate outblob based on the returned value from the 'init'
* call and that cannot be done in an atomic context.
*/
- cpu = smp_processor_id();
+ cpu = raw_smp_processor_id();
info.challenge = desc->inblob;
info.challenge_size = desc->inblob_len;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/2] Add ASRock Rack B650D4U BMC
From: Prasanth Kumar Padarthi @ 2026-05-18 3:34 UTC (permalink / raw)
To: joel, andrew, robh, krzk+dt, conor+dt
Cc: andrew+netdev, devicetree, linux-aspeed, linux-arm-kernel,
Prasanth Kumar Padarthi
Add initial devicetree support for the ASRock Rack B650D4U BMC,
an ASPEED AST2600-based server management controller.
Changes in v3:
- Reorder board DTS nodes alphabetically by label.
- Clarify that the management LAN PHY is an on-board discrete PHY.
- Keep MAC0 phy-mode as "rgmii-rxid" based on the extracted vendor DTB.
- Keep flash layout unspecified until it can be validated on hardware.
Changes in v2:
- Add MAC0 dedicated management LAN description with MDIO PHY at address 0.
Prasanth Kumar Padarthi (2):
dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-asrock-b650d4u.dts | 71 +++++++++++++++++++
3 files changed, 73 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
--
2.47.3
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Prasanth Kumar Padarthi @ 2026-05-18 3:34 UTC (permalink / raw)
To: joel, andrew, robh, krzk+dt, conor+dt
Cc: andrew+netdev, devicetree, linux-aspeed, linux-arm-kernel,
Prasanth Kumar Padarthi
In-Reply-To: <20260518033440.17569-1-prasanth.padarthi10@gmail.com>
Add the compatible string for the ASRock Rack B650D4U BMC,
which is an AST2600-based server motherboard.
Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 2f92b8ab0..656397850 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -77,6 +77,7 @@ properties:
- ampere,mtmitchell-bmc
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
+ - asrock,b650d4u-bmc
- asus,x4tf-bmc
- facebook,bletchley-bmc
- facebook,catalina-bmc
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
From: Prasanth Kumar Padarthi @ 2026-05-18 3:34 UTC (permalink / raw)
To: joel, andrew, robh, krzk+dt, conor+dt
Cc: andrew+netdev, devicetree, linux-aspeed, linux-arm-kernel,
Prasanth Kumar Padarthi
In-Reply-To: <20260518033440.17569-1-prasanth.padarthi10@gmail.com>
Add initial device tree support for the ASRock Rack B650D4U BMC.
The B650D4U is a server motherboard utilizing the ASPEED AST2600
SoC for management.
Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-asrock-b650d4u.dts | 71 +++++++++++++++++++
2 files changed, 72 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index c4f064e4b..124d4f8f8 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-asrock-romed8hm3.dtb \
aspeed-bmc-asrock-spc621d8hm3.dtb \
aspeed-bmc-asrock-x570d4u.dtb \
+ aspeed-bmc-asrock-b650d4u.dtb \
aspeed-bmc-asus-x4tf.dtb \
aspeed-bmc-bytedance-g220a.dtb \
aspeed-bmc-delta-ahe50dc.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
new file mode 100644
index 000000000..daa8b25e3
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+
+/ {
+ model = "ASRock Rack B650D4U BMC";
+ compatible = "asrock,b650d4u-bmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ };
+
+ chosen {
+ stdout-path = "serial4:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+/* SPI Flash Management */
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ };
+};
+
+/* I2C Bus for FRU/EEPROM Storage */
+&i2c7 {
+ status = "okay";
+ eeprom@57 {
+ compatible = "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+&mac0 {
+ status = "okay";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <ðphy0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
+};
+
+/* Dedicated management LAN via on-board discrete PHY */
+&mdio0 {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
+/* BMC Console UART */
+&uart5 {
+ status = "okay";
+};
+
+/* System Watchdog */
+&wdt1 {
+ status = "okay";
+ aspeed,reset-type = "soc";
+};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] ARM: PCI: expand single-line pci_common_init() wrapper function
From: Andrew Lunn @ 2026-05-18 3:42 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, Russell King,
Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <20260517235916.57178-1-enelsonmoore@gmail.com>
On Sun, May 17, 2026 at 04:59:11PM -0700, Ethan Nelson-Moore wrote:
> pci_common_init() is a compatibility wrapper that simply calls
> pci_common_init_dev() with an additional NULL argument. The comment
> above it implies that it should be replaced by pci_common_init_dev(),
> but that has never happened - there are no callers of
> pci_common_init_dev() in the kernel. Make the PCI code more
> straightforward by updating all uses of pci_common_init() to instead
> call pci_common_init_dev() with a NULL first argument and removing
> pci_common_init().
Nobody seems to call pci_common_init_dev() without passing NULL. So i
think it makes more sense to rename pci_common_init_dev() to
pci_common_init() and drop struct device *parent parameter. You then
only need to change pci.h and bios32.c.
Andrew
^ permalink raw reply
* Re: [PATCH v2 9/9] iommu/arm-smmu-v3: Directly encode TLBI commands
From: Nicolin Chen @ 2026-05-18 3:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <9-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:48PM -0300, Jason Gunthorpe wrote:
> TLBI is more complicated than all the other commands because the
> invalidation loop builds a template command from the struct
> arm_smmu_inv which is then expanded into many TLBI commands for the
> invalidation.
>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* RE: Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Chancel Liu @ 2026-05-18 4:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260515-resourceful-singing-roadrunner-ce25ec@quoll>
> > +description:
> > + The NXP I/O connector represents a physically present I/O connector
> > +on the
> > + base board. It acts as a nexus that exposes a constrained set of
> > +I/O
> > + resources, such as GPIOs, clocks, PWMs and interrupts, through
> > +fixed
> > + electrical wiring. All actual hardware providers reside on the base board.
> > + The connector node only defines index-based mappings to those
> providers.
> > +
> > +properties:
> > + compatible:
> > + const: fsl,io-connector
>
> Everything is IO. Everything is connector, so your compatible does not match
> requirements from writing bindings.
>
Yes, this compatible is too generic. I will rename the compatible to
fsl,aud-io-connector.
> > +
> > + gpio-controller: true
> > +
> > + '#gpio-cells':
> > + const: 2
> > +
> > + gpio-map:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>
> You do not need to redefine the types. You need constraints, though.
>
OK. I will add proper constraints.
> > +
> > + gpio-map-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + gpio-map-pass-thru:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + '#clock-cells':
> > + const: 1
> > +
> > + clock-map:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > + clock-map-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + clock-map-pass-thru:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
>
> I do not see these defined anywhere. I also checked cover letter for
> references for pulls to dtschema.
>
Nexus nodes are already in the device-tree specification：
https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
For reference, current kernel has supported it:
* Nexus OF support:
commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node")
* GPIO adoption:
commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
* PWM adoption:
commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
Clock adoption is ongoing:
https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/
> > +
> > + pwm-map:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > + pwm-map-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + pwm-map-pass-thru:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + '#address-cells':
> > + const: 0
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
>
> Use consistent quotes.
>
I will fix it in next revision.
> > + const: 2
> > +
> > + interrupt-map: true
> > +
> > + interrupt-map-mask: true
> > +
> > +required:
> > + - compatible
>
> You need to require the properties. You have a FIXED connector, so it has
> fixed set of features.
>
> Best regards,
> Krzysztof
I will make gpio related properties required because they are mandatory
for DT. Clock and interrupt mappings are board/configuration dependent
so I prefer to use dependentRequired when they are present.
Regards,
Chancel Liu
^ permalink raw reply
* Re: [PATCH] ARM: PCI: expand single-line pci_common_init() wrapper function
From: Ethan Nelson-Moore @ 2026-05-18 4:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-kernel, linux-kernel, Russell King,
Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <b3c8c216-d8e3-4ee9-b4bc-1080f73592dc@lunn.ch>
Hi, Andrew,
On Sun, May 17, 2026 at 8:42 PM Andrew Lunn <andrew@lunn.ch> wrote:
> Nobody seems to call pci_common_init_dev() without passing NULL. So i
> think it makes more sense to rename pci_common_init_dev() to
> pci_common_init() and drop struct device *parent parameter. You then
> only need to change pci.h and bios32.c.
I considered that, but decided against it because it would prevent the
code from easily being updated to pass a parent parameter in the
future. However, given the age of the affected platforms, that is
unlikely to happen, so your approach might make more sense. What do
you think?
Ethan
^ permalink raw reply
* [PATCH] Input: mtk-pmic-keys - use of_device_get_match_data()
From: Rosen Penev @ 2026-05-18 4:20 UTC (permalink / raw)
To: linux-input
Cc: Dmitry Torokhov, Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use of_device_get_match_data() to fetch the PMIC key register data directly instead of open-coding an of_match_device() lookup.
This also lets the driver drop the of_device.h include.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/input/keyboard/mtk-pmic-keys.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index c78d9f6d97c4..fd684ac16938 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -16,7 +16,6 @@
#include <linux/mfd/mt6397/core.h>
#include <linux/mfd/mt6397/registers.h>
#include <linux/module.h>
-#include <linux/of_device.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -333,8 +332,6 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
struct mtk_pmic_keys *keys;
const struct mtk_pmic_regs *mtk_pmic_regs;
struct input_dev *input_dev;
- const struct of_device_id *of_id =
- of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
if (!keys)
@@ -342,7 +339,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
keys->dev = &pdev->dev;
keys->regmap = pmic_chip->regmap;
- mtk_pmic_regs = of_id->data;
+ mtk_pmic_regs = of_device_get_match_data(&pdev->dev);
keys->input_dev = input_dev = devm_input_allocate_device(keys->dev);
if (!input_dev) {
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox