Date   

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

Venkata Pyla
 

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
--
2.27.0.windows.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


[PATCH 2/3] start-qemu.sh: use TARGET_IMAGE to pick respective image file

Venkata Pyla
 

From: venkata <venkata.pyla@toshiba-tsip.com>

if 'TARGET_IMAGE' variable is not set then it pick "cip-core-image",
to pick different target image set the 'TARGET_IMAGE' variable as below
e.g: $TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64

Signed-off-by: venkata <venkata.pyla@toshiba-tsip.com>
---
start-qemu.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/start-qemu.sh b/start-qemu.sh
index 49f0266..5c17d74 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -75,7 +75,11 @@ 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}"
+if [ -z "${TARGET_IMAGE}" ]; then
+ TARGET_IMAGE="cip-core-image"
+fi
+
+IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/${TARGET_IMAGE}-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)

if [ -z "${DISPLAY}" ]; then
--
2.27.0.windows.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


[PATCH 1/3] cip-security: Add packages for IEC-62443-4-2 Evaluation.

Venkata Pyla
 

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: pvenkata2 <venkata.pyla@toshiba-tsip.com>
---
.../images/cip-core-image-security.bb | 37 +++++++++++++++++++
1 file changed, 37 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..8253952
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,37 @@
+#
+# 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"
+
+# Use the same customizations as cip-core-image
+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 \
+"
--
2.27.0.windows.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


Re: Kindly review for kernel config changes

Daniel Sangorrin
 

Hi Kent,

The configuration should go to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core.

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.

Actually that is a nother AI.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 4:12 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kindly review for kernel config changes

Hi,

The security working group need to use "nftables", and it requires to add the below kernel configs to work.
Before merging to the master branch of "isar-cip-core", would you kindly review to add the below configs by this Friday, everyone?

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,34 @@ 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_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_RBTREE=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_QUEUE=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_REJECT_INET=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_CHAIN_ROUTE_IPV4=y
+CONFIG_NFT_REJECT_IPV4=y
+CONFIG_NFT_CHAIN_NAT_IPV4=y
+CONFIG_NFT_MASQ_IPV4=y
+# CONFIG_NFT_REDIR_IPV4 is not set
+CONFIG_NFT_CHAIN_ROUTE_IPV6=y
+CONFIG_NFT_REJECT_IPV6=y
+CONFIG_NFT_CHAIN_NAT_IPV6=y
+CONFIG_NFT_MASQ_IPV6=y
+# CONFIG_NFT_REDIR_IPV6 is not set
+CONFIG_NFT_BRIDGE_META=y
+CONFIG_NFT_BRIDGE_REJECT=y
+CONFIG_NF_LOG_BRIDGE=y

BR, Kent


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

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

Hi Pavel and Nobuhiro,

Thanks for the feedback.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp
<nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 21 July 2020 01:43
To: pavel@denx.de; Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Chris Paterson
<Chris.Paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: RE: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional
support for Renesas platforms

Hi, all

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Tuesday, July 21, 2020 6:00 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>; Pavel Machek <pavel@denx.de>;
Chris Paterson <chris.paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable
additional support for Renesas platforms

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more
hardware present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.


Should we have some updates for cip-kernel-config?
+1.
It should be updated as well.
Yes Will do.

Regards,
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


Kindly review for kernel config changes

Kento Yoshida
 

Hi,

 

The security working group need to use "nftables", and it requires to add the below kernel configs to work.

Before merging to the master branch of "isar-cip-core", would you kindly review to add the below configs by this Friday, everyone?

 

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig

+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig

@@ -351,3 +351,34 @@ 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_NF_TABLES=y

+CONFIG_NF_TABLES_INET=y

+CONFIG_NF_TABLES_NETDEV=y

+CONFIG_NFT_EXTHDR=y

+CONFIG_NFT_META=y

+CONFIG_NFT_CT=y

+CONFIG_NFT_RBTREE=y

