* [RFC PATCH v2 27/28] Docs/mm/damon/design: update for memcg damon filter
From: SeongJae Park @ 2026-05-12 14:36 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260512143645.113201-1-sj@kernel.org>
Update DAMON design document for the newly added belonging memory cgroup
attribute monitoring feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/design.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 887b45cbeb716..a24f9f00d1837 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -293,8 +293,8 @@ registration is made by specifying a probe per attribute. Each of the probe
specifies a rule to determine if a given memory region has the related
attribute. The rule is constructed with multiple filters. The filters work
same to :ref:`DAMOS filters <damon_design_damos_filters>` except the supported
-filter types. Currently only ``anon`` filter type is supported for data
-attributes monitoring.
+filter types. Currently only ``anon`` and ``memcg`` filter types are supported
+for data attributes monitoring.
If such probes are registered, DAMON executes the probes for each region's
sampling memory when it does the access :ref:`sampling
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2 21/28] Docs/admin-guide/mm/damon/usage: document data attributes monitoring
From: SeongJae Park @ 2026-05-12 14:36 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260512143645.113201-1-sj@kernel.org>
Update DAMON usage document for the newly added data attributes
monitoring feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 46 +++++++++++++++++---
Documentation/mm/damon/design.rst | 2 +
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 11c75a598393c..465bcdf89b182 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -72,6 +72,11 @@ comma (",").
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
│ │ │ │ │ │ nr_regions/min,max
+ │ │ │ │ │ │ :ref:`probes <damon_usage_sysfs_probes>`/nr_probes
+ │ │ │ │ │ │ │ 0/filters/nr_filters
+ │ │ │ │ │ │ │ │ │ 0/type,matching,allow
+ │ │ │ │ │ │ │ │ │ ...
+ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
│ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target,obsolete_target
│ │ │ │ │ │ │ :ref:`regions <sysfs_regions>`/nr_regions
@@ -97,7 +102,10 @@ comma (",").
│ │ │ │ │ │ │ │ 0/id,weight
│ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds,nr_snapshots,max_nr_snapshots
│ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions>`/total_bytes
- │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed
+ │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed,
+ │ │ │ │ │ │ │ │ │ probes
+ │ │ │ │ │ │ │ │ │ │ 0/hits
+ │ │ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ ...
@@ -227,8 +235,8 @@ contexts/<N>/monitoring_attrs/
Files for specifying attributes of the monitoring including required quality
and efficiency of the monitoring are in ``monitoring_attrs`` directory.
-Specifically, two directories, ``intervals`` and ``nr_regions`` exist in this
-directory.
+Specifically, two directories, ``intervals``, ``nr_regions`` and ``probes``
+exist in this directory.
Under ``intervals`` directory, three files for DAMON's sampling interval
(``sample_us``), aggregation interval (``aggr_us``), and update interval
@@ -262,6 +270,27 @@ tuning-applied current values of the two intervals can be read from the
``sample_us`` and ``aggr_us`` files after writing ``update_tuned_intervals`` to
the ``state`` file.
+.. _damon_usage_sysfs_probes:
+
+contexts/<N>/monitoring_attrs/probes/
+-------------------------------------
+
+A directory for registering :ref:`data attributes monitoring
+<damon_design_data_attrs_monitoring>` probes.
+
+In the beginning, this directory has only one file, ``nr_probes``. Writing a
+number (``N``) to the file creates the number of child directories named ``0``
+to ``N-1``. Each directory represents each monitoring probe.
+
+In each probe directory, one directory, ``filters`` exist. The directory
+contains files for installingt filters for the probe, that is used to determine
+the data attribute for the probe.
+
+In the beginning, ``filters`` directory has only one file, ``nr_filters``.
+Writing a number (``N``) to the file creates the number of child directories
+named ``0`` to ``N-1``. Each directory represents each filter and work in a
+way similar to that for :ref:`DAMOS filter <sysfs_filters>`.
+
.. _sysfs_targets:
contexts/<N>/targets/
@@ -614,10 +643,13 @@ set the ``access pattern`` as their interested pattern that they want to query.
tried_regions/<N>/
------------------
-In each region directory, you will find five files (``start``, ``end``,
-``nr_accesses``, ``age``, and ``sz_filter_passed``). Reading the files will
-show the properties of the region that corresponding DAMON-based operation
-scheme ``action`` has tried to be applied.
+In each region directory, you will find six files (``start``, ``end``,
+``nr_accesses``, ``age``, ``sz_filter_passed`` and ``probe_hits``). Reading
+the files will show the properties of the region that corresponding DAMON-based
+operation scheme ``action`` has tried to be applied.
+
+Reading ``probe_hists`` shows the number of data attributes monitoring
+probe-hit positive samples of the region.
Example
~~~~~~~
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 6731c3102d0ff..887b45cbeb716 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -276,6 +276,8 @@ interval``, DAMON checks if the region's size and access frequency
(``nr_accesses``) has significantly changed. If so, the counter is reset to
zero. Otherwise, the counter is increased.
+.. _damon_design_data_attrs_monitoring:
+
Data Attributes Monitoring
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v12 06/11] iio: test: iio-test-format: add test case for decimal format
From: Andy Shevchenko @ 2026-05-12 14:36 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260510-adf41513-iio-driver-v12-6-34af2ed2779f@analog.com>
On Sun, May 10, 2026 at 01:42:24PM +0100, Rodrigo Alencar via B4 Relay wrote:
> Add iio_test_iio_format_value_decimal_64() kunit test case for decimal
> value formatting, exploring different scales types. Also, the same
> iio_val_s64_array_populate() macro used to populate local array is used in
> iio_test_iio_format_value_integer_64().
...
> + iio_val_s64_array_populate(24, values);
You want to test this first...
I think the previous patch needs new test cases.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFC PATCH v2 20/28] Docs/mm/damon/design: document data attributes monitoring
From: SeongJae Park @ 2026-05-12 14:36 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260512143645.113201-1-sj@kernel.org>
Update DAMON design document for newly added data attributes monitoring
feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/design.rst | 37 +++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index fa7392b5a331d..6731c3102d0ff 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -276,6 +276,43 @@ interval``, DAMON checks if the region's size and access frequency
(``nr_accesses``) has significantly changed. If so, the counter is reset to
zero. Otherwise, the counter is increased.
+Data Attributes Monitoring
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Data access pattern is only one type of data attributes. In some use cases,
+users need to know more data attributes information. For example, users may
+need to know how much of a given hot or cold memory region is backed by
+anonymous pages, or belong to a specific cgroup. For such use case, data
+attributes monitoring feature is provided.
+
+Using the feature, users can register data attributes of their interest to the
+DAMON :ref:`context <damon_design_execution_model_and_data_structures>`. The
+registration is made by specifying a probe per attribute. Each of the probe
+specifies a rule to determine if a given memory region has the related
+attribute. The rule is constructed with multiple filters. The filters work
+same to :ref:`DAMOS filters <damon_design_damos_filters>` except the supported
+filter types. Currently only ``anon`` filter type is supported for data
+attributes monitoring.
+
+If such probes are registered, DAMON executes the probes for each region's
+sampling memory when it does the access :ref:`sampling
+<damon_design_region_based_sampling>`. The number of samples that identified
+as having the data attribute (hitting the probe) per :ref:`aggregation interval
+<damon_design_monitoring>` is accounted in a per-region per-probe counter.
+Users can therefore know how much of a given DAMON region has a specific data
+attribute by reading the per-region per-probe probe hits counter after each
+aggregation interval.
+
+This is a sampling based mechanism. Hence, it is lightweight but the output
+may include some measurement errors. The output should be used with good
+understanding of statistics.
+
+Another way to do this for higher accuracy is using :ref:`DAMOS filter
+<damon_design_damos_filters>` with ``stat`` :ref:`action
+<damon_design_damos_action>` and ``sz_ops_filter_passed`` :ref:`stat
+<damon_design_damos_stat>`. This approach provides the data attributes
+information in page level. But, because it is operated in page level, the
+overhead is proportional to the size of the memory.
Dynamic Target Space Updates Handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2 00/28] mm/damon: introduce data attributes monitoring
From: SeongJae Park @ 2026-05-12 14:36 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Masami Hiramatsu,
Mathieu Desnoyers, Michal Hocko, Mike Rapoport, Shuah Khan,
Shuah Khan, Steven Rostedt, Suren Baghdasaryan, Vlastimil Babka,
damon, linux-doc, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel
TL; DR
======
Extend DAMON for monitoring general data attributes other than accesses.
The short term motivation is lightweight page type (e.g., belonging
cgroup) aware monitoring. In long term, this will help extending DAMON
for multiple access events capture primitives (e.g., page faults and
PMU) and eventually pivotting DAMON to a "Data Attributes Monitoring and
Operations eNgine" in long term.
Background: High Cost of Page Level Properties Monitoring
=========================================================
DAMON is initially introduced as a Data Access MONitor. It has been
extended for not only access monitoring but also data access-aware
system operations (DAMOS). But still the monitoring part is only for
data accesses.
Data access patterns is good information, but some users need more
holistic views. Particularly, users want to show the access pattern
information together with the types of the memory. For example, users
who work for making huge pages efficiently want to know how much of
DAMON-found hot/cold regions are backed by huge pages. Users who run
multiple workloads with different cgroups want to know how much of
DAMON-found hot/cold regions belong to specific cgroups.
For the user demand, we developed a DAMOS extension for page level
properties based monitoring [1], which has landed on 6.14. Using the
feature, users can inform the page level data properties that they are
interested in, in a flexible format that uses DAMOS filters. Then,
DAMON applies the filters to each folio of the entire DAMON region and
lets users know how many bytes of memory in each DAMON region passed the
given filters.
This gives page level detailed and deterministic information to users.
But, because the operation is done at page level, the overhead is
proportional to the memory size. It was useful for test or debugging
purposes on a small number of machines. But it was obviously too heavy
to be enabled always on all machines running the real user workloads.
For real world workloads, it was recommended to use the feature with
user-space controlled sampling approaches. For example, users could do
the page level monitoring only once per hour, on randomly selected one
percent of machines of their fleet. If the runtime and the size of the
fleet is long and big enough, it should provide statistically meaningful
data.
But users are too busy to implement such controls on their own.
Data Attributes Monitoring
==========================
Extend DAMON to monitor not only data accesses, but also general data
attributes. Do the extension while keeping the main promise of DAMON,
the bounded and best-effort minimum overhead.
Allow users to specify what data attributes in addition to the data
access they want to monitor. Users can install one 'data probe' per
data attribute of their interest for this purpose. The 'data probe'
should be able to be applied to any memory, and determine if the given
memory has the appropriate data attribute. E.g., if memory of physical
address 42 belongs to cgroup A. Each 'data probe' is configured with
filters that are very similar to the DAMOS filters.
When DAMON checks if each sampling address memory of each region is
accessed since the last check, it applies data probes if registered.
Same to the number of access check-positive samples accounting
(nr_accesses), it accounts the number of each data probe-positive
samples in another per-region counters array, namely 'probe_hits'. When
DAMON resets nr_accesses every aggregation interval, it resets
'probe_hits' together.
Users can read 'probe_hits' just before the values are reset. In this
way, users can know how many hot/cold memory regions have data
attributes of their interest. E.g., 30 percent of this system's hot
memory is belonging to cgroup A, and 80 percent of the cgroup
A-belonging hot memory is backed by huge pages.
Patches Sequence
================
First eight patches implement the core feature, interface and the
working support. Patch 1 introduces data probe data structure, namely
damon_probe. Patch 2 extends damon_ctx for installing data probes.
Patch 3 introduces another data structure for filters of each data
probe, namely damon_filter. Patch 4 updates damon_ctx commit function
to handle the probes. Patch 5 extends damon_region for the per-region
per-probe positive samples counter, namely probe_hits. Patch 6 extends
damon_operations for applying probes on the underlying DAMON operations
implementation. Patch 7 updates kdamond_fn() to invoke the probes
applying callback. Patch 8 finally implements the probes support on
paddr ops.
Ten changes for user interface (patches 9-18) come next. Patches 9-13
implements sysfs directories and files for setting data probes, namely
probes directory, probe directory, filters directory, filter directory
and filter directory internal files, respectively. Patch 14 connects
the user inputs that are made via the sysfs files to DAMON core.
Following three patches (patches 15-17) implement sysfs directories and
files for showing the probe_hits to users, namely probes directory,
probe directory and hits files, respectively. Patch 18 introduces a new
tracepoint for showing the probe_hits via tracefs.
Patch 19 adds a selftest for the sysfs files.
Patches 20 and 21 documents the design and usage of the new feature,
respectively.
Seven additional patches (patches 22-28) for monitoring belonging memory
cgroup follow. Depending on the feedback, this part might be separated
to another series in future. Patch 22 defines the DAMON filter type for
the new attribute, namely DAMON_FILTER_TYPE_MEMCG. Patch 23 add the
support on paddr ops. Patch 24 updates the sysfs interface for setup of
the target memcg. Patch 25 move code for easy reuse of the filter
target memcg setup. Patch 26 connects the user input to the core layer.
Finally, patches 27 and 28 update the design and usage documents for the
memcg attribute monitoring support.
Discussions
===========
This allows the page properties monitoring with overhead that is low
enough to be enabled always on real world workloads. Because the
sampling time for access check is reused for data attributes check, the
upper-bounded and best-effort minimum overhead of DAMON is kept.
Because the sampling memory for access check is reused for data
attributes check, additional overhead is minimum.
Still DAMOS-based page level properties monitoring should be useful,
because it provides a deterministic page level information. When in
doubt of the sampling based information, running DAMOS-based one
together and comparing the results would be useful, for debugging and
tuning.
Plan for Dropping RFC tag
=========================
I'm considering renaming the tracepoint for exposing probe_hits
(damon_aggregated_v2).
Making changes for feedback from myself, humans and Sashiko should be
the major remaining work.
I'm currently hoping to drop the RFC tag by 7.2-rc1.
Future Works: Mid Term
========================
This version of implementation is limiting the maximum number of data
probes to four. I will try to find a way to remove the limit in future.
I personally think it should be enough for common use cases, though, and
therefore not giving high priority at the moment.
Future Works: Long Term
=======================
There are user requests for extending DAMON with detailed access
information, for example, per-CPUs/threads/read/writes monitoring. For
that, I was working [2] on extending DAMON to use page fault events as
another access check primitives, and making the infrastructure flexible
for future use of yet another access check primitive. Actually there is
another ongoing work [3] for extending DAMON with PMU events. The
motivation of the work is reducing the overhead, though.
In my work [2], I was introducing a new interface for access sampling
primitives control. Now I think this data probe interface can be used
for that, too. That is, data access becomes just one type of data
attribute. Also, pg_idle-confirmed access, page fault-confirmed access,
and PMU event-confirmed access will be different types of data
attributes.
The regions adjustment mechanism is currently working based on the
access information. That's because DAMON is designed for data access
monitoring. That is, data access information is the primary interest,
and therefore DAMON adjusts regions in a way that can best-present the
information.
Once data access becomes just one of data attributes, there is no reason
to think data access that special. There might be some users not
interested in access at all but want to know the location of memory of
specific type. Data probes interface will allow doing that. Further,
we could extend the interface to let users set any data attribute as the
'primary' attribute. Then, DAMON will split and merge regions in a way
that can best-present the 'primary' attributes.
DAMOS will also be extended, to specify targets based on not only the
data access pattern, but all user-registered data attributes. From this
stage, we may be able to call DAMON as a "Data Attributes Monitoring and
Operations eNgine".
[1] https://lore.kernel.org/20250106193401.109161-1-sj@kernel.org
[2] https://lore.kernel.org/20251208062943.68824-1-sj@kernel.org/
[3] https://lore.kernel.org/20260423004211.7037-1-akinobu.mita@gmail.com
Changes from RFC
- rfc: https://lore.kernel.org/all/20260426205222.93895-1-sj@kernel.org/
- Support memcg DAMON filter.
- Use per-probe probe_hits sysfs file.
- Use dynamic_array for probe_hits tracing.
- Fix filter matching field.
- Fix folio leaking in damon_pa_filter_pass().
- Move nr_regions of damon_aggregated_v2 tracepoint after end.
- Rename DAMON_TEST_TYPE_ANON to DAMON_FILTER_TYPE_ANON.
SeongJae Park (28):
mm/damon/core: introduce struct damon_probe
mm/damon/core: embed damon_probe objects in damon_ctx
mm/damon/core: introduce damon_filter
mm/damon/core: commit probes
mm/damon/core: introduce damon_region->probe_hits
mm/damon/core: introduce damon_ops->apply_probes
mm/damon/core: do data attributes monitoring
mm/damon/paddr: support data attributes monitoring
mm/damon/sysfs: implement probes dir
mm/damon/sysfs: implement probe dir
mm/damon/sysfs: implement filters directory
mm/damon/sysfs: implement filter dir
mm/damon/sysfs: implement filter dir files
mm/damon/sysfs: setup probes on DAMON core API parameters
mm/damon/sysfs-schemes: implement tried_regions/<r>/probes/
mm/damon/sysfs-schemes: implement probe dir
mm/damon/sysfs-schemes: implement probe/hits file
mm/damon: trace probe_hits
selftests/damon/sysfs.sh: test probes dir
Docs/mm/damon/design: document data attributes monitoring
Docs/admin-guide/mm/damon/usage: document data attributes monitoring
mm/damon/core: introduce DAMON_FILTER_TYPE_MEMCG
mm/damon/paddr: support DAMON_FILTER_TYPE_MEMCG
mm/damon/sysfs: add filters/<F>/path file
mm/damon/sysfs-schemes: move memcg_path_to_id() to sysfs-common
mm/damon/sysfs: setup damon_filter->memcg_id from path
Docs/mm/damon/design: update for memcg damon filter
Docs/admin-guide/mm/damon/usage: update for memcg damon filter
Documentation/admin-guide/mm/damon/usage.rst | 48 +-
Documentation/mm/damon/design.rst | 39 ++
include/linux/damon.h | 67 +++
include/trace/events/damon.h | 36 ++
mm/damon/core.c | 195 +++++++
mm/damon/paddr.c | 76 +++
mm/damon/sysfs-common.c | 41 ++
mm/damon/sysfs-common.h | 2 +
mm/damon/sysfs-schemes.c | 222 ++++++--
mm/damon/sysfs.c | 557 +++++++++++++++++++
tools/testing/selftests/damon/sysfs.sh | 48 ++
11 files changed, 1280 insertions(+), 51 deletions(-)
base-commit: 610724cfd93c1c413faf9e5bb63926fe54849887
--
2.47.3
^ permalink raw reply
* Re: [PATCH v12 05/11] iio: core: add decimal value formatting into 64-bit value
From: Andy Shevchenko @ 2026-05-12 14:35 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260510-adf41513-iio-driver-v12-5-34af2ed2779f@analog.com>
On Sun, May 10, 2026 at 01:42:23PM +0100, Rodrigo Alencar via B4 Relay wrote:
> Create new format types for iio values (IIO_VAL_DECIMAL64_*), which
> defines the representation of fixed decimal point values into a single
> 64-bit number. This new format increases the range of represented values,
> allowing for integer parts greater than 2^32, as bits are not "wasted"
> in the fractional part, which can be seen in IIO_VAL_INT_PLUS_MICRO and
> IIO_VAL_INT_PLUS_NANO. Helpers are created to compose and decompose 64-bit
> decimals into integer values used in IIO formatting interfaces, which
> creates consistency and avoid error-prone manual assignments when using
> wordpart macros. When doing the parsing, kstrtodec64() is used with the
> scale defined by the specific decimal format type.
...
> + case IIO_VAL_DECIMAL64_MILLI:
> + case IIO_VAL_DECIMAL64_MICRO:
> + case IIO_VAL_DECIMAL64_NANO:
> + case IIO_VAL_DECIMAL64_PICO:
> + {
> + s64 frac;
> + unsigned int scale = type - IIO_VAL_DECIMAL64_BASE;
Can we stick with reversed xmas tree order?
> + tmp2 = div64_s64_rem(iio_val_s64_from_array(vals),
> + int_pow(10, scale), &frac);
> + if (tmp2 == 0 && frac < 0)
> + return sysfs_emit_at(buf, offset, "-0.%0*lld", scale,
> + abs(frac));
> + else
> + return sysfs_emit_at(buf, offset, "%lld.%0*lld", tmp2,
> + scale, abs(frac));
> + }
What about
/* Print a leading '-' for negative fractions */
if (tmp2 == 0 && frac < 0)
offset += sysfs_emit_at(buf, offset, "-");
return sysfs_emit_at(buf, offset, "%lld.%0*lld", tmp2, scale, abs(frac));
Also note this won't work with the frac that are == S64_MIN. It's UB (undefined
behaviour), see the comment at abs() implementation. Maybe a time to add abs()
corner case tests...
...
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> - int ret, fract_mult = 100000;
> + int type, ret, fract_mult = 100000, dec_scale = 0;
I wouldn't mix ret here and put it...
> int integer, fract = 0;
> long long integer64;
> bool is_char = false;
...as standalone here
int ret;
...
> +#include <linux/wordpart.h>
+ blank line.
> #include <uapi/linux/iio/types.h>
...
> #define IIO_VAL_FRACTIONAL_LOG2 11
> #define IIO_VAL_CHAR 12
>
> +#define IIO_VAL_DECIMAL64_BASE 100
Okay, but I would rather see something smaller like 32 or 64.
...
> +static inline s64 iio_val_s64_compose(int val0, int val1)
Hmm... s64 composed form two int:s...
> +{
> + return (s64)(((u64)val1 << 32) | (u32)val0);
> +}
> +
> +static inline s64 iio_val_s64_from_array(const int *vals)
When I see 'array' in the name, I think of real array and some index. Here is
no index available. Perhaps
static inline s64 iio_val_s64_from_s32s(const s32 *vals)
> +{
> + return iio_val_s64_compose(vals[0], vals[1]);
> +}
> +
> +static inline void iio_val_s64_decompose(s64 dec64, int *val0, int *val1)
> +{
> + *val0 = lower_32_bits(dec64);
> + *val1 = upper_32_bits(dec64);
> +}
> +
> +static inline void iio_val_s64_array_populate(s64 dec64, int *vals)
_to_array() or _to_s32s()
> +{
> + iio_val_s64_decompose(dec64, &vals[0], &vals[1]);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/12] swap: remove the maxpages variable in sys_swapon
From: Hannes Reinecke @ 2026-05-12 14:19 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton, Chris Li, Kairui Song
Cc: Christian Brauner, Darrick J . Wong, Jens Axboe, David Sterba,
Theodore Ts'o, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Namjae Jeon, Hyunchul Lee, Steve French,
Paulo Alcantara, Carlos Maiolino, Damien Le Moal, Naohiro Aota,
linux-xfs, linux-fsdevel, linux-doc, linux-mm, linux-block,
linux-btrfs, linux-ext4, linux-f2fs-devel, linux-nfs, linux-cifs
In-Reply-To: <20260512053625.2950900-2-hch@lst.de>
On 5/12/26 07:35, Christoph Hellwig wrote:
> Always use si->max which is updated setup_swap_extents instead of copying
> into and out of maxpages.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> mm/swapfile.c | 27 +++++++++++----------------
> 1 file changed, 11 insertions(+), 16 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH v5 7/7] bus: mhi: Expose DDR training data via controller sysfs
From: Manivannan Sadhasivam @ 2026-05-12 14:19 UTC (permalink / raw)
To: Kishore Batta
Cc: Jonathan Corbet, Shuah Khan, Jeff Hugo, Carl Vanderlip,
Oded Gabbay, linux-doc, linux-kernel, linux-arm-msm, dri-devel,
mhi
In-Reply-To: <20260416-sahara_protocol_new_v2-v5-7-6aebf005e4ba@oss.qualcomm.com>
On Thu, Apr 16, 2026 at 07:39:48PM +0530, Kishore Batta wrote:
> DDR training data captured during Sahara command mode needs to be
> accessible to userspace so it can be persisted and reused on subsequent
> boots. Currently, the training data is stored internally in the driver
> but has no external visibility once the Sahara channel is torn down.
>
> Expose the captured DDR training data via a read-only binary sysfs
> attribute on the MHI controller device:
>
> /sys/bus/mhi/devices/<mhi_cntrl>/ddr_training_data
>
> The sysfs read callback serves data directly from controller scoped storage
> and protects access with the controller training data lock. The attribute
> lifetime is tied to the controller device via devres, allowing the data to
> remain readable after Sahara channel teardown and ensuring automatic
> cleanup when controller device is removed.
>
> Userspace flow:
> 1. For each controller device, userspace reads the ddr_training_data sysfs
> attribute.
> 2. If the read returns non-zero data, userspace persists it using a
> serial specific filename (for example, mdmddr_0x<serial_no>.mbn).
> 3. On subsequent boots, the Sahara driver attempts to load this serial
> specific DDR training image before falling back to the default
> training image, restoring DDR calibration data and avoiding retraining.
>
> Add ABI documentation for the DDR training data sysfs attribute exposed by
> Sahara MHI driver.
>
> Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-mhi-ddr_training_data | 19 ++++++
> drivers/bus/mhi/host/clients/sahara/sahara.c | 69 ++++++++++++++++++++++
> 2 files changed, 88 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data b/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data
> new file mode 100644
> index 0000000000000000000000000000000000000000..810b487b5a5fdba133d81255f9879844e3938a10
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data
> @@ -0,0 +1,19 @@
> +What: /sys/bus/mhi/devices/<mhi-cntrl>/ddr_training_data
> +
> +Date: March 2026
> +
> +Contact: Kishore Batta <kishore.batta@oss.qualcomm.com>
> +
> +Description: Contains the DDR training data for the Qualcomm device
> + connected. MHI driver populates different controller
> + nodes for each device. The DDR training data is exposed
> + to userspace to read and save the training data file to
> + the filesystem. In the subsequent boot up of the device,
> + the training data is restored from host to device
> + optimizing the boot up time of the device.
> +
> +Usage: Example for reading DDR training data:
> + cat /sys/bus/mhi/devices/mhi0/ddr_training_data
> +
> +Permissions: The file permissions are set to 0444 allowing read
> + access.
> diff --git a/drivers/bus/mhi/host/clients/sahara/sahara.c b/drivers/bus/mhi/host/clients/sahara/sahara.c
> index 07bc743aa061dd2fa85638067d494562152474e3..fef5dc1d8884133397d204f23361584fd1d9b075 100644
> --- a/drivers/bus/mhi/host/clients/sahara/sahara.c
> +++ b/drivers/bus/mhi/host/clients/sahara/sahara.c
> @@ -273,6 +273,73 @@ static struct sahara_cntrl_training_data *sahara_cntrl_training_get(struct devic
> return ct;
> }
>
> +static ssize_t ddr_training_data_read(struct file *filp, struct kobject *kobj,
> + const struct bin_attribute *attr, char *buf,
> + loff_t offset, size_t count)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct sahara_cntrl_training_data *ct;
> + size_t available;
> +
> + ct = sahara_cntrl_training_get(dev);
> + if (!ct)
> + return -ENODEV;
> +
> + mutex_lock(&ct->lock);
> +
> + /* No data yet or offset past end */
> + if (!ct->data || offset >= ct->size) {
> + mutex_unlock(&ct->lock);
> + return 0;
> + }
> +
> + available = ct->size - offset;
> + count = min(count, available);
> + memcpy(buf, (u8 *)ct->data + offset, count);
> +
> + mutex_unlock(&ct->lock);
> +
> + return count;
> +}
> +
> +static const struct bin_attribute ddr_training_data_attr = {
> + .attr = {
> + .name = "ddr_training_data",
> + .mode = 0444,
> + },
> + .read = ddr_training_data_read,
> +};
You can simplify the attribute creation with BIN_ATTR_RO().
> +
> +static void sahara_sysfs_devres_release(struct device *dev, void *res)
> +{
> + device_remove_bin_file(dev, &ddr_training_data_attr);
> +}
> +
> +static void sahara_sysfs_create(struct mhi_device *mhi_dev)
> +{
> + struct device *dev = &mhi_dev->mhi_cntrl->mhi_dev->dev;
> + void *cookie;
> + int ret;
> +
> + if (devres_find(dev, sahara_sysfs_devres_release, NULL, NULL))
> + return;
So you are expecting this helper to be called mutiple times without teardown?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v12 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64()
From: Rodrigo Alencar @ 2026-05-12 14:12 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: Jonathan Cameron, Rodrigo Alencar via B4 Relay, rodrigo.alencar,
linux-kernel, linux-iio, devicetree, linux-doc, David Lechner,
Andy Shevchenko, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Andrew Morton, Petr Mladek, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan, David Laight
In-Reply-To: <agMvlS3-0wvGmBwh@ashevche-desk.local>
On 26/05/12 04:48PM, Andy Shevchenko wrote:
> On Tue, May 12, 2026 at 02:21:14PM +0100, Rodrigo Alencar wrote:
> > On 26/05/12 04:12PM, Andy Shevchenko wrote:
> > > On Tue, May 12, 2026 at 12:39:53PM +0100, Jonathan Cameron wrote:
> > > > On Sun, 10 May 2026 13:42:20 +0100
> > > > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> > > >
> > > > > Add helpers that parses decimal numbers into 64-bit number, i.e., decimal
> > > > > point numbers with pre-defined scale are parsed into a 64-bit value (fixed
> > > > > precision). After the decimal point, digits beyond the specified scale
> > > > > are ignored.
> > > >
> > > > Whilst Rodrigo has already replied to say there will be another version
> > > > I'd like to request final feedback from those who were involved in the parser
> > > > discussions.
> > > >
> > > > They got very involved and I'm far from an expert in the right way to do
> > > > this stuff.
> > > >
> > > > I don't think David Laight was +CC so I've added that.
> > > > David, Andy - I think you two were most involved in that discussion:
> > > > Any objections to the end result?
> > >
> > > I already said a few times about the naming. I do not like the kstrto*()
> > > be semantically different on how they treat the input. Second point is
> > > to avoid code duplication, but this one is less of a concern since the
> > > new code is in the library close to the other potentially duplicate code
> > > piece and hence can be addressed later.
> >
> > I suppose I reached into kstrtodec64() and kstrtoudec64() because it aligns
> > with your expectations for kstrto*() semantics, no? Those include:
> > - overflow check;
> > - extensive input validation;
> > - optional '\n' in the end;
> > - mandatory nul-termination.
> >
> > am I missing anything?
>
> When we add scale we basically make that not true. Moreover the code in this
> patch makes scale == number_of_characters which I think a bit fragile, however
> it's about the fractional part when the amount of digits is equal to scale.
That is not really the case. It is being set as a limit, so it does check for
truncation and zero-padding.
> To make this work as expected we need to add an additional call like
> kstrtoull() (and perhaps drop that \n and NUL-terminator checks) and see
> if that overflows or not. Since it's a fractional part it must have less
> than 20 (decimal) digits there, so we check the rv (or how many digits
> were parsed successfully) and compare to 20. If it's more, we got too many
> decimal digits.
For overflow it checks the KSTRTOX_OVERFLOW flag and leverages check_mul_overflow()
and check_add_overflow() when combining fractional and integer parts. The amount
of characters is not really important there. The scale cannot be bigger than 19 and
that makes sure that int_pow() does not overflow. The code uses _parse_integer_limit()
due to the nature of input and to avoid 64-bit division, kstrtoull() at any point
(parsing integer or fractional parts) does not make much sense.
>
> Maybe I'm missing these checks already performed?
>
> > > Having the test cases is a big benefit, and that part I like the most.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-12 14:11 UTC (permalink / raw)
To: Liviu Dudau
Cc: Marcin Ślusarz, Ketil Johnsen, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Price, Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <agMvb_jeRsO7tSS-@e142607>
On Tue, 12 May 2026 14:47:27 +0100
Liviu Dudau <liviu.dudau@arm.com> wrote:
> On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > On Thu, 7 May 2026 11:02:26 +0200
> > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> >
> > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > return ret;
> > > > > }
> > > > >
> > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > >
> > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > name is "" already?
> > >
> > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > This check prevents that.
> >
> > Yeah, that's also a questionable design choice. I mean, we can
> > currently probe and boot the FW even though we never setup the
> > protected FW sections, so why should we defer the probe here? Can't we
> > just retry the next time a group with the protected bit is created and
> > fail if we can find a protected heap?
>
> The problem we have with the current firmware is that it does a number of setup steps at "boot"
> time only. One of the steps is preparing its internal structures for when it enters protected
> mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> process when we have a group with protected mode set.
No, but we can force a full/slow reset and have that thing
re-initialized, can't we? I mean, that's basically what we do when a
fast reset fails: we re-initialize all the sections and reset again, at
which point the FW should start from a fresh state, and be able to
properly initialize the protected-related stuff if protected sections
are populated. Am I missing something?
^ permalink raw reply
* Re: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Jiri Pirko @ 2026-05-12 14:07 UTC (permalink / raw)
To: Parav Pandit
Cc: Mark Bloch, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Andrew Lunn, David S. Miller, Jonathan Corbet, Shuah Khan,
Simon Horman, Saeed Mahameed, Leon Romanovsky, Tariq Toukan,
Andrew Morton, Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, NBU-Contact-Li Rongqing (EXTERNAL),
Paul E. McKenney, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <SJ0PR12MB68061C61AA2BF5D81005984FDC392@SJ0PR12MB6806.namprd12.prod.outlook.com>
Tue, May 12, 2026 at 03:48:32PM CEST, parav@nvidia.com wrote:
>
>> From: Jiri Pirko <jiri@resnulli.us>
>> Sent: 12 May 2026 02:16 PM
>>
>> Mon, May 11, 2026 at 08:21:37PM +0200, parav@nvidia.com wrote:
>> >
>> >> From: Mark Bloch <mbloch@nvidia.com>
>> >> Sent: 10 May 2026 06:02 PM
>> >>
>> >
>> >[..]
>> >
>> >> > I look at it from the perspective that from some CX generation,
>> >> > switchdev mode should be default. So that is a device-based decision.
>> >> > I believe as such it can optionally be permanenty configured (nv config)
>> >> > on older device. Why not?
>> >>
>> >Because sometimes switchdev_inactive is needed and sometimes not.
>> >Such knob is not device decision.
>>
>> That is what I would call corner case. In that, user can use userspace
>> configuration to change the mode in runtime.
>>
>Corner vs common depends on users one talks to. :)
>If fw has switchdev(active) as default, and then
>And user needs to run switchdev_inactive, it will actually break their switching applications.
Can you describe the actutal breakage please?
>
>So, one needs to invent switchdev_inactive in the FW.
>
>Jakub's suggestion in this RFC is covering both the scenarios uniformly without above problems.
>Single uapi for all the cases, so looks good to me.
>
>Moreover, do not understand how alternative solves such problems.
>i.e. user is unable to configure the fw because driver is not yet loaded/up.
See my other reply in this thread. I don't think there is a need to
configure anything in FW. If we fix the behaviour in switchdev mode for
non-sriov user and change the default, no fw knob needed. What am I
missing?
>
>>
>> >If it is placed in the device, orchestration needs to yet use additional vendor tool to configure in the device.
>> >And that theoretical tool cannot even run yet because driver is not yet loaded.
>> >
>> >That sort of defeats the purpose.
>> >
>> >> This is a deployment policy decision, not a permanent property of the card.
>> >+1
>> >
>> >> The same adapter can be used in a regular host/RDMA setup or in a
>> >> switchdev/offload setup. If we store this in NVM, that Linux switchdev policy
>> >> follows the device across hosts, kernels and use cases, and can surprise the
>> >> next deployment that just expects a normal NIC.
>> >>
>> >> I'll send another RFC v2 with support limited to:
>> >> devlink=[...]:esw:mode:{ switchdev | switchdev_inactive | legacy }
>> >> and let's see where we land with that.
>> >>
>> >This looks elegant to me as well covering all eswitch modes and still sw is in control.
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-12 13:57 UTC (permalink / raw)
To: Manuel Ebner
Cc: Jani Nikula, andy.shevchenko, apw, corbet, dwaipayanray1, joe,
kees, linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <46d8a5a8c8c77d3de9acfa1c55de2148fb2975c5.camel@mailbox.org>
On Tue, 12 May 2026 12:43:54 +0200
Manuel Ebner <manuelebner@mailbox.org> wrote:
> On Tue, 2026-05-12 at 11:52 +0300, Jani Nikula wrote:
> > On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add strlcat and alternatives
> >
> > You'd think it's the strlcat() definition that needs a comment above it
> > saying it's deprecated. I don't think folks really look at
> > deprecated.rst.
>
> arch/s390/lib/string.c
> lib/string.c
> and
> tools/include/nolibc/string.h
>
> do not mentions anything about obsolete.
>
> include/linux/fortify-string.h has
>
> /* Defined after fortified strlen() to reuse it. */
> extern size_t __real_strlcat(char *p, const char *q, size_t avail) __RENAME(strlcat);
> /**
> * strlcat - Append a string to an existing string
> * [...]
> * Do not use this function. While FORTIFY_SOURCE tries to avoid
> * read and write overflows, this is only possible when the sizes
> * of @p and @q are known to the compiler. Prefer building the
> * string with formatting, via scnprintf(), seq_buf, or similar.
I'm not that advice is really that good.
The other schemes (esp scnprintf) are just as dangerous.
If the code has just done 'buf = kmalloc(size)' then strlcat(,,size)
is fine - from an overflow point of view.
strlcat() isn't really any worse than memcpy().
(unlike strncat() which was just an accident waiting to happen)
-- David
>
> should i add this to the former three files?
>
> Manuel
>
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > > ---
> > > Documentation/process/deprecated.rst | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > > index fed56864d036..b8a65c19796c 100644
> > > --- a/Documentation/process/deprecated.rst
> > > +++ b/Documentation/process/deprecated.rst
> > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is
> > > strscpy(),
> > > though care must be given to any cases where the return value of strlcpy()
> > > is used, since strscpy() will return negative errno values when it truncates.
> > >
> > > +strlcat()
> > > +---------
> > > +strlcat() must re-scan the destination string from the beginning on each
> > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > +snprintf() and scnprintf()
> > > +
> > > %p format specifier
> > > -------------------
> > > Traditionally, using "%p" in format strings would lead to regular address
> >
>
>
^ permalink raw reply
* Re: [PATCH v12 03/11] lib: test-kstrtox: tests for kstrtodec64() and kstrtoudec64()
From: Andy Shevchenko @ 2026-05-12 13:51 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260510-adf41513-iio-driver-v12-3-34af2ed2779f@analog.com>
On Sun, May 10, 2026 at 01:42:21PM +0100, Rodrigo Alencar via B4 Relay wrote:
> Add tests for decimal parsing helpers kstrtodec64() and kstrtoudec64().
> The test infrastructure is reused from other kstrto*() functions, i.e.,
> the decimal parsers have fixed base of 10, so base field is used as
> scale input for the helpers.
I think I gave you a tag at some point, but in case I'm mistaken here we are
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12 04/11] lib: math: div64: add div64_s64_rem()
From: Andy Shevchenko @ 2026-05-12 13:50 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260510-adf41513-iio-driver-v12-4-34af2ed2779f@analog.com>
On Sun, May 10, 2026 at 01:42:22PM +0100, Rodrigo Alencar via B4 Relay wrote:
> Add div64_s64_rem() function, with 32-bit implementation that uses
> div64_u64_rem() and a branchless approach to resolve the sign of the
> remainder and quotient (negation in two's complement).
Cool, also chance to address:
drivers/iio/pressure/dps310.c:687: /* Kernel lacks a div64_s64_rem function; denoms are all positive */
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Parav Pandit @ 2026-05-12 13:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: Mark Bloch, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Andrew Lunn, David S. Miller, Jonathan Corbet, Shuah Khan,
Simon Horman, Saeed Mahameed, Leon Romanovsky, Tariq Toukan,
Andrew Morton, Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, NBU-Contact-Li Rongqing (EXTERNAL),
Paul E. McKenney, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <agLoeZtsSizR-R24@FV6GYCPJ69>
> From: Jiri Pirko <jiri@resnulli.us>
> Sent: 12 May 2026 02:16 PM
>
> Mon, May 11, 2026 at 08:21:37PM +0200, parav@nvidia.com wrote:
> >
> >> From: Mark Bloch <mbloch@nvidia.com>
> >> Sent: 10 May 2026 06:02 PM
> >>
> >
> >[..]
> >
> >> > I look at it from the perspective that from some CX generation,
> >> > switchdev mode should be default. So that is a device-based decision.
> >> > I believe as such it can optionally be permanenty configured (nv config)
> >> > on older device. Why not?
> >>
> >Because sometimes switchdev_inactive is needed and sometimes not.
> >Such knob is not device decision.
>
> That is what I would call corner case. In that, user can use userspace
> configuration to change the mode in runtime.
>
Corner vs common depends on users one talks to. :)
If fw has switchdev(active) as default, and then
And user needs to run switchdev_inactive, it will actually break their switching applications.
So, one needs to invent switchdev_inactive in the FW.
Jakub's suggestion in this RFC is covering both the scenarios uniformly without above problems.
Single uapi for all the cases, so looks good to me.
Moreover, do not understand how alternative solves such problems.
i.e. user is unable to configure the fw because driver is not yet loaded/up.
>
> >If it is placed in the device, orchestration needs to yet use additional vendor tool to configure in the device.
> >And that theoretical tool cannot even run yet because driver is not yet loaded.
> >
> >That sort of defeats the purpose.
> >
> >> This is a deployment policy decision, not a permanent property of the card.
> >+1
> >
> >> The same adapter can be used in a regular host/RDMA setup or in a
> >> switchdev/offload setup. If we store this in NVM, that Linux switchdev policy
> >> follows the device across hosts, kernels and use cases, and can surprise the
> >> next deployment that just expects a normal NIC.
> >>
> >> I'll send another RFC v2 with support limited to:
> >> devlink=[...]:esw:mode:{ switchdev | switchdev_inactive | legacy }
> >> and let's see where we land with that.
> >>
> >This looks elegant to me as well covering all eswitch modes and still sw is in control.
^ permalink raw reply
* Re: [PATCH v12 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64()
From: Andy Shevchenko @ 2026-05-12 13:48 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Jonathan Cameron, Rodrigo Alencar via B4 Relay, rodrigo.alencar,
linux-kernel, linux-iio, devicetree, linux-doc, David Lechner,
Andy Shevchenko, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Andrew Morton, Petr Mladek, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan, David Laight
In-Reply-To: <sj6cpjhakyfvv6rgox6cnhl2u2tgaecugcok6fw2l7zgku5wtc@aqx3ul72vgca>
On Tue, May 12, 2026 at 02:21:14PM +0100, Rodrigo Alencar wrote:
> On 26/05/12 04:12PM, Andy Shevchenko wrote:
> > On Tue, May 12, 2026 at 12:39:53PM +0100, Jonathan Cameron wrote:
> > > On Sun, 10 May 2026 13:42:20 +0100
> > > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> > >
> > > > Add helpers that parses decimal numbers into 64-bit number, i.e., decimal
> > > > point numbers with pre-defined scale are parsed into a 64-bit value (fixed
> > > > precision). After the decimal point, digits beyond the specified scale
> > > > are ignored.
> > >
> > > Whilst Rodrigo has already replied to say there will be another version
> > > I'd like to request final feedback from those who were involved in the parser
> > > discussions.
> > >
> > > They got very involved and I'm far from an expert in the right way to do
> > > this stuff.
> > >
> > > I don't think David Laight was +CC so I've added that.
> > > David, Andy - I think you two were most involved in that discussion:
> > > Any objections to the end result?
> >
> > I already said a few times about the naming. I do not like the kstrto*()
> > be semantically different on how they treat the input. Second point is
> > to avoid code duplication, but this one is less of a concern since the
> > new code is in the library close to the other potentially duplicate code
> > piece and hence can be addressed later.
>
> I suppose I reached into kstrtodec64() and kstrtoudec64() because it aligns
> with your expectations for kstrto*() semantics, no? Those include:
> - overflow check;
> - extensive input validation;
> - optional '\n' in the end;
> - mandatory nul-termination.
>
> am I missing anything?
When we add scale we basically make that not true. Moreover the code in this
patch makes scale == number_of_characters which I think a bit fragile, however
it's about the fractional part when the amount of digits is equal to scale.
To make this work as expected we need to add an additional call like
kstrtoull() (and perhaps drop that \n and NUL-terminator checks) and see
if that overflows or not. Since it's a fractional part it must have less
than 20 (decimal) digits there, so we check the rv (or how many digits
were parsed successfully) and compare to 20. If it's more, we got too many
decimal digits.
Maybe I'm missing these checks already performed?
> > Having the test cases is a big benefit, and that part I like the most.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Liviu Dudau @ 2026-05-12 13:47 UTC (permalink / raw)
To: Boris Brezillon
Cc: Marcin Ślusarz, Ketil Johnsen, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Price, Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <20260507135356.5428d50d@fedora>
On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> On Thu, 7 May 2026 11:02:26 +0200
> Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
>
> > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > return ret;
> > > > }
> > > >
> > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > >
> > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > name is "" already?
> >
> > If dma_heap_find() will fail, then the whole probe with fail too.
> > This check prevents that.
>
> Yeah, that's also a questionable design choice. I mean, we can
> currently probe and boot the FW even though we never setup the
> protected FW sections, so why should we defer the probe here? Can't we
> just retry the next time a group with the protected bit is created and
> fail if we can find a protected heap?
The problem we have with the current firmware is that it does a number of setup steps at "boot"
time only. One of the steps is preparing its internal structures for when it enters protected
mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
process when we have a group with protected mode set.
So unfortunately adding support for protected mode where the heap name is provided means we
have to try our best to set it up at boot time, or otherwise disable protected mode support.
Best regards,
Liviu
>
> > I'm not sure why it's needed at all, but if
> > it is really needed, then s/strlen(protected_heap_name)/protected_heap_name[0]/
> > would simplify this.
>
> It's not so much about how you do the test, and more about the case
> you're trying to protect against. I guess here you assume that
> panthor.protected_heap_name="" means "I don't have a protected heap for
> you". If it's deemed acceptable, this should most certainly be
> described somewhere.
>
> >
> > > > + ptdev->protm.heap = dma_heap_find(protected_heap_name);
> > > > + if (!ptdev->protm.heap) {
> > > > + drm_warn(&ptdev->base,
> > > > + "Protected heap \'%s\' not (yet) available - deferring probe",
> > > > + protected_heap_name);
> > > > + ret = -EPROBE_DEFER;
> > > > + goto err_rpm_put;
> > >
> > > If you move the heap retrieval before the rpm enablement, you can get
> > > rid of this goto err_rpm_put.
> > >
> > > > + }
> > > > + }
> > > > +
> > > > ret = panthor_hw_init(ptdev);
> > > > if (ret)
> > > > - goto err_rpm_put;
> > > > + goto err_dma_heap_put;
> > > >
> > > > ret = panthor_pwr_init(ptdev);
> > > > if (ret)
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH] Documentation/kernel-parameters: Remove "Deprecated" from isolcpus=
From: Frederic Weisbecker @ 2026-05-12 13:45 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: LKML, Gabriele Monaco, Ingo Molnar, Jonathan Corbet,
Marcelo Tosatti, Marco Crivellari, Michal Hocko,
Paul E . McKenney, Peter Zijlstra, Phil Auld, Steven Rostedt,
Thomas Gleixner, Valentin Schneider, Vlastimil Babka, Waiman Long,
linux-doc, Bagas Sanjaya, Shuah Khan, John Ogness
In-Reply-To: <20260427150739.bwVmmkj2@linutronix.de>
Le Mon, Apr 27, 2026 at 05:07:39PM +0200, Sebastian Andrzej Siewior a écrit :
> The isolcpus= option has been marked as deprecated in 2017. Back then it
> was desired for the domain sub option to be configured dynamically at
> runtime instead using this boot command line which provides a static
> configuration. In the meantime this option was extended by other sub
> options which don't have runtime counterpart or it does not make sense
> to provide one.
>
> The deprecated part always referred to the default `domain' sub option
> but it was not obvious. Also the reasoning behind the deprecation is
> sort of dubious: There is nothing wrong with a static configuration if
> there is no desired to reconfigure. This is useful on systems which
> have one purpose and the CPU partition configuration is not changed for
> the entire lifetime.
>
> Remove the "Deprecated" note. Remove the part of the description which
> suggest to use cpuset.sched_load_balance and instead point to the
> documentation file which explains how to use cpusets to configure this
> at runtime.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Shashank Balaji @ 2026-05-12 13:32 UTC (permalink / raw)
To: Sumit Gupta
Cc: Jon Hunter, Thierry Reding, Gary Guo, Suzuki K Poulose,
James Clark, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Richard Cochran, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach,
Leo Yan, Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird,
linux-modules, linux-tegra
In-Reply-To: <0d9e5a78-948e-42da-9d37-78cc2a700cd6@nvidia.com>
On Tue, May 12, 2026 at 05:44:40PM +0530, Sumit Gupta wrote:
>
> On 12/05/26 14:25, Jon Hunter wrote:
> > Hi Shashank,
> >
> > On 12/05/2026 03:12, Shashank Balaji wrote:
> >
> > ...
> >
> > > > Hi Thierry and Jonathan,
> > > >
> > > > You can find the context for this email in this patch:
> > > > https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
> > > >
> > > >
> > > > TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
> > > > registering themselves as early as in a pure_initcall. This is a
> > > > problem
> > > > on two fronts:
> > > > 1. Philosophical: As Gary pointed out, pure_initcalls are
> > > > intended to purely
> > > > initialize variables that couldn't be statically initialized. But these
> > > > are doing driver registrations.
> > > > 2. module_kset not initialized at pure_initcall stage: This is
> > > > needed to
> > > > set the module sysfs symlink. Since module_kset is not alive yet during
> > > > pure_initcalls, registering these drivers panics the kernel.
> >
> > Where exactly is this panic seen? Ie. why are we not seeing this?
The panic happens as a result of this patch series. This series aims to
set .mod_name of struct device_driver for platform drivers. So that, for
built-in drivers, their module sysfs symlink can be created on the basis
of .modname. We essentially want to link a platform driver to its
module. This happens naturally if the driver is built as a loadable
module, but for this to happen for built-in modules, .mod_name needs to be set.
To go from .mod_name to the module sysfs symlink, the module_kset kset
needs to be initialized. This currently happens in a subsys_initcall.
These tegra cbb drivers register themselves in a pure_initcall, i.e.
before subsys_initcall, leading to a null dereference of module_kset.
To fix this, we want to move the module_kset creation to pure_initcall,
and tegra cbb driver registration to core_initcall, so after
pure_initcall.
> > > > We would like to do the tegra cbb driver registration in a
> > > > core_initcall
> > > > (or some later initcall works too), and move module_kset initialization
> > > > to a pure_initcall. Like this:
> > > >
> > > > diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > b/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > index ab75d50cc85c..2f69e104c838 100644
> > > > --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
> > > > {
> > > > return platform_driver_register(&tegra194_cbb_driver);
> > > > }
> > > > -pure_initcall(tegra194_cbb_init);
> > > > +core_initcall(tegra194_cbb_init);
> > > >
> > > > static void __exit tegra194_cbb_exit(void)
> > > > {
> > > > diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > b/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > index fb26f085f691..785072fa4e85 100644
> > > > --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
> > > > {
> > > > return platform_driver_register(&tegra234_cbb_driver);
> > > > }
> > > > -pure_initcall(tegra234_cbb_init);
> > > > +core_initcall(tegra234_cbb_init);
> > > >
> > > > static void __exit tegra234_cbb_exit(void)
> > > > {
> > > >
> > > > Would this work?
> >
> >
> > I am adding Sumit who has been doing a lot of the Tegra CBB driver work.
> >
> > Sumit, any concerns here? We could run this change through our internal
> > testing to confirm.
> >
> > Jon
> >
>
> CBB driver can be switched to core_initcall.
> pure_initcall was originally added so its IRQ handler is registered
> before other Tegra drivers to catch and print any bad MMIO error
> during their probe.
> Looked at the current state of Tegra drivers:
> - The other early Tegra drivers (PMC, fuse, flowctrl, ARI) all run at
> early_initcall, before either pure_ or core_initcall.
> - The only other Tegra core_initcall is tegra-hsp, and link order keeps
> CBB ahead of it (drivers/soc/ links before drivers/mailbox/).
>
> Acked-by: Sumit Gupta <sumitg@nvidia.com>
Thanks, Sumit and Jon!
^ permalink raw reply
* Re: [PATCH 3/8] drm/panthor: De-duplicate FW memory section sync
From: Liviu Dudau @ 2026-05-12 13:37 UTC (permalink / raw)
To: Ketil Johnsen
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260505140516.1372388-4-ketil.johnsen@arm.com>
On Tue, May 05, 2026 at 04:05:09PM +0200, Ketil Johnsen wrote:
> Handle the sync to device of FW memory sections inside
> panthor_fw_init_section_mem() so that the callers do not have to.
>
> This small improvement is also critical for protected FW sections,
> so we avoid issuing memory transactions to protected memory from
> CPU running in normal mode.
>
> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 22 ++++++----------------
> 1 file changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
> index be0da5b1f3abf..0d07a133dc3af 100644
> --- a/drivers/gpu/drm/panthor/panthor_fw.c
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> @@ -446,6 +446,7 @@ static void panthor_fw_init_section_mem(struct panthor_device *ptdev,
> struct panthor_fw_section *section)
> {
> bool was_mapped = !!section->mem->kmap;
> + struct sg_table *sgt;
> int ret;
>
> if (!section->data.size &&
> @@ -464,6 +465,11 @@ static void panthor_fw_init_section_mem(struct panthor_device *ptdev,
>
> if (!was_mapped)
> panthor_kernel_bo_vunmap(section->mem);
> +
> + /* An sgt should have been requested when the kernel BO was GPU-mapped. */
> + sgt = to_panthor_bo(section->mem->obj)->dmap.sgt;
> + if (!drm_WARN_ON_ONCE(&ptdev->base, !sgt))
> + dma_sync_sgtable_for_device(ptdev->base.dev, sgt, DMA_TO_DEVICE);
> }
>
> /**
> @@ -626,7 +632,6 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
> section_size = hdr.va.end - hdr.va.start;
> if (section_size) {
> u32 cache_mode = hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_CACHE_MODE_MASK;
> - struct panthor_gem_object *bo;
> u32 vm_map_flags = 0;
> u64 va = hdr.va.start;
>
> @@ -663,14 +668,6 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
> }
>
> panthor_fw_init_section_mem(ptdev, section);
> -
> - bo = to_panthor_bo(section->mem->obj);
> -
> - /* An sgt should have been requested when the kernel BO was GPU-mapped. */
> - if (drm_WARN_ON_ONCE(&ptdev->base, !bo->dmap.sgt))
> - return -EINVAL;
> -
> - dma_sync_sgtable_for_device(ptdev->base.dev, bo->dmap.sgt, DMA_TO_DEVICE);
> }
>
> if (hdr.va.start == CSF_MCU_SHARED_REGION_START)
> @@ -724,17 +721,10 @@ panthor_reload_fw_sections(struct panthor_device *ptdev, bool full_reload)
> struct panthor_fw_section *section;
>
> list_for_each_entry(section, &ptdev->fw->sections, node) {
> - struct sg_table *sgt;
> -
> if (!full_reload && !(section->flags & CSF_FW_BINARY_IFACE_ENTRY_WR))
> continue;
>
> panthor_fw_init_section_mem(ptdev, section);
> -
> - /* An sgt should have been requested when the kernel BO was GPU-mapped. */
> - sgt = to_panthor_bo(section->mem->obj)->dmap.sgt;
> - if (!drm_WARN_ON_ONCE(&ptdev->base, !sgt))
> - dma_sync_sgtable_for_device(ptdev->base.dev, sgt, DMA_TO_DEVICE);
> }
> }
>
> --
> 2.43.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v1] docs: housekeeping: Fix struct member access in code example
From: Frederic Weisbecker @ 2026-05-12 13:34 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Costa Shulyupin, Shuah Khan, Ryan Cheevers, Waiman Long,
linux-doc, linux-kernel
In-Reply-To: <87wlxkczyy.fsf@trenco.lwn.net>
Le Sun, May 03, 2026 at 08:47:01AM -0600, Jonathan Corbet a écrit :
> Costa Shulyupin <costa.shul@redhat.com> writes:
>
> > No such array housekeeping_cpumasks
> >
> > Fix to housekeeping.cpumasks.
> >
> > Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> > ---
> > Documentation/core-api/housekeeping.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/core-api/housekeeping.rst b/Documentation/core-api/housekeeping.rst
> > index 92c6e53cea75..ccb0a88b9cb3 100644
> > --- a/Documentation/core-api/housekeeping.rst
> > +++ b/Documentation/core-api/housekeeping.rst
> > @@ -99,7 +99,7 @@ the same RCU read side critical section.
> > A typical layout example would look like this on the update side
> > (``housekeeping_update()``)::
> >
> > - rcu_assign_pointer(housekeeping_cpumasks[type], trial);
> > + rcu_assign_pointer(housekeeping.cpumasks[type], trial);
> > synchronize_rcu();
>
> This looks actively wrong to me. I think it should be:
>
> housekeeping_cpumask(type)
>
> ... Frederic ... ?
No, Costa is right, housekeeping.cpumasks[type] is where we store
the pointer. housekeeping_cpumask(type) is only an accessor.
So:
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Thanks!
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6 2/4] mm/memory-failure: classify get_any_page() failures by reason
From: Breno Leitao @ 2026-05-12 13:33 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Miaohe Lin, Naoya Horiguchi, Andrew Morton, Jonathan Corbet,
Shuah Khan, Lorenzo Stoakes, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Liam R. Howlett, linux-mm,
linux-kernel, linux-doc, linux-kselftest, linux-trace-kernel,
kernel-team, Lance Yang
In-Reply-To: <28b01c14-3d87-4cab-b695-5b9015578785@kernel.org>
On Tue, May 12, 2026 at 10:21:50AM +0200, David Hildenbrand (Arm) wrote:
>
> > }
> > goto unlock_mutex;
> > } else if (res < 0) {
> > - if (is_reserved)
> > + /*
> > + * Promote a stable unhandlable kernel page diagnosed by
> > + * get_hwpoison_page() to MF_MSG_KERNEL alongside reserved
> > + * pages; transient lifecycle races stay as MF_MSG_GET_HWPOISON.
> > + */
> > + if (is_reserved || gp_status == MF_GET_PAGE_UNHANDLABLE)
> > res = action_result(pfn, MF_MSG_KERNEL, MF_IGNORED);
>
>
> It's all a bit of a mess. get_hwpoison_page() should just indicate that a page
> is unhandable if it is PG_reserved?
Are you saying that we should identify if the page is PG_reserved in
get_hwpoison_page() instead of in memory_failure(), as done in the
previous patch ("mm/memory-failure: report MF_MSG_KERNEL for reserved
pages") ?
> Why can't we just return a special error code from get_hwpoison_page()? We ahve
> plenty of errno values to chose from.
Something like:
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 866c4428ac7ef..0a6d83575833e 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -878,7 +878,7 @@ static const char *action_name[] = {
};
static const char * const action_page_types[] = {
- [MF_MSG_KERNEL] = "reserved kernel page",
+ [MF_MSG_KERNEL] = "unrecoverable kernel page",
[MF_MSG_KERNEL_HIGH_ORDER] = "high-order kernel page",
[MF_MSG_HUGE] = "huge page",
[MF_MSG_FREE_HUGE] = "free huge page",
@@ -1394,6 +1394,21 @@ static int get_any_page(struct page *p, unsigned long flags)
int ret = 0, pass = 0;
bool count_increased = false;
+ if (PageReserved(p)) {
+ ret = -ENOTRECOVERABLE;
+ goto out;
+ }
+
if (flags & MF_COUNT_INCREASED)
count_increased = true;
@@ -1422,7 +1437,7 @@ static int get_any_page(struct page *p, unsigned long flags)
shake_page(p);
goto try_again;
}
- ret = -EIO;
+ ret = -ENOTRECOVERABLE;
goto out;
}
}
@@ -1441,10 +1456,10 @@ static int get_any_page(struct page *p, unsigned long flags)
goto try_again;
}
put_page(p);
- ret = -EIO;
+ ret = -ENOTRECOVERABLE;
}
out:
- if (ret == -EIO)
+ if (ret == -EIO || ret == -ENOTRECOVERABLE)
pr_err("%#lx: unhandlable page.\n", page_to_pfn(p));
return ret;
@@ -2431,6 +2448,9 @@ int memory_failure(unsigned long pfn, int flags)
res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
}
goto unlock_mutex;
+ } else if (res == -ENOTRECOVERABLE) {
+ res = action_result(pfn, MF_MSG_KERNEL, MF_IGNORED);
+ goto unlock_mutex;
} else if (res < 0) {
res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
goto unlock_mutex;
If that is what you are suggestion, maybe we can create another
MF_MSG_RESERVED? and another return value for get_any_page() to track
the reserve pages ?
Thanks for the review and suggestions,
--breno
^ permalink raw reply related
* [PATCH net-next] Documentation: networking: devlink: stmmac: fix typo in phc_coarse_adj
From: Avinash Duduskar @ 2026-05-12 13:32 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, pabeni, edumazet, horms, corbet, jiri,
mcoquelin.stm32, alexandre.torgue, linux-doc, linux-stm32,
linux-arm-kernel, linux-kernel
"Functionnal" should be "Functional".
Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com>
---
Documentation/networking/devlink/stmmac.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/devlink/stmmac.rst b/Documentation/networking/devlink/stmmac.rst
index 47e3ff10bc08..fbaa81ea782d 100644
--- a/Documentation/networking/devlink/stmmac.rst
+++ b/Documentation/networking/devlink/stmmac.rst
@@ -24,7 +24,7 @@ The ``stmmac`` driver implements the following driver-specific parameters.
- runtime
- Enable the Coarse timestamping mode, as defined in the DWMAC TRM.
A detailed explanation of this timestamping mode can be found in the
- Socfpga Functionnal Description [1].
+ Socfpga Functional Description [1].
In Coarse mode, the ptp clock is expected to be fed by a high-precision
clock that is externally adjusted, and the subsecond increment used for
--
2.54.0
^ permalink raw reply related
* [PATCH net-next] Documentation: networking: ip-sysctl: fix typo in tcp_ecn_option
From: Avinash Duduskar @ 2026-05-12 13:31 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, pabeni, edumazet, horms, corbet, linux-doc,
linux-kernel
"regarless" should be "regardless".
Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com>
---
Documentation/networking/ip-sysctl.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 2e3a746fcc6d..4c6a35d07a08 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -489,7 +489,7 @@ tcp_ecn - INTEGER
tcp_ecn_option - INTEGER
Control Accurate ECN (AccECN) option sending when AccECN has been
successfully negotiated during handshake. Send logic inhibits
- sending AccECN options regarless of this setting when no AccECN
+ sending AccECN options regardless of this setting when no AccECN
option has been seen for the reverse direction.
Possible values are:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v12 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64()
From: Rodrigo Alencar @ 2026-05-12 13:21 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Cameron
Cc: Rodrigo Alencar via B4 Relay, rodrigo.alencar, linux-kernel,
linux-iio, devicetree, linux-doc, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky,
Shuah Khan, David Laight
In-Reply-To: <agMnWzMjW1LwCSyT@ashevche-desk.local>
On 26/05/12 04:12PM, Andy Shevchenko wrote:
> On Tue, May 12, 2026 at 12:39:53PM +0100, Jonathan Cameron wrote:
> > On Sun, 10 May 2026 13:42:20 +0100
> > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> >
> > > Add helpers that parses decimal numbers into 64-bit number, i.e., decimal
> > > point numbers with pre-defined scale are parsed into a 64-bit value (fixed
> > > precision). After the decimal point, digits beyond the specified scale
> > > are ignored.
> >
> > Whilst Rodrigo has already replied to say there will be another version
> > I'd like to request final feedback from those who were involved in the parser
> > discussions.
> >
> > They got very involved and I'm far from an expert in the right way to do
> > this stuff.
> >
> > I don't think David Laight was +CC so I've added that.
> > David, Andy - I think you two were most involved in that discussion:
> > Any objections to the end result?
>
> I already said a few times about the naming. I do not like the kstrto*()
> be semantically different on how they treat the input. Second point is
> to avoid code duplication, but this one is less of a concern since the
> new code is in the library close to the other potentially duplicate code
> piece and hence can be addressed later.
I suppose I reached into kstrtodec64() and kstrtoudec64() because it aligns
with your expectations for kstrto*() semantics, no? Those include:
- overflow check;
- extensive input validation;
- optional '\n' in the end;
- mandatory nul-termination.
am I missing anything?
> Having the test cases is a big benefit, and that part I like the most.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Kind regards,
Rodrigo Alencar
^ 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