* Re: [PATCH RFC v6 3/5] iio: osf: add protocol decoding
From: Andy Shevchenko @ 2026-06-29 14:05 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260628191337.937-4-kimjinseob88@gmail.com>
On Mon, Jun 29, 2026 at 04:13:35AM +0900, Jinseob Kim wrote:
> Add helpers for decoding Open Sensor Fusion frame headers and supported
> message payloads.
>
> The decoder validates the OSF0 wire magic, protocol major version,
> header length, payload bounds, reserved fields and CRC before exposing
> decoded frame contents to the rest of the driver.
>
> Use explicit little-endian wire storage sizes and designated
> initializers for decoded output structures.
...
> +#include <linux/bits.h>
> +#include <linux/crc32.h>
> +#include <linux/errno.h>
> +#include <linux/limits.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
...
> +#define OSF_FRAME_MAGIC 0x3046534f /* "OSF0" little-endian */
#define OSF_FRAME_MAGIC 0x3046534f /* "OSF0", little-endian */
(mind a comma).
...
> +int osf_protocol_decode_sensor_sample(const struct osf_frame *frame,
> + struct osf_sensor_sample *sample)
> +{
> + u16 channel_count;
> + u16 sample_format;
> + u16 sensor_type;
> + size_t expected_len;
> + const u8 *payload;
> +
> + if (!frame || !sample || !frame->payload)
> + return -EINVAL;
> +
> + if (frame->message_type != OSF_MSG_SENSOR_SAMPLE)
> + return -EPROTO;
> +
> + if (frame->payload_len < OSF_SENSOR_SAMPLE_BASE_LEN)
> + return -EMSGSIZE;
> +
> + payload = frame->payload;
> + sensor_type = get_unaligned_le16(payload);
> + channel_count = get_unaligned_le16(payload + 4);
> + sample_format = get_unaligned_le16(payload + 6);
> +
> + if (!osf_sensor_type_valid(sensor_type))
> + return -EPROTO;
> +
> + if (!channel_count)
> + return -EPROTO;
> +
> + if (sample_format != OSF_SAMPLE_FORMAT_S32)
> + return -EPROTO;
> +
> + if (get_unaligned_le32(payload + 12))
> + return -EPROTO;
> + if (channel_count > (SIZE_MAX - OSF_SENSOR_SAMPLE_BASE_LEN) /
> + sizeof(__le32))
> + return -EOVERFLOW;
Dead code because it's always 'false'? Hasn't compiler given a warning?
Always compile your code with `make W=1` using both compilers: clang and GCC.
> + expected_len = OSF_SENSOR_SAMPLE_BASE_LEN + channel_count * sizeof(__le32);
> + if (frame->payload_len != expected_len)
> + return -EMSGSIZE;
> +
> + *sample = (struct osf_sensor_sample) {
> + .sensor_type = sensor_type,
> + .sensor_index = get_unaligned_le16(payload + 2),
> + .channel_count = channel_count,
> + .sample_format = sample_format,
> + .scale_nano = get_unaligned_le32(payload + 8),
> + .samples = payload + OSF_SENSOR_SAMPLE_BASE_LEN,
> + };
> +
> + return 0;
> +}
...
> + if (capability_count > (SIZE_MAX - OSF_CAP_REPORT_BASE_LEN) /
> + OSF_CAP_SENSOR_ENTRY_LEN)
> + return -EOVERFLOW;
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] sched/topology: Allow EAS without schedutil for artificial Energy Models
From: Lukasz Luba @ 2026-06-29 14:05 UTC (permalink / raw)
To: Lucas de Lima Nóbrega
Cc: dietmar.eggemann, rostedt, vincent.guittot, mingo, bsegall,
mgorman, vschneid, kprateek.nayak, corbet, skhan, linux-pm,
linux-doc, linux-kernel, juri.lelli, rafael, viresh.kumar, peterz
In-Reply-To: <20260629083542.10041-1-lucaslnobrega38@gmail.com>
On 6/29/26 09:35, Lucas de Lima Nóbrega wrote:
> EAS currently refuses to enable energy-aware scheduling on a root
> domain unless schedutil is the active CPUFreq governor for all of its
> CPUs (cpufreq_ready_for_eas()). This requirement exists to protect the
> accuracy of the energy estimate: EAS predicts the OPP a CPU will run
> at from its utilization, which is only meaningful if the active
> governor actually requests OPPs that way, and schedutil is the only
> one that does.
>
> That requirement does not apply to artificial Energy Models
> (EM_PERF_DOMAIN_ARTIFICIAL). An artificial EM is built from a
> get_cost() callback instead of real power numbers, and only encodes a
> cost ranking between CPUs (e.g. P-cores cost more than E-cores at a
> given utilization). It never claims to predict real energy use at any
> specific OPP, so there is no per-OPP accuracy for the governor
> requirement to protect, regardless of which governor is in control or
> whether it tracks utilization at all.
>
> intel_pstate registers exactly this kind of artificial EM for hybrid
> (P/E-core) systems without SMT, regardless of whether it operates in
> active or passive mode. In active mode it never uses schedutil, since
> HWP picks frequency autonomously, so on these systems EAS never
When frequency is picked autonomously then EAS and energy estimations
don't make sense IMHO.
Do you have any data from experiments how it runs?
Regards,
Lukasz
^ permalink raw reply
* Re: [PATCH RFC v6 0/5] iio: add Open Sensor Fusion IIO driver
From: Andy Shevchenko @ 2026-06-29 14:09 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260628191337.937-1-kimjinseob88@gmail.com>
On Mon, Jun 29, 2026 at 04:13:32AM +0900, Jinseob Kim wrote:
> Open Sensor Fusion (OSF) devices expose a UART/serdev host interface
> for a sensor aggregation hub. This RFC adds a Linux IIO driver that
> parses OSF frames and creates IIO devices at runtime from capability
> reports provided by the device firmware.
>
> When the corresponding capabilities are reported, the driver exposes
> accelerometer, gyroscope, magnetometer, and temperature data as IIO
> devices named osf-accel, osf-gyro, osf-magn, and osf-temp.
>
> This remains RFC while the binding, protocol subset, runtime discovery
> model, and driver-facing ABI are reviewed.
Where are the lore links to the previous versions?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RFC v6 4/5] iio: osf: add authenticated stream parser
From: Andy Shevchenko @ 2026-06-29 14:10 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260628191337.937-5-kimjinseob88@gmail.com>
On Mon, Jun 29, 2026 at 04:13:36AM +0900, Jinseob Kim wrote:
> Add a UART byte-stream parser for Open Sensor Fusion frames.
>
> The parser searches for the OSF0 wire magic, keeps partial frames
> buffered, checks header length and payload bounds, and passes complete
> candidate frames to the core decoder.
>
> Rejected candidate frames drop only the current head byte before
> resynchronizing, so a corrupted unauthenticated payload length cannot
> make the parser skip later valid frames.
...
> +#define OSF_STREAM_MAGIC_LEN 4
> +#define OSF_STREAM_MAX_PAYLOAD_LEN \
> + (OSF_STREAM_MAX_FRAME_LEN - OSF_FRAME_HEADER_LEN - OSF_FRAME_CRC_LEN)
> +
> +static const u8 osf_stream_magic[OSF_STREAM_MAGIC_LEN] = {
> + 'O', 'S', 'F', '0',
> +};
You have already this in the header (as FourCC), use that.
...
> +static size_t osf_stream_discard_to_magic(struct osf_stream *stream)
> +{
> + size_t old_len = stream->len;
> + size_t match_len;
> + size_t i;
> +
> + for (i = 0; i < stream->len; i++) {
for (size_t i = 0; i < stream->len; i++) {
> + match_len = stream->len - i;
> + if (match_len > OSF_STREAM_MAGIC_LEN)
> + match_len = OSF_STREAM_MAGIC_LEN;
> +
> + if (osf_stream_magic_match(stream->buf + i, match_len)) {
> + if (i)
> + osf_stream_discard(stream, i);
> + return i;
> + }
> + }
> +
> + stream->len = 0;
> + return old_len;
> +}
...
I stop here, because it's obvious that you neglected and ignored my previous
reviews. No explanation given, nothing. This is not how you should interact
with the community.
Come again when each of the given comment will be either addressed or argued.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [External Mail] Re: [PATCH v3 2/7] net: wwan: t9xx: Add control plane transaction layer
From: Andrew Lunn @ 2026-06-29 14:10 UTC (permalink / raw)
To: Wu. JackBB (GSM)
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <49939d4d682f4c1fb359973ea2cdbd00@compal.com>
> > > - devm_kfree(dev, mdev);
> > > + mtk_dev_free(mdev);
> >
> > Why are you removing devm_ calls?
>
> mtk_dev_alloc/mtk_dev_free are paired wrappers so the caller
> doesn't need to know the underlying allocation mechanism.
> The devm_kfree is still called inside mtk_dev_free.
Two different issues here:
1) If you don't want to use devm_, don't use devm_ from the
beginning. A patch should not change how a previous patch works, since
you are wasting reviewer time reviewing code which you later change.
2) Do you understand what devm_ actually does? Since you use
devm_free() i don't think you actually understand what devm_ is all
about.
Andrew
^ permalink raw reply
* Re: [PATCH RFC v6 0/5] iio: add Open Sensor Fusion IIO driver
From: Andy Shevchenko @ 2026-06-29 14:12 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <akJ8itlDBJfaYRj2@ashevche-desk.local>
On Mon, Jun 29, 2026 at 05:09:21PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 04:13:32AM +0900, Jinseob Kim wrote:
> > Open Sensor Fusion (OSF) devices expose a UART/serdev host interface
> > for a sensor aggregation hub. This RFC adds a Linux IIO driver that
> > parses OSF frames and creates IIO devices at runtime from capability
> > reports provided by the device firmware.
> >
> > When the corresponding capabilities are reported, the driver exposes
> > accelerometer, gyroscope, magnetometer, and temperature data as IIO
> > devices named osf-accel, osf-gyro, osf-magn, and osf-temp.
> >
> > This remains RFC while the binding, protocol subset, runtime discovery
> > model, and driver-facing ABI are reviewed.
>
> Where are the lore links to the previous versions?
Besides that you utterly ignorant in replying to the comments of the reviewers.
v3 and v5 left unanswered, third time in this version I give the very same
comments. What the heck?!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next v10 1/5] hinic3: Add ethtool queue ops
From: Andrew Lunn @ 2026-06-29 14:25 UTC (permalink / raw)
To: Fan Gong
Cc: Wu Di, Teng Peisen, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei, Mohsin Bashir, Dimitri Daskalakis,
Harshitha Ramamurthy, linux-kernel, linux-doc, luosifu, Xin Guo,
Zhou Shuai, Wu Like, Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <3414df08001307c6d96c17ffc0921206c62f85a1.1782718232.git.wudi234@huawei.com>
> @@ -315,21 +315,28 @@ static void hinic3_link_status_change(struct net_device *netdev,
> {
> struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
>
> + if (!mutex_trylock(&nic_dev->state_lock))
> + return;
> +
> if (link_status_up) {
> if (netif_carrier_ok(netdev))
> - return;
> + goto err_unlock;
So ignoring a link status change, leaving the carrier set wrongly,
because some other thread has the mutex locked, is O.K? It would be
good to explain in the commit message why this is correct, because it
is not obvious.
Andrew
^ permalink raw reply
* Re: [PATCH] docs: watchdog: Fix brackets
From: Guenter Roeck @ 2026-06-29 14:36 UTC (permalink / raw)
To: Jonathan Corbet, Manuel Ebner, rdunlap
Cc: linux-doc, linux-kernel, linux-watchdog, skhan, wim
In-Reply-To: <87pl19xy34.fsf@trenco.lwn.net>
On 6/29/26 06:42, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
>> Hi,
>>
>> is this patch on it's way?
>
> On its way where?
>
> You posted it two days ago, during the merge window. Surely you do not
> expect action on it that quickly?
>
Unfortunately people do have such expectations nowadays.
Then I come in the day after the commit window closes, with the thought
of spending a lot of (unpaid) time this week reviewing patches, and
instead start thinking that maybe it is time to resign as maintainer.
Guenter
^ permalink raw reply
* Re: [RFC PATCH 00/40] mm: reliable 1GB page allocation
From: Rik van Riel @ 2026-06-29 14:39 UTC (permalink / raw)
To: Vlastimil Babka (SUSE), Lorenzo Stoakes
Cc: linux-kernel, kernel-team, linux-mm, david, willy, surenb, hannes,
ziy, usama.arif, fvdl, Andrew Morton, Jonathan Corbet,
Chris Mason, David Sterba, Steven Rostedt, Masami Hiramatsu,
Rafael J. Wysocki, Oscar Salvador, Mike Rapoport, linux-doc,
linux-btrfs, linux-trace-kernel, linux-pm, linux-cxl,
Linus Torvalds
In-Reply-To: <361fd2e5-a5f9-42fe-90fc-bc0af109553e@kernel.org>
On Mon, 2026-06-29 at 12:03 +0200, Vlastimil Babka (SUSE) wrote:
> On 6/29/26 11:29, Lorenzo Stoakes wrote:
> >
> > So to be concrete, if you send really rough code, Use [pre-RFC] or
> > [DO NOT
> > MERGE] (on the series as a whole) to make that clear and say so in
> > the
> > cover letter VERY VERY clearly.
>
> Yes please. [POC NOT-FOR-MERGE] perhaps?
>
> > Or, you can put it in a repo somewhere and link it in an email
> > discussing
> > the concepts (like I did with scalable CoW for instance).
>
> Indeed.
I'll do that for the next version.
I suspect it will take a while to beat this thing
into shape.
>
> > And _you have already done this_ in your reply here:
> >
> > * "How do people feel about splitting up the free lists, so each
> > gigabyte
> > (well, PUD sized) chunk of memory has its own free lists?"
>
> My immediate response is that now we'd need to search multiple sets
> of lists
> instead of a single one? What about the overhead?
The current code is clearly not good enough. It
has to try several gigablocks almost blindly,
because there is no efficient way to find the
right gigablock.
I have an idea on how to fix that with bitmaps.
We could have one bitmap per order, indicating which
gigablocks have order 0 pages, order 1 pages, etc
Then a second set of bitmaps indicating which gigablocks
have unmovable / reclaimable pages.
At that point, finding a good gigablock to allocate
from can be done with a bitmap_and and a search.
These bitmaps would only need to be changed when the
status of a gigablock changes, eg. going from having
order 0 pages free, to not having any order 0 pages
free.
Does that seem like a workable approach?
Once we can quickly pinpoint a gigablock for the
page allocator to grab pages from, we can also
split out the "pick a gigablock" code from the
"allocate a page" code.
>
> > * "How can we balance the desire for higher-order kernel
> > allocations,
> > against the desire to preserve gigabyte sized chunks of memory
> > that can
> > be used for user space?"
> >
> > * "How do we balance the desire to keep compaction overhead low
> > with the
> > desire to do higher order allocations almost everywhere?"
>
> How can we have a cake and eat it too? :)
Pretty much :/
I suspect it's going to require some fun interactions
between allocation, reclaim, and compaction.
However, with everybody from networking, to filesystems,
to anonymous memory wanting to use higher order allocations
of differing sizes, it seems like we're going to have to
tackle this somehow.
>
> > I'd also very strongly suggest (as I did in my original reply)
> > breaking out
> > parts that can be broken out as prerequisite series.
> >
> > If you're doing something good or useful _anyway_ then just send
> > that
> > separately first, and have later work rely on the earlier work.
>
That becomes cleaner with the "post a link to
a tree" thing, as well.
The pcpbuddy stuff is likely to go in separately.
Johannes is still working on that code.
The "make btrfs inode cache pages movable" thing
already went in.
I think I have a few more things in the tree that
can go in separately, but hopefully that will grow
as this code solidifies.
On the flip side, things like "making compaction
scale" may well end up depending on the gigablock
stuff, because lack of targeting data seems like a
likely cause for why compaction has to try so hard.
I'll make sure to go over every point raised by
you guys before writing the next version of the
code, and again before posting a link to the
tree.
--
All Rights Reversed.
^ permalink raw reply
* [PATCH 0/5] mm/damon: five misc fixups
From: SJ Park @ 2026-06-29 14:55 UTC (permalink / raw)
To: Andrew Morton
Cc: SJ Park, Liam R. Howlett, Brendan Higgins, David Gow,
David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Shuah Khan, Suren Baghdasaryan, Vlastimil Babka,
damon, kunit-dev, linux-doc, linux-kernel, linux-kselftest,
linux-mm
Five patches for miscellaneous DAMON fixups. Use better fit kernel
functions, cleanup/fixup documents, and add unit tests.
Below is a note that is better to drop from the final commit message.
The five patches were initially sent and revisioned by different
individuals. Each patch contains changelog on their commentary area.
The patches are curated into this series by SJ, for the convenience in
reposting.
Akinobu Mita (1):
mm/damon/core: use kvmalloc for target regions array
Asier Gutierrez (1):
samples/damon: Fix typos in Kconfig help text
Doehyun Baek (1):
Docs/{admin-guide,mm}/damon: fix DAMON documentation details
Philippe Laferriere (1):
mm/damon/stat: use secs_to_jiffies() instead of msecs_to_jiffies()
Sailesh Nandanavanam (1):
mm/damon/tests/core-kunit: add KUnit test for walk_control_obsolete
behavior
Documentation/admin-guide/mm/damon/usage.rst | 8 +++---
Documentation/mm/damon/design.rst | 12 ++++-----
mm/damon/core.c | 4 +--
mm/damon/stat.c | 2 +-
mm/damon/tests/core-kunit.h | 28 ++++++++++++++++++++
samples/damon/Kconfig | 2 +-
6 files changed, 42 insertions(+), 14 deletions(-)
base-commit: 58a53a487b7a86995fdfba07723fb8416fccf830
--
2.47.3
^ permalink raw reply
* [PATCH 3/5] Docs/{admin-guide,mm}/damon: fix DAMON documentation details
From: SJ Park @ 2026-06-29 14:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Doehyun Baek, Liam R. Howlett, David Hildenbrand, Jonathan Corbet,
Lorenzo Stoakes, Michal Hocko, Mike Rapoport, SJ Park, Shuah Khan,
Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260629145538.134832-1-sj@kernel.org>
From: Doehyun Baek <doehyunbaek@gmail.com>
Fix minor DAMON documentation issues. Correct the sysfs scheme file name
apply_interval_us, the DAMON_STAT module count, a malformed reference, a
misplaced label indentation, and a few typos.
Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: "Liam R. Howlett" <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Signed-off-by: SJ Park <sj@kernel.org>
---
Changes from v5
- v5: https://lore.kernel.org/20260610053951.553739-1-doehyunbaek@gmail.com
- Collect R-b: from SJ.
- Rebase to latest mm-new.
Documentation/admin-guide/mm/damon/usage.rst | 8 ++++----
Documentation/mm/damon/design.rst | 12 ++++++------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 011296f1e7c21..b2649ea011f93 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -246,7 +246,7 @@ writing to and reading from the files.
Under ``nr_regions`` directory, two files for the lower-bound and upper-bound
of DAMON's monitoring regions (``min`` and ``max``, respectively), which
controls the monitoring overhead, exist. You can set and get the values by
-writing to and rading from the files.
+writing to and reading from the files.
For more details about the intervals and monitoring regions range, please refer
to the Design document (:doc:`/mm/damon/design`).
@@ -264,7 +264,7 @@ Please refer to the :ref:`design document of the feature
<damon_design_monitoring_intervals_autotuning>` for the internal of the tuning
mechanism. Reading and writing the four files under ``intervals_goal``
directory shows and updates the tuning parameters that described in the
-:ref:design doc <damon_design_monitoring_intervals_autotuning>` with the same
+:ref:`design doc <damon_design_monitoring_intervals_autotuning>` with the same
names. The tuning starts with the user-set ``sample_us`` and ``aggr_us``. The
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
@@ -377,7 +377,7 @@ schemes/<N>/
In each scheme directory, nine directories (``access_pattern``, ``quotas``,
``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``dests``,
``stats``, and ``tried_regions``) and three files (``action``, ``target_nid``
-and ``apply_interval``) exist.
+and ``apply_interval_us``) exist.
The ``action`` file is for setting and getting the scheme's :ref:`action
<damon_design_damos_action>`. The keywords that can be written to and read
@@ -743,7 +743,7 @@ counter). Finally the tenth field (``X``) shows the ``age`` of the region
(refer to :ref:`design <damon_design_age_tracking>` for more details of the
counter).
-If the event was ``damon:damos_beofre_apply``, the ``perf script`` output would
+If the event was ``damon:damos_before_apply``, the ``perf script`` output would
be somewhat like below::
kdamond.0 47293 [000] 80801.060214: damon:damos_before_apply: ctx_idx=0 scheme_idx=0 target_idx=0 nr_regions=11 121932607488-135128711168: 0 136
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 2da7ca0d3d17a..c16a3bb288d07 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -86,7 +86,7 @@ To know how user-space can do the configuration via :ref:`DAMON sysfs interface
documentation.
- .. _damon_design_vaddr_target_regions_construction:
+.. _damon_design_vaddr_target_regions_construction:
VMA-based Target Address Range Construction
-------------------------------------------
@@ -930,11 +930,11 @@ control parameters for the usage would also need to be optimized for the
purpose.
To support such cases, yet more DAMON API user kernel modules that provide more
-simple and optimized user space interfaces are available. Currently, two
-modules for proactive reclamation and LRU lists manipulation are provided. For
-more detail, please read the usage documents for those
-(:doc:`/admin-guide/mm/damon/stat`, :doc:`/admin-guide/mm/damon/reclaim` and
-:doc:`/admin-guide/mm/damon/lru_sort`).
+simple and optimized user space interfaces are available. Currently, three
+modules for access monitoring statistics, proactive reclamation, and LRU lists
+manipulation are provided. For more detail, please read the usage documents for
+those (:doc:`/admin-guide/mm/damon/stat`, :doc:`/admin-guide/mm/damon/reclaim`
+and :doc:`/admin-guide/mm/damon/lru_sort`).
.. _damon_design_special_purpose_modules_exclusivity:
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v20 01/14] dmaengine: constify struct dma_descriptor_metadata_ops
From: Pandey, Radhey Shyam @ 2026-06-29 15:04 UTC (permalink / raw)
To: Bartosz Golaszewski, Vinod Koul, Jonathan Corbet, Thara Gopinath,
Herbert Xu, David S. Miller, Udit Tiwari, Md Sadre Alam,
Dmitry Baryshkov, Manivannan Sadhasivam, Stephan Gerhold,
Bjorn Andersson, Peter Ujfalusi, Michal Simek, Frank Li,
Andy Gross, Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260629-qcom-qce-cmd-descr-v20-1-56f67da84c05@oss.qualcomm.com>
> There's no reason for the instances of this struct to be modifiable.
> Constify the pointer in struct dma_async_tx_descriptor and all drivers
> currently using it.
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> ---
> drivers/dma/ti/k3-udma.c | 2 +-
> drivers/dma/xilinx/xilinx_dma.c | 2 +-
> include/linux/dmaengine.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 1cf158eb7bdb541c4e7f4f79f65ab70be4311fad..fb21e0df5ab7b20e4e16777b5ff7f61d2ae67b2b 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -3408,7 +3408,7 @@ static int udma_set_metadata_len(struct dma_async_tx_descriptor *desc,
> return 0;
> }
>
> -static struct dma_descriptor_metadata_ops metadata_ops = {
> +static const struct dma_descriptor_metadata_ops metadata_ops = {
> .attach = udma_attach_metadata,
> .get_ptr = udma_get_metadata_ptr,
> .set_len = udma_set_metadata_len,
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 404235c1735384635597e88edc25c67c7d250647..165b11a7c776abc6a8d66d631e19da669644577d 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -653,7 +653,7 @@ static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
> return seg->hw.app;
> }
>
> -static struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
> +static const struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
> .get_ptr = xilinx_dma_get_metadata_ptr,
> };
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index b3d251c9734e95e1b75cf6763d4d2c3a1c6a9910..5244edb90e7e7510bf4460b6a74ee2a7f91c1ccc 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -623,7 +623,7 @@ struct dma_async_tx_descriptor {
> void *callback_param;
> struct dmaengine_unmap_data *unmap;
> enum dma_desc_metadata_mode desc_metadata_mode;
> - struct dma_descriptor_metadata_ops *metadata_ops;
> + const struct dma_descriptor_metadata_ops *metadata_ops;
> #ifdef CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH
> struct dma_async_tx_descriptor *next;
> struct dma_async_tx_descriptor *parent;
>
^ permalink raw reply
* Re: [PATCH] sched/topology: Allow EAS without schedutil for artificial Energy Models
From: Rafael J. Wysocki (Intel) @ 2026-06-29 15:16 UTC (permalink / raw)
To: Lucas de Lima Nóbrega
Cc: rafael, viresh.kumar, mingo, peterz, juri.lelli, vincent.guittot,
dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, corbet, skhan, linux-pm, linux-doc, linux-kernel
In-Reply-To: <20260629083542.10041-1-lucaslnobrega38@gmail.com>
On Mon, Jun 29, 2026 at 10:36 AM Lucas de Lima Nóbrega
<lucaslnobrega38@gmail.com> wrote:
>
> EAS currently refuses to enable energy-aware scheduling on a root
> domain unless schedutil is the active CPUFreq governor for all of its
> CPUs (cpufreq_ready_for_eas()). This requirement exists to protect the
> accuracy of the energy estimate: EAS predicts the OPP a CPU will run
> at from its utilization, which is only meaningful if the active
> governor actually requests OPPs that way, and schedutil is the only
> one that does.
>
> That requirement does not apply to artificial Energy Models
> (EM_PERF_DOMAIN_ARTIFICIAL). An artificial EM is built from a
> get_cost() callback instead of real power numbers, and only encodes a
> cost ranking between CPUs (e.g. P-cores cost more than E-cores at a
> given utilization). It never claims to predict real energy use at any
> specific OPP, so there is no per-OPP accuracy for the governor
> requirement to protect, regardless of which governor is in control or
> whether it tracks utilization at all.
But it is still about comparing the cost of running on different CPUs
at different performance levels.
For instance, say the scale-invariant utilization of a task is 256 and
it can run either by itself on a P-core, or with another task whose
utilization is 128 on an E-core, and say the P-core's and E-core's
capacity is 1024 and 512, respectively.
Say the cost function tells EAS that running a P-core at 1/4 of the
capacity is cheaper than running an E-core at 3/4 capacity, so it will
pick up the P-core to run that task, but if cpufreq ramps up the
frequency of the P-core to the max when the task gets to it, it may
actually turn out to be more expensive.
This means that EAS still has an expectation regarding cpufreq which
is that it will generally tend to run tasks at the performance level
corresponding to the sum of their scale-invariant utilization at least
roughly.
IIUC this actually has nothing to do with whether or not the energy
model used by EAS is artificial. The schedutil requirement is about
choosing a performance level proportional to the utilization (which
schedutil generally tends to do by design).
> intel_pstate registers exactly this kind of artificial EM for hybrid
> (P/E-core) systems without SMT, regardless of whether it operates in
> active or passive mode. In active mode it never uses schedutil, since
> HWP picks frequency autonomously, so on these systems EAS never
> engages even though SD_ASYM_CPUCAPACITY, frequency invariance and the
> EM are all in place: find_energy_efficient_cpu() is never reached
> because is_rd_overutilized() is hardcoded to true whenever
> sched_energy_enabled() is false. cppc_cpufreq registers the same kind
> of ranking-only artificial EM and is affected the same way with any
> non-schedutil governor.
>
> Allow EAS to be enabled when every CPU's EM in the root domain is
> artificial, even when schedutil is not the active governor.
>
> Tested on a Raptor Lake-P laptop with nosmt=force and intel_pstate in
> active/HWP mode: find_energy_efficient_cpu() was never called before
> this change (confirmed via the sched_overutilized_tp tracepoint and
> ftrace) and is exercised as expected afterwards.
If this is about allowing EAS to work with intel_pstate running in the
active mode, you may argue that what the processor firmware is doing
when intel_pstate runs in the active mode is not much different from
what schedutil would do. So a driver implementing an internal
governor (that is, using the .set_policy() callback) would need to
declare that its internal governor is as good as schedutil from EAS'
perspective and so it will pass the "cpufreq readiness" check.
> Signed-off-by: Lucas de Lima Nóbrega <lucaslnobrega38@gmail.com>
> ---
> Documentation/admin-guide/pm/intel_pstate.rst | 9 ++++--
> Documentation/scheduler/sched-energy.rst | 7 ++++-
> kernel/sched/topology.c | 28 +++++++++++++++++--
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst
> index 25fe5d88f..c8fef1e60 100644
> --- a/Documentation/admin-guide/pm/intel_pstate.rst
> +++ b/Documentation/admin-guide/pm/intel_pstate.rst
> @@ -409,13 +409,16 @@ Energy-Aware Scheduling Support
> If ``CONFIG_ENERGY_MODEL`` has been set during kernel configuration and
> ``intel_pstate`` runs on a hybrid processor without SMT, in addition to enabling
> :ref:`CAS` it registers an Energy Model for the processor. This allows the
> -Energy-Aware Scheduling (EAS) support to be enabled in the CPU scheduler if
> -``schedutil`` is used as the ``CPUFreq`` governor which requires ``intel_pstate``
> -to operate in the :ref:`passive mode <passive_mode>`.
> +Energy-Aware Scheduling (EAS) support to be enabled in the CPU scheduler.
>
> The Energy Model registered by ``intel_pstate`` is artificial (that is, it is
> based on abstract cost values and it does not include any real power numbers)
> and it is relatively simple to avoid unnecessary computations in the scheduler.
> +Because of that, EAS does not require ``schedutil`` to be used as the
> +``CPUFreq`` governor in this case: the cost ranking it relies on does not
> +depend on the governor tracking utilization when requesting frequencies, so
> +EAS works the same way regardless of whether ``intel_pstate`` operates in the
> +active or in the :ref:`passive mode <passive_mode>`.
> There is a performance domain in it for every CPU in the system and the cost
> values for these performance domains have been chosen so that running a task on
> a less performant (small) CPU appears to be always cheaper than running that
> diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst
> index 4e47aaf10..c23ca226d 100644
> --- a/Documentation/scheduler/sched-energy.rst
> +++ b/Documentation/scheduler/sched-energy.rst
> @@ -379,7 +379,12 @@ Consequently, the only sane governor to use together with EAS is schedutil,
> because it is the only one providing some degree of consistency between
> frequency requests and energy predictions.
>
> -Using EAS with any other governor than schedutil is not supported.
> +Using EAS with any other governor than schedutil is not supported, unless the
> +EM in use is artificial (see EM_PERF_DOMAIN_ARTIFICIAL). An artificial EM only
> +encodes a cost ranking between CPUs/OPPs instead of a real power table, so it
> +does not make any claim about energy use at a specific OPP and its conclusions
> +do not depend on the governor actually tracking utilization when requesting
> +frequencies.
>
>
> 6.5 Scale-invariant utilization signals
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 5847b83d9..124a4bb4d 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -212,6 +212,27 @@ static unsigned int sysctl_sched_energy_aware = 1;
> static DEFINE_MUTEX(sched_energy_mutex);
> static bool sched_energy_update;
>
> +/*
> + * An artificial EM (see EM_PERF_DOMAIN_ARTIFICIAL) only encodes a cost
> + * ranking between CPUs and does not claim to predict energy use at any
> + * particular OPP. Unlike a real power-based EM, its conclusions do not
> + * rely on the active governor tracking utilization when selecting
> + * frequencies, so the schedutil requirement below does not apply to it.
> + */
> +static bool perf_domains_are_artificial(const struct cpumask *cpu_mask)
> +{
> + int i;
> +
> + for_each_cpu(i, cpu_mask) {
> + struct em_perf_domain *pd = em_cpu_get(i);
I would do
if (!pd)
continue;
here because the CPUs without a PD simply don't matter.
Also, is any synchronization needed for this?
And should it go into the EM code?
> +
> + if (!pd || !em_is_artificial(pd))
> + return false;
> + }
> +
> + return true;
> +}
> +
> static bool sched_is_eas_possible(const struct cpumask *cpu_mask)
> {
> bool any_asym_capacity = false;
> @@ -249,7 +270,8 @@ static bool sched_is_eas_possible(const struct cpumask *cpu_mask)
> return false;
> }
>
> - if (!cpufreq_ready_for_eas(cpu_mask)) {
> + if (!cpufreq_ready_for_eas(cpu_mask) &&
> + !perf_domains_are_artificial(cpu_mask)) {
> if (sched_debug()) {
> pr_info("rd %*pbl: Checking EAS: cpufreq is not ready\n",
> cpumask_pr_args(cpu_mask));
> @@ -403,7 +425,9 @@ static void sched_energy_set(bool has_eas)
> * 1. an Energy Model (EM) is available;
> * 2. the SD_ASYM_CPUCAPACITY flag is set in the sched_domain hierarchy.
> * 3. no SMT is detected.
> - * 4. schedutil is driving the frequency of all CPUs of the rd;
> + * 4. schedutil is driving the frequency of all CPUs of the rd, or the EM
> + * of all of them is artificial (i.e. a cost ranking rather than a
> + * real power table, see EM_PERF_DOMAIN_ARTIFICIAL);
> * 5. frequency invariance support is present;
> */
> static bool build_perf_domains(const struct cpumask *cpu_map)
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Maxime Chevallier @ 2026-06-29 15:24 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski
Cc: davem, Eric Dumazet, Paolo Abeni, Simon Horman, Russell King,
Heiner Kallweit, Jonathan Corbet, Shuah Khan, Oleksij Rempel,
Vladimir Oltean, Florian Fainelli, thomas.petazzoni, netdev,
linux-kernel, linux-doc
In-Reply-To: <3b8abe17-5da7-4a7e-a42c-eb39a631843e@lunn.ch>
Hi Jakub, Andrew,
On 6/28/26 01:46, Andrew Lunn wrote:
> On Sat, Jun 27, 2026 at 02:30:28PM -0700, Jakub Kicinski wrote:
>> On Sat, 27 Jun 2026 07:34:31 +0200 Maxime Chevallier wrote:
>>>> This is very far from what existing python tests do in netdev.
>>>
>>> We can probably drop the class, as it is with this discussion, it's merely a way
>>> to regroup doc common to similar tests. The rest really is the usual set of
>>> ksft funcs you can feed to the run function, with a set of ksft_ethtool_*
>>> annotators for generic checks.
>>
>> The common way of checking prereqs in the tests is to call a function
>> called require_xyz() which then raises a skip. At a quick glance - the
>> rss_api and xdp_metadata are good tests to get a sense of the usual format.
>
> The counter example is the ksft_disruptive() decorator.
>
> Pythons own unittest framework makes use of decorators to skip
> tests. Its the Pythonic way.
So maybe in the end, we can try to have something a bit less python-y, while still
using extensive documentation using sphynx doc format ?
Let me send a V2 with the full test list, we'll see how much scaffolding
we can build for ethtool testing, and how. I suspect that running/skipping based on
the device's capabilities is going to be used throughout lots of tests
beyond pause.
For now the important part is to get that test list right, and iterate on the
test implementation once we agree on what to test, why and how.
Maxime
^ permalink raw reply
* Re: [PATCH RFC v6 0/5] iio: add Open Sensor Fusion IIO driver
From: David Lechner @ 2026-06-29 15:25 UTC (permalink / raw)
To: Jinseob Kim, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260628191337.937-1-kimjinseob88@gmail.com>
On 6/28/26 2:13 PM, Jinseob Kim wrote:
> Open Sensor Fusion (OSF) devices expose a UART/serdev host interface
> for a sensor aggregation hub. This RFC adds a Linux IIO driver that
> parses OSF frames and creates IIO devices at runtime from capability
> reports provided by the device firmware.
>
> When the corresponding capabilities are reported, the driver exposes
> accelerometer, gyroscope, magnetometer, and temperature data as IIO
> devices named osf-accel, osf-gyro, osf-magn, and osf-temp.
>
> This remains RFC while the binding, protocol subset, runtime discovery
> model, and driver-facing ABI are reviewed.
If you are just looking for review and don't have specific questions,
then it is time to drop the RFC.
^ permalink raw reply
* [PATCH v2] docs: kernel-hacking: fix typo
From: Manuel Ebner @ 2026-06-29 15:29 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Vlastimil Babka, SeongJae Park,
open list:DOCUMENTATION, open list
Cc: Manuel Ebner
'GP_KERNEL' -> 'GFP_KERNEL'
Remove trailing '`' without clear purpose
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/kernel-hacking/locking.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index c969c76ef7cb..674475123593 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -1317,7 +1317,7 @@ from user context, and can sleep.
- put_user()
-- kmalloc(GP_KERNEL) <kmalloc>`
+- kmalloc(GFP_KERNEL) <kmalloc>
- mutex_lock_interruptible() and
mutex_lock()
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 7/8] dt-bindings: riscv: Add binding for CBQRI controllers
From: Conor Dooley @ 2026-06-29 15:32 UTC (permalink / raw)
To: Drew Fustini
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, linux-kernel, linux-riscv,
x86, devicetree, linux-rt-devel, linux-doc
In-Reply-To: <20260628-dfustini-atl-sc-cbqri-dt-v3-7-c9c1342fe3cf@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Sun, Jun 28, 2026 at 02:18:18PM -0700, Drew Fustini wrote:
> Document the device tree binding for RISC-V CBQRI capacity and bandwidth
> controllers. Each controller is named by a device-specific compatible
> followed by the generic compatible. The binding also describes the
> common riscv,cbqri-rcid and riscv,cbqri-mcid properties, and the
> optional riscv,cbqri-cache phandle that links a capacity controller to
> the cache whose capacity it allocates.
>
> Assisted-by: Claude:claude-opus-4-8
> Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Drew Fustini <fustini@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2] Documentation: device-mapper: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-06-29 15:35 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Mikulas Patocka,
Benjamin Marzinski, Jonathan Corbet, Shuah Khan,
open list:DEVICE-MAPPER (LVM), open list:DOCUMENTATION,
open list
Cc: Manuel Ebner
Change the Documentation to reflect this commit 69050f8d6d07 ("treewide: Replace
kmalloc with kmalloc_obj for non-scalar types")
kmalloc -> kmalloc_objs()
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
[v2]
added '()' for automarkup
Documentation/admin-guide/device-mapper/statistics.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/device-mapper/statistics.rst b/Documentation/admin-guide/device-mapper/statistics.rst
index 41ded0bc5933..517b6d576826 100644
--- a/Documentation/admin-guide/device-mapper/statistics.rst
+++ b/Documentation/admin-guide/device-mapper/statistics.rst
@@ -30,7 +30,7 @@ region, etc. Unique region_ids enable multiple userspace programs to
request and process statistics for the same DM device without stepping
on each other's data.
-The creation of DM statistics will allocate memory via kmalloc or
+The creation of DM statistics will allocate memory via kmalloc_objs() or
fallback to using vmalloc space. At most, 1/4 of the overall system
memory may be allocated by DM statistics. The admin can see how much
memory is used by reading:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC v6 1/5] dt-bindings: iio: add Open Sensor Fusion device
From: Conor Dooley @ 2026-06-29 15:39 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260628191337.937-2-kimjinseob88@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]
On Mon, Jun 29, 2026 at 04:13:33AM +0900, Jinseob Kim wrote:
> Add a binding for the generic Open Sensor Fusion host interface.
>
> Open Sensor Fusion devices report capabilities and samples over an OSF
> protocol stream. Sensor channels are discovered at runtime from
> capability reports instead of being described individually in Device
> Tree.
>
> The protocol version is discovered at runtime from the OSF frame header.
> OSF GREEN is a product identity, and OSF0 is a wire-format magic value,
> so neither is used as the Linux compatible string.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> ---
> .../bindings/iio/opensensorfusion,osf.yaml | 54 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 6 +++
> 3 files changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> new file mode 100644
> index 000000000..8016d582f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Open Sensor Fusion Sensor Aggregation Hub
> +
> +maintainers:
> + - Jinseob Kim <kimjinseob88@gmail.com>
> +
> +description: |
> + This binding documents the generic Open Sensor Fusion host interface. Open
> + Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF protocol
> + data stream over its host interface and reports capabilities and samples for
> + multiple sensor classes. The actual sensor channels are discovered at runtime
> + from OSF capability reports instead of describing them in Device Tree. The
> + protocol version is discovered at runtime.
> +
> + Public project documentation is available at:
> +
> + https://github.com/opensensorfusion
> +
> + The compatible describes the generic Open Sensor Fusion host interface.
> It
> + is not an OSF GREEN board identity, and it does not encode the OSF0 wire
> + magic.
I think this is evident from the previous text, and the first part is a
bit confusing while the latter half is a bit confusing.
Just remove this sentence I think.
Binding looks fine to me, I'll provide a r-b when you submit a non-RFC
version.
pw-bot: not-applicable
Thanks,
Conor.
> OSF0, protocol_major, and protocol_minor are wire-protocol details
> + exchanged in OSF frames.
> +
> +allOf:
> + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + const: opensensorfusion,osf
> +
> + vcc-supply:
> + description:
> + Regulator supplying power to the Open Sensor Fusion device.
> +
> +required:
> + - compatible
> + - vcc-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + serial {
> + sensor {
> + compatible = "opensensorfusion,osf";
> + vcc-supply = <&vcc_sensor>;
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66a..88172d4a4 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1237,6 +1237,8 @@ patternProperties:
> description: OpenPandora GmbH
> "^openrisc,.*":
> description: OpenRISC.io
> + "^opensensorfusion,.*":
> + description: Open Sensor Fusion
> "^openwrt,.*":
> description: OpenWrt
> "^option,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c2c6d7927..e4df9d8dc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20011,6 +20011,12 @@ F: Documentation/devicetree/
> F: arch/*/boot/dts/
> F: include/dt-bindings/
>
> +OPEN SENSOR FUSION
> +M: Jinseob Kim <kimjinseob88@gmail.com>
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> +K: opensensorfusion
> +
> OPENCOMPUTE PTP CLOCK DRIVER
> M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> L: netdev@vger.kernel.org
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] hwmon: ltc4283: fix malformed table docs build error
From: Guenter Roeck @ 2026-06-29 15:48 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-doc, Nuno Sá, linux-hwmon
In-Reply-To: <20260620011833.3568693-1-rdunlap@infradead.org>
On Fri, Jun 19, 2026 at 06:18:30PM -0700, Randy Dunlap wrote:
> Expand the table borders (upper & lower) to prevent a documentation
> build error:
>
> Documentation/hwmon/ltc4283.rst:261: ERROR: Malformed table.
> Text in column margin in table line 3.
> ======================= ==========================================
> power1_failed_fault_log Set to 1 by a power1 fault occurring.
> power1_good_input_fault_log Set to 1 by a power1 good input fault occurring at PGIO3.
>
> Fixes: dd63353a0b5e ("hwmon: ltc4283: Add support for the LTC4283 Swap Controller")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v10 6/6] selftests/mm: add hwpoison-panic destructive test
From: Breno Leitao @ 2026-06-29 15:50 UTC (permalink / raw)
To: Mike Rapoport
Cc: Miaohe Lin, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Shuah Khan,
Naoya Horiguchi, Jonathan Corbet, Shuah Khan, Liam R. Howlett,
lance.yang, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <aj-BShkN6BXex_ku@kernel.org>
On Sat, Jun 27, 2026 at 10:52:42AM +0300, Mike Rapoport wrote:
> Hi Breno,
>
> On Fri, Jun 26, 2026 at 08:33:20AM -0700, Breno Leitao wrote:
> > Add a destructive selftest that verifies
> > vm.panic_on_unrecoverable_memory_failure actually panics when a
> > hwpoison error hits a kernel-owned page.
>
> > +ksft_skip=4
>
> ...
>
> > +ksft_print() { echo "# $*"; }
> > +ksft_exit_skip() { ksft_print "$*"; exit "$ksft_skip"; }
> > +ksft_exit_fail() { echo "not ok 1 $*"; exit 1; }
>
> There is tools/testing/selftests/kselftest/ktap_helpers.sh that already
> implements this :)
Ack, let me source that file in my selftest.
DIR="$(dirname "$(readlink -f "$0")")"
source "${DIR}"/../kselftest/ktap_helpers.sh
I will update, thanks for the review,
--breno
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: Guenter Roeck @ 2026-06-29 15:58 UTC (permalink / raw)
To: Flaviu Nistor
Cc: Javier Carrasco, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, linux-kernel,
devicetree, linux-doc
In-Reply-To: <20260625160423.17882-1-flaviu.nistor@gmail.com>
On Thu, Jun 25, 2026 at 07:04:22PM +0300, Flaviu Nistor wrote:
> Add support for an optional label property similar to other hwmon devices.
> This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
> distinct names to each instance.
>
> Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: (chipcap2) Add support for label
From: Guenter Roeck @ 2026-06-29 15:58 UTC (permalink / raw)
To: Flaviu Nistor
Cc: Javier Carrasco, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, linux-kernel,
devicetree, linux-doc
In-Reply-To: <20260625160423.17882-2-flaviu.nistor@gmail.com>
On Thu, Jun 25, 2026 at 07:04:23PM +0300, Flaviu Nistor wrote:
> Add support for label sysfs attribute similar to other hwmon devices.
> This is particularly useful for systems with multiple sensors on the
> same board, where identifying individual sensors is much easier since
> labels can be defined via device tree.
>
> Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
> Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v7 07/15] mm: preserve RWP marker across PTE rewrites
From: Kiryl Shutsemau @ 2026-06-29 16:02 UTC (permalink / raw)
To: sashiko-reviews, akpm, rppt, peterx, david
Cc: kvm, ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan,
seanjc, pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kernel-team
In-Reply-To: <20260629123320.1EF891F000E9@smtp.kernel.org>
On Mon, Jun 29, 2026 at 12:33:19PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Critical] do_swap_page bypasses RWP tracking on non-exclusive private pages by resolving COW faults internally, dropping the RWP marker.
Okay, this one is real. I will add test-case for it and fix in v8.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH] cxl: docs/linux/dax-driver - fix typos
From: Dave Jiang @ 2026-06-29 16:06 UTC (permalink / raw)
To: Zenghui Yu, linux-cxl, linux-doc, linux-kernel
Cc: dave, jic23, alison.schofield, vishal.l.verma, ira.weiny, djbw,
gourry, corbet, skhan
In-Reply-To: <20260614161458.88942-1-zenghui.yu@linux.dev>
On 6/14/26 9:14 AM, Zenghui Yu wrote:
> Fix two obvious typos in the "kmem conversion" section.
>
> Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Applied to cxl/next
a667f1eb71a7
> ---
> Documentation/driver-api/cxl/linux/dax-driver.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/driver-api/cxl/linux/dax-driver.rst b/Documentation/driver-api/cxl/linux/dax-driver.rst
> index 10d953a2167b..72c85a0f8606 100644
> --- a/Documentation/driver-api/cxl/linux/dax-driver.rst
> +++ b/Documentation/driver-api/cxl/linux/dax-driver.rst
> @@ -35,9 +35,9 @@ will be exposed to the kernel page allocator in the user-selected memory
> zone.
>
> The :code:`memmap_on_memory` setting (both global and DAX device local)
> -dictates where the kernell will allocate the :code:`struct folio` descriptors
> +dictates where the kernel will allocate the :code:`struct folio` descriptors
> for this memory will come from. If :code:`memmap_on_memory` is set, memory
> hotplug will set aside a portion of the memory block capacity to allocate
> folios. If unset, the memory is allocated via a normal :code:`GFP_KERNEL`
> -allocation - and as a result will most likely land on the local NUM node of the
> +allocation - and as a result will most likely land on the local NUMA node of the
> CPU executing the hotplug operation.
^ 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