Date   

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


Re: A lot of compiles failing

Pavel Machek
 

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.

Best regards,
Pavel

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


[PATCH v2 4.19.y-cip 7/7] spi: add Renesas RPC-IF driver

Lad Prabhakar
 

From: Sergei Shtylyov <sergei.shtylyov@...>

commit eb8d6d464a27850498dced21a8450e85d4a02009 upstream.

Add the SPI driver for the Renesas RPC-IF. It's the "front end" driver
using the "back end" APIs in the main driver to talk to the real hardware.
We only implement the 'spi-mem' interface -- there's no need to implement
the usual SPI driver methods...

Based on the original patch by Mason Yang <masonccyang@...>.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...>
Link: https://lore.kernel.org/r/1ece0e6c-71af-f0f1-709e-571f4b0b4853@cogentembedded.com
Signed-off-by: Mark Brown <broonie@...>
[PL: 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()]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/spi/Kconfig | 8 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-rpc-if.c | 208 +++++++++++++++++++++++++++++++++++++++
3 files changed, 217 insertions(+)
create mode 100644 drivers/spi/spi-rpc-if.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 0a7fd56c1ed9..dcb29af85ffc 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -514,6 +514,14 @@ config SPI_RB4XX
help
SPI controller driver for the Mikrotik RB4xx series boards.

