Date   

FW: KernelCI plans for 2020-Q3

Chris Paterson
 

FYI

Kind regards, Chris

From: kernelci@groups.io <kernelci@groups.io> On Behalf Of Guillaume
Tucker via groups.io
Sent: 16 June 2020 07:41

As you probably all know, the Linux Plumbers Conference (LPC) is
going to be KernelCI's next milestone, at the end of August.
While it's not entirely clear yet which online format it will
adopt and whether we'll be able to discuss all the things as we
would normally do face-to-face, it is still a key moment for
KernelCI and the kernel community.

A lot of progress has been made in KernelCI over the past months.
Like with any project, some things still need to be completed and
others haven't even started yet. In order to focus our efforts
and be in a strong position by LPC, we have outlined our plans in
this shared document:


https://docs.google.com/document/d/1KCIv6L3XrsNFIu4GzFMTV7Qx6Jlm2tr
c-bvRIbDEVV8/edit#


And like with any community project, nobody really has any
control over the actual course of events. But it helps to have
some guidelines and agree on what the priorities should be.
That's what the plan document is here for.


There is also a new GitHub project board for 2020-Q3, for the
tasks that fit in this format:

https://github.com/orgs/kernelci/projects/2


There's some exciting work ahead of us, and several opportunities
to grow the project with new contributors. I'm sure we'll have
to overcome some challenges but there's every reason to be
optimistic. We've come a long way already!


This is of course all open for comments and questions, please
feel free to reply on this thread or on the shared document.


Thanks,
Guillaume


Re: Share your suggestions for supporting session lock requirement in CIP

Jan Kiszka
 

On 16.06.20 09:00, Dinesh Kumar wrote:
Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar


-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: 15 June 2020 12:52
To: cip-dev@lists.cip-project.org; Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
Cc: cip-security@lists.cip-project.org
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.
But that mode is documented in systemd manuals - without any note that
it's in fact off? Something does not match here yet. At least, it would
be a documentation bug, but maybe also a chance to enhance the code and
sell it upstream.


2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.
OK. Still confused, though, because there is no mentioning of that
somewhere. Unless I miss that. Is there any Debian bug? Or even an
systemd issue?


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.
OK, so this is about adding dbus to our package set - not unrealistic.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?
Yes, this needs to be be clarified. Otherwise, we cannot decide how to
move on.


It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.
If there is an integration issue with systemd + vlock/physlock under
Debian, it may also be an option to open an ticket there so that Debian
maintainers call push it or provide further input.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: Share your suggestions for supporting session lock requirement in CIP

Dinesh Kumar
 

Hi Jan,

Thanks for your review comments.
Kindly refer my response and let me know your opinion.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: 15 June 2020 12:52
To: cip-dev@lists.cip-project.org; Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
Cc: cip-security@lists.cip-project.org
Subject: Re: [cip-dev] Share your suggestions for supporting session lock requirement in CIP

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?
Dinesh>>Yes, we can do that by using TMOUT. However, we were just trying if we can achieve session lock with some existing packages or minimal changes in CIP. But that does not seem to happen.
Our idea of sharing this detail here was if anyone can suggest achieving session lock with some Debian packages without any modifications in the packages.
TMOUT is our backup option.

CR2.6 Req-2 Remote session termination: Component should support
terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?
Dinesh>>Since idle_action=lock is disabled in current systemd code. We enabled with changes described in this email. Though it works but we are not sure about side effects.

2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?
Dinesh>>It's sufficient but disabled.

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?
Dinesh>>We quickly checked physlock, it's better alternate to vlock. But first we have to decide systemd changes, since vlock or physlock only work if systemd code changes are enabled.


4. Enable dbus in systemd
What do you mean by that?
Dinesh>>Sorry for confusing you. I meant dbus is an optional dependency of systemd package which is required to be enabled in CIP if we want to achieve session lock with systemd.


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int
manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >=
m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action,
+ false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature to systemd so that it may become configurable (avoid the patch)? Or is it even a generic feature that everyone wants?
Dinesh>>This code simply enables idle_action=lock. I am not sure why they have kept it disabled. Should we post this change in upstream and ask them whether it can be made configurable?

It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it to the component that can implement it best. Once accepted, we can still look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing tools do not fulfill the requirements. And which tools or methods you examined already.
Dinesh>>Thanks for your inputs.
We have raised our query in systemd ML to know why lock action is disabled but no one has responded so far.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


