Date   

Re: CIP embedded platform Internet connection?

Mohammed Billoo <mab@...>
 

Daniel,

Thanks for getting back. I realized that the configuration of the embedded platform and Hawkbit server may be specific for the SWUpdate demo. Suzuki-san, is that correct? If so, is it OK if these parameters are in files or would you want them in a less permanent form (e.g. environment variables)? The advantage of the latter would be that if I need to change the network configuration for my own set up (since my localhost external IP is different from what's in the BBB customization), I don't have to manage two different network configurations. I can set the appropriate environment variable (for example) and the build, if set up correctly, would pick up the environment variables and configure the BBB image correctly. Is there any strong conviction for either way?

Thanks 

Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com
201-338-2022

On Wed, Jul 29, 2020, 7:52 PM Daniel Sangorrin <daniel.sangorrin@...> wrote:
Hi Mohammed,

> -----Original Message-----
> From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
> This question stems from the thread titled "The security of NTP". If we do go with NTS, it looks like we're going to need an Internet
> connection to the embedded platform. Is that acceptable? The work that I've seen so far related to CIP SWUpdate has assumed that the
> Hawkbit server is on the local network. It isn't obvious if that has been an intentional decision (due to security requirements) or just to ease
> development.

There is nothing in CIP SWUpdate that assumes the Hawkbit server is on a local network.
Perhaps the README is using a local serve for demonstration purposes?

Thanks,
Daniel


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: [PATCH 3/3] README: Add steps to build cip-security image

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Venkata-san

Maybe Jan didn't see your e-mail because he wasn't in the CC.

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Venkata Pyla
Sent: Friday, July 24, 2020 3:58 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [PATCH 3/3] README: Add steps to build cip-security image

Hi Jan,

On Thu, Jul 23, 2020 at 04:10 PM, Jan Kiszka wrote:


On 21.07.20 10:16, Venkata Pyla wrote:
From: venkata <venkata.pyla@toshiba-tsip.com>

Signed-off-by: venkata <venkata.pyla@toshiba-tsip.com>
---
README.md | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/README.md b/README.md
index bbad1a0..b2c4166 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,16 @@ card, run
dd
if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.
img \
of=/dev/<medium-device> bs=1M status=progress

+## Building Security target images
+Building images for QEMU x86-64bit machine
+
+ ./kas-docker --isar build --target cip-core-image-security
kas.yml:board-qemu-amd64.yml
+
+Run the generated securiy images on QEMU (x86-64bit)
+
+ TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64
+
+
## Community Resources

TBD
This patch is fine, but I'm missing 4/4: Add this image to CI (same
comment as I had on the MR on gitlab).
Adding cip security image to CI,
i need some suggestions to use the current format present in .gitlab-ci.yml

Currently i have the below problem for using script deploy-cip-core.sh:
1. image name formation in the script should have another variable
.../$IMG_PREFIX-cip-core-$RELEASE-$TARGET
where $IMG_PREFIX is default to "cip-core-image" if not specified
for security image it will be passed as 4th argument "cip-core-image-security"
2. currently scrit is expecting the image format in *.wic.img so,
for qemu i think we should have wks file to generate image with format .wic.img

or for this security image do we need to deploy it seperatley?
please guide me
Sometimes it is better to send a patch instead of trying to explain it with words.

Thanks,
Daniel


Re: CIP embedded platform Internet connection?

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Mohammed,

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Mohammed Billoo
This question stems from the thread titled "The security of NTP". If we do go with NTS, it looks like we're going to need an Internet
connection to the embedded platform. Is that acceptable? The work that I've seen so far related to CIP SWUpdate has assumed that the
Hawkbit server is on the local network. It isn't obvious if that has been an intentional decision (due to security requirements) or just to ease
development.
There is nothing in CIP SWUpdate that assumes the Hawkbit server is on a local network.
Perhaps the README is using a local serve for demonstration purposes?

Thanks,
Daniel


Re: [isar-cip-core PATCH v2 0/5] A/B Rootfs update with software update

Jan Kiszka
 

