Date   

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@...>

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@...>

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@...>

Document RZ/G2E (R8A774C0) SoC bindings.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Reviewed-by: Rob Herring <robh@...>
Signed-off-by: Marc Zyngier <marc.zyngier@...>
(cherry picked from commit 24105bf4d10485143f8e26337cda8bcb7f6e6da5)
Signed-off-by: Biju Das <biju.das@...>
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@... <stable-owner@...> On
Behalf Of Pavel Machek
Sent: 06 April 2019 11:39
To: Patryk Mungai Ndungu <patryk.mungai-ndungu.kx@...>
Cc: stable@...; davem@...; cip-dev@...
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@...>

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@...>
Fixes: 2647cffb2bc6fbed ("net: ipconfig: Support using "delayed" DHCP replies")
Signed-off-by: David S. Miller <davem@...>
[Patryk: cherry-picked to 4.4]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
---
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


[PATCH 4.4 4/5] net: ipconfig: Fix more use after free

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

From: Thierry Reding <treding@...>

commit d2d371ae5dd6af9a6a3d7f50b753627c42868409 upstream.

While commit 9c706a49d660 ("net: ipconfig: fix use after free") avoids
the use after free, the resulting code still ends up calling both the
ic_setup_if() and ic_setup_routes() after calling ic_close_devs(), and
access to the device is still required.

Move the call to ic_close_devs() to the very end of the function.

Signed-off-by: Thierry Reding <treding@...>
Signed-off-by: David S. Miller <davem@...>
[Patryk: cherry-picked to 4.4]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
---
net/ipv4/ipconfig.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 23c9b8a..6b78590 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1556,12 +1556,14 @@ static int __init ip_auto_config(void)
* Close all network devices except the device we've
* autoconfigured and set up routes.
*/
- ic_close_devs();
if (ic_setup_if() < 0 || ic_setup_routes() < 0)
- return -1;
+ err = -1;
+ else
+ err = 0;

+ ic_close_devs();

- return 0;
+ return err;
}

late_initcall(ip_auto_config);
--
2.7.4


[PATCH 4.4 3/5] net: ipconfig: fix use after free

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

From: Uwe Kleine-König <u.kleine-koenig@...>

commit 9c706a49d660653625d206f6972541c1f60ea2b0 upstream.

ic_close_devs() calls kfree() for all devices's ic_device. Since commit
2647cffb2bc6 ("net: ipconfig: Support using "delayed" DHCP replies")
the active device's ic_device is still used however to print the
ipconfig summary which results in an oops if the memory is already
changed. So delay freeing until after the autoconfig results are
reported.

Fixes: 2647cffb2bc6 ("net: ipconfig: Support using "delayed" DHCP replies")
Reported-by: Geert Uytterhoeven <geert@...>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...>
Tested-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: David S. Miller <davem@...>
[Patryk: cherry-picked to 4.4]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
---
net/ipv4/ipconfig.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 35c8b35..23c9b8a 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1519,14 +1519,6 @@ static int __init ip_auto_config(void)
return -1;

/*
- * Close all network devices except the device we've
- * autoconfigured and set up routes.
- */
- ic_close_devs();
- if (ic_setup_if() < 0 || ic_setup_routes() < 0)
- return -1;
-
- /*
* Record which protocol was actually used.
*/
#ifdef IPCONFIG_DYNAMIC
@@ -1560,6 +1552,15 @@ static int __init ip_auto_config(void)
pr_cont("\n");
#endif /* !SILENT */

+ /*
+ * Close all network devices except the device we've
+ * autoconfigured and set up routes.
+ */
+ ic_close_devs();
+ if (ic_setup_if() < 0 || ic_setup_routes() < 0)
+ return -1;
+
+
return 0;
}

--
2.7.4


[PATCH 4.4 2/5] net: ipconfig: drop inter-device timeout

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

From: Uwe Kleine-König <u.kleine-koenig@...>

commit e068853409aa17208e94f4ca628005cc6f51e043 upstream.