+config SPI_RPCIF
+ tristate "Renesas RPC-IF SPI driver"
+ depends on RENESAS_RPCIF
+ help
+ SPI driver for Renesas R-Car Gen3 RPC-IF (Reduced
+ Pin Count Interface). This enables access to SPI flash or
+ HyperFlash connected to the SoC.
+
config SPI_RSPI
tristate "Renesas RSPI/QSPI controller"
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index a90d55970036..e0b5478fde62 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_SPI_PXA2XX_PCI) += spi-pxa2xx-pci.o
obj-$(CONFIG_SPI_QUP) += spi-qup.o
obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o
obj-$(CONFIG_SPI_RB4XX) += spi-rb4xx.o
+obj-$(CONFIG_SPI_RPCIF) += spi-rpc-if.o
obj-$(CONFIG_SPI_RSPI) += spi-rspi.o
obj-$(CONFIG_SPI_S3C24XX) += spi-s3c24xx-hw.o
spi-s3c24xx-hw-y := spi-s3c24xx.o
diff --git a/drivers/spi/spi-rpc-if.c b/drivers/spi/spi-rpc-if.c
new file mode 100644
index 000000000000..7934b6042d74
--- /dev/null
+++ b/drivers/spi/spi-rpc-if.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPC-IF SPI/QSPI/Octa driver
+ *
+ * Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
+ * Copyright (C) 2019 Macronix International Co., Ltd.
+ * Copyright (C) 2019 - 2020 Cogent Embedded, Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi-mem.h>
+
+#include <memory/renesas-rpc-if.h>
+
+#include <asm/unaligned.h>
+
+static void rpcif_spi_mem_prepare(struct spi_device *spi_dev,
+ const struct spi_mem_op *spi_op,
+ u64 *offs, size_t *len)
+{
+ struct rpcif *rpc = spi_controller_get_devdata(spi_dev->controller);
+ struct rpcif_op rpc_op = { };
+
+ rpc_op.cmd.opcode = spi_op->cmd.opcode;
+ rpc_op.cmd.buswidth = spi_op->cmd.buswidth;
+
+ if (spi_op->addr.nbytes) {
+ rpc_op.addr.buswidth = spi_op->addr.buswidth;
+ rpc_op.addr.nbytes = spi_op->addr.nbytes;
+ rpc_op.addr.val = spi_op->addr.val;
+ }
+
+ if (spi_op->dummy.nbytes) {
+ rpc_op.dummy.buswidth = spi_op->dummy.buswidth;
+ rpc_op.dummy.ncycles = spi_op->dummy.nbytes * 8 /
+ spi_op->dummy.buswidth;
+ }
+
+ if (spi_op->data.nbytes || (offs && len)) {
+ rpc_op.data.buswidth = spi_op->data.buswidth;
+ rpc_op.data.nbytes = spi_op->data.nbytes;
+ switch (spi_op->data.dir) {
+ case SPI_MEM_DATA_IN:
+ rpc_op.data.dir = RPCIF_DATA_IN;
+ rpc_op.data.buf.in = spi_op->data.buf.in;
+ break;
+ case SPI_MEM_DATA_OUT:
+ rpc_op.data.dir = RPCIF_DATA_OUT;
+ rpc_op.data.buf.out = spi_op->data.buf.out;
+ break;
+ case SPI_MEM_NO_DATA:
+ rpc_op.data.dir = RPCIF_NO_DATA;
+ break;
+ }
+ } else {
+ rpc_op.data.dir = RPCIF_NO_DATA;
+ }
+
+ rpcif_prepare(rpc, &rpc_op, offs, len);
+}
+
+static bool rpcif_spi_mem_supports_op(struct spi_mem *mem,
+ const struct spi_mem_op *op)
+{
+ if (!spi_mem_default_supports_op(mem, op))
+ return false;
+
+ if (op->data.buswidth > 4 || op->addr.buswidth > 4 ||
+ op->dummy.buswidth > 4 || op->cmd.buswidth > 4 ||
+ op->addr.nbytes > 4)
+ return false;
+
+ return true;
+}
+
+static ssize_t rpcif_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf)
+{
+ struct rpcif *rpc =
+ spi_controller_get_devdata(desc->mem->spi->controller);
+
+ if (offs + desc->info.offset + len > U32_MAX)
+ return -EINVAL;
+
+ rpcif_spi_mem_prepare(desc->mem->spi, &desc->info.op_tmpl, &offs, &len);
+
+ return rpcif_dirmap_read(rpc, offs, len, buf);
+}
+
+static int rpcif_spi_mem_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+ struct rpcif *rpc =
+ spi_controller_get_devdata(desc->mem->spi->controller);
+
+ if (desc->info.offset + desc->info.length > U32_MAX)
+ return -ENOTSUPP;
+
+ if (!rpcif_spi_mem_supports_op(desc->mem, &desc->info.op_tmpl))
+ return -ENOTSUPP;
+
+ if (!rpc->dirmap && desc->info.op_tmpl.data.dir == SPI_MEM_DATA_IN)
+ return -ENOTSUPP;
+
+ if (desc->info.op_tmpl.data.dir == SPI_MEM_DATA_OUT)
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static int rpcif_spi_mem_exec_op(struct spi_mem *mem,
+ const struct spi_mem_op *op)
+{
+ struct rpcif *rpc =
+ spi_controller_get_devdata(mem->spi->controller);
+
+ rpcif_spi_mem_prepare(mem->spi, op, NULL, NULL);
+
+ return rpcif_manual_xfer(rpc);
+}
+
+static const struct spi_controller_mem_ops rpcif_spi_mem_ops = {
+ .supports_op = rpcif_spi_mem_supports_op,
+ .exec_op = rpcif_spi_mem_exec_op,
+ .dirmap_create = rpcif_spi_mem_dirmap_create,
+ .dirmap_read = rpcif_spi_mem_dirmap_read,
+};
+
+static int rpcif_spi_probe(struct platform_device *pdev)
+{
+ struct device *parent = pdev->dev.parent;
+ struct spi_controller *ctlr;
+ struct rpcif *rpc;
+ int error;
+
+ ctlr = spi_alloc_master(&pdev->dev, sizeof(*rpc));
+ if (!ctlr)
+ return -ENOMEM;
+
+ rpc = spi_controller_get_devdata(ctlr);
+ rpcif_sw_init(rpc, parent);
+
+ platform_set_drvdata(pdev, ctlr);
+
+ ctlr->dev.of_node = parent->of_node;
+
+ rpcif_enable_rpm(rpc);
+
+ ctlr->num_chipselect = 1;
+ ctlr->mem_ops = &rpcif_spi_mem_ops;
+
+ ctlr->bits_per_word_mask = SPI_BPW_MASK(8);
+ ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_TX_QUAD | SPI_RX_QUAD;
+ ctlr->flags = SPI_CONTROLLER_HALF_DUPLEX;
+
+ rpcif_hw_init(rpc, false);
+
+ error = spi_register_controller(ctlr);
+ if (error) {
+ dev_err(&pdev->dev, "spi_register_controller failed\n");
+ rpcif_disable_rpm(rpc);
+ spi_controller_put(ctlr);
+ return error;
+ }
+
+ return 0;
+}
+
+static int rpcif_spi_remove(struct platform_device *pdev)
+{
+ struct spi_controller *ctlr = platform_get_drvdata(pdev);
+ struct rpcif *rpc = spi_controller_get_devdata(ctlr);
+
+ spi_unregister_controller(ctlr);
+ rpcif_disable_rpm(rpc);
+
+ return 0;
+}
+
+static int __maybe_unused rpcif_spi_suspend(struct device *dev)
+{
+ struct spi_controller *ctlr = dev_get_drvdata(dev);
+
+ return spi_controller_suspend(ctlr);
+}
+
+static int __maybe_unused rpcif_spi_resume(struct device *dev)
+{
+ struct spi_controller *ctlr = dev_get_drvdata(dev);
+
+ return spi_controller_resume(ctlr);
+}
+
+static SIMPLE_DEV_PM_OPS(rpcif_spi_pm_ops, rpcif_spi_suspend, rpcif_spi_resume);
+
+static struct platform_driver rpcif_spi_driver = {
+ .probe = rpcif_spi_probe,
+ .remove = rpcif_spi_remove,
+ .driver = {
+ .name = "rpc-if-spi",
+ .pm = &rpcif_spi_pm_ops,
+ },
+};
+module_platform_driver(rpcif_spi_driver);
+
+MODULE_DESCRIPTION("Renesas RPC-IF SPI driver");
+MODULE_LICENSE("GPL v2");
--
2.25.1