On 29.06.20 11:56, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
This patchset adds efibootguard, swupdate to allow A/B updates in
cip-core. The update mechanism is currently only implemented for x86_64.
Changes V2:
- update efibootguard to v0.7
- add swdescription and kas option to build qemu-amd64 test image
- swupdate set to upstream mirror and no longer use gitsm
Quirin Gylstorff (5):
recipes-bsp: Add efibootguard
patches: add libubootenv
recipes-core: add swupdate
wic: Add wks files for A/B Partition update
swupdate: create swu file from wic image
classes/extract-partition.bbclass | 26 +
classes/kconfig-snippets.bbclass | 90 ++++
classes/swupdate-config.bbclass | 76 +++
classes/swupdate-img.bbclass | 75 +++
classes/wic-swu-img.bbclass | 20 +
.../0001-u-boot-add-libubootenv.patch | 169 +++++++
kas-cip.yml | 4 +
kas/opt/ebg-swu.yml | 26 +
kas/opt/qemu-swupdate.yml | 19 +
.../efibootguard/efibootguard_0.7-git+isar.bb | 46 ++
recipes-bsp/efibootguard/files/debian/compat | 1 +
.../efibootguard/files/debian/control.tmpl | 20 +
.../files/debian/efibootguard-dev.install | 3 +
.../files/debian/efibootguard.install | 2 +
recipes-bsp/efibootguard/files/debian/rules | 21 +
recipes-core/images/cip-core-image.bb | 10 +
recipes-core/images/files/sw-description.tmpl | 29 ++
.../swupdate/files/debian/changelog.tmpl | 6 +
recipes-core/swupdate/files/debian/compat | 1 +
.../swupdate/files/debian/control.tmpl | 15 +
recipes-core/swupdate/files/debian/copyright | 36 ++
recipes-core/swupdate/files/debian/rules.tmpl | 30 ++
.../swupdate/files/debian/swupdate.examples | 2 +
.../swupdate/files/debian/swupdate.install | 2 +
.../swupdate/files/debian/swupdate.manpages | 5 +
.../swupdate/files/debian/swupdate.tmpfile | 2 +
recipes-core/swupdate/files/debian/watch | 12 +
recipes-core/swupdate/files/postinst | 2 +
recipes-core/swupdate/files/swupdate.cfg | 6 +
.../swupdate/files/swupdate.service.example | 11 +
.../swupdate/files/swupdate.socket.example | 11 +
.../swupdate/files/swupdate.socket.tmpl | 13 +
.../swupdate/files/swupdate_defconfig | 83 ++++
.../swupdate_defconfig_efibootguard.snippet | 3 +
.../files/swupdate_defconfig_lua.snippet | 2 +
.../swupdate_defconfig_luahandler.snippet | 4 +
.../files/swupdate_defconfig_mtd.snippet | 1 +
.../files/swupdate_defconfig_u-boot.snippet | 3 +
.../files/swupdate_defconfig_ubi.snippet | 6 +
.../swupdate/files/swupdate_handlers.lua | 453 ++++++++++++++++++
recipes-core/swupdate/swupdate.bb | 54 +++
.../wic/plugins/source/efibootguard-boot.py | 162 +++++++
.../wic/plugins/source/efibootguard-efi.py | 102 ++++
wic/ebg-sysparts.inc | 8 +
wic/qemu-amd64-efibootguard.wks | 5 +
wic/simatic-ipc227e-efibootguard.wks | 5 +
wic/swupdate-partition.inc | 4 +
47 files changed, 1686 insertions(+)
create mode 100644 classes/extract-partition.bbclass
create mode 100644 classes/kconfig-snippets.bbclass
create mode 100644 classes/swupdate-config.bbclass
create mode 100644 classes/swupdate-img.bbclass
create mode 100644 classes/wic-swu-img.bbclass
create mode 100644 isar-patches/0001-u-boot-add-libubootenv.patch
create mode 100644 kas/opt/ebg-swu.yml
create mode 100644 kas/opt/qemu-swupdate.yml
create mode 100644 recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb
create mode 100644 recipes-bsp/efibootguard/files/debian/compat
create mode 100644 recipes-bsp/efibootguard/files/debian/control.tmpl
create mode 100644 recipes-bsp/efibootguard/files/debian/efibootguard-dev.install
create mode 100644 recipes-bsp/efibootguard/files/debian/efibootguard.install
create mode 100755 recipes-bsp/efibootguard/files/debian/rules
create mode 100644 recipes-core/images/files/sw-description.tmpl
create mode 100644 recipes-core/swupdate/files/debian/changelog.tmpl
create mode 100644 recipes-core/swupdate/files/debian/compat
create mode 100644 recipes-core/swupdate/files/debian/control.tmpl
create mode 100644 recipes-core/swupdate/files/debian/copyright
create mode 100755 recipes-core/swupdate/files/debian/rules.tmpl
create mode 100644 recipes-core/swupdate/files/debian/swupdate.examples
create mode 100644 recipes-core/swupdate/files/debian/swupdate.install
create mode 100644 recipes-core/swupdate/files/debian/swupdate.manpages
create mode 100644 recipes-core/swupdate/files/debian/swupdate.tmpfile
create mode 100644 recipes-core/swupdate/files/debian/watch
create mode 100644 recipes-core/swupdate/files/postinst
create mode 100644 recipes-core/swupdate/files/swupdate.cfg
create mode 100644 recipes-core/swupdate/files/swupdate.service.example
create mode 100644 recipes-core/swupdate/files/swupdate.socket.example
create mode 100644 recipes-core/swupdate/files/swupdate.socket.tmpl
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_efibootguard.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_lua.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_luahandler.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_mtd.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_u-boot.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_defconfig_ubi.snippet
create mode 100644 recipes-core/swupdate/files/swupdate_handlers.lua
create mode 100644 recipes-core/swupdate/swupdate.bb
create mode 100644 scripts/lib/wic/plugins/source/efibootguard-boot.py
create mode 100644 scripts/lib/wic/plugins/source/efibootguard-efi.py
create mode 100644 wic/ebg-sysparts.inc
create mode 100644 wic/qemu-amd64-efibootguard.wks
create mode 100644 wic/simatic-ipc227e-efibootguard.wks
create mode 100644 wic/swupdate-partition.inc
Thanks, applied to next. The secure boot series is on hold due to conflict. When you update it, please also make sure that at least one target covering as much as possible of your code is built via CI.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core PATCH v3 4/6] secure-boot: Add secure boot with unified kernel image

