Date   

Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Jan Kiszka
 

On 17.01.20 14:14, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello Kent,
[...]
3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment
them like that.
Thank you for taking time to check this...
In order to clearly show the differences of my proposal #2 and your proposal,
it might be better to create additional yml file where the duplicated packages are dropped.
I will try to create this data next week :)


@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?
The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
but how about setting it to Jan 27th?
As I'm not in the house next week, I will not be able to comment on the new list, nor vote. In any case, one week might be ok for a short, obvious list. But if we are talking about a list of dozens of packages, that will be too short.

Jan

Best regards,
Kazu


Please reply if you have any comments or questions.

Kind regards,
Kent

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Friday, December 20, 2019 6:59 PM
To: jan.kiszka@siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
cip-dev@lists.cip-project.org; dinesh.kumar@toshiba-tsip.com
Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Hello,

On 20.12.19 03:25, Kento Yoshida wrote:
Thank you for your feedback, Jan.

Why still chrony, why not simply systemd timers? Legacy?
We agree that systemd-timesyncd is sufficient for users who need only SNTP
client functionality.
The reason we want to add Chrony to our core packages is to support
various use cases, and because Chrony is recognized
by CII as being a superior secure NTP implementation.
https://www.coreinfrastructure.org/blogs/securing-network-time/

Since the CII aims to invest in core infrastructure, providing funding for
fundamental projects, I think "chrony"
would be more secure and sustainable.
Oops, I actually confused cron and chrony here. Interestingly, the
question "can't systemd do that?" remained valid :).

I agree to pick the more mature solution for this purpose.

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing
them flat?
This, e.g., pulls python, currently even v2 - anything but a
trivial package. Or did I miss that we have this in
our list already?

@kazuhiro3.hayashi@toshiba.co.jp and @Dinesh Kumar, Do you need a
script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of top-lists
are still in preparation and are under investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their runtime
dependencies already fulfilled with the existing package set (where is
that now, BTW?) or include these dependencies in the set.
I'm assuming the "existing package set" is the list of packages that are already
accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that "all runtime dependencies
must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal pulls around 90 packages
finally)

I only checked
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and the
format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members
become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@toshiba.co.jp; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
packages)

On 09.12.19 14:54, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package
proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc
/pd
p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews,
please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list
already?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [cip-core] Package Proposal #2 (Minimum base packages in Debian)

Jan Kiszka
 

On 16.01.20 09:25, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,
I created a simple package proposal for the packages that are installed in the "minimum base system" of Debian.
These packages are installed by
$ debootstrap --variant=minbase buster ...
It consists of 58 source packages and 84 binary packages, including all run-time dependencies.
The common reason to propose:
"This package is included in the minimum base system of Debian (debootstrap --variant=minbase),
which is essential for all Debian binary package based systems"
I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review
Please reply with you opinion, agree or disagree.
Looks good to us: agree.

Jan

If you cannot agree to add specific packages, please show the reasons as well.
Due Date: January 20th (The next TSC meeting)
We have only 2-3 working days for this review, but
I think it may be enough to agree or disagree the very simple reason above.
(We can extend this due date if more time required for reviews, please let me know if any requests)
Best regards,
Kazu
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Audio Transcription Service Provider

Mew Andre <info@...>
 

Hello,

Do you need someone reliable to transcribe both your short term and long term projects? Or do you need an accurate transcript for your audio or video? 

Allow us to transcribe your audio and provide you accurate transcripts and let us help you reach your business/project goals through the help of our transcription services.

What are our goals with each transcript?
  • Speed
  • Accuracy
  • Confidentiality
Each transcript is properly formatted. Strict grammar and punctuation rules are adhered to and of course, file security is something we take very seriously. 

Have any transcription queries? Send me a message. Let's discuss what you need to get done. We will address any concerns you have. 
  • Professional transcription
  • Accurate and thorough
  • Beautifully transcribed documents.
  • Grammar, spelling and jargon thoroughly checked
We have transcribed audios & videos under various requirements such as :
  • Medical transcription
  • Technical
  • Academic
  • Lectures
  • Business
  • Groups
  • Legal
  • Research interviews