Now that ipconfig learned to handle "delayed replies" in the previous
commit, there is no reason any more to delay sending a first request per
device.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...>
Signed-off-by: David S. Miller <davem@...>
[Patryk: cherry-picked to 4.4]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
---
net/ipv4/ipconfig.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index f326433..35c8b35 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -94,7 +94,6 @@
/* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
#define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */
#define CONF_SEND_RETRIES 6 /* Send six requests per open */
-#define CONF_INTER_TIMEOUT (HZ) /* Inter-device timeout: 1 second */
#define CONF_BASE_TIMEOUT (HZ*2) /* Initial timeout: 2 seconds */
#define CONF_TIMEOUT_RANDOM (HZ) /* Maximum amount of randomization */
#define CONF_TIMEOUT_MULT *7/4 /* Rate of timeout growth */
@@ -1243,9 +1242,11 @@ static int __init ic_dynamic(void)
ic_rarp_send_if(d);
#endif

- jiff = jiffies + (d->next ? CONF_INTER_TIMEOUT : timeout);
- while (time_before(jiffies, jiff) && !ic_got_reply)
- schedule_timeout_uninterruptible(1);
+ if (!d->next) {
+ jiff = jiffies + timeout;
+ while (time_before(jiffies, jiff) && !ic_got_reply)
+ schedule_timeout_uninterruptible(1);
+ }
#ifdef IPCONFIG_DHCP
/* DHCP isn't done until we get a DHCPACK. */
if ((ic_got_reply & IC_BOOTP) &&
--
2.7.4


[PATCH 4.4 1/5] net: ipconfig: Support using "delayed" DHCP replies

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

From: Uwe Kleine-König <u.kleine-koenig@...>

commit 2647cffb2bc6fbed163d377390eb7ca552c7c1cb upstream.

The dhcp code only waits 1s between sending DHCP requests on different
devices and only accepts an answer for the device that sent out the last
request. Only the timeout at the end of a loop is increased iteratively
which favours only the last device. This makes it impossible to work
with a dhcp server that takes little more than 1s connected to a device
that is not the last one.

Instead of also increasing the inter-device timeout, teach the code to
handle delayed replies.

To accomplish that, make *ic_dev track the current ic_device instead of
the current net_device and adapt all users accordingly. The relevant
change then is to reset d to ic_dev on a reply to assert that the
followup request goes through the right device.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...>
Signed-off-by: David S. Miller <davem@...>
[Patryk: Backported to 4.4: replaced DBG function with pr_debug]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
---
net/ipv4/ipconfig.c | 31 +++++++++++--------------------
1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 60f564d..f326433 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -195,7 +195,7 @@ struct ic_device {
};

static struct ic_device *ic_first_dev __initdata; /* List of open device */
-static struct net_device *ic_dev __initdata; /* Selected device */
+static struct ic_device *ic_dev __initdata; /* Selected device */

static bool __init ic_is_init_dev(struct net_device *dev)
{
@@ -314,8 +314,8 @@ static void __init ic_close_devs(void)
while ((d = next)) {
next = d->next;
dev = d->dev;
- if (dev != ic_dev && !netdev_uses_dsa(dev)) {
- DBG(("IP-Config: Downing %s\n", dev->name));
+ if (dev != ic_dev->dev && !netdev_uses_dsa(dev)) {
+ pr_debug("IP-Config: Downing %s\n", dev->name);
dev_change_flags(dev, d->flags);
}
kfree(d);
@@ -379,7 +379,7 @@ static int __init ic_setup_if(void)
int err;

memset(&ir, 0, sizeof(ir));
- strcpy(ir.ifr_ifrn.ifrn_name, ic_dev->name);
+ strcpy(ir.ifr_ifrn.ifrn_name, ic_dev->dev->name);
set_sockaddr(sin, ic_myaddr, 0);
if ((err = ic_devinet_ioctl(SIOCSIFADDR, &ir)) < 0) {
pr_err("IP-Config: Unable to set interface address (%d)\n",
@@ -403,7 +403,7 @@ static int __init ic_setup_if(void)
* out, we'll try to muddle along.
*/
if (ic_dev_mtu != 0) {
- strcpy(ir.ifr_name, ic_dev->name);
+ strcpy(ir.ifr_name, ic_dev->dev->name);
ir.ifr_mtu = ic_dev_mtu;
if ((err = ic_dev_ioctl(SIOCSIFMTU, &ir)) < 0)
pr_err("IP-Config: Unable to set interface mtu to %d (%d)\n",
@@ -574,7 +574,7 @@ ic_rarp_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
goto drop_unlock;

/* We have a winner! */
- ic_dev = dev;
+ ic_dev = d;
if (ic_myaddr == NONE)
ic_myaddr = tip;
ic_servaddr = sip;
@@ -661,8 +661,6 @@ static struct packet_type bootp_packet_type __initdata = {
.func = ic_bootp_recv,
};

-static __be32 ic_dev_xid; /* Device under configuration */
-
/*
* Initialize DHCP/BOOTP extension fields in the request.
*/
@@ -1052,12 +1050,6 @@ static int __init ic_bootp_recv(struct sk_buff *skb, struct net_device *dev, str
goto drop_unlock;
}

- /* Is it a reply for the device we are configuring? */
- if (b->xid != ic_dev_xid) {
- net_err_ratelimited("DHCP/BOOTP: Ignoring delayed packet\n");
- goto drop_unlock;
- }
-
/* Parse extensions */
if (ext_len >= 4 &&
!memcmp(b->exten, ic_bootp_cookie, 4)) { /* Check magic cookie */
@@ -1148,7 +1140,7 @@ static int __init ic_bootp_recv(struct sk_buff *skb, struct net_device *dev, str
}

/* We have a winner! */
- ic_dev = dev;
+ ic_dev = d;
ic_myaddr = b->your_ip;
ic_servaddr = b->server_ip;
ic_addrservaddr = b->iph.saddr;
@@ -1243,9 +1235,6 @@ static int __init ic_dynamic(void)
timeout = CONF_BASE_TIMEOUT + (timeout % (unsigned int) CONF_TIMEOUT_RANDOM);
for (;;) {
#ifdef IPCONFIG_BOOTP
- /* Track the device we are configuring */
- ic_dev_xid = d->xid;
-
if (do_bootp && (d->able & IC_BOOTP))
ic_bootp_send_if(d, jiffies - start_jiffies);
#endif
@@ -1263,6 +1252,8 @@ static int __init ic_dynamic(void)
(ic_proto_enabled & IC_USE_DHCP) &&
ic_dhcp_msgtype != DHCPACK) {
ic_got_reply = 0;
+ /* continue on device that got the reply */
+ d = ic_dev;
pr_cont(",");
continue;
}
@@ -1513,7 +1504,7 @@ static int __init ip_auto_config(void)
#endif /* IPCONFIG_DYNAMIC */
} else {
/* Device selected manually or only one device -> use it */
- ic_dev = ic_first_dev->dev;
+ ic_dev = ic_first_dev;
}

addr = root_nfs_parse_addr(root_server_path);
@@ -1548,7 +1539,7 @@ static int __init ip_auto_config(void)
pr_info("IP-Config: Complete:\n");

pr_info(" device=%s, hwaddr=%*phC, ipaddr=%pI4, mask=%pI4, gw=%pI4\n",
- ic_dev->name, ic_dev->addr_len, ic_dev->dev_addr,
+ ic_dev->dev->name, ic_dev->dev->addr_len, ic_dev->dev->dev_addr,
&ic_myaddr, &ic_netmask, &ic_gateway);
pr_info(" host=%s, domain=%s, nis-domain=%s\n",
utsname()->nodename, ic_domain, utsname()->domainname);
--
2.7.4


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

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

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?

Thanks,
Patryk


Geert Uytterhoeven (1):
net: ipconfig: Fix NULL pointer dereference on RARP/BOOTP/DHCP timeout

Thierry Reding (1):
net: ipconfig: Fix more use after free

Uwe Kleine-König (3):
net: ipconfig: Support using "delayed" DHCP replies
net: ipconfig: drop inter-device timeout
net: ipconfig: fix use after free

net/ipv4/ipconfig.c | 61 ++++++++++++++++++++++++-----------------------------
1 file changed, 28 insertions(+), 33 deletions(-)

--
2.7.4


[PATCH 4.19.y] arm64: renesas: Enable GPIOLIB to allow GPIO driver selection

Biju Das <biju.das@...>
 

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

The R-Car GPIO driver cannot be enabled when Renesas SoC's ARCH configs
(ARCH_RENESAS, ARCH_R8A7795, ARCH_R8A7796 and ARCH_R8A77965) are enabled
only.

As GPIOs are a critical resource for proper operation on Renesas
platforms, this patch selects GPIOLIB, just like is done for other SoC
vendors, and on Renesas arm32 SoCs.

Reported-by: Alexandru Gheorghe <Alexandru_Gheorghe@...>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@...>
[geert: Improve patch description]
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>

(cherry picked from commit 9374eee32b666c92cf821a98eb3aeaa0bf4d5dd5)
Signed-off-by: Biju Das <biju.das@...>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index e13c9ff..a6f9b64 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -178,6 +178,7 @@ config ARCH_SYNQUACER
config ARCH_RENESAS
bool "Renesas SoC Platforms"
select ARCH_SHMOBILE
+ select GPIOLIB
select PINCTRL
select PM
select PM_GENERIC_DOMAINS
--
2.7.4


Re: isar error log

daniel.sangorrin@...
 

-----Original Message-----
From: Ben Hutchings <ben.hutchings@...>
Sent: Wednesday, April 3, 2019 10:53 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST)
<daniel.sangorrin@...>; jan.kiszka@...
Cc: isar-users@...; cip-dev@...
Subject: Re: [cip-dev] isar error log

On Wed, 2019-04-03 at 00:56 +0000, daniel.sangorrin@... wrote:
Hi Jan,

Yes I am following the Readme.

The docker image id for kasproject/kas-isar is 9e9fe44e68d3 (I am
using kas-docker script). And I am using kas-docker --isar build
kas.yml:board-qemu-amd64.yml

Yes, it seems there are multiple errors:
/proc/sys/fs/binfmt_misc/register: Invalid argument
/test-dev-null: Permission denied

Probably this is a bug or misconfiguration in Ubuntu. I will try to figure it
out.

Might this be restricted by an AppArmor profile? aa-logprof should show
you AppArmor denials and change the relevant profile(s) to allow the
operations.
Thanks for the advice Ben.
I checked with aa-logprof but there was nothing related.
# interestingly, for some reason AppArmor was restricting some functionality in Evince

Then, I tried to update the kernel to a new version (i was using about 4.4.0-84 and the latest was around 4.4.0-145) to see if something improved but I found that the new kernel wouldn't boot properly because my disk is encrypted. So I have possibly found a regression on the 4.4 kernel, I will have to check when I get back to my desk. And there is a possibility that the reason for my problem is in the binfmt kernel module.

Thanks,
Daniel


Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


CIP IRC weekly meeting today

SZ Lin (林上智) <SZ.Lin@...>
 

Hi all,

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

*Please note that 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=2019&month=4&day=4&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

US-West US-East UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* AI review
#action Iwamatsu-san will re-upload the 4.4.176-cip31
-> Done
#action The proposal of CIP identifiers in patch submissions will send to cip-dev – Chris
-> Done
#action Ask for the permission in patchwork - szlin
-> Done (Thanks to Chris!)
#action Discuss the naming of deby in TSC - Daniel Sangorrin
#action Daniel has to upload to the wiki the SW updates tool comparison document
#action The review results from Pavel will be confirmed - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* 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,

SZ Lin, Moxa.

7521 - 7540 of 9574