Date   

Re: [PATCH 4.19.y-cip 00/17] Renesas RZ/G2H add FCP{FV}, VSP, FDP1, DU, HDMI, LVDS, PWM and sound support

Nobuhiro Iwamatsu
 

Hi all,

Sorry, I noticed that the commits in this patch series did not have the signed-off-by tag by CIP kernel maintainers.
I force-pushed with signed-off-by tag. Please note that the commit-hash of git tree will change and you
will not be able to update it with 'git pull'. Please use 'git remote update' or other git command instead of.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Lad Prabhakar
Sent: Wednesday, November 4, 2020 8:04 PM
To: Pavel Machek <pavel@...>; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@...>
Cc: cip-dev@...; Biju Das <biju.das.jz@...>
Subject: Re: [cip-dev] [PATCH 4.19.y-cip 00/17] Renesas RZ/G2H add FCP{FV}, VSP, FDP1, DU, HDMI, LVDS, PWM and sound
support

Hi Pavel, Nobuhiro,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 04 November 2020 08:29
To: nobuhiro1.iwamatsu@...
Cc: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>; cip-dev@...; pavel@...;
Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 4.19.y-cip 00/17] Renesas RZ/G2H add FCP{FV}, VSP, FDP1, DU, HDMI, LVDS, PWM and sound support

Hi!

This patch series adds support for following peripheral to Renesas
RZ/G2H,
* FCPF, FCPV
* FDP1
* PWM
* DU, HDMI, LVDS
* Sound

All the patches have been cherry picked from Linux kernel
v5.10-rc2.
create mode 100644 arch/arm64/boot/dts/renesas/r8a774e1-hihope-rzg2h-ex-idk-1110wr.dts
I reviewed this patch series. I commented to 17/17.
I don't think this issue will affect our reference board, but it should be fixed.

And looks good to me without 17/17.
I don't see any problems with patches up-to 16, and our testing
passes, so I applied that.
Thank you.

Cheers,
Prabhakar


Re: Leaving Codethink and CIP

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Ben Hutchings
Sent: Wednesday, October 28, 2020 7:17 AM
To: cip-dev@...
Subject: [cip-dev] Leaving Codethink and CIP

I will be leaving Codethink next month, and will no longer be working
directly on CIP. (With my Debian hat on, I may still submit merge
requests to the cip-kernel-sec repository.) My last working day here
will be 11 November.

I want to thank everyone who's worked to make super-long-term Linux
kernel maintenance possible. CIP has a great kernel team now and I'm
confident that you'll carry on doing a fine job without me.
I appreciate your letting me know about your resignation from Codethink.
I'm so grateful for your support and advice.

I believe we will meet again at the conference soon.
And wish you a happy new job.

Best regards,
Nobuhiro


Re: Backporting of security patches for Intel i40e drivers required?

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

Hi, Ben-san,

By this time, you may have already left from cip-dev, but I wanted to update our status.

We again discussed this, and Iwamatsu-san kindly took over this and created patches.
In order to make sure that those patches appropriately address the issue, he is sending
RFC to the Intel contributors.

Thanks again for your comments.

Also, I wanted to re-iterate my thankfulness to you for what you have done for CIP.
I am really hoping your good luck in your new tasks.

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of
Ben Hutchings
Sent: Thursday, November 12, 2020 5:50 AM
To: cip-dev@...; nobuhiro1.iwamatsu@...;
jan.kiszka@...
Subject: Re: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

On Wed, 2020-11-11 at 13:18 +0000, masashi.kudo@... wrote:
Hi,

The other day, I inquired about CVE-2019-0145, CVE-2019-0147, and
CVE-2019-0148 in the following email.

The kernel team discussed for weeks how to deal with them.
As a result of these discussions, we concluded to ignore them until Intel fixes
issues, because:
- The descriptions of patches are not clear, and we cannot figure out
what is right
- The patches we identified do not really look like fixing too serious stuff.
They all seemed to involve communication with the owner of a PCIe Virtual
Function (VF). A VF might be assigned to a VM or privileged process. In Civil
Infrastructure systems those should already be trusted and so the issues don't
matter that much.