Jan Kiszka
 

On 24.07.20 17:01, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
A unified kernel image contains the os-release, kernel,
kernel commandline, initramfs and efi-stub in one binary.
This binary can be boot by systemd-boot and efibootguard.
It also allows to sign kernel and initramfs as one packages.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
...

diff --git a/start-qemu.sh b/start-qemu.sh
index 49f0266..74d1b54 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -15,6 +15,8 @@ usage()
echo "Usage: $0 ARCHITECTURE [QEMU_OPTIONS]"
echo -e "\nSet QEMU_PATH environment variable to use a locally " \
"built QEMU version"
+ echo -e "\nSet SECURE_BOOT environment variable to boot a secure boot environment " \
+ "This environment also needs the variables OVMF_VARS and OVMF_CODE set"
exit 1
}
@@ -22,17 +24,25 @@ if [ -n "${QEMU_PATH}" ]; then
QEMU_PATH="${QEMU_PATH}/"
fi
+if [ -z "${DISTRO_RELEASE}" ]; then
+ DISTRO_RELEASE="buster"
+fi
+if [ -z "${TARGET_IMAGE}" ];then
+ TARGET_IMAGE="cip-core-image"
+fi
+
case "$1" in
x86|x86_64|amd64)
DISTRO_ARCH=amd64
QEMU=qemu-system-x86_64
QEMU_EXTRA_ARGS=" \
- -cpu host -smp 4 \
- -enable-kvm -machine q35 \
+ -cpu qemu64 \
+ -smp 4 \
+ -machine q35,accel=kvm:tcg \
-device ide-hd,drive=disk \
-device virtio-net-pci,netdev=net"
KERNEL_CMDLINE=" \
- root=/dev/sda vga=0x305 console=ttyS0"
+ root=/dev/sda vga=0x305"
;;
arm64|aarch64)
DISTRO_ARCH=arm64
@@ -71,21 +81,41 @@ case "$1" in
;;
esac
-if [ -z "${DISTRO_RELEASE}" ]; then
- DISTRO_RELEASE="buster"
-fi
-
-IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/cip-core-image-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
-IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)
+IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/${TARGET_IMAGE}-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
if [ -z "${DISPLAY}" ]; then
QEMU_EXTRA_ARGS="${QEMU_EXTRA_ARGS} -nographic"
+ case "$1" in
+ x86|x86_64|amd64)
+ KERNEL_CMDLINE="${KERNEL_CMDLINE} console=ttyS0"
+ esac
+fi
+
+
+
+if [ -n "SECURE_BOOT" ]; then
+ ovmf_code=${OVMF_CODE:-/usr/share/OVMF/OVMF_CODE.secboot.fd}
+ ovmf_vars=${OVMF_VARS:-./OVMF_VARS.fd}
+ QEMU_EXTRA_ARGS=" \
+ ${QEMU_EXTRA_ARGS} \
+ -global ICH9-LPC.disable_s3=1 \
+ -global isa-fdc.driveA= \
+ "
Looks like someone fell asleep on the tab key - please indent more reasonably.

+ BOOT_FILES="-drive if=pflash,format=raw,unit=0,readonly=on,file=${ovmf_code} \
+ -drive if=pflash,format=raw,file=${ovmf_vars} \
+ -drive file=${IMAGE_PREFIX}.wic.img,discard=unmap,if=none,id=disk,format=raw"
+else
+ IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)
+
+ KERNEL_FILE=$(ls ${IMAGE_PREFIX}-vmlinuz* | tail -1)
+ INITRD_FILE=$(ls ${IMAGE_PREFIX}-initrd.img* | tail -1)
+
+ BOOT_FILES=-kernel ${KERNEL_FILE} -append "${KERNEL_CMDLINE}" \
+ -initrd ${INITRD_FILE}
fi
shift 1
${QEMU_PATH}${QEMU} \
- -drive file=${IMAGE_FILE},discard=unmap,if=none,id=disk,format=raw \
-m 1G -serial mon:stdio -netdev user,id=net \
- -kernel ${IMAGE_PREFIX}-vmlinuz -append "${KERNEL_CMDLINE}" \
- -initrd ${IMAGE_PREFIX}-initrd.img ${QEMU_EXTRA_ARGS} "$@"
+ ${BOOT_FILES} ${QEMU_EXTRA_ARGS} "$@"
This file is in conflict with changes in next. Please rebase.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core 0/3] Security Branch patches

