Date   

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

Pavel Machek
 

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


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

Nobuhiro Iwamatsu
 

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


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

Biju Das <biju.das@...>
 

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


Re: [PATCH 4.19.y 09/17] arm64: dts: renesas: r8a774c0: Add CMT device nodes

Nobuhiro Iwamatsu
 

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


Re: [PATCH 01/10] dt-bindings: arm: Add si-linux cat87[45] boards

Nobuhiro Iwamatsu
 

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)


Re: [PATCH 4.19y 01/10] pinctrl: sh-pfc: r8a77990: Add CAN pins, groups and functions

Pavel Machek
 

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


Re: [PATCH 01/11] pinctrl: sh-pfc: r8a77990: Add Audio clock pins, groups and functions

Pavel Machek
 

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


Re: [PATCH 4.19.y 09/17] arm64: dts: renesas: r8a774c0: Add CMT device nodes

Pavel Machek
 

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


Re: [PATCH 4.19.y 1/4] dt-bindings: PCI: rcar: Add device tree support for r8a774c0

Pavel Machek
 

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


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

Pavel Machek
 

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


Re: [PATCH 1/5] dt-bindings: net: ravb: Add support for r8a774c0 SoC

Pavel Machek
 

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


Re: [PATCH 4.19.y] dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support

Pavel Machek
 

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


Re: [PATCH 15/18] soc: renesas: r8a774c0-sysc: Fix initialization order of 3DG-{A, B}

Pavel Machek
 

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


Re: [PATCH 1/7] dt-bindings: pinctrl: sh-pfc: Document r8a774a1 PFC support

Pavel Machek
 

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


CIP testing

daniel.sangorrin@...
 

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


Software updates comparison

daniel.sangorrin@...
 

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


Re: [PATCH 4.4 0/5] DHCP client support when receiving "delayed" replies

Patryk Mungai Ndungu <patryk.mungai-ndungu.kx@...>
 

Hello Pavel,

-----Original Message-----
From: stable-owner@vger.kernel.org <stable-owner@vger.kernel.org> On
Behalf Of Pavel Machek
Sent: 06 April 2019 11:39
To: Patryk Mungai Ndungu <patryk.mungai-ndungu.kx@renesas.com>
Cc: stable@vger.kernel.org; davem@davemloft.net; cip-dev@lists.cip-
project.org
Subject: Re: [cip-dev] [PATCH 4.4 0/5] DHCP client support when receiving
"delayed" replies

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?
It varies: the fastest reply I've seen is 0.12931s, the slowest is in the region is just over 1.007s.
In the tests I've run, I measured the time between the kernel sending out the DHCP request and receiving a DHCP offer from the server. After running 50 tests, in around half of them, it takes just over 1s for the DHCP offer to arrive. But this is rarely over 1s +1 jiffie, hence why I think the code is able to cope with it most of the time.

However, the DHCP servers network is not at all loaded (at most only has 4 devices trying to connect to it at once), and yet I've seen this failure multiple times, so I'm not sure what would happen in a loaded network.
I think at least for CIP we need a kernel that is able to cope with however long the server takes to reply.

Can you solve the problem
some other way, like for example increasing timeouts?
I've tried increasing CONF_INTER_TIMEOUT to 2Hz and I haven't seen it fail in 50 boots. Though this is an simple workaround, it can prolong boot up time and the DHCP client is still time dependent with regards to listening for a reply on a network device.

Thanks,
Patryk


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


Re: [PATCH 4.4 0/5] DHCP client support when receiving "delayed" replies

Sasha Levin <sashal@...>
 

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


Re: [PATCH 4.4 0/5] DHCP client support when receiving "delayed" replies

Pavel Machek
 

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


[PATCH 4.4 5/5] net: ipconfig: Fix NULL pointer dereference on RARP/BOOTP/DHCP timeout

Patryk Mungai <patryk.mungai-ndungu.kx@...>
 

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

6321 - 6340 of 8382