Date   

[PATCH 4.4.y-cip 02/11] dt-bindings: arm: renesas: Convert 'renesas,prr' to json-schema

Lad Prabhakar
 

From: Simon Horman <horms+renesas@verge.net.au>

commit 09f156d97e530c2ac631620f7b29508ff5cc4e6f upstream.

Convert Renesas Product Register bindings documentation to json-schema.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20190908120528.9392-1-horms+renesas@verge.net.au
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[PL: Initially in upstream commit 5384f45cd9714287f198771bfb057eda799af9a8
("ARM: shmobile: Document DT bindings for Product Register" added DT
documentation later this was moved into separate file (renesas,prr.txt) in
commit 74791d15fd7c405511e3cc097c2f043171ecbdb0 ("dt-bindings: arm:
renesas: Move 'renesas,prr' binding to its own doc") and finally this was
converted into json-schema so using the same commit to backport]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
.../devicetree/bindings/arm/renesas,prr.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.yaml

diff --git a/Documentation/devicetree/bindings/arm/renesas,prr.yaml b/Documentation/devicetree/bindings/arm/renesas,prr.yaml
new file mode 100644
index 000000000000..1f80767da38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/renesas,prr.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/renesas,prr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Product Register
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+ - Magnus Damm <magnus.damm@gmail.com>
+
+description: |
+ Most Renesas ARM SoCs have a Product Register or Boundary Scan ID
+ Register that allows to retrieve SoC product and revision information.
+ If present, a device node for this register should be added.
+
+properties:
+ compatible:
+ enum:
+ - renesas,prr
+ - renesas,bsid
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ prr: chipid@ff000044 {
+ compatible = "renesas,prr";
+ reg = <0xff000044 4>;
+ };
--
2.17.1


[PATCH 4.4.y-cip 01/11] base: soc: Early register bus when needed

Lad Prabhakar
 

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

commit 1da1b3628df34a2a5e38b70c8551770aadce969d upstream.

If soc_device_register() is called before soc_bus_register(), it crashes
with a NULL pointer dereference.

soc_bus_register() is already a core_initcall(), but drivers/base/ is
entered later than e.g. drivers/pinctrl/ and drivers/soc/. Hence there
are several subsystems that may need to know SoC revision information,
while it's not so easy to initialize the SoC bus even earlier using an
initcall.

To fix this, let soc_device_register() register the bus early if that
hasn't happened yet.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/base/soc.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 84242e6b2897..c9fd0ee2ba50 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -114,6 +114,12 @@ struct soc_device *soc_device_register(struct soc_device_attribute *soc_dev_attr
struct soc_device *soc_dev;
int ret;

+ if (!soc_bus_type.p) {
+ ret = bus_register(&soc_bus_type);
+ if (ret)
+ goto out1;
+ }
+
soc_dev = kzalloc(sizeof(*soc_dev), GFP_KERNEL);
if (!soc_dev) {
ret = -ENOMEM;
@@ -159,6 +165,9 @@ EXPORT_SYMBOL_GPL(soc_device_unregister);

static int __init soc_bus_register(void)
{
+ if (soc_bus_type.p)
+ return 0;
+
return bus_register(&soc_bus_type);
}
core_initcall(soc_bus_register);
--
2.17.1


[PATCH 4.4.y-cip 00/11] Renesas RZ/G1x add SoC detection support

Lad Prabhakar
 

Hi All,

This patch series adds SoC detection support for Renesas RZ/G1x SoC's.

All the patches apart from {7, 9, 11}/11 have been cherry picked from
Linux v5.10-rc6

Cheers,
Prabhakar

Biju Das (1):
soc: renesas: Identify RZ/G1C

Geert Uytterhoeven (6):
base: soc: Early register bus when needed
soc: renesas: Identify SoC and register with the SoC bus
ARM: dts: r8a7743: Add device node for PRR
ARM: dts: r8a7745: Add device node for PRR
soc: renesas: Identify RZ/G1N
soc: renesas: Identify RZ/G1H

Lad Prabhakar (3):
ARM: dts: r8a7744: Add device node for PRR
ARM: dts: r8a7742: Add device node for PRR
ARM: dts: r8a77470: Add device node for PRR

Simon Horman (1):
dt-bindings: arm: renesas: Convert 'renesas,prr' to json-schema

.../devicetree/bindings/arm/renesas,prr.yaml | 37 +++++
arch/arm/boot/dts/r8a7742.dtsi | 5 +
arch/arm/boot/dts/r8a7743.dtsi | 5 +
arch/arm/boot/dts/r8a7744.dtsi | 5 +
arch/arm/boot/dts/r8a7745.dtsi | 5 +
arch/arm/boot/dts/r8a77470.dtsi | 5 +
arch/arm/mach-shmobile/Kconfig | 5 +
drivers/base/soc.c | 9 ++
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 147 ++++++++++++++++++
10 files changed, 225 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.yaml
create mode 100644 drivers/soc/renesas/renesas-soc.c

--
2.17.1


Cip-kernel-sec Updates for Week of 2020-11-26

Chen-Yu Tsai <wens213@...>
 

Hi everyone,

This week we have six new issues:

- CVE-2020-15436 [blockdev UAF] - Fixed in all stable kernels

- CVE-2020-15437 [serial/8250 NULL pointer dereference] -
Fixed in all stable kernels

- CVE-2020-27777 [powerpc/rtas usage check] - Fix backported to 4.14+

Since no member requires ppc support, we can ignore this.
Though if anyone wishes to look into this, this might require backporting
to 4.4 and 4.9.

- CVE-2020-28915 [fbcon_get_font() global-out-of-bounds] -
Fixed in all stable kernels

- CVE-2020-28941 [accessibility/speakup] - Fixed in relevant stable kernels

- CVE-2020-4788 [powerpc/power9 speculation] - Fixed in 4.9, 4.19, and mainline

The stable commits were imported from Debian, which only tracks 4.9 and 4.19.
4.9 requires one less commit compared to 4.19 and mainline. I suspect 4.14
and 5.4 might also contain the fixes, but manual matching would be required.


Regarding old issues:

CVE-2020-27673 is fixed for 4.9 with one less commit than mainline, due to
a feature introduced later. I suspect 4.4 might be the same, but this will
require some manual matching.

CVE-2019-12881 marked as fixed for all stable kernels.

CVE-2020-slab-out-of-bounds-read-fbcon is now CVE-2020-28974.


Regards
ChenYu


[ANNOUNCE] v4.19.160-cip39-rt17

Pavel Machek
 


Re: [PATCH 4.19.y-cip] arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels

Pavel Machek
 

Hi!

Looks good to me, I can apply it if there are no other comments.

(I note you switched from dmac1 + dmac2 to dma_0_ only. I believe you
double checked that's okay, but I wonder how it worked before the
patch?)
Yes I have cross checked this information. Luckily MSIOF1 wasn't populated on the dev board.
Aha, MSIOF1 not being on dev board explains things.

Applied and pushed out.

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


[ANNOUNCE] Release v4.19.160-cip39

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.160-cip39.
The linux-4.19.y-cip tree has been updated base version from v4.19.157
to v4.19.160, and r8a774e1 audio support patch has been backported.

You can get this release via the git tree at:

v4.19.160-cip39:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
53ba31d44bf6ff0a915b472797ec1af07b663751
added commits:
CIP: Bump version suffix to -cip39 after merge from stable
arm64: dts: renesas: r8a774e1: Add audio support
arm64: dts: renesas: r8a774e1: Add missing audio_clk_b

Best regards,
Nobuhiro


Re: [PATCH 4.19.y-cip] arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 26 November 2020 17:12
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>; Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip] arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels

Hi!

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

commit c91dfc9818df5f43c10c727f1cecaebdb5e2fa92 upstream.

According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be
used with SYS-DMAC0 on R-Car E3.
Looks good to me, I can apply it if there are no other comments.

(I note you switched from dmac1 + dmac2 to dma_0_ only. I believe you
double checked that's okay, but I wonder how it worked before the
patch?)
Yes I have cross checked this information. Luckily MSIOF1 wasn't populated on the dev board.

Cheers,
Prabhakar

Best regards,
Pavel

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


Re: [PATCH 4.19.y-cip] arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels

Pavel Machek
 

Hi!

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

commit c91dfc9818df5f43c10c727f1cecaebdb5e2fa92 upstream.

According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be
used with SYS-DMAC0 on R-Car E3.
Looks good to me, I can apply it if there are no other comments.

(I note you switched from dmac1 + dmac2 to dma_0_ only. I believe you
double checked that's okay, but I wonder how it worked before the
patch?)

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] arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels

Lad Prabhakar
 

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

commit c91dfc9818df5f43c10c727f1cecaebdb5e2fa92 upstream.

According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be
used with SYS-DMAC0 on R-Car E3.

Fixes: 62c0056f1c3eb15d ("arm64: dts: renesas: r8a774c0: Add MSIOF nodes")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200917132117.8515-3-geert+renesas@glider.be
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Patch has been cherry picked from v5.10-rc5.
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 44d66fcb412d..4785c486b336 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1214,9 +1214,8 @@
reg = <0 0xe6ea0000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 210>;
- dmas = <&dmac1 0x43>, <&dmac1 0x42>,
- <&dmac2 0x43>, <&dmac2 0x42>;
- dma-names = "tx", "rx", "tx", "rx";
+ dmas = <&dmac0 0x43>, <&dmac0 0x42>;
+ dma-names = "tx", "rx";
power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>;
resets = <&cpg 210>;
#address-cells = <1>;
--
2.17.1


Cip-kernel-sec Updates for Week of 2020-11-26

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

(Resent from correct email address.)

Hi everyone,

This week we have six new issues:

- CVE-2020-15436 [blockdev UAF] - Fixed in all stable kernels

- CVE-2020-15437 [serial/8250 NULL pointer dereference] -
Fixed in all stable kernels

- CVE-2020-27777 [powerpc/rtas usage check] - Fix backported to 4.14+

Since no member requires ppc support, we can ignore this.
Though if anyone wishes to look into this, this might require backporting
to 4.4 and 4.9.

- CVE-2020-28915 [fbcon_get_font() global-out-of-bounds] -
Fixed in all stable kernels

- CVE-2020-28941 [accessibility/speakup] - Fixed in relevant stable kernels

- CVE-2020-4788 [powerpc/power9 speculation] - Fixed in 4.9, 4.19, and mainline

The stable commits were imported from Debian, which only tracks 4.9 and 4.19.
4.9 requires one less commit compared to 4.19 and mainline. I suspect 4.14
and 5.4 might also contain the fixes, but manual matching would be required.


Regarding old issues:

CVE-2020-27673 is fixed for 4.9 with one less commit than mainline, due to
a feature introduced later. I suspect 4.4 might be the same, but this will
require some manual matching.

CVE-2019-12881 marked as fixed for all stable kernels.

CVE-2020-slab-out-of-bounds-read-fbcon is now CVE-2020-28974.


Regards
ChenYu
Moxa


Re: [isar-cip-core][PATCH v2] classes/image_uuid: Generate new uuid if a new package is added

Jan Kiszka
 

On 25.11.20 09:44, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

BB_BASEHASH only includes the task itself and its metadata.
Dependencies are not taken into account when this hash is
generated which means updating a package will not generate a new
UUID.

BB_TASKHASH takes the changes into account.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/image_uuid.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index d5337b8..2813ed9 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -12,7 +12,7 @@
def generate_image_uuid(d):
import uuid

- base_hash = d.getVar("BB_BASEHASH_task-do_rootfs_install", True)
+ base_hash = d.getVar("BB_TASKHASH", True)
if base_hash is None:
return None
return str(uuid.UUID(base_hash[:32], version=4))
Thanks, applied.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


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=26&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-19-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether SUNKBD is still used or not wrt CVE-2020-25669 - iwamatsu

* 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: [PATCH] dt-bindings: PCI: rcar: Add device tree support for r8a7742

Biju Das <biju.das.jz@...>
 

Hi Pavel,

Thanks for the feedback.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 24 November 2020 17:58
To: Biju Das <biju.das.jz@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>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH] dt-bindings: PCI: rcar: Add device tree support for
r8a7742