So far, we had the following AI, but we close this based on the above situation.

2. Check whether CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 needs to
be backported to 4.4 - Kernel Team
[...]

Well, I found it quite easy to backport the applicable parts of the fixes. I already
sent them along with some other fixes for the 4.14 and 4.9 branches, and could
still do so for 4.4.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


cip-kernel-sec Updates for Week of 2020-11-12

Chen-Yu Tsai <wens213@...>
 

Hi everyone,

This week we have four new issues:

- CVE-2020-25669 [input/sunkbd UAF] - No fix yet.

We can ignore this. This is ancient hardware.

It's weird that Siemens enabled it in their v4.4 config, but not
their v4.19 one.
I believe we can remove this from their v4.4 config as well.

- CVE-2020-25704 [perf memory leak] - Fix backported to 4.19+

Based on the fixes tag, this was introduced in v4.7-rc1.

- CVE-2020-8694 [powercap non-root access] - Fixed for all stable kernels

- CVE-2020-slab-out-of-bounds-read-fbcon [fbcon out-of-bounds read] -
Fixed for all stable kernels

Fix basically removes the broken KD_FONT_OP_SET ioctl.


Regards
ChenYu
Moxa


Issue in mounting Boot Partition on rootfs

Rajashree Sankar <rajashree.sankar@...>
 

Hello All,
We need the boot partition to be mounted in rootfs For its access.
We have made a fstab entry /dev/mmcblk0p1  /boot   auto auto,sync,rw 0 0 to /etc/fstab .On changing the contents of the mounted boot partition ,the system does not boot on reboot/power cycle. Thi problem occurs 2/3 times.

Could you please share how this could be solved.
Thanks and Regards,
Rajashree Sankar

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.


Re: Leaving Codethink and CIP

SZ Lin (林上智) <sz.lin@...>
 

Hi,

From: cip-dev@... <cip-dev@...> On Behalf Of
I will be leaving Codethink next month, and will no longer be working
directly on CIP. (With my Debian hat on, I may still submit merge
requests to the cip-kernel-sec repository.) My last working day here
will be 11 November.

I want to thank everyone who's worked to make super-long-term Linux
kernel maintenance possible. CIP has a great kernel team now and I'm
confident that you'll carry on doing a fine job without me.
Thanks to your massive contribution in the past few years, I cherish the
memory of working with you and wish you all the best, enjoy your new job and life.

I believe we will meet again at the conference soon.

SZ


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=11&day=12&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00

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

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

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 needs to be backported to 4.4 - Kernel Team

* Kernel maintenance updates
* Kernel testing
* 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.


Re: Leaving Codethink and CIP

Pavel Machek
 

Hi!

I will be leaving Codethink next month, and will no longer be working
directly on CIP. (With my Debian hat on, I may still submit merge
requests to the cip-kernel-sec repository.) My last working day here
will be 11 November.

I want to thank everyone who's worked to make super-long-term Linux
kernel maintenance possible. CIP has a great kernel team now and I'm
confident that you'll carry on doing a fine job without me.
Thanks for all the great work, and good luck in whatever you do next.

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


Re: Backporting of security patches for Intel i40e drivers required?

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2020-11-11 at 13:18 +0000, masashi.kudo@... wrote:
Hi,

The other day, I inquired about CVE-2019-0145, CVE-2019-0147, and CVE-2019-0148 in the following email.

The kernel team discussed for weeks how to deal with them.
As a result of these discussions, we concluded to ignore them until Intel fixes issues, because:
- The descriptions of patches are not clear, and we cannot figure out what is right
- The patches we identified do not really look like fixing too serious stuff.
They all seemed to involve communication with the owner of a PCIe
Virtual Function (VF). A VF might be assigned to a VM or privileged
process. In Civil Infrastructure systems those should already be
trusted and so the issues don't matter that much.