more...

Skilled with international accents and prompt response. Our pricing is better or comparable to individual service provider. In addition we also assist in APA Style formatting for research papers. Please note we don’t conduct research but assist only in formatting of the papers.

Regards,
Mew Andre

Unsubscribe


Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Kazuhiro Hayashi
 

Hello Kent,

[...]
3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment
them like that.
Thank you for taking time to check this...
In order to clearly show the differences of my proposal #2 and your proposal,
it might be better to create additional yml file where the duplicated packages are dropped.
I will try to create this data next week :)


@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?
The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
but how about setting it to Jan 27th?

Best regards,
Kazu


Please reply if you have any comments or questions.

Kind regards,
Kent

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Friday, December 20, 2019 6:59 PM
To: jan.kiszka@siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
cip-dev@lists.cip-project.org; dinesh.kumar@toshiba-tsip.com
Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Hello,

On 20.12.19 03:25, Kento Yoshida wrote:
Thank you for your feedback, Jan.

Why still chrony, why not simply systemd timers? Legacy?
We agree that systemd-timesyncd is sufficient for users who need only SNTP
client functionality.
The reason we want to add Chrony to our core packages is to support
various use cases, and because Chrony is recognized
by CII as being a superior secure NTP implementation.
https://www.coreinfrastructure.org/blogs/securing-network-time/

Since the CII aims to invest in core infrastructure, providing funding for
fundamental projects, I think "chrony"
would be more secure and sustainable.
Oops, I actually confused cron and chrony here. Interestingly, the
question "can't systemd do that?" remained valid :).

I agree to pick the more mature solution for this purpose.

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing
them flat?
This, e.g., pulls python, currently even v2 - anything but a
trivial package. Or did I miss that we have this in
our list already?

@kazuhiro3.hayashi@toshiba.co.jp and @Dinesh Kumar, Do you need a
script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of top-lists
are still in preparation and are under investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their runtime
dependencies already fulfilled with the existing package set (where is
that now, BTW?) or include these dependencies in the set.
I'm assuming the "existing package set" is the list of packages that are already
accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that "all runtime dependencies
must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal pulls around 90 packages
finally)

I only checked
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and the
format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members
become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@toshiba.co.jp; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
packages)

On 09.12.19 14:54, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package
proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc
/pd
p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews,
please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list
already?

Jan

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


Re: RT Testing

Chris Paterson
 

Hello Hayashi-san,

From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: 17 January 2020 01:41

Hello Chris,

Hello,
[...]
Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I
cannot clearly say Yes.
However, at least, the both profiles can create an image including python
only
for testing
because the python packages are already provided in upstream projects (isar,
meta-debian).
Okay. I'm thinking that we aren't going to be able to escape having a separate
'testing' version of CIP-Core, based on
ISAR on the assumption that it has more supported packages then Deby.
The IRC log of yesterday: https://irclogs.baserock.org/cip/%23cip.2020-01-
16.log.html

Starting from isar-cip-core would be better if we need to install
various packages for the testing like build-essential.
Deby also can generate an image including enough dependencies
of simple basic suites like LTP, cyclictest, etc. though.

Also, I guess LAVA can install additional packages for testing
(from Debian apt repository or some package directories on S3)
to their standard image after they boot on the target device.
We don't need to provide a separate testing image in this case.
This is an option. I guess I've spent too long in the oe world without apt.
A key dependency here though is to make sure that the boards have a direct connection to the internet.



Or not use CIP-Core for testing the Kernel as punit suggested ??
Personally, I would like to use CIP-Core image(s) for the kernel testing.
I have no concern about providing packages only for testing
as long as CIP is not responsible to maintain them.
Okay.

I'll try and run a test using CIP-Core + apt and go from there.

Kind regards, Chris




Whether CIP Core provides Python packages or not depends on
what kind of packages will be proposed (requested) by CIP WGs in future.
Currently, several packages which depend on Python packages would be
included in the next proposal from security WG (under review now).

BTW, it would be better to confirm which Python version (2.7 or 3) that
cyclictest.sh depends on.
Do you know anything about this?
Either version (thanks Daniel).
Thank you for your confirmation.


