Hi,

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

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@...>
Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@...>
Signed-off-by: Hao Bui <hao.bui.yg@...>
Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
Tested-by: Geert Uytterhoeven <geert+renesas@...>
Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
Signed-off-by: Biju Das <biju.das.jz@...>
---
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

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@... [mailto:cip-dev@...] On Behalf Of
masashi.kudo@...
Sent: Thursday, July 16, 2020 10:30 AM
To: cip-dev@...
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.

Hi,

On Thu, Jul 16, 2020 at 9:30 AM masashi.kudo@...
<masashi.kudo@...> 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.

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.

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

Hi!

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

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

Hi!

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

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

Hi!

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

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

On Wed 2020-07-08 23:45:49, Chen-Yu Tsai (Moxa) wrote:

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

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

Hi!

On Wed 2020-07-08 23:45:48, Chen-Yu Tsai (Moxa) wrote:

From: Jon Hunter <jonathanh@...>

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

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

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

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

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

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

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.

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

Hi!

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

I am not sure if I'll be able to make it to the meeting.

My work last week: reviews of patches for 4.19.131 and 4.19.132. I
took a look at "PM / OPP v2 & cpufreq backports part 2" and will have
some comments there.

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

Hi,