Jan Kiszka
 

On 27.07.20 13:41, Venkata Pyla wrote:
From: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
Patch series for Security changes for IEC-62443-4-2 evaluation
Kazuhiro Hayashi (1):
cip-security: Add packages for IEC-62443-4-2 evaluation
Venkata Pyla (2):
start-qemu.sh: Use 'TARGET_IMAGE' to pick respective image file
README: Add steps to build cip-security image
README.md | 10 ++++++
.../images/cip-core-image-security.bb | 36 +++++++++++++++++++
start-qemu.sh | 6 +++-
3 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 recipes-core/images/cip-core-image-security.bb
Applied to next - now awaiting the patch for .gitlab-ci.yml ;)

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core PATCH v3 1/6] kernel: add fat for qemu-amd64

Jan Kiszka
 

On 24.07.20 17:01, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
Add a fat configuration to access FAT Partitions on the qemu-amd64
target.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
recipes-kernel/linux/files/qemu-amd64_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/recipes-kernel/linux/files/qemu-amd64_defconfig b/recipes-kernel/linux/files/qemu-amd64_defconfig
index 7487152..5449317 100644
--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,9 @@ CONFIG_CRYPTO_DEV_CCP=y
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
Taking that for now, but we should quickly move that defconfig into cip-kernel-config. I'm not sure if there is anything for qemu already. Could you check an propose our defconfig for it?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core 1/3] cip-security: Add packages for IEC-62443-4-2 evaluation

Jan Kiszka
 

On 29.07.20 14:39, Venkata Pyla wrote:
On Mon, Jul 27, 2020 at 08:04 PM, Jan Kiszka wrote:


On 27.07.20 13:41, venkata.pyla@toshiba-tsip.com wrote:
From: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>

Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
---
.../images/cip-core-image-security.bb | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb
b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..a17c522
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,36 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"
Still no CI for this. You can send that separately on top, the series
looks fine otherwise.
To add security image in gitlab-ci.yml i need some suggestions...
in deploy-cip-core script that is used in gitlab-ci is expecting *.wic image for copying the files,
but because there is no wks file yet for QEMU it is not generating the image.
i think we should add wks file for the qemu target, can you guide me how to do that?
Such a wks file only makes sense when we switch QEMU to image-based booting, like Quirin does in [1].

For adding CI coverage to the security image, it would already be enough to just build it, skipping the deployment. Of course, if you'd like to feed the build result into automated testing, that needs deployment again, but possibly also more. So, let's postpone it until that is on the agenda of the day, I would say.

Jan

[1] https://lists.cip-project.org/g/cip-dev/message/4997

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core 1/3] cip-security: Add packages for IEC-62443-4-2 evaluation

Venkata Pyla
 

On Mon, Jul 27, 2020 at 08:04 PM, Jan Kiszka wrote:


On 27.07.20 13:41, venkata.pyla@toshiba-tsip.com wrote:
From: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>

Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: Venkata Pyla <venkata.pyla@toshiba-tsip.com>
---
.../images/cip-core-image-security.bb | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb
b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..a17c522
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,36 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"
Still no CI for this. You can send that separately on top, the series
looks fine otherwise.
To add security image in gitlab-ci.yml i need some suggestions...
in deploy-cip-core script that is used in gitlab-ci is expecting *.wic image for copying the files,
but because there is no wks file yet for QEMU it is not generating the image.

i think we should add wks file for the qemu target, can you guide me how to do that?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


[PATCH 4.4.y-cip] ARM: dts: iwg22d-sodimm: Enable touchscreen

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

From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>

commit 99ae78f1fc3a73c88fe726c676ae963ce722bf20 upstream.

In one of the iWave-G22D development board variants, called Generic SODIMM
Development Platform, we have an LCD with touchscreen. The resistive touch
controller, STMPE811 is on the development board and is connected through
the i2c5 of the RZ-G1E.

Additionally, this controller should generate an interrupt to the CPU and
it is connected through GPIO4,4 to the GIC.

Touch was tested with one of our iW-RainboW-G22D-SODIMM RZ/G1E development
platforms.

More details on the iWave website:
https://www.iwavesystems.com/rz-g1e-sodimm-development-kit.html

Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Link: https://lore.kernel.org/r/1583336650-25848-1-git-send-email-marian-cristian.rotariu.rb@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 33 +++++++++++++++++++++
1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index 1e331d1e414b..5cd989556b60 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -149,6 +149,39 @@
status = "okay";
clock-frequency = <400000>;