Presumably we'd want to target Python 3 though if that's what the world is
moving to?

I think this is one of the important topics to be discussed in CIP Core.
I agree with your idea (target on Python 3), but there are still
some packages in Debian buster that have a run-time dependency on python
2.7, unfortunately.
I would like to create another thread to think about this topic later :)

Best regards,
Kazu



Kind regards, Chris


Kazu


Linaro test-definitions [2] have the following tests marked within the
preempt-
rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test
[3],
but it hasn't been merged yet and I'm not
sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards
in
the Mentor lab? Or BBB, QEMU etc.? (assuming
that the hardware is suitable).


[0]
https://github.com/Linaro/test-
definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-
c724b852b75aefda2cc3
505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-
core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-
definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-
rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


Re: RT Testing

Chris Paterson
 

Hello Punit,

From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Sent: 17 January 2020 01:02

Hi Chris,

Just thinking out loud below so please bear with me if I'm just stating
the obvious.
Please do ??


Chris Paterson <Chris.Paterson2@renesas.com> writes:

Hello,

From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: 16 January 2020 06:55

Hello Chris,

Thank you for your updates!

Hello Pavel, Hayashi-san, Jan, Daniel,
[...]

Currently there is an issue with the way that the cyclic test case results are
shown (i.e. they aren't) in LAVA due to
a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't
included
in the cip-core RFS [1] that is currently
being used.

Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I
cannot clearly say Yes.
However, at least, the both profiles can create an image including python
only
for testing
because the python packages are already provided in upstream projects (isar,
meta-debian).
Okay. I'm thinking that we aren't going to be able to escape having a
separate 'testing' version of CIP-Core, based on ISAR on the
assumption that it has more supported packages then Deby.

Or not use CIP-Core for testing the Kernel as punit suggested ??
I think CIP-core shouldn't be thought of as a complete filesystem, but
the base components that should exist as part of any CIP system.

As it is, it's unlikely that any real product will need only the
functionality provided by CIP core.
True.


If that makes sense, then we should make it easy to create derived
images / filesystems that include additional software as needed for the
task at hand, e.g., testing CIP kernels.
Good point, agreed.


In addition, there is a need to test the functionality provided by the
core components, i.e., CIP-core packages along with relevant kernels on
supported devices. As yet, I don't think these tests exist (or even
defined).
This is something we do indeed need to do.

Thanks, Chris


But I'm new to the project so am very likely missing things.

Thanks,
Punit

[...]


RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Kento Yoshida
 

Hello,

I would like to resume our proposal from security working group.
As you know, Kazu has modified the script to generate a proposal and posted the minimum base system proposal, and then I created the new proposal.

The difference from the original (rev01) proposal is below:
1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the new proposal because they have an issue such as non-well maintained, python version, too much dependencies and so on. We'll separately propose them after solved these issues.
2. The new proposal shows all source package as flat. Thanks to the new script, Kazu!
3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment them like that.

@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?

Please reply if you have any comments or questions.

Kind regards,
Kent

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Friday, December 20, 2019 6:59 PM
To: jan.kiszka@siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
cip-dev@lists.cip-project.org; dinesh.kumar@toshiba-tsip.com
Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Hello,

On 20.12.19 03:25, Kento Yoshida wrote:
Thank you for your feedback, Jan.

Why still chrony, why not simply systemd timers? Legacy?
We agree that systemd-timesyncd is sufficient for users who need only SNTP
client functionality.
The reason we want to add Chrony to our core packages is to support
various use cases, and because Chrony is recognized
by CII as being a superior secure NTP implementation.
https://www.coreinfrastructure.org/blogs/securing-network-time/

Since the CII aims to invest in core infrastructure, providing funding for
fundamental projects, I think "chrony"
would be more secure and sustainable.
Oops, I actually confused cron and chrony here. Interestingly, the
question "can't systemd do that?" remained valid :).

I agree to pick the more mature solution for this purpose.

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing
them flat?
This, e.g., pulls python, currently even v2 - anything but a
trivial package. Or did I miss that we have this in
our list already?