Re: Share your suggestions for supporting session lock requirement in CIP

Jan Kiszka
 

Hi Dinesh,

On 10.06.20 15:02, Dinesh Kumar wrote:
Hi All,

IEC-62443-4-2 has following two requirements related to session termination and session lock.
CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.
Why not simply enforce log out also for local (terminal) sessions?

CR2.6 Req-2 Remote session termination: Component should support terminating remote session after a configurable time of inactivity

CR2.6 Req-2 can be met by adding system variable TMOUT.

For meeting CR2.5 we need following changes in CIP.

1. Systemd code changes
Why?

2. Add deamon which subscribes to dbus notification(sample code attached)
Why is IdleAction=lock in logind.conf insufficient?

3. Add vlock Debian package which performs session lock
What is still missing after configuring this package?

And what about physlock?


4. Enable dbus in systemd
What do you mean by that?


Systemd code change are as follows.


--- a/src/login/logind.c

+++ b/src/login/logind.c

@@ -1019,7 +1019,7 @@ static int manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us

(m->idle_action_not_before_usec <= 0 || n >= m->idle_action_not_before_usec + m->idle_action_usec)) {

log_info("System idle. Taking action.");



- manager_handle_action(m, 0, m->idle_action, false, false);

+ manager_handle_action(m, 0, m->idle_action, false, true);

m->idle_action_not_before_usec = n;

}
What is the semantic of this code change? Can this be sold as a feature
to systemd so that it may become configurable (avoid the patch)? Or is
it even a generic feature that everyone wants?

It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.
Always think upstream first: Describe your feature clearly and sell it
to the component that can implement it best. Once accepted, we can still
look into how to bridge the time best until it hits a Debian release.

So, please describe the problem technically, including why existing
tools do not fulfill the requirements. And which tools or methods you
examined already.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


[ANNOUNCE] Release v4.19.128-cip28 and v4.4.227-cip46

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.128-cip28 and v4.4.227-cip46.
The linux-4.19.y-cip tree has been updated base version from v4.19.124
to v4.19.128, and The linux-4.4.y-cip tree has been updated base version from
v4.4.222 to v4.4.227.
In addition, the linux-4.4.y-cip tree added support for MoxaUC-8100-ME-T, LCD support
for iwg20d-q7, and PM/OOP functionality for TI ARM SoC am33xx,

You can get this release via the git tree at:

v4.19.128-cip28:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
775b010f64a43fe825f22c8784b6589ac4295956
added commits:
CIP: Bump version suffix to -cip28 after merge from stable

v4.4.227-cip46:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
e65152cafde5d1f6db9b8e6e8a65fed2b19ea91d
added commits:
CIP: Bump version suffix to -cip46 after merge from stable
cpufreq: cpufreq-dt: avoid uninitialized variable warnings:
cpufreq-dt: fix handling regulator_get_voltage() result
cpufreq-dt: Supply power coefficient when registering cooling devices
devicetree: bindings: Add optional dynamic-power-coefficient property
PM / OPP: Use snprintf() instead of sprintf()
PM / OPP: Set cpu_dev->id in cpumask first
PM / OPP: Parse 'opp-<prop>-<name>' bindings
PM / OPP: Parse 'opp-supported-hw' binding
PM / OPP: Add missing doc comments
PM / OPP: Rename OPP nodes as opp@<opp-hz>
PM / OPP: Remove 'operating-points-names' binding
PM / OPP: Add {opp-microvolt|opp-microamp}-<name> binding
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add debugfs support
ARM: dts: am335x: moxa-uc-8100-me-t: Replaced register offsets with defines
ARM: dts: am33xx: Added AM33XX_PADCONF macro
ARM: dts: am33xx: Added macros for numeric pinmux addresses
ARM: dts: am335x: add support for Moxa UC-8100-ME-T open platform
ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
ARM: dts: iwg20d-q7-common: Add LCD support

Best regards,
Nobuhiro
u


Re: CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Pavel-san,

I'll go through the IRC logs.
The log is the following.
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-11-09.00.log.html

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Pavel Machek
Sent: Thursday, June 11, 2020 8:24 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] CIP IRC weekly meeting today

Hi!


Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I'm sorry I missed the meeting. I'll go through the IRC logs.

My activity last week: reviews on 4.19.127 and patches queued for 4.19.128.

Best regards,
Pavel


Re: CIP IRC weekly meeting today

Pavel Machek
 

Hi!


Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I'm sorry I missed the meeting. I'll go through the IRC logs.

My activity last week: reviews on 4.19.127 and patches queued for 4.19.128.

Best regards,
Pavel


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=6&day=11&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-04-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
3. Upload a guideline for reference hardware platform addition - masashi910
4. Post LTP results to KernelCI - patersonc
5. Ask board owners to review reference platform configs to optimize backporting - masashi910
6. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Share your suggestions for supporting session lock requirement in CIP

Dinesh Kumar
 

Hi All,

 

IEC-62443-4-2 has following two requirements related to session termination and session lock.

CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.

CR2.6 Req-2 Remote session termination: Component should support terminating remote session after a configurable time of inactivity

 

CR2.6 Req-2 can be met by adding system variable TMOUT.

 

For meeting CR2.5 we need following changes in CIP.

1.       Systemd code changes

2.       Add deamon which subscribes to dbus notification(sample code attached)

3.       Add vlock Debian package which performs session lock

4.       Enable dbus in systemd

 

Systemd code change are as follows.

 

--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -1019,7 +1019,7 @@ static int manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us
                     (m->idle_action_not_before_usec <= 0 || n >= m->idle_action_not_before_usec + m->idle_action_usec)) {
                         log_info("System idle. Taking action.");
 
-                        manager_handle_action(m, 0, m->idle_action, false, false);
+                        manager_handle_action(m, 0, m->idle_action, false, true);
                         m->idle_action_not_before_usec = n;
                 }

 

It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

 

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.

 

Thanks & Regards,

Dinesh Kumar

 

.


Re: isar-cip-core and cip-kernel-config

Daniel Sangorrin
 

Good to know Jan, thanks for the update.

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Tuesday, June 9, 2020 7:01 PM
To: cip-dev <cip-dev@lists.cip-project.org>
Subject: [cip-dev] isar-cip-core and cip-kernel-config

Hi all,

a quick follow-up from our cip-core meeting today:

isar-cip-core is already able to pull configs from cip-kernel-config. It
does so for all machines where USE_CIP_KERNEL_CONFIG = "1", ie.
hihope-rzg2m, iwg20m and simatic-ipc227e. So we "only" need to check the
other targets and see how they can be migrated.

And we should remove the old defconfigs from isar-cip-core then (some
could already go).

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH 4.4.y-cip v3 00/14] PM / OPP v2 & cpufreq backports part 1

Pavel Machek
 

Hi!

This is v3 of the part 1 of MOXA's PM / OPP / cpufreq backport series.
Changes since v2:

- Squashed "PM / OPP: Fix parsing of opp-microvolt and opp-microamp
properties" into "PM / OPP: Parse 'opp-<prop>-<name>' bindings"

Changes since v1:

- Added missing SoB and upstream commit hash for "PM / OPP: Set
cpu_dev->id in cpumask first"
Thanks! I have applied the series, will run some basic tests and push
the results if they work okay.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.4.y-cip 0/3] ARM: dts: am335x: Replace numeric pinmux address with macro defines

Pavel Machek
 

Hi!

On the other hand, I don't see any obvious benefit. Whether we use hex
constants or symbolic constants affects readability, but has no effect on
functionality.

Do you have any patches on top of these that rely on symbolic constants in the
dts? Are there any changes in the generated .dtb?
What is the benefit of this series (besides cleanup)?
Thanks for your response!

If macros of numeric pinmux addresses is used, we don't need to see AM335X's Technical Reference Manual again and again to find out the meaning of each pinmux address, just check "am33xx.h". Besides, it helps us to configure module pin's for different device trees easily. For example of mii, If we want to configure module of mii pin, we check module in "am33xx.h" can pick register names we want to modify. It's hard to remember pin address number for the specific module to us.

If AM33XX_PADCONF is taken, we can make sure both of pin's direction and mux mode are actually set, and it helps us to debug.

We have many boards based on AM335x SoC. Some dts rely on symbolic constants and some dts are not. I think this patch series can let us develop boards with AM335x SoC easiler.
Aha, ok, having more boards like this certainly explains the
benefits. Thanks for an explanation.

I have applied patches, I'll run some basic tests and push the
results.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


isar-cip-core and cip-kernel-config

Jan Kiszka
 

Hi all,

a quick follow-up from our cip-core meeting today:

isar-cip-core is already able to pull configs from cip-kernel-config. It
does so for all machines where USE_CIP_KERNEL_CONFIG = "1", ie.
hihope-rzg2m, iwg20m and simatic-ipc227e. So we "only" need to check the
other targets and see how they can be migrated.

And we should remove the old defconfigs from isar-cip-core then (some
could already go).

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


[PATCH 4.4.y-cip v3 13/14] cpufreq-dt: fix handling regulator_get_voltage() result

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Andrzej Hajda <a.hajda@samsung.com>

commit 929ca89c305a6ed7a4149115be99af6d73c36918 upstream.

The function can return negative values so it should be assigned
to signed type.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci.

Link: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/cpufreq/cpufreq-dt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 1ceece9d67112..9bc37c437874a 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -50,7 +50,8 @@ static int set_target(struct cpufreq_policy *policy, un=
signed int index)
struct private_data *priv =3D policy->driver_data;
struct device *cpu_dev =3D priv->cpu_dev;
struct regulator *cpu_reg =3D priv->cpu_reg;
- unsigned long volt =3D 0, volt_old =3D 0, tol =3D 0;
+ unsigned long volt =3D 0, tol =3D 0;
+ int volt_old =3D 0;
unsigned int old_freq, new_freq;
long freq_Hz, freq_exact;
int ret;
@@ -83,7 +84,7 @@ static int set_target(struct cpufreq_policy *policy, un=
signed int index)
opp_freq / 1000, volt);
}
=20
- dev_dbg(cpu_dev, "%u MHz, %ld mV --> %u MHz, %ld mV\n",
+ dev_dbg(cpu_dev, "%u MHz, %d mV --> %u MHz, %ld mV\n",
old_freq / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
new_freq / 1000, volt ? volt / 1000 : -1);
=20
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 10/14] PM / OPP: Use snprintf() instead of sprintf()

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 5ff24d601092b222340b28466e263b1c4559407e upstream.

sprintf() can access memory outside of the range of the character array,
and is risky in some situations. The driver specified prop_name string
can be longer than NAME_MAX here (only an attacker will do that though)
and so blindly copying it into the character array of size NAME_MAX
isn't safe. Instead we must use snprintf() here.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 504a6d4e46723..1e0a2ddf73323 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -808,7 +808,8 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
=20
/* Search for "opp-microvolt-<name>" */
if (dev_opp->prop_name) {
- sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ snprintf(name, sizeof(name), "opp-microvolt-%s",
+ dev_opp->prop_name);
prop =3D of_find_property(opp->np, name, NULL);
}
=20
@@ -855,7 +856,8 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
/* Search for "opp-microamp-<name>" */
prop =3D NULL;
if (dev_opp->prop_name) {
- sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
+ snprintf(name, sizeof(name), "opp-microamp-%s",
+ dev_opp->prop_name);
prop =3D of_find_property(opp->np, name, NULL);
}
=20
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 11/14] devicetree: bindings: Add optional dynamic-power-coefficient property

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Punit Agrawal <punit.agrawal@arm.com>

commit 3be3f8f36e7349006f19c8c8f0d686e98462a993 upstream.

The dynamic power consumption of a device is proportional to the
square of voltage (V) and the clock frequency (f). It can be expressed as

Pdyn =3D dynamic-power-coefficient * V^2 * f.

The coefficient represents the running time dynamic power consumption in
units of mw/MHz/uVolt^2 and can be used in the above formula to
calculate the dynamic power in mW.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
Documentation/devicetree/bindings/arm/cpus.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentati=
on/devicetree/bindings/arm/cpus.txt
index 9ef9a2089a5e7..6b1d8ebb94b7b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -243,6 +243,23 @@ nodes to be present and contain the properties descr=
ibed below.
Definition: Specifies the syscon node controlling the cpu core
power domains.
=20
+ - dynamic-power-coefficient
+ Usage: optional
+ Value type: <prop-encoded-array>
+ Definition: A u32 value that represents the running time dynamic
+ power coefficient in units of mW/MHz/uVolt^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the CPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn =3D dynamic-power-coefficient * V^2 * f
+
+ where voltage is in uV, frequency is in MHz.
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
=20
cpus {
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 14/14] cpufreq: cpufreq-dt: avoid uninitialized variable warnings:

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Arnd Bergmann <arnd@arndb.de>

