|
Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms
Biju Das <biju.das.jz@...>
Hi Pavel,
Thanks for the feedback. Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additionalYes, 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
|
|
|
|
Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms
Pavel Machek
Hi!
I see it is already pushed, thank you!On Mon 2020-07-20 18:52:23, Biju Das wrote:Both patches seem to be okay to me.From: Geert Uytterhoeven <geert+renesas@...>Ok, I can apply this if there are no comments. Biju, the first patch seems like a bugfix suitable for -stable. Can you send it to Greg (etc) for inclusion? Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
|
|
|
|
[isar-cip-core] tests: put all tests into a opt layer
Daniel Sangorrin <daniel.sangorrin@...>
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without them as well Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...> --- .gitlab-ci.yml | 8 ++++---- README.md | 4 ++++ opt-tests.yml | 19 +++++++++++++++++++ recipes-core/customizations/customizations.bb | 5 ++--- recipes-core/images/cip-core-image.bb | 3 +-- 5 files changed, 30 insertions(+), 9 deletions(-) create mode 100644 opt-tests.yml diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 6f1dc91..90eec1f 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -13,17 +13,17 @@ all: - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY - - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster simatic-ipc227e - sudo rm -rf build/tmp - - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb - sudo rm -rf build/tmp - - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb - sudo rm -rf build/tmp - - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml + - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml - scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb diff --git a/README.md b/README.md index bbad1a0..7339396 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,10 @@ this: This image can be run using `start-qemu.sh x86`. +If you want to include the testing layer add ':opt-tests.yml' like this + + ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml + The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19. diff --git a/opt-tests.yml b/opt-tests.yml new file mode 100644 index 0000000..a1f431d --- /dev/null +++ b/opt-tests.yml @@ -0,0 +1,19 @@ +# +# CIP Core, generic profile +# +# Copyright (c) Toshiba corp., 2020 +# +# Authors: +# Daniel Sangorrin <daniel.sangorrin@...> +# +# SPDX-License-Identifier: MIT +# + +header: + version: 8 + +local_conf_header: + tests: | + IMAGE_INSTALL += "ltp-full" + IMAGE_PREINSTALL += "rt-tests stress-ng" + diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb index 38881fb..cbd6daf 100644 --- a/recipes-core/customizations/customizations.bb +++ b/recipes-core/customizations/customizations.bb @@ -11,7 +11,7 @@ inherit dpkg-raw -DESCRIPTION = "CIP Core image demo & test customizations" +DESCRIPTION = "CIP Core image demo customizations" SRC_URI = " \ file://postinst \ @@ -21,8 +21,7 @@ SRC_URI = " \ DEPENDS += "sshd-regen-keys" DEBIAN_DEPENDS = " \ - ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \ - rt-tests, stress-ng" + ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys" do_install() { install -v -d ${D}/etc/network/interfaces.d diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb index 9ee4b25..188c714 100644 --- a/recipes-core/images/cip-core-image.bb +++ b/recipes-core/images/cip-core-image.bb @@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always DESCRIPTION = "CIP Core image" IMAGE_INSTALL += "customizations" -# for cip-testing -IMAGE_INSTALL += "ltp-full" + -- 2.25.1
|
|
|
|
Re: Kindly review for kernel config changes
Kento Yoshida
isar-cip-core and deby share cip-kernel-config configuration files.I see. Thank you, Daniel. But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1". Do you have any information for this, Dinesh or Venkata? I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig. Or, have you already confirmed to build the image using this? BR, Kent -----Original Message-----
|
|
|
|
[PATCH 3/3] README: Add steps to build cip-security image
Venkata Pyla
From: venkata <venkata.pyla@...>
Signed-off-by: venkata <venkata.pyla@...> --- 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@...>
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@...> --- 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@...>
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@...> Signed-off-by: pvenkata2 <venkata.pyla@...> --- .../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@...> +# +# 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 <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@... <cip-dev@...> on behalf of Kento Yoshida <kento.yoshida.wz@...> Sent: Tuesday, July 21, 2020 4:12 PM To: cip-dev@... 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,
toggle quoted messageShow quoted text
Thanks for the feedback.
-----Original Message-----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
toggle quoted messageShow quoted text
-----Original Message-----Both patches seem to be okay to me. I will push to repository if there is no problem in our test. +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@...>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.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 */-- 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@...>
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@...> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@...> (VIN, CSI-2) Link: https://lore.kernel.org/r/20200217103251.5205-1-geert+renesas@glider.be Signed-off-by: Biju Das <biju.das.jz@...> [ 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@...>
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@...> Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@...> [kuninori: adjusted to upstream] Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...> Signed-off-by: Mark Brown <broonie@...> Signed-off-by: Biju Das <biju.das@...> --- 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!
It looks good to me, and it passed basic testing -- so I applied theFrom: Kazuhiro Fujita <kazuhiro.fujita.jg@...>Looks good to me. 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,
toggle quoted messageShow quoted text
Thanks for the feedback.
-----Original Message-----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@...>Looks good to me. Cc: <stable@...>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,
toggle quoted messageShow quoted text
-----Original Message-----Looks good to me. I will merge if nothing else is mentioned. Best regards, Nobuhiro ---
|
|
|