Date   

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.


[ANNOUNCE] v4.19.132-cip30-rt12

Pavel Machek
 

Hi!

v4.19.132-cip30-rt12 should be available at kernel.org.

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase

And their content should be identical.

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 06/23] PM / OPP: Manage device clk

Pavel Machek
 

Hi!

From: Viresh Kumar <viresh.kumar@linaro.org>

commit d54974c2513f487e9e70fbdc79c5da51c53e23da upstream.

OPP core has got almost everything now to manage device's OPP
transitions, the only thing left is device's clk. Get that as well.
@@ -620,6 +622,15 @@ static struct device_opp *_add_device_opp(struct device *dev)
of_node_put(np);
}

+ /* Find clk for the device */
+ dev_opp->clk = clk_get(dev, NULL);
+ if (IS_ERR(dev_opp->clk)) {
+ ret = PTR_ERR(dev_opp->clk);
+ if (ret != -EPROBE_DEFER)
+ dev_dbg(dev, "%s: Couldn't find clock: %d\n", __func__,
+ ret);
+ }
+
srcu_init_notifier_head(&dev_opp->srcu_head);
INIT_LIST_HEAD(&dev_opp->opp_list);
Strange. Same code exists in mainline (drivers/opp/core.c, function
name changed to _allocate_opp_table), and ret is directly overwritten
there.

That's definitely not usual way of handling -EPROBE_DEFER.

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 06/23] PM / OPP: Manage device clk

Pavel Machek
 

Hi!

From: Viresh Kumar <viresh.kumar@linaro.org>

commit d54974c2513f487e9e70fbdc79c5da51c53e23da upstream.

OPP core has got almost everything now to manage device's OPP
transitions, the only thing left is device's clk. Get that as well.
@@ -620,6 +622,15 @@ static struct device_opp *_add_device_opp(struct device *dev)
of_node_put(np);
}

+ /* Find clk for the device */
+ dev_opp->clk = clk_get(dev, NULL);
+ if (IS_ERR(dev_opp->clk)) {
+ ret = PTR_ERR(dev_opp->clk);
+ if (ret != -EPROBE_DEFER)
+ dev_dbg(dev, "%s: Couldn't find clock: %d\n", __func__,
+ ret);
+ }
+
Can you double check this piece? In case of clk_get() returning
EPROBE_DEFER, I'd expect this code to return it to the callers,
without continuing initialization.

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 22/23] PM / OPP: Remove useless check

Pavel Machek
 

Hi!

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 21f8a99ce61b2d4b74bd425a5bf7e9efbe162788 upstream.

Regulators are optional for devices using OPPs and the OPP core
shouldn't be printing any errors for such missing regulators.

It was fine before the commit 0c717d0f9cb4, but that failed to update
this part of the code to remove an 'always true' check and an extra
unwanted print message.

Fix that now.
So we have 2/ of the series, fixed by 18/ of the series, but 18/ is
buggy too, fixed by 22/. It would be good to have them close ... or
possibly merged or dropped.

Thank you,
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 18/23] PM / OPP: Initialize regulator pointer to an error value

Pavel Machek
 

On Wed 2020-07-08 23:45:49, Chen-Yu Tsai (Moxa) wrote:
From: Viresh Kumar <viresh.kumar@linaro.org>

commit 0c717d0f9cb46259dce5272705adce64a2d646d9 upstream.

We are currently required to do two checks for regulator pointer:
IS_ERR() and IS_NULL().

And multiple instances are reported, about both of these not being used
consistently and so resulting in crashes.

Fix that by initializing regulator pointer with an error value and
checking it only against an error.

This makes code more consistent and more efficient.
Again, this should be close to (or merged with) patch 2/ of the series.

Best regards,
Pavel

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

2521 - 2540 of 7463