* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Shawn Lin @ 2026-02-24 8:21 UTC (permalink / raw)
To: phasta
Cc: shawn.lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, netdev, nic_swsd, linux-arm-msm, dri-devel, linux-usb,
iommu, linux-riscv, David Airlie, Simona Vetter, linux-cxl,
linux-crypto, platform-driver-x86, linux-serial, mhi,
Andy Shevchenko, Jan Dabros, linux-i2c, Daniel Mack,
Haojian Zhuang, linux-spi, Jonathan Derrick, linux-pci,
linux-gpio, Mauro Carvalho Chehab, linux-media, linux-mmc,
Jakub Kicinski
In-Reply-To: <07fc896007d86b731cbfb3cf6bbdf4e5315d7a77.camel@mailbox.org>
在 2026/02/24 星期二 15:47, Philipp Stanner 写道:
> On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
>> 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
>>> On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
>>>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
>>>> pci device drivers which rely on the devres machinery to help cleanup the IRQ
>>>> vectors.
>>>
>>> If you can please add this API with just a few users, and then convert
>>> remaining users via the subsystem trees in the next cycle.
>>> There's no need to risk wasting maintainer time on conflicts with
>>> conversions like this.
>>
>> Thanks for the suggestion, Jakub. I have little experience with
>> cross-subsystem cleanups like this, so your suggestion is very helpful.
>
>
> When I removed the hybrid nature of pci_request_region() et al., I
> concluded that there were so few users that doing them all in one run
> was sufficient.
>
> For larger reworks, like removing pcim_iomap_table(), a slower step-by-
> step strategy is necessary for the reasons that Jakub details.
>
> It is then smart to omit an easy to port subsystem / driver for the
> ultimate patch series where one then removes the hybrid behavior from
> PCI itself, after porting the last driver.
>
> In general, as Jakub details, those step-by-step cleanups are a bit
> safer, since you can proof valid behavior early on and in case of an
> explosion they are very easy to revert.
>
Thank you, Philipp. I wish I had attended your talk at FOSDEM 2025 on
removing pcim_iomap_table earlier. This first version was perhaps a bit
too aggressive. For v2, I think the plan should start with addressing
the switchtec and vmd drivers, since both of those, along with the new
API additions, can be handled entirely within the PCI subsystem scope.
>
> P.
>
^ permalink raw reply
* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Philipp Stanner @ 2026-02-24 8:32 UTC (permalink / raw)
To: Shawn Lin, phasta
Cc: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson, Arnd Bergmann, Benjamin Tissoires,
linux-input, linux-i3c, dmaengine, netdev, nic_swsd,
linux-arm-msm, dri-devel, linux-usb, iommu, linux-riscv,
David Airlie, Simona Vetter, linux-cxl, linux-crypto,
platform-driver-x86, linux-serial, mhi, Andy Shevchenko,
Jan Dabros, linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc, Jakub Kicinski
In-Reply-To: <d601ec05-ef38-5e8e-c643-c05010717ebe@rock-chips.com>
On Tue, 2026-02-24 at 16:21 +0800, Shawn Lin wrote:
> 在 2026/02/24 星期二 15:47, Philipp Stanner 写道:
> > On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
> > > 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> > > > On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> > > > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> > > > > pci device drivers which rely on the devres machinery to help cleanup the IRQ
> > > > > vectors.
> > > >
> > > > If you can please add this API with just a few users, and then convert
> > > > remaining users via the subsystem trees in the next cycle.
> > > > There's no need to risk wasting maintainer time on conflicts with
> > > > conversions like this.
> > >
> > > Thanks for the suggestion, Jakub. I have little experience with
> > > cross-subsystem cleanups like this, so your suggestion is very helpful.
> >
> >
> > When I removed the hybrid nature of pci_request_region() et al., I
> > concluded that there were so few users that doing them all in one run
> > was sufficient.
> >
> > For larger reworks, like removing pcim_iomap_table(), a slower step-by-
> > step strategy is necessary for the reasons that Jakub details.
> >
> > It is then smart to omit an easy to port subsystem / driver for the
> > ultimate patch series where one then removes the hybrid behavior from
> > PCI itself, after porting the last driver.
> >
> > In general, as Jakub details, those step-by-step cleanups are a bit
> > safer, since you can proof valid behavior early on and in case of an
> > explosion they are very easy to revert.
> >
>
> Thank you, Philipp. I wish I had attended your talk at FOSDEM 2025 on
> removing pcim_iomap_table earlier. This first version was perhaps a bit
> too aggressive.
No worries at all, it's very cool that you pick this work up!
> For v2, I think the plan should start with addressing
> the switchtec and vmd drivers, since both of those, along with the new
> API additions, can be handled entirely within the PCI subsystem scope.
Sounds reasonable to me.
Regards
Philipp
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Andy Shevchenko @ 2026-02-24 9:12 UTC (permalink / raw)
To: phasta
Cc: Simon Richter, Shawn Lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, netdev, nic_swsd, linux-arm-msm, dri-devel, linux-usb,
iommu, linux-riscv, David Airlie, Simona Vetter, linux-cxl,
linux-crypto, platform-driver-x86, linux-serial, mhi, Jan Dabros,
linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <7ca512d133f7a3bcfe00e9b0b2af5fe5f147ad77.camel@mailbox.org>
On Tue, Feb 24, 2026 at 08:39:43AM +0100, Philipp Stanner wrote:
> On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
> > On 2/24/26 12:29 AM, Shawn Lin wrote:
> > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > while 35 other drivers correctly rely solely on the implicit cleanup.
> >
> > Would it make sense to have a function pcim_free_irq_vectors(), to allow
> > explicit freeing even if the device is otherwise managed, analogous to
> > pcim_iounmap()?
>
> We used to add those. In part because it is easier to port old users.
>
> Nowadays I tend to think that those APIs were more on the too-complex
> than too-simple side for a long time. As an expert or as the API
> designer you wouldn't expect it, but there are actually far too many
> users who came to believe they always have to use pcim_iounmap() and
> counter parts.
>
> If I could design it from scratch I would probably try to tell users to
> use the unmanaged versions instead of revoking the devres consequence.
+many.
> Devres is actually about your consequence always happening whenever the
> driver unloads, for whatever reason.
I believe you meant "unbinds". The device<-->driver link can be broken
without unloading the driver.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Bartosz Golaszewski @ 2026-02-24 10:16 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: Manivannan Sadhasivam via B4 Relay, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Hans de Goede, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Andy Shevchenko, Bartosz Golaszewski
In-Reply-To: <20260224-pci-m2-e-v5-2-dd9b9501d33c@oss.qualcomm.com>
On Tue, 24 Feb 2026 06:30:48 +0100, Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> Add of_find_serdev_controller_by_node() API to find the serdev controller
> device associated with the devicetree node.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> drivers/tty/serdev/core.c | 19 +++++++++++++++++++
> include/linux/serdev.h | 9 +++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index 8f25510f89b6..bf88b95f7458 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -514,6 +514,25 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> }
> EXPORT_SYMBOL_GPL(serdev_controller_alloc);
>
> +#ifdef CONFIG_OF
> +/**
> + * of_find_serdev_controller_by_node() - Find the serdev controller associated
> + * with the devicetree node
> + * @node: Devicetree node
> + *
> + * Return: Pointer to the serdev controller associated with the node. NULL if
> + * the controller is not found. Caller is responsible for calling
> + * serdev_controller_put() to drop the reference.
> + */
> +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> +{
> + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> +
> + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
I'm not sure if I commented on it before but there's no reason for this to be
OF-centric. It would work equally well as (I think the same should keep the
"serdev" prefix too for correct namespacing):
struct serdev_controller *serdev_find_controller_by_fwnode(struct
fwnode_handle *fwnode)
{
struct device *dev = bus_find_device_by_fwnode();
...
}
It would be more flexible and users can always use to_of_node().
Bart
> +#endif
> +
> static int of_serdev_register_devices(struct serdev_controller *ctrl)
> {
> struct device_node *node;
> diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> index 0c7d3c27d1f8..188c0ba62d50 100644
> --- a/include/linux/serdev.h
> +++ b/include/linux/serdev.h
> @@ -334,4 +334,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
> }
> #endif /* CONFIG_ACPI */
>
> +#ifdef CONFIG_OF
> +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
> +#else
> +static inline struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_OF */
> +
> #endif /*_LINUX_SERDEV_H */
>
> --
> 2.51.0
>
>
>
^ permalink raw reply
* Re: [PATCH v5 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Andy Shevchenko @ 2026-02-24 10:29 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: manivannan.sadhasivam, Manivannan Sadhasivam via B4 Relay,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski
In-Reply-To: <CAMRc=MethnZu_GrujadpBZwj4SpgdNXEnTfEikSvPkO2f9MJjg@mail.gmail.com>
On Tue, Feb 24, 2026 at 02:16:17AM -0800, Bartosz Golaszewski wrote:
> On Tue, 24 Feb 2026 06:30:48 +0100, Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> >
> > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > device associated with the devicetree node.
...
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> > +
> > + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
>
> I'm not sure if I commented on it before but there's no reason for this to be
> OF-centric. It would work equally well as (I think the same should keep the
> "serdev" prefix too for correct namespacing):
>
> struct serdev_controller *serdev_find_controller_by_fwnode(struct
> fwnode_handle *fwnode)
> {
> struct device *dev = bus_find_device_by_fwnode();
>
> ...
> }
>
> It would be more flexible and users can always use to_of_node().
IIRC it was discussed already and the fact of use only in DT overlays and
absence of the user for all this time makes it feel like solving non-existing
problem. So OF-centric in this case seems to be fine.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Philipp Stanner @ 2026-02-24 10:30 UTC (permalink / raw)
To: Andy Shevchenko, phasta
Cc: Simon Richter, Shawn Lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, netdev, nic_swsd, linux-arm-msm, dri-devel, linux-usb,
iommu, linux-riscv, David Airlie, Simona Vetter, linux-cxl,
linux-crypto, platform-driver-x86, linux-serial, mhi, Jan Dabros,
linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <aZ1rb8zoqmQmakDP@smile.fi.intel.com>
On Tue, 2026-02-24 at 11:12 +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 08:39:43AM +0100, Philipp Stanner wrote:
> > On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
> > > On 2/24/26 12:29 AM, Shawn Lin wrote:
>
> > > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > > while 35 other drivers correctly rely solely on the implicit cleanup.
> > >
> > > Would it make sense to have a function pcim_free_irq_vectors(), to allow
> > > explicit freeing even if the device is otherwise managed, analogous to
> > > pcim_iounmap()?
> >
> > We used to add those. In part because it is easier to port old users.
> >
> > Nowadays I tend to think that those APIs were more on the too-complex
> > than too-simple side for a long time. As an expert or as the API
> > designer you wouldn't expect it, but there are actually far too many
> > users who came to believe they always have to use pcim_iounmap() and
> > counter parts.
> >
> > If I could design it from scratch I would probably try to tell users to
> > use the unmanaged versions instead of revoking the devres consequence.
>
> +many.
hm?
>
> > Devres is actually about your consequence always happening whenever the
> > driver unloads, for whatever reason.
>
> I believe you meant "unbinds". The device<-->driver link can be broken
> without unloading the driver.
Yes, thx for pointing that out. Greg KH AFAIK always calls it "driver
detach".
P.
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Andy Shevchenko @ 2026-02-24 10:39 UTC (permalink / raw)
To: phasta
Cc: Simon Richter, Shawn Lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, netdev, nic_swsd, linux-arm-msm, dri-devel, linux-usb,
iommu, linux-riscv, David Airlie, Simona Vetter, linux-cxl,
linux-crypto, platform-driver-x86, linux-serial, mhi, Jan Dabros,
linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <48297cc524736e7452def05448ece84260a4fd83.camel@mailbox.org>
On Tue, Feb 24, 2026 at 11:30:28AM +0100, Philipp Stanner wrote:
> On Tue, 2026-02-24 at 11:12 +0200, Andy Shevchenko wrote:
> > On Tue, Feb 24, 2026 at 08:39:43AM +0100, Philipp Stanner wrote:
> > > On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
...
> > > If I could design it from scratch I would probably try to tell users to
> > > use the unmanaged versions instead of revoking the devres consequence.
> >
> > +many.
> hm?
I'm supporting you with many hands up (more than I possess)!
> > > Devres is actually about your consequence always happening whenever the
> > > driver unloads, for whatever reason.
> >
> > I believe you meant "unbinds". The device<-->driver link can be broken
> > without unloading the driver.
>
> Yes, thx for pointing that out. Greg KH AFAIK always calls it "driver
> detach".
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Bartosz Golaszewski @ 2026-02-24 10:54 UTC (permalink / raw)
To: Andy Shevchenko
Cc: manivannan.sadhasivam, Manivannan Sadhasivam via B4 Relay,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <aZ19kFCv_3QUkvPL@smile.fi.intel.com>
On Tue, 24 Feb 2026 11:29:36 +0100, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Tue, Feb 24, 2026 at 02:16:17AM -0800, Bartosz Golaszewski wrote:
>> On Tue, 24 Feb 2026 06:30:48 +0100, Manivannan Sadhasivam via B4 Relay
>> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
>> >
>> > Add of_find_serdev_controller_by_node() API to find the serdev controller
>> > device associated with the devicetree node.
>
> ...
>
>> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
>> > +{
>> > + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
>> > +
>> > + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
>> > +}
>> > +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
>>
>> I'm not sure if I commented on it before but there's no reason for this to be
>> OF-centric. It would work equally well as (I think the same should keep the
>> "serdev" prefix too for correct namespacing):
>>
>> struct serdev_controller *serdev_find_controller_by_fwnode(struct
>> fwnode_handle *fwnode)
>> {
>> struct device *dev = bus_find_device_by_fwnode();
>>
>> ...
>> }
>>
>> It would be more flexible and users can always use to_of_node().
>
> IIRC it was discussed already and the fact of use only in DT overlays and
> absence of the user for all this time makes it feel like solving non-existing
> problem. So OF-centric in this case seems to be fine.
>
Ok then.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4] serial: 8250: always disable IRQ during THRE test
From: Alban Bedel @ 2026-02-24 12:16 UTC (permalink / raw)
To: linux-serial
Cc: linux-kernel, Andy Shevchenko, Ilpo Järvinen, Jiri Slaby,
Greg Kroah-Hartman, Peng Zhang, stable, Muchun Song, Alban Bedel,
Maximilian Lueer
From: Peng Zhang <zhangpeng.00@bytedance.com>
commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
has been set up") moved IRQ setup before the THRE test, in combination
with commit 205d300aea75 ("serial: 8250: change lock order in
serial8250_do_startup()") the interrupt handler can run during the
test and race with its IIR reads. This can produce wrong THRE test
results and cause spurious registration of the
serial8250_backup_timeout timer. Unconditionally disable the IRQ for
the short duration of the test and re-enable it afterwards to avoid
the race.
Cc: stable@vger.kernel.org
Fixes: 039d4926379b ("serial: 8250: Toggle IER bits on only after irq has been set up")
Depends-on: 205d300aea75 ("serial: 8250: change lock order in serial8250_do_startup()")
Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
Tested-by: Maximilian Lueer <maximilian.lueer@lht.dlh.de>
---
Changelog:
v2: Replaced disable_irq_nosync() with disable_irq() to prevent interrupts
that are currently being handled
v3: Added changelog
v4: Updated commit message to mention the addtional relation to commit
205d300aea75
---
Commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq
has been set up"), in combination with 205d300aea75 ("serial: 8250:
change lock order in serial8250_do_startup()"), introduced a bug which
showed in some of our devices after updating them to kernel
5.15.169. These devices have an I2C touch screen which is behind an
UART to I2C bridge. This bug lead to an ever growing latency on the
bus, delaying the touch events by up to several seconds.
Looking for other solutions than reverting commit 039d4926379b I found
Peng Zhang's patch, backported it to 5.15 and could confirm that it
solve the high delay issue.
As this a quiet sever regression I'm taking the liberty to re-submit
Peng Zhang's patch in the hope it will be considered for inclusion. I
added the changelog requested by greg k-h's patch email bot after the
v2 submission, as well as the mention of commit 205d300aea75 requested
by Jiri Slaby after v3.
Also please note that commit 039d4926379b was backported as far back as
5.10, so quiet a few stable kernels are affected. This patch doesn't
apply as-is on older kernels, I can provide a patch for 5.15 if desired.
Alban Bedel
---
drivers/tty/serial/8250/8250_port.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index cc94af2d578a6..a743964c9d227 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2147,8 +2147,7 @@ static void serial8250_THRE_test(struct uart_port *port)
if (up->port.flags & UPF_NO_THRE_TEST)
return;
- if (port->irqflags & IRQF_SHARED)
- disable_irq_nosync(port->irq);
+ disable_irq(port->irq);
/*
* Test for UARTs that do not reassert THRE when the transmitter is idle and the interrupt
@@ -2170,8 +2169,7 @@ static void serial8250_THRE_test(struct uart_port *port)
serial_port_out(port, UART_IER, 0);
}
- if (port->irqflags & IRQF_SHARED)
- enable_irq(port->irq);
+ enable_irq(port->irq);
/*
* If the interrupt is not reasserted, or we otherwise don't trust the iir, setup a timer to
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Jonathan Cameron @ 2026-02-24 16:20 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Srujana Challa, Bharat Bhushan,
Antoine Tenart, Herbert Xu, Raag Jadav, Hans de Goede,
Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson, Arnd Bergmann, Benjamin Tissoires,
linux-input, linux-i3c, dmaengine, Philipp Stanner, netdev,
nic_swsd, linux-arm-msm, dri-devel, linux-usb, iommu, linux-riscv,
David Airlie, Simona Vetter, linux-cxl, linux-crypto,
platform-driver-x86, linux-serial, mhi, Andy Shevchenko,
Jan Dabros, linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <1771860581-82092-2-git-send-email-shawn.lin@rock-chips.com>
On Mon, 23 Feb 2026 23:29:40 +0800
Shawn Lin <shawn.lin@rock-chips.com> wrote:
> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> pci device drivers which rely on the devres machinery to help cleanup the IRQ
> vectors.
It might be worth adding some details on why we need the is_msi_managed
flag in the first place vs just doing conventional devm_add_action_or_reset()
with pci_free_irq_vectors().
^ permalink raw reply
* [PATCH 0/4] serial: amba-pl011: Add Tegra264 UART support
From: Kartik Rajput @ 2026-02-25 6:59 UTC (permalink / raw)
To: linux, gregkh, jirislaby, mingo, tglx, linmq006, arnd,
thierry.reding, jonathanh, linux-kernel, linux-serial
Cc: Kartik Rajput
This series adds support for the NVIDIA Tegra264 UART controller, which
is derived from the AMBA PL011.
On Tegra264, the fractional baud rate divisor (FBRD) register is
broken. Configuring the baud rate using IBRD and FBRD may result in the
baud rate falling outside the required tolerance. Instead, the baud
rate is derived by setting the UART clock.
The following vendor flags are introduced:
- skip_ibrd_fbrd: to skip IBRD/FBRD programming
- set_uartclk_rate: to configure the baud rate by setting the UART
clock rate
Additionally, some DMA controllers (e.g. Tegra GPCDMA) require transfer
lengths to satisfy the controller's copy_align constraint. The PL011
driver does not currently enforce this, which can result in rejected
transfers. The DMA alignment change aligns the TX DMA length down to
the required boundary, with any remaining bytes handled via the
existing PIO fallback.
Kartik Rajput (4):
serial: amba-pl011: Introduce skip_ibrd_fbrd vendor flag
serial: amba-pl011: Introduce set_uartclk_rate vendor flag
serial: amba-pl011: Add Tegra264 UART support
serial: amba-pl011: Respect DMA controller's copy_align requirement
drivers/tty/serial/amba-pl011.c | 118 +++++++++++++++++++++++++-------
1 file changed, 94 insertions(+), 24 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/4] serial: amba-pl011: Introduce skip_ibrd_fbrd vendor flag
From: Kartik Rajput @ 2026-02-25 6:59 UTC (permalink / raw)
To: linux, gregkh, jirislaby, mingo, tglx, linmq006, arnd,
thierry.reding, jonathanh, linux-kernel, linux-serial
Cc: Kartik Rajput
In-Reply-To: <20260225065915.341522-1-kkartik@nvidia.com>
The NVIDIA Tegra264 UART has a broken fractional baud rate
divisor register. Using IBRD and FBRD may cause the baud rate
to fall outside the required tolerance.
Introduce the skip_ibrd_fbrd vendor flag to skip IBRD/FBRD
programming. When set, the baud rate is derived directly from the
UART clock rate using a fixed divisor.
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
drivers/tty/serial/amba-pl011.c | 53 +++++++++++++++++++--------------
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..79e1c937a600 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -114,6 +114,7 @@ struct vendor_data {
bool cts_event_workaround;
bool always_enabled;
bool fixed_options;
+ bool skip_ibrd_fbrd;
unsigned int (*get_fifosize)(struct amba_device *dev);
};
@@ -2115,11 +2116,6 @@ pl011_set_termios(struct uart_port *port, struct ktermios *termios,
uap->dmarx.poll_rate = DIV_ROUND_UP(10000000, baud);
#endif
- if (baud > port->uartclk / 16)
- quot = DIV_ROUND_CLOSEST(port->uartclk * 8, baud);
- else
- quot = DIV_ROUND_CLOSEST(port->uartclk * 4, baud);
-
switch (termios->c_cflag & CSIZE) {
case CS5:
lcr_h = UART01x_LCRH_WLEN_5;
@@ -2190,21 +2186,28 @@ pl011_set_termios(struct uart_port *port, struct ktermios *termios,
old_cr &= ~ST_UART011_CR_OVSFACT;
}
- /*
- * Workaround for the ST Micro oversampling variants to
- * increase the bitrate slightly, by lowering the divisor,
- * to avoid delayed sampling of start bit at high speeds,
- * else we see data corruption.
- */
- if (uap->vendor->oversampling) {
- if (baud >= 3000000 && baud < 3250000 && quot > 1)
- quot -= 1;
- else if (baud > 3250000 && quot > 2)
- quot -= 2;
+ if (!uap->vendor->skip_ibrd_fbrd) {
+ if (baud > port->uartclk / 16)
+ quot = DIV_ROUND_CLOSEST(port->uartclk * 8, baud);
+ else
+ quot = DIV_ROUND_CLOSEST(port->uartclk * 4, baud);
+
+ /*
+ * Workaround for the ST Micro oversampling variants to
+ * increase the bitrate slightly, by lowering the divisor,
+ * to avoid delayed sampling of start bit at high speeds,
+ * else we see data corruption.
+ */
+ if (uap->vendor->oversampling) {
+ if (baud >= 3000000 && baud < 3250000 && quot > 1)
+ quot -= 1;
+ else if (baud > 3250000 && quot > 2)
+ quot -= 2;
+ }
+ /* Set baud rate */
+ pl011_write(quot & 0x3f, uap, REG_FBRD);
+ pl011_write(quot >> 6, uap, REG_IBRD);
}
- /* Set baud rate */
- pl011_write(quot & 0x3f, uap, REG_FBRD);
- pl011_write(quot >> 6, uap, REG_IBRD);
/*
* ----------v----------v----------v----------v-----
@@ -2374,6 +2377,7 @@ static void pl011_console_get_options(struct uart_amba_port *uap, int *baud,
int *parity, int *bits)
{
unsigned int lcr_h, ibrd, fbrd;
+ unsigned int clkdiv;
if (!(pl011_read(uap, REG_CR) & UART01x_CR_UARTEN))
return;
@@ -2393,10 +2397,15 @@ static void pl011_console_get_options(struct uart_amba_port *uap, int *baud,
else
*bits = 8;
- ibrd = pl011_read(uap, REG_IBRD);
- fbrd = pl011_read(uap, REG_FBRD);
+ if (uap->vendor->skip_ibrd_fbrd) {
+ clkdiv = 64;
+ } else {
+ ibrd = pl011_read(uap, REG_IBRD);
+ fbrd = pl011_read(uap, REG_FBRD);
+ clkdiv = 64 * ibrd + fbrd;
+ }
- *baud = uap->port.uartclk * 4 / (64 * ibrd + fbrd);
+ *baud = uap->port.uartclk * 4 / clkdiv;
if (uap->vendor->oversampling &&
(pl011_read(uap, REG_CR) & ST_UART011_CR_OVSFACT))
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] serial: amba-pl011: Introduce set_uartclk_rate vendor flag
From: Kartik Rajput @ 2026-02-25 6:59 UTC (permalink / raw)
To: linux, gregkh, jirislaby, mingo, tglx, linmq006, arnd,
thierry.reding, jonathanh, linux-kernel, linux-serial
Cc: Kartik Rajput
In-Reply-To: <20260225065915.341522-1-kkartik@nvidia.com>
The NVIDIA Tegra264 UART relies on configuring the UART clock rate
directly to program the desired baud rate.
Introduce the set_uartclk_rate vendor flag. When set, the driver
uses clk_set_rate() to program the UART clock to the desired baud
rate and clk_round_rate() to determine the maximum supported baud
rate.
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
drivers/tty/serial/amba-pl011.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 79e1c937a600..ad06dc4cdf6e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -115,6 +115,7 @@ struct vendor_data {
bool always_enabled;
bool fixed_options;
bool skip_ibrd_fbrd;
+ bool set_uartclk_rate;
unsigned int (*get_fifosize)(struct amba_device *dev);
};
@@ -2096,6 +2097,7 @@ pl011_set_termios(struct uart_port *port, struct ktermios *termios,
unsigned int lcr_h, old_cr;
unsigned long flags;
unsigned int baud, quot, clkdiv;
+ unsigned int max_baud;
unsigned int bits;
if (uap->vendor->oversampling)
@@ -2103,11 +2105,34 @@ pl011_set_termios(struct uart_port *port, struct ktermios *termios,
else
clkdiv = 16;
+ max_baud = port->uartclk / clkdiv;
+
+ if (uap->vendor->set_uartclk_rate) {
+ long max_clkrate = clk_round_rate(uap->clk, UINT_MAX);
+
+ /*
+ * Clock is reprogrammable - determine max baud from the clock's
+ * maximum rate, not the current uartclk.
+ */
+ if (max_clkrate > 0)
+ max_baud = max_clkrate / clkdiv;
+ }
+
/*
* Ask the core to calculate the divisor for us.
*/
- baud = uart_get_baud_rate(port, termios, old, 0,
- port->uartclk / clkdiv);
+ baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
+
+ if (uap->vendor->set_uartclk_rate) {
+ int err;
+
+ err = clk_set_rate(uap->clk, baud * clkdiv);
+ if (err) {
+ dev_err(port->dev, "Failed to set clock rate: %d\n", err);
+ return;
+ }
+ }
+
#ifdef CONFIG_DMA_ENGINE
/*
* Adjust RX DMA polling rate with baud rate if not specified.
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] serial: amba-pl011: Add Tegra264 UART support
From: Kartik Rajput @ 2026-02-25 6:59 UTC (permalink / raw)
To: linux, gregkh, jirislaby, mingo, tglx, linmq006, arnd,
thierry.reding, jonathanh, linux-kernel, linux-serial
Cc: Kartik Rajput
In-Reply-To: <20260225065915.341522-1-kkartik@nvidia.com>
Add support for the NVIDIA Tegra264 UART controller, which is derived
from the AMBA PL011 design.
On Tegra264, the fractional baud rate divisor (FBRD) register is broken.
Using IBRD alone may not achieve the required baud rate
tolerance. Enable the skip_ibrd_fbrd and set_uartclk_rate flags for
the NVIDIA variant.
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
drivers/tty/serial/amba-pl011.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index ad06dc4cdf6e..7f8deb30650a 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -218,6 +218,28 @@ static struct vendor_data vendor_st = {
.get_fifosize = get_fifosize_st,
};
+static unsigned int get_fifosize_nvidia(struct amba_device *dev)
+{
+ return 32;
+}
+
+static struct vendor_data vendor_nvidia = {
+ .reg_offset = pl011_std_offsets,
+ .ifls = UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+ .fr_busy = UART01x_FR_BUSY,
+ .fr_dsr = UART01x_FR_DSR,
+ .fr_cts = UART01x_FR_CTS,
+ .fr_ri = UART011_FR_RI,
+ .oversampling = false,
+ .dma_threshold = false,
+ .cts_event_workaround = false,
+ .always_enabled = false,
+ .fixed_options = false,
+ .skip_ibrd_fbrd = true,
+ .set_uartclk_rate = true,
+ .get_fifosize = get_fifosize_nvidia,
+};
+
/* Deals with DMA transactions */
struct pl011_dmabuf {
@@ -3115,6 +3137,11 @@ static const struct amba_id pl011_ids[] = {
.mask = 0x00ffffff,
.data = &vendor_st,
},
+ {
+ .id = 0x0006b011,
+ .mask = 0x000fffff,
+ .data = &vendor_nvidia,
+ },
{ 0, 0 },
};
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] serial: amba-pl011: Respect DMA controller's copy_align requirement
From: Kartik Rajput @ 2026-02-25 6:59 UTC (permalink / raw)
To: linux, gregkh, jirislaby, mingo, tglx, linmq006, arnd,
thierry.reding, jonathanh, linux-kernel, linux-serial
Cc: Kartik Rajput
In-Reply-To: <20260225065915.341522-1-kkartik@nvidia.com>
Some DMA controllers require transfer lengths to be aligned to a
specific boundary. For example, the Tegra GPC DMA requires 4-byte
(word) aligned transfers and will reject unaligned lengths.
Align the TX DMA buffer length down to the DMA controller's copy_align
boundary before submitting the transfer. Any remaining unaligned bytes
will be transmitted via PIO on subsequent calls, which is the existing
fallback behavior when DMA is not used.
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
drivers/tty/serial/amba-pl011.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f8deb30650a..98e434b0c30a 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -649,6 +649,15 @@ static int pl011_dma_tx_refill(struct uart_amba_port *uap)
count = PL011_DMA_BUFFER_SIZE;
count = kfifo_out_peek(&tport->xmit_fifo, dmatx->buf, count);
+
+ /*
+ * Align the TX buffer length to the DMA controller's copy_align
+ * requirements. Some DMA controllers (e.g., Tegra GPC DMA) require
+ * word-aligned transfers. Unaligned bytes will be sent via PIO.
+ */
+ if (chan->device->copy_align)
+ count = ALIGN_DOWN(count, 1 << chan->device->copy_align);
+
dmatx->len = count;
dmatx->dma = dma_map_single(dma_dev->dev, dmatx->buf, count,
DMA_TO_DEVICE);
--
2.43.0
^ permalink raw reply related
* [PATCH] tty: serial: 8250: Add SystemBase Multi I/O cards
From: Michael Walle @ 2026-02-25 8:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-serial, jochen, Michael Walle
Add support for the SystemBase Multi I/O serial cards, which are
"compatible" with a standard 16550A controllers, except that they need
to have their interrupts enabled in a proprietary way.
Tested with a Delock "Serial PCI Express x1 Card 8x Serial RS-232".
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
drivers/tty/serial/8250/8250_pci.c | 51 ++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 6589bb531cc6..7957a552b6ab 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -100,6 +100,8 @@
#define PCI_DEVICE_ID_ADDIDATA_CPCI7420_NG 0x7025
#define PCI_DEVICE_ID_ADDIDATA_CPCI7300_NG 0x7026
+#define PCI_VENDOR_ID_SYSTEMBASE 0x14a1
+
/* Unknown vendors/cards - this should not be in linux/pci_ids.h */
#define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584
#define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588
@@ -2128,6 +2130,35 @@ pci_moxa_setup(struct serial_private *priv,
return setup_port(priv, port, bar, offset, 0);
}
+#define SB_OPTR_IMR0 0x0c /* Interrupt mask register, p0 to p7 */
+static int pci_systembase_init(struct pci_dev *dev)
+{
+ resource_size_t iobase;
+
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT))
+ return serial_8250_warn_need_ioport(dev);
+
+ iobase = pci_resource_start(dev, 1);
+
+ /* This will support up to 8 ports */
+ outb(0xff, iobase + SB_OPTR_IMR0);
+
+ return 0;
+}
+
+static void pci_systembase_exit(struct pci_dev *dev)
+{
+ resource_size_t iobase;
+
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
+ serial_8250_warn_need_ioport(dev);
+ return;
+ }
+
+ iobase = pci_resource_start(dev, 0);
+ outb(0x00, iobase + SB_OPTR_IMR0);
+}
+
/*
* Master list of serial port init/setup/exit quirks.
* This does not describe the general nature of the port.
@@ -2476,6 +2507,16 @@ static struct pci_serial_quirk pci_serial_quirks[] = {
.init = pci_siig_init,
.setup = pci_siig_setup,
},
+ /* Systembase */
+ {
+ .vendor = PCI_VENDOR_ID_SYSTEMBASE,
+ .device = 0x0008,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .init = pci_systembase_init,
+ .setup = pci_default_setup,
+ .exit = pci_systembase_exit,
+ },
/*
* Titan cards
*/
@@ -3041,6 +3082,7 @@ enum pci_board_num_t {
pbn_b0_1_921600,
pbn_b0_2_921600,
pbn_b0_4_921600,
+ pbn_b0_8_921600,
pbn_b0_2_1130000,
@@ -3241,6 +3283,12 @@ static struct pciserial_board pci_boards[] = {
.base_baud = 921600,
.uart_offset = 8,
},
+ [pbn_b0_8_921600] = {
+ .flags = FL_BASE0,
+ .num_ports = 8,
+ .base_baud = 921600,
+ .uart_offset = 8,
+ },
[pbn_b0_2_1130000] = {
.flags = FL_BASE0,
@@ -6152,6 +6200,9 @@ static const struct pci_device_id serial_pci_tbl[] = {
PCI_ANY_ID, PCI_ANY_ID,
0, 0, pbn_b0_1_115200 },
+ /* Systembase Multi I/O cards */
+ { PCI_VDEVICE(SYSTEMBASE, 0x0008), pbn_b0_8_921600 },
+
/* Fintek PCI serial cards */
{ PCI_DEVICE(0x1c29, 0x1104), .driver_data = pbn_fintek_4 },
{ PCI_DEVICE(0x1c29, 0x1108), .driver_data = pbn_fintek_8 },
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v5 9/9] power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
From: Bartosz Golaszewski @ 2026-02-25 11:22 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
Manivannan Sadhasivam via B4 Relay
In-Reply-To: <20260224-pci-m2-e-v5-9-dd9b9501d33c@oss.qualcomm.com>
On Tue, 24 Feb 2026 06:30:55 +0100, Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> For supporting bluetooth over the non-discoverable UART interface of
> WCN7850, create the serdev device after enumerating the PCIe interface.
> This is mandatory since the device ID is only known after the PCIe
> enumeration and the ID is used for creating the serdev device.
>
> Since by default there is no OF or ACPI node for the created serdev,
> create a dynamic OF 'bluetooth' node with the 'compatible' property and
> attach it to the serdev device. This will allow the serdev device to bind
> to the existing bluetooth driver.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>
[snip]
> -static void pwrseq_pcie_m2_free_regulators(void *data)
> +static void pwrseq_pcie_m2_free_resources(void *data)
> {
> struct pwrseq_pcie_m2_ctx *ctx = data;
>
> + serdev_device_remove(ctx->serdev);
> + bus_unregister_notifier(&pci_bus_type, &ctx->nb);
> + of_changeset_revert(ctx->ocs);
> + of_changeset_destroy(ctx->ocs);
> regulator_bulk_free(ctx->num_vregs, ctx->regs);
> }
>
> +static int pwrseq_m2_pcie_create_bt_node(struct pwrseq_pcie_m2_ctx *ctx,
> + struct device_node *parent)
> +{
> + struct device *dev = ctx->dev;
> + struct device_node *np;
> + int ret;
> +
> + ctx->ocs = devm_kzalloc(dev, sizeof(*ctx->ocs), GFP_KERNEL);
> + if (!ctx->ocs)
> + return -ENOMEM;
> +
> + of_changeset_init(ctx->ocs);
> +
> + np = of_changeset_create_node(ctx->ocs, parent, "bluetooth");
> + if (!np) {
> + dev_err(dev, "Failed to create bluetooth node\n");
> + ret = -ENODEV;
> + goto err_destroy_changeset;
> + }
> +
> + ret = of_changeset_add_prop_string(ctx->ocs, np, "compatible", "qcom,wcn7850-bt");
> + if (ret) {
> + dev_err(dev, "Failed to add bluetooth compatible: %d\n", ret);
> + goto err_destroy_changeset;
> + }
> +
> + ret = of_changeset_apply(ctx->ocs);
> + if (ret) {
> + dev_err(dev, "Failed to apply changeset: %d\n", ret);
> + goto err_destroy_changeset;
> + }
> +
> + ret = device_add_of_node(&ctx->serdev->dev, np);
> + if (ret) {
> + dev_err(dev, "Failed to add OF node: %d\n", ret);
> + goto err_revert_changeset;
> + }
> +
> + return 0;
> +
> +err_revert_changeset:
> + of_changeset_revert(ctx->ocs);
> +err_destroy_changeset:
> + of_changeset_destroy(ctx->ocs);
> +
I would prefer pwrseq_pcie_m2_free_resources() to be split into separate
devm actions, otherwise it's not much different from simply having the
.remove() callback. With a split like that you'd avoid having these labels
here.
Otherwise looks good.
Bart
^ permalink raw reply
* Re: (subset) [PATCH v3 00/10] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Vinod Koul @ 2026-02-25 11:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju
Cc: Biju Das, linux-kernel, linux-serial, dmaengine, devicetree,
linux-clk, linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260203103031.247435-1-biju.das.jz@bp.renesas.com>
On Tue, 03 Feb 2026 10:30:08 +0000, Biju wrote:
> This patch series adds initial support for the Renesas RZ/G3L SoC and
> RZ/G3L SMARC EVK platform. The RZ/G3L device is a general-purpose
> microprocessor with a quad-core CA-55, single core CM-33, Mali-G31
> 3-D Graphics and other peripherals.
>
> Support for the below list of blocks is added in the SoC DTSI (r9a08g046.dtsi):
>
> [...]
Applied, thanks!
[01/10] dt-bindings: dma: rz-dmac: Document RZ/G3L SoC
commit: e45cf0c7d9b960f1aae4ee56c3c3d46549ccde86
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] serial: tegra: remove Kconfig dependency on APB DMA controller
From: Francesco Lavra @ 2026-02-25 11:35 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko, Kartik Rajput,
Geert Uytterhoeven, Wolfram Sang, Robert Marko, Thierry Bultel,
Douglas Anderson, linux-kernel, linux-serial
In-Reply-To: <20251126090759.4042709-1-flavra@baylibre.com>
Friendly ping
On Wed, 2025-11-26 at 10:07 +0100, Francesco Lavra wrote:
> This driver runs also on SoCs without a Tegra20 APB DMA controller (e.g.
> Tegra234).
> Remove the Kconfig dependency on TEGRA20_APB_DMA, and remove reference to
> the APB DMA controller from the Kconfig help text.
>
> Fixes: 60d2016a5161 ("arm64: tegra: Add Tegra234 GPCDMA device tree
> node")
> Signed-off-by: Francesco Lavra <flavra@baylibre.com>
> ---
> drivers/tty/serial/Kconfig | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 44427415a80d..6212a814fdb7 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -255,14 +255,13 @@ config SERIAL_SAMSUNG_CONSOLE
>
> config SERIAL_TEGRA
> tristate "NVIDIA Tegra20/30 SoC serial controller"
> - depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
> + depends on ARCH_TEGRA || COMPILE_TEST
> select SERIAL_CORE
> help
> Support for the on-chip UARTs on the NVIDIA Tegra series SOCs
> providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some machines may
> not
> provide all of these ports, depending on how the serial port
> - are enabled). This driver uses the APB DMA to achieve higher
> baudrate
> - and better performance.
> + are enabled).
>
> config SERIAL_TEGRA_TCU
> tristate "NVIDIA Tegra Combined UART"
^ permalink raw reply
* [syzbot] [serial?] KASAN: slab-out-of-bounds Write in do_con_write (3)
From: syzbot @ 2026-02-26 8:31 UTC (permalink / raw)
To: gregkh, jirislaby, linux-kernel, linux-serial, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: d9d32e5bd5a4 Merge tag 'ata-7.0-rc2' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1253f152580000
kernel config: https://syzkaller.appspot.com/x/.config?x=af6ed0125ed44356
dashboard link: https://syzkaller.appspot.com/bug?extid=8e9c1abac3ceb45abffe
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ade1e7548f1e/disk-d9d32e5b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6abd23967034/vmlinux-d9d32e5b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fde04bd3e374/bzImage-d9d32e5b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8e9c1abac3ceb45abffe@syzkaller.appspotmail.com
BUG: KASAN: slab-out-of-bounds in vc_con_write_normal drivers/tty/vt/vt.c:3135 [inline]
BUG: KASAN: slab-out-of-bounds in do_con_write+0x386f/0x8540 drivers/tty/vt/vt.c:3226
Write of size 2 at addr ffff888037925fb0 by task syz.2.556/8668
CPU: 1 UID: 0 PID: 8668 Comm: syz.2.556 Tainted: G U L syzkaller #0 PREEMPT(full)
Tainted: [U]=USER, [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x156/0x4c9 mm/kasan/report.c:482
kasan_report+0xdf/0x1e0 mm/kasan/report.c:595
vc_con_write_normal drivers/tty/vt/vt.c:3135 [inline]
do_con_write+0x386f/0x8540 drivers/tty/vt/vt.c:3226
con_write+0x23/0xb0 drivers/tty/vt/vt.c:3558
process_output_block drivers/tty/n_tty.c:557 [inline]
n_tty_write+0x44f/0x12d0 drivers/tty/n_tty.c:2366
iterate_tty_write drivers/tty/tty_io.c:1006 [inline]
file_tty_write.isra.0+0x4d2/0x890 drivers/tty/tty_io.c:1081
tty_write drivers/tty/tty_io.c:1102 [inline]
redirected_tty_write drivers/tty/tty_io.c:1125 [inline]
redirected_tty_write+0xd4/0x120 drivers/tty/tty_io.c:1105
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6ac/0x1070 fs/read_write.c:688
ksys_write+0x12a/0x250 fs/read_write.c:740
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f93fa79c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f93fb676028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f93faa15fa0 RCX: 00007f93fa79c629
RDX: 000000000000fdef RSI: 0000200000000000 RDI: 0000000000000005
RBP: 00007f93fa832b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f93faa16038 R14: 00007f93faa15fa0 R15: 00007ffc82d1ce98
</TASK>
Allocated by task 8646:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kmalloc_noprof include/linux/slab.h:962 [inline]
kzalloc_noprof include/linux/slab.h:1200 [inline]
kobject_uevent_env+0x263/0x18b0 lib/kobject_uevent.c:540
rx_queue_add_kobject net/core/net-sysfs.c:1280 [inline]
net_rx_queue_update_kobjects+0x1dd/0x760 net/core/net-sysfs.c:1322
register_queue_kobjects net/core/net-sysfs.c:2114 [inline]
netdev_register_kobject+0x290/0x3d0 net/core/net-sysfs.c:2362
register_netdevice+0x12e0/0x2210 net/core/dev.c:11411
__ip_tunnel_create+0x52b/0x670 net/ipv4/ip_tunnel.c:268
ip_tunnel_init_net+0x230/0x780 net/ipv4/ip_tunnel.c:1147
vti_init_net+0x2e/0x140 net/ipv4/ip_vti.c:517
ops_init+0x1e2/0x5f0 net/core/net_namespace.c:137
setup_net+0x118/0x3a0 net/core/net_namespace.c:446
copy_net_ns+0x46f/0x7c0 net/core/net_namespace.c:581
create_new_namespaces+0x3ea/0xac0 kernel/nsproxy.c:130
unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:226
ksys_unshare+0x473/0xad0 kernel/fork.c:3174
__do_sys_unshare kernel/fork.c:3245 [inline]
__se_sys_unshare kernel/fork.c:3243 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:3243
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 8646:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2687 [inline]
slab_free mm/slub.c:6124 [inline]
kfree+0x1f6/0x6b0 mm/slub.c:6442
kobject_uevent_env+0x2e2/0x18b0 lib/kobject_uevent.c:640
rx_queue_add_kobject net/core/net-sysfs.c:1280 [inline]
net_rx_queue_update_kobjects+0x1dd/0x760 net/core/net-sysfs.c:1322
register_queue_kobjects net/core/net-sysfs.c:2114 [inline]
netdev_register_kobject+0x290/0x3d0 net/core/net-sysfs.c:2362
register_netdevice+0x12e0/0x2210 net/core/dev.c:11411
__ip_tunnel_create+0x52b/0x670 net/ipv4/ip_tunnel.c:268
ip_tunnel_init_net+0x230/0x780 net/ipv4/ip_tunnel.c:1147
vti_init_net+0x2e/0x140 net/ipv4/ip_vti.c:517
ops_init+0x1e2/0x5f0 net/core/net_namespace.c:137
setup_net+0x118/0x3a0 net/core/net_namespace.c:446
copy_net_ns+0x46f/0x7c0 net/core/net_namespace.c:581
create_new_namespaces+0x3ea/0xac0 kernel/nsproxy.c:130
unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:226
ksys_unshare+0x473/0xad0 kernel/fork.c:3174
__do_sys_unshare kernel/fork.c:3245 [inline]
__se_sys_unshare kernel/fork.c:3243 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:3243
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888037924000
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 4016 bytes to the right of
allocated 4096-byte region [ffff888037924000, ffff888037925000)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37920
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88813fe3d140 dead000000000100 dead000000000122
raw: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88813fe3d140 dead000000000100 dead000000000122
head: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
head: 00fff00000000003 ffffea0000de4801 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5207, tgid 5207 (udevd), ts 53624826174, free_ts 53538236869
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x111d/0x3140 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x27c/0x2ba0 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3255 [inline]
allocate_slab mm/slub.c:3444 [inline]
new_slab+0xa6/0x6d0 mm/slub.c:3502
refill_objects+0x26b/0x400 mm/slub.c:7134
refill_sheaf mm/slub.c:2804 [inline]
alloc_full_sheaf mm/slub.c:2825 [inline]
__pcs_replace_empty_main+0x19f/0x600 mm/slub.c:4588
alloc_from_pcs mm/slub.c:4681 [inline]
slab_alloc_node mm/slub.c:4815 [inline]
__do_kmalloc_node mm/slub.c:5218 [inline]
__kmalloc_noprof+0x688/0x850 mm/slub.c:5231
kmalloc_noprof include/linux/slab.h:966 [inline]
tomoyo_realpath_from_path+0xb6/0x690 security/tomoyo/realpath.c:251
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_check_open_permission+0x2af/0x3c0 security/tomoyo/file.c:776
tomoyo_file_open+0x6b/0x90 security/tomoyo/tomoyo.c:334
security_file_open+0xb5/0x1e0 security/security.c:2636
do_dentry_open+0x5aa/0x1660 fs/open.c:926
vfs_open+0x82/0x3f0 fs/open.c:1081
do_open fs/namei.c:4671 [inline]
path_openat+0x208c/0x31a0 fs/namei.c:4830
do_file_open+0x20e/0x430 fs/namei.c:4859
do_sys_openat2+0x10d/0x1e0 fs/open.c:1366
page last free pid 5207 tgid 5207 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0x7e1/0x10d0 mm/page_alloc.c:2978
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x47/0xe0 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x1a0/0x1f0 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x69/0x90 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4501 [inline]
slab_alloc_node mm/slub.c:4830 [inline]
__do_kmalloc_node mm/slub.c:5218 [inline]
__kmalloc_noprof+0x2b9/0x850 mm/slub.c:5231
kmalloc_noprof include/linux/slab.h:966 [inline]
tomoyo_realpath_from_path+0xb6/0x690 security/tomoyo/realpath.c:251
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_check_open_permission+0x2af/0x3c0 security/tomoyo/file.c:776
tomoyo_file_open+0x6b/0x90 security/tomoyo/tomoyo.c:334
security_file_open+0xb5/0x1e0 security/security.c:2636
do_dentry_open+0x5aa/0x1660 fs/open.c:926
vfs_open+0x82/0x3f0 fs/open.c:1081
do_open fs/namei.c:4671 [inline]
path_openat+0x208c/0x31a0 fs/namei.c:4830
do_file_open+0x20e/0x430 fs/namei.c:4859
do_sys_openat2+0x10d/0x1e0 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
Memory state around the buggy address:
ffff888037925e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888037925f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888037925f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888037926000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888037926080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH] serial: tegra: remove Kconfig dependency on APB DMA controller
From: Jon Hunter @ 2026-02-26 10:04 UTC (permalink / raw)
To: Francesco Lavra, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Kartik Rajput, Geert Uytterhoeven, Wolfram Sang, Robert Marko,
Thierry Bultel, Douglas Anderson, linux-kernel, linux-serial,
linux-tegra@vger.kernel.org
In-Reply-To: <20251126090759.4042709-1-flavra@baylibre.com>
On 26/11/2025 09:07, Francesco Lavra wrote:
> This driver runs also on SoCs without a Tegra20 APB DMA controller (e.g.
> Tegra234).
> Remove the Kconfig dependency on TEGRA20_APB_DMA, and remove reference to
> the APB DMA controller from the Kconfig help text.
>
> Fixes: 60d2016a5161 ("arm64: tegra: Add Tegra234 GPCDMA device tree node")
This patch looks fine, but I would drop the fixes tag. There are other
earlier devices, such as Tegra186 that also use this. Also please CC
linux-tegra@vger.kernel.org on these patches too. I know people try to
limit the number of list copied, but we may miss this otherwise.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] tty: vt/keyboard: Hoist and reuse variable in vt_do_kdgkb_ioctl
From: Thorsten Blum @ 2026-02-26 12:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Alexey Gladkov, Thomas Gleixner,
Nathan Chancellor, Myrrh Periwinkle
Cc: Thorsten Blum, Kees Cook, linux-kernel, linux-serial
Hoist 'len' and use it in both cases.
The last 'kbs' assignment is useless and a leftover from commit
bfb24564b5fd ("tty: vt/keyboard: use __free()"). Remove it.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/tty/vt/keyboard.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index d65fc60dd7be..6a1044f87216 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1991,17 +1991,18 @@ static char *vt_kdskbsent(char *kbs, unsigned char cur)
int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm)
{
unsigned char kb_func;
+ ssize_t len;
if (get_user(kb_func, &user_kdgkb->kb_func))
return -EFAULT;
kb_func = array_index_nospec(kb_func, MAX_NR_FUNC);
+ /* size should have been a struct member */
+ len = sizeof(user_kdgkb->kb_string);
+
switch (cmd) {
case KDGKBSENT: {
- /* size should have been a struct member */
- ssize_t len = sizeof(user_kdgkb->kb_string);
-
char __free(kfree) *kbs = kmalloc(len, GFP_KERNEL);
if (!kbs)
return -ENOMEM;
@@ -2022,12 +2023,12 @@ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm)
return -EPERM;
char __free(kfree) *kbs = strndup_user(user_kdgkb->kb_string,
- sizeof(user_kdgkb->kb_string));
+ len);
if (IS_ERR(kbs))
return PTR_ERR(kbs);
guard(spinlock_irqsave)(&func_buf_lock);
- kbs = vt_kdskbsent(kbs, kb_func);
+ vt_kdskbsent(kbs, kb_func);
return 0;
}
--
Thorsten Blum <thorsten.blum@linux.dev>
GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4
^ permalink raw reply related
* Re: [PATCH] tty: n_tty: fix KCSAN data-race in n_tty_flush_buffer / n_tty_lookahead_flow_ctrl
From: Osama Abdelkader @ 2026-02-26 15:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Ilpo Järvinen, linux-kernel, linux-serial
Cc: syzbot+80806cf7508e92c7cc86
In-Reply-To: <20260211210838.45127-1-osama.abdelkader@gmail.com>
On Wed, Feb 11, 2026 at 10:08:38PM +0100, Osama Abdelkader wrote:
> n_tty_lookahead_flow_ctrl() accesses ldata->lookahead_count without
> holding termios_rwsem, while reset_buffer_flags() in n_tty_flush_buffer()
> resets it with exclusive termios_rwsem held. This causes a data race
> reported by KCSAN when a PTY is closed while flush_to_ldisc is still
> processing lookahead data.
>
> Fix by taking termios_rwsem (read) in n_tty_lookahead_flow_ctrl(),
> consistent with __receive_buf() which also modifies lookahead_count
> under the read lock.
>
> Reported-by: syzbot+80806cf7508e92c7cc86@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=80806cf7508e92c7cc86
> Fixes: 6bb6fa6908eb ("tty: Implement lookahead to process XON/XOFF timely")
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> ---
> drivers/tty/n_tty.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index e6a0f5b40d0a..725d6ed2b863 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1480,6 +1480,8 @@ static void n_tty_lookahead_flow_ctrl(struct tty_struct *tty, const u8 *cp,
> struct n_tty_data *ldata = tty->disc_data;
> u8 flag = TTY_NORMAL;
>
> + guard(rwsem_read)(&tty->termios_rwsem);
> +
> ldata->lookahead_count += count;
>
> if (!I_IXON(tty))
> --
> 2.43.0
>
ping
^ permalink raw reply
* Re: [PATCH] tty: vt/keyboard: Hoist and reuse variable in vt_do_kdgkb_ioctl
From: Jiri Slaby @ 2026-02-27 7:22 UTC (permalink / raw)
To: Thorsten Blum, Greg Kroah-Hartman, Alexey Gladkov,
Thomas Gleixner, Nathan Chancellor, Myrrh Periwinkle
Cc: Kees Cook, linux-kernel, linux-serial
In-Reply-To: <20260226123419.737669-1-thorsten.blum@linux.dev>
On 26. 02. 26, 13:34, Thorsten Blum wrote:
> Hoist 'len' and use it in both cases.
>
> The last 'kbs' assignment is useless and a leftover from commit
> bfb24564b5fd ("tty: vt/keyboard: use __free()"). Remove it.
No, kbs is set to NULL by vt_kdskbsent() when it should NOT be freed.
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/tty/vt/keyboard.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index d65fc60dd7be..6a1044f87216 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
...
> @@ -2022,12 +2023,12 @@ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm)
> return -EPERM;
>
> char __free(kfree) *kbs = strndup_user(user_kdgkb->kb_string,
> - sizeof(user_kdgkb->kb_string));
> + len);
> if (IS_ERR(kbs))
> return PTR_ERR(kbs);
>
> guard(spinlock_irqsave)(&func_buf_lock);
> - kbs = vt_kdskbsent(kbs, kb_func);
> + vt_kdskbsent(kbs, kb_func);
--
js
suse labs
^ permalink raw reply
* [rt-devel:linux-7.0.y-rt-rebase] 55eabced1d: BUG:kernel_reboot-without-warning_in_test_stage
From: kernel test robot @ 2026-02-27 7:57 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: oe-lkp, lkp, linux-serial, oliver.sang
Hello,
patch "serial: 8250: Switch to nbcon console" was reverted by
f79b163c42314 Revert "serial: 8250: Switch to nbcon console"
based on our previous old report
"[linux-next:master] [serial] b63e6f60ea: BUG:soft_lockup-CPU##stuck_for#s![modprobe:#]"
in
https://lore.kernel.org/all/202501221029.fb0d574d-lkp@intel.com/
there are some discussions which seems think the commit is not the real root
cause of the issue.
this commit 55eabced1d reapplies "serial: 8250: Switch to nbcon console", then
we notice a new "kernel_reboot-without-warning_in_test_stage" issue in a boot
test with randconfig. however, unfortunately, we cannot capture further useful
information in dmesg.
so maybe this report cannot supply enough useful information, just FYI what
we observed in our tests.
below is full report.
kernel test robot noticed "BUG:kernel_reboot-without-warning_in_test_stage" on:
commit: 55eabced1d566d2815cc215272ece998c8f2e93f ("Reapply "serial: 8250: Switch to nbcon console"")
https://git.kernel.org/cgit/linux/kernel/git/rt/linux-rt-devel.git linux-7.0.y-rt-rebase
in testcase: boot
config: x86_64-randconfig-001-20260225
compiler: gcc-13
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
(please refer to attached dmesg/kmsg for entire log/backtrace)
+-------------------------------------------------+----------+------------+
| | v7.0-rc1 | 55eabced1d |
+-------------------------------------------------+----------+------------+
| boot_successes | 40 | 0 |
| boot_failures | 0 | 6 |
| BUG:kernel_reboot-without-warning_in_test_stage | 0 | 6 |
+-------------------------------------------------+----------+------------+
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202602271552.c972ef9e-lkp@intel.com
[ 16.023891][ T126] sleep started
[ 16.023940][ T126]
[ 17.102254][ T126] /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 http://internal-lkp-server:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/vm-meta-288/boot-1-quantal-x86_64-core-20190426.cgz-x86_64-randconfig-001-20260225-55eabced1d56-20260226-27605-1wm64jc-2.yaml&job_state=post_run -O /dev/null
[ 17.106752][ T126]
mkdir: cannot create directory `/var/lock/lkp-bootstrap.lock': File exists
[ 19.145988][ T126] kill 428 vmstat -n 1
[ 19.146032][ T126]
[ 19.189830][ T126] kill 419 cat /proc/kmsg
[ 19.189873][ T126]
[ 19.253688][ T126] kill 447 /bin/sh /lkp/lkp/src/programs/watchdog/monitor
[ 19.258684][ T126]
[ 19.277825][ T126] wait for background processes: 439
[ 19.277867][ T126]
[ 19.279442][ T126] monitor
[ 19.279463][ T126]
[ 24.067178][ T126] /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 http://internal-lkp-server:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/vm-meta-288/boot-1-quantal-x86_64-core-20190426.cgz-x86_64-randconfig-001-20260225-55eabced1d56-20260226-27605-1wm64jc-2.yaml&loadavg=0.94%200.22%200.07%201/102%20625&start_time=1772044359&end_time=1772044361&version=/lkp/lkp/.src-20260226-000921:3d999d51ba0e-dirty:bc8736f22ca0& -O /dev/null
[ 24.067231][ T126]
[ 25.032907][ T126] /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 http://internal-lkp-server:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/vm-meta-288/boot-1-quantal-x86_64-core-20190426.cgz-x86_64-randconfig-001-20260225-55eabced1d56-20260226-27605-1wm64jc-2.yaml&job_state=finished -O /dev/null
[ 25.035121][ T126]
[ 25.272417][ T1] init: tty4 main process (515) terminated with status 1
[ 25.273235][ T1] init: tty4 main process ended, respawning
[ 25.304364][ T1] init: tty5 main process (518) terminated with status 1
[ 25.305147][ T1] init: tty5 main process ended, respawning
[ 25.320550][ T1] init: tty2 main process (519) terminated with status 1
[ 25.321322][ T1] init: tty2 main process ended, respawning
[ 25.340485][ T1] init: tty3 main process (522) terminated with status 1
[ 25.341245][ T1] init: tty3 main process ended, respawning
[ 25.368534][ T1] init: tty6 main process (523) terminated with status 1
[ 25.369377][ T1] init: tty6 main process ended, respawning
LKP: ttyS0: 103: LKP: tbox cant kexec and rebooting forcely
[ 26.117689][ T126] LKP: stdout: 103: LKP: tbox cant kexec and rebooting forcely
[ 26.117719][ T126]
[ 26.234198][ T126] /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 http://internal-lkp-server:80/~lkp/cgi-bin/lkp-wtmp?tbox_name=vm-snb&tbox_state=rebooting_cant_kexec&job_file=/lkp/jobs/scheduled/vm-meta-288/boot-1-quantal-x86_64-core-20190426.cgz-x86_64-randconfig-001-20260225-55eabced1d56-20260226-27605-1wm64jc-2.yaml -O /dev/null
[ 26.238678][ T126]
BUG: kernel reboot-without-warning in test stage
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260227/202602271552.c972ef9e-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox