Date   

CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp
 

Hi, all,

Please let me resend, because the original mail does not seem to be delivered.

Best regards,
--
M. Kudo

-----Original Message-----
From: 工藤 雅司(CTJ OSS事業推進室)
Sent: Thursday, June 18, 2020 9:20 AM
To: cip-dev@lists.cip-project.org
Subject: CIP IRC weekly meeting today

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=18&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-11-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu
5. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

Note: The followings are 2020 Kernel Team Roadmap stuff. If there are any progresses I will report at the "Kernel maintenance updates" in future.
+. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
+. Upload a guideline for reference hardware platform addition - masashi910

* 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.


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp
 

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=18&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-11-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Ask board owners to review reference platform configs to optimize backporting - masashi910
4. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu
5. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

Note: The followings are 2020 Kernel Team Roadmap stuff. If there are any progresses I will report at the "Kernel maintenance updates" in future.
+. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
+. Upload a guideline for reference hardware platform addition - masashi910

* 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.


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
 

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
 

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

1941 - 1960 of 6742