Hi!

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

commit d16d538ff49145b153976bd8e124116d369db266 upstream.

Add support for r8a7742. The Renesas RZ/G1H (R8A7742) PCIe controller
is identical to the R-Car Gen2 family.

Sure, we can apply this (I assume it is for 4.4)? But it will not really
add any support, it just documents the binding... so I assume this should
go into series with patches that actually change the dts (and probably
tweak the drivers)?
We have already backported PCIEC[1] to Linux-4.4.y-cip. Only dt binding patch was pending.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/commit/arch/arm/boot/dts/r8a7742.dtsi?h=linux-4.4.y-cip&id=f7305b488be9e3048f0ee30bb7a83d6041728d7f

Regards,
Biju


Best regards,
Pavel

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index bedfdc122543..8a3d8b5be515 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -1,7 +1,8 @@
* Renesas R-Car PCIe interface

Required properties:
-compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC;
+compatible: "renesas,pcie-r8a7742" for the R8A7742 SoC;
+ "renesas,pcie-r8a7743" for the R8A7743 SoC;
"renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7790" for the R8A7790 SoC;
"renesas,pcie-r8a7791" for the R8A7791 SoC;
--
2.17.1
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH] dt-bindings: PCI: rcar: Add device tree support for r8a7742

Biju Das <biju.das.jz@...>
 

