Date   

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

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@...>
---
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@...>
Sent: 24 November 2020 17:58
To: Biju Das <biju.das.jz@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Chris
Paterson <Chris.Paterson2@...>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@...>
Subject: Re: [PATCH] dt-bindings: PCI: rcar: Add device tree support for
r8a7742

Hi!

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

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@...>
Sent: 24 November 2020 17:34
To: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>
Cc: Chris Paterson <Chris.Paterson2@...>; Biju Das
<biju.das.jz@...>; Prabhakar Mahadev Lad <prabhakar.mahadev-
lad.rj@...>
Subject: [PATCH] dt-bindings: PCI: rcar: Add device tree support for
r8a7742

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

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@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>
Acked-by: Rob Herring <robh@...>
Signed-off-by: Biju Das <biju.das.jz@...>
---
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@...>

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

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@...>
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
.../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@...>

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

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@...>
---
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@... <nobuhiro1.iwamatsu@...>
Sent: 25 November 2020 06:48
To: pavel@...; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Biju Das <biju.das.jz@...>
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@...]
Sent: Wednesday, November 25, 2020 4:49 AM
To: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
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


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

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 24 November 2020 19:49
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek
<pavel@...>; Biju Das <biju.das.jz@...>
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?
We only plan to upstream/backport driver, pinctrl and clock atm (consumers needing this feature will have to manually enable the DTS)

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()
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...
Agreed when the fixes hit linux-next I shall post a v3.

Cheers,
Prabhakar

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


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

Quirin Gylstorff
 

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

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@...>
---
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))
--
2.20.1


Re: About corresponding CVE-2020-25669 from CIP kernel config side

Nobuhiro Iwamatsu
 

Hi Jan,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Jan Kiszka
Sent: Thursday, November 19, 2020 4:42 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@...>
Cc: cip-dev@...; wens@...; pavel@...; masashi.kudo@...
Subject: Re: [cip-dev] About corresponding CVE-2020-25669 from CIP kernel config side

On 19.11.20 03:43, nobuhiro1.iwamatsu@... wrote:
Hi Jan,

CVE-2020-25669[0] is a CVE for SUNKBD (sun4/sun5 keyboard), which is
enabled in siemens_i386-rt kernel.

```
$ git grep SUNKBD
4.19.y-cip-rt/x86/siemens_i386-rt.config:# CONFIG_KEYBOARD_SUNKBD is not set
4.19.y-cip/x86/plathome_obsvx2.config:# CONFIG_KEYBOARD_SUNKBD is not set
4.19.y-cip/x86/siemens_iot2000.config:# CONFIG_KEYBOARD_SUNKBD is not set
4.4.y-cip-rt/x86/siemens_i386-rt.config:CONFIG_KEYBOARD_SUNKBD=m
4.4.y-cip/arm/siemens_am57xx-pxm3.config:# CONFIG_KEYBOARD_SUNKBD is not set
4.4.y-cip/arm/siemens_imx6_defconfig:# CONFIG_KEYBOARD_SUNKBD is not set
4.4.y-cip/x86/plathome_obsvx1.config:# CONFIG_KEYBOARD_SUNKBD is not set
4.4.y-cip/x86/siemens_iot2000.config:# CONFIG_KEYBOARD_SUNKBD is not set
```

Is this driver used? If you're not using it, I'd consider removing it from the kernel's
config to support this CVE. Could you give me your opinion on this?
Drop the config switch and ignore the issue - this was very likely an
"over-configuration" due to being derived from some distro config.
OK, I dropped this config.

Best regards,
Nobuhiro


Re: Joining CIP from Codethink

Nobuhiro Iwamatsu
 

Hi Sudip,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Sudip Mukherjee
Sent: Monday, November 16, 2020 10:57 PM
To: cip-dev@...
Subject: [cip-dev] Joining CIP from Codethink

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.
Welcome!!

Best regards,
Nobuhiro


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

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Wednesday, November 25, 2020 4:49 AM
To: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das <biju.das.jz@...>
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.

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.

Best regards,
Nobuhiro


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

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Pavel Machek
Sent: Wednesday, November 25, 2020 4:28 AM
To: Biju Das <biju.das.jz@...>
Cc: Pavel Machek <pavel@...>; cip-dev@...; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Chris Paterson <Chris.Paterson2@...>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@...>
Subject: Re: [cip-dev] [PATCH] dt-bindings: PCI: rcar: Add device tree support for r8a7742

Hi!

Thanks for the feedback.
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>

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.
Aha. Sorry for the noise. I'll apply it if there are no other
comments.
I don't see any problems with this patch. I applied and pushed.

Best regards,
Nobuhiro


Re: [PATCH 4.4.y-cip 0/9] Add USB[2.0|3.0] support

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Pavel Machek [mailto:pavel@...]
Sent: Wednesday, November 25, 2020 4:05 AM
To: Biju Das <biju.das.jz@...>
Cc: cip-dev@...; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Chris Paterson <chris.paterson2@...>;
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Subject: Re: [PATCH 4.4.y-cip 0/9] Add USB[2.0|3.0] support

Hi!

This patch series aims to add USB2.0/USB3.0 support for iWave
RZ/G1H platform.

All the patches in this series are cherrypicked from mainline and
it is based linux-4.4.y-cip.
Series looks okay to me. If there are no other comments, I can apply
it.
Looks good to me too, I applied and pushed this series.

Best regards,
Nobuhiro


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

Pavel Machek
 

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()
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...

Best regards,
Pavel
--
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

Pavel Machek
 

Hi!

Thanks for the feedback.
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>

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.
Aha. Sorry for the noise. I'll apply it if there are no other
comments.

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


Re: [PATCH 4.4.y-cip 0/9] Add USB[2.0|3.0] support

Pavel Machek
 

Hi!

This patch series aims to add USB2.0/USB3.0 support for iWave
RZ/G1H platform.

All the patches in this series are cherrypicked from mainline and
it is based linux-4.4.y-cip.
Series looks okay to me. If there are no other comments, I can apply
it.

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


Re: A lot of compiles failing

Sudip Mukherjee
 

Hi Pavel,

On 24/11/2020 18:44, Pavel Machek wrote:
Hi!

This is going on for a few days now, but today it seems worse than
usual:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/220169843

builds are failing, 'HTTP 500 curl 22' error, so not a real build
problem. I can probably just click restart... 6 times. But something
is not there, and it is getting worse.
Today I got new one....

Waiting for pod gitlab/runner-bcrayztp-project-2678032-concurrent-392fb6 to be running, status is Pending
217Running on runner-bcrayztp-project-2678032-concurrent-392fb6 via cip-project-v3-gitlab-runner-6dbd79945f-wdqqw...
219
Fetching changes with git depth set to 10...
00:35
220Initialized empty Git repository in /builds/cip-project/cip-kernel/linux-cip/.git/
221Created fresh repository.
222error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
223fatal: the remote end hung up unexpectedly
224fatal: early EOF
225fatal: index-pack failed
227
Uploading artifacts.

I wonder... Is each of our workers pulling full copy of kernel from
gitlab?

If so, I understand that gitlab might be a bit unhappy. We probably
should populate the initial version from our servers (or from
kernel.org), or maybe include copy of recent linux directly into
machine images... to reduce load on gitlab.
Maybe you can consider using git depth of 1.


--
Regards
Sudip

3761 - 3780 of 9641