* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-13 17:16 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: 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, 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
In-Reply-To: <20260112-pci-m2-e-v4-5-eff84d2c6d26@oss.qualcomm.com>
On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> devices. Spec also provides an optional interface to connect the UIM card,
> but that is not covered in this binding.
>
> The connector provides a primary power supply of 3.3v, along with an
> optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> 1.8v sideband signaling.
>
> The connector also supplies optional signals in the form of GPIOs for fine
> grained power management.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 155 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> new file mode 100644
> index 000000000000..b65b39ddfd19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -0,0 +1,154 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCIe M.2 Mechanical Key E Connector
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> +
> +description:
> + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> + connector. Mechanical Key E connectors are used to connect Wireless
> + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> +
> +properties:
> + compatible:
> + const: pcie-m2-e-connector
> +
> + vpcie3v3-supply:
> + description: A phandle to the regulator for 3.3v supply.
> +
> + vpcie1v8-supply:
> + description: A phandle to the regulator for VIO 1.8v supply.
> +
> + ports:
Also, nodes go after all properties.
> + $ref: /schemas/graph.yaml#/properties/ports
> + description: OF graph bindings modeling the interfaces exposed on the
> + connector. Since a single connector can have multiple interfaces, every
> + interface has an assigned OF graph port number as described below.
^ permalink raw reply
* Re: [PATCH v4 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Rob Herring @ 2026-01-13 17:25 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: 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, 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
In-Reply-To: <20260112-pci-m2-e-v4-6-eff84d2c6d26@oss.qualcomm.com>
On Mon, Jan 12, 2026 at 09:56:05PM +0530, Manivannan Sadhasivam wrote:
> Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> spec, it looks very similar to the M.2 Key M connector. So add the
> "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> to reuse the Key M binding.
Key M or Key E? I'm confused.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> .../devicetree/bindings/connector/pcie-m2-e-connector.yaml | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> index b65b39ddfd19..9757fe92907b 100644
> --- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -17,7 +17,14 @@ description:
>
> properties:
> compatible:
> - const: pcie-m2-e-connector
> + oneOf:
> + - items:
> + - enum:
> + - pcie-m2-1620-lga-connector
> + - const: pcie-m2-e-connector
> + - items:
> + - enum:
> + - pcie-m2-e-connector
>
> vpcie3v3-supply:
> description: A phandle to the regulator for 3.3v supply.
>
> --
> 2.48.1
>
^ permalink raw reply
* Re: [PATCH 02/19] printk: Introduce console_is_nbcon
From: Petr Mladek @ 2026-01-13 17:37 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-2-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:09, Marcos Paulo de Souza wrote:
> Besides checking if the current console is NBCON or not, console->flags
> is also being read in order to serve as argument of the console_is_usable
> function.
>
> But CON_NBCON flag is unique: it's set just once in the console
> registration and never cleared. In this case it can be possible to read
> the flag when console_srcu_lock is held (which is the case when using
> for_each_console).
>
> This change makes possible to remove the flags argument from
> console_is_usable in the next patches.
>
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> ---
> include/linux/console.h | 27 +++++++++++++++++++++++++++
> kernel/debug/kdb/kdb_io.c | 2 +-
> kernel/printk/nbcon.c | 2 +-
> kernel/printk/printk.c | 15 ++++++---------
> 4 files changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 35c03fc4ed51..dd4ec7a5bff9 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -561,6 +561,33 @@ static inline void console_srcu_write_flags(struct console *con, short flags)
> WRITE_ONCE(con->flags, flags);
> }
>
> +/**
> + * console_srcu_is_nbcon - Locklessly check whether the console is nbcon
There is _srcu in the function name, see below.
> + * @con: struct console pointer of console to check
> + *
> + * Requires console_srcu_read_lock to be held, which implies that @con might
> + * be a registered console. The purpose of holding console_srcu_read_lock is
> + * to guarantee that no exit/cleanup routines will run if the console
> + * is currently undergoing unregistration.
> + *
> + * If the caller is holding the console_list_lock or it is _certain_ that
> + * @con is not and will not become registered, the caller may read
> + * @con->flags directly instead.
> + *
> + * Context: Any context.
> + * Return: True when CON_NBCON flag is set.
> + */
> +static inline bool console_is_nbcon(const struct console *con)
And here it is without _srcu.
I would prefer the variant with _srcu to make it clear that it
can be called only under _srcu. Similar to console_srcu_read_flags(con).
> +{
> + WARN_ON_ONCE(!console_srcu_read_lock_is_held());
> +
> + /*
> + * The CON_NBCON flag is statically initialized and is never
> + * set or cleared at runtime.
> + */
> + return data_race(con->flags & CON_NBCON);
> +}
> +
> /* Variant of console_is_registered() when the console_list_lock is held. */
> static inline bool console_is_registered_locked(const struct console *con)
> {
Otherwise, it looks good to me.
With a consistent name, feel free to use:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH RFC 2/4] rust: add basic serial device bus abstractions
From: Danilo Krummrich @ 2026-01-13 17:37 UTC (permalink / raw)
To: Markus Probst
Cc: Kari Argillander, Rob Herring, Greg Kroah-Hartman, Jiri Slaby,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-serial, linux-kernel, rust-for-linux
In-Reply-To: <76491897ad6e0ff2749935c39702b93adc9951d6.camel@posteo.de>
On Tue Jan 13, 2026 at 5:15 PM CET, Markus Probst wrote:
>> > +impl<T: Driver + 'static> Adapter<T> {
>> > + const OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
>> > + receive_buf: if T::HAS_RECEIVE {
>> > + Some(Self::receive_buf_callback)
>> > + } else {
>> > + None
>> > + },
>> > + write_wakeup: if T::HAS_WRITE_WAKEUP {
>> > + Some(Self::write_wakeup_callback)
>> > + } else {
>> > + Some(bindings::serdev_device_write_wakeup)
>> > + },
>> > + };
>> > + const INITIAL_OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
>> > + receive_buf: Some(Self::initial_receive_buf_callback),
>> > + write_wakeup: if T::HAS_WRITE_WAKEUP_INITIAL {
>> > + Some(Self::initial_write_wakeup_callback)
>> > + } else {
>> > + Some(bindings::serdev_device_write_wakeup)
>> > + },
>> > + };
>> > + const NO_OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
>> > + receive_buf: None,
>> > + write_wakeup: Some(bindings::serdev_device_write_wakeup),
>> > + };
>> > +
>> > + extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi::c_int {
>> > + // SAFETY: The serial device bus only ever calls the probe callback with a valid pointer to
>> > + // a `struct serdev_device`.
>> > + //
>> > + // INVARIANT: `sdev` is valid for the duration of `probe_callback()`.
>> > + let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
>> > + let info = <Self as driver::Adapter>::id_info(sdev.as_ref());
>> > +
>> > + from_result(|| {
>> > + let data = try_pin_init!(Drvdata {
>> > + driver <- T::probe(sdev, info),
>> > + initial_data: Some(Default::default()).into(),
>> > + late_probe_data: None.into(),
>> > + });
>> > +
>> > + sdev.as_ref().set_drvdata(data)?;
This does not work, a driver can obtain its device private data with
Device::<Bound>::drvdata() [1].
For this the driver must assert the correct type, but since you use a private
type instead of the type given by the driver, i.e. T, Device::<Bound>::drvdata()
will always fail for the driver.
[1] https://rust.docs.kernel.org/kernel/device/struct.Device.html#method.drvdata
>> > +
>> > + // SAFETY: We just set drvdata to `Drvdata<T>`.
>> > + let data = unsafe { sdev.as_ref().drvdata_borrow::<Drvdata<T>>() };
>> > +
>> > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
>> > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::INITIAL_OPS) };
>> > +
>> > + // SAFETY: The serial device bus only ever calls the probe callback with a valid pointer
>> > + // to a `struct serdev_device`.
>> > + to_result(unsafe {
>> > + bindings::devm_serdev_device_open(sdev.as_ref().as_raw(), sdev.as_raw())
>> > + })?;
I don't think it is a good idea to hardcode this into the probe() callback and
split it up in multiple stages, we can always solve things like ordering with
new types, type states and guards.
>> > +
>> > + // SAFETY: `&data.driver` is guaranteed to be pinned.
>> > + T::configure(sdev, unsafe { Pin::new_unchecked(&data.driver) }, info)?;
>> > +
>> > + if !T::HAS_RECEIVE_INITIAL {
>> > + // SAFETY:
>> > + // - It is guaranteed that we have exclusive access to `data.initial_data` and
>> > + // `data.late_probe_data`.
How is it ensured that this does not run concurrently with
initial_receive_buf_callback(), etc.?
>> > + // - We just initialized `data.initial_data` with Some.
>> > + unsafe { Self::do_late_probe(sdev, data)? };
>> > + }
It is a bit unclear to me what you try to achieve here.
Do you want to synchronize an initial data transfer? Then something along the
lines of what Kari proposes seems reasonable.
Or is the intention that this will run entirely async? But then distinct
initialization stages as they appear above won't work.
>> > +
>> > + Ok(0)
>> > + })
>> > + }
>> > +
>> > + /// # Safety
>> > + ///
>> > + /// The caller must guarantee, that we have exclusive access to `data.initial_data` and
>> > + /// `data.late_probe_data`. `data.initial_data` must be Some.
>> > + /// (i. e. `late_probe` has not been called yet).
>> > + unsafe fn do_late_probe(sdev: &Device<device::CoreInternal>, data: Pin<&Drvdata<T>>) -> Result {
>> > + // SAFETY: `&data.driver` is guaranteed to be pinned.
>> > + let data_driver = unsafe { Pin::new_unchecked(&data.driver) };
>> > +
>> > + // SAFETY: The function contract guarantees that we have exclusive access to
>> > + // `data.initial_data`.
>> > + let initial_data = unsafe { &mut *data.initial_data.get() };
>> > +
>> > + // SAFETY: The function contract guarantees that we have exclusive access to
>> > + // `data.late_probe_data`.
>> > + let late_probe_data = unsafe { &mut *data.late_probe_data.get() };
>> > +
>> > + *late_probe_data = Some(KBox::pin_init(
>> > + T::late_probe(
>> > + sdev,
>> > + data_driver,
>> > + // SAFETY: The function contract guarantees that `data.initial_data` is Some.
>> > + unsafe { initial_data.take().unwrap_unchecked() },
>> > + ),
>> > + GFP_KERNEL,
>> > + )?);
>> > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
>> > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::OPS) };
>> > + Ok(())
>> > + }
<snip>
>> > + extern "C" fn initial_receive_buf_callback(
>> > + sdev: *mut bindings::serdev_device,
>> > + buf: *const u8,
>> > + length: usize,
>> > + ) -> usize {
>> > + if !T::HAS_RECEIVE_INITIAL {
>> > + return 0;
>> > + }
>> > +
>> > + // SAFETY: The serial device bus only ever calls the receive buf callback with a valid
>> > + // pointer to a `struct serdev_device`.
>> > + //
>> > + // INVARIANT: `sdev` is valid for the duration of `receive_buf_callback()`.
>> > + let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
>> > +
>> > + // SAFETY: `buf` is guaranteed to be non-null and has the size of `length`.
>> > + let buf = unsafe { core::slice::from_raw_parts(buf, length) };
>> > +
>> > + // SAFETY: `initial_receive_buf_callback` is only ever called after a successful call to
>> > + // `probe_callback`, hence it's guaranteed that `Device::set_drvdata()` has been called
>> > + // and stored a `Pin<KBox<Drvdata<T>>>`.
>> > + let data = unsafe { sdev.as_ref().drvdata_borrow::<Drvdata<T>>() };
>> > +
>> > + // SAFETY: `&data.driver` is guaranteed to be pinned.
>> > + let driver_data = unsafe { Pin::new_unchecked(&data.driver) };
>> > +
>> > + // SAFETY:
>> > + // - `data.initial_data` is always Some until `InitialReceiveResult::Ready` is
>> > + // returned below.
>> > + // - It is guaranteed that we have exclusive access to `data.initial_data`.
>> > + let initial_data = unsafe { (*data.initial_data.get()).as_mut().unwrap_unchecked() };
>> > +
>> > + match T::receive_initial(sdev, driver_data, initial_data, buf) {
>> > + Ok(InitialReceiveResult::Pending(size)) => size,
>> > + Ok(InitialReceiveResult::Ready(size)) => {
>> > + // SAFETY:
>> > + // - It is guaranteed that we have exclusive access to `data.initial_data` and
>> > + // `data.late_probe_data`.
>> > + // - We just initialized `data.initial_data` with Some.
>> > + if let Err(err) = unsafe { Self::do_late_probe(sdev, data) } {
We are calling late_probe() again from initial_receive_buf_callback()? Why?
>> > + dev_err!(sdev.as_ref(), "Unable to late probe device: {err:?}\n");
>> > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to
>> > + // `serdev_device`.
>> > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::NO_OPS) };
>> > + return length;
>> > + }
>> > + size
>> > + }
>> > + Err(err) => {
>> > + dev_err!(
>> > + sdev.as_ref(),
>> > + "Unable to receive initial data for probe: {err:?}.\n"
>> > + );
>> > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
>> > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::NO_OPS) };
>> > + length
>> > + }
>> > + }
>> > + }
<snip>
> There currently is only one serial device bus driver in the kernel,
> which needs initial data:
> drivers/bluetooth/hci_uart.h
> drivers/bluetooth/hci_ldisc.c
> drivers/bluetooth/hci_serdev.c
>
> This driver retrieves this initial data after probe (not in the probe)
> and then initializes it with a workqueue. Given it is part of the
> kernel, I assume this is the intended behaviour.
In this case I assume the driver has a lock protected buffer in its private
data? Which would be entirely different than what you implement above, no?
^ permalink raw reply
* Re: [PATCH RFC 2/4] rust: add basic serial device bus abstractions
From: Markus Probst @ 2026-01-13 17:59 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Kari Argillander, Rob Herring, Greg Kroah-Hartman, Jiri Slaby,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-serial, linux-kernel, rust-for-linux
In-Reply-To: <DFNN75KWL8B9.1YHK1ZRV43W7O@kernel.org>
On Tue, 2026-01-13 at 18:37 +0100, Danilo Krummrich wrote:
> On Tue Jan 13, 2026 at 5:15 PM CET, Markus Probst wrote:
> > > > +impl<T: Driver + 'static> Adapter<T> {
> > > > + const OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
> > > > + receive_buf: if T::HAS_RECEIVE {
> > > > + Some(Self::receive_buf_callback)
> > > > + } else {
> > > > + None
> > > > + },
> > > > + write_wakeup: if T::HAS_WRITE_WAKEUP {
> > > > + Some(Self::write_wakeup_callback)
> > > > + } else {
> > > > + Some(bindings::serdev_device_write_wakeup)
> > > > + },
> > > > + };
> > > > + const INITIAL_OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
> > > > + receive_buf: Some(Self::initial_receive_buf_callback),
> > > > + write_wakeup: if T::HAS_WRITE_WAKEUP_INITIAL {
> > > > + Some(Self::initial_write_wakeup_callback)
> > > > + } else {
> > > > + Some(bindings::serdev_device_write_wakeup)
> > > > + },
> > > > + };
> > > > + const NO_OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
> > > > + receive_buf: None,
> > > > + write_wakeup: Some(bindings::serdev_device_write_wakeup),
> > > > + };
> > > > +
> > > > + extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi::c_int {
> > > > + // SAFETY: The serial device bus only ever calls the probe callback with a valid pointer to
> > > > + // a `struct serdev_device`.
> > > > + //
> > > > + // INVARIANT: `sdev` is valid for the duration of `probe_callback()`.
> > > > + let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
> > > > + let info = <Self as driver::Adapter>::id_info(sdev.as_ref());
> > > > +
> > > > + from_result(|| {
> > > > + let data = try_pin_init!(Drvdata {
> > > > + driver <- T::probe(sdev, info),
> > > > + initial_data: Some(Default::default()).into(),
> > > > + late_probe_data: None.into(),
> > > > + });
> > > > +
> > > > + sdev.as_ref().set_drvdata(data)?;
>
> This does not work, a driver can obtain its device private data with
> Device::<Bound>::drvdata() [1].
>
> For this the driver must assert the correct type, but since you use a private
> type instead of the type given by the driver, i.e. T, Device::<Bound>::drvdata()
> will always fail for the driver.
>
> [1] https://rust.docs.kernel.org/kernel/device/struct.Device.html#method.drvdata
I need to fix that.
>
> > > > +
> > > > + // SAFETY: We just set drvdata to `Drvdata<T>`.
> > > > + let data = unsafe { sdev.as_ref().drvdata_borrow::<Drvdata<T>>() };
> > > > +
> > > > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
> > > > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::INITIAL_OPS) };
> > > > +
> > > > + // SAFETY: The serial device bus only ever calls the probe callback with a valid pointer
> > > > + // to a `struct serdev_device`.
> > > > + to_result(unsafe {
> > > > + bindings::devm_serdev_device_open(sdev.as_ref().as_raw(), sdev.as_raw())
> > > > + })?;
>
> I don't think it is a good idea to hardcode this into the probe() callback and
> split it up in multiple stages, we can always solve things like ordering with
> new types, type states and guards.
>
> > > > +
> > > > + // SAFETY: `&data.driver` is guaranteed to be pinned.
> > > > + T::configure(sdev, unsafe { Pin::new_unchecked(&data.driver) }, info)?;
> > > > +
> > > > + if !T::HAS_RECEIVE_INITIAL {
> > > > + // SAFETY:
> > > > + // - It is guaranteed that we have exclusive access to `data.initial_data` and
> > > > + // `data.late_probe_data`.
>
> How is it ensured that this does not run concurrently with
> initial_receive_buf_callback(), etc.?
```
if !T::HAS_RECEIVE_INITIAL {
return 0;
}
```
at the beginning of the function does.
>
> > > > + // - We just initialized `data.initial_data` with Some.
> > > > + unsafe { Self::do_late_probe(sdev, data)? };
> > > > + }
>
> It is a bit unclear to me what you try to achieve here.
>
> Do you want to synchronize an initial data transfer? Then something along the
> lines of what Kari proposes seems reasonable.
>
> Or is the intention that this will run entirely async? But then distinct
> initialization stages as they appear above won't work.
Async.
The driver gets probed.
late_probe will be called, after all the necessary data for the
initialization is there.
Can you explain what doesn't work? The code has been tested with a
prototype driver before submission.
Kari his approach is synchronize inside the probe function, until all
the necessary data is there.
Which one do you think should be used for the abstraction?
>
> > > > +
> > > > + Ok(0)
> > > > + })
> > > > + }
> > > > +
> > > > + /// # Safety
> > > > + ///
> > > > + /// The caller must guarantee, that we have exclusive access to `data.initial_data` and
> > > > + /// `data.late_probe_data`. `data.initial_data` must be Some.
> > > > + /// (i. e. `late_probe` has not been called yet).
> > > > + unsafe fn do_late_probe(sdev: &Device<device::CoreInternal>, data: Pin<&Drvdata<T>>) -> Result {
> > > > + // SAFETY: `&data.driver` is guaranteed to be pinned.
> > > > + let data_driver = unsafe { Pin::new_unchecked(&data.driver) };
> > > > +
> > > > + // SAFETY: The function contract guarantees that we have exclusive access to
> > > > + // `data.initial_data`.
> > > > + let initial_data = unsafe { &mut *data.initial_data.get() };
> > > > +
> > > > + // SAFETY: The function contract guarantees that we have exclusive access to
> > > > + // `data.late_probe_data`.
> > > > + let late_probe_data = unsafe { &mut *data.late_probe_data.get() };
> > > > +
> > > > + *late_probe_data = Some(KBox::pin_init(
> > > > + T::late_probe(
> > > > + sdev,
> > > > + data_driver,
> > > > + // SAFETY: The function contract guarantees that `data.initial_data` is Some.
> > > > + unsafe { initial_data.take().unwrap_unchecked() },
> > > > + ),
> > > > + GFP_KERNEL,
> > > > + )?);
> > > > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
> > > > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::OPS) };
> > > > + Ok(())
> > > > + }
>
> <snip>
>
> > > > + extern "C" fn initial_receive_buf_callback(
> > > > + sdev: *mut bindings::serdev_device,
> > > > + buf: *const u8,
> > > > + length: usize,
> > > > + ) -> usize {
> > > > + if !T::HAS_RECEIVE_INITIAL {
> > > > + return 0;
> > > > + }
> > > > +
> > > > + // SAFETY: The serial device bus only ever calls the receive buf callback with a valid
> > > > + // pointer to a `struct serdev_device`.
> > > > + //
> > > > + // INVARIANT: `sdev` is valid for the duration of `receive_buf_callback()`.
> > > > + let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
> > > > +
> > > > + // SAFETY: `buf` is guaranteed to be non-null and has the size of `length`.
> > > > + let buf = unsafe { core::slice::from_raw_parts(buf, length) };
> > > > +
> > > > + // SAFETY: `initial_receive_buf_callback` is only ever called after a successful call to
> > > > + // `probe_callback`, hence it's guaranteed that `Device::set_drvdata()` has been called
> > > > + // and stored a `Pin<KBox<Drvdata<T>>>`.
> > > > + let data = unsafe { sdev.as_ref().drvdata_borrow::<Drvdata<T>>() };
> > > > +
> > > > + // SAFETY: `&data.driver` is guaranteed to be pinned.
> > > > + let driver_data = unsafe { Pin::new_unchecked(&data.driver) };
> > > > +
> > > > + // SAFETY:
> > > > + // - `data.initial_data` is always Some until `InitialReceiveResult::Ready` is
> > > > + // returned below.
> > > > + // - It is guaranteed that we have exclusive access to `data.initial_data`.
> > > > + let initial_data = unsafe { (*data.initial_data.get()).as_mut().unwrap_unchecked() };
> > > > +
> > > > + match T::receive_initial(sdev, driver_data, initial_data, buf) {
> > > > + Ok(InitialReceiveResult::Pending(size)) => size,
> > > > + Ok(InitialReceiveResult::Ready(size)) => {
> > > > + // SAFETY:
> > > > + // - It is guaranteed that we have exclusive access to `data.initial_data` and
> > > > + // `data.late_probe_data`.
> > > > + // - We just initialized `data.initial_data` with Some.
> > > > + if let Err(err) = unsafe { Self::do_late_probe(sdev, data) } {
>
> We are calling late_probe() again from initial_receive_buf_callback()? Why?
It only gets called once.
This is gated behind "if T::HAS_RECEIVE_INITIAL". And in probe its
gated behind "if T::HAS_RECEIVE_INITIAL".
If "receive_initial" does not get implemented by the driver, late probe
will be run immediately after the regular probe.
>
> > > > + dev_err!(sdev.as_ref(), "Unable to late probe device: {err:?}\n");
> > > > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to
> > > > + // `serdev_device`.
> > > > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::NO_OPS) };
> > > > + return length;
> > > > + }
> > > > + size
> > > > + }
> > > > + Err(err) => {
> > > > + dev_err!(
> > > > + sdev.as_ref(),
> > > > + "Unable to receive initial data for probe: {err:?}.\n"
> > > > + );
> > > > + // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
> > > > + unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::NO_OPS) };
> > > > + length
> > > > + }
> > > > + }
> > > > + }
>
> <snip>
>
> > There currently is only one serial device bus driver in the kernel,
> > which needs initial data:
> > drivers/bluetooth/hci_uart.h
> > drivers/bluetooth/hci_ldisc.c
> > drivers/bluetooth/hci_serdev.c
> >
> > This driver retrieves this initial data after probe (not in the probe)
> > and then initializes it with a workqueue. Given it is part of the
> > kernel, I assume this is the intended behaviour.
>
> In this case I assume the driver has a lock protected buffer in its private
> data? Which would be entirely different than what you implement above, no?
^ permalink raw reply
* Re: [PATCH RFC 2/4] rust: add basic serial device bus abstractions
From: Danilo Krummrich @ 2026-01-13 19:10 UTC (permalink / raw)
To: Markus Probst
Cc: Kari Argillander, Rob Herring, Greg Kroah-Hartman, Jiri Slaby,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-serial, linux-kernel, rust-for-linux
In-Reply-To: <dcab1e61e451aeba27575c8245aef687caf94b23.camel@posteo.de>
On Tue Jan 13, 2026 at 6:59 PM CET, Markus Probst wrote:
> This is gated behind "if T::HAS_RECEIVE_INITIAL". And in probe its
> gated behind "if T::HAS_RECEIVE_INITIAL".
I guess you mean `if !T::HAS_RECEIVE_INITIAL` in probe().
Anyways, I now get what you are trying to do. (I got confused by late_probe(),
which I think is a misleading name for what it actually is and in which context
it might run in. I think a better name would be initial_xfer() or something
along those lines.)
So, what you really want is additional private data that is valid between some
inital xfer happening at some point of time after probe() and unbind(), and
hence is valid to access in all subsequent transfers callbacks.
There are three options:
(1) What you already implement, but with less callbacks.
I think the only additional callback you need is initial_xfer(), where you
return the init private data.
For storing this data you probably want to add void *init_data to
struct serdev_device.
(2) A synchronous inital transfer in probe() as proposed by Kari.
This is much simpler than (1), but still leaves the driver without an
Option for the init data in its device private data.
(3) Leave it to the driver.
The driver can store an Option in its device private data, which is
initialized in the first callback.
> Which one do you think should be used for the abstraction?
I don't know, it depends on the requirements of serdev drivers.
But since you already mentioned that there is only a single driver that needs
this initial xfer data, I'd say don't consider it in the abstraction at all
until we are sure it is a common pattern needed by drivers. We can always add it
later on if needed.
^ permalink raw reply
* Re: [PATCH v4 15/15] arm64: dts: microchip: add EV23X71A board
From: Robert Marko @ 2026-01-13 20:09 UTC (permalink / raw)
To: claudiu beznea
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
herbert, davem, vkoul, andi.shyti, lee, andrew+netdev, edumazet,
kuba, pabeni, linusw, Steen.Hegelund, daniel.machon,
UNGLinuxDriver, olivia, radu_nicolae.pirea, richard.genoud,
gregkh, jirislaby, broonie, lars.povlsen, devicetree,
linux-arm-kernel, linux-kernel, linux-crypto, dmaengine,
linux-i2c, netdev, linux-gpio, linux-spi, linux-serial, linux-usb,
luka.perkov
In-Reply-To: <858ca139-61c5-45e3-a2c9-d0af414e3592@tuxon.dev>
On Sun, Jan 11, 2026 at 3:42 PM claudiu beznea <claudiu.beznea@tuxon.dev> wrote:
>
> Hi, Robert,
>
> On 12/29/25 20:37, Robert Marko wrote:
> > Microchip EV23X71A is an LAN9696 based evaluation board.
> >
> > Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> > ---
> > Changes in v2:
> > * Split from SoC DTSI commit
> > * Apply DTS coding style
> > * Enclose array in i2c-mux
> > * Alphanumericaly sort nodes
> > * Change management port mode to RGMII-ID
> >
> > arch/arm64/boot/dts/microchip/Makefile | 1 +
> > .../boot/dts/microchip/lan9696-ev23x71a.dts | 757 ++++++++++++++++++
> > 2 files changed, 758 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
> >
> > diff --git a/arch/arm64/boot/dts/microchip/Makefile b/arch/arm64/boot/dts/microchip/Makefile
> > index c6e0313eea0f..09d16fc1ce9a 100644
> > --- a/arch/arm64/boot/dts/microchip/Makefile
> > +++ b/arch/arm64/boot/dts/microchip/Makefile
> > @@ -1,4 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_ARCH_LAN969X) += lan9696-ev23x71a.dtb
> > dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb125.dtb
> > dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb134.dtb sparx5_pcb134_emmc.dtb
> > dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb135.dtb sparx5_pcb135_emmc.dtb
> > diff --git a/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts b/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
> > new file mode 100644
> > index 000000000000..435df455b078
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
>
> [ ...]
>
> > +&gpio {
> > + emmc_sd_pins: emmc-sd-pins {
> > + /* eMMC_SD - CMD, CLK, D0, D1, D2, D3, D4, D5, D6, D7, RSTN */
> > + pins = "GPIO_14", "GPIO_15", "GPIO_16", "GPIO_17",
> > + "GPIO_18", "GPIO_19", "GPIO_20", "GPIO_21",
> > + "GPIO_22", "GPIO_23", "GPIO_24";
> > + function = "emmc_sd";
> > + };
> > +
> > + fan_pins: fan-pins {
> > + pins = "GPIO_25", "GPIO_26";
> > + function = "fan";
> > + };
> > +
> > + fc0_pins: fc0-pins {
> > + pins = "GPIO_3", "GPIO_4";
> > + function = "fc";
> > + };
> > +
> > + fc2_pins: fc2-pins {
> > + pins = "GPIO_64", "GPIO_65", "GPIO_66";
> > + function = "fc";
> > + };
> > +
> > + fc3_pins: fc3-pins {
> > + pins = "GPIO_55", "GPIO_56";
> > + function = "fc";
> > + };
> > +
> > + mdio_pins: mdio-pins {
> > + pins = "GPIO_9", "GPIO_10";
> > + function = "miim";
> > + };
> > +
> > + mdio_irq_pins: mdio-irq-pins {
> > + pins = "GPIO_11";
> > + function = "miim_irq";
> > + };
> > +
> > + sgpio_pins: sgpio-pins {
> > + /* SCK, D0, D1, LD */
> > + pins = "GPIO_5", "GPIO_6", "GPIO_7", "GPIO_8";
> > + function = "sgpio_a";
> > + };
> > +
> > + usb_ulpi_pins: usb-ulpi-pins {
> > + pins = "GPIO_30", "GPIO_31", "GPIO_32", "GPIO_33",
> > + "GPIO_34", "GPIO_35", "GPIO_36", "GPIO_37",
> > + "GPIO_38", "GPIO_39", "GPIO_40", "GPIO_41";
> > + function = "usb_ulpi";
> > + };
> > +
> > + usb_rst_pins: usb-rst-pins {
> > + pins = "GPIO_12";
> > + function = "usb2phy_rst";
> > + };
> > +
> > + usb_over_pins: usb-over-pins {
> > + pins = "GPIO_13";
> > + function = "usb_over_detect";
> > + };
> > +
> > + usb_power_pins: usb-power-pins {
> > + pins = "GPIO_1";
> > + function = "usb_power";
> > + };
> > +
> > + ptp_out_pins: ptp-out-pins {
> > + pins = "GPIO_58";
> > + function = "ptpsync_4";
> > + };
>
> Could you please move this one upper to have all the entries in the gpio
> container alphanumerically sorted?
>
> > +
> > + ptp_ext_pins: ptp-ext-pins {
> > + pins = "GPIO_59";
> > + function = "ptpsync_5";
> > + };
>
> Same here.
Sure, I will make sure that pin nodes are alphabetical (I found some
more that are not) in v5.
>
> [ ...]
>
> > + port29: port@29 {
> > + reg = <29>;
> > + phys = <&serdes 11>;
> > + phy-handle = <&phy3>;
> > + phy-mode = "rgmii-id";
> > + microchip,bandwidth = <1000>;
>
> There are some questions around this node from Andrew in v1 of this series,
> which I don't see an answer for in any of the following versions. Could you
> please clarify?
Sure, as for the RGMII I switched to rgmii-id so the PHY is adding the delays.
Though, I am not sure if its better to add them via MAC as it can add
the delays instead of the PHY,
so I am open to suggestions here.
As for the phys property, yes that is not required here as RGMII ports
are dedicated, there are no
SERDES lanes being used for them.
I have updated the bindings to account for this and it will be part of v5.
Regards,
Robert
>
> The rest looks good to me.
>
> Thank you,
> Claudiu
>
--
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr
^ permalink raw reply
* Re: [PATCH v4 00/11] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Conor Dooley @ 2026-01-13 22:17 UTC (permalink / raw)
To: Yixun Lan
Cc: Guodong Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Heinrich Schuchardt, Kevin Meng Zhang,
Andrew Jones, devicetree, linux-riscv, linux-kernel, spacemit,
linux-serial, Krzysztof Kozlowski, Heinrich Schuchardt,
Conor Dooley
In-Reply-To: <20260113002123-GYA19926@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]
On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> Hi Conor,
>
> On 21:45 Mon 12 Jan , Conor Dooley wrote:
> > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> >
> > > Hi, Conor
> > >
> > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > change in v4):
> > >
> > > 1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > > time, I will start another patchset which implements the strategy
> > > outlined by Conor in Link [2] and by Samuel in Link [3].
> >
> > Okay, that seems reasonable to separate out.
> >
> > >
> > > 2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > > 6 others. "sha" implies these extensions, and it should be allowed
> > > to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > >
> > > 3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > > - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > > - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > > - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > > The commit message of this patch is updated too, to better explain the
> > > relationship between "ziccamoa", "za64rs", "ziccrse" and "a".
> > >
> > > 4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > > dependency check in both directions, as discussed in [4]. Since "b"
> > > was ratified much later than its component extensions (zba/zbb/zbs),
> > > existing software and kernels expect these explicit strings. This
> > > bidirectional check ensures cores declaring "b" remain compatible
> > > with older software that only recognizes zba/zbb/zbs.
> >
> > This I asked about in the relevant patch, I would like to know what your
> > plan for adding the "b"s is.
> >
> ..
> > Spacemit folks, I assume you weren't planning on taking the
> > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > the question about b is answered.
>
> sure, please take extension stuff which are patches 6-9, for 1-5, it's
> all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT
Stuff for spacemit is either for you or for the relevant subsystem
maintainers. You're probably safe enough taking the
timer/interrupt-controller stuff if the maintainers don't apply it in a
reasonable period, it's not abnormal for those in particular to go via
the platform maintainer in my experience. Just be clear that you have
done so. I'm only interested in taking 6-9.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v4 00/11] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Conor Dooley @ 2026-01-13 22:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Guodong Xu
Cc: conor, Conor Dooley, Paul Walmsley, Heinrich Schuchardt,
Kevin Meng Zhang, Andrew Jones, devicetree, linux-riscv,
linux-kernel, spacemit, linux-serial, Krzysztof Kozlowski,
Heinrich Schuchardt
In-Reply-To: <20260110-k3-basic-dt-v4-0-d492f3a30ffa@riscstar.com>
From: Conor Dooley <conor.dooley@microchip.com>
On Sat, 10 Jan 2026 13:18:12 +0800, Guodong Xu wrote:
> This series introduces basic support for the SpacemiT K3 SoC and the
> K3 Pico-ITX evaluation board.
>
> This series (starting from v2) also adds descriptions about ISA extensions
> mandated by the RVA23 Profile Version 1.0 into riscv/extensions.yaml.
> There are extensive discussions about how to handle these new extensions
> in v2. In v3 (now v4), here is my best understading of what I think we have
> reached consensus on.
>
> [...]
Applied 6-9 to riscv-dt-for-next :)
[06/11] dt-bindings: riscv: Add B ISA extension description
https://git.kernel.org/conor/c/0cdb7fc1879b
[07/11] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm
https://git.kernel.org/conor/c/b321256a4f36
[08/11] dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl
https://git.kernel.org/conor/c/c712413333f8
[09/11] dt-bindings: riscv: Add Sha and its comprised extensions
https://git.kernel.org/conor/c/89febd6a0276
Thanks,
Conor.
^ permalink raw reply
* Re: [PATCH 00/19] printk cleanup - part 3
From: Marcos Paulo de Souza @ 2026-01-14 0:32 UTC (permalink / raw)
To: Daniel Thompson
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Breno Leitao, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Geert Uytterhoeven, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Andreas Larsson, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Jacky Huang, Shan-Chun Hung,
Laurentiu Tudor, linux-um, linux-kernel, kgdb-bugreport,
linux-serial, netdev, linux-m68k, linux-hardening, linuxppc-dev,
sparclinux, linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <a5d83903fe2d2c2eb21de1527007913ff00847c5.camel@suse.com>
On Tue, 2026-01-13 at 09:41 -0300, Marcos Paulo de Souza wrote:
> On Mon, 2026-01-05 at 14:08 +0000, Daniel Thompson wrote:
> > On Mon, Jan 05, 2026 at 12:52:14PM +0000, Daniel Thompson wrote:
> > > Hi Marcos
> > >
> > > On Sat, Dec 27, 2025 at 09:16:07AM -0300, Marcos Paulo de Souza
> > > wrote:
> > > > The parts 1 and 2 can be found here [1] and here[2].
> > > >
> > > > The changes proposed in this part 3 are mostly to clarify the
> > > > usage of
> > > > the interfaces for NBCON, and use the printk helpers more
> > > > broadly.
> > > > Besides it, it also introduces a new way to register consoles
> > > > and drop thes the CON_ENABLED flag. It seems too much, but in
> > > > reality
> > > > the changes are not complex, and as the title says, it's
> > > > basically a
> > > > cleanup without changing the functional changes.
> > >
> > > I ran this patchset through the kgdb test suite and I'm afraid it
> > > is
> > > reporting functional changes.
> > >
> > > Specifically the earlycon support for kdb has regressed (FWIW the
> > > problem bisects down to the final patch in the series where
> > > CON_ENABLED
> > > is removed).
> > >
> > > Reproduction on x86-64 KVM outside of the test suite should be
> > > easy:
> > >
> > > make defconfig
> > > scripts/config \
> > > --enable DEBUG_INFO \
> > > --enable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
> > > --enable DEBUG_FS \
> > > --enable KALLSYMS_ALL \
> > > --enable MAGIC_SYSRQ \
> > > --enable KGDB \
> > > --enable KGDB_TESTS \
> > > --enable KGDB_KDB \
> > > --enable KDB_KEYBOARD \
> > > --enable LKDTM \
> > > --enable SECURITY_LOCKDOWN_LSM
> > > make olddefconfig
> > > make -j$(nproc)
> > > qemu-system-x86_64 \
> > > -m 1G -smp 2 -nographic \
> > > -kernel arch/x86/boot/bzImage \
> > > -append "console=ttyS0,115200 kgdboc=ttyS0
> > > earlycon=uart8250,io,0x3f8 kgdboc_earlycon kgdbwait"
> >
> > Actually I realized there was a simpler reproduction (hinted at by
> > the
> > missing "printk: legacy bootconsole [uart8250] enabled" in the
> > regressed
> > case). It looks like the earlycon simply doesn't work and that
> > means
> > the
> > reproduction doesn't require anything related to kgdb at all.
> > Simply:
> >
> > make defconfig
> > make -j$(nproc)
> > qemu-system-x86_64 -m 1G -smp 2 -nographic -kernel
> > arch/x86/boot/bzImage \
> > -append "earlycon=uart8250,io,0x3f8"
> >
> > With the part 3 patchset applied I get no output from the earlycon
> > (without the patch set I get the early boot messages which, as
> > expected,
> > stop when tty0 comes up).
>
> Hi Daniel, sorry for the late reply! Lots of things to check lately
> :)
>
> Ok, I reproduced here, thanks a lot for testing kgdboc, it's a quick
> way to check that the new register_console_force is not working. Let
> me
> take a look to find what's wrong. Thanks a lot for finding this
> issue!
Ok, I did a bisect and found out that the issue lies in the last
commit, where CON_ENABLED was removed. After it, I then checked what
was wrong, since everything was being plumbed correctly (tm), and then
I found that it was not:
On _register_console, the function try_enable_default_console is called
when there are not registered consoles, and then it sets CON_ENABLED
for the console. Later on, try_enable_preferred_console it checks if
the console was specified by the user, and at the same time it had
CON_ENABLED set.
It worked by chance, but now, we don't have this flag anymore, and then
we are not _marking_ the console on try_enable_default_console so
try_enable_preferred_console returns ENOENT.
I have added logs for both cases first the case with the patchset
applied but the last one patch, and it works:
$ vng --append "console=ttyS0,115200 earlyprintk=ttyS0,115200
kgdboc=ttyS0 earlycon=uart8250,io,0x3f8 kgdboc_earlycon kgdbwait" --
verbose
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel (entry_offset: 0x000000000450d530).
XXX register_console earlyser
XXX try_enable_default_console earlyser enabled
XXX try_enable_preferred_console earlyser user_specified 1 returned -
ENOENT
XXX try_enable_preferred_console earlyser user_specified 0 returned 0
because flags was ENABLED
^^ here, returning 0 means that the console was accepted and will be
registered
XXX __register_console earlyser registered
XXX register_console uart
XXX try_enable_default_console uart enabled
XXX try_enable_preferred_console uart user_specified 1 returned -ENOENT
XXX try_enable_preferred_console uart user_specified 0 returned 0
because flags was ENABLED
XXX __register_console uart registered
^^^^ same here
Going to register kgdb with earlycon 'uart'
Entering kdb (current=0x0000000000000000, pid 0)
Now, the logs of the patchset with the last patch also applied:
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel (entry_offset: 0x000000000450d530).
XXX register_console earlyser
XXX try_enable_default_console earlyser enabled
XXX try_enable_preferred_console earlyser user_specified 1 returned -
ENOENT
XXX try_enable_preferred_console earlyser user_specified 0 returned -
ENOENT
XXX register_console uart
XXX try_enable_default_console uart enabled
XXX try_enable_preferred_console uart user_specified 1 returned -ENOENT
XXX try_enable_preferred_console uart user_specified 0 returned -ENOENT
^^^^ here, it should have registered the console
XXX console_setup hvc0
XXX __add_preferred_console hvc added, idx 0 i 0
XXX console_setup ttyS0,115200
XXX __add_preferred_console ttyS added, idx 0 i 1
Poking KASLR using RDRAND RDTSC...
XXX register_console tty
XXX try_enable_preferred_console tty user_specified 1 returned -ENOENT
XXX try_enable_preferred_console tty user_specified 0 returned -ENOENT
^^^ again, it fails because we don't flag the console with CON_ENABLED
as before.
XXX register_console hvc
XXX register_console ttyS
XXX try_enable_preferred_console ttyS user_specified 1 returned 0 with
user specified
XXX __register_console ttyS registered
[ 0.000000] Linux version 6.18.0+ (mpdesouza@daedalus) (clang
version 21.1.7, LLD 21.1.7) #374 SMP PREEMPT_RT Tue J
an 13 21:08:34 -03 2026 reserved
[ 0.000000] earlycon: uart8250 at I/O port 0x3f8 (options '')
[ 0.000000] kgdboc: No suitable earlycon yet, will try later
So, without any console kgdb is activated much later in the boot
process, as you found it.
I talked with Petr Mladek and it would need to rework the way that we
register a console, and he's already working on it. For now I believe
that we could take a look in all the patches besides the last one that
currently breaks the earlycon with kgdb and maybe other usecases.
Sorry for not catching this issue before. I'll use kgdb next time to
make sure that it keeps working :)
^ permalink raw reply
* Re: [PATCH v4 00/11] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Yixun Lan @ 2026-01-14 2:14 UTC (permalink / raw)
To: Conor Dooley, Paul Walmsley
Cc: Guodong Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Daniel Lezcano,
Thomas Gleixner, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Paul Walmsley,
Heinrich Schuchardt, Kevin Meng Zhang, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial,
Krzysztof Kozlowski, Heinrich Schuchardt, Conor Dooley
In-Reply-To: <20260113-swarm-mama-cbd7d0546578@spud>
On 22:17 Tue 13 Jan , Conor Dooley wrote:
> On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> > Hi Conor,
> >
> > On 21:45 Mon 12 Jan , Conor Dooley wrote:
> > > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> > >
> > > > Hi, Conor
> > > >
> > > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > > change in v4):
> > > >
> > > > 1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > > > time, I will start another patchset which implements the strategy
> > > > outlined by Conor in Link [2] and by Samuel in Link [3].
> > >
> > > Okay, that seems reasonable to separate out.
> > >
> > > >
> > > > 2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > > > 6 others. "sha" implies these extensions, and it should be allowed
> > > > to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > > >
> > > > 3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > > > - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > > > - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > > > - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > > > The commit message of this patch is updated too, to better explain the
> > > > relationship between "ziccamoa", "za64rs", "ziccrse" and "a".
> > > >
> > > > 4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > > > dependency check in both directions, as discussed in [4]. Since "b"
> > > > was ratified much later than its component extensions (zba/zbb/zbs),
> > > > existing software and kernels expect these explicit strings. This
> > > > bidirectional check ensures cores declaring "b" remain compatible
> > > > with older software that only recognizes zba/zbb/zbs.
> > >
> > > This I asked about in the relevant patch, I would like to know what your
> > > plan for adding the "b"s is.
> > >
> > ..
> > > Spacemit folks, I assume you weren't planning on taking the
> > > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > > the question about b is answered.
> >
> > sure, please take extension stuff which are patches 6-9, for 1-5, it's
> > all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> > I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT
>
> Stuff for spacemit is either for you or for the relevant subsystem
> maintainers. You're probably safe enough taking the
> timer/interrupt-controller stuff if the maintainers don't apply it in a
> reasonable period, it's not abnormal for those in particular to go via
> the platform maintainer in my experience. Just be clear that you have
> done so. I'm only interested in taking 6-9.
Hi Conor,
Ok, I got, thank you!
Hi Paul Walmsley,
I assume you're responsible for more general riscv stuff with your
effective maintainer hat, so do you mind if I take patches 1-5 via SpacemiT
SoC tree? I think the potential conflicts should be low and easy to fix.
Or, in the other hand, just let me know which patches you would like
to take, then I will handle the rest. Thanks
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Sui Jingfeng @ 2026-01-14 3:40 UTC (permalink / raw)
To: Andy Shevchenko, manivannan.sadhasivam
Cc: 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, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Bartosz Golaszewski,
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, linux-pci
In-Reply-To: <aWSpFk9z0zpyKjr6@smile.fi.intel.com>
On 2026/1/12 15:56, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>
>> Because the software node backend of the fwnode API framework lacks an
>> implementation for the .device_get_match_data function callback.
>
> Maybe this is done on purpose.
It is a *fact* that the broken swnode lacks an implementation for the
.device_get_match_data stub.
Otherwise, If it is really done *on purpose*, the maintainers of swnode
backend probably shall document it in the source file *explicitly*.
Have you thought about this aspect?
>
If it is sure thing, then it shouldn't start with "Maybe ..."
>> This makes it difficult to use(and/or test) a few drivers that originates
>> from DT world on the non-DT platform.
>
> How difficult?
The emphasis isn't on the 'difficult' word, it means 'inconvenience'
> DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?
Software node as an complement of ACPI, Therefore should do the same.
DT overlay introduce extra overhead/side effects on the non-DT systems.
Besides, DT overlay requires the OS distribution(such as ubuntu) has the
DT overlay config option selected.
>
>> Implement the .device_get_match_data fwnode callback, which helps to keep
>> the three backends of the fwnode API aligned as much as possible. This is
>> also a fundamental step to make a few drivers OF-independent truely
>> possible.
>>
>> Device drivers or platform setup codes are expected to provide a software
>> node string property, named as "compatible". At this moment, the value of
>> this string property is being used to match against the compatible entries
>> in the of_device_id table. It can be extended in the future though.
>
> I really do not want to see this patch
You can do that by dropping the maintainer-ship.
Your endless, bruth-force ranting on such a straight-forward thing
doesn't make much sense, because that waste everybody's time.
> without very good justification
Justifications has been provided over and over again.
> (note, there were at least two attempts in the past to add this stuff
This exactly saying that the implementation is missing.
> and no-one was merged,
That's the reason why you see it at least the second time.
have you studied those cases?).
>
The first one is not 100% correct.
^ permalink raw reply
* Re: [PATCH v2] serial:xilinx_uartps:fix rs485 delay_rts_after_send
From: Shubhrajyoti Datta @ 2026-01-14 4:38 UTC (permalink / raw)
To: j.turek
Cc: gregkh, jirislaby, michal.simek, namcao, tglx, zack.rusin,
sean.anderson, hshah, linux-serial, linux-arm-kernel,
linux-kernel
In-Reply-To: <20251221103221.1971125-1-jakub.turek@elsta.tech>
On Sun, Dec 21, 2025 at 4:03 PM j.turek <jakub.turek@elsta.tech> wrote:
>
> RTS line control with delay should be triggered when there is no more bytes
> in kfifo and hardware buffer is empty. Without this patch RTS control is
> scheduled right after feeding hardware buffer and this is too early.
> RTS line may change state before hardware buffer is empty.
> With this patch delayed RTS state change is triggered when function
> cdns_uart_handle_tx is called from cdns_uart_isr on CDNS_UART_IXR_TXEMPTY
> exactly when hardware completed transmission
>
> Signed-off-by: Jakub Turek <jakub.turek@elsta.tech>
>
> Fixes: fccc9d9233f9 ("tty: serial: uartps: Add rs485 support to uartps driver")
Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
^ permalink raw reply
* Re: [PATCH v4 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14 7:31 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-4-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:25:59AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Events Keypad binding to DT schema format.
> Move the file to the input directory to match the subsystem.
> Update the example node name to 'keypad' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 4/6] dt-bindings: power: supply: google,goldfish-battery: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14 7:31 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-5-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:26:00AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Battery binding to DT schema format.
> Move the file to the power/supply directory to match the subsystem.
> Update the example node name to 'battery' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 5/6] dt-bindings: sound: google,goldfish-audio: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-01-14 7:31 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, jserv, eleanor15x, dri-devel, devicetree,
linux-kernel, linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-6-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:26:01AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Audio binding to DT schema format.
> Move the file to the sound directory to match the subsystem.
> Update the example node name to 'sound' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> .../devicetree/bindings/goldfish/audio.txt | 17 ---------
> .../bindings/sound/google,goldfish-audio.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/goldfish/audio.txt
> create mode 100644 Documentation/devicetree/bindings/sound/google,goldfish-audio.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/19] printk cleanup - part 3
From: Petr Mladek @ 2026-01-14 8:20 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Daniel Thompson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <89409a0f48e6998ff6dd2245691b9954f0e1e435.camel@suse.com>
On Tue 2026-01-13 21:32:33, Marcos Paulo de Souza wrote:
> On Tue, 2026-01-13 at 09:41 -0300, Marcos Paulo de Souza wrote:
> > On Mon, 2026-01-05 at 14:08 +0000, Daniel Thompson wrote:
> > > On Mon, Jan 05, 2026 at 12:52:14PM +0000, Daniel Thompson wrote:
> > > > Hi Marcos
> > > >
> > > > On Sat, Dec 27, 2025 at 09:16:07AM -0300, Marcos Paulo de Souza
> > > > wrote:
> > > > > The parts 1 and 2 can be found here [1] and here[2].
> > > > >
> > > > > The changes proposed in this part 3 are mostly to clarify the
> > > > > usage of
> > > > > the interfaces for NBCON, and use the printk helpers more
> > > > > broadly.
> > > > > Besides it, it also introduces a new way to register consoles
> > > > > and drop thes the CON_ENABLED flag. It seems too much, but in
> > > > > reality
> > > > > the changes are not complex, and as the title says, it's
> > > > > basically a
> > > > > cleanup without changing the functional changes.
> > > >
> > > > I ran this patchset through the kgdb test suite and I'm afraid it
> > > > is
> > > > reporting functional changes.
> > > >
> > > > Specifically the earlycon support for kdb has regressed (FWIW the
> > > > problem bisects down to the final patch in the series where
> > > > CON_ENABLED
> > > > is removed).
> > > >
> > > > Reproduction on x86-64 KVM outside of the test suite should be
> > > > easy:
> > > >
> > > > make defconfig
> > > > scripts/config \
> > > > --enable DEBUG_INFO \
> > > > --enable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
> > > > --enable DEBUG_FS \
> > > > --enable KALLSYMS_ALL \
> > > > --enable MAGIC_SYSRQ \
> > > > --enable KGDB \
> > > > --enable KGDB_TESTS \
> > > > --enable KGDB_KDB \
> > > > --enable KDB_KEYBOARD \
> > > > --enable LKDTM \
> > > > --enable SECURITY_LOCKDOWN_LSM
> > > > make olddefconfig
> > > > make -j$(nproc)
> > > > qemu-system-x86_64 \
> > > > -m 1G -smp 2 -nographic \
> > > > -kernel arch/x86/boot/bzImage \
> > > > -append "console=ttyS0,115200 kgdboc=ttyS0
> > > > earlycon=uart8250,io,0x3f8 kgdboc_earlycon kgdbwait"
> > >
> > > Actually I realized there was a simpler reproduction (hinted at by
> > > the
> > > missing "printk: legacy bootconsole [uart8250] enabled" in the
> > > regressed
> > > case). It looks like the earlycon simply doesn't work and that
> > > means
> > > the
> > > reproduction doesn't require anything related to kgdb at all.
> > > Simply:
> > >
> > > make defconfig
> > > make -j$(nproc)
> > > qemu-system-x86_64 -m 1G -smp 2 -nographic -kernel
> > > arch/x86/boot/bzImage \
> > > -append "earlycon=uart8250,io,0x3f8"
> > >
> > > With the part 3 patchset applied I get no output from the earlycon
> > > (without the patch set I get the early boot messages which, as
> > > expected,
> > > stop when tty0 comes up).
> >
> > Hi Daniel, sorry for the late reply! Lots of things to check lately
> > :)
> >
> > Ok, I reproduced here, thanks a lot for testing kgdboc, it's a quick
> > way to check that the new register_console_force is not working. Let
> > me
> > take a look to find what's wrong. Thanks a lot for finding this
> > issue!
>
> Ok, I did a bisect and found out that the issue lies in the last
> commit, where CON_ENABLED was removed. After it, I then checked what
> was wrong, since everything was being plumbed correctly (tm), and then
> I found that it was not:
>
> On _register_console, the function try_enable_default_console is called
> when there are not registered consoles, and then it sets CON_ENABLED
> for the console. Later on, try_enable_preferred_console it checks if
> the console was specified by the user, and at the same time it had
> CON_ENABLED set.
>
> It worked by chance, but now, we don't have this flag anymore, and then
> we are not _marking_ the console on try_enable_default_console so
> try_enable_preferred_console returns ENOENT.
Great catch! Yeah, it worked just by chance.
> So, without any console kgdb is activated much later in the boot
> process, as you found it.
>
> I talked with Petr Mladek and it would need to rework the way that we
> register a console, and he's already working on it.
Yes, I have some patches in early stages of developnent of another
feature which would help here.
> For now I believe
> that we could take a look in all the patches besides the last one that
> currently breaks the earlycon with kgdb and maybe other usecases.
I agree. I am going to review this patchset first. Then I'll try to
clean up the patches which remove the ugly side effect from
try_enable_preferred_console(). Then we could discuss how
to move forward. It might make sense to push this patchset
first without the last patch...
> Sorry for not catching this issue before. I'll use kgdb next time to
> make sure that it keeps working :)
Do not worry at all. It was a well hidden catch. It is great that
Daniel found the regression in time...
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 03/19] printk: Drop flags argument from console_is_usable
From: Petr Mladek @ 2026-01-14 8:44 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-3-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:10, Marcos Paulo de Souza wrote:
> The flags argument was also used to check if CON_NBCON was set, but their
> usage was fixed in the last commit. All current users are reading the
> variable just to call console_is_usable.
>
> By calling console_srcu_read_flags inside console_is_usable makes the
> code cleaner and removes one argument from the function.
>
> Along with it, create a variant called __console_is_usable that can be
> used under console_list_lock(), like unregister_console_locked.
>
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -656,13 +656,8 @@ extern bool nbcon_kdb_try_acquire(struct console *con,
> struct nbcon_write_context *wctxt);
> extern void nbcon_kdb_release(struct nbcon_write_context *wctxt);
>
> -/*
> - * Check if the given console is currently capable and allowed to print
> - * records. Note that this function does not consider the current context,
> - * which can also play a role in deciding if @con can be used to print
> - * records.
> - */
> -static inline bool console_is_usable(struct console *con, short flags,
> +/* Variant of console_is_usable() when the console_list_lock is held. */
Nit: The comment is a bit misleading because this function is called
also from console_is_usable() under console_srcu_read_lock().
I would say something like:
/*
* The caller must ensure that @con can't disappear either by taking
* console_list_lock() or console_srcu_read_lock(). See also
* console_is_usable().
*/
> +static inline bool __console_is_usable(struct console *con, short flags,
> enum nbcon_write_cb nwc)
> {
> if (!(flags & CON_ENABLED))
> @@ -707,6 +702,18 @@ static inline bool console_is_usable(struct console *con, short flags,
> return true;
> }
>
> +/*
> + * Check if the given console is currently capable and allowed to print
> + * records. Note that this function does not consider the current context,
> + * which can also play a role in deciding if @con can be used to print
> + * records.
And I would add here something like:
*
* Context: Must be called under console_srcu_read_lock().
> + */
> +static inline bool console_is_usable(struct console *con,
> + enum nbcon_write_cb nwc)
> +{
> + return __console_is_usable(con, console_srcu_read_flags(con), nwc);
> +}
> +
> #else
> static inline void nbcon_cpu_emergency_enter(void) { }
> static inline void nbcon_cpu_emergency_exit(void) { }
Otherwise, it looks good. It is a nice clean up.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Herve Codina @ 2026-01-14 12:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: manivannan.sadhasivam, 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,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, 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, Bartosz Golaszewski, Sui Jingfeng
In-Reply-To: <aWSuYd8zqCxZ9DYE@smile.fi.intel.com>
Hi Andy, Manivannan,
On Mon, 12 Jan 2026 10:18:41 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> +Cc: Herve (btw, any news on LAN966x support?)
Related to LAN966x support, I am still stucked on issues related to
fw_devlink and DT overlays [1].
[1] https://lore.kernel.org/all/20260112154731.6540453b@bootlin.com/
>
> On Mon, Jan 12, 2026 at 10:04:24AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > Hi,
> > >
> > > This series is the continuation of the series [1] that added the initial support
> > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > connectors. These connectors are used to connect the Wireless Connectivity
> > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > interfaces are left for future improvements.
Related to describing a connector in DT. If DT overlays are involved to described
what is connected to this connector, some issues need to be fixed.
Those issues are related to referencing an external symbol from the overlay.
We, at Boolin, have been working on the topic
A talk (last year at ELC Europe) gives all details about the topic an related issue:
https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
https://www.youtube.com/watch?v=C8dEQ4OzMnc
Also a discussion took place after this talk:
https://lore.kernel.org/all/20250902105710.00512c6d@booty/
Recently, I also send a RFC series to DTC in order to move forward on this symbol
reverence topic. This series implements features emerged from the pointed out
discussion.
> > >
> > > Serdev device support for BT
> > > ============================
> > >
> > > Adding support for the PCIe interface was mostly straightforward and a lot
> > > similar to the previous Key M connector. But adding UART interface has proved to
> > > be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> > > unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> > > create the serdev device for UART/BT. This means the PCIe interface will be
> > > brought up first and after the PCIe device enumeration, the serdev device will
> > > be created by the pwrseq driver. This logic is necessary since the connector
> > > driver and DT node don't describe the device, but just the connector. So to make
> > > the connector interface Plug and Play, the connector driver uses the PCIe device
> > > ID to identify the card and creates the serdev device. This logic could be
> > > extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> > > interface for connecting WLAN, a SDIO notifier could be added to create the
> > > serdev device.
> > >
> > > Open questions
> > > ==============
> > >
> > > Though this series adds the relevant functionality for handling the M.2 Key M
> > > connectors, there are still a few open questions exists on the design.
> > >
> > > 1. I've used the DT compatible for the serdev swnode to match the existing OF
> > > device_id of the bluetooth driver. This avoids implementing custom serdev id
> > > matching as implemented till v2.
> >
> > Yeah, swnodes are not designed to replace the real DT or other firmware
> > interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> > fixing up the broken or missed FW device properties). This should not have been
> > done this way. Please, consider another approach, e.g. DT-overlay.
>
> This is what I have in mind when replied to you:
>
> https://lore.kernel.org/all/20251015071420.1173068-1-herve.codina@bootlin.com/
>
> > > 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> > > the PCIe device DT node to extract properties such as
> > > 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> > > add the PCIe DT node in the Root Port in conjunction with the Port node as
> > > below?
> > >
> > > pcie@0 {
> > > wifi@0 {
> > > compatible = "pci17cb,1103";
> > > ...
> > > qcom,calibration-variant = "LE_X13S";
> > > };
> > >
> > > port {
> > > pcie4_port0_ep: endpoint {
> > > remote-endpoint = <&m2_e_pcie_ep>;
> > > };
> > > };
> > > };
Using mechanisms used by the LAN966x, those wifi@0 and port nodes could be added by
a DT overlay by the PCI device driver handling the Qcom QCA6390 PCI device.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 04/19] printk: Reintroduce consoles_suspended global state
From: Petr Mladek @ 2026-01-14 13:12 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-4-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:11, Marcos Paulo de Souza wrote:
> This change partially reverts commit 9e70a5e109a4
> ("printk: Add per-console suspended state"). The intent of the original
> commit was to move the management of the console suspended state to the
> consoles themselves to be able to use SRCU instead of console lock.
>
> But having a global state is still useful when checking if the global
> suspend was triggered by power management. This way, instead of setting
> the state of each individual console, the code would only set/read from the
> global state.
>
> Along with this change, two more fixes are necessary: change
> console_{suspend,resume} to set/clear CON_SUSPEND instead of setting
> CON_ENABLED and change show_cons_active to call __console_is_usable to
> check console usefulness.
I would invert the logic a bit. I think that the main motivation
is to replace CON_ENABLE -> CON_SUSPEND.
<proposal>
The flag CON_ENABLE is cleared when serial drivers get suspended. This
"hack" has been added by the commit 33c0d1b0c3ebb6 ("[PATCH] Serial
driver stuff") back in v2.5.28.
Stop hijacking CON_ENABLE flag and use the CON_SUSPEND flag instead.
Still allow to distinguish when:
- the backing device is being suspended, see console_suspend().
- the power management wants to calm down all consoles using
a big-hammer, see console_suspend_all().
And restore the global "consoles_suspended" flag which was removed
by the commit 9e70a5e109a4 ("printk: Add per-console suspended state").
The difference is that accesses to the new global flag are
synchronized the same way as to the CON_SUSPEND flag. It allows
to read it under console_srcu_read_lock().
Finally, use __console_is_usable() in show_cons_active(). It is the
last location where the CON_ENABLED flag was checked directly.
The patch should not change the existing behavior because all users check
the state of the console using console_is_usable().
</proposal>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index e2d92cf70eb7..7d2bded75b75 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3552,9 +3552,9 @@ static ssize_t show_cons_active(struct device *dev,
> for_each_console(c) {
> if (!c->device)
> continue;
> - if (!(c->flags & CON_NBCON) && !c->write)
> - continue;
> - if ((c->flags & CON_ENABLED) == 0)
> + if (!__console_is_usable(c, c->flags,
> + consoles_suspended,
> + NBCON_USE_ANY))
It would be better to move this into a separate patch.
> continue;
> cs[i++] = c;
> if (i >= ARRAY_SIZE(cs))
Otherwise, it looks good.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 05/19] printk: Add more context to suspend/resume functions
From: Petr Mladek @ 2026-01-14 13:20 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-5-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:12, Marcos Paulo de Souza wrote:
> The new comments clarifies from where the functions are supposed to be
> called.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
The improved comments would have helped to understand the previous patch.
I would either merge it into the previous patch or switch the
ordering.
If this stays as a separate patch, feel free to use:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Hans de Goede @ 2026-01-14 14:01 UTC (permalink / raw)
To: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, 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
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
In-Reply-To: <20260112-pci-m2-e-v4-2-eff84d2c6d26@oss.qualcomm.com>
Hi Mani,
Thank you for your work in this.
On 12-Jan-26 17:26, Manivannan Sadhasivam via B4 Relay wrote:
> 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.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> drivers/tty/serdev/core.c | 16 ++++++++++++++++
> include/linux/serdev.h | 9 +++++++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index b33e708cb245..25382c2d63e6 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> }
> EXPORT_SYMBOL_GPL(serdev_controller_alloc);
>
> +/**
> + * 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.
> + */
> +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);
> +
This new of_find_serdev_controller_by_node() function needs:
#ifdef CONFIG_OF ... #endif
around it, to match the stubbing you are doing in serdev.h
> 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 ecde0ad3e248..db9bfaba0662 100644
> --- a/include/linux/serdev.h
> +++ b/include/linux/serdev.h
> @@ -333,4 +333,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
> +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> +{
> + return NULL;
> +}
stubs like this one should be static inline to avoid warnings like this one:
In file included from drivers/tty/serdev/core.c:21:
./include/linux/serdev.h:339:27: warning: no previous prototype for ‘of_find_serdev_controller_by_node’ [-Wmissing-prototypes]
339 | struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 06/19] printk: Introduce register_console_force
From: Petr Mladek @ 2026-01-14 14:22 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-6-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:13, Marcos Paulo de Souza wrote:
> The register_console_force function will register a console even if it
> wasn't specified on boot. The new function will act like all consoles
> being registered were using the CON_ENABLED flag.
I am a bit confused by the last sentence. It might be bacause I am not
a native speaker. I wonder if the following is more clear:
<proposal>
The register_console_force() function will register a console even if it
wasn't preferred via the command line, SPCR, or device tree. Currently,
certain drivers pre-set the CON_ENABLE flag to achieve this.
</proposal>
> The CON_ENABLED flag will be removed in the following patches and the
> drivers that use it will migrate to register_console_force instead.
>
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3858,7 +3858,7 @@ static int console_call_setup(struct console *newcon, char *options)
> * enabled such as netconsole
> */
> static int try_enable_preferred_console(struct console *newcon,
> - bool user_specified)
> + bool user_specified, bool force)
> {
> struct console_cmdline *c;
> int i, err;
> @@ -3896,12 +3896,15 @@ static int try_enable_preferred_console(struct console *newcon,
> return 0;
> }
>
> + if (force)
> + newcon->flags |= CON_ENABLED;
> +
This makes sense because the pre-enabled CON_ENABLED flag is handled
right below.
> /*
> * Some consoles, such as pstore and netconsole, can be enabled even
> * without matching. Accept the pre-enabled consoles only when match()
> * and setup() had a chance to be called.
> */
> - if (newcon->flags & CON_ENABLED && c->user_specified == user_specified)
> + if (newcon->flags & CON_ENABLED && c->user_specified == user_specified)
> return 0;
But this location was not a good idea in the first place. It hides an unexpected
side-effect into this function. It is easy to miss. A good example is
the regression caused by the last patch in this patch set, see
https://lore.kernel.org/all/89409a0f48e6998ff6dd2245691b9954f0e1e435.camel@suse.com/
I actually have a patch removing this side-effect:
From d24cd6b812967669900f9866f6202e8b0b65325a Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.com>
Date: Mon, 24 Nov 2025 17:34:25 +0100
Subject: [PATCH] printk/console: Do not rely on
try_enable_preferred_console() for pre-enabled consoles
try_enable_preferred_console() has non-obvious side effects. It returns
success for pre-enabled consoles.
Move the check for pre-enabled consoles to register_console(). It makes
the handling of pre-enabled consoles more obvious.
Also it will allow call try_enable_preferred_console() only when there
is an entry in preferred_consoles[] array. But it would need some more
changes.
It is part of the code clean up. It should not change the existing
behavior.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/printk/printk.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index abf1b93de056..d6b1d0a26217 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3826,14 +3826,6 @@ static int try_enable_preferred_console(struct console *newcon,
return 0;
}
- /*
- * Some consoles, such as pstore and netconsole, can be enabled even
- * without matching. Accept the pre-enabled consoles only when match()
- * and setup() had a chance to be called.
- */
- if (newcon->flags & CON_ENABLED && pc->user_specified == user_specified)
- return 0;
-
return -ENOENT;
}
@@ -4022,6 +4014,14 @@ void register_console(struct console *newcon)
if (err == -ENOENT)
err = try_enable_preferred_console(newcon, false);
+ /*
+ * Some consoles, such as pstore and netconsole, can be enabled even
+ * without matching. Accept them at this stage when they had a chance
+ * to match() and call setup().
+ */
+ if (err == -ENOENT && (newcon->flags & CON_ENABLED))
+ err = 0;
+
/* printk() messages are not printed to the Braille console. */
if (err || newcon->flags & CON_BRL) {
if (newcon->flags & CON_NBCON)
--
2.52.0
It would be better to do the above change 1st. Then the @force
parameter might be checked in __register_console() directly, like:
/*
* Some consoles, such as pstore and netconsole, can be enabled even
* without matching. Accept them at this stage when they had a chance
* to match() and call setup().
*/
if (err == -ENOENT && (force || newcon->flags & CON_ENABLED))
err = 0;
You might just remove the check of CON_ENABLED in the last patch.
I think that this should actually fix the regression. It will
handle also the case when the console was enabled by
try_enable_default_console() and try_enable_preferred_console()
returned -ENOENT.
Note: I have some more patches which clean up this mess. But they are
more complicated because of how the Braille console support
is wired. They still need some love. Anyway, the above patch should
be good enough for removing CON_ENABLED flag.
Best Regards,
Petr
^ permalink raw reply related
* printk's threaded legacy console + fbcon => schedule where it should not
From: Sebastian Andrzej Siewior @ 2026-01-14 14:59 UTC (permalink / raw)
To: linux-kernel, linux-serial, linux-fbdev
Cc: Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Greg Kroah-Hartman, Jiri Slaby, Simona Vetter, Helge Deller
Hi,
legacy_kthread_func() does console_lock() which means
console_may_schedule is 1.
The other path is from vprintk_emit() where we have
if (ft.legacy_direct) {
preempt_disable();
if (console_trylock_spinning())
console_unlock();
preempt_enable();
}
so all printing happens from console_unlock() where
console_may_schedule is 0. This is a small difference. With the legacy
console enabled I get:
| BUG: sleeping function called from invalid context at kernel/printk/printk.c:3377
| in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 15, name: pr/legacy
| preempt_count: 1, expected: 0
| RCU nest depth: 0, expected: 0
| 3 locks held by pr/legacy/15:
| #0: ffffffffa8aebac0 (console_lock){+.+.}-{0:0}, at: legacy_kthread_func+0x6c/0x130
| #1: ffffffffa8aebb18 (console_srcu){....}-{0:0}, at: console_flush_one_record+0x7e/0x4d0
| #2: ffffffffa8c49818 (printing_lock){+.+.}-{3:3}, at: vt_console_print+0x55/0x490
| Preemption disabled at:
| [<0000000000000000>] 0x0
| CPU: 7 UID: 0 PID: 15 Comm: pr/legacy Not tainted 6.19.0-rc5+ #19 PREEMPT(lazy)
| Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3-M, BIOS P2.30 06/29/2012
| Call Trace:
| <TASK>
| dump_stack_lvl+0x68/0x90
| __might_resched.cold+0xf0/0x12b
| console_conditional_schedule+0x27/0x30
| fbcon_redraw+0xa0/0x240
| fbcon_scroll+0x164/0x1c0
| con_scroll+0xfa/0x200
| lf+0xa5/0xb0
| vt_console_print+0x313/0x490
| console_flush_one_record+0x2a0/0x4d0
| legacy_kthread_func+0x83/0x130
| kthread+0x118/0x250
| ret_from_fork+0x309/0x3b0
| ret_from_fork_asm+0x1a/0x30
| </TASK>
because vt_console_print() acquires a spin_lock for synchronisation
against another caller while console_conditional_schedule() would like
to schedule.
Most callers of console_unlock() do trylock except for few such as
__pr_flush() which are affected by this the same way as the legacy
printing thread. But we don't have much pr_flush() so this is hidden.
Is there a strict need for fbcon_scroll() to schedule in fbcon_redraw()?
From a quick look it looks that intense callers such the printk flush do
cond_resched() on their own and tty does it, too
| fbcon_scroll+0x164/0x1c0
| con_scroll+0xfa/0x200
| lf+0xa5/0xb0
| do_con_write+0xc68/0x2630
| con_write+0xf/0x40
| do_output_char+0x180/0x1e0
| n_tty_write+0x1ba/0x580
| file_tty_write.isra.0+0x17e/0x2c0
the cond_resched() is in file_tty_write()/ iterate_tty_write().
Therefore I would suggest to simply
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba1..53daf7614b1af 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3236,7 +3236,6 @@ static int do_con_write(struct tty_struct *tty, const u8 *buf, int count)
goto rescan_last_byte;
}
con_flush(vc, &draw);
- console_conditional_schedule();
notify_update(vc);
return n;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 7be9e865325d9..36dd9d4a46ae0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1607,12 +1607,10 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
start = s;
}
}
- console_conditional_schedule();
s++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, dy, x);
- console_conditional_schedule();
dy++;
}
}
@@ -1648,14 +1646,12 @@ static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
par->bitops->bmove(vc, info, line + ycount, x, line, x, 1,
s - start);
- console_conditional_schedule();
if (ycount > 0)
line++;
else {
@@ -1703,13 +1699,11 @@ static void fbcon_redraw(struct vc_data *vc, int line, int count, int offset)
}
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, line, x);
- console_conditional_schedule();
if (offset > 0)
line++;
else {
diff --git a/include/linux/console.h b/include/linux/console.h
index fc9f5c5c1b04c..ec506d3501965 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -697,7 +697,6 @@ extern int unregister_console(struct console *);
extern void console_lock(void);
extern int console_trylock(void);
extern void console_unlock(void);
-extern void console_conditional_schedule(void);
extern void console_unblank(void);
extern void console_flush_on_panic(enum con_flush_mode mode);
extern struct tty_driver *console_device(int *);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1d765ad242b82..52b1fefdff4e0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3362,22 +3362,6 @@ void console_unlock(void)
}
EXPORT_SYMBOL(console_unlock);
-/**
- * console_conditional_schedule - yield the CPU if required
- *
- * If the console code is currently allowed to sleep, and
- * if this CPU should yield the CPU to another task, do
- * so here.
- *
- * Must be called within console_lock();.
- */
-void __sched console_conditional_schedule(void)
-{
- if (console_may_schedule)
- cond_resched();
-}
-EXPORT_SYMBOL(console_conditional_schedule);
-
void console_unblank(void)
{
bool found_unblank = false;
Sebastian
^ permalink raw reply related
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam @ 2026-01-14 15:57 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
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
In-Reply-To: <CAMRc=McDvQoqfH0Gy-wzbcEGvNCZACSACCcviwpCc4YNSpKYrw@mail.gmail.com>
On Tue, Jan 13, 2026 at 08:54:55AM -0500, Bartosz Golaszewski wrote:
> On Mon, 12 Jan 2026 17:26:01 +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.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > drivers/tty/serdev/core.c | 16 ++++++++++++++++
> > include/linux/serdev.h | 9 +++++++++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index b33e708cb245..25382c2d63e6 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> > }
> > EXPORT_SYMBOL_GPL(serdev_controller_alloc);
> >
> > +/**
> > + * 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.
> > + */
>
> Please also say that the caller is responsible for calling
> serdev_controller_put() on the returned object.
>
Ack.
- Mani
> Bart
>
> > +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);
> > +
> > 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 ecde0ad3e248..db9bfaba0662 100644
> > --- a/include/linux/serdev.h
> > +++ b/include/linux/serdev.h
> > @@ -333,4 +333,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
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + return NULL;
> > +}
> > +#endif /* CONFIG_OF */
> > +
> > #endif /*_LINUX_SERDEV_H */
> >
> > --
> > 2.48.1
> >
> >
> >
--
மணிவண்ணன் சதாசிவம்
^ 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