Hi Pavel, Nobuhiro,

Please ignore this patch for Linux-4.4.y-cip. I have send another patch fixing tab between commit and commit id
in the patch description.

Regards,
Biju

-----Original Message-----
From: Biju Das <biju.das.jz@bp.renesas.com>
Sent: 24 November 2020 17:34
To: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Chris Paterson <Chris.Paterson2@renesas.com>; Biju Das
<biju.das.jz@bp.renesas.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-
lad.rj@bp.renesas.com>
Subject: [PATCH] dt-bindings: PCI: rcar: Add device tree support for
r8a7742

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

commit d16d538ff49145b153976bd8e124116d369db266 upstream.

Add support for r8a7742. The Renesas RZ/G1H (R8A7742) PCIe controller is
identical to the R-Car Gen2 family.

Link:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ker
nel.org%2Fr%2F20200810174156.30880-2-prabhakar.mahadev-
lad.rj%40bp.renesas.com&amp;data=04%7C01%7Cbiju.das.jz%40bp.renesas.com%7C
3d34a2122cbd4154baf708d8909f2fab%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C
0%7C637418360659367751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9BWyqx81fEYB0IMcK
8nJz2xG1WLwRJG5lAE4FXVMBFo%3D&amp;reserved=0
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/pci/rcar-pci.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index bedfdc122543..8a3d8b5be515 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -1,7 +1,8 @@
* Renesas R-Car PCIe interface