[PATCH v2 4.19.y-cip 6/7] spi: spi-mem: Add a new API to support direct mapping

Lad Prabhakar
 

From: Boris Brezillon <boris.brezillon@...>

commit aa167f3fed0c37e0e4c707d4331d827661f46644 upstream.

Most modern SPI controllers can directly map a SPI memory (or a portion
of the SPI memory) in the CPU address space. Most of the time this
brings significant performance improvements as it automates the whole
process of sending SPI memory operations every time a new region is
accessed.

This new API allows SPI memory drivers to create direct mappings and
then use them to access the memory instead of using spi_mem_exec_op().

Signed-off-by: Boris Brezillon <boris.brezillon@...>
Reviewed-by: Miquel Raynal <miquel.raynal@...>
Signed-off-by: Mark Brown <broonie@...>
[PL: Return early in spi_mem_dirmap_dirmap_{read/write}]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/spi/spi-mem.c | 204 ++++++++++++++++++++++++++++++++++++
include/linux/spi/spi-mem.h | 80 ++++++++++++++
2 files changed, 284 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 2607981d973d..930a83c964c1 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -433,6 +433,210 @@ int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
}
EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);

+static ssize_t spi_mem_no_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf)
+{
+ struct spi_mem_op op = desc->info.op_tmpl;
+ int ret;
+
+ op.addr.val = desc->info.offset + offs;
+ op.data.buf.in = buf;
+ op.data.nbytes = len;
+ ret = spi_mem_adjust_op_size(desc->mem, &op);
+ if (ret)
+ return ret;
+
+ ret = spi_mem_exec_op(desc->mem, &op);
+ if (ret)
+ return ret;
+
+ return op.data.nbytes;
+}
+
+static ssize_t spi_mem_no_dirmap_write(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, const void *buf)
+{
+ struct spi_mem_op op = desc->info.op_tmpl;
+ int ret;
+
+ op.addr.val = desc->info.offset + offs;
+ op.data.buf.out = buf;
+ op.data.nbytes = len;
+ ret = spi_mem_adjust_op_size(desc->mem, &op);
+ if (ret)
+ return ret;
+
+ ret = spi_mem_exec_op(desc->mem, &op);
+ if (ret)
+ return ret;
+
+ return op.data.nbytes;
+}
+
+/**
+ * spi_mem_dirmap_create() - Create a direct mapping descriptor
+ * @mem: SPI mem device this direct mapping should be created for
+ * @info: direct mapping information
+ *
+ * This function is creating a direct mapping descriptor which can then be used
+ * to access the memory using spi_mem_dirmap_read() or spi_mem_dirmap_write().
+ * If the SPI controller driver does not support direct mapping, this function
+ * fallback to an implementation using spi_mem_exec_op(), so that the caller
+ * doesn't have to bother implementing a fallback on his own.
+ *
+ * Return: a valid pointer in case of success, and ERR_PTR() otherwise.
+ */
+struct spi_mem_dirmap_desc *
+spi_mem_dirmap_create(struct spi_mem *mem,
+ const struct spi_mem_dirmap_info *info)
+{
+ struct spi_controller *ctlr = mem->spi->controller;
+ struct spi_mem_dirmap_desc *desc;
+ int ret = -ENOTSUPP;
+
+ /* Make sure the number of address cycles is between 1 and 8 bytes. */
+ if (!info->op_tmpl.addr.nbytes || info->op_tmpl.addr.nbytes > 8)
+ return ERR_PTR(-EINVAL);
+
+ /* data.dir should either be SPI_MEM_DATA_IN or SPI_MEM_DATA_OUT. */
+ if (info->op_tmpl.data.dir == SPI_MEM_NO_DATA)
+ return ERR_PTR(-EINVAL);
+
+ desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+ if (!desc)
+ return ERR_PTR(-ENOMEM);
+
+ desc->mem = mem;
+ desc->info = *info;
+ if (ctlr->mem_ops && ctlr->mem_ops->dirmap_create)
+ ret = ctlr->mem_ops->dirmap_create(desc);
+
+ if (ret) {
+ desc->nodirmap = true;
+ if (!spi_mem_supports_op(desc->mem, &desc->info.op_tmpl))
+ ret = -ENOTSUPP;
+ else
+ ret = 0;
+ }
+
+ if (ret) {
+ kfree(desc);
+ return ERR_PTR(ret);
+ }
+
+ return desc;
+}
+EXPORT_SYMBOL_GPL(spi_mem_dirmap_create);
+
+/**
+ * spi_mem_dirmap_destroy() - Destroy a direct mapping descriptor
+ * @desc: the direct mapping descriptor to destroy
+ * @info: direct mapping information
+ *
+ * This function destroys a direct mapping descriptor previously created by
+ * spi_mem_dirmap_create().
+ */
+void spi_mem_dirmap_destroy(struct spi_mem_dirmap_desc *desc)
+{
+ struct spi_controller *ctlr = desc->mem->spi->controller;
+
+ if (!desc->nodirmap && ctlr->mem_ops && ctlr->mem_ops->dirmap_destroy)
+ ctlr->mem_ops->dirmap_destroy(desc);
+}
+EXPORT_SYMBOL_GPL(spi_mem_dirmap_destroy);
+
+/**
+ * spi_mem_dirmap_dirmap_read() - Read data through a direct mapping
+ * @desc: direct mapping descriptor
+ * @offs: offset to start reading from. Note that this is not an absolute
+ * offset, but the offset within the direct mapping which already has
+ * its own offset
+ * @len: length in bytes
+ * @buf: destination buffer. This buffer must be DMA-able
+ *
+ * This function reads data from a memory device using a direct mapping
+ * previously instantiated with spi_mem_dirmap_create().
+ *
+ * Return: the amount of data read from the memory device or a negative error
+ * code. Note that the returned size might be smaller than @len, and the caller
+ * is responsible for calling spi_mem_dirmap_read() again when that happens.
+ */
+ssize_t spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf)
+{
+ struct spi_controller *ctlr = desc->mem->spi->controller;
+ ssize_t ret;
+
+ if (desc->info.op_tmpl.data.dir != SPI_MEM_DATA_IN)
+ return -EINVAL;
+
+ if (!len)
+ return 0;
+
+ if (desc->nodirmap)
+ return spi_mem_no_dirmap_read(desc, offs, len, buf);
+
+ if (ctlr->mem_ops && ctlr->mem_ops->dirmap_read) {
+ ret = spi_mem_access_start(desc->mem);
+ if (ret)
+ return ret;
+
+ ret = ctlr->mem_ops->dirmap_read(desc, offs, len, buf);
+
+ spi_mem_access_end(desc->mem);
+ return ret;
+ }
+
+ return -ENOTSUPP;
+}
+EXPORT_SYMBOL_GPL(spi_mem_dirmap_read);
+
+/**
+ * spi_mem_dirmap_dirmap_write() - Write data through a direct mapping
+ * @desc: direct mapping descriptor
+ * @offs: offset to start writing from. Note that this is not an absolute
+ * offset, but the offset within the direct mapping which already has
+ * its own offset
+ * @len: length in bytes
+ * @buf: source buffer. This buffer must be DMA-able
+ *
+ * This function writes data to a memory device using a direct mapping
+ * previously instantiated with spi_mem_dirmap_create().
+ *
+ * Return: the amount of data written to the memory device or a negative error
+ * code. Note that the returned size might be smaller than @len, and the caller
+ * is responsible for calling spi_mem_dirmap_write() again when that happens.
+ */
+ssize_t spi_mem_dirmap_write(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, const void *buf)
+{
+ struct spi_controller *ctlr = desc->mem->spi->controller;
+ ssize_t ret;
+
+ if (desc->info.op_tmpl.data.dir != SPI_MEM_DATA_OUT)
+ return -EINVAL;
+
+ if (!len)
+ return 0;
+
+ if (desc->nodirmap)
+ return spi_mem_no_dirmap_write(desc, offs, len, buf);
+
+ if (ctlr->mem_ops && ctlr->mem_ops->dirmap_write) {
+ ret = spi_mem_access_start(desc->mem);
+ if (ret)
+ return ret;
+
+ ret = ctlr->mem_ops->dirmap_write(desc, offs, len, buf);
+
+ spi_mem_access_end(desc->mem);
+ return ret;
+ }
+
+ return -ENOTSUPP;
+}
+EXPORT_SYMBOL_GPL(spi_mem_dirmap_write);
+
static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
{
return container_of(drv, struct spi_mem_driver, spidrv.driver);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 253a8d451d4c..762b3974cf9c 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -124,6 +124,49 @@ struct spi_mem_op {
.data = __data, \
}

+/**
+ * struct spi_mem_dirmap_info - Direct mapping information
+ * @op_tmpl: operation template that should be used by the direct mapping when
+ * the memory device is accessed
+ * @offset: absolute offset this direct mapping is pointing to
+ * @length: length in byte of this direct mapping
+ *
+ * These information are used by the controller specific implementation to know
+ * the portion of memory that is directly mapped and the spi_mem_op that should
+ * be used to access the device.
+ * A direct mapping is only valid for one direction (read or write) and this
+ * direction is directly encoded in the ->op_tmpl.data.dir field.
+ */
+struct spi_mem_dirmap_info {
+ struct spi_mem_op op_tmpl;
+ u64 offset;
+ u64 length;
+};
+
+/**
+ * struct spi_mem_dirmap_desc - Direct mapping descriptor
+ * @mem: the SPI memory device this direct mapping is attached to
+ * @info: information passed at direct mapping creation time
+ * @nodirmap: set to 1 if the SPI controller does not implement
+ * ->mem_ops->dirmap_create() or when this function returned an
+ * error. If @nodirmap is true, all spi_mem_dirmap_{read,write}()
+ * calls will use spi_mem_exec_op() to access the memory. This is a
+ * degraded mode that allows spi_mem drivers to use the same code
+ * no matter whether the controller supports direct mapping or not
+ * @priv: field pointing to controller specific data
+ *
+ * Common part of a direct mapping descriptor. This object is created by
+ * spi_mem_dirmap_create() and controller implementation of ->create_dirmap()
+ * can create/attach direct mapping resources to the descriptor in the ->priv
+ * field.
+ */
+struct spi_mem_dirmap_desc {
+ struct spi_mem *mem;
+ struct spi_mem_dirmap_info info;
+ unsigned int nodirmap;
+ void *priv;
+};
+
/**
* struct spi_mem - describes a SPI memory device
* @spi: the underlying SPI device
@@ -179,10 +222,32 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
* Note that if the implementation of this function allocates memory
* dynamically, then it should do so with devm_xxx(), as we don't
* have a ->free_name() function.
+ * @dirmap_create: create a direct mapping descriptor that can later be used to
+ * access the memory device. This method is optional
+ * @dirmap_destroy: destroy a memory descriptor previous created by
+ * ->dirmap_create()
+ * @dirmap_read: read data from the memory device using the direct mapping
+ * created by ->dirmap_create(). The function can return less
+ * data than requested (for example when the request is crossing
+ * the currently mapped area), and the caller of
+ * spi_mem_dirmap_read() is responsible for calling it again in
+ * this case.
+ * @dirmap_write: write data to the memory device using the direct mapping
+ * created by ->dirmap_create(). The function can return less
+ * data than requested (for example when the request is crossing
+ * the currently mapped area), and the caller of
+ * spi_mem_dirmap_write() is responsible for calling it again in
+ * this case.
*
* This interface should be implemented by SPI controllers providing an
* high-level interface to execute SPI memory operation, which is usually the
* case for QSPI controllers.
+ *
+ * Note on ->dirmap_{read,write}(): drivers should avoid accessing the direct
+ * mapping from the CPU because doing that can stall the CPU waiting for the
+ * SPI mem transaction to finish, and this will make real-time maintainers
+ * unhappy and might make your system less reactive. Instead, drivers should
+ * use DMA to access this direct mapping.
*/
struct spi_controller_mem_ops {
int (*adjust_op_size)(struct spi_mem *mem, struct spi_mem_op *op);
@@ -191,6 +256,12 @@ struct spi_controller_mem_ops {
int (*exec_op)(struct spi_mem *mem,
const struct spi_mem_op *op);
const char *(*get_name)(struct spi_mem *mem);
+ int (*dirmap_create)(struct spi_mem_dirmap_desc *desc);
+ void (*dirmap_destroy)(struct spi_mem_dirmap_desc *desc);
+ ssize_t (*dirmap_read)(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf);
+ ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, const void *buf);
};

/**
@@ -262,6 +333,15 @@ int spi_mem_exec_op(struct spi_mem *mem,

const char *spi_mem_get_name(struct spi_mem *mem);

+struct spi_mem_dirmap_desc *
+spi_mem_dirmap_create(struct spi_mem *mem,
+ const struct spi_mem_dirmap_info *info);
+void spi_mem_dirmap_destroy(struct spi_mem_dirmap_desc *desc);
+ssize_t spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf);
+ssize_t spi_mem_dirmap_write(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, const void *buf);
+
int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
struct module *owner);

--
2.25.1

4281 - 4300 of 10158