+ stmpe811@44 {
+ compatible = "st,stmpe811";
+ reg = <0x44>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ /* 8 sample average control */
+ st,ave-ctrl = <3>;
+ /* 7 length fractional part in z */
+ st,fraction-z = <7>;
+ /*
+ * 50 mA typical 80 mA max touchscreen drivers
+ * current limit value
+ */
+ st,i-drive = <1>;
+ /* 1 ms panel driver settling time */
+ st,settling = <3>;
+ /* 5 ms touch detect interrupt delay */
+ st,touch-det-delay = <5>;
+ };
+ };
+
sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
#sound-dai-cells = <0>;
--
2.17.1


Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

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

Hi All,

Thanks for the feedback.

Subject: RE: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

Hi all,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Wednesday, July 29, 2020 5:40 AM
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC
◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Chris Paterson
<chris.paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E
board

Hi!

Add LCD Panel support for iWave RZ/G1E board based on r8a7745 SoC.

Backporting the panel patch as it is, requires drm bridge Api
changes, which is not present at 4.4 kernel. So used the 4.4 rm
framework to attach the simple panel driver with rgb connector
driver. The rgb connector is based on the workdone for the lvds
connector. The display panel binding patch is backported to 4.4
kernel,since the mainline uses yaml file and it conflict with corresponding
.txt in 4.4 kernel.

Other patches in this series are cherry picked from mainline.
I don't see anything wrong with this, so I'll test/apply it if noone objects.
I didn't see any isseue this patche series.
The CI test is fine, so I commit.

I guess we could like patches for cip-kernel-config repository to
actually enable this in our testing...
+1.
Sure I will send a new merge request for cip-kernel-config.

Cheers,
Biju


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

Nobuhiro Iwamatsu
 

Hi all,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Wednesday, July 29, 2020 5:40 AM
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Chris Paterson <chris.paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

Hi!

Add LCD Panel support for iWave RZ/G1E board based on r8a7745 SoC.

Backporting the panel patch as it is, requires drm bridge Api changes,
which is not present at 4.4 kernel. So used the 4.4 rm framework to attach
the simple panel driver with rgb connector driver. The rgb connector is
based on the workdone for the lvds connector. The display panel binding
patch is backported to 4.4 kernel,since the mainline uses yaml file and
it conflict with corresponding .txt in 4.4 kernel.

Other patches in this series are cherry picked from mainline.
I don't see anything wrong with this, so I'll test/apply it if noone objects.
I didn't see any isseue this patche series.
The CI test is fine, so I commit.

I guess we could like patches for cip-kernel-config repository to actually enable this in
our testing...
+1.


Best regards,
Pavel
Best regards,
Nobuhiro


Re: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 11:07 PM
[...]

Nobuhiro, is something missing from your perspective in Daniels approach? If not, I'd like to have one patch that takes us to that level.

By now, I think an opt-testtools.yml is better (an "option", not a
"layer") than a separate image. That allows to test the security image eventually as well.
Personally, I think the same.
Perhaps Iwamatsu-san got a bit confused by the comments on the merge request.

Thanks,
Daniel


Re: [PATCH 4.4.y-cip 0/9] Add LCD Panel support for RZ/G1E board

Pavel Machek
 

Hi!

Add LCD Panel support for iWave RZ/G1E board based on r8a7745 SoC.

Backporting the panel patch as it is, requires drm bridge Api changes,
which is not present at 4.4 kernel. So used the 4.4 rm framework to attach
the simple panel driver with rgb connector driver. The rgb connector is
based on the workdone for the lvds connector. The display panel binding
patch is backported to 4.4 kernel,since the mainline uses yaml file and
it conflict with corresponding .txt in 4.4 kernel.

Other patches in this series are cherry picked from mainline.
I don't see anything wrong with this, so I'll test/apply it if noone objects.

I guess we could like patches for cip-kernel-config repository to actually enable this in
our testing...

Best regards,
Pavel


[PATCH 4.4.y-cip 9/9] ARM: dts: iwg22d-sodimm: Enable LCD panel

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

From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>

commit 7f61dff1ed915c44845d6865d295853b1c39b6d7 upstream.

On the Generic SODIMM Development Platform there is an RGB LCD panel
directly connected to the DU output. It uses the TPU0 as backlight, one
GPIO pull-up configuration for power enable, R[2:7], G[2:7], B[2:7],
VSYNC, HSYNC, DU0_DISP and, DU0_CLK as inputs.

There is no encoder between the DU and the panel, therefore the default
connector driver is used.

The two variants of the iW-G22D should be mutually exclusive, therefore
this patch also disables the RGB LCD display when the HDMI extension board
is used.

Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Link: https://lore.kernel.org/r/1583239490-8837-1-git-send-email-marian-cristian.rotariu.rb@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
[Removed enable-active-high property to make backlight to work on 4.4.]
---
.../dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 6 ++
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 59 +++++++++++++++++++
2 files changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
index 654d28b629e5..b01405fc1b49 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
@@ -109,6 +109,12 @@
};
};