commit b331bc20d9281213f7fb67912638e0fb5baeb324 upstream.

gcc warns quite a bit about values returned from allocate_resources()
in cpufreq-dt.c:

cpufreq-dt.c: In function 'cpufreq_init':
cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
cpufreq-dt.c: In function 'dt_cpufreq_probe':
cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here

The problem is that it's slightly hard for gcc to follow return
codes across PTR_ERR() calls.

This patch uses explicit assignments to the "ret" variable to make
it easier for gcc to verify that the code is actually correct,
without the need to add a bogus initialization.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/cpufreq/cpufreq-dt.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 9bc37c437874a..0ca74d0700583 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -142,15 +142,16 @@ static int allocate_resources(int cpu, struct devic=
e **cdev,
=20
try_again:
cpu_reg =3D regulator_get_optional(cpu_dev, reg);
- if (IS_ERR(cpu_reg)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_reg);
+ if (ret) {
/*
* If cpu's regulator supply node is present, but regulator is
* not yet registered, we should try defering probe.
*/
- if (PTR_ERR(cpu_reg) =3D=3D -EPROBE_DEFER) {
+ if (ret =3D=3D -EPROBE_DEFER) {
dev_dbg(cpu_dev, "cpu%d regulator not ready, retry\n",
cpu);
- return -EPROBE_DEFER;
+ return ret;
}
=20
/* Try with "cpu-supply" */
@@ -159,18 +160,16 @@ try_again:
goto try_again;
}
=20
- dev_dbg(cpu_dev, "no regulator for cpu%d: %ld\n",
- cpu, PTR_ERR(cpu_reg));
+ dev_dbg(cpu_dev, "no regulator for cpu%d: %d\n", cpu, ret);
}
=20
cpu_clk =3D clk_get(cpu_dev, NULL);
- if (IS_ERR(cpu_clk)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_clk);
+ if (ret) {
/* put regulator */
if (!IS_ERR(cpu_reg))
regulator_put(cpu_reg);
=20
- ret =3D PTR_ERR(cpu_clk);
-
/*
* If cpu's clk node is present, but clock is not yet
* registered, we should try defering probe.
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 12/14] cpufreq-dt: Supply power coefficient when registering cooling devices

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Punit Agrawal <punit.agrawal@arm.com>

commit f8fa8ae06b8c2c25d81c99766f9226adc5c3e073 upstream.

Support registering cooling devices with dynamic power coefficient
where provided by the device tree. This allows OF registered cooling
devices driver to be used with the power_allocator thermal governor.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/cpufreq/cpufreq-dt.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 90d64081ddb34..1ceece9d67112 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -407,8 +407,13 @@ static void cpufreq_ready(struct cpufreq_policy *pol=
icy)
* thermal DT code takes care of matching them.
*/
if (of_find_property(np, "#cooling-cells", NULL)) {
- priv->cdev =3D of_cpufreq_cooling_register(np,
- policy->related_cpus);
+ u32 power_coefficient =3D 0;
+
+ of_property_read_u32(np, "dynamic-power-coefficient",
+ &power_coefficient);
+
+ priv->cdev =3D of_cpufreq_power_cooling_register(np,
+ policy->related_cpus, power_coefficient, NULL);
if (IS_ERR(priv->cdev)) {
dev_err(priv->cpu_dev,
"running cpufreq without cooling device: %ld\n",
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 09/14] PM / OPP: Set cpu_dev->id in cpumask first

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Pi-Cheng Chen <pi-cheng.chen@linaro.org>

commit d9de19b1cc013433ad293365b5b3902ec73dfd60 upstream.

Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that
share the same OPP table. This might be helpful when handling cpumask
without the original CPU bitfield set.

Signed-off-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 1a2e8f260b060..a0db8b3575f38 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -218,7 +218,6 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table);
/*
* Works only for OPP v2 bindings.
*
- * cpumask should be already set to mask of cpu_dev->id.
* Returns -ENOENT if operating-points-v2 bindings aren't supported.
*/
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t=
cpumask)
@@ -234,6 +233,8 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu=
_dev, cpumask_var_t cpumask
return -ENOENT;
}
=20
+ cpumask_set_cpu(cpu_dev->id, cpumask);
+
/* OPPs are shared ? */
if (!of_property_read_bool(np, "opp-shared"))
goto put_cpu_node;
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 08/14] PM / OPP: Parse 'opp-<prop>-<name>' bindings

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 01fb4d3c39d35b725441e8a9a26b3f3ad67793ed upstream.
commit fd8d8e63467c922be9ae4452cca2980d473477d9 upstream squashed in.

