* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Bartosz Golaszewski @ 2026-06-11 8:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <ailxrP-_9_NL8qnN@ashevche-desk.local>
On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
>> When a USB hub port is connected to a connector in a firmware node
>> graph, the port itself has a node in the graph.
>>
>> Associate the port's firmware node with the USB port's device,
>> usb_port::dev. This is used in later changes for the M.2 slot power
>> sequencing provider to match against the requesting port.
>
> Okay, would this affect ACPI-based systems? if so, how?
> Can you elaborate on that, please?
>
Is it possible that there's an ACPI device node associated with the port like
on some DT systems? I don't think so and there should be no impact IMO but I
also don't know enough about ACPI.
Bart
^ permalink raw reply
* Re: [PATCH v2 06/16] usb: hub: Pass |struct usb_port*| to usb_port_is_power_on()
From: Bartosz Golaszewski @ 2026-06-11 8:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-7-wenst@chromium.org>
On Wed, 10 Jun 2026 10:40:40 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> usb_port_is_power_on() currently takes |struct usb_hub*|, but only needs
> it to tell if the hub/port is SuperSpeed or not.
>
> In a subsequent change, usb_port_is_power_on() needs access to a pwrseq
> state tracking field in |struct usb_port|. Either structure can be used
> to identify whether a port/hub is SuperSpeed or not, as the field in
> |struct usb_port| is inherited from the hub:
>
> port->is_superspeed = hub_is_superspeed(hub)
>
> Replace usb_port_is_power_on()'s |struct usb_hub*| parameter with
> |struct usb_port*| so a subsequent change can use it.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
Makes sense.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/4] ASoC: meson: aiu: align I2S design to the AXG one
From: Jerome Brunet @ 2026-06-11 8:28 UTC (permalink / raw)
To: Valerio Setti
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, linux-kernel,
linux-sound, linux-arm-kernel, linux-amlogic
In-Reply-To: <20260610-reshape-aiu-as-axg-v2-0-cac3663a8b51@baylibre.com>
On mer. 10 juin 2026 at 23:29, Valerio Setti <vsetti@baylibre.com> wrote:
> The goal of this series is to reshape Amlogic GX's AIU implementation for
> I2S to let it follow the same design as in AXG's TDM. Keeping the same
> design allows for unifying the two platform implementations in the future
> and it also allows for an easy addition of I2S input.
>
> The first commit introduces gx-formatter as the basic block which takes
> care of properly formatting audio data. Formatters are DAPM widgets
> (c.f. axg-tdm-formatter in AXG) which are dynamically attached/detached
> to the streams when the latters starts/stop, respectively.
> aiu-formatter-i2s is introduced as formatter implementation for the i2s
> output.
>
> By the end aiu-encoder-i2s will only need to handle interface clocks and
> enforce interface wide rate symmetry (c.f axg-tdm-interface on the AXG
> platform). Right now rate symmetry is not relevant because only i2s output
> is supported, but it will become useful when following patch series will
> introduce the i2s input part.
>
> This series was tested on an OdroidC2 board (Amlogic S905 SOC) both with
> HDMI output and with NXP SGTL5000 codec connected to the I2S pins.
> This series was also verified using "pcm-test" test tool and all tests
> are passing.
>
> Changes in v2:
> - Fixed most of the weaknesses found by Sashiko review tool [1].
> - Resolved testing failures with "pcm-test" as reported by Mark Brown
> (thanks for the heads up!). I left a comment in
> "aiu_encoder_i2s_startup" to explain the fix.
>
> Link to v1: https://lore.kernel.org/r/20260515-reshape-aiu-as-axg-v1-0-53b457784ff3@baylibre.com
>
> [1]: https://sashiko.dev/#/patchset/20260515-reshape-aiu-as-axg-v1-0-53b457784ff3%40baylibre.com
>
> Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Nice work. Thanks for taking the time to understand the existing drivers
and build upon them !
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Feel free to add yourself as maintainer of the Amlogic audio drivers, if
you fancy doing so ;)
> ---
> Valerio Setti (4):
> ASoC: meson: gx: add gx-formatter and gx-interface
> ASoC: meson: aiu-encoder-i2s: prepare for multiple streams
> ASoC: meson: aiu: introduce I2S output formatter
> ASoC: meson: aiu: use aiu-formatter-i2s to format I2S output data
>
> sound/soc/meson/Makefile | 2 +
> sound/soc/meson/aiu-encoder-i2s.c | 281 +++++++++++++++++++++++++----------
> sound/soc/meson/aiu-formatter-i2s.c | 104 +++++++++++++
> sound/soc/meson/aiu.c | 32 +++-
> sound/soc/meson/aiu.h | 4 +
> sound/soc/meson/gx-formatter.c | 282 ++++++++++++++++++++++++++++++++++++
> sound/soc/meson/gx-formatter.h | 56 +++++++
> sound/soc/meson/gx-interface.h | 48 ++++++
> 8 files changed, 731 insertions(+), 78 deletions(-)
> ---
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> change-id: 20260515-reshape-aiu-as-axg-1dac9037cad3
>
> Best regards,
--
Jerome
^ permalink raw reply
* [PATCH] firmware: arm_scmi: Use common error handling code in __scmi_device_create()
From: Markus Elfring @ 2026-06-11 8:34 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel, Cristian Marussi, Sudeep Holla
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 11 Jun 2026 10:27:45 +0200
Use an additional label so that a bit of exception handling can be better
reused at the end of an if branch.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/firmware/arm_scmi/bus.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 793be9eabaed..8c20ed1a8243 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -450,14 +450,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
return NULL;
scmi_dev->name = kstrdup_const(name ?: "unknown", GFP_KERNEL);
- if (!scmi_dev->name) {
- kfree(scmi_dev);
- return NULL;
- }
+ if (!scmi_dev->name)
+ goto free_scmi_dev;
id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
if (id < 0) {
kfree_const(scmi_dev->name);
+free_scmi_dev:
kfree(scmi_dev);
return NULL;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 0/3] tty: serial: Add Cortina-Access UART driver and platform support
From: Arnd Bergmann @ 2026-06-11 8:35 UTC (permalink / raw)
To: Jason Li, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <JH0PR01MB5777B84BE8D9987329ABA54BA21B2@JH0PR01MB5777.apcprd01.prod.exchangelabs.com>
On Thu, Jun 11, 2026, at 07:27, Jason Li wrote:
> Hi Arnd,
>
> Your memory is truly amazing; you even remember a submission from a few
> years ago.
No, I just looked up your previous submissions when I saw the new one,
lore.kernel.org never forgets anything ;-)
> Yes, we expect actual end-user products based on these SoCs, and our
> intention is to provide complete upstream support over time. The UART
> driver and DTS support submitted in this series are the first step in
> that effort.
>
> Cortina-System and Cortina-Access are now totally different company.
> Current aarch64 chipset are totally different with legacy gemini
> processor.
> Realtek has many business unit, different BU may have upstream plan but
> they are individual.
> Although Cortina-Access is a wholly-owned subsidiary of Realtek, our
> product development is entirely independent.
Thanks for the information. Please make sure to add something along
these into the changeset text for the initial arm64 patch, along
with a brief description of what type of chip this is
Arnd
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Andy Shevchenko @ 2026-06-11 8:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <CAMRc=MdiwQM6yk8FXcc+RisVP2iqWKWzVsn2-Yy6dyJXt-1X=Q@mail.gmail.com>
On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
> On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
> >> When a USB hub port is connected to a connector in a firmware node
> >> graph, the port itself has a node in the graph.
> >>
> >> Associate the port's firmware node with the USB port's device,
> >> usb_port::dev. This is used in later changes for the M.2 slot power
> >> sequencing provider to match against the requesting port.
> >
> > Okay, would this affect ACPI-based systems? if so, how?
> > Can you elaborate on that, please?
>
> Is it possible that there's an ACPI device node associated with the port like
> on some DT systems? I don't think so and there should be no impact IMO but I
> also don't know enough about ACPI.
The API is agnostic. There is a possibility to have software nodes associated
with the port. I think the best is to be sure that ACPI-aware people who are
experts in USB will check this (Heikki?).
Also note Sashiko complain on reference count leakage.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: aspeed: add BMC-side PCIe BMC device driver
From: Grégoire Layet @ 2026-06-11 8:40 UTC (permalink / raw)
To: Andrew Jeffery
Cc: joel, andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel
In-Reply-To: <4839c31f666b612799a795bb47c884901fd2a903.camel@codeconstruct.com.au>
Hello Andrew,
> It's probably best to use ASPEED's SDK as a source of inspiration for
> fixing obscure bugs, but not send drivers directly extracted from it.
I would like to discuss the different options then.
If we decide to continue on the current path, I'll modify the code according
to your remarks.
> We should avoid adding more drivers in drivers/soc/aspeed where we can.
> Is this really necessary?
This driver (for the BMC side) only enables some configuration on the SCU to
make MSI interrupts work. It is a very specific configuration, which is why I
thought it was OK as a separate driver.
Fundamentally, the BMC side driver is not necessary. During my testing,
I successfully made data flow in both directions without the BMC side driver,
but this was using polling mode (IRQ = 0), it's not ideal.
It is also possible to put the SCU initialisation on the
8250_aspeed_vuart driver
directly. This could be activated with a specific flag added to VUART nodes
('pcie2vuart' for example) on the DeviceTree.
Putting this configuration in the VUART driver directly would make the setup
on the devicetree easier and more understandable. Because in this series, the
bmc side driver needs a bmc_device node to be loaded. But the bmc_dev node
doesn't hold any meaningful information.
If we decide to take this approach, I think we should also add the
differentiation for the ast2600 compatibility. Currently, the aspeed-g6.dtsi
uses the "aspeed,ast2500-vuart" compatibility entry for the four VUARTs.
What do you think about this solution ?
Thanks,
Grégoire
On Wed, 10 Jun 2026 at 14:33, Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> Hello Grégoire,
>
> On Mon, 2026-06-08 at 14:51 +0000, Grégoire Layet wrote:
> > Taken from ASPEED 6.18 Kernel SDK
>
> It's probably best to use ASPEED's SDK as a source of inspiration for
> fixing obscure bugs, but not send drivers directly extracted from it.
>
> >
> > Add support for VUART over PCIe between BMC and host.
> > This add BMC side driver.
> >
> > Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
> > Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
> > Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> > Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
> > ---
> > drivers/soc/aspeed/Kconfig | 7 ++
> > drivers/soc/aspeed/Makefile | 1 +
> > drivers/soc/aspeed/aspeed-bmc-dev.c | 187 ++++++++++++++++++++++++++++
>
> We should avoid adding more drivers in drivers/soc/aspeed where we can.
>
> Is this really necessary?
>
> > 3 files changed, 195 insertions(+)
> > create mode 100644 drivers/soc/aspeed/aspeed-bmc-dev.c
> >
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > index f579ee0b5afa..3e1fcf3c3268 100644
> > --- a/drivers/soc/aspeed/Kconfig
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -4,6 +4,13 @@ if ARCH_ASPEED || COMPILE_TEST
> >
> > menu "ASPEED SoC drivers"
> >
> > +config ASPEED_BMC_DEV
> > + tristate "ASPEED BMC Device"
> > + default n
> > + help
> > + Enable support for the ASPEED AST2600 BMC Device.
> > + This exposes the PCIe-to-LPC bridge of the BMC to the host over PCIe.
> > +
> > config ASPEED_LPC_CTRL
> > tristate "ASPEED LPC firmware cycle control"
> > select REGMAP
> > diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
> > index b35d74592964..fab0d247df66 100644
> > --- a/drivers/soc/aspeed/Makefile
> > +++ b/drivers/soc/aspeed/Makefile
> > @@ -1,4 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_ASPEED_BMC_DEV) += aspeed-bmc-dev.o
> > obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > obj-$(CONFIG_ASPEED_UART_ROUTING) += aspeed-uart-routing.o
> > diff --git a/drivers/soc/aspeed/aspeed-bmc-dev.c b/drivers/soc/aspeed/aspeed-bmc-dev.c
> > new file mode 100644
> > index 000000000000..7a204b543c97
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/aspeed-bmc-dev.c
> > @@ -0,0 +1,187 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +// Copyright (C) ASPEED Technology Inc.
> > +
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/errno.h>
> > +
> > +#include <linux/of_address.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include <linux/regmap.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/mfd/syscon.h>
> > +
> > +#define SCU_TRIGGER_MSI
> > +
> > +/* AST2600 SCU */
> > +#define ASPEED_SCU04 0x04
> > +#define AST2600A3_SCU04 0x05030303
> > +#define ASPEED_SCUC20 0xC20
> > +#define ASPEED_SCUC24 0xC24
>
> These could all use properly descriptive names.
>
> Pinctrl is an exception because of how the documentation is structured.
>
> > +#define MSI_ROUTING_MASK GENMASK(11, 10)
> > +#define PCIDEV1_INTX_MSI_HOST2BMC_EN BIT(18)
> > +#define MSI_ROUTING_PCIe2LPC_PCIDEV0 (0x1 << 10)
> > +#define MSI_ROUTING_PCIe2LPC_PCIDEV1 (0x2 << 10)
> > +
> > +#define ASPEED_SCU_PCIE_CONF_CTRL 0xC20
> > +#define SCU_PCIE_CONF_BMC_DEV_EN BIT(8)
> > +#define SCU_PCIE_CONF_BMC_DEV_EN_MMIO BIT(9)
> > +#define SCU_PCIE_CONF_BMC_DEV_EN_MSI BIT(11)
> > +#define SCU_PCIE_CONF_BMC_DEV_EN_IRQ BIT(13)
> > +#define SCU_PCIE_CONF_BMC_DEV_EN_DMA BIT(14)
> > +#define SCU_PCIE_CONF_BMC_DEV_EN_E2L BIT(15)
> > +#define SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE BIT(21)
> > +
> > +#define ASPEED_SCU_BMC_DEV_CLASS 0xC68
> > +
> > +
> > +struct aspeed_platform {
> > + int (*init)(struct platform_device *pdev);
> > +};
> > +
> > +struct aspeed_bmc_device {
> > + struct device *dev;
> > + int id;
> > + void __iomem *reg_base;
> > +
> > + int pcie2lpc;
> > + int irq;
> > +
> > + const struct aspeed_platform *platform;
> > +
> > + struct regmap *scu;
> > + int pcie_irq;
> > +};
> > +
> > +
> > +static int aspeed_ast2600_init(struct platform_device *pdev)
> > +{
> > + struct aspeed_bmc_device *bmc_device = platform_get_drvdata(pdev);
> > + struct device *dev = &pdev->dev;
> > + u32 pcie_config_ctl = SCU_PCIE_CONF_BMC_DEV_EN_IRQ |
> > + SCU_PCIE_CONF_BMC_DEV_EN_MMIO | SCU_PCIE_CONF_BMC_DEV_EN;
> > + u32 scu_id;
> > +
> > + bmc_device->scu = syscon_regmap_lookup_by_phandle(dev->of_node, "aspeed,scu");
>
> We should rather look at auxbus for the SCU.
>
> > + if (IS_ERR(bmc_device->scu)) {
> > + dev_err(&pdev->dev, "failed to find SCU regmap\n");
> > + return PTR_ERR(bmc_device->scu);
> > + }
> > +
> > + if (bmc_device->pcie2lpc)
> > + pcie_config_ctl |= SCU_PCIE_CONF_BMC_DEV_EN_E2L |
> > + SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE;
> > +
> > + regmap_update_bits(bmc_device->scu, ASPEED_SCU_PCIE_CONF_CTRL,
> > + pcie_config_ctl, pcie_config_ctl);
> > +
> > + /* update class code to others as it is a MFD device */
> > + regmap_write(bmc_device->scu, ASPEED_SCU_BMC_DEV_CLASS, 0xff000000);
> > +
> > +#ifdef SCU_TRIGGER_MSI
>
> I don't see that this needs to be a CPP test. This could be a C test.
> The construct would be optimised because of the constant and we'd get
> compile time coverage of both sides without additional configuration.
>
> Have you tested both sides?
>
> > + //SCUC24[17]: Enable PCI device 1 INTx/MSI from SCU560[15]. Will be added in next version
> > + regmap_update_bits(bmc_device->scu, ASPEED_SCUC20, BIT(11) | BIT(14), BIT(11) | BIT(14));
>
> These bits need descriptive macros.
>
> > +
> > + regmap_read(bmc_device->scu, ASPEED_SCU04, &scu_id);
> > + if (scu_id == AST2600A3_SCU04)
> > + regmap_update_bits(bmc_device->scu, ASPEED_SCUC24,
> > + PCIDEV1_INTX_MSI_HOST2BMC_EN | MSI_ROUTING_MASK,
> > + PCIDEV1_INTX_MSI_HOST2BMC_EN | MSI_ROUTING_PCIe2LPC_PCIDEV1);
> > + else
> > + regmap_update_bits(bmc_device->scu, ASPEED_SCUC24,
> > + BIT(17) | BIT(14) | BIT(11), BIT(17) | BIT(14) | BIT(11));
>
> As do these
>
> > +#else
> > + //SCUC24[18]: Enable PCI device 1 INTx/MSI from Host-to-BMC controller.
> > + regmap_update_bits(bmc_device->scu, 0xc24, BIT(18) | BIT(14), BIT(18) | BIT(14));
>
> And these.
>
> > +#endif
> > +
> > +
> > + return 0;
> > +}
> > +
> > +
> > +static struct aspeed_platform ast2600_plaform = {
> > + .init = aspeed_ast2600_init
> > +};
> > +
> > +
> > +static const struct of_device_id aspeed_bmc_device_of_matches[] = {
> > + { .compatible = "aspeed,ast2600-bmc-device", .data = &ast2600_plaform },
>
> This compatible isn't documented in this series and isn't present in
> linux-next at a87737435cfa ("Add linux-next specific files for
> 20260608"). You'll need to address that if it's reasonable to continue
> down this path. I expect you'll want to avoid it, and define any
> necessary properties on the SCU node rather than add further children.
>
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, aspeed_bmc_device_of_matches);
> > +
> > +static int aspeed_bmc_device_probe(struct platform_device *pdev)
> > +{
> > + struct aspeed_bmc_device *bmc_device;
> > + struct device *dev = &pdev->dev;
>
> This shortcut is defined but inconsistently used.
>
> > + const void *md = of_device_get_match_data(dev);
>
> I think we can do without this, see below.
>
> > + int ret = 0;
> > +
> > + if (!md)
> > + return -ENODEV;
> > +
> > + bmc_device = devm_kzalloc(&pdev->dev, sizeof(struct aspeed_bmc_device), GFP_KERNEL);
> > + if (!bmc_device)
> > + return -ENOMEM;
> > + dev_set_drvdata(dev, bmc_device);
> > +
> > + bmc_device->platform = md;
> > +
> > + bmc_device->id = of_alias_get_id(dev->of_node, "bmcdev");
> > + if (bmc_device->id < 0)
> > + bmc_device->id = 0;
> > +
> > + bmc_device->dev = dev;
> > + bmc_device->reg_base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(bmc_device->reg_base))
> > + return PTR_ERR(bmc_device->reg_base);
> > +
> > + bmc_device->irq = platform_get_irq(pdev, 0);
>
> This seems unnecessary.
>
> > + if (bmc_device->irq < 0) {
> > + dev_err(&pdev->dev, "platform get of irq[=%d] failed!\n", bmc_device->irq);
> > + return bmc_device->irq;
> > + }
> > +
> > + if (of_property_read_bool(dev->of_node, "pcie2lpc"))
>
> This property isn't documented.
>
> > + bmc_device->pcie2lpc = 1;
> > +
> > + ret = bmc_device->platform->init(pdev);
>
> The driver only supports one SoC, this indirection seems unnecessary
> right now. We can add that later when there's a need to differentiate.
> I'd rather you call the setup function directly for now.
>
> > + if (ret) {
> > + dev_err(dev, "Initialize bmc device failed\n");
> > + goto out;
> > + }
> > +
> > + dev_info(dev, "aspeed bmc device: driver successfully loaded.\n");
> > +
> > + return 0;
> > +
> > +out:
> > + dev_warn(dev, "aspeed bmc device: driver init failed (ret=%d)!\n", ret);
> > + return ret;
> > +}
> > +
> > +static void aspeed_bmc_device_remove(struct platform_device *pdev)
> > +{
> > + struct aspeed_bmc_device *bmc_device = platform_get_drvdata(pdev);
> > +
> > + devm_free_irq(&pdev->dev, bmc_device->irq, bmc_device);
> > + devm_kfree(&pdev->dev, bmc_device);
>
> These are unnecessary due to cleanup of devres on release.
>
> Andrew
^ permalink raw reply
* Re: [PATCH v2 2/2] soc: aspeed: add host-side PCIe BMC device driver
From: Grégoire Layet @ 2026-06-11 8:41 UTC (permalink / raw)
To: Andrew Jeffery
Cc: joel, andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel
In-Reply-To: <66df26f7ec827a0f48cd44c454bfd36968ca4dd0.camel@codeconstruct.com.au>
Hello Andrew,
> Again, I'd rather we avoid drivers/soc/aspeed.
If creating a new specific driver is the right move, where should it go if
not in drivers/soc/aspeed ?
But again, considering all you remarks, maybe this driver is unnecessary.
As initially the driver was doing all the PCI BMC device functionality
provided by ASPEED (shared memory, VUART, message queue and doorbell),
it made sense to have everything in a driver for this specific case.
However for a TTY-only driver, that might be excessive.
When I trimmed down the driver, I didn't consider whether the driver itself
was still necessary.
I think adding a new driver is not the right solution for this.
From my research, the ASPEED PCIe device could be added to the 8250_pci driver.
The ASPEED PCIe device has a specific device ID and Vendor ID.
What do you think about this?
Thanks,
Grégoire
On Wed, 10 Jun 2026 at 14:51, Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> On Mon, 2026-06-08 at 14:51 +0000, Grégoire Layet wrote:
> > Taken from ASPEED 6.18 Kernel SDK
> >
> > Add support for VUART over PCIe between BMC and host.
> > This add host side driver.
> >
> > Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
> > Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
> > Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> > Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
> > ---
> > drivers/soc/aspeed/Kconfig | 8 +
> > drivers/soc/aspeed/Makefile | 1 +
> > drivers/soc/aspeed/aspeed-host-bmc-dev.c | 249 +++++++++++++++++++++++
>
> Again, I'd rather we avoid drivers/soc/aspeed.
>
> > 3 files changed, 258 insertions(+)
> > create mode 100644 drivers/soc/aspeed/aspeed-host-bmc-dev.c
> >
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > index 3e1fcf3c3268..5deefb64e8c7 100644
> > --- a/drivers/soc/aspeed/Kconfig
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -11,6 +11,14 @@ config ASPEED_BMC_DEV
> > Enable support for the ASPEED AST2600 BMC Device.
> > This exposes the PCIe-to-LPC bridge of the BMC to the host over PCIe.
> >
> > +config ASPEED_HOST_BMC_DEV
> > + tristate "ASPEED Host BMC Device"
> > + depends on PCI
> > + depends on SERIAL_8250
> > + help
> > + Enable support for the ASPEED AST2600 BMC Device on the Host.
> > + This configure the PCIe and setup two 8250 compatible VUART ports.
> > +
> > config ASPEED_LPC_CTRL
> > tristate "ASPEED LPC firmware cycle control"
> > select REGMAP
> > diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
> > index fab0d247df66..3fd3f6d8d36e 100644
> > --- a/drivers/soc/aspeed/Makefile
> > +++ b/drivers/soc/aspeed/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_ASPEED_BMC_DEV) += aspeed-bmc-dev.o
> > +obj-$(CONFIG_ASPEED_HOST_BMC_DEV) += aspeed-host-bmc-dev.o
> > obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > obj-$(CONFIG_ASPEED_UART_ROUTING) += aspeed-uart-routing.o
> > diff --git a/drivers/soc/aspeed/aspeed-host-bmc-dev.c b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
> > new file mode 100644
> > index 000000000000..7cb52a770fb6
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
> > @@ -0,0 +1,249 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +// Copyright (C) ASPEED Technology Inc.
> > +
> > +#include <linux/init.h>
> > +#include <linux/version.h>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/errno.h>
> > +#include <linux/pci.h>
> > +#include <linux/serial_core.h>
> > +#include <linux/serial_8250.h>
> > +
> > +static DEFINE_IDA(bmc_device_ida);
> > +
> > +#define VUART_MAX_PARMS 2
>
> Given the one supported piece of hardware we could avoid the associated
> loops and rather extract loop bodies to functions and call the function
> twice.
>
> > +#define MAX_MSI_NUM 8
> > +#define BMC_MULTI_MSI 32
> > +
> > +#define DRIVER_NAME "aspeed-host-bmc-dev"
> > +
> > +enum aspeed_platform_id {
> > + ASPEED,
> > +};
> > +
> > +enum msi_index {
> > + VUART0_MSI,
> > + VUART1_MSI,
> > +};
> > +
> > +/* Match msi_index */
> > +static int ast2600_msi_idx_table[MAX_MSI_NUM] = { 16, 15 };
> > +
> > +struct aspeed_platform {
> > + int (*setup)(struct pci_dev *pdev);
> > +};
> > +
> > +struct aspeed_pci_bmc_dev {
> > + struct device *dev;
> > + struct aspeed_platform *platform;
> > + kernel_ulong_t driver_data;
> > + int id;
> > +
> > + unsigned long message_bar_base;
> > + unsigned long message_bar_size;
> > + void __iomem *msg_bar_reg;
> > +
> > + struct uart_8250_port uart[VUART_MAX_PARMS];
> > + int uart_line[VUART_MAX_PARMS];
> > +
> > + /* Interrupt
> > + * The index of array is using to enum msi_index
> > + */
> > + int *msi_idx_table;
> > +};
> > +
> > +static void aspeed_pci_setup_irq_resource(struct pci_dev *pdev)
> > +{
> > + struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
> > +
> > + /* Assign static msi index table by platform */
> > + pci_bmc_dev->msi_idx_table = ast2600_msi_idx_table;
> > +
> > + if (pci_alloc_irq_vectors(pdev, 1, BMC_MULTI_MSI, PCI_IRQ_INTX | PCI_IRQ_MSI) <= 1)
> > + /* Set all msi index to the first vector */
> > + memset(pci_bmc_dev->msi_idx_table, 0, sizeof(int) * MAX_MSI_NUM);
> > +}
> > +
> > +static int aspeed_pci_bmc_device_setup_vuart(struct pci_dev *pdev)
> > +{
> > + struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
> > + struct device *dev = &pdev->dev;
> > + u16 vuart_ioport;
> > + int ret, i;
> > +
> > + for (i = 0; i < VUART_MAX_PARMS; i++) {
> > + /* Assign the line to non-exist device */
> > + pci_bmc_dev->uart_line[i] = -ENOENT;
> > + vuart_ioport = 0x3F8 - (i * 0x100);
> > + pci_bmc_dev->uart[i].port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ;
> > + pci_bmc_dev->uart[i].port.uartclk = 115200 * 16;
> > + pci_bmc_dev->uart[i].port.irq =
> > + pci_irq_vector(pdev, pci_bmc_dev->msi_idx_table[VUART0_MSI + i]);
> > + pci_bmc_dev->uart[i].port.dev = dev;
> > + pci_bmc_dev->uart[i].port.iotype = UPIO_MEM32;
> > + pci_bmc_dev->uart[i].port.iobase = 0;
> > + pci_bmc_dev->uart[i].port.mapbase =
> > + pci_bmc_dev->message_bar_base + (vuart_ioport << 2);
> > + pci_bmc_dev->uart[i].port.membase = 0;
> > + pci_bmc_dev->uart[i].port.type = PORT_16550A;
> > + pci_bmc_dev->uart[i].port.flags |= (UPF_IOREMAP | UPF_FIXED_PORT | UPF_FIXED_TYPE);
> > + pci_bmc_dev->uart[i].port.regshift = 2;
> > + ret = serial8250_register_8250_port(&pci_bmc_dev->uart[i]);
> > + if (ret < 0) {
> > + dev_err_probe(dev, ret, "Can't setup PCIe VUART\n");
> > + return ret;
> > + }
> > + pci_bmc_dev->uart_line[i] = ret;
> > + }
> > + return 0;
> > +}
> > +
> > +static void aspeed_pci_host_bmc_device_release_vuart(struct pci_dev *pdev)
> > +{
> > + struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
> > + int i;
> > +
> > + for (i = 0; i < VUART_MAX_PARMS; i++) {
> > + if (pci_bmc_dev->uart_line[i] >= 0)
> > + serial8250_unregister_port(pci_bmc_dev->uart_line[i]);
> > + }
> > +}
> > +
> > +static int aspeed_pci_host_setup(struct pci_dev *pdev)
> > +{
> > + struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
> > + int rc = 0;
> > +
> > + /* Get Message BAR */
> > + pci_bmc_dev->message_bar_base = pci_resource_start(pdev, 1);
> > + pci_bmc_dev->message_bar_size = pci_resource_len(pdev, 1);
> > + pci_bmc_dev->msg_bar_reg = pci_ioremap_bar(pdev, 1);
> > + if (!pci_bmc_dev->msg_bar_reg)
> > + return -ENOMEM;
> > +
> > + if (pdev->revision < 0x27) {
> > + /* AST2600 ERRTA40: dummy read */
>
> Can you please rather document what problem this is actually solving.
>
> > + (void)__raw_readl((void __iomem *)pci_bmc_dev->msg_bar_reg);
> > + } else {
> > + /* AST2700 not supported */
> > + pr_err("AST2700 detected but not supported");
>
> This logs an error but rc = 0 on return. Perhaps drop the log message
> and return an appropriate error code?
>
> > + goto out_free0;
> > + }
> > +
> > + rc = aspeed_pci_bmc_device_setup_vuart(pdev);
> > + if (rc) {
> > + pr_err("Cannot setup Virtual UART");
> > + goto out_free0;
> > + }
> > +
> > + return 0;
> > +
> > +out_free0:
> > + pci_iounmap(pdev, pci_bmc_dev->msg_bar_reg);
> > +
> > + return rc;
> > +}
> > +
> > +static struct aspeed_platform aspeed_pcie_host[] = {
> > + { .setup = aspeed_pci_host_setup },
> > + { 0 }
> > +};
> > +
> > +static int aspeed_pci_host_bmc_device_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> > +{
> > + struct aspeed_pci_bmc_dev *pci_bmc_dev;
> > + int rc = 0;
> > +
> > + pr_info("ASPEED BMC PCI ID %04x:%04x, IRQ=%u\n", pdev->vendor, pdev->device, pdev->irq);
>
> I think we could do without this.
>
> > +
> > + pci_bmc_dev = devm_kzalloc(&pdev->dev, sizeof(*pci_bmc_dev), GFP_KERNEL);
> > + if (!pci_bmc_dev)
> > + return -ENOMEM;
> > +
> > + /* Get platform id */
> > + pci_bmc_dev->driver_data = ent->driver_data;
> > + pci_bmc_dev->platform = &aspeed_pcie_host[ent->driver_data];
> > +
> > + pci_bmc_dev->id = ida_alloc(&bmc_device_ida, GFP_KERNEL);
>
> This seems unnecessary.
>
> > + if (pci_bmc_dev->id < 0)
> > + return pci_bmc_dev->id;
> > +
> > + rc = pci_enable_device(pdev);
> > + if (rc) {
> > + dev_err(&pdev->dev, "pci_enable_device() returned error %d\n", rc);
> > + return rc;
> > + }
> > +
> > + pci_set_master(pdev);
> > + pci_set_drvdata(pdev, pci_bmc_dev);
> > +
> > + /* Prepare IRQ resource */
> > + aspeed_pci_setup_irq_resource(pdev);
> > +
> > + /* Setup BMC PCI device */
> > + rc = pci_bmc_dev->platform->setup(pdev);
>
> As with patch 1 this indirection seems unnecessary.
>
> > + if (rc) {
> > + dev_err(&pdev->dev, "ASPEED PCIe Host device returned error %d\n", rc);
> > + pci_free_irq_vectors(pdev);
> > + pci_disable_device(pdev);
> > + return rc;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void aspeed_pci_host_bmc_device_remove(struct pci_dev *pdev)
> > +{
> > + struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
> > +
> > + if (pci_bmc_dev->driver_data == ASPEED)
>
> This condition seems unnecessary as the value shouldn't be anything
> else.
>
> > + aspeed_pci_host_bmc_device_release_vuart(pdev);
> > +
> > + ida_free(&bmc_device_ida, pci_bmc_dev->id);
> > +
> > + pci_iounmap(pdev, pci_bmc_dev->msg_bar_reg);
> > +
> > + pci_free_irq_vectors(pdev);
> > + pci_disable_device(pdev);
> > +}
> > +
> > +/**
> > + * This table holds the list of (VendorID,DeviceID) supported by this driver
> > + *
> > + */
>
> I think that's self-evident and prefer the comment be removed.
>
> > +static struct pci_device_id aspeed_host_bmc_dev_pci_ids[] = {
> > + /* ASPEED BMC Device */
> > + { PCI_DEVICE(0x1A03, 0x2402), .class = 0xFF0000, .class_mask = 0xFFFF00,
> > + .driver_data = ASPEED },
> > + {
> > + 0,
> > + }
> > +};
> > +
> > +MODULE_DEVICE_TABLE(pci, aspeed_host_bmc_dev_pci_ids);
> > +
> > +static struct pci_driver aspeed_host_bmc_dev_driver = {
> > + .name = DRIVER_NAME,
> > + .id_table = aspeed_host_bmc_dev_pci_ids,
> > + .probe = aspeed_pci_host_bmc_device_probe,
> > + .remove = aspeed_pci_host_bmc_device_remove,
> > +};
> > +
> > +static int __init aspeed_host_bmc_device_init(void)
> > +{
> > + return pci_register_driver(&aspeed_host_bmc_dev_driver);
> > +}
> > +
> > +static void aspeed_host_bmc_device_exit(void)
> > +{
> > + /* unregister pci driver */
> > + pci_unregister_driver(&aspeed_host_bmc_dev_driver);
> > +}
> > +
> > +late_initcall(aspeed_host_bmc_device_init);
> > +module_exit(aspeed_host_bmc_device_exit);
>
> module_driver() could be used here.
>
> > +
> > +MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
> > +MODULE_DESCRIPTION("ASPEED Host BMC DEVICE Driver");
> > +MODULE_LICENSE("GPL");
^ permalink raw reply
* RE: [PATCH v32 0/5] Add ASPEED AST2600 I2C controller driver
From: Ryan Chen @ 2026-06-11 8:42 UTC (permalink / raw)
To: Ryan Chen, jk@codeconstruct.com.au,
andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, william@wkennington.com,
wsa+renesas@sang-engineering.com
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, Conor Dooley
In-Reply-To: <20260611-upstream_i2c-v32-0-b66eba921d01@aspeedtech.com>
Hello Andi, Wolfram,
Sorry to bother you, can this i2c patch series can be review?
Ryan
> Subject: [PATCH v32 0/5] Add ASPEED AST2600 I2C controller driver
>
> This series adds support for the AST2600 I2C controller “new register set”
> implementation.
>
> The AST2600 I2C controller introduces a revised register layout which
> separates controller and target functionality into distinct register blocks, and
> extends clock divider configuration and packet-based transfer support
> compared to the legacy mixed register layout used on earlier ASPEED SoCs.
>
> The current driver implementation for the AST2600 I2C peripheral is through
> the hardware's "compatibility mode", which exposes a register set that
> matches the previous generation hardware (AST2500 and earlier).
>
> Instead, add a driver that works in new-register-set mode, to allow the new
> features, and will provide support for future hardware that will not implement
> compatibility mode.
>
> In order to support the new mode, we need a DT binding change to reflect the
> reference to the global register set. Since the binding still represents the same
> (AST2600 SoC) physical hardware, we continue to use the existing compatible
> string of "aspeed,ast2600-i2c-bus".
>
> However: since we're changing semantics for an existing binding, we allow
> backwards compatibility by selecting on presence/absence of the newly-added
> properties, and fall back to the old driver (ie., in compatibility mode) when we
> detect a DT using the old binding spec.
>
> Specifically:
>
> - ast2600-i2c-bus nodes that provide the `aspeed,global-regs` property
> (present in the new binding and absent in the legacy binding) will be
> successfully probed by the new driver
>
> - ast2600-i2c-bus nodes without `aspeed,global-regs` continue to use the
> existing driver (in legacy register mode), ensuring that platforms
> with the current DTBs remain functional
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v32:
> - 1/5: add MAINTAINERS entry for aspeed,ast2600-i2c.yaml in the same
> patch that creates the file.
> - 3/5: add if/then conditional schema: when aspeed,global-regs is
> present, require reg to have at least two items. The new driver
> unconditionally maps resource index 1 (the buffer SRAM region); a DT
> with one reg entry and aspeed,global-regs passes schema validation but
> fails probe. The constraint makes the schema consistent with driver
> behaviour.
> - 4/5: address follow-on code review issues:
> - add MAINTAINERS entry for drivers/i2c/busses/i2c-ast2600.c.
> - fix interrupt storm when msgs is NULL: clear PKT_DONE in the IRQ
> handler; per the datasheet this auto-clears all associated status
> bits.
> - fix out-of-bounds: guard msgs_index against msgs_count before
> indexing msgs array in ast2600_i2c_controller_packet_irq().
> - fix use-after-free: WRITE_ONCE() null msgs before complete() in
> all IRQ completion paths so trailing IRQs bail out immediately.
> - fix race in timeout path: null msgs before re-enabling IER so a
> late IRQ cannot access the caller's freed message buffer.
> - fix 0-length SMBus block read hanging the bus: issue STOP via
> CONTROLLER_TRIGGER_LAST_STOP, set stop_pending, poll for
> NORMAL_STOP.
> - initialise clk_div_reg to I2CCG_DIV_CTRL and global_ctrl to 0
> to avoid uninitialized values if regmap_read() fails.
> - guard against clock-frequency = <0> in DT; default to 100 kHz
> to prevent divide-by-zero in ast2600_i2c_ac_timing_config().
> - remove AST2600_I2CM_BUS_RECOVER_FAIL from IER writes; bit 15 is
> Reserved in I2CM10 (IER) and only exists as a status bit in I2CM14.
> - 5/5: address follow-on code review issues:
> - fix target RX data loss in master-abort path: remove BUFF_CTRL
> zeroing that discarded pending target RX data stored in bits [29:24].
> - fix use-after-free in master-abort path: null msgs and re-enable
> IER before complete(), not after, preventing stale IRQ from touching
> the newly-installed msgs of the next transfer.
> - fix shared-buffer corruption on coalesced STOP+SLAVE_MATCH IRQ:
> restore the SLAVE_PENDING guard on target_active = false.
> SLAVE_PENDING
> (bit 29) is set when a new address-match is queued before the previous
> DMA receive completes; clearing target_active in that case allows the
> controller to overwrite the shared Tx/Rx buffer.
> - use READ_ONCE() for all process-context reads of target_active;
> the IRQ path writes it with WRITE_ONCE() and plain loads allow the
> compiler to cache a stale value across the IER-disable window.
> - Link to v31:
> https://lore.kernel.org/r/20260603-upstream_i2c-v31-0-ba7a02714f22@aspee
> dtech.com
> Changes in v31:
> - 1/5: clarify in the commit message that the second reg region is
> optional (minItems: 1), matching the schema change from v30.
> - 2/5: zero-initialise struct i2c_timings so the bus-frequency fallback
> correctly triggers when clock-frequency is absent in the DT.
> - 4/5: fix zero-length RX: ast2600_i2c_setup_buff_rx() now returns
> -EINVAL for xfer_len <= 0, propagated through the controller packet
> IRQ handler to abort the transfer instead of hanging until SW timeout.
> - 4/5: address follow-on code review issues:
> - Guard controller_packet_irq() against NULL msgs (post-timeout UAF).
> - Clamp HW-reported xfer_len via ast2600_i2c_clamp_len() in TX_ACK
> and RX_DONE to prevent out-of-bounds writes on HW length glitches.
> - Use regmap_update_bits() for I2CG_CTRL to avoid clobbering shared
> global bits across parallel bus probes (TOCTOU fix).
> - Fix SMBus block read with recv_len == 0: set controller_xfer_cnt =
> msg->len to satisfy the "msg done" check without an extra 1-byte RX.
> - Mirror the controller timeout sequence in recover_bus() timeout path
> (disable IER, synchronize_irq(), W1C ISR, reset master, restore IER).
> - Remove unused #include <linux/of_device.h>.
> - Remove dead adap.algo_data assignment in probe().
> - 5/5: address follow-on target-mode code review issues:
> - Clear target_active on any STOP (not just STOP without SLAVE_PENDING),
> fixing a deadlock under coalesced IRQ events.
> - Enable target IER in reg_target() rather than unconditionally in
> probe(), matching the disable in unreg_target().
> - Re-arm HW in SLAVE_PENDING|RX_DONE|WAIT_TX_DMA|STOP ISR case
> (missing CMD_STS write left bus SCL-stretched until INACTIVE_TO).
> - Default target ISR case: write TARGET_TRIGGER_CMD instead of
> silently breaking, preventing bus hang on unhandled states.
> - W1C-clear ADDR1/2/3_NAK bits in HW in target_irq() to prevent
> stale NAK bits from bouncing controller transfers with -EBUSY.
> - unreg_target(): write 0 to ADDR_CTRL instead of masking with
> ADDR1_MASK, which left ADDR1_ENABLE (BIT(7)) set after unregister.
> - Link to v30:
> https://lore.kernel.org/r/20260528-upstream_i2c-v30-0-5d4f9adc3530@aspee
> dtech.com
>
> Changes in v30:
> - 1/5: aspeed,ast2600-i2c.yaml: keep backward compatibility for
> existing in-tree AST2600 device trees (Sashiko AI review).
> - reg: add minItems: 1 so legacy single-reg DTs still validate.
> - retain bus-frequency as a deprecated property so DTs that still
> use it are not rejected by unevaluatedProperties: false.
> - 2/5: new patch "i2c: aspeed: Read clock-frequency via
> i2c_parse_fw_timings()". The legacy i2c-aspeed driver now reads
> the standard clock-frequency property first and falls back to
> bus-frequency, avoiding a silent 100 kHz downgrade when a DT
> follows the updated binding but still binds to the legacy
> driver (Sashiko AI review).
> - 4/5: address Sashiko AI code review feedback:
> - Use manual i2c_add_adapter() / i2c_del_adapter() instead of
> devm_i2c_add_adapter() so the adapter is torn down before the
> hardware is disabled in remove(); otherwise client .remove()
> callbacks can fail or hang after FUN_CTRL/IER have been cleared.
> - synchronize_irq() and clear pending IRQ status on the controller
> timeout path to avoid the ISR racing with the next transfer and
> touching freed msgs.
> - Use clamp_t() for AC TIMING divisor / scl_low / scl_high so
> extreme clock-frequency values cannot underflow into the unsigned
> domain and corrupt the AC TIMING register.
> - Derive the RX buffer offset from buf_size instead of hardcoding
> 0x10, since the dual-pool split is configurable.
> - Clamp i2c-scl-clk-low-timeout-us to the TTIMEOUT field's 5-bit
> range (max 31 * 1024us) and emit a dev_warn() instead of letting
> AST2600_I2CC_TTIMEOUT()'s mask silently truncate larger values.
> - Return -EBUSY (not -ENOMEM) for every ast2600_i2c_do_start()
> failure path in the controller packet IRQ handler (NORMAL_STOP,
> TX_ACK, and RX_DONE branches).
> - Advertise I2C_AQ_NO_ZERO_LEN_READ via i2c_adapter_quirks so the
> i2c-core rejects zero-byte reads before they reach the driver.
> The AST2600 packet engine cannot encode a zero-length RX command
> and would otherwise stall waiting for an RX_DONE that never
> arrives.
> - 5/5: address Sashiko AI code review feedback:
> - Force-stop path (target IRQ aborting an in-flight controller
> transfer): disable the controller IER and W1C-clear pending ISR
> before calling complete(), then restore the IER after the
> wake-up. Without the disable/clear sequence the controller IRQ
> handler can race with the target abort path and double-complete
> or touch freed msgs.
> - unreg_target() teardown ordering: disable the target IER first,
> then disable SLAVE_EN / clear ADDR_CTRL, synchronize_irq(), W1C
> pending ISR, and only then NULL i2c_bus->target and clear
> target_active. The old order left IER enabled while target was
> being cleared, allowing an in-flight handler to dereference a
> target pointer the caller had already freed.
> - reg_target() bring-up ordering: assign i2c_bus->target before
> enabling SLAVE_EN. Otherwise an IRQ that fires after SLAVE_EN
> is set but before the pointer is stored finds target == NULL,
> exits without clearing the ISR, and the unmasked event re-fires
> as an IRQ storm.
> - Use writel() instead of writeb() when staging a TX byte into
> the target buffer. The AST2600 buffer SRAM only supports 32-bit
> accesses; byte writes are silently dropped (or, on some
> revisions, raise a bus fault), so a SLAVE_READ_REQUESTED reply
> never reaches the master.
> - reg_target() rejects 10-bit client addresses with
> -EAFNOSUPPORT. AST2600_I2CS_ADDR1 is only a 7-bit field;
> without the check, the high bits of a 10-bit address overflow
> into the adjacent ADDR2 field and silently corrupt a second
> target slot.
> - Initialise the local `u8 value` to 0 in the target packet IRQ
> handler. Its address is passed to i2c_slave_event() for events
> such as I2C_SLAVE_STOP / I2C_SLAVE_READ_REQUESTED; a slave
> backend that reads the byte before writing would otherwise leak
> uninitialised kernel stack.
> - Link to v29:
> https://lore.kernel.org/r/20260415-upstream_i2c-v29-0-317c1a905ae1@aspee
> dtech.com
>
> Changes in v29:
> - 2/4: remove aspeed,enable-dma properties.
> - 3/4: update commit message remove transfer mode selection.
> - 3/4: remove sysfs file.
> - 3/4: remove define I2C_TARGET_MSG_BUF_SIZE and
> AST2600_I2C_DMA_SIZE.
> - 3/4: remove buf_index in struct ast2600_i2c_bus.
> - 3/4, 4/4: remove dma/byte mode, use buffer mode only.
> - 4/4: fix race between unreg_target and IRQ handler.
> - 4/4: move i2cs ier enable from ast2600_i2c_init to probe after master ier
> enable.
> - Link to v28:
> https://lore.kernel.org/r/20260330-upstream_i2c-v28-0-17bdae39c5cb@aspee
> dtech.com
>
> Changes in v28:
> - 2/4: update commit message correspond with aspeed,enable-dma.
> - 2/4: remove aspeed,transfer-mode and add aspeed,enable-dma property
> and description.
> - 2/4: Fix aspeed,enable-dma description to reflect hardware capability
> rather than software behavior.
> - 3/4: Separate xfer_mode_store into distinct parse and availability-check
> steps by introducing ast2600_i2c_xfer_mode_check().
> - 3/4: fix tx dma memcpy source point address.
> - 3/4: Use a temporary variable for
> devm_platform_get_and_ioremap_resource()
> to avoid storing an ERR_PTR in i2c_bus->buf_base; drop the redundant
> NULL assignment in the error path since i2c_bus is kzalloc()ed.
> - 3/4: Add ABI documentation file
> Documentation/ABI/testing/sysfs-driver-ast2600-i2c.
> - 4/4: fix typo condication -> condition.
> - 4/4: fix compile error, when disable CONFIG_I2C_SLAVE.
> - Link to v27:
> https://lore.kernel.org/r/20260324-upstream_i2c-v27-0-f19b511c8c28@aspee
> dtech.com
>
> Changes in v27:
> - 1/4 use aspeed,enable-dma instead aspeed,transfer-mode.
> - 2/4 remove aspeed,transfer-mode selection instad aspeed,transfer-mode
> - 2/4 add sysfs for xfer mode.
> - Link to v26:
> https://lore.kernel.org/r/20260309-upstream_i2c-v26-0-5fedcff8ffe8@aspeedt
> ech.com
>
> Changes in v26:
> - 1/4: binding reworks based on review feedback
> - Link to v25:
> https://lore.kernel.org/r/20260225-upstream_i2c-v25-0-9f4bdd954f3f@aspeed
> tech.com
>
> Changes in v25:
> - Use b4 to send series.
> - Rebase on v7.0-rc1.
> - Clarify cover letter and commit logs based on review feedback.
> - Remove the i2c-aspeed-core multiplexer infrastructure and
> implement driver selection via conditional -ENODEV handling
> in individual probe() functions.
> - 3/4: incorporate review feedback and refactor new driver
> - Link to v24:
> https://lore.kernel.org/r/20251118014034.820988-1-ryan_chen@aspeedtech.c
> om
>
> Changes in v24:
> - aspeed,ast2600-i2c.yaml
> - fix make dt_binding_check blank warning.
> - Link to v23:
> https://lore.kernel.org/all/20251117025040.3622984-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v23:
> - update typo patch (1/4) commit message.
> - aspeed,ast2600-i2c.yaml
> - update reg and description.
> - i2c-ast2600.c controller
> - replace ast2600_select_i2c_clock to ast2600_i2c_ac_timing_config.
> - i2c-ast2600.c target
> - I2C_TARGET_MSG_BUF_SIZE 256 to 4096
> - remove blank line.
> - refine Master comment description to controller
> - Link to v22:
> https://lore.kernel.org/all/20251112085649.1903631-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v22:
> - update patch (1/4) commit message add dts example reason.
> - aspeed,ast2600-i2c.yaml @patch (1/4)
> - rename ast2600-i2c.yaml to aspeed,ast2600-i2c.yaml.
> - update reg, clock-frequency description.
> - aspeed,ast2600-i2c.yaml @patch (2/4)
> - aspeed,transfer-mode, aspeed,transfer-mode add for ast2600.
> - i2c-aspeed-core.c,h @patch (3/4)
> - add i2c-aspeed-core allow both old and new device trees using the
> same compatible string "aspeed,ast2600-i2c-bus".
> - Link to v21:
> https://lore.kernel.org/all/20251027061240.3427875-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v21:
> - update patch (1/4) commit message
> - i2c-ast2600.c
> - move rst to local variable in ast2600_i2c_probe().
> - Link to v20:
> https://lore.kernel.org/all/20251021013548.2375190-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v20:
> - ast2600-i2c.yaml
> - fix warning at make dt_binding_check.
> - Link to v19:
> https://lore.kernel.org/all/20251020013200.1858325-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v19:
> - Split AST2600 binding into its own YAML file
> - Removed `aspeed,ast2600-i2c-bus` from `aspeed,i2c.yaml`
> - Added `aspeed,global-regs` and `aspeed,transfer-mode` to AST2600 binding
> - Link to v18:
> https://lore.kernel.org/all/20250820051832.3605405-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v18:
> - refine patch (1/3) commit message (reason for commit not list.)
> - i2c-ast2600.c
> - remove redundant reset_control_deassert in driver probe.
> - remove reset_control_assert(i2c_bus->rst) in driver remove.
> - Link to v17:
> https://lore.kernel.org/all/20250814084156.1650432-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v17:
> - move i2c new mode register and feature into driver commit message.
> - aspeed,i2c.yaml
> - remove multi-master properties.
> - use aspeed,transfer-mode properties for aspeed,enable-byte/enable-dma.
> -i2c-ast2600.c
> - rename dma_safe_buf to controller_dma_safe_buf.
> - fix ast2600_i2c_recover_bus return overflow warnings.
> - add ast2600_i2c_target_packet_buff_irq unhandle case.
> - add parameter "cmd" in ast2600_i2c_setup_dma_rx,
> ast2600_i2c_setup_buff_rx, ast2600_i2c_setup_byte_rx
> - use reset_control_deassert replace
> devm_reset_control_get_shared_deasserted.
> - useaspeed,transfer-mode properties for transfer mode setting.
> - change compatible = "aspeed,ast2600-i2cv2" to "aspeed,ast2600-i2c-bus".
> - Link to v16:
> https://lore.kernel.org/all/20250224055936.1804279-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v16:
> - aspeed,i2c.yaml: add aspeed,enable-byte properties for force byte mode.
> - i2c-ast2600.c
> - change include asm/unaligned.h to linux/unaligned.h.
> - add reset timeout councter when slave active timeout.
> - modify issue i2c_recovery_bus before slave re-enable.
> - add aspeed,enable-byte properties.
> - Link to v15:
> https://lore.kernel.org/all/20241007035235.2254138-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v15:
> - i2c-ast2600.c
> - add include unaligned.h
> - rename all master -> controller, slave -> target.
> - keep multi-master to align property.
> - remove no used element in ast2600_i2c_bus.
> - Link to v14:
> https://lore.kernel.org/all/20241002070213.1165263-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v14:
> - aspeed,i2c.yaml
> - v13 change people reviewed-by tag, v14 fixed to original people tag,
> modify to Reviewed-by: Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org>
> - struct ast2600_i2c_bus layout optimal.
> - ast2600_select_i2c_clock refine.
> - ast2600_i2c_recover_bus overridden fix.
> - dma_mapping_error() returned error code shadowed modify.
> - buffer register in a 4-byte aligned simplified
> - remove smbus alert
> - Link to v13:
> https://lore.kernel.org/all/20240819092850.1590758-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v13:
> - separate i2c master and slave driver to be two patchs.
> - modify include header list, add bits.h include. remove of*.h
> - modify (((x) >> 24) & GENMASK(5, 0)) to (((x) & GENMASK(29, 24)) >> 24)
> - modify ast2600_select_i2c_clock function implement.
> - modify ast2600_i2c_recover_bus function u32 claim to
> u32 state = readl(i2c_bus->reg_base + AST2600_I2CC_STS_AND_BUFF);
> - Link to v12:
> https://lore.kernel.org/all/20230714074522.23827-1-ryan_chen@aspeedtech.c
> om/
>
> Changes in v12:
> - aspeed,i2c.yaml
> - add Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> - i2c-ast2600.c
> - update include by alphabetical order
> - make just a one TAB and put the last two lines on the single one
> - remove no used timing_table structre
> - remove enum explicit assinment
> - rewritten to avoid this and using loop in ast2600_select_i2c_clock
> - use GENMASK for most 0xffff
> - remove too many parentheses
> - use str_read_write replace read write string
> - remove redundant blank line after ast2600_i2c_bus_of_table
> - fix wrong multi-line style of the comment
> - use macro for i2c standard speeds
> - remove useless noise dev_info
> - Link to v11:
> https://lore.kernel.org/all/20230430041712.3247998-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v11:
> - aspeed,i2c.yaml
> - no change, the same with v10.
> - i2c-ast2600.c
> - modify alert_enable from int -> boolean.
> - modify dbg string recovery -> recover.
> - remove no need to init 0.
> - remove new line after break.
> - remove unneeded empty line.
> - modify dma_alloc_coherent to dmam_alloc_coherent
> - modify probe nomem return dev_err_probe
> - modify i2c_add_adapter to devm_i2c_adapter
> - modify checkpatch: Alignment should match open parenthesis
> - modify checkpatch: braces {} should be used on all arms of this statement
> - modify checkpatch: Unbalanced braces around else statement
> - Link to v10:
> https://lore.kernel.org/all/20230415012848.1777768-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v10:
> - aspeed,i2c.yaml
> - move unevaluatedProperties after allOf.
> - remove extra one blank line.
> - i2c-ast2600.c
> - no change, the same with v8.
> - Link to v9:
> https://lore.kernel.org/all/20230405022825.333246-1-ryan_chen@aspeedtech.
> com/
>
> Changes in v9:
> - aspeed,i2c.yaml
> - backoff to v7.
> - no fix typo in maintainer's name and email. this would be another patch.
> - no remove address-cells, size-cells, this would be another patch.
> - use aspeed,enable-dma property instead of aspeed,xfer-mode selection.
> - fix allOf and else false properties for aspeed,ast2600-i2cv2.
> - i2c-ast2600.c
> - no change, the same with v8
> - Link to v8:
> https://lore.kernel.org/all/20230330073259.485606-1-ryan_chen@aspeedtech.
> com/
>
> Changes in v8:
> - aspeed,i2c.yaml
> - modify commit message.
> - Fix typo in maintainer's name and email.
> - remove address-cells, size-cells.
> - i2c-ast2600.c
> - move "i2c timeout counter" comment description before property_read.
> - remove redundant code "return ret" in probe end.
> - Link to v7:
> https://lore.kernel.org/all/20230327092524.3916389-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v7:
> - aspeed,i2c.yaml
> - Update ASPEED I2C maintainers email.
> - use aspeed,enable-dma property instead of aspeed,xfer-mode selection.
> - fix allOf and else false properties for aspeed,ast2600-i2cv2.
> - i2c-ast2600.c
> - remove aspeed,xfer-mode instead of aspeed,enable-dma mode. buffer
> mode
> is default.
> - remove aspeed,timeout instead of i2c-scl-clk-low-timeout-us for
> timeout setting.
> - Link to v6:
> https://lore.kernel.org/all/20230226031321.3126756-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v6:
> - remove aspeed,i2cv2.yaml, merge to aspeed,i2c.yaml -add support for
> i2cv2 properites.
> - i2c-ast2600.c
> - fix ast2600_i2c_remove ordering.
> - remove ast2600_i2c_probe goto labels, and add dev_err_probe -remove
> redundant deb_dbg debug message.
> - rename gr_regmap -> global_regs
> - Link to v5:
> https://lore.kernel.org/all/20230220061745.1973981-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v5:
> - remove ast2600-i2c-global.yaml, i2c-ast2600-global.c.
> - i2c-ast2600.c
> - remove legacy clock divide, all go for new clock divide.
> - remove duplicated read isr.
> - remove no used driver match
> - fix probe return for each labels return.
> - global use mfd driver, driver use phandle to regmap read/write.
> - rename aspeed,i2c-ast2600.yaml to aspeed,i2cv2.yaml -remove
> bus-frequency.
> - add required aspeed,gr
> - add timeout, byte-mode, buff-mode properites.
> - Link to v4:
> https://lore.kernel.org/all/20230201103359.1742140-1-ryan_chen@aspeedtec
> h.com/
>
> Changes in v4:
> - fix i2c-ast2600.c driver buffer mode use single buffer conflit in
> master slave mode both enable.
> - fix kmemleak issue when use dma mode.
> - fix typo aspeed,i2c-ast2600.yaml compatible is "aspeed,ast2600-i2c"
> - fix typo aspeed,i2c-ast2600.ymal to aspeed,i2c-ast2600.yaml
> - Link to v3:
> https://lore.kernel.org/all/20220516064900.30517-1-ryan_chen@aspeedtech.c
> om/
>
> Changes in v3:
> - fix i2c global clock divide default value.
> - remove i2c slave no used dev_dbg info.
> - Link to v2:
> https://lore.kernel.org/all/20220413101735.27678-1-ryan_chen@aspeedtech.c
> om/
>
> Changes in v2:
> - add i2c global ymal file commit.
> - rename file name from new to ast2600.
> aspeed-i2c-new-global.c -> i2c-ast2600-global.c
> aspeed-i2c-new-global.h -> i2c-ast2600-global.h
> i2c-new-aspeed.c -> i2c-ast2600.c
> - rename all driver function name to ast2600.
> - Link to v1:
> https://lore.kernel.org/all/20220323004009.943298-1-ryan_chen@aspeedtech.
> com/
>
> ---
> Ryan Chen (5):
> dt-bindings: i2c: Split AST2600 binding into a new YAML
> i2c: aspeed: Read clock-frequency via i2c_parse_fw_timings()
> dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs properties
> i2c: ast2600: Add controller driver for AST2600 new register set
> i2c: ast2600: Add target mode support
>
> .../bindings/i2c/aspeed,ast2600-i2c.yaml | 88 ++
> .../devicetree/bindings/i2c/aspeed,i2c.yaml | 3 +-
> MAINTAINERS | 2 +
> drivers/i2c/busses/Makefile | 2 +-
> drivers/i2c/busses/i2c-aspeed.c | 24 +-
> drivers/i2c/busses/i2c-ast2600.c | 1290
> ++++++++++++++++++++
> 6 files changed, 1400 insertions(+), 9 deletions(-)
> ---
> base-commit: a293ec25d59dd96309058c70df5a4dd0f889a1e4
> change-id: 20260223-upstream_i2c-ebd07f89739c
>
> Best regards,
> --
> Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* [PATCH v2 0/2] iommu/arm-smmu-v3: Fix Tegra241 CMDQV CMD_SYNC use-after-free
From: Shameer Kolothum @ 2026-06-11 8:42 UTC (permalink / raw)
To: iommu, linux-kernel, linux-arm-kernel
Cc: nicolinc, jgg, joro, will, robin.murphy, nathanc, mochs,
skolothumtho
Hi,
The arm-smmu-v3 probe teardown mixes devm and manual cleanup, so resources
unwind in the wrong order. The IOPF queue is freed before the event-queue
IRQ whose handler uses it. On Tegra241 this is worse: devres frees
smmu->cmdq.q.base before arm_smmu_impl_remove() runs, and the CMDQV
teardown then issues a CMD_SYNC on the freed queue, a use-after-free.
Patch 1 moves the remaining manual teardown (IOPF queue, vmid_map, device
disable) onto devm so the unwind order is correct. Patch 2 adds a
device_disable() impl op and uses it to quiesce the Tegra241 VINTFs
while the CMDQ is still up, fixing the UAF.
v1 is here:
https://lore.kernel.org/linux-iommu/20260529091052.317102-1-skolothumtho@nvidia.com/
Please take a look and let me know.
Thanks,
Shameer
Shameer Kolothum (2):
iommu/arm-smmu-v3: Manage teardown with devm
iommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardown
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 54 +++++++++++++------
.../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 15 +++++-
3 files changed, 52 insertions(+), 18 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] iommu/arm-smmu-v3: Manage teardown with devm
From: Shameer Kolothum @ 2026-06-11 8:42 UTC (permalink / raw)
To: iommu, linux-kernel, linux-arm-kernel
Cc: nicolinc, jgg, joro, will, robin.murphy, nathanc, mochs,
skolothumtho
In-Reply-To: <20260611084205.686559-1-skolothumtho@nvidia.com>
arm_smmu_device_remove() manually frees the IOPF queue, destroys the
vmid_map and disables the device, while the IRQs and queues are devm
managed. devm unwinds only after remove() returns, so the cleanup runs
in the wrong order. The IOPF queue is freed before the event-queue IRQ
whose handler uses it.
Manage all of it with devm so the unwind order is correct. Free the IOPF
queue and vmid_map via devm actions, and disable the device from one
registered after arm_smmu_device_reset().
This is also a prerequisite for fixing a Tegra241 CMDQV CMD_SYNC
use-after-free in the subsequent patch.
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 ++++++++++++++-------
1 file changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e8d7dbe495f0..00261e77e7bc 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4464,6 +4464,16 @@ int arm_smmu_cmdq_init(struct arm_smmu_device *smmu,
return 0;
}
+static void arm_smmu_free_iopf_action(void *data)
+{
+ iopf_queue_free(data);
+}
+
+static void arm_smmu_destroy_vmid_map(void *data)
+{
+ ida_destroy(data);
+}
+
static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
{
int ret;
@@ -4491,6 +4501,11 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
smmu->evtq.iopf = iopf_queue_alloc(dev_name(smmu->dev));
if (!smmu->evtq.iopf)
return -ENOMEM;
+ ret = devm_add_action_or_reset(smmu->dev,
+ arm_smmu_free_iopf_action,
+ smmu->evtq.iopf);
+ if (ret)
+ return ret;
}
/* priq */
@@ -4569,7 +4584,8 @@ static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
ida_init(&smmu->vmid_map);
- return 0;
+ return devm_add_action_or_reset(smmu->dev, arm_smmu_destroy_vmid_map,
+ &smmu->vmid_map);
}
static int arm_smmu_init_structures(struct arm_smmu_device *smmu)
@@ -4782,6 +4798,11 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
return ret;
}
+static void arm_smmu_disable_action(void *data)
+{
+ arm_smmu_device_disable(data);
+}
+
static void arm_smmu_write_strtab(struct arm_smmu_device *smmu)
{
struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
@@ -5540,7 +5561,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
/* Initialise in-memory data structures */
ret = arm_smmu_init_structures(smmu);
if (ret)
- goto err_free_iopf;
+ return ret;
/* Record our private device structure */
platform_set_drvdata(pdev, smmu);
@@ -5550,30 +5571,30 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
/* Reset the device */
ret = arm_smmu_device_reset(smmu);
+ if (ret) {
+ arm_smmu_device_disable(smmu);
+ return ret;
+ }
+
+ /* Register last so it unwinds first, while the CMDQ is still up. */
+ ret = devm_add_action_or_reset(smmu->dev, arm_smmu_disable_action, smmu);
if (ret)
- goto err_disable;
+ return ret;
/* And we're up. Go go go! */
ret = iommu_device_sysfs_add(&smmu->iommu, dev, NULL,
"smmu3.%pa", &ioaddr);
if (ret)
- goto err_disable;
+ return ret;
ret = iommu_device_register(&smmu->iommu, &arm_smmu_ops, dev);
if (ret) {
dev_err(dev, "Failed to register iommu\n");
- goto err_free_sysfs;
+ iommu_device_sysfs_remove(&smmu->iommu);
+ return ret;
}
return 0;
-
-err_free_sysfs:
- iommu_device_sysfs_remove(&smmu->iommu);
-err_disable:
- arm_smmu_device_disable(smmu);
-err_free_iopf:
- iopf_queue_free(smmu->evtq.iopf);
- return ret;
}
static void arm_smmu_device_remove(struct platform_device *pdev)
@@ -5582,9 +5603,6 @@ static void arm_smmu_device_remove(struct platform_device *pdev)
iommu_device_unregister(&smmu->iommu);
iommu_device_sysfs_remove(&smmu->iommu);
- arm_smmu_device_disable(smmu);
- iopf_queue_free(smmu->evtq.iopf);
- ida_destroy(&smmu->vmid_map);
}
static void arm_smmu_device_shutdown(struct platform_device *pdev)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] iommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardown
From: Shameer Kolothum @ 2026-06-11 8:42 UTC (permalink / raw)
To: iommu, linux-kernel, linux-arm-kernel
Cc: nicolinc, jgg, joro, will, robin.murphy, nathanc, mochs,
skolothumtho
In-Reply-To: <20260611084205.686559-1-skolothumtho@nvidia.com>
arm_smmu_impl_remove() is registered as a devres action in
arm_smmu_impl_probe(), before arm_smmu_init_queues() allocates
smmu->cmdq.q.base. On a devres unwind, whether a failed probe or an
unbind, the queue is freed first and arm_smmu_impl_remove() then runs
tegra241_cmdqv_remove_vintf(), whose VINTF deinit issues a CMD_SYNC on
the freed memory.
Observed during testing with a QEMU hack that makes the VCMDQ fail to
enable, so the impl reset fails and probe aborts into the devres unwind:
platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: failed to enable, STATUS=0x00000000
platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: GERRORN=0x0, GERROR=0x4, CONS=0x0
platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: uncleared error detected, resetting
arm-smmu-v3 arm-smmu-v3.0.auto: failed to reset impl
arm-smmu-v3 arm-smmu-v3.0.auto: probe with driver arm-smmu-v3 failed with error -110
Unable to handle kernel paging request at virtual address ffff8000891e0098
...
Internal error: Oops: 0000000096000047 [#1] SMP
...
Call trace:
arm_smmu_cmdq_issue_cmdlist+0x320/0x6fc (P)
tegra241_vcmdq_hw_deinit+0x98/0x168
tegra241_vintf_hw_deinit+0x5c/0x1b0
tegra241_cmdqv_remove_vintf+0x34/0xec
tegra241_cmdqv_remove+0x40/0x9c
arm_smmu_impl_remove+0x20/0x30
devm_action_release+0x14/0x20
devres_release_all+0xa8/0x110
device_unbind_cleanup+0x18/0x84
really_probe+0x1f0/0x29c
Drop the VINTF deinit from tegra241_cmdqv_remove_vintf() so the unwind no
longer touches the freed queue. Quiesce the VINTFs earlier instead. Add a
device_disable() impl op and run it from arm_smmu_disable_action() while
the CMDQ is still up. That handles a live unbind. A failed reset is already
handled because tegra241_vintf_hw_init() deinits the VINTF on its own error
path. tegra241_cmdqv_remove_vintf() is also used by the iommufd viommu
destroy path, so quiesce there too.
Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support")
Cc: stable@vger.kernel.org
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +++++-
drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 15 +++++++++++++--
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index ef42df4753ec..690055aa63c7 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -804,6 +804,7 @@ struct arm_smmu_strtab_cfg {
struct arm_smmu_impl_ops {
int (*device_reset)(struct arm_smmu_device *smmu);
+ void (*device_disable)(struct arm_smmu_device *smmu);
void (*device_remove)(struct arm_smmu_device *smmu);
int (*init_structures)(struct arm_smmu_device *smmu);
struct arm_smmu_cmdq *(*get_secondary_cmdq)(
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 00261e77e7bc..3d531af7e16c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4800,7 +4800,11 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
static void arm_smmu_disable_action(void *data)
{
- arm_smmu_device_disable(data);
+ struct arm_smmu_device *smmu = data;
+
+ if (smmu->impl_ops && smmu->impl_ops->device_disable)
+ smmu->impl_ops->device_disable(smmu);
+ arm_smmu_device_disable(smmu);
}
static void arm_smmu_write_strtab(struct arm_smmu_device *smmu)
diff --git a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
index 83f6e9f6c51d..c7af7658a4ea 100644
--- a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
+++ b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
@@ -761,8 +761,6 @@ static void tegra241_cmdqv_remove_vintf(struct tegra241_cmdqv *cmdqv, u16 idx)
struct tegra241_vintf *vintf = cmdqv->vintfs[idx];
u16 lidx;
- tegra241_vintf_hw_deinit(vintf);
-
/* Remove LVCMDQ resources */
for (lidx = 0; lidx < vintf->cmdqv->num_lvcmdqs_per_vintf; lidx++)
if (vintf->lvcmdqs[lidx])
@@ -779,6 +777,17 @@ static void tegra241_cmdqv_remove_vintf(struct tegra241_cmdqv *cmdqv, u16 idx)
}
}
+static void tegra241_cmdqv_hw_disable(struct arm_smmu_device *smmu)
+{
+ struct tegra241_cmdqv *cmdqv =
+ container_of(smmu, struct tegra241_cmdqv, smmu);
+ u16 idx;
+
+ for (idx = 0; idx < cmdqv->num_vintfs; idx++)
+ if (cmdqv->vintfs[idx])
+ tegra241_vintf_hw_deinit(cmdqv->vintfs[idx]);
+}
+
static void tegra241_cmdqv_remove(struct arm_smmu_device *smmu)
{
struct tegra241_cmdqv *cmdqv =
@@ -844,6 +853,7 @@ static struct arm_smmu_impl_ops tegra241_cmdqv_impl_ops = {
/* For in-kernel use */
.get_secondary_cmdq = tegra241_cmdqv_get_cmdq,
.device_reset = tegra241_cmdqv_hw_reset,
+ .device_disable = tegra241_cmdqv_hw_disable,
.device_remove = tegra241_cmdqv_remove,
/* For user-space use */
.hw_info = tegra241_cmdqv_hw_info,
@@ -1152,6 +1162,7 @@ static void tegra241_cmdqv_destroy_vintf_user(struct iommufd_viommu *viommu)
if (vintf->mmap_offset)
iommufd_viommu_destroy_mmap(&vintf->vsmmu.core,
vintf->mmap_offset);
+ tegra241_vintf_hw_deinit(vintf);
tegra241_cmdqv_remove_vintf(vintf->cmdqv, vintf->idx);
}
--
2.43.0
^ permalink raw reply related
* Re: (subset) [PATCH v4 1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
From: Lee Jones @ 2026-06-11 8:46 UTC (permalink / raw)
To: lee, ukleinek, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, linusw, Manish Baing
Cc: linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, Conor Dooley
In-Reply-To: <20260523173251.72540-2-manishbaing2789@gmail.com>
On Sat, 23 May 2026 17:32:50 +0000, Manish Baing wrote:
> The st,stmpe-pwm binding is already covered by the MFD schema in
> Documentation/devicetree/bindings/mfd/st,stmpe.yaml. However, the
> PWM subnode was missing a 'required' properties block. This allowed
> Device Tree nodes to pass validation even if the 'compatible'
> string was omitted. This omission could lead to probe failures
> at runtime.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
commit: b07f7904e0523170856876e4412be852377d492a
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler
From: Sebastian Ene @ 2026-06-11 8:47 UTC (permalink / raw)
To: Vincent Donnefort
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <aikmBBHEUfolXrHC@google.com>
On Wed, Jun 10, 2026 at 09:53:24AM +0100, Vincent Donnefort wrote:
> On Mon, Jun 08, 2026 at 04:55:44PM +0000, Sebastian Ene wrote:
> > Allow FF-A notification bitmap destruction messages to be forwarded to
> > Trustzone from the host.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index c20d45191085..91e89d889c44 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -688,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
> > case FFA_MEM_DONATE:
> > case FFA_MEM_RETRIEVE_REQ:
> > /* Optional notification interfaces added in FF-A 1.1 */
> > - case FFA_NOTIFICATION_BITMAP_DESTROY:
> > case FFA_NOTIFICATION_BIND:
> > case FFA_NOTIFICATION_UNBIND:
> > case FFA_NOTIFICATION_SET:
> > @@ -893,6 +892,26 @@ static void do_ffa_notif_bitmap_create(struct arm_smccc_1_2_regs *res,
> > arm_smccc_1_2_smc(args, res);
> > }
> >
> > +static void do_ffa_notif_bitmap_destroy(struct arm_smccc_1_2_regs *res,
> > + struct kvm_cpu_context *ctxt)
> > +{
> > + DECLARE_REG(u32, vmid, ctxt, 1);
> > + struct arm_smccc_1_2_regs *args;
> > +
> > + if (ffa_check_unused_args_sbz(ctxt, 2)) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + if (vmid != HOST_FFA_ID) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + args = (void *)&ctxt->regs.regs[0];
> > + arm_smccc_1_2_smc(args, res);
> > +}
Hello Vincent,
>
> Sounds exactly like do_ffa_notif_bitmap_create. Could we use a single one
> "do_ffa_notif_bitmap" ?
>
Yes, I guess we can have only one method since the only difference
between them is in the number of unused args.
> > +
> > bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > {
> > struct arm_smccc_1_2_regs res;
> > @@ -954,6 +973,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > case FFA_NOTIFICATION_BITMAP_CREATE:
> > do_ffa_notif_bitmap_create(&res, host_ctxt);
> > goto out_handled;
> > + case FFA_NOTIFICATION_BITMAP_DESTROY:
> > + do_ffa_notif_bitmap_destroy(&res, host_ctxt);
> > + goto out_handled;
> > }
> >
> > if (ffa_call_supported(func_id))
> > --
> > 2.54.0.1064.gd145956f57-goog
> >
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH 0/2] clocksource/drivers/arm_arch_timer_mmio: Restore support for early init
From: Stephan Gerhold @ 2026-06-11 8:47 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, Daniel Lezcano, Thomas Gleixner, Sudeep Holla,
linux-arm-kernel, linux-kernel, linux-arm-msm, Jack Matthews
In-Reply-To: <87se6t8q3s.wl-maz@kernel.org>
On Thu, Jun 11, 2026 at 08:59:19AM +0100, Marc Zyngier wrote:
> On Wed, 10 Jun 2026 18:53:09 +0100,
> Stephan Gerhold <stephan.gerhold@linaro.org> wrote:
> >
> > Jack reported a regression for some single-core Qualcomm platforms (e.g.
> > MDM9625, MDM9607) that no longer boot because no timers can be found during
> > early boot [1].
>
> Again, this is *not* a regression. These machines were *never*
> supported upstream.
>
Sorry, I'll reword this next time. MDM9607 does have all required
drivers and compatibles upstream already and is just missing the actual
DT so it does feel somewhat supported to me, but I'm fine treating this
as a feature extension without stable backporting etc.
> > These platforms rely on an obscure timer setup where the
> > global Arm MMIO timer (arm,armv7-timer-mem) is used as the only available
> > timer for the CPU. This setup used to work fine until commit 0f67b56d84b4
> > ("clocksource/drivers/arm_arch_timer_mmio: Switch over to standalone
> > driver") when the early timer initialization using TIMER_OF_DECLARE() was
> > removed when moving to the standalone MMIO driver.
> >
> > There doesn't seem to be any other usable CPU timer on those platforms, so
> > this series restores the early timer support using TIMER_OF_DECLARE()
> > inside the new standalone arm_arch_timer_mmio driver. This is pretty ugly,
> > but I could not think of a better solution so far. I tried to keep the
> > ugliness for the two probe paths as limited as possible. :-)
> >
> > If someone has a better idea how to solve this, I would be happy to try it.
>
> I would suggest finding out what is the latest point in the init
> sequence where the timer can be probed without preventing boot.
>
It doesn't get far without having any timer:
[ 0.000000] timer_probe: no matching timers found
[ 0.000000] entering initcall level: console
[ 0.000000] calling con_init+0x0/0x354 @ 0
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] initcall con_init+0x0/0x354 returned 0 after 0 usecs
[ 0.000000] sched_clock: 32 bits at 300 Hz, resolution 3333333ns, wraps every 7158278824300949ns
[ 0.000000] Calibrating delay loop...
<board hangs>
If you look at start_kernel() in init/main.c it's basically time_init()
that would normally probe the TIMER_OF_DECLARE() timers and
calibrate_delay() that needs some timer to finish. There is also
random_init() that comes directly after time_init(), which already wants
to have access to timestamp counters. I don't see any other suitable
place to hook into. :-/
I also don't see any other timer we could use, at least for MDM9625.
It's a single-core Cortex-A5 and the downstream kernel defines only the
arm,armv7-timer-mem, which seems to be used for everything... (The
situation for MDM9607 is a bit different, but not any less messy,
unfortunately.)
Thanks,
Stephan
^ permalink raw reply
* Re: [PATCH 0/2] HiSilicon TRNG fix and simplification
From: Herbert Xu @ 2026-06-11 8:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Olivia Mackall, Weili Qian, Wei Xu, Longfang Liu,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260530202624.20768-1-ebiggers@kernel.org>
On Sat, May 30, 2026 at 01:26:22PM -0700, Eric Biggers wrote:
> This series fixes and greatly simplifies the HiSilicon TRNG driver by
> removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> Note that this mirrors similar changes in other drivers such as qcom-rng
> (https://lore.kernel.org/r/20260530020332.143058-1-ebiggers@kernel.org)
>
> Eric Biggers (2):
> crypto: hisi-trng - Remove crypto_rng interface
> hwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> drivers/char/hw_random/Kconfig | 10 +
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/hisi-trng-v2.c | 98 +++++++
> drivers/crypto/hisilicon/Kconfig | 8 -
> drivers/crypto/hisilicon/Makefile | 1 -
> drivers/crypto/hisilicon/trng/Makefile | 2 -
> drivers/crypto/hisilicon/trng/trng.c | 390 -------------------------
> 9 files changed, 111 insertions(+), 403 deletions(-)
> create mode 100644 drivers/char/hw_random/hisi-trng-v2.c
> delete mode 100644 drivers/crypto/hisilicon/trng/Makefile
> delete mode 100644 drivers/crypto/hisilicon/trng/trng.c
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] Xilinx TRNG fix and simplification
From: Herbert Xu @ 2026-06-11 8:49 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Mounika Botcha, Harsh Jain,
Olivia Mackall, Michal Simek, linux-arm-kernel
In-Reply-To: <20260531191738.55843-1-ebiggers@kernel.org>
On Sun, May 31, 2026 at 12:17:34PM -0700, Eric Biggers wrote:
> This series fixes and greatly simplifies the Xilinx TRNG driver by:
>
> - Removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> - Replacing the really complicated AES based entropy extraction
> algorithm with a much simpler one.
>
> Note that this mirrors similar changes in other drivers.
>
> Eric Biggers (4):
> crypto: xilinx-trng - Remove crypto_rng interface
> crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()
> crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512
> hwrng: xilinx - Move xilinx-rng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> crypto/Kconfig | 5 -
> crypto/Makefile | 2 -
> crypto/df_sp80090a.c | 222 ------------------
> drivers/char/hw_random/Kconfig | 11 +
> drivers/char/hw_random/Makefile | 1 +
> .../xilinx => char/hw_random}/xilinx-trng.c | 134 ++---------
> drivers/crypto/Kconfig | 13 -
> drivers/crypto/xilinx/Makefile | 1 -
> include/crypto/df_sp80090a.h | 53 -----
> 11 files changed, 37 insertions(+), 409 deletions(-)
> delete mode 100644 crypto/df_sp80090a.c
> rename drivers/{crypto/xilinx => char/hw_random}/xilinx-trng.c (75%)
> delete mode 100644 include/crypto/df_sp80090a.h
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: sun4i-ss - Remove insecure and unused rng_alg
From: Herbert Xu @ 2026-06-11 8:50 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-sunxi, linux-arm-kernel, linux-kernel,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Corentin Labbe,
stable, Tianchu Chen
In-Reply-To: <20260601160757.79645-1-ebiggers@kernel.org>
On Mon, Jun 01, 2026 at 04:07:57PM +0000, Eric Biggers wrote:
> Remove sun4i_ss_rng, as it is insecure and unused:
>
> - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing
> locking and has a buffer overflow. sun4i_ss_prng_generate() fails to
> fill the entire buffer with cryptographic random bytes, because it
> rounds the destination length down and also doesn't actually wait for
> the hardware to be ready before pulling bytes from it.
>
> - No user of this code is known. It's usable only theoretically via the
> "rng" algorithm type of AF_ALG. But userspace actually just uses the
> actual Linux RNG (/dev/random etc) instead. And rng_algs don't
> contribute entropy to the actual Linux RNG either. (This may have
> been confused with hwrng, which does contribute entropy.)
>
> The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen
> and discovered by Atuin - Automated Vulnerability Discovery Engine
>
> There's no point in fixing all these vulnerabilities individually when
> this is unused code, so let's just remove it.
>
> Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG")
> Cc: stable@vger.kernel.org
> Reported-by: Tianchu Chen <flynnnchen@tencent.com>
> Closes: https://lore.kernel.org/r/af749a8447bd7f0e9dd26ca6c87e9c6afecb09d9@linux.dev/
> Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is targeting crypto/master
>
> v2: rebased onto crypto/master, and added Acked-by and Reported-by
>
> arch/arm/configs/sunxi_defconfig | 1 -
> drivers/crypto/allwinner/Kconfig | 8 ---
> drivers/crypto/allwinner/sun4i-ss/Makefile | 1 -
> .../crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 36 ----------
> .../crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 69 -------------------
> drivers/crypto/allwinner/sun4i-ss/sun4i-ss.h | 20 ------
> 6 files changed, 135 deletions(-)
> delete mode 100644 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Marek Szyprowski @ 2026-06-11 8:26 UTC (permalink / raw)
To: Viacheslav Bocharov, Linus Walleij, Bartosz Golaszewski
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Robin Murphy, Diederik de Haas, linux-gpio, linux-arm-kernel,
linux-amlogic, linux-kernel, linux-rockchip, Heiko Stuebner
In-Reply-To: <20260610153329.937833-1-v@baodeep.com>
Hi Viachesla,
On 10.06.2026 17:32, Viacheslav Bocharov wrote:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> This was reported on Khadas VIM3 and worked around for Amlogic by
> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
> sleeping"), which marked the whole meson controller sleeping. That
> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
> no longer detects devices, because its IRQ-disabled read slot calls the
> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>
> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>
> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
> gating on gpiod_cansleep() change behaviour. No current device needs
> atomic (non-cansleep) value access on a shared GPIO -- every report
> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
> which is what the proxy exists to vote on. An alternative that keeps
> atomic value access (split locking) is possible but adds a second lock
> and new race windows. I went with the simpler, verified approach and
> would appreciate guidance on whether the atomic value path must be
> preserved.
>
> The two are a unit: patch 2 must not be applied without patch 1,
> otherwise the original VIM3 splat returns on boards that share a meson
> GPIO -- please keep the order. I have not Cc'd stable; I will request
> stable backports separately once both patches have landed.
>
> Viacheslav Bocharov (2):
> gpio: shared-proxy: always serialize with a sleeping mutex
> pinctrl: meson: restore non-sleeping GPIO access
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
This probably also affects the similar changes in Rockchip GPIO driver done
by the following commits:
20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction")
I've checked this patchset with these two reverted and no warning was reported.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH] spi: xilinx: use FIFO occupancy register to determine buffer size
From: Michal Simek @ 2026-06-11 8:52 UTC (permalink / raw)
To: lars.poeschel.linux, Mark Brown, linux-spi, linux-arm-kernel,
linux-kernel
Cc: Lars Pöschel, Mahapatra, Amit Kumar
In-Reply-To: <20260611071033.1937983-1-lars.poeschel.linux@edag.com>
+Amit,
On 6/11/26 09:10, lars.poeschel.linux@edag.com wrote:
> From: Lars Pöschel <lars.poeschel@edag.com>
>
> The method the driver uses to determine the size of the FIFO has a
> problem. What it currently does is this:
> It stops the SPI hardware and writes to the TX FIFO register until TX
> FIFO FULL asserts in the status register. But the hardware does not only
> have the FIFO, it also seems to have a shift register. This can be seen,
I don't think you should guess here
> when writing a byte to the FIFO (while the SPI hardware is stopped,) the
> TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for
> example, the current method returns a 17.
> This is a problem, at least when using the driver in irq mode. The same
> size determined for the TX FIFO is also assumed for the RX FIFO. When an
> SPI transaction wants to write the amount of the FIFO size or more
> bytes, the following happens, let's assume 16 bytes FIFO size:
s/let's/for example/
> The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and
> starts the SPI hardware and goes sleep.
> The hardware then shifts out 17 bytes (FIFO + shift register) and
> simultaneously reads bytes into the RX FIFO, but it only has 16 places,
> so it looses one byte. Then TX FIFO empty asserts, wakes the driver
> again, which has a fast path and reads 16 bytes from the RX FIFO, but
> before reading the last 17th byte (which is lost) it does this:
>
> sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
> if (!(sr & XSPI_SR_RX_EMPTY_MASK)) {
> xilinx_spi_rx(xspi);
> rx_words--;
> }
>
> It reads the status register and checks if the RX FIFO is not empty.
> But it is empty in our case. So this check spins in a while loop
> forever locking the driver.
>
> The new method for determining the FIFO size is to read the SPITFOR (TX
> FIFO occupancy register, value = occupancy - 1) after filling the TX
> FIFO to obtain the true FIFO storage depth, which also equals the RX
> FIFO depth. In non-FIFO configurations (n_words == 1) the register does
> not exist; return 1 directly in that case.
>
missing fix tag.
> Signed-off-by: Lars Pöschel <lars.poeschel@edag.com>
> ---
> drivers/spi/spi-xilinx.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
> index 9f065d4e27d1..2d31e30fc4eb 100644
> --- a/drivers/spi/spi-xilinx.c
> +++ b/drivers/spi/spi-xilinx.c
> @@ -54,6 +54,7 @@
> #define XSPI_RXD_OFFSET 0x6c /* Data Receive Register */
>
> #define XSPI_SSR_OFFSET 0x70 /* 32-bit Slave Select Register */
> +#define XSPI_TFOR_OFFSET 0x74 /* Transmit FIFO Occupancy Register */
>
> /* Register definitions as per "OPB IPIF (v3.01c) Product Specification", DS414
> * IPIF registers are 32 bit
> @@ -377,7 +378,9 @@ static int xilinx_spi_find_buffer_size(struct xilinx_spi *xspi)
> n_words++;
> } while (!(sr & XSPI_SR_TX_FULL_MASK));
>
> - return n_words;
> + if (n_words == 1)
> + return 1;
> + return xspi->read_fn(xspi->regs + XSPI_TFOR_OFFSET) + 1;
Based on pg153
Exists only when FIFO Depth is set to 16 or 256
Based on ds570
This register does not exist if C_FIFO_EXIST = 0
It means this is not going to work with all HW configurations.
Pretty much you wanted to use this register to find out how big is the fifo
but I think in this case you should be just fixing logic around +-1 caused by
n_words++ in a loop.
What about to change logic to be like this? It is clear and it is without any +1
logic and no fifo is handled separately?
while (1) {
xspi->write_fn(0, xspi->regs + XSPI_TXD_OFFSET);
sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
if (sr & XSPI_SR_TX_FULL_MASK)
break;
n_words++;
}
/* Handle NO FIFO case separately */
if (!n_words)
return 1;
return n_words;
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 19/37] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe
From: Luca Ceresoli @ 2026-06-11 8:54 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260608-mellow-weasel-of-politeness-a56172@houat>
On Mon Jun 8, 2026 at 1:58 PM CEST, Maxime Ripard wrote:
> On Tue, May 19, 2026 at 12:37:36PM +0200, Luca Ceresoli wrote:
>> This bridge driver calls drm_bridge_add() in the DSI host .attach callback
>> instead of in the probe function.
>>
>> This works for current use cases but is problematic for supporting hotplug
>> of DRM bridges. The problematic case is when this DSI host is always
>> present while its DSI device is hot-pluggable. In such case with the
>> current code the DRM card will not be populated until after the DSI device
>> attaches to the host, which could happen a very long time after booting, or
>> even not happen at all.
>>
>> The reason is that the previous pipeline component (the encoder in this
>> case) when probing cannot find the samsung-dsim bridge. What happens is:
>>
>> [1 and 2 can happen in any order, same result]
>> 1) samsung-dsim probes (does not drm_bridge_add() itself)
>> 2) The lcdif starts probing multiple times, but
>> lcdif_probe
>> -> lcdif_load
>> -> lcdif_attach_bridge
>> -> devm_drm_of_get_bridge() returns -EPROBE_DEFER because
>> the samsung-dsim is not in the global bridge_list
>> (deferred probe pending: imx-lcdif: Cannot connect bridge)
>>
>> The samsung-dsim will not drm_bridge_add() itself until a DSI device will
>> try to mipi_dsi_attach() to the DSI Host, which can happen arbitratily late
>> on hot-pluggable hardware.
>>
>> As a preliminary step to supporting hotplug move drm_bridge_add() at probe
>> time, so that the samsung-dsim DSI host bridge is available during boot,
>> even without a connected DSI device. This results in:
>>
>> 1) samsung-dsim probes (and adds to drm_bridge_add() itself)
>> 2) The lcdif starts probing multiple times, but
>> lcdif_probe
>> -> lcdif_load
>> -> lcdif_attach_bridge
>> -> devm_drm_of_get_bridge() --> OK, returns samsung-dsim ptr
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> We should probably amend
> https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
>
> To mention this use case here
Right. I haven't updated the docs for this v1 because I was not sure the
overall approach would be acked. Now Dmitry acked it overall, and I kind of
infer you are not against, so I'll look into updating the docs in v2.
However I find that section of the docs a bit hard to read especially from
a newcomer perspective.
A better understanding on my side would help in doing the right change as
far as this patch is concerned, and as a bonus in improving the section
overall (that would probably be a separate series).
So I have a couple questions to start from:
* Do I understand correctly that using the component framework is legacy,
not recommended for new DRM development, and that converting existing
code to stop using it is welcome?
* The first bullet quotes "The upstream driver [...] isn’t a MIPI-DSI
host". If the upstream driver of a MIPI DSI link isn't a MIPI DSI host,
what else could it be? What are the use cases here?
* If read literally, none of the 4 bullets after "Indeed, there’s multiple
cases that needs to be considered" covers this driver (it does not use
the component framework, it does not use DCS, and the upstream device is
a DSI host). However the 3 bullets after "The ideal pattern to cover the
last item" appear to cover what this driver does. Do we need a fifth
bullet for drivers like this one? Or...?
* To me it looks like the "bridge" word in this section is always used to
refer to the DSI device. Would it make sense to replace "bridge" ->
"[DSI ]device" in this section? (especially as the DSI host is also a
DRM bridge)
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - drop dead code in atmel_ecdh_max_size
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260602222517.1071850-3-thorsten.blum@linux.dev>
On Wed, Jun 03, 2026 at 12:25:19AM +0200, Thorsten Blum wrote:
> atmel_ecdh_init_tfm() always allocates ctx->fallback, so it is never
> NULL in atmel_ecdh_max_size(). Remove the dead code and return
> crypto_kpp_maxsize() directly.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-ecc.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 08/16] Revert "dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP"
From: Bartosz Golaszewski @ 2026-06-11 8:57 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Bartosz Golaszewski, Greg Kroah-Hartman,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
In-Reply-To: <20260610084053.2059858-9-wenst@chromium.org>
On Wed, 10 Jun 2026 10:40:42 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> This reverts commit 454a1e3cd36c113341d7b71e8e691c6e47ab4a8a.
>
> mtk-xhci handles both USB 2.0 High Speed (HS) and USB 3.x SuperSpeed
> (SS) host connections. And there are USB 2.0 only mtk-xhci blocks.
> The SSUSB controller handles the device or gadget mode. Saying that
> SSUSB handles the HS portion is wrong.
>
> Fixes: 454a1e3cd36c ("dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP")
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Maybe put it in the front of the series?
Bart
^ permalink raw reply
* [PATCH 0/5] ARM/arm64: dts: st: fix node ordering in ST board device trees
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In the ST board DTS files, &label entries must be ordered
alphanumerically.
Over time, several nodes ended up out of order as a side effect of
adding new features or refactoring existing ones.
This series restores the correct alphanumeric ordering across
all ST board DTS files, with no functional change.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
Amelie Delaunay (5):
arm64: dts: st: reorder ommanager node in stm32mp257f-ev1.dts
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp135f-dk.dts
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp15xx-dkx.dtsi
ARM: dts: stm32: reorder cs_cti_trace node in stm32mp157c-ev1.dts
ARM: dts: stm32: reorder mdma1 node in stm32mp15*-scmi.dts
arch/arm/boot/dts/st/stm32mp135f-dk.dts | 4 +-
arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 8 ++--
arch/arm/boot/dts/st/stm32mp157c-ev1.dts | 6 +--
arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi | 6 +--
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 56 +++++++++++++--------------
8 files changed, 52 insertions(+), 52 deletions(-)
---
base-commit: fba4a31a7f3b6b29b01c83180f83e7ed4c398738
change-id: 20260611-node_reordering-4b9b132b007f
Best regards,
--
Amelie Delaunay <amelie.delaunay@foss.st.com>
^ permalink raw reply
* [PATCH 2/5] ARM: dts: stm32: reorder cs_cti_trace node in stm32mp135f-dk.dts
From: Amelie Delaunay @ 2026-06-11 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
Amelie Delaunay
In-Reply-To: <20260611-node_reordering-v1-0-7e519f2cb456@foss.st.com>
In the ST board DTS files, the &label entries must be ordered
alphanumerically.
The nodes became misordered when Coresight support was added.
Move cs_cti_trace to the right place to avoid future misordering.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
arch/arm/boot/dts/st/stm32mp135f-dk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp135f-dk.dts b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
index 6022e73f58af..bc3050a9bec5 100644
--- a/arch/arm/boot/dts/st/stm32mp135f-dk.dts
+++ b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
@@ -190,11 +190,11 @@ &cryp {
status = "okay";
};
-&cs_cti_trace {
+&cs_cti_cpu0 {
status = "okay";
};
-&cs_cti_cpu0 {
+&cs_cti_trace {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox