* [PATCH v2 2/2] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Fenglin Wu @ 2026-04-03 0:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu, Taniya Das
In-Reply-To: <20260402-haw-rpmhpd-v2-0-2bce0767f2ca@oss.qualcomm.com>
Add the RPMh power domains required for the Hawi SoC. This includes
new definitions for domains supplying specific hardware components:
- DCX: supplies VDD_DISP
- GBX: supplies VDD_GFX_BX
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index 19849703be4a..f5ae2a63765d 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -102,11 +102,21 @@ static struct rpmhpd cx_ao_w_mx_parent = {
.res_name = "cx.lvl",
};
+static struct rpmhpd dcx = {
+ .pd = { .name = "dcx", },
+ .res_name = "dcx.lvl",
+};
+
static struct rpmhpd ebi = {
.pd = { .name = "ebi", },
.res_name = "ebi.lvl",
};
+static struct rpmhpd gbx = {
+ .pd = { .name = "gbx", },
+ .res_name = "gbx.lvl",
+};
+
static struct rpmhpd gfx = {
.pd = { .name = "gfx", },
.res_name = "gfx.lvl",
@@ -622,6 +632,33 @@ static const struct rpmhpd_desc kaanapali_desc = {
.num_pds = ARRAY_SIZE(kaanapali_rpmhpds),
};
+/* Hawi RPMH powerdomains */
+static struct rpmhpd *hawi_rpmhpds[] = {
+ [RPMHPD_CX] = &cx,
+ [RPMHPD_CX_AO] = &cx_ao,
+ [RPMHPD_DCX] = &dcx,
+ [RPMHPD_EBI] = &ebi,
+ [RPMHPD_GBX] = &gbx,
+ [RPMHPD_GFX] = &gfx,
+ [RPMHPD_GMXC] = &gmxc,
+ [RPMHPD_LCX] = &lcx,
+ [RPMHPD_LMX] = &lmx,
+ [RPMHPD_MMCX] = &mmcx,
+ [RPMHPD_MMCX_AO] = &mmcx_ao,
+ [RPMHPD_MX] = &mx,
+ [RPMHPD_MX_AO] = &mx_ao,
+ [RPMHPD_MXC] = &mxc,
+ [RPMHPD_MXC_AO] = &mxc_ao,
+ [RPMHPD_MSS] = &mss,
+ [RPMHPD_NSP] = &nsp,
+ [RPMHPD_NSP2] = &nsp2,
+};
+
+static const struct rpmhpd_desc hawi_desc = {
+ .rpmhpds = hawi_rpmhpds,
+ .num_pds = ARRAY_SIZE(hawi_rpmhpds),
+};
+
/* QDU1000/QRU1000 RPMH powerdomains */
static struct rpmhpd *qdu1000_rpmhpds[] = {
[QDU1000_CX] = &cx,
@@ -796,6 +833,7 @@ static const struct rpmhpd_desc qcs615_desc = {
static const struct of_device_id rpmhpd_match_table[] = {
{ .compatible = "qcom,glymur-rpmhpd", .data = &glymur_desc },
+ { .compatible = "qcom,hawi-rpmhpd", .data = &hawi_desc },
{ .compatible = "qcom,kaanapali-rpmhpd", .data = &kaanapali_desc },
{ .compatible = "qcom,milos-rpmhpd", .data = &milos_desc },
{ .compatible = "qcom,qcs615-rpmhpd", .data = &qcs615_desc },
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Hawi SoC
From: Fenglin Wu @ 2026-04-03 0:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
In-Reply-To: <20260402-haw-rpmhpd-v2-0-2bce0767f2ca@oss.qualcomm.com>
Document the RPMh power domain for Hawi SoC, and add definitions for
the new power domains which present in Hawi SoC:
- RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display
subsystem
- RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics
subsystem
Also, add constants for new power domain levels that supported in Hawi
SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0,
TURBO_L1_0/1/2, TURBO_L1_0/1/2.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
include/dt-bindings/power/qcom,rpmhpd.h | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 27af5b8aa134..35a0e01c2015 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -18,6 +18,7 @@ properties:
oneOf:
- enum:
- qcom,glymur-rpmhpd
+ - qcom,hawi-rpmhpd
- qcom,kaanapali-rpmhpd
- qcom,mdm9607-rpmpd
- qcom,milos-rpmhpd
diff --git a/include/dt-bindings/power/qcom,rpmhpd.h b/include/dt-bindings/power/qcom,rpmhpd.h
index 06851363ae0e..67e2634fdc99 100644
--- a/include/dt-bindings/power/qcom,rpmhpd.h
+++ b/include/dt-bindings/power/qcom,rpmhpd.h
@@ -28,15 +28,20 @@
#define RPMHPD_XO 18
#define RPMHPD_NSP2 19
#define RPMHPD_GMXC 20
+#define RPMHPD_DCX 21
+#define RPMHPD_GBX 22
/* RPMh Power Domain performance levels */
#define RPMH_REGULATOR_LEVEL_RETENTION 16
#define RPMH_REGULATOR_LEVEL_MIN_SVS 48
+#define RPMH_REGULATOR_LEVEL_LOW_SVS_D3_0 49
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D3 50
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D2_1 51
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D2 52
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D1_1 54
+#define RPMH_REGULATOR_LEVEL_LOW_SVS_D1_0 55
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D1 56
+#define RPMH_REGULATOR_LEVEL_LOW_SVS_D0_0 59
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D0 60
#define RPMH_REGULATOR_LEVEL_LOW_SVS 64
#define RPMH_REGULATOR_LEVEL_LOW_SVS_P1 72
@@ -47,6 +52,7 @@
#define RPMH_REGULATOR_LEVEL_SVS_L0 144
#define RPMH_REGULATOR_LEVEL_SVS_L1 192
#define RPMH_REGULATOR_LEVEL_SVS_L2 224
+#define RPMH_REGULATOR_LEVEL_SVS_L2_0 225
#define RPMH_REGULATOR_LEVEL_NOM 256
#define RPMH_REGULATOR_LEVEL_NOM_L0 288
#define RPMH_REGULATOR_LEVEL_NOM_L1 320
@@ -54,8 +60,14 @@
#define RPMH_REGULATOR_LEVEL_TURBO 384
#define RPMH_REGULATOR_LEVEL_TURBO_L0 400
#define RPMH_REGULATOR_LEVEL_TURBO_L1 416
+#define RPMH_REGULATOR_LEVEL_TURBO_L1_0 417
+#define RPMH_REGULATOR_LEVEL_TURBO_L1_1 418
+#define RPMH_REGULATOR_LEVEL_TURBO_L1_2 419
#define RPMH_REGULATOR_LEVEL_TURBO_L2 432
#define RPMH_REGULATOR_LEVEL_TURBO_L3 448
+#define RPMH_REGULATOR_LEVEL_TURBO_L3_0 449
+#define RPMH_REGULATOR_LEVEL_TURBO_L3_1 450
+#define RPMH_REGULATOR_LEVEL_TURBO_L3_2 451
#define RPMH_REGULATOR_LEVEL_TURBO_L4 452
#define RPMH_REGULATOR_LEVEL_TURBO_L5 456
#define RPMH_REGULATOR_LEVEL_SUPER_TURBO 464
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] power: qcom,rpmpd: add RPMh power doamins support for Hawi SoC
From: Fenglin Wu @ 2026-04-03 0:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu, Taniya Das
Add constant definitions for the new power domains and new voltage
levels present in Hawi SoC. Also add RPMH power domain support for
Hawi SoC.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Changes in v2:
- Squash patch 1 and 2 into a single binding change
- Add trailers for the new patch 2
- Link to v1: https://patch.msgid.link/20260401-haw-rpmhpd-v1-0-c830c79ed8f9@oss.qualcomm.com
---
Fenglin Wu (2):
dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Hawi SoC
pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++
include/dt-bindings/power/qcom,rpmhpd.h | 12 +++++++
3 files changed, 51 insertions(+)
---
base-commit: 33b1a2ee3a3df63e7a08e51e6de2b2d28ddf257f
change-id: 20260401-haw-rpmhpd-b40a68a3ce79
Best regards,
--
Fenglin Wu <fenglin.wu@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: power: qcom,rpmhpd: Add new power domains and new levels
From: Fenglin Wu @ 2026-04-03 0:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio, Subbaraman Narayanamurthy,
linux-arm-msm, devicetree, linux-kernel, linux-pm, kernel
In-Reply-To: <20260402-great-affable-panther-1a5ed7@quoll>
On 4/2/2026 4:34 PM, Krzysztof Kozlowski wrote:
> On Wed, Apr 01, 2026 at 02:15:30AM -0700, Fenglin Wu wrote:
>> Add definitions for the new power domains which present in Hawi SoC:
>> - RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display
>> subsystem
>> - RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics
>> subsystem
>>
>> Also, add constants for new power domain levels that supported in Hawi
>> SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0,
>> TURBO_L1_0/1/2, TURBO_L1_0/1/2.
>>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> This belongs to the binding change. Unless you are not doing it for
> Hawi...
Sure, I will squash patch 1 and patch 2 and resend.
Thanks.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 3/3] power: sequencing: pcie-m2: Guard the helper functions making use of PCI bus notifier
From: kernel test robot @ 2026-04-02 22:56 UTC (permalink / raw)
To: Manivannan Sadhasivam, brgl, robh
Cc: llvm, oe-kbuild-all, linux-pci, linux-pm, linux-kernel,
linux-serial, mani, Manivannan Sadhasivam, kernel test robot
In-Reply-To: <20260401070735.107162-4-manivannan.sadhasivam@oss.qualcomm.com>
Hi Manivannan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linux-next/master]
[also build test WARNING on linus/master v6.16-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Manivannan-Sadhasivam/serdev-Add-missing-stubs-for-serdev-APIs-when-CONFIG_SERIAL_DEV_BUS-is-not-selected/20260402-225703
base: linux-next/master
patch link: https://lore.kernel.org/r/20260401070735.107162-4-manivannan.sadhasivam%40oss.qualcomm.com
patch subject: [PATCH 3/3] power: sequencing: pcie-m2: Guard the helper functions making use of PCI bus notifier
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260403/202604030008.5exLAPFm-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260403/202604030008.5exLAPFm-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/202604030008.5exLAPFm-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/tty/tty_port.c:20:
>> include/linux/serdev.h:268:83: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
268 | static inline struct serdev_device *serdev_device_alloc(struct serdev_controller *)
| ^
include/linux/serdev.h:272:59: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
272 | static inline int serdev_device_add(struct serdev_device *)
| ^
include/linux/serdev.h:276:63: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
276 | static inline void serdev_device_remove(struct serdev_device *) {}
| ^
include/linux/serdev.h:284:67: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
284 | static inline int serdev_controller_add(struct serdev_controller *)
| ^
include/linux/serdev.h:288:71: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
288 | static inline void serdev_controller_remove(struct serdev_controller *) {}
| ^
5 warnings generated.
vim +268 include/linux/serdev.h
267
> 268 static inline struct serdev_device *serdev_device_alloc(struct serdev_controller *)
269 {
270 return NULL;
271 }
272 static inline int serdev_device_add(struct serdev_device *)
273 {
274 return -ENODEV;
275 }
276 static inline void serdev_device_remove(struct serdev_device *) {}
277
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] power: supply: qcom_smbx: allow disabling charging
From: Sebastian Reichel @ 2026-04-02 22:54 UTC (permalink / raw)
To: Casey Connolly, Sebastian Reichel, Konrad Dybcio,
David Heidelberg
Cc: linux-arm-msm, linux-pm, linux-kernel, phone-devel
In-Reply-To: <20260315-smb2-cherry-pick-v1-1-b2710e470490@ixit.cz>
On Sun, 15 Mar 2026 20:40:16 +0100, David Heidelberg wrote:
> Hook up USBIN_CMD_IL so that writing "0" to the status register will
> disable charging, this is useful to let users limit charging
> automatically.
>
>
Applied, thanks!
[1/1] power: supply: qcom_smbx: allow disabling charging
commit: 98d68b74ebb9d5f145960ff7d96ce8e7a39fb965
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/2] dt-bindings: power: reset: cortina: Convert to DT schema and rename node
From: Sebastian Reichel @ 2026-04-02 22:54 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw,
Khushal Chitturi
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
On Mon, 30 Mar 2026 16:31:33 +0530, Khushal Chitturi wrote:
> Convert the Cortina Systems Gemini Poweroff Controller bindings to
> DT schema and update corresponding dtsi file with new node name
>
Applied, thanks!
[1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
commit: 64a97c98f93e344be00d4ff10fef4119973938bd
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/9] gpio: remove uneeded Kconfig dependencies on OF_GPIO
From: Sebastian Reichel @ 2026-04-02 22:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Linus Walleij, Lee Jones, Pavel Machek,
Wim Van Sebroeck, Guenter Roeck, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Sebastian Reichel, Bartosz Golaszewski
Cc: brgl, linux-arm-kernel, linux-kernel, netdev, linux-gpio,
linux-leds, linux-watchdog, linux-media, linux-staging, linux-pm
In-Reply-To: <20260316-gpio-of-kconfig-v2-0-de2f4b00a0e4@oss.qualcomm.com>
On Mon, 16 Mar 2026 10:45:20 +0100, Bartosz Golaszewski wrote:
> NOTE: Each patch in this series can be picked up independently into
> maintainer trees.
>
> CONFIG_OF_GPIO is a switch that enables the compilation of the gpiolib-of
> module. The module itself handles GPIO lookup via the OF-node tree and
> is automatically enabled on all OF systems. It does not export any
> public symbols to drivers. There is no reason for them to select or
> depend on it in Kconfig.
>
> [...]
Applied, thanks!
[8/9] power: reset: drop unneeded dependencies on OF_GPIO
commit: 0629c33fe1873a48e1e06078409de76c5a159fdb
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [PATCH] power: supply: bd71828: add input current limit property
From: Sebastian Reichel @ 2026-04-02 22:54 UTC (permalink / raw)
To: Matti Vaittinen, Sebastian Reichel, Andreas Kemnade
Cc: linux-pm, linux-kernel
In-Reply-To: <20260401-bd-inp-limit-v1-1-689eb22531e2@kemnade.info>
On Wed, 01 Apr 2026 23:17:05 +0200, Andreas Kemnade wrote:
> Add input current property to be able to work around issues created by
> automatic input limiting and have some control.
> Disabling the automatic management is another step.
>
>
Applied, thanks!
[1/1] power: supply: bd71828: add input current limit property
commit: be353c6729d087925da702cf8c0ad3cb1ae53dec
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] power: supply: Add PD SPR AVS support to USB type enum
From: Sebastian Reichel @ 2026-04-02 22:39 UTC (permalink / raw)
To: Badhri Jagan Sridharan
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heikki Krogerus,
Greg Kroah-Hartman, Amit Sunil Dhamne, devicetree, linux-kernel,
linux-pm, linux-usb
In-Reply-To: <20260316150301.3892223-3-badhri@google.com>
[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]
Hi,
On Mon, Mar 16, 2026 at 03:03:00PM +0000, Badhri Jagan Sridharan wrote:
> Add two new members to the power_supply_usb_type to represent the
> USB Power Delivery (PD) Standard Power Range (SPR) Adjustable Voltage
> Supply (AVS) charging types:
>
> POWER_SUPPLY_USB_TYPE_PD_SPR_AVS: For devices supporting only the
> PD SPR AVS type.
>
> POWER_SUPPLY_USB_TYPE_PD_PPS_SPR_AVS: For devices that support both
> PD Programmable Power Supply (PPS) and PD SPR AVS.
>
> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
> ---
I'm not too fond of these types, but I guess we already fell into
the rabbit hole when PD_PPS was added. So:
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
I guess the patches will be handled via the USB tree.
Greetings,
-- Sebastian
> Documentation/ABI/testing/sysfs-class-power | 3 ++-
> drivers/power/supply/power_supply_sysfs.c | 2 ++
> include/linux/power_supply.h | 3 +++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
> index 4b21d5d23251..32697b926cc8 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -675,7 +675,8 @@ Description:
>
> Valid values:
> "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
> - "PD_DRP", "PD_PPS", "BrickID"
> + "PD_DRP", "PD_PPS", "BrickID", "PD_SPR_AVS",
> + "PD_PPS_SPR_AVS"
>
> **Device Specific Properties**
>
> diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
> index dd3a48d72d2b..f30a7b9ccd5e 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -70,6 +70,8 @@ static const char * const POWER_SUPPLY_USB_TYPE_TEXT[] = {
> [POWER_SUPPLY_USB_TYPE_PD] = "PD",
> [POWER_SUPPLY_USB_TYPE_PD_DRP] = "PD_DRP",
> [POWER_SUPPLY_USB_TYPE_PD_PPS] = "PD_PPS",
> + [POWER_SUPPLY_USB_TYPE_PD_SPR_AVS] = "PD_SPR_AVS",
> + [POWER_SUPPLY_USB_TYPE_PD_PPS_SPR_AVS] = "PD_PPS_SPR_AVS",
> [POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID] = "BrickID",
> };
>
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 360ffdf272da..7a5e4c3242a0 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -210,6 +210,9 @@ enum power_supply_usb_type {
> POWER_SUPPLY_USB_TYPE_PD, /* Power Delivery Port */
> POWER_SUPPLY_USB_TYPE_PD_DRP, /* PD Dual Role Port */
> POWER_SUPPLY_USB_TYPE_PD_PPS, /* PD Programmable Power Supply */
> + /* PD Standard Power Range Adjustable Voltage Supply */
> + POWER_SUPPLY_USB_TYPE_PD_SPR_AVS,
> + POWER_SUPPLY_USB_TYPE_PD_PPS_SPR_AVS, /* Supports both PD PPS + SPR AVS */
> POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID, /* Apple Charging Method */
> };
>
> --
> 2.53.0.851.ga537e3e6e9-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] power: supply: max77759_charger: fix voltage scale (mV -> uV)
From: Sebastian Reichel @ 2026-04-02 22:28 UTC (permalink / raw)
To: amitsd
Cc: Greg Kroah-Hartman, André Draszik, linux-kernel, linux-pm,
linux-usb, Badhri Jagan Sridharan
In-Reply-To: <20260402-fix-psy-max77759-usb-next-v1-1-427f5af566c3@google.com>
[-- Attachment #1: Type: text/plain, Size: 8432 bytes --]
Hi,
On Thu, Apr 02, 2026 at 07:15:29AM +0000, Amit Sunil Dhamne via B4 Relay wrote:
> From: Amit Sunil Dhamne <amitsd@google.com>
>
> CONSTANT_CHARGE_VOLTAGE_MAX property incorrectly uses mV instead of uV.
> Add fix to use uV as per the power-supply subsystem convention.
>
> Also, add a note indicating all the properties use non negative values.
> A negative value indicates failure with the appropriate error value. In
> that case, it should not be taken as a measurement value or status.
>
> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
> ---
> This patch is a follow-up to the series [1]. [1] has been accepted in
> the USB subsystem tree (usb-next). However, since Sebastian has additional
> feedback [2], I am sending this patch to address it. Please note that this
> patch is based out of usb-next branch on usb tree. This patch should be
> applied on top of 70d7dd27f6dc ("power: supply: max77759: add charger driver").
>
> [1] https://lore.kernel.org/all/20260325-max77759-charger-v9-0-4486dd297adc@google.com/
> [2] https://lore.kernel.org/all/ac2jYUA2F5oQsA2g@venus/#t
> ---
Fixes: 70d7dd27f6dc ("power: supply: max77759: add charger driver")
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Greetings,
-- Sebastian
> Output of power supply selftest:
> root@google-gs:/data/power_supply# ./test_power_supply_properties.sh
> TAP version 13
> 1..66
> # Testing device max77759-charger
> ok 1 max77759-charger.exists
> ok 2 max77759-charger.uevent.NAME
> ok 3 max77759-charger.sysfs.type
> ok 4 max77759-charger.uevent.TYPE
> ok 5 max77759-charger.sysfs.usb_type # SKIP
> # Reported: '1' ()
> ok 6 max77759-charger.sysfs.online
> # Reported: '1' ()
> ok 7 max77759-charger.sysfs.present
> # Reported: 'Charging'
> ok 8 max77759-charger.sysfs.status
> ok 9 max77759-charger.sysfs.capacity # SKIP
> ok 10 max77759-charger.sysfs.capacity_level # SKIP
> ok 11 max77759-charger.sysfs.model_name # SKIP
> ok 12 max77759-charger.sysfs.manufacturer # SKIP
> ok 13 max77759-charger.sysfs.serial_number # SKIP
> ok 14 max77759-charger.sysfs.technology # SKIP
> ok 15 max77759-charger.sysfs.cycle_count # SKIP
> ok 16 max77759-charger.sysfs.scope # SKIP
> # Reported: '3000000' uA (3000 mA)
> ok 17 max77759-charger.sysfs.input_current_limit
> ok 18 max77759-charger.sysfs.input_voltage_limit # SKIP
> ok 19 max77759-charger.sysfs.voltage_now # SKIP
> ok 20 max77759-charger.sysfs.voltage_min # SKIP
> ok 21 max77759-charger.sysfs.voltage_max # SKIP
> ok 22 max77759-charger.sysfs.voltage_min_design # SKIP
> ok 23 max77759-charger.sysfs.voltage_max_design # SKIP
> ok 24 max77759-charger.sysfs.current_now # SKIP
> ok 25 max77759-charger.sysfs.current_max # SKIP
> ok 26 max77759-charger.sysfs.charge_now # SKIP
> ok 27 max77759-charger.sysfs.charge_full # SKIP
> ok 28 max77759-charger.sysfs.charge_full_design # SKIP
> ok 29 max77759-charger.sysfs.power_now # SKIP
> ok 30 max77759-charger.sysfs.energy_now # SKIP
> ok 31 max77759-charger.sysfs.energy_full # SKIP
> ok 32 max77759-charger.sysfs.energy_full_design # SKIP
> ok 33 max77759-charger.sysfs.energy_full_design # SKIP
> # Testing device tcpm-source-psy-1-0025
> ok 34 tcpm-source-psy-1-0025.exists
> ok 35 tcpm-source-psy-1-0025.uevent.NAME
> ok 36 tcpm-source-psy-1-0025.sysfs.type
> ok 37 tcpm-source-psy-1-0025.uevent.TYPE
> # Reported: 'C [PD] PD_PPS PD_SPR_AVS PD_PPS_SPR_AVS' ()
> ok 38 tcpm-source-psy-1-0025.sysfs.usb_type
> # Reported: '1' ()
> ok 39 tcpm-source-psy-1-0025.sysfs.online
> ok 40 tcpm-source-psy-1-0025.sysfs.present # SKIP
> ok 41 tcpm-source-psy-1-0025.sysfs.status # SKIP
> ok 42 tcpm-source-psy-1-0025.sysfs.capacity # SKIP
> ok 43 tcpm-source-psy-1-0025.sysfs.capacity_level # SKIP
> ok 44 tcpm-source-psy-1-0025.sysfs.model_name # SKIP
> ok 45 tcpm-source-psy-1-0025.sysfs.manufacturer # SKIP
> ok 46 tcpm-source-psy-1-0025.sysfs.serial_number # SKIP
> ok 47 tcpm-source-psy-1-0025.sysfs.technology # SKIP
> ok 48 tcpm-source-psy-1-0025.sysfs.cycle_count # SKIP
> ok 49 tcpm-source-psy-1-0025.sysfs.scope # SKIP
> ok 50 tcpm-source-psy-1-0025.sysfs.input_current_limit # SKIP
> ok 51 tcpm-source-psy-1-0025.sysfs.input_voltage_limit # SKIP
> # Reported: '5000000' uV (5 V)
> ok 52 tcpm-source-psy-1-0025.sysfs.voltage_now
> # Reported: '5000000' uV (5 V)
> ok 53 tcpm-source-psy-1-0025.sysfs.voltage_min
> # Reported: '5000000' uV (5 V)
> ok 54 tcpm-source-psy-1-0025.sysfs.voltage_max
> ok 55 tcpm-source-psy-1-0025.sysfs.voltage_min_design # SKIP
> ok 56 tcpm-source-psy-1-0025.sysfs.voltage_max_design # SKIP
> # Reported: '3000000' uA (3000 mA)
> ok 57 tcpm-source-psy-1-0025.sysfs.current_now
> # Reported: '3000000' uA (3000 mA)
> ok 58 tcpm-source-psy-1-0025.sysfs.current_max
> ok 59 tcpm-source-psy-1-0025.sysfs.charge_now # SKIP
> ok 60 tcpm-source-psy-1-0025.sysfs.charge_full # SKIP
> ok 61 tcpm-source-psy-1-0025.sysfs.charge_full_design # SKIP
> ok 62 tcpm-source-psy-1-0025.sysfs.power_now # SKIP
> ok 63 tcpm-source-psy-1-0025.sysfs.energy_now # SKIP
> ok 64 tcpm-source-psy-1-0025.sysfs.energy_full # SKIP
> ok 65 tcpm-source-psy-1-0025.sysfs.energy_full_design # SKIP
> ok 66 tcpm-source-psy-1-0025.sysfs.energy_full_design # SKIP
> # 47 skipped test(s) detected. Consider enabling relevant config options to improve coverage.
> # Totals: pass:19 fail:0 xfail:0 xpass:0 skip:47 error:0
> ---
> drivers/power/supply/max77759_charger.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/power/supply/max77759_charger.c b/drivers/power/supply/max77759_charger.c
> index 9bb414599f16..58594bb78426 100644
> --- a/drivers/power/supply/max77759_charger.c
> +++ b/drivers/power/supply/max77759_charger.c
> @@ -26,7 +26,7 @@
>
> /* Default values for Fast Charge Current & Float Voltage */
> #define CHG_CC_DEFAULT_UA 2266770
> -#define CHG_FV_DEFAULT_MV 4300
> +#define CHG_FV_DEFAULT_UV 4300000
>
> #define MAX_NUM_RETRIES 3
> #define PSY_WORK_RETRY_DELAY_MS 10
> @@ -61,10 +61,10 @@ static const struct linear_range chgcc_limit_ranges[] = {
> LINEAR_RANGE(200000, 0x3, 0x3C, 66670),
> };
>
> -/* Charge Termination Voltage Limits (in mV) */
> +/* Charge Termination Voltage Limits (in uV) */
> static const struct linear_range chg_cv_prm_ranges[] = {
> - LINEAR_RANGE(3800, 0x38, 0x39, 100),
> - LINEAR_RANGE(4000, 0x0, 0x32, 10),
> + LINEAR_RANGE(3800000, 0x38, 0x39, 100000),
> + LINEAR_RANGE(4000000, 0x0, 0x32, 10000),
> };
>
> /* USB input current limits (in uA) */
> @@ -310,14 +310,14 @@ static int get_float_voltage(struct max77759_charger *chg)
> return ret ? ret : val;
> }
>
> -static int set_float_voltage_limit(struct max77759_charger *chg, u32 fv_mv)
> +static int set_float_voltage_limit(struct max77759_charger *chg, u32 fv_uv)
> {
> u32 regval;
> bool found;
>
> linear_range_get_selector_high_array(chg_cv_prm_ranges,
> ARRAY_SIZE(chg_cv_prm_ranges),
> - fv_mv, ®val, &found);
> + fv_uv, ®val, &found);
> if (!found)
> return -EINVAL;
>
> @@ -370,6 +370,11 @@ static const enum power_supply_property max77759_charger_props[] = {
> POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
> };
>
> +/*
> + * Note: None of the properties in this driver support usage of negative values.
> + * If you do see one, it's because the function is reporting an error value and
> + * should not be taken as a measurement value or status.
> + */
> static int max77759_charger_get_property(struct power_supply *psy,
> enum power_supply_property psp,
> union power_supply_propval *pval)
> @@ -557,10 +562,10 @@ static int max77759_charger_init(struct max77759_charger *chg)
> return ret;
>
> if (power_supply_get_battery_info(chg->psy, &info)) {
> - fv = CHG_FV_DEFAULT_MV;
> + fv = CHG_FV_DEFAULT_UV;
> fast_chg_curr = CHG_CC_DEFAULT_UA;
> } else {
> - fv = info->constant_charge_voltage_max_uv / 1000;
> + fv = info->constant_charge_voltage_max_uv;
> fast_chg_curr = info->constant_charge_current_max_ua;
> }
>
>
> ---
> base-commit: 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d
> change-id: 20260402-fix-psy-max77759-usb-next-15a4f86a08ce
>
> Best regards,
> --
> Amit Sunil Dhamne <amitsd@google.com>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [rafael-pm:fixes] BUILD SUCCESS 3cc0b373bfce228551d54404eb2e763a1fd1968d
From: kernel test robot @ 2026-04-02 22:15 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git fixes
branch HEAD: 3cc0b373bfce228551d54404eb2e763a1fd1968d Merge branch 'thermal-core-fixes' into fixes
elapsed time: 733m
configs tested: 219
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260402 gcc-11.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260402 gcc-15.2.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260402 gcc-15.2.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260402 clang-20
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260402 clang-20
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260402 clang-20
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260402 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260402 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260402 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260402 gcc-14
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260402 gcc-14
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260402 gcc-14
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260402 gcc-14
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS d8d394c43391141e6369ccfa5e40b88841a6d939
From: kernel test robot @ 2026-04-02 22:14 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: d8d394c43391141e6369ccfa5e40b88841a6d939 Merge branch 'experimental/acpi-driver-conversion' into bleeding-edge
elapsed time: 733m
configs tested: 219
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260402 gcc-11.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260402 gcc-15.2.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260402 gcc-15.2.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260402 clang-20
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260402 clang-20
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260402 clang-20
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260402 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260402 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260402 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260402 gcc-14
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260402 gcc-14
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260402 gcc-14
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260402 gcc-14
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 1/2] power: reset: Add QEMU virt-ctrl driver
From: Sebastian Reichel @ 2026-04-02 21:52 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: geert, jserv, eleanor15x, daniel, laurent, linux-kernel,
linux-m68k, linux-pm
In-Reply-To: <20260222173225.1105572-2-visitorckw@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7126 bytes --]
Hi,
On Sun, Feb 22, 2026 at 05:32:24PM +0000, Kuan-Wei Chiu wrote:
> Add a new driver for the 'virt-ctrl' device found on QEMU virt machines
> (e.g. m68k). This device provides a simple interface for system reset
> and power off [1].
>
> This driver utilizes the modern system-off API to register callbacks
> for both system restart and power off. It also registers a reboot
> notifier to catch SYS_HALT events, ensuring that LINUX_REBOOT_CMD_HALT
> is properly handled. It is designed to be generic and can be reused by
> other architectures utilizing this QEMU device.
>
> Link: https://gitlab.com/qemu-project/qemu/-/blob/v10.2.0/hw/misc/virt_ctrl.c [1]
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
I think this should be merged with the second patch via the m68k
tree:
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Greetings,
-- Sebastian
> Changes in v3:
> - Add a reboot notifier to handle SYS_HALT.
> - Implement virt_ctrl_write32() to handle native endianness.
>
> I noticed devm_register_sys_off_handler() currently lacks a
> SYS_OFF_MODE_HALT. Therefore, I registered a standard reboot notifier
> for SYS_HALT, while keeping restart and power-off on the sys-off API.
>
> MAINTAINERS | 6 ++
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/qemu-virt-ctrl.c | 122 +++++++++++++++++++++++++++
> 4 files changed, 139 insertions(+)
> create mode 100644 drivers/power/reset/qemu-virt-ctrl.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 55af015174a5..aa9eb8540637 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21441,6 +21441,12 @@ S: Maintained
> F: drivers/firmware/qemu_fw_cfg.c
> F: include/uapi/linux/qemu_fw_cfg.h
>
> +QEMU VIRT MACHINE SYSTEM CONTROLLER DRIVER
> +M: Kuan-Wei Chiu <visitorckw@gmail.com>
> +L: linux-pm@vger.kernel.org
> +S: Maintained
> +F: drivers/power/reset/qemu-virt-ctrl.c
> +
> QLOGIC QL41xxx FCOE DRIVER
> M: Saurav Kashyap <skashyap@marvell.com>
> M: Javed Hasan <jhasan@marvell.com>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index f6c1bcbb57de..99e3334726a5 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -354,4 +354,14 @@ config POWER_MLXBF
> help
> This driver supports reset or low power mode handling for Mellanox BlueField.
>
> +config POWER_RESET_QEMU_VIRT_CTRL
> + tristate "QEMU Virt Machine System Controller"
> + depends on HAS_IOMEM
> + help
> + This driver supports the system reset and power off functionality
> + provided by the QEMU 'virt-ctrl' device.
> +
> + Say Y here if you are running Linux on a QEMU virtual machine that
> + provides this controller, such as the m68k virt machine.
> +
> endif
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 0e4ae6f6b5c5..d7ae97241a83 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -41,3 +41,4 @@ obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
> +obj-$(CONFIG_POWER_RESET_QEMU_VIRT_CTRL) += qemu-virt-ctrl.o
> diff --git a/drivers/power/reset/qemu-virt-ctrl.c b/drivers/power/reset/qemu-virt-ctrl.c
> new file mode 100644
> index 000000000000..f40d04afd4e3
> --- /dev/null
> +++ b/drivers/power/reset/qemu-virt-ctrl.c
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * QEMU Virt Machine System Controller Driver
> + *
> + * Copyright (C) 2026 Kuan-Wei Chiu <visitorckw@gmail.com>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/platform_device.h>
> +#include <linux/reboot.h>
> +
> +/* Registers */
> +#define VIRT_CTRL_REG_FEATURES 0x00
> +#define VIRT_CTRL_REG_CMD 0x04
> +
> +/* Commands */
> +#define CMD_NOOP 0
> +#define CMD_RESET 1
> +#define CMD_HALT 2
> +#define CMD_PANIC 3
> +
> +struct qemu_virt_ctrl {
> + void __iomem *base;
> + struct notifier_block reboot_nb;
> +};
> +
> +static inline void virt_ctrl_write32(u32 val, void __iomem *addr)
> +{
> + if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> + iowrite32be(val, addr);
> + else
> + iowrite32(val, addr);
> +}
> +
> +static int qemu_virt_ctrl_power_off(struct sys_off_data *data)
> +{
> + void __iomem *base = data->cb_data;
> +
> + virt_ctrl_write32(CMD_HALT, base + VIRT_CTRL_REG_CMD);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int qemu_virt_ctrl_restart(struct sys_off_data *data)
> +{
> + void __iomem *base = data->cb_data;
> +
> + virt_ctrl_write32(CMD_RESET, base + VIRT_CTRL_REG_CMD);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int qemu_virt_ctrl_reboot_notify(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct qemu_virt_ctrl *ctrl = container_of(nb, struct qemu_virt_ctrl, reboot_nb);
> +
> + if (action == SYS_HALT)
> + virt_ctrl_write32(CMD_HALT, ctrl->base + VIRT_CTRL_REG_CMD);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int qemu_virt_ctrl_probe(struct platform_device *pdev)
> +{
> + struct qemu_virt_ctrl *ctrl;
> + int ret;
> +
> + ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL);
> + if (!ctrl)
> + return -ENOMEM;
> +
> + ctrl->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(ctrl->base))
> + return PTR_ERR(ctrl->base);
> +
> + ret = devm_register_sys_off_handler(&pdev->dev,
> + SYS_OFF_MODE_RESTART,
> + SYS_OFF_PRIO_DEFAULT,
> + qemu_virt_ctrl_restart,
> + ctrl->base);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "cannot register restart handler\n");
> +
> + ret = devm_register_sys_off_handler(&pdev->dev,
> + SYS_OFF_MODE_POWER_OFF,
> + SYS_OFF_PRIO_DEFAULT,
> + qemu_virt_ctrl_power_off,
> + ctrl->base);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "cannot register power-off handler\n");
> +
> + ctrl->reboot_nb.notifier_call = qemu_virt_ctrl_reboot_notify;
> + ret = devm_register_reboot_notifier(&pdev->dev, &ctrl->reboot_nb);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "cannot register reboot notifier\n");
> +
> + return 0;
> +}
> +
> +static const struct platform_device_id qemu_virt_ctrl_id[] = {
> + { "qemu-virt-ctrl", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(platform, qemu_virt_ctrl_id);
> +
> +static struct platform_driver qemu_virt_ctrl_driver = {
> + .probe = qemu_virt_ctrl_probe,
> + .driver = {
> + .name = "qemu-virt-ctrl",
> + },
> + .id_table = qemu_virt_ctrl_id,
> +};
> +module_platform_driver(qemu_virt_ctrl_driver);
> +
> +MODULE_AUTHOR("Kuan-Wei Chiu <visitorckw@gmail.com>");
> +MODULE_DESCRIPTION("QEMU Virt Machine System Controller Driver");
> +MODULE_LICENSE("GPL");
> --
> 2.53.0.345.g96ddfc5eaa-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [GIT PULL] amd-pstate new content for 7.1 (2026-04-02)
From: Mario Limonciello @ 2026-04-02 20:33 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux PM
The following changes since commit c369299895a591d96745d6492d4888259b004a9e:
Linux 7.0-rc5 (2026-03-22 14:42:17 -0700)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git
tags/amd-pstate-v7.1-2026-04-02
for you to fetch changes up to 9487e2a00e7b3c6f258c5c99953f470eba6fb61d:
MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as
reviewer (2026-04-02 11:30:24 -0500)
----------------------------------------------------------------
amd-pstate new content for 7.1 (2026-04-02)
Add support for new features:
* CPPC performance priority
* Dynamic EPP
* Raw EPP
* New unit tests for new features
Fixes for:
* PREEMPT_RT
* sysfs files being present when HW missing
* Broken/outdated documentation
----------------------------------------------------------------
Gautham R. Shenoy (13):
amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init()
amd-pstate: Update cppc_req_cached in fast_switch case
amd-pstate: Make certain freq_attrs conditionally visible
x86/cpufeatures: Add AMD CPPC Performance Priority feature.
amd-pstate: Add support for CPPC_REQ2 and FLOOR_PERF
amd-pstate: Add sysfs support for floor_freq and floor_count
amd-pstate: Introduce a tracepoint trace_amd_pstate_cppc_req2()
amd-pstate-ut: Add module parameter to select testcases
amd-pstate-ut: Add a testcase to validate the visibility of
driver attributes
Documentation/amd-pstate: List amd_pstate_hw_prefcore sysfs file
Documentation/amd-pstate: List amd_pstate_prefcore_ranking sysfs file
Documentation/amd-pstate: Add documentation for
amd_pstate_floor_{freq,count}
MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as
reviewer
K Prateek Nayak (2):
cpufreq/amd-pstate: Pass the policy to amd_pstate_update()
cpufreq: Pass the policy to cpufreq_driver->adjust_perf()
Mario Limonciello (AMD) (6):
cpufreq/amd-pstate: Cache the max frequency in cpudata
cpufreq/amd-pstate: Add dynamic energy performance preference
cpufreq/amd-pstate: add kernel command line to override dynamic epp
cpufreq/amd-pstate: Add support for platform profile class
cpufreq/amd-pstate: Add support for raw EPP writes
cpufreq/amd-pstate-ut: Add a unit test for raw EPP
Ninad Naik (1):
Documentation: amd-pstate: fix dead links in the reference section
Documentation/admin-guide/kernel-parameters.txt | 7 ++
Documentation/admin-guide/pm/amd-pstate.rst | 87 ++++++++++++--
MAINTAINERS | 2 +-
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/include/asm/msr-index.h | 5 +
arch/x86/kernel/cpu/scattered.c | 1 +
drivers/cpufreq/Kconfig.x86 | 13 +++
drivers/cpufreq/amd-pstate-trace.h | 35 ++++++
drivers/cpufreq/amd-pstate-ut.c | 279
+++++++++++++++++++++++++++++++++++++++++++-
drivers/cpufreq/amd-pstate.c | 625
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
drivers/cpufreq/amd-pstate.h | 37 +++++-
drivers/cpufreq/cpufreq.c | 6 +-
drivers/cpufreq/intel_pstate.c | 4 +-
include/linux/cpufreq.h | 4 +-
kernel/sched/cpufreq_schedutil.c | 5 +-
rust/kernel/cpufreq.rs | 13 +--
tools/arch/x86/include/asm/cpufeatures.h | 2 +-
17 files changed, 1009 insertions(+), 118 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/2] Support BPF traversal of wakeup sources
From: Samuel Wu @ 2026-04-02 19:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, kernel-team,
linux-kernel, linux-pm, driver-core, bpf, linux-kselftest
In-Reply-To: <2026040236-kiln-carat-bb6d@gregkh>
On Wed, Apr 1, 2026 at 9:06 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Apr 01, 2026 at 12:07:12PM -0700, Samuel Wu wrote:
> > On Wed, Apr 1, 2026 at 2:15 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Mar 31, 2026 at 08:34:09AM -0700, Samuel Wu wrote:
> > > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > > wakeup_sources, and puts a config flag around the sysfs interface.
> > > >
> > > > Currently, a traversal of wakeup sources require going through
> > > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > > wakeup source also having multiple attributes. debugfs is unstable and
> > > > insecure.
> > >
> > > Describe "inefficient" please?
> >
> > Ack; I’ll provide a more detailed breakdown in the v4 cover letter. To
> > summarize: the "inefficiency" isn't just the number of sources (150),
> > but the fact that each source has 10 attributes. We are looking at
> > 1,500+ sysfs nodes to get a full snapshot of the system.
>
> Wait, no, something is wrong here. You should NEVER be wanting to
> combine multiple sysfs files at the same time into a "snapshot" of the
> system because by virtue of how this works, it's going to change while
> you are actually traversing all of those files!
Agree, the current approach with sysfs might have stale values. The
BPF approach holds a lock while traversing the list. It's not a
perfect snapshot, but it's internally consistent and arguably better
than the current sysfs implementation.
> Why are you trying to read 1500+ sysfs files at once, and what are you
> doing with that information? And if you really need it "all at once",
> why can't we provide it for you in a sane manner, instead of being
> forced to either walk the whole sysfs tree, or rely on a bpf script?
The data is fundamental for debugging and improving power at scale.
The original discussion and patch [1] provide more context of the
intent. To summarize the history, debugfs was unstable and insecure,
leading to the current sysfs implementation. However, sysfs has the
constraint of one attribute per node, requiring 10 sysfs accesses per
wakeup source.
That said, I completely agree that reading 1500+ sysfs files at once
is unreasonable. Perhaps the sysfs approach was manageable at the time
of [1], but moving forward we need a more scalable solution. This is
the main motivator and makes BPF the sane approach, as it improves
traversal in nearly every aspect (e.g. cycles, memory, simplicity,
scalability).
[1]: https://lore.kernel.org/all/20190715214348.81865-1-trong@android.com/
Thanks!
Sam
^ permalink raw reply
* Re: [PATCH v10 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
From: Amit Sunil Dhamne @ 2026-04-02 18:47 UTC (permalink / raw)
To: Heikki Krogerus
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Sebastian Reichel, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <ac5-OzwQkczTWtMg@kuha>
Hi Heikki,
On 4/2/26 7:33 AM, Heikki Krogerus wrote:
> Hi Amit,
>
>> +static int get_vbus_regulator_handle(struct max_tcpci_chip *chip)
>> +{
>> + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
>> + chip->vbus_reg = devm_regulator_get_exclusive(chip->dev,
>> + "vbus");
> Sorry to go back to this, but why can't you just get the regulator in
> max_tcpci_probe()?
Thanks for calling this out. This was an intentional design decision to
break a circular dependency.
The charger driver is guaranteed to probe after the TCPC driver due to a
power supply dependency (the TCPC is a supplier of power for the Battery
Charger). However, the charger driver is also the regulator provider for
VBUS out (when Type-C goes into source mode).
Because of this, the regulator handle will not be available during the
TCPC driver's probe. If we tried to fetch it in max_tcpci_probe() and
returned -EPROBE_DEFER, it would create a probe deadlock, as the charger
would then never probe. Therefore, I made the decision to get the
regulator handle lazily and on-demand.
Thanks,
Amit
>
> thanks,
>
>> + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
>> + dev_err(chip->dev,
>> + "Failed to get vbus regulator handle\n");
>> + return -ENODEV;
>> + }
>> + }
>> +
>> + return 0;
>> +}
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-04-02 18:38 UTC (permalink / raw)
To: Arnd Bergmann, Lorenzo Pieralisi
Cc: Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, André Draszik, Kathiravan Thirumoorthy,
linux-pm, linux-kernel, linux-arm-kernel, linux-arm-msm,
devicetree, Srinivas Kandagatla
In-Reply-To: <f6ed07b1-8bfc-49ea-951e-b590bf8b299a@app.fastmail.com>
On 01-04-2026 20:26, Arnd Bergmann wrote:
> On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
>> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>>
>>>>> +#include <linux/err.h>
>>>>> +#include <linux/of.h>
>>>>> +#include <linux/psci.h>
>>>>> +#include <linux/reboot.h>
>>>>> +#include <linux/reboot-mode.h>
>>>>> +#include <linux/types.h>
>>>>> +
>>>>> +/*
>>>>> + * Predefined reboot-modes are defined as per the values
>>>>> + * of enum reboot_mode defined in the kernel: reboot.c.
>>>>> + */
>>>>> +static struct mode_info psci_resets[] = {
>>>>> + { .mode = "warm", .magic = REBOOT_WARM},
>>>>> + { .mode = "soft", .magic = REBOOT_SOFT},
>>>>> + { .mode = "cold", .magic = REBOOT_COLD},
>>
>> These strings match the command userspace issue right ? I think that we
>> should make them match the corresponding PSCI reset types, the list above
>> maps command to reboot_mode values and those can belong to any reboot
>> mode driver to be honest they don't make much sense in a PSCI reboot
>> mode driver only.
>>
>> It is a question for everyone here: would it make sense to make these
>> predefined resets a set of strings, eg:
>>
>> psci-system-reset
>> psci-system-reset2-arch-warm-reset
>>
>> and then vendor resets:
>>
>> psci-system-reset2-vendor-reset
>>
>> at least we know what a string maps to ?
>>
>> We can export a function from the PSCI driver to detect whether PSCI
>> SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
>> instance that we can call from this driver to detect its presence.
>
> Sorry I've been out of the loop for this series for a while, but
> can someone refresh me on why we got back to mixing in
> the 'enum reboot_mode' from legacy i386 and arm32 into the new
> interface?
>
> I don't mind having whichever strings are defined for PSCI present
> in the user interface, but this seems like a mistake to me.
> If at all possible, lets define your own magic constants that
> are not tied to "enum reboot_mode" or the legacy reboot= command
> line argument.
sure. will remove usage of "enum reboot_mode".
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-04-02 18:35 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <ac0trUGsRBLPS+ux@lpieralisi>
On 01-04-2026 20:07, Lorenzo Pieralisi wrote:
> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>
>>
>> On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
>>>> PSCI supports different types of resets like COLD reset, ARCH WARM
[snip..]
>>>> + * Predefined reboot-modes are defined as per the values
>>>> + * of enum reboot_mode defined in the kernel: reboot.c.
>>>> + */
>>>> +static struct mode_info psci_resets[] = {
>>>> + { .mode = "warm", .magic = REBOOT_WARM},
>>>> + { .mode = "soft", .magic = REBOOT_SOFT},
>>>> + { .mode = "cold", .magic = REBOOT_COLD},
>
> These strings match the command userspace issue right ? I think that we
> should make them match the corresponding PSCI reset types, the list above
> maps command to reboot_mode values and those can belong to any reboot
> mode driver to be honest they don't make much sense in a PSCI reboot
> mode driver only.
>
> It is a question for everyone here: would it make sense to make these
> predefined resets a set of strings, eg:
>
> psci-system-reset
> psci-system-reset2-arch-warm-reset
>
> and then vendor resets:
>
> psci-system-reset2-vendor-reset
Can you share bit more details on this? We are already defining the
string from userspace in the struct - eg: ".mode = "warm".
yes we can move away from enum reboot_mode and use custom psci defines
one - Ack.
>
[snip ..]
>>>> +
>>>> +/*
>>>> + * arg1 is reset_type(Low 32 bit of magic).
>>>> + * arg2 is cookie(High 32 bit of magic).
>>>> + * If reset_type is 0, cookie will be used to decide the reset command.
>>>> + */
>>>> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
>>>> +{
>>>> + u32 reset_type = REBOOT_MODE_ARG1(magic);
>>>> + u32 cookie = REBOOT_MODE_ARG2(magic);
>>>> +
>>>> + if (reset_type == 0) {
>>>> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
>>>> + psci_set_reset_cmd(true, 0, 0);
>>>> + else
>>>> + psci_set_reset_cmd(false, 0, 0);
>>>> + } else {
>>>> + psci_set_reset_cmd(true, reset_type, cookie);
>>>> + }
>>>
>>> I don't think that psci_set_reset_cmd() has the right interface (and this
>>> nested if is too complicated for my taste). All we need to pass is reset-type
>>> and cookie (and if the reset is one of the predefined ones, reset-type is 0
>>> and cookie is the REBOOT_* cookie).
>>>
>>> Then the PSCI firmware driver will take the action according to what
>>> resets are available.
>>>
>>> How does it sound ?
>>
>> So we mean these checks will move to the psci driver? Sorry for re-iterating
>> the question.
>
> Given what I say above, I believe that something we can do is mapping the magic
> to an enum like:
>
> PSCI_SYSTEM_RESET
> PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET
> PSCI_SYSTEM_RESET2_VENDOR_RESET
>
> and can add a probe function into PSCI driver similar to psci_has_osi_support() but
> to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly,
> depending on its presence.
Not able to get it cleanly.
1. Will move away from reboot_mode enum for pre-defined modes and define
new enum defining these modes- fine.
2. get SYSTEM_RESET2 is supported from psci exported function -- fine,
but how we use it here now, as we do not want to send the reset_cmd from
psci_set_reset_cmd now?
3. For pre-defined modes, warm/soft or cold - reset_type and cookie,
both are zero, sys_reset2 or sys_reset2 decides the ARCH reset vs cold
reset.
4. For vendor-rest , we use sys_reset2 with reset_type and cookie.
All above is done in reboot_notifier call at psci-reboot-mode.
--
Now in the final restart_notifier->psci_sys_reset --
If panic is in progress, we do not use any of the cmd based reset params
and go with the legacy reset. So we need to preserve the values that
were set from psci-reboot-mode.
Did not understand the proposed suggestion in above usecase. Need more
input on this.
--
One other option is to have a restart_notifier in psci-reboot-mode, with
lesser priority than psci_sys_rest and then handle all the case
including panic and sys_reset2.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH RESEND] thermal/drivers/brcmstb_thermal: Use max to simplify brcmstb_get_temp
From: Daniel Lezcano @ 2026-04-02 17:24 UTC (permalink / raw)
To: Thorsten Blum, Markus Mayer, Broadcom internal kernel review list,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Florian Fainelli
Cc: linux-pm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260402165616.895305-3-thorsten.blum@linux.dev>
On 4/2/26 18:56, Thorsten Blum wrote:
> Use max() to simplify brcmstb_get_temp() and improve its readability.
> Since avs_tmon_code_to_temp() returns an int, change the data type of
> the local variable 't' from long to int. No functional changes.
>
> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
Applied, thanks
^ permalink raw reply
* Re: [PATCH 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Ronald Claveau @ 2026-04-02 17:00 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <5e3e8684-f893-4fb0-879e-9661820f72dd@linaro.org>
On 4/2/26 5:39 PM, Neil Armstrong wrote:
> On 4/2/26 16:27, Ronald Claveau wrote:
>> Replace the hardcoded MAX_LEVEL constant and fan register
>> with values read from platform_data (fan_reg, max_level),
>> as new MCUs need different values.
>>
>> Optionally acquire and enable a "fan" regulator supply
>> at probe time and on resume,
>> so boards that gate fan power through a regulator are handled.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> drivers/thermal/khadas_mcu_fan.c | 43 ++++++++++++++++++++++++++++++
>> ++++------
>> 1 file changed, 37 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/
>> khadas_mcu_fan.c
>> index d35e5313bea41..55b496625e3bd 100644
>> --- a/drivers/thermal/khadas_mcu_fan.c
>> +++ b/drivers/thermal/khadas_mcu_fan.c
>> @@ -13,13 +13,15 @@
>> #include <linux/regmap.h>
>> #include <linux/sysfs.h>
>> #include <linux/thermal.h>
>> -
>> -#define MAX_LEVEL 3
>> +#include <linux/regulator/consumer.h>
>> struct khadas_mcu_fan_ctx {
>> struct khadas_mcu *mcu;
>> + unsigned int fan_reg;
>> unsigned int level;
>> + unsigned int max_level;
>> struct thermal_cooling_device *cdev;
>> + struct regulator *power;
>> };
>> static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
>> @@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct
>> khadas_mcu_fan_ctx *ctx,
>> {
>> int ret;
>> - ret = regmap_write(ctx->mcu->regmap,
>> KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> - level);
>> + ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
>> if (ret)
>> return ret;
>> @@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct
>> khadas_mcu_fan_ctx *ctx,
>> static int khadas_mcu_fan_get_max_state(struct
>> thermal_cooling_device *cdev,
>> unsigned long *state)
>> {
>> - *state = MAX_LEVEL;
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + *state = ctx->max_level;
>> return 0;
>> }
>> @@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct
>> thermal_cooling_device *cdev,
>> {
>> struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> - if (state > MAX_LEVEL)
>> + if (state > ctx->max_level)
>> return -EINVAL;
>> if (state == ctx->level)
>> @@ -83,11 +86,32 @@ static int khadas_mcu_fan_probe(struct
>> platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> struct khadas_mcu_fan_ctx *ctx;
>> int ret;
>> + const struct khadas_mcu_fan_pdata *pdata =
>> dev_get_platdata(&pdev->dev);
>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> if (!ctx)
>> return -ENOMEM;
>> +
>> ctx->mcu = mcu;
>> + ctx->fan_reg = pdata->fan_reg;
>> + ctx->max_level = pdata->max_level;
>> +
>> + ctx->power = devm_regulator_get_optional(dev->parent, "fan");
>> + if (IS_ERR(ctx->power)) {
>> + if (PTR_ERR(ctx->power) == -ENODEV)
>> + ctx->power = NULL;
>> + else
>> + return PTR_ERR(ctx->power);
>> + }
>> +
>> + if (ctx->power) {
>> + ret = regulator_enable(ctx->power);
>> + if (ret) {
>> + dev_err(dev, "Failed to enable fan power supply: %d\n",
>> ret);
>> + return ret;
>> + }
>> + }
>> +
>> platform_set_drvdata(pdev, ctx);
>> cdev = devm_thermal_of_cooling_device_register(dev->parent,
>> @@ -130,6 +154,13 @@ static int khadas_mcu_fan_suspend(struct device
>> *dev)
>> static int khadas_mcu_fan_resume(struct device *dev)
>> {
>> struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + if (ctx->power) {
>> + ret = regulator_enable(ctx->power);
>
> Seems you're missing a regulator_disable() on suspend.
>
> Neil
>
You right, I will add the regulator_disable on suspend for next version.
Thanks for your feedback.
>> + if (ret)
>> + return ret;
>> + }
>> return khadas_mcu_fan_set_level(ctx, ctx->level);
>> }
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH] power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
From: Arnd Bergmann @ 2026-04-02 16:58 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Arnd Bergmann, Manivannan Sadhasivam, Ulf Hansson,
Michal Wilczynski, linux-pm, linux-kernel
In-Reply-To: <CAMRc=MfHsKk7zb6E7MC2WT-dANQrnC7B2eX1dJb=__2=NnEGRg@mail.gmail.com>
On Thu, Apr 2, 2026, at 18:36, Bartosz Golaszewski wrote:
> On Thu, Apr 2, 2026 at 5:42 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> Mani's patch adds stubs for the symbols that the linker couldn't find
> in the build error you posted above. I thought this would fix the
> issue?
No, when you have POWER_SEQUENCING_PCIE_M2=y and
CONFIG_SERIAL_DEV_BUS=m, you still get the same build failure.
Arnd
^ permalink raw reply
* [PATCH RESEND] thermal/drivers/brcmstb_thermal: Use max to simplify brcmstb_get_temp
From: Thorsten Blum @ 2026-04-02 16:56 UTC (permalink / raw)
To: Markus Mayer, Broadcom internal kernel review list,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Florian Fainelli
Cc: Thorsten Blum, linux-pm, linux-arm-kernel, linux-kernel
Use max() to simplify brcmstb_get_temp() and improve its readability.
Since avs_tmon_code_to_temp() returns an int, change the data type of
the local variable 't' from long to int. No functional changes.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/thermal/broadcom/brcmstb_thermal.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c b/drivers/thermal/broadcom/brcmstb_thermal.c
index f46f2ddc174e..a9ffa596f7c0 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -16,6 +16,7 @@
#include <linux/irqreturn.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/minmax.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -154,7 +155,7 @@ static int brcmstb_get_temp(struct thermal_zone_device *tz, int *temp)
{
struct brcmstb_thermal_priv *priv = thermal_zone_device_priv(tz);
u32 val;
- long t;
+ int t;
val = __raw_readl(priv->tmon_base + AVS_TMON_STATUS);
@@ -164,10 +165,7 @@ static int brcmstb_get_temp(struct thermal_zone_device *tz, int *temp)
val = (val & AVS_TMON_STATUS_data_msk) >> AVS_TMON_STATUS_data_shift;
t = avs_tmon_code_to_temp(priv, val);
- if (t < 0)
- *temp = 0;
- else
- *temp = t;
+ *temp = max(0, t);
return 0;
}
^ permalink raw reply related
* Re: [PATCH] power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
From: Bartosz Golaszewski @ 2026-04-02 16:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Manivannan Sadhasivam, Ulf Hansson,
Michal Wilczynski, linux-pm, linux-kernel
In-Reply-To: <f402c8e8-cc71-4263-a51a-368a8a0e018f@app.fastmail.com>
On Thu, Apr 2, 2026 at 5:42 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Apr 2, 2026, at 17:38, Bartosz Golaszewski wrote:
> > On Wed, Apr 1, 2026 at 9:10 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >> diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
> >> index 77c6d9227251..1c5f5820f5b7 100644
> >> --- a/drivers/power/sequencing/Kconfig
> >> +++ b/drivers/power/sequencing/Kconfig
> >> @@ -39,6 +39,7 @@ config POWER_SEQUENCING_PCIE_M2
> >> tristate "PCIe M.2 connector power sequencing driver"
> >> depends on OF
> >> depends on PCI
> >> + depends on SERIAL_DEV_BUS
> >> select OF_DYNAMIC
> >> help
> >> Say Y here to enable the power sequencing driver for PCIe M.2
> >> --
> >> 2.39.5
> >>
> >
> > I assume with this patch[1] from Mani, we no longer need this one?
> >
> > [1]
> > https://lore.kernel.org/all/20260401070735.107162-2-manivannan.sadhasivam@oss.qualcomm.com/
>
> Depends on which one you mean with 'this one'.
>
> My patch is needed with or without Mani's, while
> his patch is harmless but does not fix the issue.
>
> Arnd
Mani's patch adds stubs for the symbols that the linker couldn't find
in the build error you posted above. I thought this would fix the
issue?
Bart
^ permalink raw reply
* [PATCH v2] cpupower: remove extern declarations in cmd functions
From: Kaushlendra Kumar @ 2026-04-02 16:15 UTC (permalink / raw)
To: shuah, jwyatt, jkacur; +Cc: linux-pm, Kaushlendra Kumar
extern char *optarg and extern int optind, opterr, optopt are
already declared by <getopt.h>, which is included at the top of
the file. Repeating extern declarations inside a function body
is misleading and unnecessary.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
---
v2: Extended the fix to all cmd functions across cpupower utils
tools/power/cpupower/utils/cpufreq-info.c | 2 --
tools/power/cpupower/utils/cpufreq-set.c | 2 --
tools/power/cpupower/utils/cpuidle-info.c | 2 --
tools/power/cpupower/utils/cpuidle-set.c | 2 --
tools/power/cpupower/utils/cpupower-info.c | 2 --
tools/power/cpupower/utils/cpupower-set.c | 2 --
6 files changed, 12 deletions(-)
diff --git a/tools/power/cpupower/utils/cpufreq-info.c b/tools/power/cpupower/utils/cpufreq-info.c
index 5fe01e516817..5a242b491a9d 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -542,8 +542,6 @@ static struct option info_opts[] = {
int cmd_freq_info(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
int ret = 0, cont = 1;
unsigned int cpu = 0;
unsigned int human = 0;
diff --git a/tools/power/cpupower/utils/cpufreq-set.c b/tools/power/cpupower/utils/cpufreq-set.c
index c5e60a39cfa6..06cd4b280132 100644
--- a/tools/power/cpupower/utils/cpufreq-set.c
+++ b/tools/power/cpupower/utils/cpufreq-set.c
@@ -195,8 +195,6 @@ static int do_one_cpu(unsigned int cpu, struct cpufreq_policy *new_pol,
int cmd_freq_set(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
int ret = 0, cont = 1;
int double_parm = 0, related = 0, policychange = 0;
unsigned long freq = 0;
diff --git a/tools/power/cpupower/utils/cpuidle-info.c b/tools/power/cpupower/utils/cpuidle-info.c
index 81b4763a97d6..ccb37125bd37 100644
--- a/tools/power/cpupower/utils/cpuidle-info.c
+++ b/tools/power/cpupower/utils/cpuidle-info.c
@@ -139,8 +139,6 @@ static inline void cpuidle_exit(int fail)
int cmd_idle_info(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
int ret = 0, cont = 1, output_param = 0, verbose = 1;
unsigned int cpu = 0;
diff --git a/tools/power/cpupower/utils/cpuidle-set.c b/tools/power/cpupower/utils/cpuidle-set.c
index a551d1d4ac51..703094f1343c 100644
--- a/tools/power/cpupower/utils/cpuidle-set.c
+++ b/tools/power/cpupower/utils/cpuidle-set.c
@@ -24,8 +24,6 @@ static struct option info_opts[] = {
int cmd_idle_set(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
int ret = 0, cont = 1, param = 0, disabled;
unsigned long long latency = 0, state_latency;
unsigned int cpu = 0, idlestate = 0, idlestates = 0;
diff --git a/tools/power/cpupower/utils/cpupower-info.c b/tools/power/cpupower/utils/cpupower-info.c
index 18fd7751f509..79154d71e498 100644
--- a/tools/power/cpupower/utils/cpupower-info.c
+++ b/tools/power/cpupower/utils/cpupower-info.c
@@ -28,8 +28,6 @@ static void print_wrong_arg_exit(void)
int cmd_info(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
unsigned int cpu;
struct utsname uts;
diff --git a/tools/power/cpupower/utils/cpupower-set.c b/tools/power/cpupower/utils/cpupower-set.c
index 550a942e72ce..c2176b9fa57d 100644
--- a/tools/power/cpupower/utils/cpupower-set.c
+++ b/tools/power/cpupower/utils/cpupower-set.c
@@ -33,8 +33,6 @@ static void print_wrong_arg_exit(void)
int cmd_set(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
unsigned int cpu;
struct utsname uts;
--
2.34.1
^ permalink raw reply related
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