+CONFIG_NFT_HASH=y

+CONFIG_NFT_COUNTER=y

+CONFIG_NFT_LOG=y

+CONFIG_NFT_LIMIT=y

+CONFIG_NFT_MASQ=y

+CONFIG_NFT_REDIR=y

+CONFIG_NFT_NAT=y

+CONFIG_NFT_QUEUE=y

+CONFIG_NFT_REJECT=y

+CONFIG_NFT_REJECT_INET=y

+CONFIG_NFT_COMPAT=y

+CONFIG_NFT_CHAIN_ROUTE_IPV4=y

+CONFIG_NFT_REJECT_IPV4=y

+CONFIG_NFT_CHAIN_NAT_IPV4=y

+CONFIG_NFT_MASQ_IPV4=y

+# CONFIG_NFT_REDIR_IPV4 is not set

+CONFIG_NFT_CHAIN_ROUTE_IPV6=y

+CONFIG_NFT_REJECT_IPV6=y

+CONFIG_NFT_CHAIN_NAT_IPV6=y

+CONFIG_NFT_MASQ_IPV6=y

+# CONFIG_NFT_REDIR_IPV6 is not set

+CONFIG_NFT_BRIDGE_META=y

+CONFIG_NFT_BRIDGE_REJECT=y

+CONFIG_NF_LOG_BRIDGE=y

 

BR, Kent


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Nobuhiro Iwamatsu
 

Hi, all

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Tuesday, July 21, 2020 6:00 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>; Pavel Machek <pavel@denx.de>; Chris Paterson <chris.paterson2@renesas.com>;
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more hardware
present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.


Should we have some updates for cip-kernel-config?
+1.
It should be updated as well.

Best regards,
Nobuhiro


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Pavel Machek
 

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more hardware
present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.

Should we have some updates for cip-kernel-config?

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


Re: [PATCH 4.19.y-cip 1/2] ASoC: rsnd: fixup SSI clock during suspend/resume modes

Pavel Machek
 

Hi!

commit 624d1a7cd8991e33dad96ab4629a52c412540e65 upstream.

Prepare <-> Cleanup functions pair has balanced calls.
But in case of suspend mode no call to rsnd_soc_dai_shutdown()
function, so cleanup isn't called. OTOH during resume mode
function rsnd_soc_dai_prepare() is called, but calling
rsnd_ssi_prepare() is skipped (rsnd_status_update() returns zero,
bacause was not cleanup before).
We need to call rsnd_ssi_prepare(), because it enables SSI clocks
by calling rsnd_ssi_master_clk_start().

This patch allows to call prepare/cleanup functions always.
Ok, this is "interesting". It has something to do with rsnd_dai_call()
macro.

You really should not be programming drivers in preprocessor like
this.

OTOH patch is simple enough, and only affects "your" code, so ... I'll
apply it if there are no other comments.

#define __rsnd_mod_shift_hw_params 28 /* always called */
#define __rsnd_mod_shift_pointer 28 /* always called */
+#define __rsnd_mod_shift_prepare 28 /* always called */
+#define __rsnd_mod_shift_cleanup 28 /* always called */