Required properties:
-compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC;
+compatible: "renesas,pcie-r8a7742" for the R8A7742 SoC;
+ "renesas,pcie-r8a7743" for the R8A7743 SoC;
"renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7790" for the R8A7790 SoC;
"renesas,pcie-r8a7791" for the R8A7791 SoC;
--
2.17.1


Re: [isar-cip-core][PATCH] classes/image_uuid: Generate new uuid if a new package is added

Quirin Gylstorff
 

On 9/18/20 2:21 PM, Jan Kiszka wrote:
On 18.09.20 10:04, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

BB_BASEHASH only includes the task itself and its metadata.
Dependencies are not taken into account when this hash is
generated which means updating a package will not generate a new
UUID.

BB_TASKHASH takes the changes into account.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
  classes/image_uuid.bbclass | 20 ++++++++++----------
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/classes/image_uuid.bbclass b/classes/image_uuid.bbclass
index d5337b8..873abc5 100644
--- a/classes/image_uuid.bbclass
+++ b/classes/image_uuid.bbclass
@@ -9,23 +9,23 @@
  # SPDX-License-Identifier: MIT
  #
-def generate_image_uuid(d):
-    import uuid
+IMAGE_UUID ?= "random"
Why not using an undefined or empty IMAGE_UUID as "generate me one" indication?
I will try to use the previous version after testing it has the same effect as this patch.


