On Wed 2019-04-10 08:09:14, nobuhiro1.iwamatsu@toshiba.co.jp wrote:

Hi, Biju.

This patch "arm64: dts: renesas: Initial device tree for r8a774c0" have
"arch/arm64/boot/dts/renesas/r8a774c0.dtsi"

https://lists.cip-project.org/pipermail/cip-dev/2019-March/001917.ht
ml

Do you want me to send it again?

You do not need to send.
This patch has been reviewed and committed to linux-4.19.y-cip
branch by me.

Thank you!

But I don't see anything new at
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/
. Did you forget to push or is it still processing?

Best regards,

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

Hi, Biju.

This patch "arm64: dts: renesas: Initial device tree for r8a774c0" have
"arch/arm64/boot/dts/renesas/r8a774c0.dtsi"

https://lists.cip-project.org/pipermail/cip-dev/2019-March/001917.ht
ml

Do you want me to send it again?

You do not need to send.
This patch has been reviewed and committed to linux-4.19.y-cip branch by me.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Biju Das
Sent: Wednesday, April 10, 2019 3:42 PM
To: Pavel Machek <pavel@denx.de>
Cc: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [PATCH 4.19.y 6/9] arm64: dts: renesas: r8a774c0:
Add I2C and IIC-DVFS support

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y 6/9] arm64: dts: renesas:
r8a774c0: Add I2C and IIC-DVFS support

On Wed 2019-03-27 12:13:06, Biju Das wrote:

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Add the I2C[0-7] and IIC Bus Interface for DVFS (IIC for DVFS)
devices nodes to the r8a774c0 device tree.

This fails for me, because arch/arm64/boot/dts/renesas/r8a774c0.dtsi
does not yet exist.

This patch "arm64: dts: renesas: Initial device tree for r8a774c0" have
"arch/arm64/boot/dts/renesas/r8a774c0.dtsi"

https://lists.cip-project.org/pipermail/cip-dev/2019-March/001917.ht
ml

Do you want me to send it again?

Regards,
Biju

_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y 6/9] arm64: dts: renesas: r8a774c0: Add
I2C and IIC-DVFS support

On Wed 2019-03-27 12:13:06, Biju Das wrote:

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Add the I2C[0-7] and IIC Bus Interface for DVFS (IIC for DVFS) devices
nodes to the r8a774c0 device tree.

This fails for me, because arch/arm64/boot/dts/renesas/r8a774c0.dtsi does
not yet exist.

This patch "arm64: dts: renesas: Initial device tree for r8a774c0" have "arch/arm64/boot/dts/renesas/r8a774c0.dtsi"

https://lists.cip-project.org/pipermail/cip-dev/2019-March/001917.html

Do you want me to send it again?

Regards,
Biju

Hi, all.

From: Biju Das <biju.das@bp.renesas.com>

commit fa930bb65cf930c48efc01cc90f928a8db99fa94 upstream.

This patch adds CMT{0|1|2|3} device nodes for r8a774c0 SoC.

I could not apply this, as arch/arm64/boot/dts/renesas/r8a774c0.dtsi does
not exist in my tree.

This was depended patch in charge.
I already applied and push to linux-4.19.y-cip branch.

Best regards,
Nobuhiro

________________________________________
差出人: cip-dev-bounces@lists.cip-project.org <cip-dev-bounces@lists.cip-project.org> が Pavel Machek <pavel@denx.de> の代理で送信
送信日時: 2019年4月10日 5:55
宛先: Fabrizio Castro
CC: cip-dev@lists.cip-project.org; Biju Das
件名: Re: [cip-dev] [PATCH 4.19.y 09/17] arm64: dts: renesas: r8a774c0: Add CMT device nodes

Hi!

From: Biju Das <biju.das@bp.renesas.com>

commit fa930bb65cf930c48efc01cc90f928a8db99fa94 upstream.

This patch adds CMT{0|1|2|3} device nodes for r8a774c0 SoC.

I could not apply this, as arch/arm64/boot/dts/renesas/r8a774c0.dtsi does
not exist in my tree.

Plus, you are pushing spdx comment changes. I guess it is ok if it makes your
life easier, but...

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

_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Hi, all.

This patch adds board cat874 (powered by the RZ/G2E) and board
cat875 (that sits on top of cat874). Both boards are made by Silicon Linux.