@kazuhiro3.hayashi@toshiba.co.jp and @Dinesh Kumar, Do you need a
script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of top-lists
are still in preparation and are under investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their runtime
dependencies already fulfilled with the existing package set (where is
that now, BTW?) or include these dependencies in the set.
I'm assuming the "existing package set" is the list of packages that are already
accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that "all runtime dependencies
must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal pulls around 90 packages
finally)

I only checked
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and the
format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members
become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@toshiba.co.jp; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
packages)

On 09.12.19 14:54, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package
proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc
/pd
p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews,
please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list
already?

Jan

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


Re: RT Testing

Kazuhiro Hayashi
 

Hello Chris,

Hello,
[...]
Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I
cannot clearly say Yes.
However, at least, the both profiles can create an image including python only
for testing
because the python packages are already provided in upstream projects (isar,
meta-debian).
Okay. I'm thinking that we aren't going to be able to escape having a separate 'testing' version of CIP-Core, based on
ISAR on the assumption that it has more supported packages then Deby.
The IRC log of yesterday: https://irclogs.baserock.org/cip/%23cip.2020-01-16.log.html

Starting from isar-cip-core would be better if we need to install
various packages for the testing like build-essential.
Deby also can generate an image including enough dependencies
of simple basic suites like LTP, cyclictest, etc. though.

Also, I guess LAVA can install additional packages for testing
(from Debian apt repository or some package directories on S3)
to their standard image after they boot on the target device.
We don't need to provide a separate testing image in this case.


Or not use CIP-Core for testing the Kernel as punit suggested ??
Personally, I would like to use CIP-Core image(s) for the kernel testing.
I have no concern about providing packages only for testing
as long as CIP is not responsible to maintain them.



Whether CIP Core provides Python packages or not depends on
what kind of packages will be proposed (requested) by CIP WGs in future.
Currently, several packages which depend on Python packages would be
included in the next proposal from security WG (under review now).

BTW, it would be better to confirm which Python version (2.7 or 3) that
cyclictest.sh depends on.
Do you know anything about this?
Either version (thanks Daniel).
Thank you for your confirmation.


Presumably we'd want to target Python 3 though if that's what the world is moving to?
I think this is one of the important topics to be discussed in CIP Core.
I agree with your idea (target on Python 3), but there are still
some packages in Debian buster that have a run-time dependency on python 2.7, unfortunately.
I would like to create another thread to think about this topic later :)

Best regards,
Kazu



Kind regards, Chris


Kazu


Linaro test-definitions [2] have the following tests marked within the preempt-
rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test [3],
but it hasn't been merged yet and I'm not
sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards in
the Mentor lab? Or BBB, QEMU etc.? (assuming
that the hardware is suitable).


[0]
https://github.com/Linaro/test-
definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-
c724b852b75aefda2cc3
505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-
core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-
rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


Re: RT Testing

punit1.agrawal@...
 

Hi Chris,

Just thinking out loud below so please bear with me if I'm just stating
the obvious.

Chris Paterson <Chris.Paterson2@renesas.com> writes:

Hello,

From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: 16 January 2020 06:55

Hello Chris,

Thank you for your updates!

Hello Pavel, Hayashi-san, Jan, Daniel,
[...]

Currently there is an issue with the way that the cyclic test case results are
shown (i.e. they aren't) in LAVA due to
a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't included
in the cip-core RFS [1] that is currently
being used.

Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I
cannot clearly say Yes.
However, at least, the both profiles can create an image including python only
for testing
because the python packages are already provided in upstream projects (isar,
meta-debian).
Okay. I'm thinking that we aren't going to be able to escape having a
separate 'testing' version of CIP-Core, based on ISAR on the
assumption that it has more supported packages then Deby.

Or not use CIP-Core for testing the Kernel as punit suggested ??
I think CIP-core shouldn't be thought of as a complete filesystem, but
the base components that should exist as part of any CIP system.

As it is, it's unlikely that any real product will need only the
functionality provided by CIP core.

If that makes sense, then we should make it easy to create derived
images / filesystems that include additional software as needed for the
task at hand, e.g., testing CIP kernels.

In addition, there is a need to test the functionality provided by the
core components, i.e., CIP-core packages along with relevant kernels on
supported devices. As yet, I don't think these tests exist (or even
defined).

