Date   

[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


Re: [PATCH 4.4.y-cip 17/23] PM / OPP: Fix NULL pointer dereference crash when disabling OPPs

Pavel Machek
 

Hi!

On Wed 2020-07-08 23:45:48, Chen-Yu Tsai (Moxa) wrote:
From: Jon Hunter <jonathanh@nvidia.com>

commit 78ecc56247f0ec2bc0cf6f2f2af69e98d99767bc upstream.

Commit 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by
the regulator) causes a crash to happen on Tegra124 Jetson TK1 when
using the DFLL clock source for the CPU. The DFLL manages the voltage
itself and so there is no regulator specified for the OPPs and so we
get a crash when we try to dereference the regulator pointer. Fix
this by checking to see if the regulator IS_ERR_OR_NULL before
dereferencing it.

Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by
So this one should be close to the patch it fixes, or maybe squashed
together.

Best regards,
Pavel

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 91b4cc261d84a..067379f931662 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -975,7 +975,7 @@ static bool _opp_supported_by_regulators(struct dev_pm_opp *opp,
{
struct regulator *reg = dev_opp->regulator;

- if (!IS_ERR(reg) &&
+ if (!IS_ERR_OR_NULL(reg) &&
!regulator_is_supported_voltage(reg, opp->u_volt_min,
opp->u_volt_max)) {
pr_warn("%s: OPP minuV: %lu maxuV: %lu, not supported by regulator\n",
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.4.y-cip 00/23] PM / OPP v2 & cpufreq backports part 2

Pavel Machek
 

Hi!

This is part 2 of MOXA's PM / OPP / cpufreq backport series. The whole
series aims to backport patches related to PM / OPPv2 and cpufreq
which were included in the v4.4 kernel from TI's SDK. The end goal is
to include cpufreq-ti and convert am33xx to using it and OPPv2.
Ok, I went through them, and most of them are ok.

OTOH lots of them are changing common code, and I don't believe all of
them are neccessary for am33xx support.

Could you identify changes that are not neccesary for am33xx support,
and drop those?

Could the fixes be moved closer to patch they fix (ideally merged
together)?

Best regards,
Pavel


Part 2 here includes patches from the v4.6 cycle, as well as additional
fixed found through Fixes tags:

9f8ea969d5cf PM / OPP: get/put regulators from OPP core
7d34d56ef334 PM / OPP: Disable OPPs that aren't supported by the regulator
655c9df96175 PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()
2174344765f4 PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()
50f8cfbd5897 PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindings
d54974c2513f PM / OPP: Manage device clk
6a0712f6f199 PM / OPP: Add dev_pm_opp_set_rate()
896d6a4c0f41 cpufreq: dt: Convert few pr_debug/err() calls to dev_dbg/err()
457e99e60a8f cpufreq: dt: Rename 'need_update' to 'opp_v1'
391d9aef8145 cpufreq: dt: OPP layers handles clock-latency for V1 bindings as well
050794aaebbb cpufreq: dt: Pass regulator name to the OPP core
6def6ea75e6d cpufreq: dt: Unsupported OPPs are already disabled
755b888ff098 cpufreq: dt: Reuse dev_pm_opp_get_max_transition_latency()
78c3ba5df96c cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
df2c8ec28e73 cpufreq: dt: No need to fetch voltage-tolerance
dd02a3d92008 cpufreq: dt: No need to allocate resources anymore
78ecc56247f0 PM / OPP: Fix NULL pointer dereference crash when disabling OPPs
0c717d0f9cb4 PM / OPP: Initialize regulator pointer to an error value
a5da64477ee7 PM / OPP: Fix incorrect comments
2c2709dc6921 PM / OPP: Rename structures for clarity
b318556479cc cpufreq: dt: Drop stale comment
21f8a99ce61b PM / OPP: Remove useless check
c5c2a97b3ac7 PM / OPP: Update voltage in case freq == old_freq

Of these,

b318556479cc cpufreq: dt: Drop stale comment

was found while looking through git logs.

21f8a99ce61b PM / OPP: Remove useless check
c5c2a97b3ac7 PM / OPP: Update voltage in case freq == old_freq

were found by looking for commit hashes in Fixes tags.
All other patches were included from TI's SDK.

The patches apply cleanly on top of linux-4.4.y-cip. The last patch
involved some backporting due to path and code changes between v4.6
and v4.18.

Please have a look.


Regards
ChenYu


Jon Hunter (1):
PM / OPP: Fix NULL pointer dereference crash when disabling OPPs

Viresh Kumar (21):
PM / OPP: get/put regulators from OPP core
PM / OPP: Disable OPPs that aren't supported by the regulator
PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()
PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()
PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindings
PM / OPP: Manage device clk
PM / OPP: Add dev_pm_opp_set_rate()
cpufreq: dt: Convert few pr_debug/err() calls to dev_dbg/err()
cpufreq: dt: Rename 'need_update' to 'opp_v1'
cpufreq: dt: OPP layers handles clock-latency for V1 bindings as well
cpufreq: dt: Pass regulator name to the OPP core
cpufreq: dt: Unsupported OPPs are already disabled
cpufreq: dt: Reuse dev_pm_opp_get_max_transition_latency()
cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
cpufreq: dt: No need to fetch voltage-tolerance
cpufreq: dt: No need to allocate resources anymore
PM / OPP: Initialize regulator pointer to an error value
PM / OPP: Fix incorrect comments
PM / OPP: Rename structures for clarity
cpufreq: dt: Drop stale comment
PM / OPP: Remove useless check

Waldemar Rymarkiewicz (1):
PM / OPP: Update voltage in case freq == old_freq

drivers/base/power/opp/core.c | 1066 +++++++++++++++++++++---------
drivers/base/power/opp/cpu.c | 22 +-
drivers/base/power/opp/debugfs.c | 85 ++-
drivers/base/power/opp/opp.h | 74 ++-
drivers/cpufreq/cpufreq-dt.c | 303 +++------
include/linux/pm_opp.h | 27 +
6 files changed, 973 insertions(+), 604 deletions(-)

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


Re: v4.19-rt status

Pavel Machek
 

Hi!

Newest 4.19-rt kernel is currently v4.19.127-rt54. That's not good
match for us, as -cip kernels are v4.19.128-cip28 and v4.19.130-cip29.

I could do kernel based on v4.19.127-rt54 and v4.19.124-cip27, but I
believe it makes more sense to wait for newer v4.19-rt release.
Still no new -rt release.

In April, Tom Zanussi took over 4.19-rt releases:

Apr 20 Linux 4.19.115-rt49
Apr 28 Linux 4.19.115-rt50
May 3 Linux 4.19.116-rt51
May 4 Linux 4.19.120-rt52
May 20 Linux 4.19.124-rt53
Jun 7 Linux 4.19.127-rt54
Jun 10 Linux 4.19.127-rt55

Based on past releases, I'd expect new -rt release real soon
now. Hmm. I guess easiest option is to just ask Tom ;-)... and I did
that.
And Tom said he expects new release this Monday. With new -cip kernel
released, that should be good timing.

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


[ANNOUNCE] Release v4.19.132-cip30 and v4.4.230-cip47

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.132-cip30 and v4.4.230-cip47.
The linux-4.19.y-cip tree has been updated base version from v4.19.130 to v4.19.132,
and linux-4.4.y-cip tree has been updated base version from v4.4.227 to v4.4.230.
You can get this release via the git tree at:

v4.19.132-cip29:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
4da95b68eb2b04de4ec212c17db4863d0301e7f9
added commits:
CIP: Bump version suffix to -cip30 after merge from stable

v4.4.230-cip47:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
fec45d1a4e38bbe5cc9248c9400748c857052bb6
added commits:
CIP: Bump version suffix to -cip47 after merge from stable

Best regards,
Nobuhiro


KernelCI Community Survey Report

Chris Paterson
 

Hello all,

If you're interested, the KernelCI project have published the results of their first user survey:
https://foundation.kernelci.org/blog/2020/07/09/kernelci-community-survey-report/

Kind regards, Chris

2121 - 2140 of 7058