OPP bindings (for few properties) allow a platform to choose a
value/range among a set of available options. The options are present as
opp-<prop>-<name>, where the platform needs to supply the <name> string.

The OPP properties which allow such an option are: opp-microvolt and
opp-microamp.

Add support to the OPP-core to parse these bindings, by introducing
dev_pm_opp_{set|put}_prop_name() APIs.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[wens: Squashed in Bartlomiej Zolnierkiewicz's <b.zolnierkie@samsung.com>
upstream commit fd8d8e63467c922be9ae4452cca2980d473477d9 to fix a =
bug]
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 165 ++++++++++++++++++++++++++++++----
drivers/base/power/opp/opp.h | 2 +
include/linux/pm_opp.h | 9 ++
3 files changed, 161 insertions(+), 15 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index a73433c3cbe45..504a6d4e46723 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -562,6 +562,9 @@ static void _remove_device_opp(struct device_opp *dev=
_opp)
if (dev_opp->supported_hw)
return;
=20
+ if (dev_opp->prop_name)
+ return;
+
list_dev =3D list_first_entry(&dev_opp->dev_list, struct device_list_op=
p,
node);
=20
@@ -794,35 +797,48 @@ unlock:
}
=20
/* TODO: Support multiple regulators */
-static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev=
)
+static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev=
,
+ struct device_opp *dev_opp)
{
u32 microvolt[3] =3D {0};
u32 val;
int count, ret;
+ struct property *prop =3D NULL;
+ char name[NAME_MAX];
+
+ /* Search for "opp-microvolt-<name>" */
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microvolt" */
+ sprintf(name, "opp-microvolt");
+ prop =3D of_find_property(opp->np, name, NULL);
=20
- /* Missing property isn't a problem, but an invalid entry is */
- if (!of_find_property(opp->np, "opp-microvolt", NULL))
- return 0;
+ /* Missing property isn't a problem, but an invalid entry is */
+ if (!prop)
+ return 0;
+ }
=20
- count =3D of_property_count_u32_elems(opp->np, "opp-microvolt");
+ count =3D of_property_count_u32_elems(opp->np, name);
if (count < 0) {
- dev_err(dev, "%s: Invalid opp-microvolt property (%d)\n",
- __func__, count);
+ dev_err(dev, "%s: Invalid %s property (%d)\n",
+ __func__, name, count);
return count;
}
=20
/* There can be one or three elements here */
if (count !=3D 1 && count !=3D 3) {
- dev_err(dev, "%s: Invalid number of elements in opp-microvolt property=
(%d)\n",
- __func__, count);
+ dev_err(dev, "%s: Invalid number of elements in %s property (%d)\n",
+ __func__, name, count);
return -EINVAL;
}
=20
- ret =3D of_property_read_u32_array(opp->np, "opp-microvolt", microvolt,
- count);
+ ret =3D of_property_read_u32_array(opp->np, name, microvolt, count);
if (ret) {
- dev_err(dev, "%s: error parsing opp-microvolt: %d\n", __func__,
- ret);
+ dev_err(dev, "%s: error parsing %s: %d\n", __func__, name, ret);
return -EINVAL;
}
=20
@@ -836,7 +852,20 @@ static int opp_parse_supplies(struct dev_pm_opp *opp=
, struct device *dev)
opp->u_volt_max =3D microvolt[2];
}
=20
- if (!of_property_read_u32(opp->np, "opp-microamp", &val))
+ /* Search for "opp-microamp-<name>" */
+ prop =3D NULL;
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microamp" */
+ sprintf(name, "opp-microamp");
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (prop && !of_property_read_u32(opp->np, name, &val))
opp->u_amp =3D val;
=20
return 0;
@@ -954,6 +983,112 @@ unlock:
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_supported_hw);
=20
+/**
+ * dev_pm_opp_set_prop_name() - Set prop-extn name
+ * @dev: Device for which the regulator has to be set.
+ * @name: name to postfix to properties.
+ *
+ * This is required only for the V2 bindings, and it enables a platform =
to
+ * specify the extn to be used for certain property names. The propertie=
s to
+ * which the extension will apply are opp-microvolt and opp-microamp. OP=
P core
+ * should postfix the property name with -<name> while looking for them.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_set_prop_name(struct device *dev, const char *name)
+{
+ struct device_opp *dev_opp;
+ int ret =3D 0;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ dev_opp =3D _add_device_opp(dev);
+ if (!dev_opp) {
+ ret =3D -ENOMEM;
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ /* Do we already have a prop-name associated with dev_opp? */
+ if (dev_opp->prop_name) {
+ dev_err(dev, "%s: Already have prop-name %s\n", __func__,
+ dev_opp->prop_name);
+ ret =3D -EBUSY;
+ goto err;
+ }
+
+ dev_opp->prop_name =3D kstrdup(name, GFP_KERNEL);
+ if (!dev_opp->prop_name) {
+ ret =3D -ENOMEM;
+ goto err;
+ }
+
+ mutex_unlock(&dev_opp_list_lock);
+ return 0;
+
+err:
+ _remove_device_opp(dev_opp);
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_set_prop_name);
+
+/**
+ * dev_pm_opp_put_prop_name() - Releases resources blocked for prop-name
+ * @dev: Device for which the regulator has to be set.
+ *
+ * This is required only for the V2 bindings, and is called for a matchi=
ng
+ * dev_pm_opp_set_prop_name(). Until this is called, the device_opp stru=
cture
+ * will not be freed.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+void dev_pm_opp_put_prop_name(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ /* Check for existing list for 'dev' first */
+ dev_opp =3D _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_err(dev, "Failed to find dev_opp: %ld\n", PTR_ERR(dev_opp));
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ if (!dev_opp->prop_name) {
+ dev_err(dev, "%s: Doesn't have a prop-name\n", __func__);
+ goto unlock;
+ }
+
+ kfree(dev_opp->prop_name);
+ dev_opp->prop_name =3D NULL;
+
+ /* Try freeing device_opp if this was the last blocking resource */
+ _remove_device_opp(dev_opp);
+
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_put_prop_name);
+
static bool _opp_is_supported(struct device *dev, struct device_opp *dev=
_opp,
struct device_node *np)
{
@@ -1048,7 +1183,7 @@ static int _opp_add_static_v2(struct device *dev, s=
truct device_node *np)
if (!of_property_read_u32(np, "clock-latency-ns", &val))
new_opp->clock_latency_ns =3D val;
=20
- ret =3D opp_parse_supplies(new_opp, dev);
+ ret =3D opp_parse_supplies(new_opp, dev, dev_opp);
if (ret)
goto free_opp;
=20
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index 70f4564a6ab9d..690638ef36ee5 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -131,6 +131,7 @@ struct device_list_opp {
* @suspend_opp: Pointer to OPP to be used during device suspend.
* @supported_hw: Array of version number to support.
* @supported_hw_count: Number of elements in supported_hw array.
+ * @prop_name: A name to postfix to many DT properties, while parsing th=
em.
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
@@ -157,6 +158,7 @@ struct device_opp {
=20
unsigned int *supported_hw;
unsigned int supported_hw_count;
+ const char *prop_name;
=20
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 3a85110242f00..95403d2ccaf56 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -58,6 +58,8 @@ struct srcu_notifier_head *dev_pm_opp_get_notifier(stru=
ct device *dev);
int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
unsigned int count);
void dev_pm_opp_put_supported_hw(struct device *dev);
+int dev_pm_opp_set_prop_name(struct device *dev, const char *name);
+void dev_pm_opp_put_prop_name(struct device *dev);
#else
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *op=
p)
{
@@ -142,6 +144,13 @@ static inline int dev_pm_opp_set_supported_hw(struct=
device *dev,
=20
static inline void dev_pm_opp_put_supported_hw(struct device *dev) {}
=20
+static inline int dev_pm_opp_set_prop_name(struct device *dev, const cha=
r *name)
+{
+ return -EINVAL;
+}
+
+static inline void dev_pm_opp_put_prop_name(struct device *dev) {}
+
#endif /* CONFIG_PM_OPP */
=20
#if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
--=20
2.27.0.rc0

2221 - 2240 of 7020