But I'm new to the project so am very likely missing things.

Thanks,
Punit

[...]


Re: [PATCH 4.19.y-cip 10/12] arm64: dts: renesas: r8a774c0: cat874: Add definition for 12V regulator

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 16 January 2020 15:30
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>;
Chris Paterson <Chris.Paterson2@renesas.com>
Subject: Re: [PATCH 4.19.y-cip 10/12] arm64: dts: renesas: r8a774c0: cat874:
Add definition for 12V regulator

Hi!

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 7fc009cbd7d11d6b27ba5443dbfa80a0513829e4 upstream.

Power rail "D12.0V" comes straight from the power barrel connector,
and it's used in both main board and sub board.
Given that line is always on, always constant, and not referenced anywhere,
does it need to be described in the dts?

Will it be used in future?
Yes the regulator will be used in future. (we plan to add support for lvds panel, the regulator will be used by the backlight)

Cheers,
--Prabhakar

Best regards,
Pavel

@@ -65,6 +65,15 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};

+reg_12p0v: regulator-12p0v {
+compatible = "regulator-fixed";
+regulator-name = "D12.0V";
+regulator-min-microvolt = <12000000>;
+regulator-max-microvolt = <12000000>;
+regulator-boot-on;
+regulator-always-on;
+};
+
sound: sound {
compatible = "simple-audio-card";

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

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: RT Testing

Daniel Wagner <wagi@...>
 

On Thu, Jan 16, 2020 at 02:25:27PM +0100, Pavel Machek wrote:
Even basic cyclictest is good to have, but it would be really good to
have some kind of background load. I'd expect latency to raise by
factor of 3 in make -j 5 of kernel.
I've been experimenting with compiling the kernel as workload to
trigger latency spikes. So far this test didn't trigger one. It is
quite good to see if there are performance rgressions (it takes
suddenly longer). As long there is enough space on the device and all
tools are available it's okay to run it.

I found it a bit difficult to use it in lava because the rootfs
doesn't bring all the tools and the kernel source it takes ages to
setup.

I tried to come up with simpler test reproducing comparable latencies,
but I did not get there. This creates cca factor of two for me:

cat /dev/urandom | head -c 10000000 | gzip -9 - > delme.random.gz
echo "Initial phase done"
for A in `seq 222`; do
( zcat delme.random.gz | gzip -9 - | zcat > /dev/null; echo -n [$A done] ) &
done

What is easily available on the test systems? gzip? python? bzip2?
I am using rt-tests and plan to run more stressors from
stress-ng. This seems to give a good reproducable workload and really
stresses the system.

Thanks,
Daniel


Re: [PATCH 4.19.y-cip 10/12] arm64: dts: renesas: r8a774c0: cat874: Add definition for 12V regulator

Pavel Machek
 

Hi!

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 7fc009cbd7d11d6b27ba5443dbfa80a0513829e4 upstream.

Power rail "D12.0V" comes straight from the power barrel connector,
and it's used in both main board and sub board.
Given that line is always on, always constant, and not referenced
anywhere, does it need to be described in the dts?

Will it be used in future?

Best regards,
Pavel

@@ -65,6 +65,15 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};

+ reg_12p0v: regulator-12p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "D12.0V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound: sound {
compatible = "simple-audio-card";

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


Re: [PATCH 4.19.y-cip 00/12] Renesas RZ/G2E backport IPA support along with minor fixes

Pavel Machek
 

Hi!

I quickly reviewed the patches, and might have minor comments, but the
series look good.

Tests are currently running at

https://gitlab.com/cip-project/cip-kernel/linux-cip/tree/ci/pavel/linux-cip

If there are no objections and tests succeed, I can push the applied
series.

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


[PATCH 4.19.y-cip 12/12] arm64: dts: renesas: r8a774c0: cat874: Sort nodes

Lad Prabhakar
 

From: Yoshihiro Kaneko <ykaneko0929@gmail.com>