So far, we had the following AI, but we close this based on the above situation.

2. Check whether CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 needs to be backported to 4.4 - Kernel Team
[...]

Well, I found it quite easy to backport the applicable parts of the
fixes. I already sent them along with some other fixes for the 4.14
and 4.9 branches, and could still do so for 4.4.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: Backporting of security patches for Intel i40e drivers required?

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

Hi,

The other day, I inquired about CVE-2019-0145, CVE-2019-0147, and CVE-2019-0148 in the following email.

The kernel team discussed for weeks how to deal with them.
As a result of these discussions, we concluded to ignore them until Intel fixes issues, because:
- The descriptions of patches are not clear, and we cannot figure out what is right
- The patches we identified do not really look like fixing too serious stuff.

So far, we had the following AI, but we close this based on the above situation.

2. Check whether CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 needs to be backported to 4.4 - Kernel Team

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of
Jan Kiszka
Sent: Friday, October 9, 2020 4:24 PM
To: nobuhiro1.iwamatsu@...; cip-dev@...
Subject: Re: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

Hi all,

given the exposure of such a device but also the fact that I can't tell for sure
if/where it's used (not only by us), I would recommend backporting.

Jan

On 09.10.20 02:23, nobuhiro1.iwamatsu@... wrote:
Hi,

I have some comment for this issue.
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200810/021
006.html

https://lore.kernel.org/stable/20200807205517.1740307-1-jesse.brandebu
rg@.../

There are multiple patches fixed for 4.19, which can be separated by feature.

- i40e: add num_vectors checker in iwarp handler

This issue has been produced by e3219ce6a7754 ("i40e: Add support for
client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

- i40e: Wrong truncation from u16 to u8
This can be apply in 4.4.y.

- i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c

This issue has been produced by e284fc280473b ("i40e: Add and delete
cloud filter").
It is not included in 4.4.y. However, this patch has several different fixes, so
some patches need to be applied.

--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -181,7 +181,7 @@ static inline bool i40e_vc_isvalid_vsi_id(struct
i40e_vf *vf, u16 vsi_id)
* check for the valid queue id
**/
static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
- u8 qid)
+ u16 qid)
{
struct i40e_pf *pf = vf->pf;
struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);


