Date   

Joining CIP from Codethink

Sudip Mukherjee
 

Hi All,

I am starting with CIP and will be trying to do what Ben used to do.
Though many of my colleagues and ex-colleagues have worked with CIP,
this will be my first time directly working with CIP and excited with
the chance to contribute to the super-long-term Linux Kernel.



--
Regards
Sudip


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

Pavel Machek
 

Hi!


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.
This is my fault; thanks for fixing it up and sorry for the confusion.

Best regards,
Pavel

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Lad Prabhakar
Sent: Wednesday, November 4, 2020 8:04 PM
To: Pavel Machek <pavel@denx.de>; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; Biju Das <biju.das.jz@bp.renesas.com>
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@denx.de>
Sent: 04 November 2020 08:29
To: nobuhiro1.iwamatsu@toshiba.co.jp
Cc: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>; cip-dev@lists.cip-project.org; pavel@denx.de;
Biju Das
<biju.das.jz@bp.renesas.com>
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
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[ANNOUNCE] Release v4.19.157-cip38 and v4.4.243-cip51

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.157-cip38 and v4.4.243-cip51.
The linux-4.19.y-cip tree has been updated base version from v4.19.152 to v4.19.157,
and The linux-4.4.y-cip tree has been updated base version from v4.4.238 to v4.4.243.
In addition, the following features have been backported and updated.
linux-4.19.y-cip:
- Added support for SATA and PCIe EP of Renesas r8a774b1.
- Added support for SATA, PCIe EP, rcar-du, PWM and others of Renesas r8a774e1.

linux-4.4.y-cip:
- Added support PCIe, SATA, RTC, QSPI, CAN and others for of Renesas r8a7742.

You can get this release via the git tree at:

v4.19.157-cip38:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
d0a2919cfb81bc30f7def0b39f5cb1e370051f7a
added commits:
CIP: Bump version suffix to -cip38 after merge from stable
arm64: dts: renesas: r8a774e1: Add USB-DMAC and HSUSB device nodes
arm64: dts: renesas: r8a774e1: Add USB3.0 device nodes
arm64: dts: renesas: r8a774e1: Add USB2.0 phy and host (EHCI/OHCI) device nodes
dt-bindings: dma: renesas,usb-dmac: Add binding for r8a774e1
dt-bindings: phy: renesas,usb3-phy: Add r8a774e1 support
dt-bindings: phy: renesas,usb2-phy: Add r8a774e1 support
dt-bindings: sound: renesas, rsnd: Document r8a774e1 bindings
arm64: dts: renesas: Add HiHope RZ/G2H board with idk-1110wr display
arm64: dts: renesas: r8a774e1: Add PWM device nodes
dt-bindings: pwm: renesas,pwm-rcar: Add r8a774e1 support
arm64: dts: renesas: r8a774e1-hihope-rzg2h: Setup DU clocks
arm64: dts: renesas: r8a774e1: Add LVDS device node
drm: rcar-du: lvds: Add support for R8A774E1 SoC
dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
arm64: dts: renesas: r8a774e1: Populate HDMI encoder node
dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
arm64: dts: renesas: r8a774e1: Populate DU device node
drm: rcar-du: Add support for R8A774E1 SoC
dt-bindings: display: renesas,du: Document r8a774e1 bindings
arm64: dts: renesas: r8a774e1: Add FDP1 device nodes
arm64: dts: renesas: r8a774e1: Add VSP instances
arm64: dts: renesas: r8a774e1: Add FCPF and FCPV instances
arm64: dts: renesas: r8a774e1-hihope-rzg2h-ex: Enable sata
misc: pci_endpoint_test: Add Device ID for RZ/G2H PCIe controller
arm64: dts: renesas: r8a774e1: Add PCIe EP nodes
dt-bindings: pci: rcar-pci-ep: Document r8a774e1
arm64: dts: renesas: r8a774e1: Add SATA controller node
arm64: dts: renesas: r8a774e1: Add PCIe device nodes
misc: pci_endpoint_test: Add Device ID for RZ/G2M and RZ/G2N PCIe controllers
arm64: dts: renesas: r8a774b1: Add PCIe EP nodes
arm64: dts: renesas: r8a774a1: Add PCIe EP nodes
arm64: dts: renesas: r8a774c0: Add PCIe EP node
dt-bindings: pci: rcar-pci-ep: Document r8a774a1 and r8a774b1
ata: sata_rcar: Fix DMA boundary mask
arm64: dts: renesas: r8a774b1-hihope-rzg2n-ex: Enable sata
arm64: dts: renesas: r8a774b1: Add SATA controller node
dt-bindings: ata: sata_rcar: Add r8a774b1 support