-    base_hash = d.getVar("BB_BASEHASH_task-do_rootfs_install", True)
-    if base_hash is None:
-        return None
-    return str(uuid.UUID(base_hash[:32], version=4))
-
-IMAGE_UUID ?= "${@generate_image_uuid(d)}"
+IMAGE_UUID_NAMESPACE = "6090f47e-b068-475c-b125-7be7c24cdd4e"
Is that namespace random, or does that have specific meaning?
The namespace is random.

  do_generate_image_uuid[vardeps] += "IMAGE_UUID"
  do_generate_image_uuid[depends] = "buildchroot-target:do_build"
+IMAGER_INSTALL += "uuid-runtime"
Please separate variable for job definitions be a blank line. Also the job specifications above should be visually separated from the code below that way. IOW:
IMAGER_INSTALL += "uuid-runtime"
do_generate_image_uuid[vardeps] += "IMAGE_UUID"
do_generate_image_uuid[depends] = "buildchroot-target:do_build"
do_generate_image_uuid() {
Replace with a sipmler version in v2.

  do_generate_image_uuid() {
+    image_do_mounts
+    if [ "${IMAGE_UUID}" != "random" ]; then
+        IMAGE_UUID_FINAL="${IMAGE_UUID}"
+    else
+        IMAGE_UUID_FINAL="$(sudo -E chroot ${BUILDCHROOT_DIR} uuidgen -s -n "${IMAGE_UUID_NAMESPACE}" -N "${BB_TASKHASH}")"
Why do we need to switch to uuidgen from the buildchroot, rather than using python's uuid?
And what ensures that uuidgen is available there?
I switch back to python to avoid unnecassary package installations.
See v2.


+    fi
      sudo sed -i '/^IMAGE_UUID=.*/d' '${IMAGE_ROOTFS}/etc/os-release'
-    echo "IMAGE_UUID=\"${IMAGE_UUID}\"" | \
+    echo "IMAGE_UUID=\"${IMAGE_UUID_FINAL}\"" | \
          sudo tee -a '${IMAGE_ROOTFS}/etc/os-release'
-    image_do_mounts
      # update initramfs to add uuid
      sudo chroot '${IMAGE_ROOTFS}' update-initramfs -u
Jan
Quirin


[isar-cip-core][PATCH 2/2] Secureboot: Wait until udev populates /dev

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

In actual physical targets like ipc227e, with the current initramfs
local file, the system drops to initramfs shell during boot.

This is due to "blkid -o device" returning empty list since the udev
has not yet created the necessary entries in /dev.

Add a timeout to reattempt finding a valid partition before giving up.

Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
.../files/secure-boot-debian-local-patch | 104 +++++++++++-------
1 file changed, 64 insertions(+), 40 deletions(-)

diff --git a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
index 219578c..cd2d271 100644
--- a/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
+++ b/recipes-support/initramfs-config/files/secure-boot-debian-local-patch
@@ -1,79 +1,103 @@
---- local 2020-07-02 14:59:15.461895194 +0200
-+++ ../../../../../../../../../../../recipes-support/initramfs-config/files/local 2020-07-02 14:58:58.405730914 +0200
+--- local.orig 2020-11-18 14:42:43.540055680 +0530
++++ local 2020-11-18 20:15:48.687164540 +0530
@@ -1,5 +1,4 @@
# Local filesystem mounting -*- shell-script -*-
-
local_top()
{
if [ "${local_top_used}" != "yes" ]; then
-@@ -155,34 +154,47 @@
- local_mount_root()
+@@ -152,36 +151,70 @@
+ DEV="${real_dev}"
+ }
+
+-local_mount_root()
++local_find_by_uuid()
{
- local_top
+- local_top
- if [ -z "${ROOT}" ]; then
- panic "No root device specified. Boot arguments must include a root= parameter."
- fi
- local_device_setup "${ROOT}" "root file system"
- ROOT="${DEV}"
--
++ partitions="$1"
+
- # Get the root filesystem type if not set
- if [ -z "${ROOTFSTYPE}" ] || [ "${ROOTFSTYPE}" = auto ]; then
- FSTYPE=$(get_fstype "${ROOT}")
- else
- FSTYPE=${ROOTFSTYPE}
-+ if [ ! -e /conf/image_uuid ]; then
-+ panic "could not find image_uuid to select correct root file system"
- fi
-+ local INITRAMFS_IMAGE_UUID=$(cat /conf/image_uuid)
-+ local partitions=$(blkid -o device)
+- fi
+ for part in $partitions; do
-+ if [ "$(blkid -p ${part} --match-types novfat -s USAGE -o value)" = "filesystem" ]; then
-+ local_device_setup "${part}" "root file system"
-+ ROOT="${DEV}"
++ if [ "$(blkid -p ${part} --match-types novfat -s USAGE -o value)" = "filesystem" ]; then
++ local_device_setup "${part}" "root file system"
++ ROOT="${DEV}"
+
-+ # Get the root filesystem type if not set
-+ if [ -z "${ROOTFSTYPE}" ] || [ "${ROOTFSTYPE}" = auto ]; then
-+ FSTYPE=$(get_fstype "${ROOT}")
-+ else
-+ FSTYPE=${ROOTFSTYPE}
-+ fi
++ # Get the root filesystem type if not set
++ if [ -z "${ROOTFSTYPE}" ] || [ "${ROOTFSTYPE}" = auto ]; then
++ FSTYPE=$(get_fstype "${ROOT}")
++ else
++ FSTYPE=${ROOTFSTYPE}
++ fi

- local_premount
-+ local_premount
++ local_premount

- if [ "${readonly?}" = "y" ]; then
- roflag=-r
- else
- roflag=-w
- fi
-+ if [ "${readonly?}" = "y" ]; then
-+ roflag=-r
-+ else
-+ roflag=-w
-+ fi
-+ checkfs "${ROOT}" root "${FSTYPE}"
++ if [ "${readonly?}" = "y" ]; then
++ roflag=-r
++ else
++ roflag=-w
++ fi
++ checkfs "${ROOT}" root "${FSTYPE}"

- checkfs "${ROOT}" root "${FSTYPE}"
-+ # Mount root
-+ # shellcheck disable=SC2086
-+ if mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
-+ if [ -e "${rootmnt?}"/etc/os-release ]; then
-+ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/os-release | tr -d '"' )
-+ if [ "${INITRAMFS_IMAGE_UUID}" = "${image_uuid}" ]; then
-+ return
-+ fi
-+ fi
-+ umount "${rootmnt?}"
++ # Mount root
++ # shellcheck disable=SC2086
++ if mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
++ if [ -e "${rootmnt?}"/etc/os-release ]; then
++ image_uuid=$(sed -n 's/^IMAGE_UUID=//p' "${rootmnt?}"/etc/os-release | tr -d '"' )
++ if [ "${INITRAMFS_IMAGE_UUID}" = "${image_uuid}" ]; then
++ return 0
++ fi
+ fi
++ umount "${rootmnt?}"
+ fi
++ fi
+ done
-+ panic "Could not find ROOTFS with matching UUID $INITRAMFS_IMAGE_UUID"
++ return 1
++}

- # Mount root
- # shellcheck disable=SC2086
- if ! mount ${roflag} ${FSTYPE:+-t "${FSTYPE}"} ${ROOTFLAGS} "${ROOT}" "${rootmnt?}"; then
- panic "Failed to mount ${ROOT} as root file system."
-- fi
++local_mount_root()
++{
++ local_top
++ if [ ! -e /conf/image_uuid ]; then
++ panic "could not find image_uuid to select correct root file system"
++ fi
++ local INITRAMFS_IMAGE_UUID=$(cat /conf/image_uuid)
++ local partitions=""
++ local ret=1
++ local timeout_uuid=0
++ while [ "${ret}" != 0 ] && [ "${timeout_uuid}" -le 10 ]; do
++ wait_for_udev 10
++ partitions=$(blkid -o device)
++ local_find_by_uuid "$partitions"
++ ret=$?
++ timeout_uuid="$(cat /proc/uptime)"
++ timeout_uuid="${timeout_uuid%%[. ]*}"
++ timeout_uuid=$((timeout_uuid - local_top_time))
++ done
++ if [ "${ret}" != 0 ]; then
++ panic "Could not find ROOTFS with matching UUID $INITRAMFS_IMAGE_UUID"
++ else
++ return $ret
+ fi
}

- local_mount_fs()
--
2.20.1


[isar-cip-core][PATCH 0/2] Secureboot fixes

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

Adapt OVMF binaries to new upstream names.
Repeat scan for rootfs until udev finished populating /dev or a timeout occurs.
Build at:
https://gitlab.com/Quirin.Gy/isar-cip-core/-/pipelines/220660576

Quirin Gylstorff (2):
start-qemu.sh: Change OVMF binary names
Secureboot: Wait until udev populates /dev

doc/README.secureboot.md | 12 +-
.../files/secure-boot-debian-local-patch | 104 +++++++++++-------
start-qemu.sh | 4 +-
3 files changed, 72 insertions(+), 48 deletions(-)

--
2.20.1


[isar-cip-core][PATCH 1/2] start-qemu.sh: Change OVMF binary names

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

Upstream changed the names of the OVMF binaries as
```
The existing 2MB images no longer have sufficient variable space for the
current Secure Boot Forbidden Signature Database.
```

Reference:
https://salsa.debian.org/qemu-team/edk2/-/commit/72d8cee9648dd79852ea976e6a8eac0727c27b7f
https://salsa.debian.org/qemu-team/edk2/-/commit/27f786b5fdd126b09c4e732429cc8a30191b72e6

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
doc/README.secureboot.md | 12 ++++++------
start-qemu.sh | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/README.secureboot.md b/doc/README.secureboot.md
index d79248b..4c4ab41 100644
--- a/doc/README.secureboot.md
+++ b/doc/README.secureboot.md
@@ -78,8 +78,8 @@ Set up a secure boot test environment with [QEMU](https://www.qemu.org/)

### Debian Snakeoil keys

-The build copies the Debian Snakeoil keys to the directory `./build/tmp/deploy/images/<machine>/OVMF. Y
-u can use them as described in section [Start Image](### Start the image).
+The build copies the Debian Snakeoil keys to the directory `./build/tmp/deploy/images/<machine>/OVMF.
+You can use them as described in section [Start Image](### Start the image).

### Generate Keys

@@ -112,8 +112,8 @@ mkdir secureboot-tools
cp -r keys secureboot-tools
cp /lib/efitools/x86_64-linux-gnu/KeyTool.efi secureboot-tools
```
-2. Copy the file OVMF_VARS.fd (in Debian the file can be found at /usr/share/OVMF/OVMF_VARS.fd)
-to the current directory. OVMF_VARS.fd contains no keys can be instrumented for secureboot.
+2. Copy the file OVMF_VARS_4M.fd (in Debian the file can be found at /usr/share/OVMF/OVMF_VARS_4M.fd)
+to the current directory. OVMF_VARS_4M.fd contains no keys can be instrumented for secureboot.
3. Start QEMU with the script scripts/start-efishell.sh
```
scripts/start-efishell.sh secureboot-tools
@@ -172,7 +172,7 @@ SECURE_BOOT=y \
./start-qemu.sh amd64
```

-The default `OVMF_VARS.snakeoil.fd` boot to the EFI shell. To boot Linux enter the following command:
+The default `OVMF_VARS.snakeoil_4M.fd` boot to the EFI shell. To boot Linux enter the following command:
```
FS0:\EFI\BOOT\bootx64.efi
```
@@ -182,7 +182,7 @@ To change the boot behavior, enter `exit` in the shell to enter the bios and cha
Start the image with the following command:
```
SECURE_BOOT=y \
-OVMF_CODE=./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_CODE.secboot.fd \
+OVMF_CODE=./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_CODE_4M.secboot.fd \
OVMF_VARS=<path to the modified OVMF_VARS.fd> \
./start-qemu.sh amd64
```
diff --git a/start-qemu.sh b/start-qemu.sh
index e53cd99..6592ac6 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -94,8 +94,8 @@ fi
shift 1

if [ -n "${SECURE_BOOT}" ]; then
- ovmf_code=${OVMF_CODE:-./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_CODE.secboot.fd}
- ovmf_vars=${OVMF_VARS:-./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_VARS.snakeoil.fd}
+ ovmf_code=${OVMF_CODE:-./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_CODE_4M.secboot.fd}
+ ovmf_vars=${OVMF_VARS:-./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_VARS_4M.snakeoil.fd}
QEMU_EXTRA_ARGS=" ${QEMU_EXTRA_ARGS} \
-global ICH9-LPC.disable_s3=1 \
-global isa-fdc.driveA= "
--
2.20.1


Re: [PATCH v2 4.19.y-cip 0/7] Add RPC-IF driver for RZ/G2x SoC's

Lad Prabhakar
 

Hi Nobuhiro,

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 25 November 2020 06:48
To: pavel@denx.de; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Biju Das <biju.das.jz@bp.renesas.com>
Subject: RE: [PATCH v2 4.19.y-cip 0/7] Add RPC-IF driver for RZ/G2x SoC's

Hi,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Wednesday, November 25, 2020 4:49 AM
To: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Biju Das
<biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH v2 4.19.y-cip 0/7] Add RPC-IF driver for RZ/G2x SoC's

Hi!

This patch series adds SPI driver for the Renesas RPC-IF.
Alongside relevant changes for spi-mem have been also
backported. This enables accessing SPI flash chip connected
to RPC-IF on RZ/G2x boards.

We currently only aim to backport just the driver hence there
are no changes to dts/i files. The driver has been tested on
RZ/G2{EM} with all the required dts/i changes [1].
Okay, that was quick.

What is your plan, merge dts changes soon? Or is the driver useful
even without the dts changes?

Changes for v2:
* Patches {1, 3, 4}/7 unchanged
* Patch 2/7
* Fixed reference leak for OF node in rpcif_probe()
* Fixed overwriting return value in error path of rpcif_manual_xfer()
* Replaced C++ style comment with C style
* Replaced tab with a space between struct and struct name
* Fixed a typo in commit message (s/absract/abstract)
* Patch 5/7
* Fixed reference leak in spi_mem_access_start for PM
* Patch 6/7
* Return early in spi_mem_dirmap_dirmap_{read/write}
* Patch 7/7
* Replaced C++ style comment with C style
* Used __maybe_unused for rpcif_spi_{suspend,resume} and dropped
CONFIG_PM_SLEEP ifdef checks
* Elaborated the description for SPI_RPCIF config
* Dropped the label err_put_ctlr from rpc_spi_probe()
I don't see any problems with this series.
Thank you for the review.

Thanks for the changes; they are probably good (I have yet to take
close look), but I wonder if we should wait until they hit next or
mainline? If upstream maintainer disagrees, we would get divergence...
These patch series contain fixes for issues in the patch itself, so we need to
separate them and post them mainline or subsystem tree.
So I think we have to wait for those patches to be merged.
Agreed will repost the series once the fixes hit linux-next.

Cheers,
Prabhakar

Best regards,
Nobuhiro

2521 - 2540 of 8412