commit 63a0f811558b9a5587a8c52978a57a8b528b074a upstream.

Sort nodes.

If node address is present
* Sort by node address, grouping all nodes with the same compat string
and sorting the group alphabetically.
Else
* Sort alphabetically

This should not have any run-time effect.

Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 28 ++++++++++++-------------
1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
index 160b176..5be3bad 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
@@ -82,13 +82,13 @@
simple-audio-card,bitclock-master = <&sndcpu>;
simple-audio-card,frame-master = <&sndcpu>;

- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
-
sndcodec: simple-audio-card,codec {
sound-dai = <&tda19988>;
};
+
+ sndcpu: simple-audio-card,cpu {
+ sound-dai = <&rcar_sound>;
+ };
};

vcc_sdhi0: regulator-vcc-sdhi0 {
@@ -255,16 +255,16 @@
function = "du";
};

- i2c1_pins: i2c1 {
- groups = "i2c1_b";
- function = "i2c1";
- };
-
hscif2_pins: hscif2 {
groups = "hscif2_data_a", "hscif2_ctrl_a";
function = "hscif2";
};

+ i2c1_pins: i2c1 {
+ groups = "i2c1_b";
+ function = "i2c1";
+ };
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
@@ -288,15 +288,15 @@
power-source = <1800>;
};

- sound_pins: sound {
- groups = "ssi01239_ctrl", "ssi0_data";
- function = "ssi";
- };
-
sound_clk_pins: sound_clk {
groups = "audio_clkout1_a";
function = "audio_clk";
};
+
+ sound_pins: sound {
+ groups = "ssi01239_ctrl", "ssi0_data";
+ function = "ssi";
+ };
};

&rcar_sound {
--
2.7.4


[PATCH 4.19.y-cip 11/12] arm64: dts: renesas: Use ip=on for bootargs

Lad Prabhakar
 

From: Magnus Damm <damm+renesas@opensource.se>

commit b31b43c92daee8628c60b411452b1b17acdac580 upstream.

Convert bootargs from ip=dhcp to ip=on

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[fab: Drop changes to r8a77990-ebisu.dts, r8a77995-draak.dts, and
ulcb.dtsi as not applicable]
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 2 +-
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
index 83b39fd..160b176 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
@@ -20,7 +20,7 @@
};

chosen {
- bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=on";
stdout-path = "serial0:115200n8";
};

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index b6d5332..233f26f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -19,7 +19,7 @@
};

chosen {
- bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=on";
stdout-path = "serial0:115200n8";
};

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 3b90f81..99b95d9 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -38,7 +38,7 @@
};

chosen {
- bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=on";
stdout-path = "serial0:115200n8";
};

--
2.7.4


[PATCH 4.19.y-cip 10/12] arm64: dts: renesas: r8a774c0: cat874: Add definition for 12V regulator

Lad Prabhakar
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 7fc009cbd7d11d6b27ba5443dbfa80a0513829e4 upstream.

Power rail "D12.0V" comes straight from the power barrel connector,
and it's used in both main board and sub board.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
index fdca695..83b39fd 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
@@ -65,6 +65,15 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};

+ reg_12p0v: regulator-12p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "D12.0V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound: sound {
compatible = "simple-audio-card";

--
2.7.4


[PATCH 4.19.y-cip 09/12] arm64: dts: renesas: Update 'vsps' properties for readability

Lad Prabhakar
 

From: Jacopo Mondi <jacopo+renesas@jmondi.org>

commit 38290431d56d7d3928ac89e9f8d3d6b3c8df4c6e upstream.

Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
match what's in the documentation example.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[fab: Dropped changes to r8a77990.dtsi as not applicable]
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 3f5b659..cf25dbb 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1813,7 +1813,7 @@
clocks = <&cpg CPG_MOD 724>,
<&cpg CPG_MOD 723>;
clock-names = "du.0", "du.1";
- vsps = <&vspd0 0 &vspd1 0>;
+ vsps = <&vspd0 0>, <&vspd1 0>;
status = "disabled";

