* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Linus Walleij @ 2026-04-07 9:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Bartosz Golaszewski, dri-devel,
devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260402-sticky-wooden-silkworm-5bdff4@quoll>
On Thu, Apr 2, 2026 at 10:30 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Apr 01, 2026 at 10:26:20AM +0300, Dmitry Baryshkov wrote:
> > + # Waveshare 12.3-DSI-TOUCH-A panel
> > + - waveshare,12.3-dsi-touch-a
>
> I don't think we use '.' in compatibles, so waveshare,12-3-dsi-touch-a
Qualcomm happen to use periods in similar cases for their
"qualcomm universal peripheral":
Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
I don't know if the policy changed since, but that's a big and widespread
platform and I never saw it challenged so I think it's kind of established
that we do.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-04-07 9:38 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <iaoee5r5e2w52fap7ex23wdikbuvpjpesinedgjkehsedszhzo@64yoo2avmxle>
[-- Attachment #1: Type: text/plain, Size: 12894 bytes --]
On Thu, Apr 02, 2026 at 11:02:02PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Apr 02, 2026 at 04:27:37PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
> > driver is very small, with its main purpose being to set up the address
> > translation registers and then creating a standard PCI host using ECAM.
> >
> > Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> What is the rationale for adding a new driver? Can't you reuse the existing one?
> If so, that should be mentioned in the description.
Which existing one? Tegra PCI controllers for previou generations
(Tegra194 and Tegra234) were DesignWare IP, but Tegra264 is an internal
IP, so the programming is entirely different. I'll add something to that
effect to the commit message.
> > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> > index 5aaed8ac6e44..6ead04f7bd6e 100644
> > --- a/drivers/pci/controller/Kconfig
> > +++ b/drivers/pci/controller/Kconfig
> > @@ -254,7 +254,15 @@ config PCI_TEGRA
> > select IRQ_MSI_LIB
> > help
> > Say Y here if you want support for the PCIe host controller found
> > - on NVIDIA Tegra SoCs.
> > + on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
> > +
> > +config PCIE_TEGRA264
> > + bool "NVIDIA Tegra264 PCIe controller"
>
> This driver seems to be using external MSI controller. So it can be built as a
> module. Also, you have the remove() callback for some reason.
Okay, I can turn this into a tristate symbol.
> > + depends on ARCH_TEGRA || COMPILE_TEST
> > + depends on PCI_MSI
>
> Why?
I suppose it's not necessary in the sense of it being a build
dependency. At runtime, however, the root complex is not useful if PCI
MSI is not enabled. We can drop this dependency and rely on .config to
have it enabled as needed.
> > diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> > new file mode 100644
> > index 000000000000..3ce1ad971bdb
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-tegra264.c
[...]
> > +struct tegra264_pcie {
> > + struct device *dev;
> > + bool link_up;
>
> Keep bool types at the end to avoid holes.
Done.
> > +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> > +{
> > + int err;
> > +
> > + pcie->wake_gpio = devm_gpiod_get_optional(pcie->dev, "nvidia,pex-wake",
>
> You should switch to standard 'wake-gpios' property.
Will do.
> > + GPIOD_IN);
> > + if (IS_ERR(pcie->wake_gpio))
> > + return PTR_ERR(pcie->wake_gpio);
> > +
> > + if (pcie->wake_gpio) {
>
> Since you are bailing out above, you don't need this check.
I think we still want to have this check to handle the case of optional
wake GPIOs. Not all controllers may have this wired up and
devm_gpiod_get_optional() will return NULL (not an ERR_PTR()-encoded
error) if the wake-gpios property is missing.
> > +static void tegra264_pcie_bpmp_set_rp_state(struct tegra264_pcie *pcie)
>
> I don't think this function name is self explanatory. Looks like it is turning
> off the PCIe controller, so how about tegra264_pcie_power_off()?
Agreed. The name is a relic from when this was potentially being used to
toggle on and off the controller. But it's only used for disabling, so
tegra264_pcie__power_off() sounds much better.
> > +{
> > + struct tegra_bpmp_message msg = {};
> > + struct mrq_pcie_request req = {};
> > + int err;
> > +
> > + req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
> > + req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
> > +
> > + msg.mrq = MRQ_PCIE;
> > + msg.tx.data = &req;
> > + msg.tx.size = sizeof(req);
> > +
> > + err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> > + if (err)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
>
> Why not dev_err()?
>
> > + pcie->ctl_id, ERR_PTR(err));
> > +
> > + if (msg.rx.ret)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %d\n",
>
> Same here.
These are not fatal errors and are safe to ignore. dev_err() seemed too
strong for this. They also really shouldn't happen. Though I now realize
that's a bad argument, or rather, actually an argument for making them
dev_err() so that they do stand out if they really should happen.
>
> > + pcie->ctl_id, msg.rx.ret);
> > +}
> > +
> > +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> > +{
> > + u32 value, speed, width, bw;
> > + int err;
> > +
> > + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> > + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> > + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> > +
> > + bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
> > + value = MBps_to_icc(bw);
>
> So this becomes, 'width * (PCIE_SPEED2MBS_ENC(speed) / 8) * 1000 / 8'. But don't
> you want, 'width * (PCIE_SPEED2MBS_ENC(speed)) * 1000 / 8'?
This is M*B*ps_to_icc(), not M*b*ps_to_icc(), so we do in fact get the
latter. I almost fell for this as well because I got confused by some of
these macros being all-caps and other times the case actually mattering.
> > + err = icc_set_bw(pcie->icc_path, bw, bw);
> > + if (err < 0)
> > + dev_err(pcie->dev,
> > + "failed to request bandwidth (%u MBps): %pe\n",
> > + bw, ERR_PTR(err));
>
> So you don't want to error out if this fails?
No. This is not a fatal error and the system will continue to work,
albeit perhaps at suboptimal performance. Given that Ethernet and mass
storage are connected to these, a failure to set the bandwidth and
erroring out here may leave the system unusable, but continuing on would
let the system boot and update firmware, kernel or whatever to recover.
I'll add a comment explaining this.
[...]
> > +static void tegra264_pcie_init(struct tegra264_pcie *pcie)
> > +{
> > + enum pci_bus_speed speed;
> > + unsigned int i;
> > + u32 value;
> > +
> > + /* bring the link out of reset */
>
> s/link/controller or endpoint?
This controls the PERST# signal, so I guess "endpoint" would be more
correct.
> > + value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > + value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
> > + writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > +
> > + if (!tegra_is_silicon()) {
>
> This looks like some pre-silicon validation thing. Do you really want it to be
> present in the upstream driver?
At this point there is silicon for this chip, but we've been trying to
get some of the pre-silicon code merged upstream as well because
occasionally people will want to run upstream on simulation, even after
silicon is available. At other times we may want to reuse these drivers
on future chips during pre-silicon validation.
Obviously there needs to be a balance. We don't want to have excessive
amounts of code specifically for pre-silicon validation, but in
relatively simple cases like this it is useful.
>
> > + dev_info(pcie->dev,
> > + "skipping link state for PCIe #%u in simulation\n",
> > + pcie->ctl_id);
> > + pcie->link_up = true;
> > + return;
> > + }
> > +
> > + for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
> > + if (tegra264_pcie_link_up(pcie, NULL))
> > + break;
> > +
> > + usleep_range(PCIE_LINK_WAIT_US_MIN, PCIE_LINK_WAIT_US_MAX);
> > + }
> > +
> > + if (tegra264_pcie_link_up(pcie, &speed)) {
>
> Why are you doing it for the second time?
It's just a last-resort check to see if it's really not come up after
the retries. Also, in this call we're actually interested in retrieving
the detected link speed.
>
> > + /* Per PCIe r5.0, 6.6.1 wait for 100ms after DLL up */
>
> No need of this comment.
Fair enough. This was perhaps more useful in earlier versions of the
patch before the line below used the standardize wait time.
[...]
> > +static int tegra264_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct pci_host_bridge *bridge;
> > + struct tegra264_pcie *pcie;
> > + struct resource_entry *bus;
> > + struct resource *res;
> > + int err;
> > +
> > + bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
> > + if (!bridge)
> > + return dev_err_probe(dev, -ENOMEM,
> > + "failed to allocate host bridge\n");
> > +
> > + pcie = pci_host_bridge_priv(bridge);
> > + platform_set_drvdata(pdev, pcie);
> > + pcie->bridge = bridge;
> > + pcie->dev = dev;
> > +
> > + err = pinctrl_pm_select_default_state(dev);
>
> I questioned this before:
> https://lore.kernel.org/linux-pci/o5sxxdikdjwd76zsedvkpsl54nw6wrhopwsflt43y5st67mrub@uuw3yfjfqthd/
I'll remove this. Looks like we should be fine with just relying on the
default state being set by the pinctrl core. We might need to move it
into the resume callback.
> > + if (err < 0)
> > + return dev_err_probe(dev, err,
> > + "failed to configure sideband pins\n");
> > +
> > + err = tegra264_pcie_parse_dt(pcie);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to parse device tree");
> > +
> > + pcie->xal = devm_platform_ioremap_resource_byname(pdev, "xal");
> > + if (IS_ERR(pcie->xal))
> > + return dev_err_probe(dev, PTR_ERR(pcie->xal),
> > + "failed to map XAL memory\n");
> > +
> > + pcie->xtl = devm_platform_ioremap_resource_byname(pdev, "xtl-pri");
> > + if (IS_ERR(pcie->xtl))
> > + return dev_err_probe(dev, PTR_ERR(pcie->xtl),
> > + "failed to map XTL-PRI memory\n");
> > +
> > + bus = resource_list_first_type(&bridge->windows, IORESOURCE_BUS);
> > + if (!bus)
> > + return dev_err_probe(dev, -ENODEV,
> > + "failed to get bus resources\n");
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
> > + if (!res)
> > + return dev_err_probe(dev, -ENXIO,
> > + "failed to get ECAM resource\n");
> > +
> > + pcie->icc_path = devm_of_icc_get(&pdev->dev, "write");
> > + if (IS_ERR(pcie->icc_path))
> > + return dev_err_probe(&pdev->dev, PTR_ERR(pcie->icc_path),
> > + "failed to get ICC");
> > +
> > + /*
> > + * Parse BPMP property only for silicon, as interaction with BPMP is
> > + * not needed for other platforms.
> > + */
> > + if (tegra_is_silicon()) {
> > + pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
> > + if (IS_ERR(pcie->bpmp))
> > + return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
> > + "failed to get BPMP\n");
> > + }
> > +
>
> pm_runtime_set_active()
>
> > + pm_runtime_enable(dev);
>
> devm_pm_runtime_enable()?
Looks like I can even use devm_pm_runtime_set_active_enabled() to
combine the two.
>
> > + pm_runtime_get_sync(dev);
> > +
> > + /* sanity check that programmed ranges match what's in DT */
> > + if (!tegra264_pcie_check_ranges(pdev)) {
> > + err = -EINVAL;
> > + goto put_pm;
> > + }
> > +
> > + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > + if (IS_ERR(pcie->cfg)) {
> > + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > + "failed to create ECAM\n");
> > + goto put_pm;
> > + }
> > +
> > + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > + bridge->sysdata = pcie->cfg;
> > + pcie->ecam = pcie->cfg->win;
> > +
> > + tegra264_pcie_init(pcie);
> > +
> > + if (!pcie->link_up)
> > + goto free;
>
> goto free_ecam;
It's not clear to me, but are you suggesting to rename the existing
"free" label to "free_ecam"? I can do that.
> > + err = pci_host_probe(bridge);
> > + if (err < 0) {
> > + dev_err(dev, "failed to register host: %pe\n", ERR_PTR(err));
>
> dev_err_probe()
Okay.
>
> > + goto free;
> > + }
> > +
> > + return err;
>
> return 0;
Done.
[...]
> > +static int tegra264_pcie_resume_noirq(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = disable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + if (pcie->link_up == false)
> > + return 0;
> > +
> > + tegra264_pcie_init(pcie);
> > +
>
> Why do you need init() here without deinit() in tegra264_pcie_suspend_noirq()?
That's because when we come out of suspend the link may have gone down
again, so we need to take the endpoint out of reset to retrigger the
link training. I think we could possibly explicitly clear that PERST_O_N
bit in the PERST_CONTROL register in a new tegra264_pcie_deinit() to
mirror what tegra264_pcie_init() does, but it's automatically done by
firmware anyway, so not needed.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Upstream] Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Frank Li @ 2026-04-07 9:37 UTC (permalink / raw)
To: Primoz Fiser
Cc: Florijan Plohl, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
imx, linux-arm-kernel, devicetree, linux-kernel, upstream
In-Reply-To: <707e106b-f444-4c26-9816-c53c8eda8cbb@norik.com>
On Tue, Apr 07, 2026 at 08:14:08AM +0200, Primoz Fiser wrote:
> Hi Frank, Florijan,
>
> On 4/6/26 04:56, Frank Li wrote:
> > On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
> >> Hello,
> >>
> >> On 4/2/26 15:50, Frank Li wrote:
> >>> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
> >>>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> >>> what's means PEB-AV-18? Is it random board name?
> >> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
> >> be used to connect displays on their boards.
> >>
> >> I will improve commit message to add more such information in v2.
> >>
> >>>
> >>>
> >>>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
> >>>>
> >>>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
> >>>> ---
> >>>> arch/arm64/boot/dts/freescale/Makefile | 4 +
> >>>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> >>>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> >>> Any difference between 91 and 93, can use one overlay file?
> >>>
> >>> Frank
> >>
> >> Can you suggest how to do so?
> >>
> >> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
> >> between imx91 and imx93.
> >
> > I suggest move pinmux setting to mainboard's dts files, which provide
> > plug adaptor header, signal should be descripted in mainboard's dts file,
> > which provide an unified label to overlay file.
>
> Yeah, that would be one way of doing it.
>
> However, the phycore dtsi and phyboard dts are kept simple by design
> choice. This way, all optional pinctrls and peripherals are kept
> separate from the board device-tree to maintain clutter low.
>
> For v2 I would prefer to keep as is (current downstream implementation)
> or at least use this approach:
>
> imx91-93-phyboard-segin-peb-av-18.dtsi
> |
> -> imx91-phyboard-segin-peb-av-18.dtso
> |
> -> imx93-phyboard-segin-peb-av-18.dtso
It is better than v1's method.
Frank
>
> BR,
> Primoz
>
> >
> > Frank
> >
> >>
> >> So we can only create common dtsi like so:
> >>
> >> imx91-93-phyboard-segin-peb-av-18.dtsi
> >>
> >> and still use separate dtsos:
> >>
> >> imx91-phyboard-segin-peb-av-18.dtso
> >> imx93-phyboard-segin-peb-av-18.dtso
> >>
> >> Is that your idea?
> >>
> >> BR,
> >>
> >> Florijan Plohl
> >>
> >>>> --
> >>>> 2.43.0
> >>>>
> > _______________________________________________
> > upstream mailing list -- upstream@lists.phytec.de
> > To unsubscribe send an email to upstream-leave@lists.phytec.de
>
> --
> Primoz Fiser
> phone: +386-41-390-545
> email: primoz.fiser@norik.com
> --
> Norik systems d.o.o.
> Your embedded software partner
> Slovenia, EU
> phone: +386-41-540-545
> email: info@norik.com
>
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-04-07 9:36 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Jeffery, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB42763DAD359305DEBA4B769D9057A@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Arnd,
Thanks for the comments and questions.
> These all seem to be viable options, but I still think we should focus on
> agreeing on a design for the low-level hardware interface and whether this
> can or should be abstracted between SoC vendor specific drivers before
> trying to solve the user interface side.
Could you share your thoughts on whether it would make sense to accept our
eSPI driver as is, and whether it should live under the SoC vendor-specific
directories? Any comment would be greatly appreciated.
Thanks,
YunHsuan
^ permalink raw reply
* Re: [PATCH v2 5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
From: Konrad Dybcio @ 2026-04-07 9:35 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexander Koskovich,
Liam Girdwood, Mark Brown, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Johannes Berg, Jeff Johnson
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>
On 4/3/26 3:52 PM, Luca Weiss wrote:
> Add a node for the WCN6755 WiFi found with the Milos SoC.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Konrad Dybcio @ 2026-04-07 9:32 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260406174613.3388987-2-krishna.kurapati@oss.qualcomm.com>
On 4/6/26 7:46 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Add the base USB devicetree definitions for Kaanapali platform. The overall
> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
> (rev. v8) and M31 eUSB2 PHY.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Konrad Dybcio @ 2026-04-07 9:32 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260406174613.3388987-4-krishna.kurapati@oss.qualcomm.com>
On 4/6/26 7:46 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Enable USB support on Kaanapali QRD variant. Enable USB controller in
> device mode till glink node is added.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> +&usb_dp_qmpphy {
nit: the addition of the "_dp_" bit which is absent on other platforms
in the label made the reference unsorted
Konrad
> + vdda-phy-supply = <&vreg_l1d_1p2>;
> + vdda-pll-supply = <&vreg_l4f_0p8>;
> +
> + status = "okay";
> +};
^ permalink raw reply
* [PATCH 1/2] dt-bindings: display: simple: Add Startek KD070HDFLD092 panel
From: Stefan Kerkmann @ 2026-04-07 9:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Stefan Kerkmann
In-Reply-To: <20260407-panel-simple-startek-upstream-v1-0-76721696655f@pengutronix.de>
Add Startek KD070HDFLD092 7" WSVGA LVDS panel compatible.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 868edb04989a5..2a6a41349e5f7 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -302,6 +302,8 @@ properties:
- shelly,sca07010-bfn-lnn
# Starry KR070PE2T 7" WVGA TFT LCD panel
- starry,kr070pe2t
+ # Startek KD070HDFLD092 7" WSVGA TFT LCD panel
+ - startek,kd070hdfld092
# Startek KD070WVFPA043-C069A 7" TFT LCD panel
- startek,kd070wvfpa
# Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel
--
2.47.3
^ permalink raw reply related
* [PATCH 2/2] drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
From: Stefan Kerkmann @ 2026-04-07 9:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Stefan Kerkmann
In-Reply-To: <20260407-panel-simple-startek-upstream-v1-0-76721696655f@pengutronix.de>
The Startek KD070HDFLD092 is a 7" WSVGA LVDS panel.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
drivers/gpu/drm/panel/panel-simple.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 91ab280869bac..737a1014f8112 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4540,6 +4540,32 @@ static const struct panel_desc starry_kr070pe2t = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct display_timing startek_kd070hdfld092_timing = {
+ .pixelclock = { 40800000, 51200000, 67200000 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 40, 160, 216 },
+ .hback_porch = { 30, 140, 140 },
+ .hsync_len = { 20, 20, 20 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 2, 12, 177 },
+ .vback_porch = { 5, 20, 20 },
+ .vsync_len = { 3, 3, 3 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc startek_kd070hdfld092 = {
+ .timings = &startek_kd070hdfld092_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing startek_kd070wvfpa_mode = {
.pixelclock = { 25200000, 27200000, 30500000 },
.hactive = { 800, 800, 800 },
@@ -5532,6 +5558,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "starry,kr070pe2t",
.data = &starry_kr070pe2t,
+ }, {
+ .compatible = "startek,kd070hdfld092",
+ .data = &startek_kd070hdfld092,
}, {
.compatible = "startek,kd070wvfpa",
.data = &startek_kd070wvfpa,
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
From: Stefan Kerkmann @ 2026-04-07 9:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Stefan Kerkmann
The Startek KD070HDFLD092 is a 7" WSVGA LVDS panel.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
Stefan Kerkmann (2):
dt-bindings: display: simple: Add Startek KD070HDFLD092 panel
drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++
2 files changed, 31 insertions(+)
---
base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
change-id: 20260407-panel-simple-startek-upstream-7eddd07166c1
Best regards,
--
Stefan Kerkmann <s.kerkmann@pengutronix.de>
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
From: Konrad Dybcio @ 2026-04-07 9:31 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260406174613.3388987-3-krishna.kurapati@oss.qualcomm.com>
On 4/6/26 7:46 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Enable USB support on Kaanapali MTP variant. Enable USB controller in
> device mode till glink node is added.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: Add AYN QCS8550 Common
From: Konrad Dybcio @ 2026-04-07 9:20 UTC (permalink / raw)
To: Aaron Kling, Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Teguh Sobirin
In-Reply-To: <CALHNRZ9ZiENcXJn7SKuAoDWoBbuxWuOktBDF7FZob6xFH8A3=A@mail.gmail.com>
On 4/3/26 12:04 AM, Aaron Kling wrote:
> On Mon, Mar 30, 2026 at 6:32 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Mon, Mar 30, 2026 at 01:00:55PM +0200, Konrad Dybcio wrote:
>>> On 3/27/26 10:26 PM, Aaron Kling wrote:
>>>> On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
>>>> <konrad.dybcio@oss.qualcomm.com> wrote:
>>>>>
>>>>> On 3/23/26 5:27 PM, Aaron Kling via B4 Relay wrote:
>>>>>> From: Teguh Sobirin <teguh@sobir.in>
>>>>>>
>>>>>> This contains everything common between the AYN QCS8550 devices. It will
>>>>>> be included by device specific dts'.
>>>>>>
>>>>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> + sound {
>>>>>> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
>>>>>> + pinctrl-0 = <&lpi_i2s3_active>;
>>>>>> + pinctrl-names = "default";
>>>>>> +
>>>>>> + model = "AYN-Odin2";
>>>>>
>>>>> Is this enough of a distinction? Do you need to make any changes to the
>>>>> one with a HDMI bridge to get HDMI audio?
>>>>
>>>> After this quesstion, I tried to verify hdmi and am unable to even get
>>>> the connector to come up. The lt8912b driver complains that the
>>>> connector doesn't support edid read.
>>
>> Looking at the driver, please drop lt8912_bridge_edid_read(),
>> lt8912_bridge_detect() and lt->bridge.ops assignment. Those bits are
>> lame and useless.
>>
>>> Which per the current connector
>>>> node is correct, none of the devices list a ddc node. I am trying to
>>>> investigate this further, but vendor source release unfortunately
>>>> appears to be missing pieces related to this. And no other current
>>>> qcom device uses this bridge to take a guess at which controller the
>>>> ddc is on.
>>>
>>> Go through the I2C buses that are enabled on the vendor kernel and try
>>> inspecting them with toos like i2cdetect
>>
>> I'd second this suggestion. The chip doesn't support EDID reading, so it
>> is (hopefully) handled via some existing bus. Does downstream handle
>> EDID / HDMI at all?
>
> I have been unable to get the stock OS to display anything on hdmi at
> all. The downstream kernel reports the head as DSI, and is hardcoded
> to a 1920x1080 mode in the kernel dt. We have been unable to find any
> kernel handling of this bridge at all for downstream, in the source
> release or the prebuilt kernel shipped with the stock OS. Best I can
> tell, they just hardcode the one mode and nothing else will work.
> There are reports of hdmi audio working, though; which I'm not sure
> how if the bridge has no kernel driver at all.
>
> All i2c nodes used by downstream are already enabled. And when an hdmi
> cable is plugged in, I never see the ddc address, 0x50 if I understand
> correctly, show up on any of them. I tried enabling other i2c nodes to
> check if anything shows up on them, but that causes kernel panics
> during boot and without uart, I can't see why.
>
> This all seems rather broken, perhaps by odm design. Given this state,
> should I just drop all references to hdmi and leave a comment in the
> dts where the bridge should be to explain why?
That's definitely better than describing (for all we know) broken hw
We can always come back to that if a fix is found
Konrad
^ permalink raw reply
* RE: [PATCH V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Sherry Sun @ 2026-04-07 9:18 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <gxqcmujdzlzcoawn4rkttasftuyusqtvycu7oagogxaw4yggeo@ww6rjdwbyj2w>
> On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > > Add support for parsing Root Port child nodes in
> > > > dw_pcie_host_init() using pci_host_common_parse_ports(). This
> > > > allows DWC-based drivers to specify Root Port properties (like
> > > > reset GPIOs) in individual Root Port nodes rather than in the host bridge
> node.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > index da152c31bb2e..f6fca984fb34 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > @@ -20,6 +20,7 @@
> > > > #include <linux/platform_device.h>
> > > >
> > > > #include "../../pci.h"
> > > > +#include "../pci-host-common.h"
> > > > #include "pcie-designware.h"
> > > >
> > > > static struct pci_ops dw_pcie_ops; @@ -581,6 +582,13 @@ int
> > > > dw_pcie_host_init(struct dw_pcie_rp *pp)
> > > >
> > > > pp->bridge = bridge;
> > > >
> > > > + /* Parse Root Port nodes if present */
> > > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > > + if (ret && ret != -ENOENT) {
> > > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > > + return ret;
> > >
> > > Won't this change break drivers that parse Root Ports on their own?
> > > Either you need to modify them also in this change or call this API
> > > from imx6 driver and let other drivers switch to it in a phased manner.
> > >
> > > I perfer the latter.
> >
> > Hi Mani, sorry I didn't fully get your point here, there are no
> > changes to this part V10, for drivers that parse Root Ports on their
> > own, here pci_host_common_parse_ports() will return -ENOENT, so
> > nothing break as we discussed this in V8
> https://lore.ke/
> rnel.org%2Fall%2Fdcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m%40
> vm3ywyyp4ujh%2F&data=05%7C02%7Csherry.sun%40nxp.com%7Cd9faef64b
> 8154bdbc6ee08de94724b22%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C639111415791802118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=POsurqr9RqBCnaQyeXDK2HQTN
> a4Nc0tfl7thSiM9qHA%3D&reserved=0.
> >
>
> So if this API gets called first, it will acquire PERST# from the Root Port node
> and if the controller drivers try to do the same in their own parsing code,
> PERST# request will return -EBUSY and the probe will fail.
>
> On the other hand, if the controller drivers parse PERST# first, this API will
> return -EBUSY and will result in probe failure.
>
> Only way to fix this issue would be to call this API from imx6 driver for now
> and start migrating other drivers later.
>
Ok, get your point here. Your assumption is based on the premise that the controller
driver parse the reset-gpios in the Root Port node, not that most controller drivers
now use reset under the host bridge node. For reset-gpios in the Root Port node,
they should eventually switch to this common API.
Anyway, I will call this API in imx6 driver at this stage to avoid impact other platforms.
Best Regards
Sherry
^ permalink raw reply
* [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-07 9:15 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, Liu Ying
Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
The panel connects with the QSB board through an adapter board[1]
designed by NXP.
Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
.../freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso | 14 +++
4 files changed, 127 insertions(+), 105 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c99..6315fb8390ff 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -455,9 +455,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb.dtb
imx93-9x9-qsb-can1-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-can1.dtbo
imx93-9x9-qsb-i3c-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-i3c.dtbo
imx93-9x9-qsb-ontat-kd50g21-40nt-a1-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo
+imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-tianma-tm050rdh03.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-can1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-i3c.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
new file mode 100644
index 000000000000..d167c9fc3b8f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx93-pinfunc.h"
+
+&{/} {
+ backlight: backlight {
+ compatible = "gpio-backlight";
+ gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel {
+ compatible = "ontat,kd50g21-40nt-a1";
+ backlight = <&backlight>;
+ power-supply = <®_rpi_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+};
+
+&dpi_bridge {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dpi_to_panel: endpoint {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x31e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x31e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x31e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x31e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x31e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x31e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x31e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x31e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x31e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x31e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x31e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x31e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x31e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x31e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x31e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x31e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x31e
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x31e
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x31e
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x31e
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x31e
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x31e
+ >;
+ };
+};
+
+&lcdif {
+ status = "okay";
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&pcal6524 {
+ /*
+ * exp-sel-hog has property 'output-low' while DT overlay doesn't
+ * support /delete-property/. Both 'output-low' and 'output-high'
+ * will exist under hog nodes if DT overlay file sets 'output-high'.
+ * Workaround is to disable this hog and create new hog with
+ * 'output-high'.
+ */
+ exp-sel-hog {
+ status = "disabled";
+ };
+
+ exp-high-sel-hog {
+ gpio-hog;
+ gpios = <22 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+};
+
+&sai3 {
+ /* disable due to GPIO12 and GPIO17~20 pin conflicts with LCDIF */
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
index d167c9fc3b8f..356533a7b513 100644
--- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
@@ -3,108 +3,4 @@
* Copyright 2026 NXP
*/
-/dts-v1/;
-/plugin/;
-
-#include <dt-bindings/gpio/gpio.h>
-#include "imx93-pinfunc.h"
-
-&{/} {
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>;
- };
-
- panel {
- compatible = "ontat,kd50g21-40nt-a1";
- backlight = <&backlight>;
- power-supply = <®_rpi_3v3>;
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&dpi_to_panel>;
- };
- };
- };
-};
-
-&dpi_bridge {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcdif>;
- status = "okay";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dpi_to_panel: endpoint {
- remote-endpoint = <&panel_in>;
- bus-width = <18>;
- };
- };
- };
-};
-
-&iomuxc {
- pinctrl_lcdif: lcdifgrp {
- fsl,pins = <
- MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x31e
- MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x31e
- MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x31e
- MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x31e
- MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x31e
- MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x31e
- MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x31e
- MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x31e
- MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x31e
- MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x31e
- MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x31e
- MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x31e
- MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x31e
- MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x31e
- MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x31e
- MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x31e
- MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x31e
- MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x31e
- MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x31e
- MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x31e
- MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x31e
- MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x31e
- >;
- };
-};
-
-&lcdif {
- status = "okay";
-};
-
-&media_blk_ctrl {
- status = "okay";
-};
-
-&pcal6524 {
- /*
- * exp-sel-hog has property 'output-low' while DT overlay doesn't
- * support /delete-property/. Both 'output-low' and 'output-high'
- * will exist under hog nodes if DT overlay file sets 'output-high'.
- * Workaround is to disable this hog and create new hog with
- * 'output-high'.
- */
- exp-sel-hog {
- status = "disabled";
- };
-
- exp-high-sel-hog {
- gpio-hog;
- gpios = <22 GPIO_ACTIVE_HIGH>;
- output-high;
- };
-};
-
-&sai3 {
- /* disable due to GPIO12 and GPIO17~20 pin conflicts with LCDIF */
- status = "disabled";
-};
+#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
new file mode 100644
index 000000000000..c233797ec28c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
+
+&{/} {
+ panel {
+ compatible = "tianma,tm050rdh03";
+ enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
+ };
+};
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
Best regards,
--
Liu Ying <victor.liu@nxp.com>
^ permalink raw reply related
* Re: [PATCH 7/7] arm64: dts: qcom: sm8750: Correct DPU VBIF address space size
From: Konrad Dybcio @ 2026-04-07 9:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260402-dts-qcom-display-regs-v1-7-daa54ab448a3@oss.qualcomm.com>
On 4/2/26 1:45 PM, Krzysztof Kozlowski wrote:
> VBIF register range is 0x3000 long, so correct the code even though
> missing part seems without practical impact.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X
From: Vladimir Oltean @ 2026-04-07 9:12 UTC (permalink / raw)
To: Jens Emil Schulz Ostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, davem, edumazet, pabeni,
horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <c1b824a3e597b37df133053f6b216e9196b130d5.camel@microchip.com>
On Wed, Apr 01, 2026 at 01:46:19PM +0200, Jens Emil Schulz Ostergaard wrote:
> On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > ---
> > Subject: net: dsa: lan9645x: add basic dsa driver for LAN9645X
> >
> > This commit adds a basic DSA driver for the Microchip LAN9645X switch. It
> > includes initialization, port module setup for NPI, CPU, and front ports,
> > and phylink integration for MAC side configuration.
> >
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > [ ... ]
> > > +static void disable_conduit_ipv6(struct lan9645x *lan9645x,
> > > + struct net_device *conduit)
> > > +{
> > > + struct inet6_dev *dev_v6;
> > > +
> > > + if (!conduit)
> > > + return;
> > > +
> > > + /* IPv6 on the conduit will generate frames bypassing our tag driver, so
> > > + * they lack an IFH. This will be garbage in garbage out and we want to
> > > + * avoid this.
> > > + */
> > > + rtnl_lock();
> > > + dev_v6 = __in6_dev_get(conduit);
> > > + if (dev_v6) {
> > > + WRITE_ONCE(dev_v6->cnf.disable_ipv6, 1);
> > > + dev_warn(lan9645x->dev, "Disabled IPv6 on conduit device: %s\n",
> > > + netdev_name(conduit));
> > > + }
> > > + rtnl_lock();
> > > +}
> >
> > Does directly modifying dev_v6->cnf.disable_ipv6 bypass the proper sysctl
> > teardown path (addrconf_disable_ipv6) and leave the IPv6 stack in an
> > inconsistent state on the conduit device by failing to clean up routes,
> > addresses, and MLD memberships?
> >
> > Is it a layering violation for a switch driver to alter the networking
> > configuration of an external upper device, especially since this change
> > isn't reverted during driver unbind?
>
> Yes this will bypass the sysctl teardown path. I can change this to instead
> read disable_ipv6 state and warn the user that their device is misconfigured.
I don't want to have to deal with a DSA driver altering the conduit
configuration outside of the DSA core. NACK to any attempts of trying
this.
Define "garbage in, garbage out" for your case. The packets are sent to
random ports? Normally, switches are configured by their drivers to drop
those packets that don't contain DSA tags. You can also do that, by
setting up the switch to require an injection prefix.
> > [ ... ]
> > > + /* Configure IFH prefix mode for NPI port. */
> > > + lan_rmw(SYS_PORT_MODE_INCL_XTR_HDR_SET(LAN9645X_TAG_PREFIX_LONG) |
> > > + SYS_PORT_MODE_INCL_INJ_HDR_SET(LAN9645X_TAG_PREFIX_NONE),
> > > + SYS_PORT_MODE_INCL_XTR_HDR |
> > > + SYS_PORT_MODE_INCL_INJ_HDR,
> > > + lan9645x,
> > > + SYS_PORT_MODE(p->chip_port));
> >
> > Setting LAN9645X_TAG_PREFIX_NONE means the hardware interprets the first
> > bytes of any frame received from the host as an IFH command structure.
> >
> > Does this allow a local user to transmit crafted frames (for example, via
> > raw sockets or standard protocols) whose MAC address bytes map to malicious
> > IFH commands, thereby bypassing VLAN isolation or flooding the switch?
> >
> > Should the hardware be configured to require a strict prefix, such as
> > LAN9645X_TAG_PREFIX_LONG, for injected frames to prevent this?
>
> A prefix offers no protection against the described scenario. The current
> configuration is correct. If a prefix is configured frames MUST contain the
> prefix. With the conduit exposed in userspace this is not something we can
> guarantee.
The short prefix prevents user space from sending frames by mistake
which will reach the wire (daemons attaching to all interfaces, like for DHCP).
It still allows user space to intentionally inject frames into the
switch (for example from XDP on the conduit).
I recommend you go for the short prefix and drop the conduit alterations.
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > [ ... ]
> > > +static int lan9645x_setup(struct dsa_switch *ds)
> > > +{
> > > + struct lan9645x *lan9645x = ds->priv;
> > > + struct device *dev = lan9645x->dev;
> > > + u32 all_phys_ports;
> > > + int err;
> > > +
> > > + lan9645x->num_phys_ports = ds->num_ports;
> > > + all_phys_ports = GENMASK(lan9645x->num_phys_ports - 1, 0);
> > > +
> > > + err = lan9645x_reset_switch(lan9645x);
> > > + if (err)
> > > + return err;
> > > +
> > > + lan9645x->ports = devm_kcalloc(lan9645x->dev, lan9645x->num_phys_ports,
> > > + sizeof(struct lan9645x_port *),
> > > + GFP_KERNEL);
> >
> > Since the DSA .setup callback can be invoked multiple times during the
> > platform device's lifetime (for example, when the DSA master interface is
> > unbound and bound again), does using devm_kcalloc here cause a memory leak?
> > Should these allocations be moved to .probe or managed with kcalloc and
> > freed in .teardown?
> >
>
> Hmm I do not think this is right? I think dsa_tree_teardown is called from
> dsa_switch_remove which is called by the switch drivers .remove.
>
> So I do not think you can get multiple setup/teardown cycles during the device
> lifetime?
>
> As far as I can tell both felix and ksz use device managed allocations in their
> setup callback.
It's valid feedback in general. In a multi-switch tree, ds->ops->setup()
is called when the tree is complete, and ds->ops->teardown() when the
first switch disappears. If there are 2 switches and you unbind and
rebind the driver from A, then switch B will see a ds->ops->teardown()
call followed by ds->ops->setup().
In your case, since the switch doesn't support cascading, it probably
doesn't matter. But the LLM doesn't have the context to know that.
> > [ ... ]
> > > + /* Set all the entries to obey VLAN. */
> > > + for (int i = 0; i < PGID_ENTRIES; ++i)
> > > + lan_wr(ANA_PGID_CFG_OBEY_VLAN_SET(1),
> > > + lan9645x, ANA_PGID_CFG(i));
> >
> > PGID_ENTRIES is defined as 89, so this loop initializes indices 0 through
> > 88. Since the CPU port is index 9, its source PGID is PGID_SRC + CPU_PORT
> > (80 + 9 = 89).
> >
> > Is index 89 left uninitialized, breaking the OBEY_VLAN rule and allowing
> > CPU-injected frames to leak across VLAN boundaries?
> >
>
> No I this misunderstands OBEY_VLAN. When set the vlan table can control
> whether cpu copy from the pgid table is enabled. It makes no sense for PGID 89.
Explain that in a comment.
> > [ ... ]
> > > + /* Multicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MC));
> > > +
> > > + /* IP multicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV4));
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV6));
> > > +
> > > + /* Unicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_UC));
> > > +
> > > + /* Broadcast to all ports */
> > > + lan_wr(BIT(CPU_PORT) | all_phys_ports, lan9645x, ANA_PGID(PGID_BC));
> >
> > PGID_BC includes BIT(CPU_PORT) and all_phys_ports (which includes the NPI
> > port). Will this forward broadcast frames to both the CPU extraction queue
> > and the NPI port's normal egress queue, causing duplicate frames for the host?
> >
> > Conversely, the multicast masks and PGID_UC exclude BIT(CPU_PORT). Does
> > this cause them to bypass the CPU extraction queue entirely, thereby
> > lacking the LONG extraction prefix and breaking the host's DSA tagger parsing?
> >
>
> No this is not how it works. Generally when you configure the CPU port to use
> an NPI port, the hardware manages this internally. You do you have to start
> using the npi port number all of a sudden.
The comment is fair though. Why would you set all_phys_ports to
GENMASK(lan9645x->num_phys_ports - 1, 0) when you can compute the mask
of user ports which are enabled? It seems sloppy at best, and also
contradictory (comments say "all front ports", but code includes the NPI
port in this mask).
> > [ ... ]
> > > +int lan9645x_port_setup(struct dsa_switch *ds, int port)
> > > +{
> > > + struct dsa_port *dp = dsa_to_port(ds, port);
> > > + struct lan9645x *lan9645x = ds->priv;
> > > + struct lan9645x_port *p;
> > > +
> > > + p = lan9645x_to_port(lan9645x, port);
> > > +
> > > + if (dp->dn) {
> > > + p->rx_internal_delay =
> > > + of_property_present(dp->dn, "rx-internal-delay-ps");
> > > + p->tx_internal_delay =
> > > + of_property_present(dp->dn, "tx-internal-delay-ps");
> > > + }
> >
> > These are standard integer properties specifying delays in picoseconds. If
> > a user explicitly disables the delay via devicetree using a value of 0,
> > will of_property_present evaluate to true and enable the hardware delay
> > anyway? Should of_property_read_u32 be used instead to check the value?
>
> A value of 0 is not allowed per the bindings. The bindings enforce that if this
> is present the value must be 2000.
Bindings may change. Please use of_property_read_u32().
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Johan Hovold @ 2026-04-07 9:07 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Mark Brown, alexander.stein, andrew, andrew,
andriy.shevchenko, astewart, bhelgaas, brgl, davem, devicetree,
driver-core, hkallweit1, jirislaby, joel, kees, kuba, lgirdwood,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pci,
linux-serial, linux-usb, linux, mani, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Doug Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
This flag is only set before registering a device with driver core so
there is no issue using the existing bitfield here (with the caveat that
PCI pwrctrl may have gotten that wrong). I haven't checked the other
flags, but I assume most of them work the same way.
But apart from the commit message being misleading, switching to using
atomic ops and accessors for consistency is fine.
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
These two uses are broken currently though and should be using
device_set_of_node_from_dev() so that an extra reference is taken to
balance the one dropped by the platform bus code.
I'll send two fixes to Mark, any merge conflict should be trivial to
fixup.
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: PK Lee @ 2026-04-07 9:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <258747f4-9da5-44da-8eb9-24f8a8cbff3a@lunn.ch>
> > +&mac3 {
> > + status = "okay";
> > + phy-mode = "rmii";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_rmii4_default>;
> > + fixed-link {
> > + speed = <100>;
> > + full-duplex;
> > + };
>
> What is on the other end of this fixed link?
The other end of this fixed link is the CPU port of a Marvell 88E6393X
switch. We are using this switch in unmanaged mode rather than using
the DSA subsystem. Therefore, we use a fixed-link to force the mac3 to
100Mbps full-duplex RMII to match the CPU port configuration.
>
> > +};
> > +
> > +&mdio0 {
> > + status = "okay";
> > +};
>
> If there are no devices on the bus, why enable it?
We intentionally enable it so user-space tools can access the switch
registers. I have added a comment in v13 to clarify this.
>
> Andrew
P.K. Lee
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: qcom: sm8550-hdk: update PCIe port label reference
From: Joe Sandom @ 2026-04-07 8:55 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <bzbxyduvwlk42yj6mchu2denfvhqemahdeuuwxgzpbz52kmhn5@roukkyhpdbwf>
On Sun, Apr 05, 2026 at 12:07:39AM +0300, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 10:50:55AM +0100, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > Update the pcieport0 reference to pcie0_port0 to match the label
> > rename in sm8550.dtsi.
>
> This one (and the next one) should be squashed with the port label
> rename.
Thanks for the correction. Will address this in v2
>
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> > index ee13e6136a8259d28540e718851e094f74ead278..e821b731bdc496c872703723df02ae9b9b0233b5 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> > +++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> > @@ -1012,7 +1012,7 @@ &pcie0 {
> > status = "okay";
> > };
> >
> > -&pcieport0 {
> > +&pcie0_port0 {
> > wifi@0 {
> > compatible = "pci17cb,1107";
> > reg = <0x10000 0x0 0x0 0x0 0x0>;
> >
> > --
> > 2.34.1
> >
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: qcom: sm8550: add PCIe MHI register regions and port labels
From: Joe Sandom @ 2026-04-07 8:53 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <sdr64ldaoitb7rj6a7eupmqrsh47wgir6nkbsnbsv6bpftiqyf@youdquby6sog>
On Sun, Apr 05, 2026 at 12:07:14AM +0300, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 10:50:54AM +0100, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > Add the MHI register regions to the pcie0 and pcie1 controller nodes
> > so that the MHI bus layer can access controller registers directly.
> >
> > Also add labels to the root port nodes (pcie0_port0, pcie1_port0) to
> > allow board DTS files to reference them for adding endpoint devices
> > to each pcie root port.
>
> Two separate changes, please.
ack. Will address this in v2
>
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/sm8550.dtsi | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 912525e9bca6f5e1cbb8887ee0bf9e39650dc4ff..d4caf4d00832d7f1e8f65bf2bc873cddadc42168 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -1964,8 +1964,9 @@ pcie0: pcie@1c00000 {
> > <0 0x60000000 0 0xf1d>,
> > <0 0x60000f20 0 0xa8>,
> > <0 0x60001000 0 0x1000>,
> > - <0 0x60100000 0 0x100000>;
> > - reg-names = "parf", "dbi", "elbi", "atu", "config";
> > + <0 0x60100000 0 0x100000>,
> > + <0 0x01C03000 0 0x1000>;
>
> Lowercase the hex, align vertically.
ack. Will address this in v2
>
> > + reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
> > @@ -2092,7 +2093,7 @@ opp-16000000-3 {
> > };
> > };
> >
> > - pcieport0: pcie@0 {
> > + pcie0_port0: pcie@0 {
> > device_type = "pci";
> > reg = <0x0 0x0 0x0 0x0 0x0>;
> > bus-range = <0x01 0xff>;
> > @@ -2138,8 +2139,9 @@ pcie1: pcie@1c08000 {
> > <0x0 0x40000000 0x0 0xf1d>,
> > <0x0 0x40000f20 0x0 0xa8>,
> > <0x0 0x40001000 0x0 0x1000>,
> > - <0x0 0x40100000 0x0 0x100000>;
> > - reg-names = "parf", "dbi", "elbi", "atu", "config";
> > + <0x0 0x40100000 0x0 0x100000>,
> > + <0x0 0x01C0B000 0x0 0x1000>;
> > + reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
> > @@ -2288,7 +2290,7 @@ opp-32000000-4 {
> > };
> > };
> >
> > - pcie@0 {
> > + pcie1_port0: pcie@0 {
> > device_type = "pci";
> > reg = <0x0 0x0 0x0 0x0 0x0>;
> > bus-range = <0x01 0xff>;
> >
> > --
> > 2.34.1
> >
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [RFC PATCH 06/15] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
From: Herve Codina @ 2026-04-07 8:51 UTC (permalink / raw)
To: Luca Ceresoli
Cc: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <DHHWY06CRC21.XENO1ENNAV55@bootlin.com>
Hi Luca, David,
On Wed, 01 Apr 2026 17:11:42 +0200
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> > In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> > at the offset 0 of the structure block.
> >
> > This assumption is not correct. Indeed, a FDT_NOP can be present at the
> > offset 0 and this is a legit case.
> >
> > fdt_first_node() has been introduce recently to get the offset of the
> ^
> introduced
Will be fixed in the next iteration.
...
> > int fdt_next_node(const void *fdt, int offset, int *depth)
> > {
> > - int nextoffset = 0;
> > + int nextoffset = offset;
> > uint32_t tag;
> >
> > + if (offset <= 0) {
>
> What is the difference between 0 and a engative value?
I will add a comment in the code.
0 means that we want the next node from the first node.
The negative value is an invalid value. In that case we start from the
first node. This was the behavior of the code without my modification and
I kept the same behavior in that case.
>
> This is where the parameter value is not obvious to the newcomer and I'd
> love seeing it concisely documented.
David, is functions documentation expected ?
I can add to this documentation if you want it.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Thomas Richard @ 2026-04-07 8:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260405-smoky-spectacular-koel-dbfcda@quoll>
Hello Krzysztof,
On 4/5/26 10:06 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 09:02:23PM +0200, Thomas Richard wrote:
>> Create schema for LAN75XX compatible USB Ethernet controllers. The smsc75xx
>> driver only supports LAN7500 and LAN7505 devices.
>>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52 ++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>
> Rather microchip,lan7500.yaml. Wildcards don't really scale when you
> have 75yy coming which does not fit into this binding.
>
>
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
>> +
>> +maintainers:
>> + - Thomas Richard <thomas.richard@bootlin.com>
>> +
>> +description:
>> + Device tree properties for LAN75XX compatible USB Ethernet controller.
>> +
>> +allOf:
>> + - $ref: ethernet-controller.yaml#
>> +
>> +properties:
>> + compatible:
>> + items:
>
> Drop items, that's enum directly.
>
>> + - enum:
>> + - usb424,7500
>> + - usb424,7505
>
> But you should notice that this is exactly the same as 95xx, so why it
> cannot go there? Because of the wildcard 95xx naming? That's not a
> reason.
Yes I noticed. I did not put them in 95xx because it is not the same
driver. Isn't that a valid reason?
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH net-next v2 9/9] net: dsa: lan9645x: add port statistics
From: Jens Emil Schulz Ostergaard @ 2026-04-07 8:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195639.2789284-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: dsa: lan9645x: add port statistics
>
> Add statistics support for the port counters. Chip registers are 32 bit,
> so this unit is responsible maintaining a 64bit software cache, and
> updating it frequently to handle overflows in hardware.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > index 24a60f40f6b8..9a46c08dad59 100644
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> [ ... ]
> > @@ -262,6 +264,12 @@ static int lan9645x_setup(struct dsa_switch *ds)
> > if (!lan9645x->owq)
> > return -ENOMEM;
> >
> > + err = lan9645x_stats_init(lan9645x);
> > + if (err) {
> > + dev_err(dev, "Failed to init stats.\n");
> > + goto owq_destroy;
> > + }
> > +
> [ ... ]
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> > index 000000000000..3e82a859f173
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> [ ... ]
> > +static const struct lan9645x_ethtool_stat lan9645x_port_ethtool_stats[] = {
> > + { "rx_uc", SCNT_RX_UC },
> > + { "rx_cat_drop", SCNT_RX_CAT_DROP },
> [ ... ]
> > + { "tx_uc", SCNT_TX_UC },
> > + { "tx_drop", SCNT_TX_DROP },
> [ ... ]
> > +};
>
> Is it necessary to duplicate standard networking statistics in the driver
> private ethtool output?
>
> The networking subsystem guidelines state that stats possessing a standard UAPI
> representation, such as tx_dropped and rx_packets in struct rtnl_link_stats64,
> should not be duplicated in the ethtool -S output.
>
> Could these redundant strings be removed since the driver natively supports
> them via lan9645x_stats_get_stats64?
>
I do not think they are redundant. They are only available in an aggregated form
via rtnl_link_stats64, not directly. Information is lost if they are removed.
> [ ... ]
> > +static const struct lan9645x_view_stats lan9645x_view_stat_cfgs[] = {
> > + [LAN9645X_STAT_PORTS] = {
> > + .name = "ports",
> > + .type = LAN9645X_STAT_PORTS,
> > + .layout = lan9645x_port_stats_layout,
> > + .num_cnts = ARRAY_SIZE(lan9645x_port_stats_layout),
> > + .num_indexes = NUM_PHYS_PORTS,
> > + },
> > +};
> [ ... ]
> > +static u64 *lan9645x_stats_view_idx_update(struct lan9645x *lan9645x,
> > + enum lan9645x_view_stat_type vtype,
> > + int idx)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > +
> > + mutex_lock(&s->hw_lock);
> > + __lan9645x_stats_view_idx_update(lan9645x, vtype, idx);
> > + mutex_unlock(&s->hw_lock);
> > +
> > + return STAT_COUNTERS(lan9645x, vtype, idx);
> > +}
>
> Does this code overflow the allocated buffer when called for the CPU port?
>
> The stats buffer cnts is allocated using num_indexes, which is NUM_PHYS_PORTS
> (9). This covers ports 0 to 8. However, the CPU port is defined as index 9
> (CPU_PORT = 9).
>
> When the DSA core invokes stat callbacks like get_ethtool_stats or get_stats64
> for the CPU port, the idx argument is 9. While the helper
> __lan9645x_stats_view_idx_update skips the hardware read for out-of-bounds
> indices, lan9645x_stats_view_idx_update ignores that failure and returns the
> result of STAT_COUNTERS(lan9645x, vtype, idx).
>
> This computes a pointer past the end of the cnts array, which the callers then
> blindly dereference, potentially leaking kernel memory or causing a crash. Can
> bounds checking be added to the callers, or should the buffer be sized to
> include the CPU port?
>
No this is not called for the CPU port index 9.
> [ ... ]
> > +void lan9645x_stats_get_ethtool_stats(struct lan9645x *lan9645x, int port,
> > + u64 *data)
> > +{
> > + struct lan9645x_stats *stats = lan9645x->stats;
> > + u64 *c;
> > + int i;
> > +
> > + c = lan9645x_stats_view_idx_update(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&stats->sw_lock);
> > + for (i = 0; i < ARRAY_SIZE(lan9645x_port_ethtool_stats); i++)
> > + *data++ = c[lan9645x_port_ethtool_stats[i].idx];
> > + spin_unlock(&stats->sw_lock);
> > +}
> [ ... ]
> > +/* Called in atomic context */
> > +void lan9645x_stats_get_stats64(struct lan9645x *lan9645x, int port,
> > + struct rtnl_link_stats64 *stats)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > + u64 *c;
> > +
> > + c = STAT_COUNTERS(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&s->sw_lock);
>
> Can this code deadlock when a softirq interrupts a process holding the lock?
>
> The sw_lock spinlock protects the 64-bit software stats counters. In
> lan9645x_stats_get_stats64, which acts as the ndo_get_stats64 callback, this
> lock is acquired using a plain spin_lock. The code comment notes this function
> is called in atomic context (such as from NET_RX_SOFTIRQ via dev_get_stats).
>
> Concurrently, process context paths like lan9645x_stats_get_ethtool_stats and
> lan9645x_check_stats_work also acquire sw_lock using plain spin_lock. Because
> plain spin_lock does not disable softirqs, if a softirq preempts the execution
> on a CPU while process context holds sw_lock, the softirq will spin
> indefinitely waiting for the lock.
>
> Should the process-context acquisitions use spin_lock_bh instead?
>
As far as I can tell ndo_get_stats64 is not called from softirq. Ocelot also uses
a plain spin_lock here. Since no softirq path touches this lock, there is no
deadlock.
> [ ... ]
> > +int lan9645x_stats_init(struct lan9645x *lan9645x)
> > +{
> > + const struct lan9645x_view_stats *vs;
> > + struct lan9645x_stats *stats;
> > + int err, i;
> > +
> > + lan9645x->stats = devm_kzalloc(lan9645x->dev, sizeof(*stats),
> > + GFP_KERNEL);
>
> Will this memory be leaked when the DSA switch unbinds and rebinds?
>
> The lan9645x_stats_init function allocates lan9645x->stats, vstat->cnts, and
> vstat->buf using devm_kzalloc and devm_kcalloc. This function is called from
> lan9645x_setup, which is the DSA .setup callback.
>
> The DSA tree lifecycle is independent of the platform device lifecycle. If the
> master netdevice is unbound and bound again, the DSA switch's .teardown and
> .setup callbacks will be invoked multiple times. Because .teardown cannot free
> devres-managed memory, the memory tied to the platform device will be leaked
> on every setup cycle until the switch's platform device itself is destroyed.
>
> Could this use standard kzalloc allocations paired with kfree in teardown?
Similar comment as the devm_* comment for the .setup function. I do not think
this is a problem, since there can not be multiple setup/teardown cycles
during the device lifetime. dsa_tree_teardown is only called from
dsa_switch_remove which is called by the switch drivers .remove.
As far as I can tell both felix and ksz use device managed allocations in their
setup callback.
^ permalink raw reply
* [PATCH v6 9/9] riscv: dts: spacemit: k1-musepi-pro: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
From: Trevor Gamblin <tgamblin@baylibre.com>
Update the Muse Pi Pro devicetree with SD card support to match what
was done for the OrangePi RV2 in [1]. More precisely:
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
[1] https://lore.kernel.org/linux-riscv/20260316-orangepi-sd-card-uhs-v3-0-aefd3b7832df@gmail.com/T/#
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts | 66 ++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts b/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
index 29e333b670cf0a5c4ed852668460db475b9c44cb..774a4640f06562b5632c510e8961e3d8f60a3b81 100644
--- a/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
@@ -18,6 +18,24 @@ aliases {
ethernet0 = ð0;
serial0 = &uart0;
};
+ reg_dc_in: dc-in-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_in_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_vcc_4v: vcc-4v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_4v";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <4000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
chosen {
stdout-path = "serial0";
@@ -77,3 +95,51 @@ &uart0 {
pinctrl-names = "default";
status = "okay";
};
+
+&i2c8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c8_cfg>;
+ status = "okay";
+
+ pmic@41 {
+ compatible = "spacemit,p1";
+ reg = <0x41>;
+ interrupts = <64>;
+ vin-supply = <®_vcc_4v>;
+
+ regulators {
+ buck4: buck4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ aldo1: aldo1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 8/9] riscv: dts: spacemit: k1-bananapi-f3: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add complete SD card controller support with UHS high-speed modes.
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
This enables full SD card functionality including high-speed UHS modes
for improved performance.
Suggested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 5790d927b93db350c8f53aa0f314183b3173fd76..a7d88564630f3332270ba5fe47b078bb14f564e5 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -220,7 +220,7 @@ buck3_1v8: buck3 {
regulator-always-on;
};
- buck4 {
+ buck4: buck4 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3300000>;
regulator-ramp-delay = <5000>;
@@ -241,7 +241,7 @@ buck6 {
regulator-always-on;
};
- aldo1 {
+ aldo1: aldo1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-boot-on;
@@ -367,3 +367,23 @@ hub_3_0: hub@2 {
reset-gpios = <&gpio K1_GPIO(124) GPIO_ACTIVE_LOW>;
};
};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ broken-cd;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.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