* Re: [PATCH v2 5/6] misc: amd-sbi: Add SBTSI ioctl register transfer interface
From: Gupta, Akshay @ 2026-05-28 5:49 UTC (permalink / raw)
To: Guenter Roeck, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org
Cc: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
gregkh@linuxfoundation.org, Chatradhi, Naveen Krishna,
L k, Prathima, Umarji, Anand, Kevin.Tung@quantatw.com
In-Reply-To: <54160fbb-01d9-400b-80f7-bf340997a8d0@roeck-us.net>
On 5/15/2026 7:41 PM, Guenter Roeck wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 5/15/26 06:45, Akshay Gupta wrote:
>> From: Prathima <Prathima.Lk@amd.com>
>>
>> Implement IOCTL interface for SB-TSI driver to enable userspace access
>> to TSI register read/write operations through the AMD Advanced Platform
>> Management Link (APML) protocol.
>> Add an ioctl command (SBTSI_IOCTL_REG_XFER_CMD) that accepts a register
>> address, data byte, and direction flag. Serialize access with a mutex
>> shared between the hwmon and ioctl paths to prevent concurrent bus
>> transactions from corrupting register state.
>>
>> Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
>> Signed-off-by: Prathima <Prathima.Lk@amd.com>
>> ---
>> Changes since v1:
>> - Use of devm_mutex_init in place of mutex_init
>> - Use of guard_mutex in place of mutex_lock()/mutex_unlock()
>> - Use of devm_add_action_or_reset() for clean removal
>>
>> drivers/hwmon/sbtsi_temp.c | 6 +++
>> drivers/misc/amd-sbi/tsi-core.c | 84 ++++++++++++++++++++++++++++++++-
>> drivers/misc/amd-sbi/tsi-core.h | 15 ++++++
>> drivers/misc/amd-sbi/tsi.c | 20 ++++++--
>> include/linux/misc/tsi.h | 8 ++++
>> include/uapi/misc/amd-apml.h | 23 +++++++++
>> 6 files changed, 151 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/misc/amd-sbi/tsi-core.h
>>
>> diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
>> index d7ae986d824c..00e982f4c716 100644
>> --- a/drivers/hwmon/sbtsi_temp.c
>> +++ b/drivers/hwmon/sbtsi_temp.c
>> @@ -64,12 +64,15 @@ static inline void sbtsi_mc_to_reg(s32 temp, u8 *integer, u8 *decimal)
>> /*
>> * Read integer and decimal parts of an SB-TSI temperature register pair
>> * The read order is determined by the ReadOrder bit to ensure atomic latching.
>> + * The mutex protects against concurrent access to the shared I2C/I3C bus by
>> + * the hwmon sysfs and a userspace ioctl
>> */
>> static int sbtsi_temp_read(struct sbtsi_data *data, u8 reg1, u8 reg2,
>> u8 *val1, u8 *val2)
>> {
>> int ret;
>>
>> + guard(mutex)(&data->lock);
> I would suggest to hide this behind access functions such as sbtsi_lock(),
> sbtsi_unlock(), and the matching guard functions. That can be done in a
> separate patch; it should not be necessary to include hwmon in the patch
> introducing the ioctl.
>
> Thanks,
> Guenter
Thank you for the feedback, Guenter.
In the next version, we will address this by implementing the matching
guard function in the ioctl patch and creating a new patch for hwmon.
>
^ permalink raw reply
* [PATCH] iommu: Documentation: rearrange, update kernel-parameters
From: Randy Dunlap @ 2026-05-28 5:46 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jonathan Corbet, Shuah Khan, linux-doc,
Joerg Roedel, Will Deacon, Robin Murphy, iommu, Borislav Petkov
Add text for some undescribed iommu= parameters (merge, nomerge,
biomerge, panic, nopanic, pt, nopt). Add "usedac" and its description.
Add that iommu=pt is equivalent to iommu.passthrough=1
and that iommu=nopt is equivalent to iommu.passthrough=0.
Move the PPC/POWERNV heading & its option "nobypass" to a separate
area since the current "iommu=" applies only to X86 (according to
its heading).
Unindent the AMD GART IOMMU options heading to make it stand out.
Also add its kconfig symbol name to be explicit about what these
options apply to.
Make sure that the IOMMU options that are listed under AMD Gart
HW IOMMU-specific options are only for that product; i.e., add "force"
there and move "merge", "nomerge", and "panic" to the general IOMMU
options area.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
NB: Wording suggestions welcome.
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: iommu@lists.linux.dev
Cc: Borislav Petkov <bp@alien8.de>
Documentation/admin-guide/kernel-parameters.txt | 48 +++++++++-----
1 file changed, 32 insertions(+), 16 deletions(-)
--- linux-next-20260527.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20260527/Documentation/admin-guide/kernel-parameters.txt
@@ -2548,23 +2548,41 @@ Kernel parameters
Don't force hardware IOMMU usage when it is not
needed. (default).
+ merge
+ Do scatter-gather (SG) merging. Implies "force"
+ (experimental).
+
+ nomerge
+ Don't do scatter-gather (SG) merging.
+
biomerge
+ Do scatter-gather (SG) merging. Implies "force"
+ (experimental). [same as "merge"]
+
panic
+ Always panic when IOMMU overflows.
+
nopanic
- merge
- nomerge
+ Don't panic on IOMMU overflows.
+
+ pt
+ Use passththrough mode by default
+ (Equivalent to iommu.passthrough=1)
+
+ nopt
+ Use translated mode for DMA by default
+ (Equivalent to iommu.passthrough=0)
soft
Use software bounce buffering (SWIOTLB) (default for
Intel machines). This can be used to prevent the usage
of an available hardware IOMMU.
- pt
- nopt
- nobypass [PPC/POWERNV]
- Disable IOMMU bypass, using IOMMU for PCI devices.
+ usedac
+ Use the DAC on VIA PCI bridge
+ (default: disable the VIA PCI bridge DAC)
- AMD Gart HW IOMMU-specific options:
+ AMD Gart HW IOMMU-specific options: (CONFIG_GART_IOMMU)
<size>
Set the size of the remapping area in bytes.
@@ -2572,6 +2590,9 @@ Kernel parameters
allowed
Overwrite iommu off workarounds for specific chipsets
+ force
+ Overwrite iommu off workarounds for specific chipsets
+
fullflush
Flush IOMMU on each allocation (default).
@@ -2582,21 +2603,16 @@ Kernel parameters
Allocate an own aperture over RAM with size
32MB<<order. (default: order=1, i.e. 64MB)
- merge
- Do scatter-gather (SG) merging. Implies "force"
- (experimental).
-
- nomerge
- Don't do scatter-gather (SG) merging.
-
noaperture
Ask the IOMMU not to touch the aperture for AGP.
noagp
Don't initialize the AGP driver and use full aperture.
- panic
- Always panic when IOMMU overflows.
+ iommu= [PPC/POWERNV]
+
+ nobypass
+ Disable IOMMU bypass, using IOMMU for PCI devices.
iommu.forcedac= [ARM64,X86,EARLY] Control IOVA allocation for PCI devices.
Format: { "0" | "1" }
^ permalink raw reply
* Re: [PATCH v10 1/4] HID: hid-msi: Add MSI Claw configuration driver
From: Dmitry Torokhov @ 2026-05-28 5:32 UTC (permalink / raw)
To: Derek J. Clark
Cc: Jiri Kosina, Benjamin Tissoires, Pierre-Loup A . Griffais,
Denis Benato, Zhouwang Huang, linux-input, linux-doc,
linux-kernel
In-Reply-To: <20260527222122.10620-2-derekjohn.clark@gmail.com>
Hi Derek,
On Wed, May 27, 2026 at 10:21:19PM +0000, Derek J. Clark wrote:
> Adds configuration HID driver for the MSI Claw series of handheld PC's.
> In this initial patch add the initial driver outline and attributes for
> changing the gamepad mode, M-key behavior, and add a WO reset function.
>
> Sending the SWITCH_MODE and RESET commands causes a USB disconnect in
> the device. The completion will therefore never get hit and would trigger
> an -EIO. To avoid showing the user an error for every write to these
> attrs a bypass for the completion handling is introduced when timeout ==
> 0.
>
> The initial version of this patch was written by Denis Benato, which
> contained the initial reverse-engineering and implementation for the
> gamepad mode switching. This work was later expanded by Zhouwang Huang
> to include more gamepad modes. Finally, I refactored the drivers data
> in/out flow and overall format to conform to kernel driver best
> practices and style guides. Claude was used as an initial reviewer of
> this patch.
I wonder why do you need to roll asynchronous probing and asynchronous
resume by hand? This I think complicates the driver greatly and forces
you to use a ton of works, spinlocks, and checks.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/3] delaytop: add delay max, timestamp and sorting for top latency analysis
From: wang.yaxin @ 2026-05-28 4:38 UTC (permalink / raw)
To: akpm; +Cc: fan.yu9, yang.yang29, corbet, linux-kernel, linux-doc, xu.xin16
In-Reply-To: <20260527124210.19726c1c89a94b89310e5a47@linux-foundation.org>
>> From: Wang Yaxin <wang.yaxin@zte.com.cn>
>>
>> Previously delaytop only showed average delays. This patch adds:
>>
>> 1. delay_max fields to track the maximum delay value for each delay type
>> (cpu, blkio, irq, swapin, freepages, thrashing, compact, wpcopy)
>> per task.
>>
>> 2. The -t/--type option displays only the specified delay type with avg/max
>> values side by side, allowing focused analysis:
>> delaytop -t cpu # Show only CPU delay with avg/max
>> delaytop -t wpcopy # Show Copy-on-Write delay with avg/max
>>
>> 3. Wall-clock timestamp when each maximum delay occurred, displayed in the
>> MAX_TIMESTAMP column when using -t/--type option. This enables:
>> - Identifying the time when a process experienced an abnormal delay max
>> - Correlating delay max across multiple processes at the same timestamp
>> - Cross-referencing with logs, traces, or other metrics at that time
>>
>> 4. When using -t/--type option, tasks are sorted by maximum delay value in
>> descending order (largest delay first), enabling quick identification of
>> top N processes with highest delay spikes.
>
>Sounds useful. Am I correct in assuming that you're a regular user of
>delaytop and that these changes are based on your experience with it?
This indeed comes from latency observation requirements in business
scenarios. Some of our tasks are highly latency-sensitive, so we
need to monitor the "delay max" of specific tasks and detect anomalies
in a timely manner. delaytop is very useful for observing task-level
latency.
Thanks for the review. I will submit the v2 patch to fix the potential
issues as suggested
Thanks
Yaxin
^ permalink raw reply
* [PATCH v2] docs: pt_BR: update maintainer-handbooks
From: Amanda Corrêa @ 2026-05-28 4:19 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
Update the content of the maintainer-handbooks documentation
to Brazilian Portuguese.
v2: Update maintainer-handbooks documentation based on the actual latest version of the English
documentation. Prior version was based on an older version of the English documentation, which caused
some inconsistencies between the two versions.
This update ensures that the Brazilian Portuguese documentation is in sync with the latest English
version, providing accurate and up-to-date information.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
.../pt_BR/process/maintainer-handbooks.rst | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
index bf7a38147..b7aab788f 100644
--- a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
@@ -6,14 +6,17 @@ Notas sobre o processo de desenvolvimento de subsistemas e mantenedores
O propósito deste documento é fornecer informações específicas de
subsistemas que são suplementares ao manual geral do processo de
desenvolvimento.
+:ref:`Documentation/process <development_process_main>`.
-Conteúdos:
+Para desenvolvedores, veja abaixo todos os guias específicos de
+subsistemas conhecidos. Se o subsistema para o qual você está
+contribuindo não tiver um guia listado aqui, é recomendável buscar
+esclarecimentos sobre as questões levantadas em
+Documentation/maintainer/maintainer-entry-profile.rst.
-.. toctree::
- :numbered:
- :maxdepth: 2
+Para mantenedores, considere documentar requisitos adicionais e
+expectativas caso as submissões frequentemente deixem de atender
+a critérios específicos de submissão. Veja
+Documentation/maintainer/maintainer-entry-profile.rst.
- maintainer-netdev
- maintainer-soc
- maintainer-soc-clean-dts
- maintainer-kvm-x86
+.. maintainers-profile-toc::
--
2.43.0
^ permalink raw reply related
* [PATCH v2] docs: pt_BR: update maintainer-handbooks
From: Amanda Corrêa @ 2026-05-28 4:17 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
From: Amanda Corrêa <amandacorreasilvax@gmail.com>
Update the content of the maintainer-handbooks documentation
to Brazilian Portuguese.
v2: Update maintainer-handbooks documentation based on the actual latest version of the English
documentation. Prior version was based on an older version of the English documentation, which caused
some inconsistencies between the two versions.
This update ensures that the Brazilian Portuguese documentation is in sync with the latest English
version, providing accurate and up-to-date information.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
.../pt_BR/process/maintainer-handbooks.rst | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
index bf7a38147..b7aab788f 100644
--- a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
@@ -6,14 +6,17 @@ Notas sobre o processo de desenvolvimento de subsistemas e mantenedores
O propósito deste documento é fornecer informações específicas de
subsistemas que são suplementares ao manual geral do processo de
desenvolvimento.
+:ref:`Documentation/process <development_process_main>`.
-Conteúdos:
+Para desenvolvedores, veja abaixo todos os guias específicos de
+subsistemas conhecidos. Se o subsistema para o qual você está
+contribuindo não tiver um guia listado aqui, é recomendável buscar
+esclarecimentos sobre as questões levantadas em
+Documentation/maintainer/maintainer-entry-profile.rst.
-.. toctree::
- :numbered:
- :maxdepth: 2
+Para mantenedores, considere documentar requisitos adicionais e
+expectativas caso as submissões frequentemente deixem de atender
+a critérios específicos de submissão. Veja
+Documentation/maintainer/maintainer-entry-profile.rst.
- maintainer-netdev
- maintainer-soc
- maintainer-soc-clean-dts
- maintainer-kvm-x86
+.. maintainers-profile-toc::
--
2.43.0
^ permalink raw reply related
* [PATCH] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: CHEN-YOU-0331 @ 2026-05-28 4:13 UTC (permalink / raw)
To: Hu Haowen
Cc: Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel,
CHEN-YOU-0331
Translate PRC tech terms into Taiwanese tech terms (e.g.,
內核 -> 核心, 代碼 -> 程式碼, 軟件 -> 軟體) to improve
readability for local developers. Also, rephrase several
awkward sentences to make the document more fluent.
Signed-off-by: CHEN-YOU-0331 <chenyou910331@gmail.com>
---
.../zh_TW/process/8.Conclusion.rst | 45 +++++++++----------
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
index d1634421b62c..823969cf793d 100644
--- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
+++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
@@ -14,42 +14,41 @@
.. _tw_development_conclusion:
-更多信息
+更多資訊
========
-關於Linux內核開發和相關主題的信息來源很多。首先是在內核源代碼分發中找到的
-文檔目錄。頂級
+關於Linux核心開發和相關主題的資訊來源很多。首先是在核心原始碼分發中找到的
+文件目錄。頂級
:ref:`Documentation/translations/zh_CN/process/howto.rst <tw_process_howto>`
文件是一個重要的起點；
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
-也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制
-記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文檔
-（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文檔）。
-
-不同的網站在各個細節層次上討論內核開發。本文作者想謙虛地建議用 https://lwn.net/
-作爲來源；有關許多特定內核主題的信息可以通過以下網址的 LWN 內核索引找到：
+也是所有核心開發人員都應該閱讀的內容。許多內部核心API都是使用kerneldoc機制
+記錄的；“make htmldocs”或“make pdfdocs”可用於以HTML或PDF格式生成這些文件
+（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文件）。
+不同的網站在各個細節層次上討論核心開發。本文作者想謙虛地建議用 https://lwn.net/
+作爲來源；有關許多特定核心主題的資訊可以通過以下網址的 LWN 核心索引找到:
http://lwn.net/kernel/index/
-除此之外，內核開發人員的一個寶貴資源是：
+除此之外，核心開發人員的一個寶貴資源是：
https://kernelnewbies.org/
-當然，也不應該忘記 https://kernel.org/ ，這是內核發佈信息的最終位置。
+當然，也不應該忘記 https://kernel.org/ ，這是核心發佈資訊的最終位置。
-關於內核開發有很多書：
+關於核心開發有很多書：
《Linux設備驅動程序》第三版（Jonathan Corbet、Alessandro Rubini和Greg Kroah Hartman）
線上版本在 http://lwn.net/kernel/ldd3/
- 《Linux內核設計與實現》（Robert Love）
+ 《Linux核心設計與實現》（Robert Love）
- 《深入理解Linux內核》(Daniel Bovet和Marco Cesati）
+ 《深入理解Linux核心》(Daniel Bovet和Marco Cesati）
然而，所有這些書都有一個共同的缺點：它們上架時就往往有些過時，而且已經上架
-一段時間了。不過，在那裏還是可以找到相當多的好信息。
+一段時間了。不過，在那裏還是可以找到相當多的好資訊。
-有關git的文檔，請訪問：
+有關git的文件，請訪問：
https://www.kernel.org/pub/software/scm/git/docs/
@@ -58,16 +57,16 @@
結論
====
-祝賀所有通過這篇冗長的文檔的人。希望它能夠幫助您理解Linux內核是如何開發的，
+祝賀所有通過這篇冗長的文件的人。希望它能夠幫助您理解Linux核心是如何開發的，
以及您如何參與這個過程。
-最後，重要的是參與。任何開源軟件項目都不會超過其貢獻者投入其中的總和。Linux
-內核的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它
-變得更好。內核是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起
+最後，重要的是參與。任何開源軟體專案都不會超過其貢獻者投入其中的總和。Linux
+核心的發展速度和以前一樣快，因爲它得到了大量開發人員的幫助，他們都在努力使它
+變得更好。核心是一個最成功的例子，說明了當成千上萬的人爲了一個共同的目標一起
工作時，可以做出什麼。
-不過，內核總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
-重要的是，Linux生態系統中的大多數其他參與者可以通過爲內核做出貢獻而受益。使
-代碼進入主線是提高代碼質量、降低維護和分發成本、提高對內核開發方向的影響程度
+不過，核心總是可以從更大的開發人員基礎中獲益。總有更多的工作要做。但是同樣
+重要的是，Linux生態系統中的大多數其他參與者可以通過爲核心做出貢獻而受益。使
+程式碼進入主線是提高程式碼品質、降低維護和分發成本、提高對核心開發方向的影響程度
等的關鍵。這是一種共贏的局面。啓動你的編輯器，來加入我們吧；你會非常受歡迎的。
--
2.43.0
^ permalink raw reply related
* Re: [RFC] hwmon: add a driver for the temp/voltage sensor on PolarFire SoC
From: Guenter Roeck @ 2026-05-28 4:07 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-hwmon, Lars Randers, Conor Dooley, Jonathan Corbet,
Shuah Khan, Daire McNamara, linux-doc, linux-kernel, linux-riscv,
Valentina.FernandezAlanis
In-Reply-To: <20260527-earring-bully-eb4a268c2e68@spud>
On Wed, May 27, 2026 at 10:06:11AM +0100, Conor Dooley wrote:
> From: Lars Randers <lranders@mail.dk>
>
> Add a driver for the temperature and voltage sensors on PolarFire SoC.
> The temperature reports how hot the die is, and the voltages are the
> SoC's 1.05, 1.8 and 2.5 volt rails respectively.
>
> The hardware supports alarms in theory, but there is an unconfirmed
> erratum that prevents clearing them once triggered, so no support is
> added.
>
> The hardware measures voltage with 16 bits, of which 1 is a sign bit and
> the remainder holds the voltage as a fixed point integer value. It's
> improbable that the hardware will work if the voltages are negative, so
> the driver ignores the sign bits.
>
> There's no dt support etc here because this is the child of a simple-mfd
> syscon.
>
> Signed-off-by: Lars Randers <lranders@mail.dk>
> Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> Guenter, there's one question here about the unit that update_interval
> is in, I didn't see anyone else using us, but I assume that's okay since
> the resolution that ms would give would be 8 steps only?
> RFC cos the question is also in the driver as a comment.
>
That just came up in a different context. We'll add a new standard attribute
update_interval_us. The existing attribute MUST use ms. Everything else
would be an ABI violation.
Guenter
> CC: Guenter Roeck <linux@roeck-us.net>
> CC: Jonathan Corbet <corbet@lwn.net>
> CC: Shuah Khan <skhan@linuxfoundation.org>
> CC: Conor Dooley <conor.dooley@microchip.com>
> CC: Daire McNamara <daire.mcnamara@microchip.com>
> CC: linux-hwmon@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> CC: linux-riscv@lists.infradead.org
> CC: Valentina.FernandezAlanis@microchip.com
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/tvs-mpfs.rst | 53 +++++
> MAINTAINERS | 1 +
> drivers/hwmon/Kconfig | 12 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/tvs-mpfs.c | 396 +++++++++++++++++++++++++++++++
> 6 files changed, 464 insertions(+)
> create mode 100644 Documentation/hwmon/tvs-mpfs.rst
> create mode 100644 drivers/hwmon/tvs-mpfs.c
>
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 8b655e5d6b68..84a5339e1d6f 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -262,6 +262,7 @@ Hardware Monitoring Kernel Drivers
> tps53679
> tps546d24
> tsc1641
> + tvs-mpfs
> twl4030-madc-hwmon
> ucd9000
> ucd9200
> diff --git a/Documentation/hwmon/tvs-mpfs.rst b/Documentation/hwmon/tvs-mpfs.rst
> new file mode 100644
> index 000000000000..39889c06ef0c
> --- /dev/null
> +++ b/Documentation/hwmon/tvs-mpfs.rst
> @@ -0,0 +1,53 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Kernel driver tvs-mpfs
> +======================
> +
> +Supported chips:
> +
> + * PolarFire SoC
> +
> +Authors:
> +
> + - Conor Dooley <conor.dooley@microchip.com>
> + - Lars Randers <lranders@mail.dk>
> +
> +Description
> +-----------
> +
> +This driver implements support for the temperature and voltage sensors on
> +PolarFire SoC. The temperature reports how hot the die is, and the voltages are
> +the SoC's 1.05, 1.8 and 2.5 volt rails respectively.
> +
> +
> +Usage Notes
> +-----------
> +
> +update_interval is in microseconds, with a permitted range of 0 to 8128.
> +
> +Temperatures are read in millidegrees Celsius, but the hardware measures in
> +degrees Kelvin, storing the result as 11.4 fixed point data, for a maximum
> +value of 2047.9375 degrees Kelvin.
> +
> +Voltages are read in millivolts. The hardware measures in millivolts, storing
> +the value as 12.3 fixed point data, for a maximum of 4095.875 millivolts.
> +The minimum value reportable by the driver is 0 volts, although the hardware
> +is capable of measuring negative values.
> +
> +Sysfs entries
> +-------------
> +
> +The following attributes are supported. update_interval is read-write, as are
> +the enables. All other attributes are read only.
> +
> +======================= ====================================================
> +temp1_label Fixed name for channel.
> +temp1_input Measured temperature for channel.
> +temp1_enable Enable/disable for channel.
> +
> +in[0-2]_label Fixed name for channel.
> +in[0-2]_input Measured voltage for channel.
> +in[0-2]_enable Enable/disable for channel.
> +
> +update_interval The interval at which the chip will update readings.
> +======================= ====================================================
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2fb1c75afd16..a492cf5ad0fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -22938,6 +22938,7 @@ F: drivers/char/hw_random/mpfs-rng.c
> F: drivers/clk/microchip/clk-mpfs*.c
> F: drivers/firmware/microchip/mpfs-auto-update.c
> F: drivers/gpio/gpio-mpfs.c
> +F: drivers/hwmon/tvs-mpfs.c
> F: drivers/i2c/busses/i2c-microchip-corei2c.c
> F: drivers/mailbox/mailbox-mpfs.c
> F: drivers/pci/controller/plda/pcie-microchip-host.c
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 14e4cea48acc..194c8116fd01 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -930,6 +930,18 @@ config SENSORS_JC42
> This driver can also be built as a module. If so, the module
> will be called jc42.
>
> +config SENSORS_POLARFIRE_SOC_TVS
> + tristate "PolarFire SoC (MPFS) temperature and voltage sensor"
> + depends on POLARFIRE_SOC_MAILBOX
> + help
> + This driver adds support for the PolarFire SoC (MPFS) Temperature and
> + Voltage Sensor.
> +
> + To compile this driver as a module, choose M here. the
> + module will be called tvs-mpfs.
> +
> + If unsure, say N.
> +
> config SENSORS_POWERZ
> tristate "ChargerLAB POWER-Z USB-C tester"
> depends on USB
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 4788996aa137..b58d249e4cf4 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -194,6 +194,7 @@ obj-$(CONFIG_SENSORS_NZXT_SMART2) += nzxt-smart2.o
> obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
> obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> +obj-$(CONFIG_SENSORS_POLARFIRE_SOC_TVS) += tvs-mpfs.o
> obj-$(CONFIG_SENSORS_POWERZ) += powerz.o
> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> obj-$(CONFIG_SENSORS_PT5161L) += pt5161l.o
> diff --git a/drivers/hwmon/tvs-mpfs.c b/drivers/hwmon/tvs-mpfs.c
> new file mode 100644
> index 000000000000..30d7baa808c4
> --- /dev/null
> +++ b/drivers/hwmon/tvs-mpfs.c
> @@ -0,0 +1,396 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Author: Lars Randers <lranders@mail.dk>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/err.h>
> +#include <linux/freezer.h>
> +#include <linux/hwmon.h>
> +#include <linux/io.h>
> +#include <linux/kthread.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#define MPFS_TVS_CTRL 0x08
> +#define MPFS_TVS_OUTPUT0 0x24
> +#define MPFS_TVS_OUTPUT1 0x28
> +
> +#define MPFS_TVS_CTRL_TEMP_VALID BIT(19)
> +#define MPFS_TVS_CTRL_V2P5_VALID BIT(18)
> +#define MPFS_TVS_CTRL_V1P8_VALID BIT(17)
> +#define MPFS_TVS_CTRL_V1P05_VALID BIT(16)
> +
> +#define MPFS_TVS_CTRL_TEMP_ENABLE BIT(3)
> +#define MPFS_TVS_CTRL_V2P5_ENABLE BIT(2)
> +#define MPFS_TVS_CTRL_V1P8_ENABLE BIT(1)
> +#define MPFS_TVS_CTRL_V1P05_ENABLE BIT(0)
> +#define MPFS_TVS_CTRL_ENABLE_ALL GENMASK(3, 0)
> +
> +/*
> + * For all of these the value in millivolts is stored in 16 bits, with an upper
> + * sign bit and a lower 2 bits of decimal. These masks discard the sign bit and
> + * decimal places, because if Linux is running these voltages cannot be negative
> + * and so avoid having to convert to two's complement.
> + */
> +#define MPFS_OUTPUT0_V1P8_MASK GENMASK(30, 19)
> +#define MPFS_OUTPUT0_V1P05_MASK GENMASK(14, 3)
> +#define MPFS_OUTPUT1_V2P5_MASK GENMASK(14, 3)
> +
> +/*
> + * The register map claims that the temperature is stored in bits 31:16, but
> + * application note "AN4682: PolarFire FPGA Temperature and Voltage Sensor"
> + * says that 31 is reserved. Temperature is in kelvin, so what's probably a
> + * sign bit has no value anyway.
> + */
> +#define MPFS_OUTPUT1_TEMP_MASK GENMASK(30, 16)
> +
> +#define MPFS_TVS_INTERVAL_MASK GENMASK(15, 8)
> +#define MPFS_TVS_INTERVAL_OFFSET 8
> +/* The interval register is in increments of 32 us */
> +#define MPFS_TVS_INTERVAL_SCALE 32
> +
> +/* 273.5 in 11.4 fixed-point notation */
> +#define MPFS_TVS_K_TO_C 0x1112
> +
> +enum mpfs_tvs_sensors {
> + SENSOR_V1P05 = 0,
> + SENSOR_V1P8,
> + SENSOR_V2P5,
> +};
> +
> +static const char * const mpfs_tvs_voltage_labels[] = { "1P05", "1P8", "2P5" };
> +
> +struct mpfs_tvs {
> + struct regmap *regmap;
> +};
> +
> +static int mpfs_tvs_voltage_read(struct mpfs_tvs *data, u32 attr,
> + int channel, long *val)
> +{
> + u32 tmp, control;
> +
> + if (attr != hwmon_in_input && attr != hwmon_in_enable)
> + return -EOPNOTSUPP;
> +
> + regmap_read(data->regmap, MPFS_TVS_CTRL, &control);
> +
> + switch (channel) {
> + case SENSOR_V2P5:
> + if (attr == hwmon_in_enable) {
> + *val = FIELD_GET(MPFS_TVS_CTRL_V2P5_ENABLE, control);
> + break;
> + }
> +
> + if (!(control & MPFS_TVS_CTRL_V2P5_VALID))
> + return -EINVAL;
> +
> + regmap_read(data->regmap, MPFS_TVS_OUTPUT1, &tmp);
> + *val = FIELD_GET(MPFS_OUTPUT1_V2P5_MASK, tmp);
> + break;
> + case SENSOR_V1P8:
> + if (attr == hwmon_in_enable) {
> + *val = FIELD_GET(MPFS_TVS_CTRL_V1P8_ENABLE, control);
> + break;
> + }
> +
> + if (!(control & MPFS_TVS_CTRL_V1P8_VALID))
> + return -EINVAL;
> +
> + regmap_read(data->regmap, MPFS_TVS_OUTPUT0, &tmp);
> + *val = FIELD_GET(MPFS_OUTPUT0_V1P8_MASK, tmp);
> + break;
> + case SENSOR_V1P05:
> + if (attr == hwmon_in_enable) {
> + *val = FIELD_GET(MPFS_TVS_CTRL_V1P05_ENABLE, control);
> + break;
> + }
> +
> + if (!(control & MPFS_TVS_CTRL_V1P05_VALID))
> + return -EINVAL;
> +
> + regmap_read(data->regmap, MPFS_TVS_OUTPUT0, &tmp);
> + *val = FIELD_GET(MPFS_OUTPUT0_V1P05_MASK, tmp);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static int mpfs_tvs_voltage_write(struct mpfs_tvs *data, u32 attr,
> + int channel, long val)
> +{
> + u32 tmp;
> +
> + if (attr != hwmon_in_enable)
> + return -EOPNOTSUPP;
> +
> + switch (channel) {
> + case SENSOR_V2P5:
> + if (val > 1)
> + return -EINVAL;
> +
> + tmp = FIELD_PREP(MPFS_TVS_CTRL_V2P5_ENABLE, val);
> + regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> + MPFS_TVS_CTRL_V2P5_ENABLE, tmp);
> + break;
> + case SENSOR_V1P8:
> + if (val > 1)
> + return -EINVAL;
> +
> + tmp = FIELD_PREP(MPFS_TVS_CTRL_V1P8_ENABLE, val);
> + regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> + MPFS_TVS_CTRL_V1P8_ENABLE, tmp);
> + break;
> + case SENSOR_V1P05:
> + if (val > 1)
> + return -EINVAL;
> +
> + tmp = FIELD_PREP(MPFS_TVS_CTRL_V1P05_ENABLE, val);
> + regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> + MPFS_TVS_CTRL_V1P05_ENABLE, tmp);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static int mpfs_tvs_temp_read(struct mpfs_tvs *data, u32 attr, long *val)
> +{
> + u32 tmp, control;
> +
> + if (attr != hwmon_temp_input && attr != hwmon_temp_enable)
> + return -EOPNOTSUPP;
> +
> + regmap_read(data->regmap, MPFS_TVS_CTRL, &control);
> +
> + if (attr == hwmon_temp_enable) {
> + *val = FIELD_GET(MPFS_TVS_CTRL_TEMP_ENABLE, control);
> + return 0;
> + }
> +
> + if (!(control & MPFS_TVS_CTRL_TEMP_VALID))
> + return -EINVAL;
> +
> + regmap_read(data->regmap, MPFS_TVS_OUTPUT1, &tmp);
> + *val = FIELD_GET(MPFS_OUTPUT1_TEMP_MASK, tmp);
> + *val -= MPFS_TVS_K_TO_C;
> + *val = (1000 * *val) >> 4; /* fixed point (11.4) to millidegrees */
> +
> + return 0;
> +}
> +
> +static int mpfs_tvs_temp_write(struct mpfs_tvs *data, u32 attr, long val)
> +{
> + u32 tmp;
> +
> + if (attr != hwmon_temp_enable)
> + return -EOPNOTSUPP;
> +
> + if (val > 1)
> + return -EINVAL;
> +
> + tmp = FIELD_PREP(MPFS_TVS_CTRL_TEMP_ENABLE, val);
> + regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> + MPFS_TVS_CTRL_TEMP_ENABLE, tmp);
> +
> + return 0;
> +}
> +
> +static int mpfs_tvs_interval_read(struct mpfs_tvs *data, u32 attr, long *val)
> +{
> + u32 tmp;
> +
> + if (attr != hwmon_chip_update_interval)
> + return -EOPNOTSUPP;
> +
> + regmap_read(data->regmap, MPFS_TVS_CTRL, &tmp);
> + //TODO: Guenter, update_interval, as implemented here, expects values
> + //in microseconds. Is that okay? Most drivers (all that I checked tbh)
> + //use milliseconds, but this is an 8-bit value so using ms will have
> + //almost no granularity at all.
> + *val = FIELD_GET(MPFS_TVS_INTERVAL_MASK, tmp) * MPFS_TVS_INTERVAL_SCALE;
> +
> + return 0;
> +}
> +
> +static int mpfs_tvs_interval_write(struct mpfs_tvs *data, u32 attr, long val)
> +{
> + unsigned long temp = val;
> +
> + if (attr != hwmon_chip_update_interval)
> + return -EOPNOTSUPP;
> +
> + temp /= MPFS_TVS_INTERVAL_SCALE;
> +
> + /*
> + * The value is 8 bits wide, but 255 is described as
> + * "255= Do single set of transfers when scoverride set"
> + * but there's no scoverride bit in the tvs register region.
> + * Ban using 255 since its behaviour is suspect.
> + */
> + if (temp > 254)
> + return -EINVAL;
> +
> + temp <<= MPFS_TVS_INTERVAL_OFFSET;
> + regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> + MPFS_TVS_INTERVAL_MASK, temp);
> +
> + return 0;
> +}
> +
> +
> +static umode_t mpfs_tvs_is_visible(const void *data,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + if (type == hwmon_chip && attr == hwmon_chip_update_interval)
> + return 0644;
> +
> + if (type == hwmon_temp) {
> + switch (attr) {
> + case hwmon_temp_enable:
> + return 0644;
> + case hwmon_temp_input:
> + case hwmon_temp_label:
> + return 0444;
> + default:
> + return 0;
> + }
> + }
> +
> + if (type == hwmon_in) {
> + switch (attr) {
> + case hwmon_in_enable:
> + return 0644;
> + case hwmon_in_input:
> + case hwmon_in_label:
> + return 0444;
> + default:
> + return 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int mpfs_tvs_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct mpfs_tvs *data = dev_get_drvdata(dev);
> +
> + switch (type) {
> + case hwmon_temp:
> + return mpfs_tvs_temp_read(data, attr, val);
> + case hwmon_in:
> + return mpfs_tvs_voltage_read(data, attr, channel, val);
> + case hwmon_chip:
> + return mpfs_tvs_interval_read(data, attr, val);
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int mpfs_tvs_write(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long val)
> +{
> + struct mpfs_tvs *data = dev_get_drvdata(dev);
> +
> + switch (type) {
> + case hwmon_temp:
> + return mpfs_tvs_temp_write(data, attr, val);
> + case hwmon_in:
> + return mpfs_tvs_voltage_write(data, attr, channel, val);
> + case hwmon_chip:
> + return mpfs_tvs_interval_write(data, attr, val);
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int mpfs_tvs_read_labels(struct device *dev,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel,
> + const char **str)
> +{
> + switch (type) {
> + case hwmon_temp:
> + *str = "Die Temp";
> + return 0;
> + case hwmon_in:
> + *str = mpfs_tvs_voltage_labels[channel];
> + return 0;
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static const struct hwmon_ops mpfs_tvs_ops = {
> + .is_visible = mpfs_tvs_is_visible,
> + .read_string = mpfs_tvs_read_labels,
> + .read = mpfs_tvs_read,
> + .write = mpfs_tvs_write,
> +};
> +
> +static const struct hwmon_channel_info *mpfs_tvs_info[] = {
> + HWMON_CHANNEL_INFO(chip,
> + HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
> + HWMON_CHANNEL_INFO(temp,
> + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_ENABLE),
> + HWMON_CHANNEL_INFO(in,
> + HWMON_I_INPUT | HWMON_I_LABEL | HWMON_I_ENABLE,
> + HWMON_I_INPUT | HWMON_I_LABEL | HWMON_I_ENABLE,
> + HWMON_I_INPUT | HWMON_I_LABEL | HWMON_I_ENABLE),
> + NULL
> +};
> +
> +static const struct hwmon_chip_info mpfs_tvs_chip_info = {
> + .ops = &mpfs_tvs_ops,
> + .info = mpfs_tvs_info,
> +};
> +
> +static int mpfs_tvs_probe(struct platform_device *pdev)
> +{
> + struct device *hwmon_dev;
> + struct mpfs_tvs *data;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->regmap = device_node_to_regmap(pdev->dev.parent->of_node);
> + if (IS_ERR(data->regmap))
> + return dev_err_probe(&pdev->dev, PTR_ERR(data->regmap),
> + "Failed to find syscon regmap\n");
> +
> + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev, "mpfs_tvs",
> + data,
> + &mpfs_tvs_chip_info,
> + NULL);
> + if (IS_ERR(hwmon_dev))
> + return dev_err_probe(&pdev->dev, PTR_ERR(hwmon_dev),
> + "hwmon device registration failed.\n");
> +
> + regmap_write(data->regmap, MPFS_TVS_CTRL, MPFS_TVS_CTRL_ENABLE_ALL);
> +
> + return 0;
> +}
> +
> +static struct platform_driver mpfs_tvs_driver = {
> + .probe = mpfs_tvs_probe,
> + .driver = {
> + .name = "mpfs-tvs",
> + },
> +};
> +module_platform_driver(mpfs_tvs_driver);
> +
> +MODULE_AUTHOR("Lars Randers <lranders@mail.dk>");
> +MODULE_DESCRIPTION("PolarFire SoC temperature & voltage sensor driver");
> +MODULE_LICENSE("GPL");
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH net-next v2 10/10] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Andrew Lunn @ 2026-05-28 3:10 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-10-37e5c8d4e0a0@analog.com>
> +static netdev_tx_t adin1140_start_xmit(struct sk_buff *skb,
> + struct net_device *netdev)
> +{
> + struct adin1140_priv *priv = netdev_priv(netdev);
> +
> + /* Pad frames to minimum Ethernet frame size (60 bytes without FCS).
> + * The MAC will append the FCS, but we need to ensure the frame is
> + * at least ETH_ZLEN bytes.
> + */
> + if (skb_put_padto(skb, ETH_ZLEN))
> + return NETDEV_TX_OK;
Does the standard say anything about this? It seems like something
which could be moved into the core.
Andrew
^ permalink raw reply
* 答复: [外部邮件] Re: [PATCH] mm/mempool: use static key for boot-time debug enablement
From: Li,Rongqing(ACG CCN) @ 2026-05-28 3:00 UTC (permalink / raw)
To: Usama Arif
Cc: Jonathan Corbet, Shuah Khan, Vlastimil Babka, Harry Yoo,
Andrew Morton, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <20260527130337.983366-1-usama.arif@linux.dev>
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > Replace the #ifdef CONFIG_SLUB_DEBUG_ON conditional compilation with a
> > static key (mempool_debug_enabled). This allows enabling mempool
> > debugging at boot time via:
> >
> > mempool_debug
> >
> > Instead of requiring CONFIG_SLUB_DEBUG_ON at compile time. Benefits:
> >
> > - Debugging can be enabled without rebuilding the kernel
> > - Uses standard kernel static_key mechanism with minimal overhead
> >
> > Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > Cc: Vlastimil Babka <vbabka@kernel.org>
> > Cc: Harry Yoo <harry@kernel.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Hao Li <hao.li@linux.dev>
> > Cc: Christoph Lameter <cl@gentwo.org>
> > Cc: David Rientjes <rientjes@google.com>
> > Cc: Roman Gushchin <roman.gushchin@linux.dev>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 5 ++++
> > mm/mempool.c | 32
> ++++++++++++++++++-------
> > 2 files changed, 28 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 35ed9dc..5a070e6 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -3998,6 +3998,11 @@ Kernel parameters
> > Note that even when enabled, there are a few cases where
> > the feature is not effective.
> >
> > + mempool_debug [MM]
> > + Enable mempool debugging. This enables element
> > + poison checking when freeing elements back to the
> > + pool. Useful for debugging mempool corruption.
> > +
> > memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable memtest
> > Format: <integer>
> > default : 0 <disable>
> > diff --git a/mm/mempool.c b/mm/mempool.c index db23e0e..4f429a1
> 100644
> > --- a/mm/mempool.c
> > +++ b/mm/mempool.c
> > @@ -16,11 +16,28 @@
> > #include <linux/export.h>
> > #include <linux/mempool.h>
> > #include <linux/writeback.h>
> > +#include <linux/static_key.h>
> > +#include <linux/init.h>
> > #include "slab.h"
> >
> > static DECLARE_FAULT_ATTR(fail_mempool_alloc);
> > static DECLARE_FAULT_ATTR(fail_mempool_alloc_bulk);
> >
> > +/*
> > + * Debugging support for mempool using static key.
> > + *
> > + * This allows enabling mempool debug at boot time via:
> > + * mempool_debug
> > + */
> > +static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
> > +
> > +static int __init mempool_debug_setup(char *str) {
> > + static_branch_enable(&mempool_debug_enabled);
> > + return 0;
> > +}
> > +early_param("mempool_debug", mempool_debug_setup);
> > +
>
> Can static_branch_enable() in mempool_debug_setup() run before
> jump_label_init() has set static_key_initialized?
>
> Looking at start_kernel() in init/main.c:
>
> setup_arch(&command_line);
> mm_core_init_early();
> /* Static keys and static calls are needed by LSMs */
> jump_label_init();
> ...
> /* parameters may set static keys */
> parse_early_param();
>
> This will trigger the warning in include/linux/jump_label.h has:
>
> #define STATIC_KEY_CHECK_USE(key) WARN(!static_key_initialized, \
> "%s(): static key '%pS' used before call to jump_label_init()", \
> __func__, (key))
>
>
> mm/dmapool.c registers an equivalent debug toggle via __setup() rather than
> early_param():
>
> static int __init dmapool_debug_setup(char *str)
> {
> static_branch_enable(&dmapool_debug_enabled);
> return 1;
> }
> __setup("dmapool_debug", dmapool_debug_setup);
>
> I think you can reuse that.
Thanks for your review!
While this boot-time ordering used to be a generic issue, it seems many
architectures have already aligned or fixed this internally. For instance,
commit ca829e05d3d4 ("powerpc/64: Init jump labels before parse_early_param()")
and commit 6070970db9fe ("m68k: Initialize jump labels early during setup_arch()")
explicitly relocated jump_label_init() before the early parameter parsing.
Furthermore, leveraging early_param() to directly manage static keys is still
actively used and accepted in the current core kernel. Some examples include:
- early_param("randomize_kstack_offset", early_randomize_kstack_offset);
- early_param("threadirqs", setup_forced_irqthreads);
The primary reason for using early_param() here instead of __setup() is that
mempool allocations can happen extremely early during the boot phase. Moving
this to a later stage like __setup() would mean missing the tracking for the
most critical early-stage memory pools, which defeats the purpose of boot-time
debugging.
Therefore, I think using early_param() here is the most robust option to
ensure full coverage of mempool allocations.
What do you think?
Thanks
-Li
>
> > static int __init mempool_faul_inject_init(void) {
> > int error;
> > @@ -37,7 +54,6 @@ static int __init mempool_faul_inject_init(void) }
> > late_initcall(mempool_faul_inject_init);
> >
> > -#ifdef CONFIG_SLUB_DEBUG_ON
> > static void poison_error(struct mempool *pool, void *element, size_t size,
> > size_t byte)
> > {
> > @@ -73,6 +89,9 @@ static void __check_element(struct mempool *pool,
> > void *element, size_t size)
> >
> > static void check_element(struct mempool *pool, void *element) {
> > + if (!static_branch_unlikely(&mempool_debug_enabled))
> > + return;
> > +
> > /* Skip checking: KASAN might save its metadata in the element. */
> > if (kasan_enabled())
> > return;
> > @@ -112,6 +131,9 @@ static void __poison_element(void *element, size_t
> > size)
> >
> > static void poison_element(struct mempool *pool, void *element) {
> > + if (!static_branch_unlikely(&mempool_debug_enabled))
> > + return;
> > +
>
> Before this change, building with CONFIG_SLUB_DEBUG_ON=y compiled in
> check_element() and poison_element() unconditionally, so the poisoning and
> corruption checks ran on every mempool free/alloc.
> After this change those checks are gated on the mempool_debug boot parameter
> even when CONFIG_SLUB_DEBUG_ON=y.
>
> Existing users who relied on CONFIG_SLUB_DEBUG_ON=y giving them mempool
> poison checking will silently lose it on upgrade unless they also add
> "mempool_debug" to the command line.
>
> Would it be worth defaulting the static key to true under
> CONFIG_SLUB_DEBUG_ON=y, for example:
>
> #ifdef CONFIG_SLUB_DEBUG_ON
> static DEFINE_STATIC_KEY_TRUE(mempool_debug_enabled);
> #else
> static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
> #endif
>
> so the previous default behaviour is preserved.
>
>
> > /* Skip poisoning: KASAN might save its metadata in the element. */
> > if (kasan_enabled())
> > return;
> > @@ -140,14 +162,6 @@ static void poison_element(struct mempool *pool,
> > void *element) #endif
> > }
> > }
> > -#else /* CONFIG_SLUB_DEBUG_ON */
> > -static inline void check_element(struct mempool *pool, void *element)
> > -{ -} -static inline void poison_element(struct mempool *pool, void
> > *element) -{ -} -#endif /* CONFIG_SLUB_DEBUG_ON */
> >
> > static __always_inline bool kasan_poison_element(struct mempool *pool,
> > void *element)
> > --
> > 2.9.4
> >
> >
^ permalink raw reply
* Re: [PATCH net-next v2 09/10] net: phy: Add support for the ADIN1140 PHY
From: Andrew Lunn @ 2026-05-28 2:50 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-9-37e5c8d4e0a0@analog.com>
> +static int adin1140_config_aneg(struct phy_device *phydev)
> +{
> + /* phylib tries to clear BIT(12) in MDIO_CTRL1, since AN is disabled.
> + * However, on the ADIN1140, that field is non-standard, being used
> + * to control the reset status of the PHY (thus it needs to remain set).
More brokenness. 802.3 defines PMA/PMD control 1 bit 12 as reserved
and always 0.
How did this chip get passed QA with so many issues?
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* htmldocs: Documentation/accounting/delay-accounting.rst:237: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
From: kernel test robot @ 2026-05-28 2:36 UTC (permalink / raw)
To: Wang Yaxin; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/wang-yaxin-zte-com-cn/delaytop-add-delay-max-for-delaytop/20260527-220949
head: 44e6b3df52686da300225295e81360c85eac7218
commit: 44e6b3df52686da300225295e81360c85eac7218 delaytop: sort by max delay to highlight top latency processes
date: 12 hours ago
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260528/202605280425.CtB8dwcy-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605280425.CtB8dwcy-lkp@intel.com/
All warnings (new ones prefixed by >>):
[WARNING] /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index is defined 2 times: ./Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:373; ./Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:243
[WARNING] /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled is defined 2 times: ./Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:636; ./Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:252
[WARNING] /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled_index is defined 2 times: ./Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:645; ./Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:261
Using alabaster theme
Documentation/accounting/delay-accounting.rst:236: ERROR: Unexpected indentation. [docutils]
>> Documentation/accounting/delay-accounting.rst:237: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/accounting/delay-accounting.rst:237: ERROR: Missing matching underline for section title overline.
--
30 30 kworker/2:0H-kb 2.87 11.36 2026-05-27T13:32:36 [docutils]
Documentation/accounting/delay-accounting.rst:243: ERROR: Unexpected indentation. [docutils]
Documentation/accounting/delay-accounting.rst:244: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/accounting/delay-accounting.rst:246: ERROR: Unexpected indentation. [docutils]
Documentation/accounting/delay-accounting.rst:247: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>> Documentation/accounting/delay-accounting.rst:249: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
Documentation/accounting/delay-accounting.rst:246: ERROR: Unknown target name: "pool_workqueue". [docutils]
WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:364; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:234
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:373; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:243
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:636; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:252
vim +237 Documentation/accounting/delay-accounting.rst
224
225
226 System Pressure Information: (avg10/avg60vg300/total)
227 CPU some: 0.4%/ 0.2%/ 0.1%/ 220(ms)
228 CPU full: 0.0%/ 0.0%/ 0.0%/ 0(ms)
229 Memory full: 0.0%/ 0.0%/ 0.0%/ 0(ms)
230 Memory some: 0.0%/ 0.0%/ 0.0%/ 0(ms)
231 IO full: 0.0%/ 0.0%/ 0.0%/ 12(ms)
232 IO some: 0.0%/ 0.0%/ 0.0%/ 13(ms)
233 IRQ full: 0.0%/ 0.0%/ 0.0%/ 0(ms)
234 [o]sort [M]memverbose [q]quit
235 Top 20 processes (sorted by cpu MAX delay, largest first):
236 PID TGID COMMAND AVG(ms) MAX(ms) MAX_TIMESTAMP
> 237 ------------------------------------------------------------------------------------------------
238 9 9 kworker/0:0-eve 0.59 16.87 2026-05-27T13:32:39
239 30 30 kworker/2:0H-kb 2.87 11.36 2026-05-27T13:32:36
240 27 27 migration/2 1.05 9.51 2026-05-27T13:32:37
241 50 50 kworker/2:1-eve 0.50 9.13 2026-05-27T13:32:37
242 15 15 rcu_preempt 0.11 8.98 2026-05-27T13:32:37
243 1 1 init 0.17 7.12 2026-05-27T13:32:38
244 67 67 scsi_eh_0 1.20 4.23 2026-05-27T13:32:37
245 23 23 ksoftirqd/1 1.12 3.77 2026-05-27T13:32:36
246 3 3 pool_workqueue_ 0.72 3.55 2026-05-27T13:32:38
247 62 62 kworker/u20:2-a 0.49 3.03 2026-05-27T13:32:37
248 2 2 kthreadd 0.18 2.82 2026-05-27T13:32:37
> 249 11 11 kworker/0:1 1.42 2.76 2026-05-27T13:32:36
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v2 08/10] net: phy: microchip-t1s: use generic C45 MMD access helpers
From: Andrew Lunn @ 2026-05-28 2:33 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-8-37e5c8d4e0a0@analog.com>
On Wed, May 27, 2026 at 12:51:53AM +0300, Ciprian Regus via B4 Relay wrote:
> From: Ciprian Regus <ciprian.regus@analog.com>
>
> Replace the driver specific lan865x_phy_read_mmd() and
> lan865x_phy_write_mmd() with the shared genphy_read_mmd_c45() and
> genphy_write_mmd_c45() helpers.
>
> No functional change.
>
> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 07/10] net: phy: add generic helpers for direct C45 MMD access
From: Andrew Lunn @ 2026-05-28 2:33 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-7-37e5c8d4e0a0@analog.com>
On Wed, May 27, 2026 at 12:51:52AM +0300, Ciprian Regus via B4 Relay wrote:
> From: Ciprian Regus <ciprian.regus@analog.com>
>
> Some PHYs support direct C45 register access but not C22 indirect MMD
> access (registers 0xD and 0xE). When discovered via C22, phylib routes
> MMD access through the indirect path, which won't work on these
> devices.
>
> Add genphy_read_mmd_c45() and genphy_write_mmd_c45() as read_mmd/
> write_mmd callbacks that bypass the C22 indirect path and use the bus
> C45 accessors directly.
>
> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 06/10] net: ethernet: oa_tc6: Add MMS register formatting macro
From: Andrew Lunn @ 2026-05-28 2:31 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-6-37e5c8d4e0a0@analog.com>
On Wed, May 27, 2026 at 12:51:51AM +0300, Ciprian Regus via B4 Relay wrote:
> From: Ciprian Regus <ciprian.regus@analog.com>
>
> The Open Alliance TC6 standard defines multiple memory maps for the
> MAC-PHY's register space. These are used to separate standard, vendor
> and PHY MMD specific registers. Add a macro to make it more clear which
> memory map each register is part of and allow easier definition.
>
> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
>
> ---
> v2 changelog:
> - New patch
> ---
> drivers/net/ethernet/oa_tc6.c | 4 ++--
> include/linux/oa_tc6.h | 3 +++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
> index 904bd790159d..876891ca9859 100644
> --- a/drivers/net/ethernet/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6.c
> @@ -471,7 +471,7 @@ int oa_tc6_mdiobus_read_c45(struct mii_bus *bus, int addr, int devnum,
> if (ret < 0)
> return ret;
>
> - ret = oa_tc6_read_register(tc6, (ret << 16) | regnum, ®val);
> + ret = oa_tc6_read_register(tc6, OA_TC6_MMS_REG(ret, regnum), ®val);
How about:
ret = oa_tc6_read_register_mms(tc6, ret, regnum, ®val);
and let oa_tc6_read_register_mms() combine them in the correct way.
Maybe also change
ret = oa_tc6_get_phy_c45_mms(devnum);
to
mms = oa_tc6_get_phy_c45_mms(devnum);
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 05/10] net: ethernet: oa_tc6: Export standard defined registers
From: Andrew Lunn @ 2026-05-28 2:21 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-5-37e5c8d4e0a0@analog.com>
On Wed, May 27, 2026 at 12:51:50AM +0300, Ciprian Regus via B4 Relay wrote:
> From: Ciprian Regus <ciprian.regus@analog.com>
>
> Move defines for standard Open Alliance TC6 register addresses and
> subfields in the oa_tc6's header and add entries for the PHYID and
> CONFIG2. As such, other ethernet drivers that rely on oa_tc6 can use
> them directly.
A patch which says its moves defines should only move defines. Don't
change them at the same time.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2 04/10] net: ethernet: oa_tc6: Export the C45 access functions
From: Andrew Lunn @ 2026-05-28 2:13 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-4-37e5c8d4e0a0@analog.com>
On Wed, May 27, 2026 at 12:51:49AM +0300, Ciprian Regus via B4 Relay wrote:
> From: Ciprian Regus <ciprian.regus@analog.com>
>
> The C45 access functions can still be used by some Ethernet drivers
> which set the OA_TC6_BROKEN_PHY flag. Export them.
>
> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 03/10] net: ethernet: oa_tc6: add OA_TC6_BROKEN_PHY quirk flag
From: Andrew Lunn @ 2026-05-28 2:12 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260527-adin1140-driver-v2-3-37e5c8d4e0a0@analog.com>
> To avoid extending the oa_tc6_init() signature for each new option,
> convert it to take a config struct. Update lan865x and the framework
> documentation accordingly.
We are talking about quirks here. I would prefer you add a new
parameter to oa_tc6_init() which contains these quirks, and leave the
existing parameters alone. It should probably be a structure, with a
flags member. That makes it easier to add other members in the future.
lan865x can pass a NULL, since so far they have avoided breaking the
standard, they don't need any quirks.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Andrew Lunn @ 2026-05-28 1:15 UTC (permalink / raw)
To: Maxime Chevallier (Netdev Foundation)
Cc: Jakub Kicinski, 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: <20260522175109.198059-1-maxime.chevallier@bootlin.com>
> +A.1 : Sanity Checks
> +~~~~~~~~~~~~~~~~~~~
> +
> +Pause autoneg is set to off::
> +
> + ethtool -A <iface> autoneg off
> +
> +The 'supported' fields retrieved using the ETHTOOL_MSG_LINKMODES_GET includes
> +a "Pause" bit and an "Asym" bit.
> +
> +The ETHTOOL_MSG_PAUSE_GET command returns the currently configured pause modes
> +in the "tx" and "rx" attributes.
What you have left unspecified here is the state a link autoneg,
ethtool -s <iface> autoneg on|off
At minimum, it should be specified. I've not read the other tests yet,
but we may also want to run this basic test with both possible
setting.
One possible bug which we are trying to detect is that pause autoneg
is off, the values are forced, but -s autoneg is on, it completes, and
overwrites the forces values with negotiated values.
> +A.2 : Half-duplex operation
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Pause settings as exposed with the ethtool API only concern full-duplex modes.
> +
> +Test scenario:
> +--------------
> +
> +Set the interface under test in half-duplex mode with::
> +
> + ethtool -s <iface> duplex half
> +
> +Expected behaviour::
> +
> + - ethtool <iface>
> +
> +shows no Pause settings advertised.
Since we are talking about advertisement of pause, i think you actually want
ethtool -A <iface> autoneg on
ethtool -s <iface> duplex half autoneg on
If -s autoneg is off, nothing should be advertised. So we need that
turned on. And if -A autoneg is off, no pause values should be
advertised, so you need that turned on as well.
Also, since we expect this to trigger an autoneg, we probably want a
sleep(2) in there before looking at the results, to ensure autoneg has
completed.
There is also the possibility that the link does not come up, because
the link peer does not support half duplex. This is quite common for
1G interfaces. It could also be the local interface does not support
1G half. So maybe
ethtool -s <iface> duplex half speed 100 autoneg on
Or let it first autoneg unrestricted, look at both the local and LP
values, and pick a half duplex link mode both support and set it to do
that?
The tests defined so far also don't cover all the possible settings of
-A autoneg and -s autoneg. There are combinations:
Link autoneg with pause autoneg
Link autoneg with forced pause
Force link, with forced pause
It would be good to consider what can be tested for these three. Maybe
nothing can be tested with forced link, because that it likely to
result in no link, when only the local side can be configured.
> +B : Combined devices testing
> +============================
> +
> +Requirements : The interface under test must be connected to a link-partner that
> +can be actively configured during the tests. It must at least support full-duplex
> +modes, and optionally (but ideally) symmetric and asymmetric flow-control, as
> +well as autonegotiation of the Pause parameters.
and forced link parameters.
> +
> +B.1 : Autoneg advertising
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Goal: Validate that the *advertised* Pause and AsymDir bits match the configured
> +pausemarams.
typo.
> +
> +The link-level autonegotiation must be enabled::
> +
> + ethtool <iface> autoneg on
> +
> +Pause parameters are set with::
> +
> + ethtool -A <iface> rx <val> tx <val> autoneg on
> +
> +Pause advertising is retrieved with::
> +
> + ethtool <iface>
> +
> +Case 1
> +------
> +
> +Pause parameters : rx **off** tx **off**
> +
> +Expected advertisement : **None** (Pause = 0, AsymDir = 0)
> +
> +Case 2
> +------
> +
> +Pause parameters : rx **off** tx **on**
> +
> +Expected advertisement : **Transmit-only** (Pause = 0, AsymDir = 1)
> +
> +Case 3
> +------
> +
> +Pause parameters : rx **on** tx **off**
> +
> +Expected advertisement : **Symmetric receive-only** (Pause = 1, Asymdir = 1)
> +
> +Case 4
> +------
> +
> +Pause parameters : rx **on** tx **on**
> +
> +Expected advertisement : **Symmetric** (Pause = 1, Asymdir = 0)
We should consider here what happens when the local side only supports
symmetric pause. We would expect EOPNOTSUPP, or maybe EINVAL. If
ethtool report:
Supported pause frame use: Symmetric Receive-only
not getting an error for the asymmetric settings would be a bug.
> +
> +B.2 : Autoneg resolution
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Goal: Validate that the Pause and AsymDir negotiation translates to the right
> +TX and RX pause parameters.
> +
> +The following table, from the 802.3 standard, exposes the autoneg resolution
> +result for the advertised pause parameters by each link partner.
> +
> ++-------------+--------------+--------------------------+
> +|Local device | Link partner | Pause settings resolution|
> ++------+------+-------+------+-----------+--------------+
> +|Pause | Asym | Pause | Asym | RX | TX |
There is a tab vs space issue here.
> ++======+======+=======+======+===========+==============+
> +| 0 | 0 | Any | Any | No | No |
> ++------+------+-------+------+-----------+--------------+
> +| 0 | 1 | 0 | Any | No | No |
> ++------+------+-------+------+-----------+--------------+
> +| 0 | 1 | 1 | 0 | No | No |
> ++------+------+-------+------+-----------+--------------+
> +| 0 | 1 | 1 | 1 | No | Yes |
> ++------+------+-------+------+-----------+--------------+
> +| 1 | 0 | 0 | Any | No | No |
> ++------+------+-------+------+-----------+--------------+
> +| 1 | Any | 1 | Any | Yes | Yes |
> ++------+------+-------+------+-----------+--------------+
> +| 1 | 1 | 0 | 0 | No | No |
> ++------+------+-------+------+-----------+--------------+
> +| 1 | 1 | 0 | 1 | Yes | No |
> ++------+------+-------+------+-----------+--------------+
> +
> +The mapping between the configured pause parameters and advertised modes follow
> +the following truth table :
> +
> ++----+----+-------+---------+
> +| tx | rx | Pause | AsymDir |
> ++====+====+=======+=========+
> +| 0 | 0 | 0 | 0 |
> ++----+----+-------+---------+
> +| 0 | 1 | 1 | 1 |
> ++----+----+-------+---------+
> +| 1 | 0 | 0 | 1 |
> ++----+----+-------+---------+
> +| 1 | 1 | 1 | 0 |
> ++----+----+-------+---------+
> +
> +We can boil that down to the following cases to test, keeping the number small
> +to avoid dealing with the whole combinatory::
Why not do the whole set of combination? There are 16 combinations,
autoneg takes a little over 1 second, so we are probably talking 32
seconds in total. That is a reasonable runtime for a test.
> +Case 1
> +------
> +
> +Local device : rx **off**, tx **off**
> +Remote device : rx **on** tx **on**
> +
> +Expected result on local device after autonegotiation completes :
> + rx negotiated **off**
> + tx negotiated **off**
> +
...
> +Case 7
> +------
> +
> +Local device : rx **on** tx **on**
> +Remote device : rx **off** tx **off**
> +
> +Expected result on local device after autonegotiation completes :
> + rx negotiated **off**
> + tx negotiated **off**
> +
> +Case 8
> +------
> +
> +Local device : rx **on** tx **on**
> +Remote device : rx **off** tx **on**
> +
> +Expected result on local device after autonegotiation completes :
> + rx negotiated **on**
> + tx negotiated **off**
what also needs to be considered here is:
What if the local side only supports symmetric pause?
What if the LP only supports symmetric pause?
The expect results should take this into account, that the
configuration fails, but that is not a test failure, just a hardware
limitation.
> +
> +B.3 : Pause Autoneg
> +~~~~~~~~~~~~~~~~~~~
> +
> +Goal: Validate that the Pause autonegotiation flag correctly toggles the
> +advertised Pause and AsymDir link parameters.
> +
> +Test scenario:
> +--------------
> +
> + - Enable pause autoneg and at least rx or tx pause::
> +
> + ethtool -A <iface> rx on tx on autoneg on
> +
> + - Check the Advertised pause frame use::
> +
> + ethtool <iface>
> +
> + ...
> + Advertised pause frame use: Symmetric Receive-only
> +
> + - Disable pause autoneg::
> +
> + ethtool -A <iface> autoneg off
> +
> + - Check the Advertised pause frame use, which must be 'No'::
> +
> + ethtool <iface>
> +
> + ...
> + Advertised pause frame use: No
Please describe configuration for both sides. This is needed for all
the tests when there are two devices involved.
Also, when local pause advertisement is turned off, check what the
link partner is reporting it received from its link partner.
Andrew
^ permalink raw reply
* [PATCH 4/5] watchdog: core: clean up some comments
From: Randy Dunlap @ 2026-05-28 0:28 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260528002803.1260126-1-rdunlap@infradead.org>
Fix some grammar typos and bulleted kernel-doc comment format.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org
drivers/watchdog/watchdog_core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-next-20260525.orig/drivers/watchdog/watchdog_core.c
+++ linux-next-20260525/drivers/watchdog/watchdog_core.c
@@ -55,9 +55,9 @@ MODULE_PARM_DESC(stop_on_reboot, "Stop w
* for example when it's impossible to disable it. To do so,
* raising the initcall level of the watchdog driver is a solution.
* But in such case, the miscdev is maybe not ready (subsys_initcall), and
- * watchdog_core need miscdev to register the watchdog as a char device.
+ * watchdog_core needs miscdev to register the watchdog as a char device.
*
- * The deferred registration infrastructure offer a way for the watchdog
+ * The deferred registration infrastructure offers a way for the watchdog
* subsystem to register a watchdog properly, even before miscdev is ready.
*/
@@ -222,11 +222,11 @@ static int watchdog_pm_notifier(struct n
* watchdog_set_restart_priority - Change priority of restart handler
* @wdd: watchdog device
* @priority: priority of the restart handler, should follow these guidelines:
- * 0: use watchdog's restart function as last resort, has limited restart
- * capabilies
- * 128: default restart handler, use if no other handler is expected to be
+ * * 0: use watchdog's restart function as last resort, has limited restart
+ * capabilities
+ * * 128: default restart handler, use if no other handler is expected to be
* available and/or if restart is sufficient to restart the entire system
- * 255: preempt all other handlers
+ * * 255: preempt all other handlers
*
* If a wdd->ops->restart function is provided when watchdog_register_device is
* called, it will be registered as a restart handler with the priority given
^ permalink raw reply
* [PATCH 2/5] watchdog: linux/watchdog.h: repair kernel-doc comments
From: Randy Dunlap @ 2026-05-28 0:28 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260528002803.1260126-1-rdunlap@infradead.org>
Convert struct comments to correct kernel-doc format and
add one missing struct member description.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org
include/linux/watchdog.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- linux-next-20260525.orig/include/linux/watchdog.h
+++ linux-next-20260525/include/linux/watchdog.h
@@ -26,7 +26,8 @@ struct watchdog_device;
struct watchdog_core_data;
struct watchdog_governor;
-/** struct watchdog_ops - The watchdog-devices operations
+/**
+ * struct watchdog_ops - The watchdog-devices operations
*
* @owner: The module owner.
* @start: The routine for starting the watchdog device.
@@ -59,7 +60,8 @@ struct watchdog_ops {
long (*ioctl)(struct watchdog_device *, unsigned int, unsigned long);
};
-/** struct watchdog_device - The structure that defines a watchdog device
+/**
+ * struct watchdog_device - The structure that defines a watchdog device
*
* @id: The watchdog's ID. (Allocated by watchdog_register_device)
* @parent: The parent bus device
@@ -83,6 +85,8 @@ struct watchdog_ops {
* Replaces max_timeout if specified.
* @reboot_nb: The notifier block to stop watchdog on reboot.
* @restart_nb: The notifier block to register a restart function.
+ * @pm_nb: The notifier block to stop watchdog on suspend and restart it
+ * on resume.
* @driver_data:Pointer to the drivers private data.
* @wd_data: Pointer to watchdog core internal data.
* @status: Field that contains the devices internal status bits.
^ permalink raw reply
* [PATCH 3/5] watchdog: uapi: add comments for what bit masks apply to
From: Randy Dunlap @ 2026-05-28 0:28 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260528002803.1260126-1-rdunlap@infradead.org>
Add comments similar to those in include/linux/watchdog.h
so that the reader/user doesn't have to dig into the API documentation
files for this.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
include/uapi/linux/watchdog.h | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20260525.orig/include/uapi/linux/watchdog.h
+++ linux-next-20260525/include/uapi/linux/watchdog.h
@@ -36,6 +36,7 @@ struct watchdog_info {
#define WDIOF_UNKNOWN -1 /* Unknown flag error */
#define WDIOS_UNKNOWN -1 /* Unknown status error */
+/* Bit numbers for watchdog_info.options, GETSTATUS and GETBOOTSTATUS ioctls */
#define WDIOF_OVERHEAT 0x0001 /* Reset due to CPU overheat */
#define WDIOF_FANFAULT 0x0002 /* Fan failed */
#define WDIOF_EXTERN1 0x0004 /* External relay 1 */
@@ -50,6 +51,7 @@ struct watchdog_info {
other external alarm not a reboot */
#define WDIOF_KEEPALIVEPING 0x8000 /* Keep alive ping reply */
+/* Bit numbers for WDIOC_SETOPTIONS ioctl */
#define WDIOS_DISABLECARD 0x0001 /* Turn off the watchdog timer */
#define WDIOS_ENABLECARD 0x0002 /* Turn on the watchdog timer */
#define WDIOS_TEMPPANIC 0x0004 /* Kernel panic on temperature trip */
^ permalink raw reply
* [PATCH 1/5] watchdog: add devm_watchdog_register_device() to watchdog-kernel-api
From: Randy Dunlap @ 2026-05-28 0:27 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260528002803.1260126-1-rdunlap@infradead.org>
devm_watchdog_register_device() is not documented. Add it to the current
kernel API documentation.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Documentation/watchdog/watchdog-kernel-api.rst | 8 ++++++++
1 file changed, 8 insertions(+)
--- linux-next-20260525.orig/Documentation/watchdog/watchdog-kernel-api.rst
+++ linux-next-20260525/Documentation/watchdog/watchdog-kernel-api.rst
@@ -42,6 +42,14 @@ The watchdog subsystem includes a regist
which allows you to register a watchdog as early as you wish during
the boot process.
+There is also a resource-managed watchdog_register_device(),
+devm_watchdog_register_device(). If you use this to register a watchdog
+device, watchdog_unregister_device() is called automatically on driver
+detach::
+
+ int devm_watchdog_register_device(struct device *dev,
+ struct watchdog_device *wdd);
+
The watchdog device structure looks like this::
struct watchdog_device {
^ permalink raw reply
* [PATCH 0/5] watchdog: improve comments & Documentation
From: Randy Dunlap @ 2026-05-28 0:27 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
Jonathan Corbet, Shuah Khan, linux-doc
Add the missing devm_watchdog_register_device() to watchdog-kernel-api.rst.
Convert some struct and function comments to kernel-doc format.
Add some UAPI comments for quick reference.
Correct some grammar and bulleted list format.
[PATCH 1/5] watchdog: add devm_watchdog_register_device() to watchdog-kernel-api
[PATCH 2/5] watchdog: linux/watchdog.h: repair kernel-doc comments
[PATCH 3/5] watchdog: uapi: add comments for what bit masks apply to
[PATCH 4/5] watchdog: core: clean up some comments
[PATCH 5/5] watchdog: dev: convert to kernel-doc comments
Documentation/watchdog/watchdog-kernel-api.rst | 8 ++++
drivers/watchdog/watchdog_core.c | 12 +++---
drivers/watchdog/watchdog_dev.c | 30 +++++++--------
include/linux/watchdog.h | 8 +++-
include/uapi/linux/watchdog.h | 2 +
5 files changed, 37 insertions(+), 23 deletions(-)
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
^ permalink raw reply
* [PATCH 5/5] watchdog: dev: convert to kernel-doc comments
From: Randy Dunlap @ 2026-05-28 0:28 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260528002803.1260126-1-rdunlap@infradead.org>
Convert multiple functions to kernel-doc format.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org
drivers/watchdog/watchdog_dev.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
--- linux-next-20260525.orig/drivers/watchdog/watchdog_dev.c
+++ linux-next-20260525/drivers/watchdog/watchdog_dev.c
@@ -176,7 +176,7 @@ static int __watchdog_ping(struct watchd
return err;
}
-/*
+/**
* watchdog_ping - ping the watchdog
* @wdd: The watchdog device to ping
*
@@ -236,7 +236,7 @@ static enum hrtimer_restart watchdog_tim
return HRTIMER_NORESTART;
}
-/*
+/**
* watchdog_start - wrapper to start the watchdog
* @wdd: The watchdog device to start
*
@@ -279,7 +279,7 @@ static int watchdog_start(struct watchdo
return err;
}
-/*
+/**
* watchdog_stop - wrapper to stop the watchdog
* @wdd: The watchdog device to stop
*
@@ -319,7 +319,7 @@ static int watchdog_stop(struct watchdog
return err;
}
-/*
+/**
* watchdog_get_status - wrapper to get the watchdog status
* @wdd: The watchdog device to get the status from
*
@@ -356,7 +356,7 @@ static unsigned int watchdog_get_status(
return status;
}
-/*
+/**
* watchdog_set_timeout - set the watchdog timer timeout
* @wdd: The watchdog device to set the timeout for
* @timeout: Timeout to set in seconds
@@ -391,7 +391,7 @@ static int watchdog_set_timeout(struct w
return err;
}
-/*
+/**
* watchdog_set_pretimeout - set the watchdog timer pretimeout
* @wdd: The watchdog device to set the timeout for
* @timeout: pretimeout to set in seconds
@@ -417,7 +417,7 @@ static int watchdog_set_pretimeout(struc
return err;
}
-/*
+/**
* watchdog_get_timeleft - wrapper to get the time left before a reboot
* @wdd: The watchdog device to get the remaining time from
* @timeleft: The time that's left
@@ -659,7 +659,7 @@ __ATTRIBUTE_GROUPS(wdt);
#define wdt_groups NULL
#endif
-/*
+/**
* watchdog_ioctl_op - call the watchdog drivers ioctl op if defined
* @wdd: The watchdog device to do the ioctl on
* @cmd: Watchdog command
@@ -678,7 +678,7 @@ static int watchdog_ioctl_op(struct watc
return wdd->ops->ioctl(wdd, cmd, arg);
}
-/*
+/**
* watchdog_write - writes to the watchdog
* @file: File from VFS
* @data: User address of data
@@ -732,7 +732,7 @@ static ssize_t watchdog_write(struct fil
return len;
}
-/*
+/**
* watchdog_ioctl - handle the different ioctl's for the watchdog device
* @file: File handle to the device
* @cmd: Watchdog command
@@ -845,7 +845,7 @@ out_ioctl:
return err;
}
-/*
+/**
* watchdog_open - open the /dev/watchdog* devices
* @inode: Inode of device
* @file: File handle to device
@@ -923,7 +923,7 @@ static void watchdog_core_data_release(s
kfree(wd_data);
}
-/*
+/**
* watchdog_release - release the watchdog device
* @inode: Inode of device
* @file: File handle to device
@@ -932,7 +932,7 @@ static void watchdog_core_data_release(s
* stop the watchdog when we have received the magic char (and nowayout
* was not set), else the watchdog will keep running.
*
- * Always returns 0.
+ * Returns: Always 0.
*/
static int watchdog_release(struct inode *inode, struct file *file)
{
@@ -1004,7 +1004,7 @@ static const struct class watchdog_class
.dev_groups = wdt_groups,
};
-/*
+/**
* watchdog_cdev_register - register watchdog character device
* @wdd: Watchdog device
*
@@ -1105,7 +1105,7 @@ static int watchdog_cdev_register(struct
return 0;
}
-/*
+/**
* watchdog_cdev_unregister - unregister watchdog character device
* @wdd: Watchdog device
*
^ 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