#define __rsnd_mod_add_probe 0
#define __rsnd_mod_add_remove 0
-#define __rsnd_mod_add_prepare 1
-#define __rsnd_mod_add_cleanup -1
+#define __rsnd_mod_add_prepare 0
+#define __rsnd_mod_add_cleanup 0
#define __rsnd_mod_add_init 1
#define __rsnd_mod_add_quit -1
#define __rsnd_mod_add_start 1
@@ -365,7 +365,7 @@ struct rsnd_mod {
#define __rsnd_mod_call_probe 0
#define __rsnd_mod_call_remove 0
#define __rsnd_mod_call_prepare 0
-#define __rsnd_mod_call_cleanup 1
+#define __rsnd_mod_call_cleanup 0
#define __rsnd_mod_call_init 0
#define __rsnd_mod_call_quit 1
#define __rsnd_mod_call_start 0
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

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

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

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more hardware
present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
- MSIOF SPI controllers,
- ROHM BD9571 GPIO support,
- R-Car MIPI CSI-2 receivers,
- R-Car Video Input,
- Renesas Fine Display Processors,
- Renesas Digital Radio Interfaces,
- R-Car Gen3 internal HDMI encoders,
- Generic LVDS panel support,
- Dumb VGA DAC Bridge support,
- Thine THC63LVD1024 LVDS decoder bridges,
- Synopsys Designware AHB Audio and CEC interfaces,
- Renesas USBHS HCD support,
- IDT VersaClock 5,6 devices,
- Maxim max9611/max9612 ADCs,
- ARM TrustZone CryptoCell security processors.

All of the above are modular, except for the VC5 clock driver, and the
SDR config gatekeepers.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> (VIN, CSI-2)
Link: https://lore.kernel.org/r/20200217103251.5205-1-geert+renesas@glider.be
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
[ Removed the following R-Car Specific configs
- ROHM BD9571 GPIO support,
- Renesas Digital Radio Interfaces,
- Dumb VGA DAC Bridge support,
- Thine THC63LVD1024 LVDS decoder bridges,
- Maxim max9611/max9612 ADCs,
- ARM TrustZone CryptoCell security processors.
Added Synopsys Designware HDMI I2S interface
]
---
arch/arm64/configs/defconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8ae8008..64a116b 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -154,6 +154,9 @@ CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
CONFIG_BPF_JIT=y
+CONFIG_CAN=m
+CONFIG_CAN_RCAR=m
+CONFIG_CAN_RCAR_CANFD=m
CONFIG_BT=m
CONFIG_BT_HIDP=m
# CONFIG_BT_HS is not set
@@ -329,6 +332,7 @@ CONFIG_SPI_PL022=y
CONFIG_SPI_ROCKCHIP=y
CONFIG_SPI_QUP=y
CONFIG_SPI_S3C64XX=y
+CONFIG_SPI_SH_MSIOF=m
CONFIG_SPI_SPIDEV=m
CONFIG_SPMI=y
CONFIG_PINCTRL_SINGLE=y
@@ -424,9 +428,12 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
+CONFIG_VIDEO_RCAR_CSI2=m
+CONFIG_VIDEO_RCAR_VIN=m
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
+CONFIG_VIDEO_RENESAS_FDP1=m
CONFIG_VIDEO_RENESAS_FCP=m
CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_DRM=m
@@ -446,10 +453,15 @@ CONFIG_ROCKCHIP_DW_HDMI=y
CONFIG_ROCKCHIP_DW_MIPI_DSI=y
CONFIG_ROCKCHIP_INNO_HDMI=y
CONFIG_DRM_RCAR_DU=m
+CONFIG_DRM_RCAR_DW_HDMI=m
CONFIG_DRM_RCAR_LVDS=m
CONFIG_DRM_TEGRA=m
+CONFIG_DRM_PANEL_LVDS=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=m
+CONFIG_DRM_DW_HDMI_CEC=m
CONFIG_DRM_VC4=m
CONFIG_DRM_HISI_HIBMC=m
CONFIG_DRM_HISI_KIRIN=m
@@ -493,6 +505,7 @@ CONFIG_USB_EHCI_HCD_PLATFORM=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_RENESAS_USBHS_HCD=m
CONFIG_USB_RENESAS_USBHS=m
CONFIG_USB_STORAGE=y
CONFIG_USB_MUSB_HDRC=y
@@ -584,6 +597,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_S2MPS11=y
CONFIG_CLK_QORIQ=y
CONFIG_COMMON_CLK_PWM=y
+CONFIG_COMMON_CLK_VC5=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_QCOM_CLK_SMD_RPM=y
CONFIG_IPQ_GCC_8074=y
--
2.7.4


[PATCH 4.19.y-cip 1/2] ASoC: rsnd: fixup SSI clock during suspend/resume modes

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

From: Dmytro Prokopchuk <dmytro.prokopchuk@globallogic.com>

commit 624d1a7cd8991e33dad96ab4629a52c412540e65 upstream.

Prepare <-> Cleanup functions pair has balanced calls.
But in case of suspend mode no call to rsnd_soc_dai_shutdown()
function, so cleanup isn't called. OTOH during resume mode
function rsnd_soc_dai_prepare() is called, but calling
rsnd_ssi_prepare() is skipped (rsnd_status_update() returns zero,
bacause was not cleanup before).
We need to call rsnd_ssi_prepare(), because it enables SSI clocks
by calling rsnd_ssi_master_clk_start().

This patch allows to call prepare/cleanup functions always.

Signed-off-by: Dmytro Prokopchuk <dmytro.prokopchuk@globallogic.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
[kuninori: adjusted to upstream]
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
sound/soc/sh/rcar/dma.c | 7 +++----
sound/soc/sh/rcar/rsnd.h | 14 +++++++-------
2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c
index 83bf0f6..58da57e 100644
--- a/sound/soc/sh/rcar/dma.c
+++ b/sound/soc/sh/rcar/dma.c
@@ -134,10 +134,9 @@ static int rsnd_dmaen_prepare(struct rsnd_mod *mod,
struct rsnd_dmaen *dmaen = rsnd_dma_to_dmaen(dma);
struct device *dev = rsnd_priv_to_dev(priv);

- if (dmaen->chan) {
- dev_err(dev, "it already has dma channel\n");
- return -EIO;
- }
+ /* maybe suspended */
+ if (dmaen->chan)
+ return 0;

/*
* DMAEngine request uses mutex lock.
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index c449d9f..31bf791 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -320,9 +320,8 @@ struct rsnd_mod {
/*
* status
*
- * 0xH0000CBA
+ * 0xH0000CB0
*
- * A 0: prepare 1: cleanup
* B 0: init 1: quit
* C 0: start 1: stop
*
@@ -333,9 +332,8 @@ struct rsnd_mod {
* H 0: hw_params
* H 0: pointer
* H 0: prepare
+ * H 0: cleanup
*/
-#define __rsnd_mod_shift_prepare 0
-#define __rsnd_mod_shift_cleanup 0
#define __rsnd_mod_shift_init 4
#define __rsnd_mod_shift_quit 4
#define __rsnd_mod_shift_start 8
@@ -347,11 +345,13 @@ struct rsnd_mod {
#define __rsnd_mod_shift_fallback 28 /* always called */
#define __rsnd_mod_shift_hw_params 28 /* always called */
#define __rsnd_mod_shift_pointer 28 /* always called */
+#define __rsnd_mod_shift_prepare 28 /* always called */
+#define __rsnd_mod_shift_cleanup 28 /* always called */

#define __rsnd_mod_add_probe 0
#define __rsnd_mod_add_remove 0
-#define __rsnd_mod_add_prepare 1
-#define __rsnd_mod_add_cleanup -1
+#define __rsnd_mod_add_prepare 0
+#define __rsnd_mod_add_cleanup 0
#define __rsnd_mod_add_init 1
#define __rsnd_mod_add_quit -1
#define __rsnd_mod_add_start 1
@@ -365,7 +365,7 @@ struct rsnd_mod {
#define __rsnd_mod_call_probe 0
#define __rsnd_mod_call_remove 0
#define __rsnd_mod_call_prepare 0
-#define __rsnd_mod_call_cleanup 1
+#define __rsnd_mod_call_cleanup 0
#define __rsnd_mod_call_init 0
#define __rsnd_mod_call_quit 1
#define __rsnd_mod_call_start 0
--
2.7.4


Re: [PATCH 4.4.y-cip] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

Pavel Machek
 

Hi!

From: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>

commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream.

For SCIF and HSCIF interfaces the SCxSR register holds the status of
data that is to be read next from SCxRDR register, But where as for
SCIFA and SCIFB interfaces SCxSR register holds status of data that is
previously read from SCxRDR register.

This patch makes sure the status register is read depending on the port
types so that errors are caught accordingly.

Cc: <stable@vger.kernel.org>
Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>
Signed-off-by: Hao Bui <hao.bui.yg@renesas.com>
Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Looks good to me.
I will merge if nothing else is mentioned.
It looks good to me, and it passed basic testing -- so I applied the
patch and am pushing it. (I hope you don't mind).

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] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

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

Hi Pavel,

Thanks for the feedback.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 17 July 2020 09:25
To: cip-dev@lists.cip-project.org
Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel
Machek <pavel@denx.de>; Chris Paterson <Chris.Paterson2@renesas.com>;
Biju Das <biju.das.jz@bp.renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [cip-dev] [PATCH 4.4.y-cip] serial: sh-sci: Make sure status
register SCxSR is read in correct sequence

Hi!

From: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>

commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream.

For SCIF and HSCIF interfaces the SCxSR register holds the status of
data that is to be read next from SCxRDR register, But where as for
SCIFA and SCIFB interfaces SCxSR register holds status of data that is
previously read from SCxRDR register.

This patch makes sure the status register is read depending on the
port types so that errors are caught accordingly.
Looks good to me.

Cc: <stable@vger.kernel.org>
I notice this applies cleanly to v4.4-stable. Was this submitted to
4.4 / do you need some help there?
The original patch is not cleanly applied on 4.4 see the mail below

https://www.spinics.net/lists/linux-renesas-soc/msg48219.html

Does this have user-visible impact?
No, You can verify this on console after applying the patch.

stty evenp

Test Case 1:

paste "p" on the console should generate parity error and "o" should not

Test Case 2:-

paste "ppppp" on the console should generate parity error and "ooooo" should not

Testcase 3:-

Paste "pop", it should generate parity error for "p"

Regards,
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] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

Pavel Machek
 

Hi!

From: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>

commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream.

For SCIF and HSCIF interfaces the SCxSR register holds the status of
data that is to be read next from SCxRDR register, But where as for
SCIFA and SCIFB interfaces SCxSR register holds status of data that is
previously read from SCxRDR register.

This patch makes sure the status register is read depending on the port
types so that errors are caught accordingly.
Looks good to me.

Cc: <stable@vger.kernel.org>
I notice this applies cleanly to v4.4-stable. Was this submitted to
4.4 / do you need some help there?

Does this have user-visible impact?

Best regards,

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


Notes from realtime meeting, questions for companies using realtime

Pavel Machek
 

Hi!

This week I attended virtual RT meeting, and have couple of notes, and
couple of questions.

Intel was biggest sponsor of RT, and they are decreasing their
funding. So RT project is looking for ... more funding. If we can
provide funding, or know someone who could, there might be good time
to step in.

They still believe most of RT patch can be merged in 5.10, which would
be around end of 2020. But there was interesting question "which
architecture(s) would be present in initial merge". And it looks like
x86 is the initial target (which kind of makes sense given that Intel
is/was the biggest sponsor, and it is "main" Linux architecture; otoh
I'd say x86 is not exactly suitable for realtime/safety related
tasks...). ARM32 and ARM64 is on the radar.

It would be interesting to know:

## Who is using RT in production? On what architectures?

## Is someone planning RT use? If so, on what architectures?

There will be RT microconference (on Plumbers, IIRC). RT project
believes it would be cool if someone from industry stepped up and
explained how they use RT. (It would be interesting for me, too, so it
sounds like a good idea). Is someone willing to do that?

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH 4.4.y-cip] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Biju Das [mailto:biju.das.jz@bp.renesas.com]
Sent: Thursday, July 16, 2020 10:24 PM
To: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Chris Paterson <chris.paterson2@renesas.com>; Biju Das <biju.das.jz@bp.renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: [PATCH 4.4.y-cip] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

From: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>

commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream.

For SCIF and HSCIF interfaces the SCxSR register holds the status of
data that is to be read next from SCxRDR register, But where as for
SCIFA and SCIFB interfaces SCxSR register holds status of data that is
previously read from SCxRDR register.

This patch makes sure the status register is read depending on the port
types so that errors are caught accordingly.

Cc: <stable@vger.kernel.org>
Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>
Signed-off-by: Hao Bui <hao.bui.yg@renesas.com>
Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Looks good to me.
I will merge if nothing else is mentioned.

Best regards,
Nobuhiro

---
drivers/tty/serial/sh-sci.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 22f7201..2b5b342 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -793,9 +793,16 @@ static void sci_receive_chars(struct uart_port *port)
tty_insert_flip_char(tport, c, TTY_NORMAL);
} else {
for (i = 0; i < count; i++) {
- char c = serial_port_in(port, SCxRDR);
-
- status = serial_port_in(port, SCxSR);
+ char c;
+
+ if (port->type == PORT_SCIF ||
+ port->type == PORT_HSCIF) {
+ status = serial_port_in(port, SCxSR);
+ c = serial_port_in(port, SCxRDR);
+ } else {
+ c = serial_port_in(port, SCxRDR);
+ status = serial_port_in(port, SCxSR);
+ }
#if defined(CONFIG_CPU_SH3)
/* Skip "chars" during break */
if (sci_port->break_flag) {
--
2.7.4


[PATCH 4.4.y-cip] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

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

From: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>

commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream.

For SCIF and HSCIF interfaces the SCxSR register holds the status of
data that is to be read next from SCxRDR register, But where as for
SCIFA and SCIFB interfaces SCxSR register holds status of data that is
previously read from SCxRDR register.

This patch makes sure the status register is read depending on the port
types so that errors are caught accordingly.

Cc: <stable@vger.kernel.org>
Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>
Signed-off-by: Hao Bui <hao.bui.yg@renesas.com>
Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/tty/serial/sh-sci.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 22f7201..2b5b342 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -793,9 +793,16 @@ static void sci_receive_chars(struct uart_port *port)
tty_insert_flip_char(tport, c, TTY_NORMAL);
} else {
for (i = 0; i < count; i++) {
- char c = serial_port_in(port, SCxRDR);
-
- status = serial_port_in(port, SCxSR);
+ char c;
+
+ if (port->type == PORT_SCIF ||
+ port->type == PORT_HSCIF) {
+ status = serial_port_in(port, SCxSR);
+ c = serial_port_in(port, SCxRDR);
+ } else {
+ c = serial_port_in(port, SCxRDR);
+ status = serial_port_in(port, SCxSR);
+ }
#if defined(CONFIG_CPU_SH3)
/* Skip "chars" during break */
if (sci_port->break_flag) {
--
2.7.4


Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi,

I can't attend today's IRC meeting.

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
No update.
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu
No update.

* Kernel maintenance updates
I reviewed 4.4.y-rc patches.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, July 16, 2020 10:30 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according
to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=16&hour=9&min=0&sec=0&p1=224&p2=
179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/07/cip.2020-07-09-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics
can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: CIP IRC weekly meeting today

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

Hi,

On Thu, Jul 16, 2020 at 9:30 AM masashi.kudo@cybertrust.co.jp
<masashi.kudo@cybertrust.co.jp> wrote:

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=16&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/07/cip.2020-07-09-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
I might not make it, so here are updates from me for this week:

Two new issues:

- CVE-2020-11935 (aufs, not applicable to mainline)
- CVE-2020-14314 (ext4 related, fix posted)


Regards
ChenYu

* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=16&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/07/cip.2020-07-09-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.

1881 - 1900 of 6828