* Re: [PATCH v3 01/10] gpu: nova-core: convert PMC registers to kernel register macro
From: Danilo Krummrich @ 2026-03-23 11:21 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <20260323-b4-nova-register-v3-1-ae2486ecef1b@nvidia.com>
On Mon Mar 23, 2026 at 12:07 PM CET, Alexandre Courbot wrote:
> -impl TryFrom<u8> for Architecture {
> +impl TryFrom<Bounded<u32, 6>> for Architecture {
> type Error = Error;
>
> - fn try_from(value: u8) -> Result<Self> {
> - match value {
> + fn try_from(value: Bounded<u32, 6>) -> Result<Self> {
> + match u8::from(value) {
> 0x16 => Ok(Self::Turing),
> 0x17 => Ok(Self::Ampere),
> 0x19 => Ok(Self::Ada),
> @@ -155,23 +151,26 @@ fn try_from(value: u8) -> Result<Self> {
> }
> }
>
> -impl From<Architecture> for u8 {
> +impl From<Architecture> for Bounded<u32, 6> {
> fn from(value: Architecture) -> Self {
> - // CAST: `Architecture` is `repr(u8)`, so this cast is always lossless.
> - value as u8
> + match value {
> + Architecture::Turing => Bounded::<u32, _>::new::<0x16>(),
> + Architecture::Ampere => Bounded::<u32, _>::new::<0x17>(),
> + Architecture::Ada => Bounded::<u32, _>::new::<0x19>(),
> + }
> }
> }
Can this use bounded_enum!()?
^ permalink raw reply
* Re: [PATCH v3 07/10] gpu: nova-core: falcon: introduce `bounded_enum` macro
From: Danilo Krummrich @ 2026-03-23 11:22 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <20260323-b4-nova-register-v3-7-ae2486ecef1b@nvidia.com>
On Mon Mar 23, 2026 at 12:07 PM CET, Alexandre Courbot wrote:
> Introduce a powered-up version of our ad-hoc `impl_from_enum_to_u8`
> macro that allows the definition of an enum type associated to a
> `Bounded` of a given width, and provides the `From` and `TryFrom`
> implementations required to use that enum as a register field member.
>
> The next patch will make use of it to convert all falcon registers to
> the kernel register macro.
>
> The macro is unused in this patch: it is introduced ahead-of-time to
> avoid diff mingling in the next patch that would make it difficult to
> review.
>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpu/nova-core/falcon.rs | 82 +++++++++++++++++++++++++++++++++++++++++
Why does this live in falcon.rs?
^ permalink raw reply
* Re: [PATCH RFC v2 8/9] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Rodrigo Alencar @ 2026-03-23 11:36 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260322172257.1681de69@jic23-huawei>
On 26/03/22 05:22PM, Jonathan Cameron wrote:
> On Wed, 18 Mar 2026 17:56:08 +0000
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add ABI documentation file for the DDS AD9910 with sysfs entries to
> > control Parallel Port, Digital Ramp Generator, RAM and OSK parameters.
> >
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > ---
...
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_profile
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + Read/write the active profile index [0, 7] from/to the physical
> > + channel. The AD9910 supports 8 profiles, each storing a complete
> > + set of single tone (frequency, phase, amplitude) and RAM playback
> > + parameters.
>
> This one is interesting. Can we treat them as symbols that we are picking
> between? We have similar DAC ABIs for that already.
The profile concept comes from the datasheet and defines sets of configuration
for single tone and RAM control mode. I am not sure how we fit this idea into a
"symbol"
> Is this picking between them for purposes of configuration or setting which one is
> in being output currently?
Well, this is being used for configuration and activating, then, yes, you can only configure
an active profile, but I was not seeing that as an issue. I suppose that simplifies the
ABI a bit.
...
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_destination
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + Read/write the digital ramp generator (DRG) or the RAM control
> > + destination parameter. Determines which DDS core parameter is to
> > + be modulated when the child mode channel is enabled.
> > +
> > + Available values can be read from the corresponding
> > + out_altvoltageY_destination_available attribute.
> > +
> > + Valid values: "polar" (only for RAM control), "frequency", "phase"
> > + and "amplitude"
>
> This is very device specific. Maybe we are better representing these as separate
> channels each with their own controls for DRG. No problem if changing one changes
> another.
You mean removing this generic Y there? Indeed, there are separate configs for each one.
...
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_operating_mode
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + Read/write the DRG or RAM control operating mode. For the DRG
> > + channel it controls the no-dwell behavior of the ramp.
> > +
> > + Available values can be read from the corresponding
> > + out_altvoltageY_operating_mode_available attribute.
> > +
> > + Valid values for DRG channel:
> > +
> > + - "bidirectional": Normal ramp generation (ramp up then
> > + down, dwelling at limits).
>
> Some sort of trapezium wave? Maybe this and continuous forms are combined
> and we have a separate dwell time control?
Yes, sort of. Dwell control is made by an external pin (DRCTL), often controlled
by an FPGA to achieve certain required timings. I can say that software control
is not really recommended, unless only a one-shot ramp is necessary.
When adding the IIO backend support, extendend attributes will be added to
support control of dwell times.
>
> > + - "ramp_down": No-dwell low; the ramp resets to upper
> > + limit upon reaching the lower limit.
> > + - "ramp_up": No-dwell high; the ramp resets to lower
> > + limit upon reaching the upper limit.
> > + - "bidirectional_continuous": Both no-dwell high and low;
> > + the ramp continuously sweeps without dwelling.
>
> Triangle wave? bidirectional continuous is a rather confusing term so maybe
> we should rethink this one.
Mostly yes, but not only that. Sawtooth can be achieved as well by changing
the step sizes, also other weird patterns can be achieved by toggling DRCTL pin.
This mode is the most useful when one does not have an FPGA and want to save
resources on controlling the DRCTL pin. That mode name comes from the datasheet,
so I suppose it was fine.
> > +
> > + Valid values for RAM control channel:
> > +
> > + - "direct_switch": start address defines fixed word to be used
> > + by the selected profile.
> > + - "ramp_up": One-shot ramp up through current profile's address
> > + range.
> > + - "bidirectional": Ramp up then down through PROFILE0 pin.
>
> Avoid specifics like this. Can we call external control pin or something like that?
>
> > + - "bidirectional_continuous": Continuous ramp up/down
> > + through current profile's address range.
> > + - "ramp_up_continuous": Continuous ramp up through
> > + current profile's address range.
>
> I guess this goes back to start on finishing ramping up?
Yes, any dwell time should be considered when loading the "waveform" into the RAM
>
> > + - "sequenced": Sequenced playback of RAM profiles up to
> > + the active profile. Requires active profile > 0.
> Is this just running through each profile one after another? (other than profile 0)?
for this, this would be the actions:
- configure all desired profiles (0 up to X)
- Set the operating mode to sequenced (profile X would be active at this point)
- Enable RAM mode
When RAM mode is enabled, it would trigger the execution of profiles 0 up to X,
in sequence, according to the configured address range and sample rate for each profile.
When one profile ends the next starts until profile X finishes.
> > + - "sequenced_continuous": Continuous sequenced playback
> > + of RAM profiles up to the active profile. Requires
> > + active profile > 0.
> Similar to above, maybe separate out dwell time if that's the difference between
> sequenced and sequenced_continuous.
The difference here is that when Profile X finishes, Profile 0 starts again.
So the previous one is kind of an one-shot mode of multiple profiles in sequence
...
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH RFC v2 9/9] docs: iio: add documentation for ad9910 driver
From: Rodrigo Alencar @ 2026-03-23 11:58 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260322173434.23d2ee0d@jic23-huawei>
On 26/03/22 05:34PM, Jonathan Cameron wrote:
> On Wed, 18 Mar 2026 17:56:09 +0000
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add documentation for the AD9910 DDS IIO driver, which describes channels,
> > DDS modes, attributes and ABI usage examples.
> >
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
...
> > +Channel hierarchy
> > +=================
> > +
> > +The driver exposes the following IIO output channels, each identified by a
> > +unique channel number and a human-readable label:
> > +
> > +* ``out_altvoltage100``: ``phy``: Physical output: system clock and profile control
> > +
> > + * ``out_altvoltage110``: ``single_tone``: Single tone mode: per-profile
> > + frequency, phase, amplitude
> > +
> > + * ``out_altvoltage120``: ``parallel_port``: Parallel port modulation: enable
> > + and offset/scale parameters
> > +
> > + * ``out_altvoltage130``: ``digital_ramp_generator``: DRG control: enable,
> > + destination, operating mode
> > +
> > + * ``out_altvoltage131``: ``digital_ramp_up``: DRG ramp-up parameters:
> > + limits, step sizes, ramp rate
> > + * ``out_altvoltage132``: ``digital_ramp_down``: DRG ramp-down parameters:
> > + limits, step sizes, ramp rate
> > +
> > + * ``out_altvoltage140``: ``ram_control``: RAM playback: enable, destination,
> > + operating mode, address range
> > +
> > + * ``out_altvoltage150``: ``output_shift_keying``: OSK: enable, amplitude
> > + scale, ramp rate, auto/manual control
> > +
> > +The ``phy`` channel is the root of the hierarchy. Changing its
> > +``sampling_frequency`` reconfigures the system clock (SYSCLK) which affects all
> > +other channels. The ``profile`` attribute on this channel selects the active
> > +hardware profile (0-7) used by the single tone and RAM channels.
> I asked out this profile thing in one of the other patches. Key to me is
> that how we write non active profiles? The most similar thing we've seen
> in the past has been setting other frequencies for FSK or phases for PSK or
> more mundane DC DAC output that are symbol based. (often an external signal)
Yes, not allowing to configure a non-active profile at this point.
Initially was not seeing this as a problem, but would you think different
channels for each profiles should be created? e.g.:
- out_altvoltage111 ... out_altvoltage118 for single tone profiles; and
- out_altvoltage141 .. out_altvoltage148 for RAM profiles
That would not remove the need for something like the profile attribute.
> For those we have added an additional index so we can see which symbol we
> are changing parameters for. Here it might need to be done in the channel
> numbering. I'm not sure.
>
> > +
> > +All mode-specific channels (parallel port, DRG, RAM, OSK) have an ``enable``
> > +attribute. The DRG and RAM channels additionally have ``destination`` and
> > +``operating_mode`` attributes that configure which DDS core parameter is
> > +modulated and how.
>
> I wonder if we flatten things out and have separate channels for each type
> of modulation. Might lead to a more standard looking interfaces. We don't really
> have a standard path to control one type of thing feeding another, whereas
> we do have simple 'enable' interfaces.
...
> > +RAM mode
> > +--------
> > +
> > +The AD9910 contains a 1024 x 32-bit RAM that can be loaded with waveform data
> > +and played back to modulate frequency, phase, amplitude, or polar (phase +
> > +amplitude) parameters.
> > +
> > +RAM control channel attributes
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +.. flat-table::
> > + :header-rows: 1
> > +
> > + * - Attribute
> > + - Unit
> > + - Description
> > +
> > + * - ``out_altvoltage140_en``
> > + - boolean
> > + - Enable/disable RAM playback. Toggling swaps profile registers between
> > + single tone and RAM configurations across all 8 profiles.
...
> > + * - ``out_altvoltage140_address_start``
> Do we need this flexibility to set the start? We needed a length, but
> if we want different effective start can just load a different image.
There is one image being loaded into the entire RAM and each profile may choose
from wich sample it starts and ends its address ramp.
The profiles can have those address ranges to overlap or not, then I suppose
considering different images would just complicate things.
> > + - integer
> > + - Start address for the active profile. Range [0, 1023]. Cannot be
> > + changed while RAM mode is enabled. If set above current end address,
> > + end address is automatically adjusted.
> > +
...
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next v2 03/13] net: introduce ndo_set_rx_mode_async and dev_rx_mode_work
From: Loktionov, Aleksandr @ 2026-03-23 12:09 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, andrew+netdev@lunn.ch,
michael.chan@broadcom.com, pavan.chebbi@broadcom.com,
Nguyen, Anthony L, Kitszel, Przemyslaw, saeedm@nvidia.com,
tariqt@nvidia.com, mbloch@nvidia.com, alexanderduyck@fb.com,
kernel-team@meta.com, johannes@sipsolutions.net,
sd@queasysnail.net, jianbol@nvidia.com, dtatulea@nvidia.com,
mohsin.bashr@gmail.com, Keller, Jacob E, willemb@google.com,
skhawaja@google.com, bestswngs@gmail.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kselftest@vger.kernel.org,
leon@kernel.org
In-Reply-To: <20260318150305.123900-4-sdf@fomichev.me>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Stanislav Fomichev
> Sent: Wednesday, March 18, 2026 4:03 PM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; horms@kernel.org; corbet@lwn.net;
> skhan@linuxfoundation.org; andrew+netdev@lunn.ch;
> michael.chan@broadcom.com; pavan.chebbi@broadcom.com; Nguyen, Anthony
> L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; saeedm@nvidia.com; tariqt@nvidia.com;
> mbloch@nvidia.com; alexanderduyck@fb.com; kernel-team@meta.com;
> johannes@sipsolutions.net; sd@queasysnail.net; jianbol@nvidia.com;
> dtatulea@nvidia.com; sdf@fomichev.me; mohsin.bashr@gmail.com; Keller,
> Jacob E <jacob.e.keller@intel.com>; willemb@google.com;
> skhawaja@google.com; bestswngs@gmail.com; linux-doc@vger.kernel.org;
> linux-kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-
> rdma@vger.kernel.org; linux-wireless@vger.kernel.org; linux-
> kselftest@vger.kernel.org; leon@kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next v2 03/13] net: introduce
> ndo_set_rx_mode_async and dev_rx_mode_work
>
> Add ndo_set_rx_mode_async callback that drivers can implement instead
> of the legacy ndo_set_rx_mode. The legacy callback runs under the
> netif_addr_lock spinlock with BHs disabled, preventing drivers from
> sleeping. The async variant runs from a work queue with rtnl_lock and
> netdev_lock_ops held, in fully sleepable context.
>
> When __dev_set_rx_mode() sees ndo_set_rx_mode_async, it schedules
> dev_rx_mode_work instead of calling the driver inline. The work
> function takes two snapshots of each address list (uc/mc) under the
> addr_lock, then drops the lock and calls the driver with the work
> copies. After the driver returns, it reconciles the snapshots back to
> the real lists under the lock.
>
> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> ---
> Documentation/networking/netdevices.rst | 8 +++
> include/linux/netdevice.h | 20 ++++++
> net/core/dev.c | 94 +++++++++++++++++++++++-
> -
> 3 files changed, 115 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/networking/netdevices.rst
> b/Documentation/networking/netdevices.rst
> index 35704d115312..dc83d78d3b27 100644
> --- a/Documentation/networking/netdevices.rst
> +++ b/Documentation/networking/netdevices.rst
> @@ -289,6 +289,14 @@ struct net_device synchronization rules
> ndo_set_rx_mode:
> Synchronization: netif_addr_lock spinlock.
> Context: BHs disabled
...
>
> -/*
> - * Upload unicast and multicast address lists to device and
> - * configure RX filtering. When the device doesn't support unicast
> - * filtering it is put in promiscuous mode while unicast addresses
> - * are present.
> +static void dev_rx_mode_work(struct work_struct *work) {
> + struct net_device *dev = container_of(work, struct net_device,
> + rx_mode_work);
> + struct netdev_hw_addr_list uc_snap, mc_snap, uc_ref, mc_ref;
> + const struct net_device_ops *ops = dev->netdev_ops;
> + int err;
> +
> + __hw_addr_init(&uc_snap);
> + __hw_addr_init(&mc_snap);
> + __hw_addr_init(&uc_ref);
> + __hw_addr_init(&mc_ref);
> +
> + rtnl_lock();
> + netdev_lock_ops(dev);
> +
> + if (!netif_up_and_present(dev))
> + goto out;
> +
> + if (ops->ndo_set_rx_mode_async) {
> + netif_addr_lock_bh(dev);
> +
> + err = __hw_addr_list_snapshot(&uc_snap, &dev->uc,
> + dev->addr_len);
> + if (!err)
> + err = __hw_addr_list_snapshot(&uc_ref, &dev->uc,
> + dev->addr_len);
> + if (!err)
> + err = __hw_addr_list_snapshot(&mc_snap, &dev->mc,
> + dev->addr_len);
> + if (!err)
> + err = __hw_addr_list_snapshot(&mc_ref, &dev->mc,
> + dev->addr_len);
> + netif_addr_unlock_bh(dev);
> +
> + if (err) {
> + __hw_addr_flush(&uc_snap);
> + __hw_addr_flush(&uc_ref);
> + __hw_addr_flush(&mc_snap);
Shouldn't here go cleanup for symmetry?
__hw_addr_flush(&mc_ref);
> + goto out;
> + }
> +
> + ops->ndo_set_rx_mode_async(dev, &uc_snap, &mc_snap);
> +
> + netif_addr_lock_bh(dev);
> + __hw_addr_list_reconcile(&dev->uc, &uc_snap,
> + &uc_ref, dev->addr_len);
> + __hw_addr_list_reconcile(&dev->mc, &mc_snap,
> + &mc_ref, dev->addr_len);
> + netif_addr_unlock_bh(dev);
> + }
> +
> +out:
> + netdev_unlock_ops(dev);
> + rtnl_unlock();
> +}
...
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH V8 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: Jonathan Cameron @ 2026-03-23 12:12 UTC (permalink / raw)
To: John Groves
Cc: Miklos Szeredi, Dan Williams, Bernd Schubert, Alison Schofield,
John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Dave Jiang, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Darrick J . Wong,
Randy Dunlap, Jeff Layton, Amir Goldstein, Stefan Hajnoczi,
Joanne Koong, Josef Bacik, Bagas Sanjaya, Chen Linxuan,
James Morse, Fuad Tabba, Sean Christopherson, Shivank Garg,
Ackerley Tng, Gregory Price, Aravind Ramesh, Ajay Joshi,
venkataravis, linux-doc, linux-kernel, nvdimm, linux-cxl,
linux-fsdevel
In-Reply-To: <ab3nFoKxirEgoS_v@groves.net>
> > > diff --git a/drivers/dax/Makefile b/drivers/dax/Makefile
> > > index 5ed5c39857c8..3bae252fd1bf 100644
> > > --- a/drivers/dax/Makefile
> > > +++ b/drivers/dax/Makefile
> > > @@ -5,10 +5,16 @@ obj-$(CONFIG_DEV_DAX_KMEM) += kmem.o
> > > obj-$(CONFIG_DEV_DAX_PMEM) += dax_pmem.o
> > > obj-$(CONFIG_DEV_DAX_CXL) += dax_cxl.o
> > >
> > > +# fsdev_dax: fs-dax compatible devdax driver (needs DEV_DAX and FS_DAX)
> > > +ifeq ($(CONFIG_FS_DAX),y)
> > > +obj-$(CONFIG_DEV_DAX) += fsdev_dax.o
> > > +endif
> >
> > Why not throw in a new CONFIG_FSDAX_DEV and handle the dependencies
> > in Kconfig?
>
> At one point I had another config parameter, but I'm trying not to
> gratuitously add them. The fsdev driver is pretty small, and including it
> whenever FS_DAX is enabled felt reasonable to me. I'm willing to change it
> if there's a consensus that way.
You can make the build do exactly the same thing with a separate Kconfig
option. Just moves where the dependency tracking is. I'd prefer Kconfig
because that's generally where I'd look for something like this.
Jonathan
^ permalink raw reply
* Re: [PATCH v3 07/10] gpu: nova-core: falcon: introduce `bounded_enum` macro
From: Gary Guo @ 2026-03-23 12:43 UTC (permalink / raw)
To: Alexandre Courbot, Danilo Krummrich, Alice Ryhl, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross
Cc: John Hubbard, Alistair Popple, Joel Fernandes, Timur Tabi,
Zhi Wang, Eliot Courtney, dri-devel, linux-kernel, linux-riscv,
linux-doc, rust-for-linux
In-Reply-To: <20260323-b4-nova-register-v3-7-ae2486ecef1b@nvidia.com>
On Mon Mar 23, 2026 at 11:07 AM GMT, Alexandre Courbot wrote:
> Introduce a powered-up version of our ad-hoc `impl_from_enum_to_u8`
> macro that allows the definition of an enum type associated to a
> `Bounded` of a given width, and provides the `From` and `TryFrom`
> implementations required to use that enum as a register field member.
>
> The next patch will make use of it to convert all falcon registers to
> the kernel register macro.
>
> The macro is unused in this patch: it is introduced ahead-of-time to
> avoid diff mingling in the next patch that would make it difficult to
> review.
>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpu/nova-core/falcon.rs | 82 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
>
> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
> index 5a4f7fc85160..5221e4476f90 100644
> --- a/drivers/gpu/nova-core/falcon.rs
> +++ b/drivers/gpu/nova-core/falcon.rs
> @@ -54,6 +54,88 @@ fn from(value: $enum_type) -> Self {
> };
> }
>
> +/// Creates an enum type associated to a `Bounded`, with a `From` conversion to the associated
> +/// `Bounded` and either a `TryFrom` or `From` converting from the associated `Bounded`.
> +// TODO[FPRI]: This is a temporary solution to be replaced with the corresponding derive macros
> +// once they land.
> +#[expect(unused)]
> +macro_rules! bounded_enum {
> + (
> + $(#[doc = $enum_doc:expr])*
> + enum $enum_type:ident with $from_impl:ident<Bounded<$width:ty, $length:literal>> {
> + $( $(#[doc = $variant_doc:expr])* $variant:ident = $value:expr),* $(,)*
> + }
> + ) => {
> + $(#[doc = $enum_doc])*
> + #[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
> + pub(crate) enum $enum_type {
> + $(
> + $(#[doc = $variant_doc])*
> + $variant = $value
> + ),*
> + }
> +
> + impl From<$enum_type> for Bounded<$width, $length> {
> + fn from(value: $enum_type) -> Self {
> + match value {
> + $($enum_type::$variant => Bounded::<$width, _>::new::<$value>()),*
Hi Alex,
This looks exactly the same as the last version, without out the {} and MAX..
change made (which you mentioned in the cover letter).
Best,
Gary
> + }
> + }
> + }
> +
> + bounded_enum!(@impl_from $enum_type with $from_impl<Bounded<$width, $length>> {
> + $($variant = $value),*
> + });
> + };
> +
> + // `TryFrom` implementation from associated `Bounded` to enum type.
> + (@impl_from $enum_type:ident with TryFrom<Bounded<$width:ty, $length:literal>> {
> + $($variant:ident = $value:expr),* $(,)*
> + }) => {
> + impl TryFrom<Bounded<$width, $length>> for $enum_type {
> + type Error = Error;
> +
> + fn try_from(value: Bounded<$width, $length>) -> Result<Self> {
> + match value.get() {
> + $(
> + $value => Ok($enum_type::$variant),
> + )*
> + _ => Err(EINVAL),
> + }
> + }
> + }
> + };
> +
> + // `From` implementation from associated `Bounded` to enum type. Triggers a `build_error` if
> + // all possible values of the `Bounded` are not covered by the enum type.
> + (@impl_from $enum_type:ident with From<Bounded<$width:ty, $length:literal>> {
> + $($variant:ident = $value:expr),* $(,)*
> + }) => {
> + impl From<Bounded<$width, $length>> for $enum_type {
> + fn from(value: Bounded<$width, $length>) -> Self {
> + $(
> + // Ensure all enum values fit into the `Bounded` type.
> + const { assert!(
> + $value < (1 << $length),
> + "Enum variant doesn't fit into assigned `Bounded` type."
> + ); }
> + )*
> +
> + // Makes the compiler optimizer aware of the possible range of values.
> + let value = value.get() & ((1 << $length) - 1);
> + match value {
> + $(
> + $value => $enum_type::$variant,
> + )*
> + // We land here if the match didn't cover all possible values for the
> + // `Bounded`.
> + _ => build_error!("Enum doesn't cover all values of the `Bounded` type."),
> + }
> + }
> + }
> + }
> +}
> +
> /// Revision number of a falcon core, used in the [`crate::regs::NV_PFALCON_FALCON_HWCFG1`]
> /// register.
> #[repr(u8)]
^ permalink raw reply
* Re: [PATCH v13 05/12] dmaengine: qcom: bam_dma: add support for BAM locking
From: Bartosz Golaszewski @ 2026-03-23 13:36 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bartosz Golaszewski, Vinod Koul, Jonathan Corbet, Thara Gopinath,
Herbert Xu, David S. Miller, Udit Tiwari, Md Sadre Alam,
Dmitry Baryshkov, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, dmaengine, linux-doc,
linux-kernel, linux-arm-msm, linux-crypto, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <hohx2judes5c6na4svpah254hqbaf4kbeyu7prwkprfv5dy7hj@26nxwlvb76yp>
On Mon, Mar 23, 2026 at 10:35 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Tue, Mar 17, 2026 at 03:02:12PM +0100, Bartosz Golaszewski wrote:
> > Add support for BAM pipe locking. To that end: when starting DMA on an RX
> > channel - prepend the existing queue of issued descriptors with an
> > additional "dummy" command descriptor with the LOCK bit set. Once the
> > transaction is done (no more issued descriptors), issue one more dummy
> > descriptor with the UNLOCK bit.
>
> I've left some comments in v12, but looks like you've missed them.
Sorry for that, as I explained in private, this email did not end up
in my inbox and I didn't see it on lore.
> >
> > +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> > +{
> > + struct bam_chan *bchan = to_bam_chan(desc->chan);
> > + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> > + struct bam_desc_metadata *metadata = data;
> > +
> > + if (!data)
> > + return -EINVAL;
> > +
> > + if (!bdata->pipe_lock_supported)
> > + return -EOPNOTSUPP;
>
> As mentioned in v12, you should return 0 to avoid erroring out the clients if
> pipe lock is not supported.
>
If the client attaches the scratchpad register then it probably does
want to use locking, right? On the other hand, I assume you're
thinking about a situation where the client wants locking but BAM does
not support it. It's unlikely but ok, I'll change it.
> >
> > +static struct bam_async_desc *
> > +bam_make_lock_desc(struct bam_chan *bchan, struct scatterlist *sg,
> > + struct bam_cmd_element *ce, unsigned long flag)
> > +{
> > + struct dma_chan *chan = &bchan->vc.chan;
> > + struct bam_async_desc *async_desc;
> > + struct bam_desc_hw *desc;
> > + struct virt_dma_desc *vd;
> > + struct virt_dma_chan *vc;
> > + unsigned int mapped;
> > + dma_cookie_t cookie;
> > + int ret;
> > +
> > + sg_init_table(sg, 1);
> > +
> > + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
> > + if (!async_desc) {
> > + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
> > + return NULL;
> > + }
> > +
> > + async_desc->num_desc = 1;
> > + async_desc->curr_desc = async_desc->desc;
> > + async_desc->dir = DMA_MEM_TO_DEV;
> > +
> > + desc = async_desc->desc;
> > +
> > + bam_prep_ce_le32(ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
> > + sg_set_buf(sg, ce, sizeof(*ce));
> > +
> > + mapped = dma_map_sg_attrs(chan->slave, sg, 1, DMA_TO_DEVICE, DMA_PREP_CMD);
> > + if (!mapped) {
> > + kfree(async_desc);
> > + return NULL;
> > + }
> > +
> > + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
> > + desc->addr = sg_dma_address(sg);
> > + desc->size = sizeof(struct bam_cmd_element);
> > +
> > + vc = &bchan->vc;
> > + vd = &async_desc->vd;
> > +
> > + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
> > + vd->tx.flags = DMA_PREP_CMD;
> > + vd->tx.desc_free = vchan_tx_desc_free;
> > + vd->tx_result.result = DMA_TRANS_NOERROR;
> > + vd->tx_result.residue = 0;
> > +
> > + cookie = dma_cookie_assign(&vd->tx);
> > + ret = dma_submit_error(cookie);
> > + if (ret)
> > + return NULL;
>
> You are leaking async_desc here.
>
Yeah, not only that but also should unmap the sg here too. Thanks.
> > +
> > + return async_desc;
> > +}
> > +
> > +static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
> > +{
> > + struct bam_device *bdev = bchan->bdev;
> > + const struct bam_device_data *bdata = bdev->dev_data;
> > + struct bam_async_desc *lock_desc;
> > + struct bam_cmd_element *ce;
> > + struct scatterlist *sgl;
> > + unsigned long flag;
> > +
> > + lockdep_assert_held(&bchan->vc.lock);
> > +
> > + if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
> > + bchan->slave.direction != DMA_MEM_TO_DEV)
> > + return 0;
> > +
> > + if (lock) {
> > + sgl = &bchan->lock_sg;
> > + ce = &bchan->lock_ce;
> > + flag = DESC_FLAG_LOCK;
> > + } else {
> > + sgl = &bchan->unlock_sg;
> > + ce = &bchan->unlock_ce;
> > + flag = DESC_FLAG_UNLOCK;
> > + }
> > +
> > + lock_desc = bam_make_lock_desc(bchan, sgl, ce, flag);
> > + if (!lock_desc)
> > + return -ENOMEM;
> > +
> > + if (lock)
> > + list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > + else
> > + list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > +
> > + bchan->locked = lock;
>
> What is this flag for?
>
Just a leftover. I'll drop it, thanks.
> >
> > +struct bam_desc_metadata {
> > + phys_addr_t scratchpad_addr;
>
> I think it'd be worth adding a comment for this.
>
Will do.
Bart
^ permalink raw reply
* Re: [PATCH v13 05/12] dmaengine: qcom: bam_dma: add support for BAM locking
From: Manivannan Sadhasivam @ 2026-03-23 13:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Vinod Koul, Jonathan Corbet, Thara Gopinath,
Herbert Xu, David S. Miller, Udit Tiwari, Md Sadre Alam,
Dmitry Baryshkov, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, dmaengine, linux-doc,
linux-kernel, linux-arm-msm, linux-crypto, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <CAMRc=McostnmVjE=uV=2KA7-dqLvQ2BAJYTXzANacFpPGgS+Sw@mail.gmail.com>
On Mon, Mar 23, 2026 at 02:36:59PM +0100, Bartosz Golaszewski wrote:
> On Mon, Mar 23, 2026 at 10:35 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Tue, Mar 17, 2026 at 03:02:12PM +0100, Bartosz Golaszewski wrote:
> > > Add support for BAM pipe locking. To that end: when starting DMA on an RX
> > > channel - prepend the existing queue of issued descriptors with an
> > > additional "dummy" command descriptor with the LOCK bit set. Once the
> > > transaction is done (no more issued descriptors), issue one more dummy
> > > descriptor with the UNLOCK bit.
> >
> > I've left some comments in v12, but looks like you've missed them.
>
> Sorry for that, as I explained in private, this email did not end up
> in my inbox and I didn't see it on lore.
>
> > >
> > > +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> > > +{
> > > + struct bam_chan *bchan = to_bam_chan(desc->chan);
> > > + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> > > + struct bam_desc_metadata *metadata = data;
> > > +
> > > + if (!data)
> > > + return -EINVAL;
> > > +
> > > + if (!bdata->pipe_lock_supported)
> > > + return -EOPNOTSUPP;
> >
> > As mentioned in v12, you should return 0 to avoid erroring out the clients if
> > pipe lock is not supported.
> >
>
> If the client attaches the scratchpad register then it probably does
> want to use locking, right? On the other hand, I assume you're
> thinking about a situation where the client wants locking but BAM does
> not support it. It's unlikely but ok, I'll change it.
>
Locking is supported only since v1.4.0. So I was trying to avoid erroring out
the clients wanting to use DMA on older platforms (pre 1.4.0). I'm not sure if
such platforms exist, but could be possible.
- Mani
> > >
> > > +static struct bam_async_desc *
> > > +bam_make_lock_desc(struct bam_chan *bchan, struct scatterlist *sg,
> > > + struct bam_cmd_element *ce, unsigned long flag)
> > > +{
> > > + struct dma_chan *chan = &bchan->vc.chan;
> > > + struct bam_async_desc *async_desc;
> > > + struct bam_desc_hw *desc;
> > > + struct virt_dma_desc *vd;
> > > + struct virt_dma_chan *vc;
> > > + unsigned int mapped;
> > > + dma_cookie_t cookie;
> > > + int ret;
> > > +
> > > + sg_init_table(sg, 1);
> > > +
> > > + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
> > > + if (!async_desc) {
> > > + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
> > > + return NULL;
> > > + }
> > > +
> > > + async_desc->num_desc = 1;
> > > + async_desc->curr_desc = async_desc->desc;
> > > + async_desc->dir = DMA_MEM_TO_DEV;
> > > +
> > > + desc = async_desc->desc;
> > > +
> > > + bam_prep_ce_le32(ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
> > > + sg_set_buf(sg, ce, sizeof(*ce));
> > > +
> > > + mapped = dma_map_sg_attrs(chan->slave, sg, 1, DMA_TO_DEVICE, DMA_PREP_CMD);
> > > + if (!mapped) {
> > > + kfree(async_desc);
> > > + return NULL;
> > > + }
> > > +
> > > + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
> > > + desc->addr = sg_dma_address(sg);
> > > + desc->size = sizeof(struct bam_cmd_element);
> > > +
> > > + vc = &bchan->vc;
> > > + vd = &async_desc->vd;
> > > +
> > > + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
> > > + vd->tx.flags = DMA_PREP_CMD;
> > > + vd->tx.desc_free = vchan_tx_desc_free;
> > > + vd->tx_result.result = DMA_TRANS_NOERROR;
> > > + vd->tx_result.residue = 0;
> > > +
> > > + cookie = dma_cookie_assign(&vd->tx);
> > > + ret = dma_submit_error(cookie);
> > > + if (ret)
> > > + return NULL;
> >
> > You are leaking async_desc here.
> >
>
> Yeah, not only that but also should unmap the sg here too. Thanks.
>
> > > +
> > > + return async_desc;
> > > +}
> > > +
> > > +static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
> > > +{
> > > + struct bam_device *bdev = bchan->bdev;
> > > + const struct bam_device_data *bdata = bdev->dev_data;
> > > + struct bam_async_desc *lock_desc;
> > > + struct bam_cmd_element *ce;
> > > + struct scatterlist *sgl;
> > > + unsigned long flag;
> > > +
> > > + lockdep_assert_held(&bchan->vc.lock);
> > > +
> > > + if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
> > > + bchan->slave.direction != DMA_MEM_TO_DEV)
> > > + return 0;
> > > +
> > > + if (lock) {
> > > + sgl = &bchan->lock_sg;
> > > + ce = &bchan->lock_ce;
> > > + flag = DESC_FLAG_LOCK;
> > > + } else {
> > > + sgl = &bchan->unlock_sg;
> > > + ce = &bchan->unlock_ce;
> > > + flag = DESC_FLAG_UNLOCK;
> > > + }
> > > +
> > > + lock_desc = bam_make_lock_desc(bchan, sgl, ce, flag);
> > > + if (!lock_desc)
> > > + return -ENOMEM;
> > > +
> > > + if (lock)
> > > + list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > > + else
> > > + list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > > +
> > > + bchan->locked = lock;
> >
> > What is this flag for?
> >
>
> Just a leftover. I'll drop it, thanks.
>
> > >
> > > +struct bam_desc_metadata {
> > > + phys_addr_t scratchpad_addr;
> >
> > I think it'd be worth adding a comment for this.
> >
>
> Will do.
>
> Bart
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 0/1] docs: examples of pages affected by C API signature overflow
From: Jonathan Corbet @ 2026-03-23 13:42 UTC (permalink / raw)
To: Rito Rhymes, Rito Rhymes, linux-doc; +Cc: Shuah Khan, linux-kernel, rdunlap
In-Reply-To: <DHA2MFSL71FH.1Z930JBKI8AOE@ritovision.com>
"Rito Rhymes" <rito@ritovision.com> writes:
> Thank you for the feedback.
>
> I'll put some examples in the changelogs with versioned URLs and
> reroll them without a cover letter.
>
>> The cover letter tells reviewers what the series as a whole does
>
> Admittedly, I knew including a cover letter for a single patch was
> non-standard. Given the quantity of examples I aimed to include,
> I didn't think it acceptable to include it all in the changelog, but I
> knew having the examples was important for testing, so I repurposed the
> cover letter as the vehicle for including them. I'll lay off that.
If you want to include extra information for reviewers that doesn't
belong in the changelog, you can put it below the "---" line and it will
be stripped out at application time.
Thanks,
jon
^ permalink raw reply
* RE: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang @ 2026-03-23 13:51 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer,
arnaud.pouliquen@foss.st.com
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <20260313195801.2043306-4-shenwei.wang@nxp.com>
Hi Bjorn,
> -----Original Message-----
> From: Shenwei Wang
> Sent: Friday, March 13, 2026 2:59 PM
> To: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> Andersson <andersson@kernel.org>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; arnaud.pouliquen@foss.st.com
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Shenwei
> Wang <shenwei.wang@nxp.com>; Peng Fan <peng.fan@nxp.com>;
> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>; Andrew Lunn
> <andrew@lunn.ch>
> Subject: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver
>
Since I rewrote this version based on your earlier feedback
---
"My expectation is that it will be better to just have two separate
drivers - but reuse all the design-work done in the gpio-virtio."
---
I'd glad to hear what you think about this patch.
Thanks,
Shenwei
> On an AMP platform, the system may include two processors:
> - An MCU running an RTOS
> - An MPU running Linux
>
> These processors communicate via the RPMSG protocol.
> The driver implements the standard GPIO interface, allowing the Linux side to
> control GPIO controllers which reside in the remote processor via RPMSG
> protocol.
>
> Cc: Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
> drivers/gpio/Kconfig | 17 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rpmsg.c | 596 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 614 insertions(+)
> create mode 100644 drivers/gpio/gpio-rpmsg.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> b45fb799e36c..cff0fda8a283 100644
^ permalink raw reply
* Re: [PATCH v4 0/4] kallsyms: embed source file:line info in kernel stack traces
From: Sasha Levin @ 2026-03-23 14:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Masahiro Yamada, Luis Chamberlain, Linus Torvalds,
Richard Weinberger, Juergen Gross, Geert Uytterhoeven,
James Bottomley, Jonathan Corbet, Nathan Chancellor,
Nicolas Schier, Petr Pavlu, Daniel Gomez, Greg KH, Petr Mladek,
Steven Rostedt, Kees Cook, Peter Zijlstra, Thorsten Leemhuis,
Vlastimil Babka, Helge Deller, Randy Dunlap, Laurent Pinchart,
Vivian Wang, linux-kernel, linux-kbuild, linux-modules, linux-doc
In-Reply-To: <20260322093533.c0aab4ed9f5eef9536d14c21@linux-foundation.org>
On Sun, Mar 22, 2026 at 09:35:33AM -0700, Andrew Morton wrote:
>On Sun, 22 Mar 2026 09:15:39 -0400 Sasha Levin <sashal@kernel.org> wrote:
>
>> This series adds CONFIG_KALLSYMS_LINEINFO, which embeds source file:line
>> information directly in the kernel image so that stack traces annotate
>> every frame with the originating source location - no external tools, no
>> debug symbols at runtime, and safe to use in NMI/panic context.
>
>Sashiko review hasn't completed yet, but it has things to say:
> https://sashiko.dev/#/patchset/20260322131543.971079-1-sashal@kernel.org
Nice! I looked at the comments, and I don't think that there are any changes
required as a result of the review. It asked good questions, but the concerns
are mainly false positives.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3 01/10] gpu: nova-core: convert PMC registers to kernel register macro
From: Alexandre Courbot @ 2026-03-23 14:11 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DHA4EQAOO8QW.3AFGNJZFQX6N7@kernel.org>
On Mon Mar 23, 2026 at 8:21 PM JST, Danilo Krummrich wrote:
> On Mon Mar 23, 2026 at 12:07 PM CET, Alexandre Courbot wrote:
>> -impl TryFrom<u8> for Architecture {
>> +impl TryFrom<Bounded<u32, 6>> for Architecture {
>> type Error = Error;
>>
>> - fn try_from(value: u8) -> Result<Self> {
>> - match value {
>> + fn try_from(value: Bounded<u32, 6>) -> Result<Self> {
>> + match u8::from(value) {
>> 0x16 => Ok(Self::Turing),
>> 0x17 => Ok(Self::Ampere),
>> 0x19 => Ok(Self::Ada),
>> @@ -155,23 +151,26 @@ fn try_from(value: u8) -> Result<Self> {
>> }
>> }
>>
>> -impl From<Architecture> for u8 {
>> +impl From<Architecture> for Bounded<u32, 6> {
>> fn from(value: Architecture) -> Self {
>> - // CAST: `Architecture` is `repr(u8)`, so this cast is always lossless.
>> - value as u8
>> + match value {
>> + Architecture::Turing => Bounded::<u32, _>::new::<0x16>(),
>> + Architecture::Ampere => Bounded::<u32, _>::new::<0x17>(),
>> + Architecture::Ada => Bounded::<u32, _>::new::<0x19>(),
>> + }
>> }
>> }
>
> Can this use bounded_enum!()?
If we move it outside of `falcon.rs`, yes. I didn't want to make too
permanent a solution with the `TryFrom` macro being developed, but if
you prefer that way that's doable. I guess `bounded_enum` would need to
be in the root module though to be accessible by both `falcon` and
`gpu`.
^ permalink raw reply
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: Guenter Roeck @ 2026-03-23 14:15 UTC (permalink / raw)
To: Akshay Gupta, linux-kernel
Cc: corbet, skhan, arnd, gregkh, Prathima.Lk, naveenkrishna.chatradhi,
Anand.Umarji, linux-doc, linux-hwmon, kunyi
In-Reply-To: <20260323110811.2898997-2-Akshay.Gupta@amd.com>
On 3/23/26 04:08, Akshay Gupta wrote:
> From: Prathima <Prathima.Lk@amd.com>
>
> Move SBTSI core functionality out of the hwmon-only path and into
> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>
> This split prepares the driver for additional interfaces while keeping
> hwmon support as an optional layer on top of common SBTSI core logic.
>
This moves the driver out of hwmon space into misc/amd-sbi which,
in my opinion, is completely unnecessary to accomplish the stated goals.
I assume this is to be able to make changes which do not follow
the hwmon ABI and/or to bypass hwmon subsystem review, similar
to what has been done by others.
Obviously, I think this is a bad idea. I won't give it a NACK,
but I won't approve (nor review) it either.
Guenter
^ permalink raw reply
* Re: [PATCH v3 01/10] gpu: nova-core: convert PMC registers to kernel register macro
From: Danilo Krummrich @ 2026-03-23 14:21 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DHA81784G24U.1446CUTJC271J@nvidia.com>
On 3/23/26 3:11 PM, Alexandre Courbot wrote:
> On Mon Mar 23, 2026 at 8:21 PM JST, Danilo Krummrich wrote:
>> On Mon Mar 23, 2026 at 12:07 PM CET, Alexandre Courbot wrote:
>>> -impl TryFrom<u8> for Architecture {
>>> +impl TryFrom<Bounded<u32, 6>> for Architecture {
>>> type Error = Error;
>>>
>>> - fn try_from(value: u8) -> Result<Self> {
>>> - match value {
>>> + fn try_from(value: Bounded<u32, 6>) -> Result<Self> {
>>> + match u8::from(value) {
>>> 0x16 => Ok(Self::Turing),
>>> 0x17 => Ok(Self::Ampere),
>>> 0x19 => Ok(Self::Ada),
>>> @@ -155,23 +151,26 @@ fn try_from(value: u8) -> Result<Self> {
>>> }
>>> }
>>>
>>> -impl From<Architecture> for u8 {
>>> +impl From<Architecture> for Bounded<u32, 6> {
>>> fn from(value: Architecture) -> Self {
>>> - // CAST: `Architecture` is `repr(u8)`, so this cast is always lossless.
>>> - value as u8
>>> + match value {
>>> + Architecture::Turing => Bounded::<u32, _>::new::<0x16>(),
>>> + Architecture::Ampere => Bounded::<u32, _>::new::<0x17>(),
>>> + Architecture::Ada => Bounded::<u32, _>::new::<0x19>(),
>>> + }
>>> }
>>> }
>>
>> Can this use bounded_enum!()?
>
> If we move it outside of `falcon.rs`, yes. I didn't want to make too
> permanent a solution with the `TryFrom` macro being developed, but if
> you prefer that way that's doable. I guess `bounded_enum` would need to
> be in the root module though to be accessible by both `falcon` and
> `gpu`.
Since we are going to have it as an intermediate solution, let's be consistent
about it. Maybe num.rs is a good place?
^ permalink raw reply
* Re: [PATCH v3 07/10] gpu: nova-core: falcon: introduce `bounded_enum` macro
From: Alexandre Courbot @ 2026-03-23 14:22 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DHA65RY78M31.20BCCF00R67TH@garyguo.net>
On Mon Mar 23, 2026 at 9:43 PM JST, Gary Guo wrote:
> On Mon Mar 23, 2026 at 11:07 AM GMT, Alexandre Courbot wrote:
>> Introduce a powered-up version of our ad-hoc `impl_from_enum_to_u8`
>> macro that allows the definition of an enum type associated to a
>> `Bounded` of a given width, and provides the `From` and `TryFrom`
>> implementations required to use that enum as a register field member.
>>
>> The next patch will make use of it to convert all falcon registers to
>> the kernel register macro.
>>
>> The macro is unused in this patch: it is introduced ahead-of-time to
>> avoid diff mingling in the next patch that would make it difficult to
>> review.
>>
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/falcon.rs | 82 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 82 insertions(+)
>>
>> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
>> index 5a4f7fc85160..5221e4476f90 100644
>> --- a/drivers/gpu/nova-core/falcon.rs
>> +++ b/drivers/gpu/nova-core/falcon.rs
>> @@ -54,6 +54,88 @@ fn from(value: $enum_type) -> Self {
>> };
>> }
>>
>> +/// Creates an enum type associated to a `Bounded`, with a `From` conversion to the associated
>> +/// `Bounded` and either a `TryFrom` or `From` converting from the associated `Bounded`.
>> +// TODO[FPRI]: This is a temporary solution to be replaced with the corresponding derive macros
>> +// once they land.
>> +#[expect(unused)]
>> +macro_rules! bounded_enum {
>> + (
>> + $(#[doc = $enum_doc:expr])*
>> + enum $enum_type:ident with $from_impl:ident<Bounded<$width:ty, $length:literal>> {
>> + $( $(#[doc = $variant_doc:expr])* $variant:ident = $value:expr),* $(,)*
>> + }
>> + ) => {
>> + $(#[doc = $enum_doc])*
>> + #[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
>> + pub(crate) enum $enum_type {
>> + $(
>> + $(#[doc = $variant_doc])*
>> + $variant = $value
>> + ),*
>> + }
>> +
>> + impl From<$enum_type> for Bounded<$width, $length> {
>> + fn from(value: $enum_type) -> Self {
>> + match value {
>> + $($enum_type::$variant => Bounded::<$width, _>::new::<$value>()),*
>
> Hi Alex,
>
> This looks exactly the same as the last version, without out the {} and MAX..
> change made (which you mentioned in the cover letter).
I'm so sorry. I mistakenly squashed the fixup commit into the next
commit instead of this one. I will resend after hearing back from Danilo
about where the macro should reside.
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: hwmon: Document the LTC4283 Swap Controller
From: Guenter Roeck @ 2026-03-23 14:33 UTC (permalink / raw)
To: Nuno Sá, nuno.sa
Cc: linux-gpio, linux-hwmon, devicetree, linux-doc, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <77cd7e879a10df791d9d5eb1f16f1654e9904199.camel@gmail.com>
[ ...]
>>> + adi,pgio1-func:
>>> + description: Configures the function of the PGIO1 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_power_good, power_good, gpio]
>>> + default: inverted_power_good
>>> +
>>> + adi,pgio2-func:
>>> + description: Configures the function of the PGIO2 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_power_good, power_good, gpio, active_current_limiting]
>>> + default: inverted_power_good
>>> +
>>> + adi,pgio3-func:
>>> + description: Configures the function of the PGIO3 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_power_good_input, power_good_input, gpio]
>>> + default: inverted_power_good_input
>>> +
>>> + adi,pgio4-func:
>>> + description: Configures the function of the PGIO4 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_external_fault, external_fault, gpio]
>>> + default: inverted_external_fault
>>> +
>>> + adi,gpio-on-adio1:
>>> + description: If set, the ADIO1 pin is used as a GPIO.
>>> + type: boolean
>>> +
>>> + adi,gpio-on-adio2:
>>> + description: If set, the ADIO2 pin is used as a GPIO.
>>> + type: boolean
>>> +
>>> + adi,gpio-on-adio3:
>>> + description: If set, the ADIO3 pin is used as a GPIO.
>>> + type: boolean
>>> +
>>> + adi,gpio-on-adio4:
>>> + description: If set, the ADIO4 pin is used as a GPIO.
>>> + type: boolean
>>
>> Does this dependency block force a redundant specification of adi,pgio4-func?
>> The default for adi,pgio4-func is inverted_external_fault, which means the
>> default hardware state already supports external fault features.
>> If a device tree legitimately omits adi,pgio4-func to rely on that default,
>> will it fail schema validation here since the dependencies keyword strictly
>> checks for the literal presence of properties without injecting defaults?
>
> Fair point. I guess it will fail but the alternative is to not have any constrain at all so
> maybe worth it to be explicit in here?
>
I don't claim to understand how to define devicetree properties, but
adi,pgio4-func = <"gpio">
and
adi,gpio-on-adio4;
seem to be equivalent to me, and omitting the first property (because
it defaults to inverted_external_fault) would cause the second to fail.
So either both would be necessary or none. If that is correct, what is
the point of having the adi,gpio-on-adio4 property in the first place ?
In other words, what is the difference between
adi,pgio4-func = <"gpio">;
adi,gpio-on-adio4;
and
adi,pgio4-func = <"gpio">;
(with no boolean property) ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v7 03/10] x86/bhi: Rename clear_bhb_loop() to clear_bhb_loop_nofence()
From: Nikolay Borisov @ 2026-03-23 14:44 UTC (permalink / raw)
To: Pawan Gupta, x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-3-b76a777a98af@linux.intel.com>
On 19.03.26 г. 17:40 ч., Pawan Gupta wrote:
> To reflect the recent change that moved LFENCE to the caller side.
>
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Nit: I think having the _nofence in the function name is leaking an
implementation detail into the name/interface. I.e things change and we
decide that the implementation of a particular function must change so
we just do the change and substantiate it in the commit message or in a
comment. Especially that we don't have a "with an lfence" version.
What's more I'd consider this a "private" function, that's called via
the CLEAR_BRANCH_HISTORY macros, the only place it's called directly is
in the bpf jit code, but that's more of an exception.
Still,
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
<snip>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: watchdog: Drop SMARC-sAM67 support
From: Guenter Roeck @ 2026-03-23 14:45 UTC (permalink / raw)
To: Michael Walle, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Srinivas Kandagatla, Wim Van Sebroeck, Jonathan Corbet,
Shuah Khan
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-hwmon,
linux-watchdog, linux-doc, Conor Dooley
In-Reply-To: <DHA13HM1GIJW.1E7XCMY349JX7@kernel.org>
On 3/23/26 01:45, Michael Walle wrote:
> Hi,
>
> On Mon Mar 2, 2026 at 4:01 PM CET, Guenter Roeck wrote:
>> On 3/2/26 04:24, Michael Walle wrote:
>>> I was just informed that this product is discontinued (without being
>>> ever released to the market). Pull the plug and let's not waste any more
>>> maintainers time and revert commit 354f31e9d2a3 ("dt-bindings: watchdog:
>>> Add SMARC-sAM67 support").
>>>
>>> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Everything expect this patch was picked up. Guenter, do you want to
> take it, or should it go through the TI SoC queue?
>
> Thanks,
> -michael
I am fine with either approach. Wim handles all watchdog subsystem pull requests,
so we'll need his feedback.
Thanks,
Guenter
^ permalink raw reply
* Re: (subset) [PATCH v8 0/2] Add support for sound profile switching and leverage for OnePlus slider
From: Bjorn Andersson @ 2026-03-23 14:50 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Casey Connolly, Guido Günther, David Heidelberg
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, Casey Connolly
In-Reply-To: <20251113-op6-tri-state-v8-0-54073f3874bc@ixit.cz>
On Thu, 13 Nov 2025 17:02:57 +0100, David Heidelberg wrote:
> This series add initial support for OnePlus 6 and 6T, but other OnePlus
> phones contains same mechanism to switch sound profiles.
>
> This code was tested for two years within the downstream Snapdragon 845 tree.
> It is now perfectly integrated with feedbackd in the Phosh environment.
>
> The series is also available (until merged) at
> https://gitlab.com/sdm845/sdm845-next/-/commits/b4/op6-tri-state
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: sdm845-oneplus: Add alert-slider
commit: ca5adb26c5927f28016c6b1778622dee9ada5ca0
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE.
From: gutierrez.asier @ 2026-03-23 14:56 UTC (permalink / raw)
To: gutierrez.asier, artem.kuzin, stepanov.anatoly, wangkefeng.wang,
yanquanmin1, zuoze1, damon, sj, akpm, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, corbet, skhan, linux-doc, linux-mm,
linux-kernel
From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
working, since it relies on hugepage_madvise to add a new slot. This
slot should be picked up by khugepaged and eventually collapse (or
not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
enabled, khugepaged will not be working, and therefore no collapse
will happen.
DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
the address range synchronously.
This new action may be required to support autotuning with hugepage as
a goal[1].
[1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
---------
Benchmarks:
T n: THP never
T m: THP madvise
D h: DAMON action hugepage
D c: DAMON action collapse
+------------------+----------+----------+----------+
| | T n, D h | T m, D h | T n, D c |
+------------------+----------+----------+----------+
| Total memory use | 2.07 | 2.09 | 2.07 |
| Huge pages | 0 | 1.3 | 1.25 |
+------------------+----------+----------+----------+
Changes
---------
v1-v2:
Added benchmarks
Added damos_filter_type documentation for new action to fix kernel-doc
Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
Documentation/mm/damon/design.rst | 4 ++++
include/linux/damon.h | 2 ++
mm/damon/sysfs-schemes.c | 4 ++++
mm/damon/vaddr.c | 3 +++
tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
5 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 838b14d22519..405142641e55 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -467,6 +467,10 @@ that supports each action are as below.
Supported by ``vaddr`` and ``fvaddr`` operations set. When
TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
fail.
+ - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set. When
+ TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
+ fail.
- ``lru_prio``: Prioritize the region on its LRU lists.
Supported by ``paddr`` operations set.
- ``lru_deprio``: Deprioritize the region on its LRU lists.
diff --git a/include/linux/damon.h b/include/linux/damon.h
index d9a3babbafc1..6941113968ec 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -121,6 +121,7 @@ struct damon_target {
* @DAMOS_PAGEOUT: Reclaim the region.
* @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
* @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
+ * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
* @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
* @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
* @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
@@ -140,6 +141,7 @@ enum damos_action {
DAMOS_PAGEOUT,
DAMOS_HUGEPAGE,
DAMOS_NOHUGEPAGE,
+ DAMOS_COLLAPSE,
DAMOS_LRU_PRIO,
DAMOS_LRU_DEPRIO,
DAMOS_MIGRATE_HOT,
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 5186966dafb3..aa08a8f885fb 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
.action = DAMOS_NOHUGEPAGE,
.name = "nohugepage",
},
+ {
+ .action = DAMOS_COLLAPSE,
+ .name = "collapse",
+ },
{
.action = DAMOS_LRU_PRIO,
.name = "lru_prio",
diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
index b069dbc7e3d2..dd5f2d7027ac 100644
--- a/mm/damon/vaddr.c
+++ b/mm/damon/vaddr.c
@@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
case DAMOS_NOHUGEPAGE:
madv_action = MADV_NOHUGEPAGE;
break;
+ case DAMOS_COLLAPSE:
+ madv_action = MADV_COLLAPSE;
+ break;
case DAMOS_MIGRATE_HOT:
case DAMOS_MIGRATE_COLD:
return damos_va_migrate(t, r, scheme, sz_filter_passed);
diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
index 3aa5c91548a5..c6476e63f4fb 100755
--- a/tools/testing/selftests/damon/sysfs.py
+++ b/tools/testing/selftests/damon/sysfs.py
@@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
'pageout': 2,
'hugepage': 3,
'nohugeapge': 4,
- 'lru_prio': 5,
- 'lru_deprio': 6,
- 'migrate_hot': 7,
- 'migrate_cold': 8,
- 'stat': 9,
+ 'collapse': 5
+ 'lru_prio': 6,
+ 'lru_deprio': 7,
+ 'migrate_hot': 8,
+ 'migrate_cold': 9,
+ 'stat': 10,
}
assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
--
2.43.0
^ permalink raw reply related
* [RFC PATCH v2 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action
From: gutierrez.asier @ 2026-03-23 14:56 UTC (permalink / raw)
To: gutierrez.asier, artem.kuzin, stepanov.anatoly, wangkefeng.wang,
yanquanmin1, zuoze1, damon, sj, akpm, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, corbet, skhan, linux-doc, linux-mm,
linux-kernel
In-Reply-To: <20260323145646.4165053-1-gutierrez.asier@huawei-partners.com>
From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
This patch set introces a new action: DAMOS_COLLAPSE.
For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
working, since it relies on hugepage_madvise to add a new slot. This
slot should be picked up by khugepaged and eventually collapse (or
not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
enabled, khugepaged will not be working, and therefore no collapse
will happen.
DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
the address range synchronously.
This new action may be required to support autotuning with hugepage as
a goal[1].
[1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
---------
Benchmarks:
T n: THP never
T m: THP madvise
D h: DAMON action hugepage
D c: DAMON action collapse
+------------------+----------+----------+----------+
| | T n, D h | T m, D h | T n, D c |
+------------------+----------+----------+----------+
| Total memory use | 2.07 | 2.09 | 2.07 |
| Huge pages | 0 | 1.3 | 1.25 |
+------------------+----------+----------+----------+
Changes
---------
v1 -> v2:
Added benchmarks
Added damos_filter_type documentation for new action to fix kernel-doc
Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
Documentation/mm/damon/design.rst | 4 ++++
include/linux/damon.h | 2 ++
mm/damon/sysfs-schemes.c | 4 ++++
mm/damon/vaddr.c | 3 +++
tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
5 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 838b14d22519..405142641e55 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -467,6 +467,10 @@ that supports each action are as below.
Supported by ``vaddr`` and ``fvaddr`` operations set. When
TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
fail.
+ - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set. When
+ TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
+ fail.
- ``lru_prio``: Prioritize the region on its LRU lists.
Supported by ``paddr`` operations set.
- ``lru_deprio``: Deprioritize the region on its LRU lists.
diff --git a/include/linux/damon.h b/include/linux/damon.h
index d9a3babbafc1..6941113968ec 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -121,6 +121,7 @@ struct damon_target {
* @DAMOS_PAGEOUT: Reclaim the region.
* @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
* @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
+ * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
* @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
* @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
* @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
@@ -140,6 +141,7 @@ enum damos_action {
DAMOS_PAGEOUT,
DAMOS_HUGEPAGE,
DAMOS_NOHUGEPAGE,
+ DAMOS_COLLAPSE,
DAMOS_LRU_PRIO,
DAMOS_LRU_DEPRIO,
DAMOS_MIGRATE_HOT,
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 5186966dafb3..aa08a8f885fb 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
.action = DAMOS_NOHUGEPAGE,
.name = "nohugepage",
},
+ {
+ .action = DAMOS_COLLAPSE,
+ .name = "collapse",
+ },
{
.action = DAMOS_LRU_PRIO,
.name = "lru_prio",
diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
index b069dbc7e3d2..dd5f2d7027ac 100644
--- a/mm/damon/vaddr.c
+++ b/mm/damon/vaddr.c
@@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
case DAMOS_NOHUGEPAGE:
madv_action = MADV_NOHUGEPAGE;
break;
+ case DAMOS_COLLAPSE:
+ madv_action = MADV_COLLAPSE;
+ break;
case DAMOS_MIGRATE_HOT:
case DAMOS_MIGRATE_COLD:
return damos_va_migrate(t, r, scheme, sz_filter_passed);
diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
index 3aa5c91548a5..c6476e63f4fb 100755
--- a/tools/testing/selftests/damon/sysfs.py
+++ b/tools/testing/selftests/damon/sysfs.py
@@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
'pageout': 2,
'hugepage': 3,
'nohugeapge': 4,
- 'lru_prio': 5,
- 'lru_deprio': 6,
- 'migrate_hot': 7,
- 'migrate_cold': 8,
- 'stat': 9,
+ 'collapse': 5
+ 'lru_prio': 6,
+ 'lru_deprio': 7,
+ 'migrate_hot': 8,
+ 'migrate_cold': 9,
+ 'stat': 10,
}
assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 0/2] hwmon: Add support for MPS mp2985
From: Guenter Roeck @ 2026-03-23 15:08 UTC (permalink / raw)
To: wenswang, robh, krzk+dt, conor+dt, skhan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc
In-Reply-To: <20260323061901.827025-1-wenswang@yeah.net>
On 3/22/26 23:19, wenswang@yeah.net wrote:
> From: Wensheng Wang <wenswang@yeah.net>
>
> Add mp2985 driver in hwmon and add dt-bindings for it.
>
AI feedback is here:
https://sashiko.dev/#/patchset/20260323062104.827263-1-wenswang%40yeah.net
Couple of comments:
- If the mantissa overflow can not happen, please add a comment into the code
explaining the reason.
- EINVAL returns need to be explained. They should only be used
if the chip can not handle reading unsupported registers, and a comment
in the code needs to explain that.
- Ignore the concern about the chip being left on page 2 after an error
reading MFR_VR_MULTI_CONFIG_R[12] for now. It makes me wonder if
pmbus_init_common() should explicitly select page 0 for multi-page
chips.
- The alignment of
+ ret = i2c_smbus_read_word_data(client, page == 0 ?
+ MFR_VR_MULTI_CONFIG_R1 :
+ MFR_VR_MULTI_CONFIG_R2);
still seems odd. Why the large indentation ?
Thanks,
Guenter
^ permalink raw reply
* [PATCH v3] docs: allow inline literals in paragraphs to wrap to prevent overflow
From: Rito Rhymes @ 2026-03-23 15:14 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc; +Cc: Shuah Khan, linux-kernel, rdunlap, Rito Rhymes
In-Reply-To: <20260321141118.23828-1-rito@ritovision.com>
Some documentation pages contain long inline literals in paragraph
text that can force page-wide horizontal scroll overflow and break
layout on smaller screens.
Override the default `span.pre` white-space behavior for inline
literals and use `overflow-wrap: anywhere` so they can wrap when
needed. For code used as part of a paragraph, wrapping is appropriate
because it is stylistically part of the surrounding text. Code blocks,
by contrast, are meant to preserve formatting fidelity and are better
served by contained horizontal scrolling.
Examples:
https://docs.kernel.org/6.15/userspace-api/futex2.html
https://docs.kernel.org/6.15/security/IMA-templates.html
Signed-off-by: Rito Rhymes <rito@ritovision.com>
Assisted-by: Codex:GPT-5.4
---
v3: add latest public versioned URL examples to the patchlog
Documentation/sphinx-static/custom.css | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index db24f4344..dd69df2a7 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -149,6 +149,15 @@ div.language-selection ul li:hover {
background: #dddddd;
}
+/*
+ * Let long inline literals in paragraph text wrap as needed to prevent
+ * overflow.
+ */
+code.docutils.literal span.pre {
+ white-space: normal;
+ overflow-wrap: anywhere;
+}
+
/* Make xrefs more universally visible */
a.reference, a.reference:hover {
border-bottom: none;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v7 1/3] dt-bindings: hwmon: Document the LTC4283 Swap Controller
From: Nuno Sá @ 2026-03-23 15:17 UTC (permalink / raw)
To: Guenter Roeck, nuno.sa
Cc: linux-gpio, linux-hwmon, devicetree, linux-doc, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <453dbd6c-c68d-4977-8418-a898008b0fe7@roeck-us.net>
On Mon, 2026-03-23 at 07:33 -0700, Guenter Roeck wrote:
> [ ...]
> > > > + adi,pgio1-func:
> > > > + description: Configures the function of the PGIO1 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_power_good, power_good, gpio]
> > > > + default: inverted_power_good
> > > > +
> > > > + adi,pgio2-func:
> > > > + description: Configures the function of the PGIO2 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_power_good, power_good, gpio, active_current_limiting]
> > > > + default: inverted_power_good
> > > > +
> > > > + adi,pgio3-func:
> > > > + description: Configures the function of the PGIO3 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_power_good_input, power_good_input, gpio]
> > > > + default: inverted_power_good_input
> > > > +
> > > > + adi,pgio4-func:
> > > > + description: Configures the function of the PGIO4 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_external_fault, external_fault, gpio]
> > > > + default: inverted_external_fault
> > > > +
> > > > + adi,gpio-on-adio1:
> > > > + description: If set, the ADIO1 pin is used as a GPIO.
> > > > + type: boolean
> > > > +
> > > > + adi,gpio-on-adio2:
> > > > + description: If set, the ADIO2 pin is used as a GPIO.
> > > > + type: boolean
> > > > +
> > > > + adi,gpio-on-adio3:
> > > > + description: If set, the ADIO3 pin is used as a GPIO.
> > > > + type: boolean
> > > > +
> > > > + adi,gpio-on-adio4:
> > > > + description: If set, the ADIO4 pin is used as a GPIO.
> > > > + type: boolean
> > >
> > > Does this dependency block force a redundant specification of adi,pgio4-func?
> > > The default for adi,pgio4-func is inverted_external_fault, which means the
> > > default hardware state already supports external fault features.
> > > If a device tree legitimately omits adi,pgio4-func to rely on that default,
> > > will it fail schema validation here since the dependencies keyword strictly
> > > checks for the literal presence of properties without injecting defaults?
> >
> > Fair point. I guess it will fail but the alternative is to not have any constrain at all so
> > maybe worth it to be explicit in here?
> >
>
> I don't claim to understand how to define devicetree properties, but
>
> adi,pgio4-func = <"gpio">
>
> and
>
> adi,gpio-on-adio4;
>
> seem to be equivalent to me, and omitting the first property (because
Not exactly. ADIO4 and PGIO4 are different pins and can be both configured
as GPIOs. ADIO is a boolean because they are either monitored by the ADC (default)
or configured as GPIOs. PGIOs can have additional configurations and hence the
enum.
- Nuno Sá
> it defaults to inverted_external_fault) would cause the second to fail.
> So either both would be necessary or none. If that is correct, what is
> the point of having the adi,gpio-on-adio4 property in the first place ?
>
> In other words, what is the difference between
> adi,pgio4-func = <"gpio">;
> adi,gpio-on-adio4;
>
> and
> adi,pgio4-func = <"gpio">;
> (with no boolean property) ?
>
> Thanks,
> Guenter
^ 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