- i40e: Memory leak in i40e_config_iwarp_qvlist
This issue has been produced by e3219ce6a7754 ("i40e: Add support for
client interface for IWARP driver").
e3219ce6a7754 is not included in 4.4.y and can be ignored.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@...
[mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@...
Cc: jan.kiszka@...
Subject: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

Hi, Jan-san, All,

At the IRC meeting today, we identified the following new CVEs are not in
LTS4.4 yet.

- CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for
mainline and 4.19+

These are for i40e driver for Intel.

The kernel team would like to know whether their backporting is needed or
not.

For details of those CVE checking results, please see the following.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requ
ests/75/diffs

Regarding the discussion of the IRC meeting, please see the following.
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.0
0.log.html

Best regards,
--
M. Kudo
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Re: [cip-members] Report from Real Time meeting

Pavel Machek
 

Hi!

There was (virtual) Real Time meeting yesterday.
The meeting was with Thomas Gleixner (and company), about upstreaming
efforts; it was not a CIP meeting.

We still make our own plans, and likely next CIP LTS kernel will be
5.10-based, and likely we'll maintain 5.10-cip and 5.10-cip-rt
branches.

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 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Lad Prabhakar
 

Hi Nobuhiro, Pavel,

-----Original Message-----
From: nobuhiro1.iwamatsu@... <nobuhiro1.iwamatsu@...>
Sent: 10 November 2020 12:17
To: pavel@...
Cc: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>; cip-dev@...;
Biju Das <biju.das.jz@...>
Subject: RE: [PATCH 4.4.y-cip 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Hi all,

-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Tuesday, November 10, 2020 4:55 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@...>
Cc: prabhakar.mahadev-lad.rj@...; cip-dev@...; pavel@...;
biju.das.jz@...
Subject: Re: [PATCH 4.4.y-cip 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Hi!

.../devicetree/bindings/net/can/rcar_can.txt | 3 +-
.../devicetree/bindings/spi/spi-rspi.txt | 1 +
.../boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts | 11 ++
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 52 ++++++++
arch/arm/boot/dts/r8a7742-iwg21m.dtsi | 79 +++++++++++-
arch/arm/boot/dts/r8a7742.dtsi | 90 ++++++++++++++
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 112 +++++++++++++++++-
drivers/spi/spi-sh-msiof.c | 92 +++++++++++---
8 files changed, 418 insertions(+), 22 deletions(-)
I reviewed this patch series, there is not issue.
I can apply and push if there is no objection.
I don't see any problems either, so no objections from me.
OK, I will push this series.
Thank you for the review and acceptance.

Cheers,
Prabhakar


Re: [PATCH 4.4.y-cip 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Nobuhiro Iwamatsu
 

Hi all,

-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Tuesday, November 10, 2020 4:55 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@...>
Cc: prabhakar.mahadev-lad.rj@...; cip-dev@...; pavel@...;
biju.das.jz@...
Subject: Re: [PATCH 4.4.y-cip 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Hi!

.../devicetree/bindings/net/can/rcar_can.txt | 3 +-
.../devicetree/bindings/spi/spi-rspi.txt | 1 +
.../boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts | 11 ++
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 52 ++++++++
arch/arm/boot/dts/r8a7742-iwg21m.dtsi | 79 +++++++++++-
arch/arm/boot/dts/r8a7742.dtsi | 90 ++++++++++++++
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 112 +++++++++++++++++-
drivers/spi/spi-sh-msiof.c | 92 +++++++++++---
8 files changed, 418 insertions(+), 22 deletions(-)
I reviewed this patch series, there is not issue.
I can apply and push if there is no objection.
I don't see any problems either, so no objections from me.
OK, I will push this series.

Best regards,
Pavel
Best regards,
Nobuhiro


Report from Real Time meeting

Pavel Machek
 

Hi!

There was (virtual) Real Time meeting yesterday.

They are switching from "gold"/"silver" etc levels to "premier" 50K /
"general" 25K a year; staying with the old agreement is okay.

-stable-rt will likely be published two days before final release, and
it would be good to test them on our Lave infrastructure when they
are.

v4.4-rt maintainence will likely end in Feb 2022, v4.19-rt is
scheduled to end in Dec 2024. We may need to start mainaining it
ourselves or step up as a maintainers in that timeframe.

It is now clear that Real Time support will not be merged into v5.10.

Useful Real Time support for arm32 and arm64 _may_ make it to
v5.11. If it does not make it, printk() support will likely be
responsible.

If you don't use printk() in production, and merging Real Time support
to v5.11 would be useful to you, let me know; it is possible we can
push in that direction. It would mean additional additional patches
for v5.11 during development, but final product could run on
unmodified v5.11.

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 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Pavel Machek
 

Hi!

.../devicetree/bindings/net/can/rcar_can.txt | 3 +-
.../devicetree/bindings/spi/spi-rspi.txt | 1 +
.../boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts | 11 ++
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 52 ++++++++
arch/arm/boot/dts/r8a7742-iwg21m.dtsi | 79 +++++++++++-
arch/arm/boot/dts/r8a7742.dtsi | 90 ++++++++++++++
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 112 +++++++++++++++++-
drivers/spi/spi-sh-msiof.c | 92 +++++++++++---
8 files changed, 418 insertions(+), 22 deletions(-)
I reviewed this patch series, there is not issue.
I can apply and push if there is no objection.
I don't see any problems either, so no objections from me.

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 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Lad Prabhakar [mailto:prabhakar.mahadev-lad.rj@...]
Sent: Tuesday, November 10, 2020 12:50 AM
To: cip-dev@...; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>
Cc: Biju Das <biju.das.jz@...>
Subject: [PATCH 4.4.y-cip 00/14] Renesas RZ/G1H add support for CAN, IPMMU, QSPI, RTC

Hi All,

This patch series adds support for below peripherals (along with fixes to
msiof driver),
* CAN
* IPMMU
* QSPI
* RTC

All the patches have been cherry picked from upstream kernel.

Cheers,
Prabhakar

Geert Uytterhoeven (2):
spi: sh-msiof: Avoid writing to registers from spi_master.setup()
spi: sh-msiof: Implement cs-gpios configuration

Lad Prabhakar (12):
ARM: dts: r8a7742-iwg21m: Sort the nodes alphabetically
ARM: dts: r8a7742-iwg21m: Add RTC support
spi: renesas,rspi: Add r8a7742 to the compatible list
ARM: dts: r8a7742: Add QSPI support
ARM: dts: r8a7742-iwg21m: Add SPI NOR support
ARM: dts: r8a7742-iwg21d-q7: Add SPI NOR support
pinctrl: sh-pfc: r8a7790: Add CAN pins, groups and functions
dt-bindings: can: rcar_can: Add r8a7742 support
ARM: dts: r8a7742: Add CAN support
ARM: dts: r8a7742-iwg21d-q7: Add can1 support to carrier board
ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Add can0 support to camera DB
ARM: dts: r8a7742: Add IPMMU DT nodes

.../devicetree/bindings/net/can/rcar_can.txt | 3 +-
.../devicetree/bindings/spi/spi-rspi.txt | 1 +
.../boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts | 11 ++
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 52 ++++++++
arch/arm/boot/dts/r8a7742-iwg21m.dtsi | 79 +++++++++++-
arch/arm/boot/dts/r8a7742.dtsi | 90 ++++++++++++++
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 112 +++++++++++++++++-
drivers/spi/spi-sh-msiof.c | 92 +++++++++++---
8 files changed, 418 insertions(+), 22 deletions(-)
I reviewed this patch series, there is not issue.
I can apply and push if there is no objection.

Best regards,
Nobuhiro


[PATCH 4.4.y-cip 14/14] ARM: dts: r8a7742: Add IPMMU DT nodes

Lad Prabhakar
 

commit 78aa219022f636f2adda9eb12be0a04b6907a4e0 upstream.

Add the five IPMMU instances found in the r8a7742 to DT with a disabled
status.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Link: https://lore.kernel.org/r/20200825141805.27105-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Joerg Roedel <jroedel@...>
[PL: Dropped SoC specific compatible string]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
arch/arm/boot/dts/r8a7742.dtsi | 43 ++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index af6888521595..d326602bee3f 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -782,6 +782,49 @@
#thermal-sensor-cells = <0>;
};

+ ipmmu_sy0: iommu@e6280000 {
+ compatible = "renesas,ipmmu-vmsa";
+ reg = <0 0xe6280000 0 0x1000>;
+ interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ status = "disabled";
+ };
+
+ ipmmu_sy1: iommu@e6290000 {
+ compatible = "renesas,ipmmu-vmsa";
+ reg = <0 0xe6290000 0 0x1000>;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ status = "disabled";
+ };
+
+ ipmmu_ds: iommu@e6740000 {
+ compatible = "renesas,ipmmu-vmsa";
+ reg = <0 0xe6740000 0 0x1000>;
+ interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ status = "disabled";
+ };
+
+ ipmmu_mp: iommu@ec680000 {
+ compatible = "renesas,ipmmu-vmsa";
+ reg = <0 0xec680000 0 0x1000>;
+ interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ status = "disabled";
+ };
+
+ ipmmu_mx: iommu@fe951000 {
+ compatible = "renesas,ipmmu-vmsa";
+ reg = <0 0xfe951000 0 0x1000>;
+ interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ status = "disabled";
+ };
+
icram0: sram@e63a0000 {
compatible = "mmio-sram";
reg = <0 0xe63a0000 0 0x12000>;
--
2.17.1


[PATCH 4.4.y-cip 13/14] ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Add can0 support to camera DB

Lad Prabhakar
 

commit 9d8827b27b758ecb4fda3da812c77c316b3a5548 upstream.

This patch enables CAN0 interface exposed through connector J4 on the
camera DB.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
Link: https://lore.kernel.org/r/20200911083615.17377-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts b/arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts
index 951820dfdf1c..629fa0819111 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts
@@ -26,6 +26,12 @@
status = "disabled";
};

+&can0 {
+ pinctrl-0 = <&can0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&ether {
pinctrl-0 = <&ether_pins>;
pinctrl-names = "default";
@@ -48,6 +54,11 @@
};

&pfc {
+ can0_pins: can0 {
+ groups = "can0_data_d";
+ function = "can0";
+ };
+
ether_pins: ether {
groups = "eth_mdio", "eth_rmii";
function = "eth";
--
2.17.1


[PATCH 4.4.y-cip 12/14] ARM: dts: r8a7742-iwg21d-q7: Add can1 support to carrier board

Lad Prabhakar
 

commit 68ee7720a01cf20e1de20a2e770b6568db18c253 upstream.

This patch enables CAN1 interface exposed through connector J20 on the
carrier board.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
Link: https://lore.kernel.org/r/20200907155541.2011-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
[PL: Manually applied the changes]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index 728664e901fc..4adcf97ae7c4 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -130,10 +130,26 @@
};
};

+&can1 {
+ pinctrl-0 = <&can1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
&cmt0 {
status = "okay";
};

+&gpio1 {
+ can-trx-en-gpio{
+ gpio-hog;
+ gpios = <28 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "can-trx-en-gpio";
+ };
+};
+
&msiof0 {
pinctrl-0 = <&msiof0_pins>;
pinctrl-names = "default";
@@ -178,6 +194,11 @@
function = "avb";
};

+ can1_pins: can1 {
+ groups = "can1_data_b";
+ function = "can1";
+ };
+
i2c2_pins: i2c2 {
groups = "i2c2_b";
function = "i2c2";
--
2.17.1


[PATCH 4.4.y-cip 11/14] ARM: dts: r8a7742: Add CAN support

Lad Prabhakar
 

commit 5a81ade1dd284a25c25b7582e94e33e5690c3da5 upstream.

Add the definitions for can0 and can1 to the r8a7742 SoC dtsi.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
Link: https://lore.kernel.org/r/20200816190732.6905-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
[PL: dropped resets property. changed clocks and power-domains properties.]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
arch/arm/boot/dts/r8a7742.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index a8ce139e9fc5..af6888521595 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -35,6 +35,14 @@
clock-frequency = <0>;
};

+ /* External CAN clock */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -1106,6 +1114,30 @@
status = "disabled";
};

+ can0: can@e6e80000 {
+ compatible = "renesas,can-r8a7742",
+ "renesas,rcar-gen2-can";
+ reg = <0 0xe6e80000 0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7742_CLK_RCAN0>,
+ <&cpg_clocks R8A7742_CLK_RCAN>, <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ can1: can@e6e88000 {
+ compatible = "renesas,can-r8a7742",
+ "renesas,rcar-gen2-can";
+ reg = <0 0xe6e88000 0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7742_CLK_RCAN1>,
+ <&cpg_clocks R8A7742_CLK_RCAN>, <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
scifb0: serial@e6c20000 {
compatible = "renesas,scifb-r8a7742",
"renesas,scifb";
--
2.17.1

3801 - 3820 of 9599