backported from commit 1a69a73c9b006ae72 ("dt-bindings: arm: renesas:
Add si-linux cat87[45] boards")

I applied this series, thanks.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Biju Das
Sent: Friday, March 22, 2019 1:22 AM
To: cip-dev@lists.cip-project.org
Cc: Biju Das <biju.das@bp.renesas.com>
Subject: [cip-dev] [PATCH 01/10] dt-bindings: arm: Add si-linux cat87[45]
boards

This patch adds board cat874 (powered by the RZ/G2E) and board
cat875 (that sits on top of cat874). Both boards are made by Silicon Linux.

backported from commit 1a69a73c9b006ae72 ("dt-bindings: arm: renesas:
Add si-linux cat87[45] boards")

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 7b1e257..1556460 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -131,6 +131,10 @@ Boards:
compatible = "renesas,salvator-xs", "renesas,r8a7796"
- Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S)
compatible = "renesas,salvator-xs", "renesas,r8a77965"
+ - Silicon Linux RZ/G2E 96board platform (CAT874)
+ compatible = "si-linux,cat874", "renesas,r8a774c0"
+ - Silicon Linux sub board for CAT874 (CAT875)
+ compatible = "si-linux,cat875", "si-linux,cat874",
"renesas,r8a774c0"
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"
- SK-RZG1E (YR8A77450S000BE)

On Mon 2019-04-01 14:55:38, Fabrizio Castro wrote:

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

commit c1e5bd286fe501992165608551f889ec69f5901a upstream.

This patch adds CAN{0,1} pins, groups and functions to the R8A77990 SoC.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

This does not apply. My kernel still has:

- struct sh_pfc_pin_group common[117];

while this expects... way higher number. I tried to look at pending patches
in patchwork, that maybe if I tried to apply everything it would work, but
could not get that to work, either.

Current status of the tree is at:

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

Could the patches that depend on each other go into one series? If it is
hard identifying what depends on what, maybe the best way forward is to
create a big series on top of 64729dc0be4847961550cdcca4ddc66adf556aaa
with all patches you have pending. Your patches seem to be in good shape,
so applying it should not be a big deal.

Thanks and sorry for confusion,
Pavel

@@ -3475,7 +3504,7 @@ static const unsigned int vin5_clk_b_mux[] = {
};

static const struct {
- struct sh_pfc_pin_group common[238];
+ struct sh_pfc_pin_group common[241];
struct sh_pfc_pin_group automotive[0];
} pinmux_groups = {
.common = {
@@ -3504,6 +3533,9 @@ static const struct {

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

On Fri 2019-03-22 09:40:00, Biju Das wrote:

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

This patch adds AUDIO_CLK{A,B,C}, AUDIO_CLKOUT, AUDIO_CLKOUT{1,2,3}
pins, groups and functions to the R8A77990 SoC.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[simon: rebase]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

(cherry picked from commit 4c833b2fa5b6b121cc657e5f24b8c3585a8c37ea)
Signed-off-by: Biju Das <biju.das@bp.renesas.com>

I could not apply this on c312fd1d432e36f9012127fe3c1d2b7023afae48-based tree.

I have struct sh_pfc_pin_group common[117];
while the patch expects struct sh_pfc_pin_group common[123];

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

Hi!

From: Biju Das <biju.das@bp.renesas.com>

commit fa930bb65cf930c48efc01cc90f928a8db99fa94 upstream.

This patch adds CMT{0|1|2|3} device nodes for r8a774c0 SoC.

I could not apply this, as arch/arm64/boot/dts/renesas/r8a774c0.dtsi does
not exist in my tree.

Plus, you are pushing spdx comment changes. I guess it is ok if it makes your
life easier, but...

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

On Fri 2019-03-29 08:32:34, Fabrizio Castro wrote:

Add PCIe support for the RZ/G2E (a.k.a. R8A774C0).

This does not apply.

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

On Wed 2019-03-27 12:13:06, Biju Das wrote:

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Add the I2C[0-7] and IIC Bus Interface for DVFS (IIC for DVFS)
devices nodes to the r8a774c0 device tree.

This fails for me, because arch/arm64/boot/dts/renesas/r8a774c0.dtsi does not yet exist.

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

On Fri 2019-03-22 09:56:17, Biju Das wrote:

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Document RZ/G2E (R8A774C0) SoC bindings.

This one rejected when I tried applying it.

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

On Fri 2019-03-29 08:51:37, Biju Das wrote:

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Document RZ/G2E (R8A774C0) SoC bindings.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 24105bf4d10485143f8e26337cda8bcb7f6e6da5)
Signed-off-by: Biju Das <biju.das@bp.renesas.com>

Thanks, applied.

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

On Thu 2019-03-21 14:24:13, Biju Das wrote:

The workaround for the wrong hierarchy of the 3DG-{A,B} power domains on
RZ/G2E ES1.0 corrected the parent domains. However, the 3DG-{A,B} power
domains were still initialized and powered in the wrong order, causing
3DG operation to fail.

Fix this by changing the order in the table at runtime, when running on
an affected SoC.

This work is based on the work done by Geert for R-Car E3.

Fixes: f37d211c687588328 ("soc: renesas: rcar-sysc: Add r8a774c0 support")

I prefer directly including good commit (rather than including bad commit and
then fixing it up). Let me try to fix it up.

Anyway, I merged this and the rest of the series.

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

On Thu 2019-03-21 15:30:37, Biju Das wrote:

Document PFC support for the R8A774A1 SoC.

Thanks, I applied the series.

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

Hi,

Last week I went to the Linaro connect in Bangkok and had very interesting meetings and conversations with other test engineers.
I also gave a talk [1] that included several Demos using the CIP testing infrastracture.
# Thanks to Renesas for providing the lab, everything worked great!

Summarizing, this is what I got working on our infrastructure:
- I showed how to convert Fuego tests into LAVA/Linaro test-definitions
https://lava.ciplatform.org/scheduler/job/1051/definition
https://github.com/sangorrin/test-definitions/tree/master/automated/linux/fuego
- I showed how to run any Fuego test from LAVA natively (I used Debos for the file system, but ISAR should work too)
https://lava.ciplatform.org/scheduler/job/1050/definition

[Note] apart from that I also showed how to run Fuego with Gitlab, Ktest (any Fuego test, including some LTP test case, can be used to bisect or check a series of patches), Yocto Ptests, and Linaro test definitions.

Other than that, I thought that it would be great if we can collaborate a bit more with other LTS kernel testing efforts such as LKFT (or KernelCI in the future). Not sure where to start that collaboration but I will give a few hints (some links provided by Naresh Kamboju):

- Test definitions
- LKFT: https://github.com/Linaro/test-definitions/
- CIP: https://gitlab.com/cip-project/cip-testing/cip-kernel-tests/tree/master

- Jobs definitions using templates (useful when you manage multiple devices)
- https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/lava-job-definitions

- Jenkins interface (maybe we can collaborate on using Gitlab instead)
- https://ci.linaro.org/job/openembedded-lkft-linux-stable-rc-4.19/131/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-lkft/

Thanks,
Daniel

[1] https://static.sched.com/hosted_files/bkk19/5f/linaro-connect-sangorrin-april2019.pdf

Hi,

I have added a Software updates comparison report to our wiki:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report

This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.

For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.

If you think that information in the comparison is not accurate or you want to complement it please let me know.

Thanks,
Daniel Sangorrin

Hello Pavel,

On Fri, Apr 05, 2019 at 11:47:31AM +0100, Patryk Mungai wrote:

Dear All,

When running dhcp tests using the 4.4.y (and 4.4.y-cip kernel as well), I
encountered an issue where the dhcp client in the kernel could not get an
IP address when multiple network devices were enabled. It seems that the
current implementation of the dhcp client in the 4.4 kernel is send dhcp
request via device 1 -> wait <1s for response from server on device 1 ->
if no response, switch to device 2 -> repeat process on device 2 ...etc.
When the dhcp server is slow to respond, this means it is impossible to get
a dhcp address.

This series backported from upstream fixes the issue, is it possible
to apply this to 4.4.y and/or 4.4.y-cip?

This is something that seems more suited for the CIP kernel as it adds
new functionality.

--
Thanks,
Sasha

Hi!

When running dhcp tests using the 4.4.y (and 4.4.y-cip kernel as well), I
encountered an issue where the dhcp client in the kernel could not get an
IP address when multiple network devices were enabled. It seems that the
current implementation of the dhcp client in the 4.4 kernel is send dhcp
request via device 1 -> wait <1s for response from server on device 1 ->
if no response, switch to device 2 -> repeat process on device 2 ...etc.
When the dhcp server is slow to respond, this means it is impossible to get
a dhcp address.

This series backported from upstream fixes the issue, is it possible
to apply this to 4.4.y and/or 4.4.y-cip?

Ok, so first patch adds support for using "delayed" DHCP replies, then
there are three more patches to fix up issues it creates.

Which tells me that maybe this is not quite suitable for -stable.

How long do your dhcp servers take to reply? Can you solve the problem
some other way, like for example increasing timeouts?

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

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

commit 1ae292a2457cd692828da2be87cb967260993ad0 upstream.

If no RARP, BOOTP, or DHCP response is received, ic_dev is never set,
causing a NULL pointer dereference in ic_close_devs():

Sending DHCP requests ...... timed out!
Unable to handle kernel NULL pointer dereference at virtual address 00000004

To fix this, add a check to avoid dereferencing ic_dev if it is still
NULL.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: 2647cffb2bc6fbed ("net: ipconfig: Support using "delayed" DHCP replies")
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patryk: cherry-picked to 4.4]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@renesas.com>
---
net/ipv4/ipconfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 6b78590..ca658af 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -313,7 +313,7 @@ static void __init ic_close_devs(void)
while ((d = next)) {
next = d->next;
dev = d->dev;
- if (dev != ic_dev->dev && !netdev_uses_dsa(dev)) {
+ if ((!ic_dev || dev != ic_dev->dev) && !netdev_uses_dsa(dev)) {
pr_debug("IP-Config: Downing %s\n", dev->name);
dev_change_flags(dev, d->flags);
}
--
2.7.4