+&lcd_panel {
+ status = "disabled";
+
+ /delete-node/ port;
+};
+
&pfc {
can1_pins: can1 {
groups = "can1_data_b";
diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index 94e9088f6b40..1e331d1e414b 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -33,6 +33,7 @@

/dts-v1/;
#include "r8a7745-iwg22m.dtsi"
+#include <dt-bindings/pwm/pwm.h>

/ {
model = "iWave Systems RainboW-G22D-SODIMM board based on RZ/G1E";
@@ -82,6 +83,48 @@
states = <3300000 1
1800000 0>;
};
+
+ vccq_panel: regulator-vccq-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "Panel VccQ";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 13 GPIO_ACTIVE_LOW>;
+ };
+
+ backlight_lcd: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&tpu 3 5000000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ };
+
+ lcd_panel: lcd {
+ compatible = "edt,etm043080dh6gp";
+ power-supply = <&vccq_panel>;
+ backlight = <&backlight_lcd>;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&du_out_rgb0>;
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ ports {
+ port@0 {
+ endpoint {
+ remote-endpoint = <&lcd_in>;
+ };
+ };
+ };
};

&can0 {
@@ -117,11 +160,21 @@
};

&pfc {
+ backlight_pins: backlight {
+ groups = "tpu_to3_c";
+ function = "tpu";
+ };
+
can0_pins: can0 {
groups = "can0_data";
function = "can0";
};

+ du0_pins: du0 {
+ groups = "du0_rgb666", "du0_sync", "du0_disp", "du0_clk0_out";
+ function = "du0";
+ };
+
hscif1_pins: hscif1 {
groups = "hscif1_data", "hscif1_ctrl";
function = "hscif1";
@@ -233,6 +286,12 @@
shared-pin;
};

+&tpu {
+ pinctrl-0 = <&backlight_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&usbphy {
status = "okay";
};
--
2.17.1


[PATCH 4.4.y-cip 5/9] drm: rcar-du: Support panels connected directly to the DPAD outputs

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

The DPAD outputs can be connected directly to a panel. To support this
use case, detect whether the entities connected to the DU DPAD outputs
are panels based on the number of ports of their DT node, and retrieve
the corresponding type of DRM objects.

This patch is based on the commit 73eb5476df72
("Support panels connected directly to the DPAD outputs") and
commit 56c5dd00f8db ("drm/rcar-du: Split LVDS encoder and connector")

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 36 ++++++++
drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c | 105 ++++++++++++++++++++++
drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h | 22 +++++
4 files changed, 164 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h

diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 05de1c4097af..51b7ccc66cb7 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,6 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_group.o \
rcar_du_kms.o \
rcar_du_lvdscon.o \
+ rcar_du_rgbcon.o \
rcar_du_plane.o \
rcar_du_vgacon.o

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index d0ae1e8009c6..c407fd4c98ce 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -16,6 +16,7 @@
#include <drm/drmP.h>
#include <drm/drm_crtc.h>
#include <drm/drm_crtc_helper.h>
+#include <drm/drm_panel.h>

#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -23,6 +24,7 @@
#include "rcar_du_hdmienc.h"
#include "rcar_du_kms.h"
#include "rcar_du_lvdscon.h"
+#include "rcar_du_rgbcon.h"
#include "rcar_du_lvdsenc.h"
#include "rcar_du_vgacon.h"

@@ -42,6 +44,26 @@ rcar_du_connector_best_encoder(struct drm_connector *connector)
* Encoder
*/

+static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
+{
+ struct device_node *ports;
+ struct device_node *port;
+ unsigned int num_ports = 0;
+
+ ports = of_get_child_by_name(node, "ports");
+ if (!ports)
+ ports = of_node_get(node);
+
+ for_each_child_of_node(ports, port) {
+ if (of_node_name_eq(port, "port"))
+ num_ports++;
+ }
+
+ of_node_put(ports);
+
+ return num_ports;
+}
+
static void rcar_du_encoder_disable(struct drm_encoder *encoder)
{
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
@@ -127,6 +149,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
{
struct rcar_du_encoder *renc;
struct drm_encoder *encoder;
+ struct drm_panel *panel;
unsigned int encoder_type;
int ret;

@@ -193,6 +216,19 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
ret = rcar_du_hdmi_connector_init(rcdu, renc);
break;

+ case DRM_MODE_ENCODER_NONE:
+ if ((output == RCAR_DU_OUTPUT_DPAD0 ||
+ output == RCAR_DU_OUTPUT_DPAD1) &&
+ rcar_du_encoder_count_ports(con_node) == 1) {
+ panel = of_drm_find_panel(con_node);
+ if (!panel)
+ ret = -EPROBE_DEFER;
+ else
+ ret = rcar_du_rgb_connector_init(rcdu, renc,
+ panel);
+ }
+ break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c b/drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c
new file mode 100644
index 000000000000..f62073e65f03
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_rgbcon.c
@@ -0,0 +1,105 @@
+/*
+ * rcar_du_rgbcon.c -- R-Car Display Unit RGB Connector
+ *
+ * Copyright (C) 2013-2020 Renesas Electronics Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_panel.h>
+
+#include "rcar_du_drv.h"
+#include "rcar_du_encoder.h"
+#include "rcar_du_kms.h"
+#include "rcar_du_rgbcon.h"
+
+struct rcar_du_rgb_connector {
+ struct rcar_du_connector connector;
+ struct drm_panel *drmpanel;
+};
+
+#define to_rcar_rgb_connector(c) \
+ container_of(c, struct rcar_du_rgb_connector, connector.connector)
+
+static int rcar_du_rgb_connector_get_modes(struct drm_connector *connector)
+{
+ struct rcar_du_rgb_connector *rgbcon =
+ to_rcar_rgb_connector(connector);
+
+ return drm_panel_get_modes(rgbcon->drmpanel);
+}
+
+static const struct drm_connector_helper_funcs connector_helper_funcs = {
+ .get_modes = rcar_du_rgb_connector_get_modes,
+ .best_encoder = rcar_du_connector_best_encoder,
+};
+
+static enum drm_connector_status
+rcar_du_rgb_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void rcar_du_rgb_connector_destroy(struct drm_connector *connector)
+{
+ struct rcar_du_rgb_connector *rgbcon =
+ to_rcar_rgb_connector(connector);
+
+ drm_panel_detach(rgbcon->drmpanel);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs connector_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .reset = drm_atomic_helper_connector_reset,
+ .detect = rcar_du_rgb_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = rcar_du_rgb_connector_destroy,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+int rcar_du_rgb_connector_init(struct rcar_du_device *rcdu,
+ struct rcar_du_encoder *renc,
+ struct drm_panel *drmpanel)
+{
+ struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(renc);
+ struct rcar_du_rgb_connector *rgbcon;
+ struct drm_connector *connector;
+ int ret;
+
+ rgbcon = devm_kzalloc(rcdu->dev, sizeof(*rgbcon), GFP_KERNEL);
+ if (!rgbcon)
+ return -ENOMEM;
+
+ rgbcon->drmpanel = drmpanel;
+ connector = &rgbcon->connector.connector;
+ ret = drm_connector_init(rcdu->ddev, connector, &connector_funcs,
+ DRM_MODE_CONNECTOR_DPI);
+ if (ret < 0)
+ return ret;
+
+ drm_connector_helper_add(connector, &connector_helper_funcs);
+
+ connector->dpms = DRM_MODE_DPMS_OFF;
+ drm_object_property_set_value(&connector->base,
+ rcdu->ddev->mode_config.dpms_property,
+ DRM_MODE_DPMS_OFF);
+
+ ret = drm_mode_connector_attach_encoder(connector, encoder);
+ if (ret < 0)
+ return ret;
+
+ drm_panel_attach(rgbcon->drmpanel, connector);
+ rgbcon->connector.encoder = renc;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h b/drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h
new file mode 100644
index 000000000000..b3bfad52f589
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_rgbcon.h
@@ -0,0 +1,22 @@
+/*
+ * rcar_du_rgbcon.h -- R-Car Display Unit RGB Connector
+ *
+ * Copyright (C) 2013-2020 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __RCAR_DU_RGBCON_H__
+#define __RCAR_DU_RGBCON_H__
+
+struct rcar_du_device;
+struct rcar_du_encoder;
+
+int rcar_du_rgb_connector_init(struct rcar_du_device *rcdu,
+ struct rcar_du_encoder *renc,
+ struct drm_panel *drmpanel);
+
+#endif /* __RCAR_DU_RGBCON_H__ */
--
2.17.1


[PATCH 4.4.y-cip 4/9] drm/panel: simple: Add EDT panel support

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

From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>

commit 82d57a590f51eb86e1ad0f24db257739ce0bfd74 upstream.

EDT ET043080DH6-GP is a 4.3" WQVGA 480x272 RGB LCD panel used on the iWave
Generic SODIMM Development Platform.

Changes in v2:
-added mandatory .connector_type field
-changed the .bus_format MEDIA_BUS_FMT_RGB666_1X18

Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1580386118-22895-3-git-send-email-marian-cristian.rotariu.rb@bp.renesas.com
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
[Removed connector type. Supporting the same requires framework changes]
---
drivers/gpu/drm/panel/panel-simple.c | 33 ++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index ecad4d7c6cd1..2b2a2f3da9a4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -614,6 +614,36 @@ static const struct panel_desc chunghwa_claa101wb01 = {
},
};

+static const struct drm_display_mode edt_etm043080dh6gp_mode = {
+ .clock = 10870,
+ .hdisplay = 480,
+ .hsync_start = 480 + 8,
+ .hsync_end = 480 + 8 + 4,
+ .htotal = 480 + 8 + 4 + 41,
+
+ /*
+ * IWG22M: Y resolution changed for "dc_linuxfb" module crashing while
+ * fb_align
+ */
+
+ .vdisplay = 288,
+ .vsync_start = 288 + 2,
+ .vsync_end = 288 + 2 + 4,
+ .vtotal = 288 + 2 + 4 + 10,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc edt_etm043080dh6gp = {
+ .modes = &edt_etm043080dh6gp_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 100,
+ .height = 65,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
static const struct drm_display_mode edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -1129,6 +1159,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "chunghwa,claa101wb01",
.data = &chunghwa_claa101wb01
+ }, {
+ .compatible = "edt,etm043080dh6gp",
+ .data = &edt_etm043080dh6gp,
}, {
.compatible = "edt,et057090dhu",
.data = &edt_et057090dhu,
--
2.17.1


[PATCH 4.4.y-cip 2/9] of: add node name compare helper functions

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

From: Rob Herring <robh@kernel.org>

commit f42b0e18f2e5cf34f73ef1b6327b49040b307a33 upstream.

In preparation to remove device_node.name pointer, add helper functions
for node name comparisons which are a common pattern throughout the kernel.

Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/of/base.c | 22 ++++++++++++++++++++++
include/linux/of.h | 13 +++++++++++++
2 files changed, 35 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 164eb1306661..b02f4b272e5b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -54,6 +54,28 @@ DEFINE_MUTEX(of_mutex);
*/
DEFINE_RAW_SPINLOCK(devtree_lock);

+bool of_node_name_eq(const struct device_node *np, const char *name)
+{
+ const char *node_name;
+ size_t len;
+
+ if (!np)
+ return false;
+
+ node_name = kbasename(np->full_name);
+ len = strchrnul(node_name, '@') - node_name;
+
+ return (strlen(name) == len) && (strncmp(node_name, name, len) == 0);
+}
+
+bool of_node_name_prefix(const struct device_node *np, const char *prefix)
+{
+ if (!np)
+ return false;
+
+ return strncmp(kbasename(np->full_name), prefix, strlen(prefix)) == 0;
+}
+
int of_n_addr_cells(struct device_node *np)
{
const __be32 *ip;
diff --git a/include/linux/of.h b/include/linux/of.h
index a09b9fb8e67d..1bef273a1909 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -231,6 +231,9 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
#define OF_IS_DYNAMIC(x) test_bit(OF_DYNAMIC, &x->_flags)
#define OF_MARK_DYNAMIC(x) set_bit(OF_DYNAMIC, &x->_flags)

+extern bool of_node_name_eq(const struct device_node *np, const char *name);
+extern bool of_node_name_prefix(const struct device_node *np, const char *prefix);
+
static inline const char *of_node_full_name(const struct device_node *np)
{
return np ? np->full_name : "<no-node>";
@@ -397,6 +400,16 @@ static inline struct device_node *to_of_node(struct fwnode_handle *fwnode)
return NULL;
}

+static inline bool of_node_name_eq(const struct device_node *np, const char *name)
+{
+ return false;
+}
+
+static inline bool of_node_name_prefix(const struct device_node *np, const char *prefix)
+{
+ return false;
+}
+
static inline const char* of_node_full_name(const struct device_node *np)
{
return "<no-node>";
--
2.17.1


[PATCH 4.4.y-cip 7/9] ARM: shmobile: defconfig: Enable frame buffer console for armadillo800eva

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

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

commit af48156ff3a1762989627fba7c56e77743fc0fdc upstream.

Enabling the frame buffer device on armadillo800eva requires the board
staging code.
Also enable the frame buffer, so you will actually see output during
boot.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
[Removed staging related configs]
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 9e48febd5956..f21de1bec37c 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -161,6 +161,7 @@ CONFIG_FB_SH_MOBILE_MERAM=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
CONFIG_BACKLIGHT_AS3711=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SOC=y
--
2.17.1


[PATCH 4.4.y-cip 6/9] drm: rcar-du: Use the DRM panel API

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

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit bf7149f34241dcd6c95ea76b2b5ab4ff33f1c9b9 upstream.

Instead of parsing the panel device tree node manually, use the panel
API to delegate panel handling to a panel driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
[Removed all other changes except Kconfig. This config is
required for building simple panel driver]
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index d4e0a39568f6..4261a302e051 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -21,6 +21,7 @@ config DRM_RCAR_HDMI
config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
+ select DRM_PANEL
depends on ARCH_R8A7790 || ARCH_R8A7791 || COMPILE_TEST
help
Enable support for the R-Car Display Unit embedded LVDS encoders
--
2.17.1

2021 - 2040 of 7074