ports {
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c87eed7..b9edb71 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2795,7 +2795,7 @@
<&cpg CPG_MOD 721>,
<&cpg CPG_MOD 727>;
clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
- vsps = <&vspd0 0 &vspd1 0 &vspd2 0 &vspd0 1>;
+ vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
status = "disabled";

ports {
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index f1dfd174..7de6edf 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1839,7 +1839,7 @@
clock-names = "du.0", "du.1", "du.3";
status = "disabled";

- vsps = <&vspd0 0 &vspd1 0 &vspd0 1>;
+ vsps = <&vspd0 0>, <&vspd1 0>, <&vspd0 1>;

ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index fe77bc4..db0c8ad 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -944,7 +944,7 @@
clocks = <&cpg CPG_MOD 724>,
<&cpg CPG_MOD 723>;
clock-names = "du.0", "du.1";
- vsps = <&vspd0 0 &vspd1 0>;
+ vsps = <&vspd0 0>, <&vspd1 0>;
status = "disabled";

ports {
--
2.7.4


[PATCH 4.19.y-cip 08/12] arm64: dts: renesas: r8a774c0: Fix register range of display node

Lad Prabhakar
 

From: Geert Uytterhoeven <geert+renesas@glider.be>

commit 23ad2b4672a7572e0f091cfe90aac1cd9bdca28a upstream.

Since the R8A774C0 SoC uses DU{0,1} only, the register block length
should be 0x40000.

Based on commit 06585ed38b6698bc ("arm64: dts: renesas: r8a77990: Fix
register range of display node") for R-Car E3.

Fixes: 8ed3a6b223159df3 ("arm64: dts: renesas: r8a774c0: Add display output support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 438844f..3f5b659 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1807,7 +1807,7 @@

du: display@feb00000 {
compatible = "renesas,du-r8a774c0";
- reg = <0 0xfeb00000 0 0x80000>;
+ reg = <0 0xfeb00000 0 0x40000>;
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 724>,
--
2.7.4


[PATCH 4.19.y-cip 07/12] arm64: dts: renesas: r8a774c0: Add missing assigned-clocks for CAN[01]

Lad Prabhakar
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit e8efd2a8e20a9d7a7bd701950254a0ae04a8ce27 upstream.

Define "assigned-clocks" and "assigned-clock-rates" properties
for CAN[01] DT nodes, as required by the dt-bindings.

Fixes: 036bc85c1d06ef0a ("arm64: dts: renesas: r8a774c0: Add clkp2 clock to CAN nodes")
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index cb1b71d..438844f 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -975,6 +975,8 @@
<&cpg CPG_CORE R8A774C0_CLK_CANFD>,
<&can_clk>;
clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A774C0_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>;
resets = <&cpg 916>;
status = "disabled";
@@ -989,6 +991,8 @@
<&cpg CPG_CORE R8A774C0_CLK_CANFD>,
<&can_clk>;
clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A774C0_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>;
resets = <&cpg 915>;
status = "disabled";
--
2.7.4


[PATCH 4.19.y-cip 06/12] arm64: dts: renesas: r8a774c0: Clean up CPU compatibles

Lad Prabhakar
 

From: Robin Murphy <robin.murphy@arm.com>

commit 11290c09e29600f45684113d78209d1df1c22aba upstream.

Apparently this DTS crossed over with commit 31af04cd60d3 ("arm64: dts:
Remove inconsistent use of 'arm,armv8' compatible string") and missed
out on the cleanup, so put it right.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 1e8b8af..cb1b71d 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -70,7 +70,7 @@
#size-cells = <0>;

a53_0: cpu@0 {
- compatible = "arm,cortex-a53", "arm,armv8";
+ compatible = "arm,cortex-a53";
reg = <0>;
device_type = "cpu";
#cooling-cells = <2>;
@@ -83,7 +83,7 @@
};

a53_1: cpu@1 {
- compatible = "arm,cortex-a53", "arm,armv8";
+ compatible = "arm,cortex-a53";
reg = <1>;
device_type = "cpu";
power-domains = <&sysc R8A774C0_PD_CA53_CPU1>;
--
2.7.4

3321 - 3340 of 7513