v4.4.243-cip51:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
c47314d1a4fafc496bb1f62c31f287c88372a4c1
added commits:
CIP: Bump version suffix to -cip51 after merge from stable
ARM: dts: r8a7742: Add IPMMU DT nodes
ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Add can0 support to camera DB
ARM: dts: r8a7742-iwg21d-q7: Add can1 support to carrier board
ARM: dts: r8a7742: Add CAN support
dt-bindings: can: rcar_can: Add r8a7742 support
pinctrl: sh-pfc: r8a7790: Add CAN pins, groups and functions
ARM: dts: r8a7742-iwg21d-q7: Add SPI NOR support
spi: sh-msiof: Implement cs-gpios configuration
spi: sh-msiof: Avoid writing to registers from spi_master.setup()
ARM: dts: r8a7742-iwg21m: Add SPI NOR support
ARM: dts: r8a7742: Add QSPI support
spi: renesas,rspi: Add r8a7742 to the compatible list
ARM: dts: r8a7742-iwg21m: Add RTC support
ARM: dts: r8a7742-iwg21m: Sort the nodes alphabetically
ARM: dts: r8a7742: Add VSP support
ARM: dts: r8a7742: Add SATA nodes
dt-bindings: ata: renesas,rcar-sata: Add r8a7742 support
ata: sata_rcar: Fix DMA boundary mask
ata: sata_rcar: add gen[23] fallback compatibility strings
ARM: dts: r8a7742-iwg21d-q7: Enable PCIe Controller
ARM: dts: r8a7742: Add PCIe Controller device node
dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742

Best regards,
Nobuhiro


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@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Lad Prabhakar
Sent: Wednesday, November 4, 2020 8:04 PM
To: Pavel Machek <pavel@denx.de>; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; Biju Das <biju.das.jz@bp.renesas.com>
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@denx.de>
Sent: 04 November 2020 08:29
To: nobuhiro1.iwamatsu@toshiba.co.jp
Cc: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>; cip-dev@lists.cip-project.org; pavel@denx.de;
Biju Das
<biju.das.jz@bp.renesas.com>
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@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Ben Hutchings
Sent: Wednesday, October 28, 2020 7:17 AM
To: cip-dev@lists.cip-project.org
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@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Ben Hutchings
Sent: Thursday, November 12, 2020 5:50 AM
To: cip-dev@lists.cip-project.org; nobuhiro1.iwamatsu@toshiba.co.jp;
jan.kiszka@siemens.com
Subject: Re: [cip-dev] Backporting of security patches for Intel i40e drivers
required?

On Wed, 2020-11-11 at 13:18 +0000, masashi.kudo@cybertrust.co.jp 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@lists.cip-project.org <cip-dev@lists.cip-project.org> 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@cybertrust.co.jp 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@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Friday, October 9, 2020 4:24 PM
To: nobuhiro1.iwamatsu@toshiba.co.jp; cip-dev@lists.cip-project.org
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@toshiba.co.jp 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@intel.com/

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@lists.cip-project.org
[mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, October 8, 2020 6:43 PM
To: cip-dev@lists.cip-project.org
Cc: jan.kiszka@siemens.com
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@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 10 November 2020 12:17
To: pavel@denx.de
Cc: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>; cip-dev@lists.cip-project.org;
Biju Das <biju.das.jz@bp.renesas.com>
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@denx.de]
Sent: Tuesday, November 10, 2020 4:55 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: prabhakar.mahadev-lad.rj@bp.renesas.com; cip-dev@lists.cip-project.org; pavel@denx.de;
biju.das.jz@bp.renesas.com
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@denx.de]
Sent: Tuesday, November 10, 2020 4:55 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: prabhakar.mahadev-lad.rj@bp.renesas.com; cip-dev@lists.cip-project.org; pavel@denx.de;
biju.das.jz@bp.renesas.com
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@bp.renesas.com]
Sent: Tuesday, November 10, 2020 12:50 AM
To: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
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@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200825141805.27105-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
[PL: Dropped SoC specific compatible string]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
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

2581 - 2600 of 8382