Date   

Re: [RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Fabrizio Castro <fabrizio.castro@...>
 

Hi Johnson,

Thank you for your email!

From: Johnson CH Chen (陳昭勳) <JohnsonCH.Chen@...>
Sent: 13 November 2019 09:17
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Hi,

Hello Iwamatsu-san,

Thank you for your feedback!

From: nobuhiro1.iwamatsu@...
<nobuhiro1.iwamatsu@...>
Sent: 12 November 2019 00:30
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Hi,

-----Original Message-----
From: Fabrizio Castro [mailto:fabrizio.castro@...]
Sent: Monday, November 11, 2019 6:49 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@...>; pavel@...
Cc: JohnsonCH.Chen@...; cip-dev@...;
Fabrizio Castro <fabrizio.castro@...>; Chris Paterson
<Chris.Paterson2@...>; Biju Das <biju.das@...>
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix
bad of_node pointer

Hi guys,

We have got a good feedback from Johnson, what do you think about
this patch?

Thanks,
Fab

From: Fabrizio Castro <fabrizio.castro@...>
Sent: 08 November 2019 16:47
Subject: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Not every driver initialises of_node from struct gpio_chip,
therefore the replacement of of_node from struct gpio_chip with
dev->of_node in the below commit won't work on every
platform:
baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges'
property") The final result is that on some platforms the kernel
will try to dereference a NULL pointer, with obvious consequences.

This patch makes sure the pointer gets initialised before its
first usage.

Fixes: baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges'
property")
Reported-by: Johnson CH Chen <JohnsonCH.Chen@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>

---
v1->v2:
* v1 was for testing purposes only, but no point in sending
out a dirty patch, therefore cleaned it up
---
drivers/gpio/gpiolib-of.c | 2 +-
drivers/gpio/gpiolib.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c
b/drivers/gpio/gpiolib-of.c index ec642bf..6fa1818 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -338,7 +338,7 @@ static void
of_gpiochip_init_valid_mask(struct
gpio_chip *chip) {
int len, i;
u32 start, count;
- struct device_node *np = chip->dev->of_node;
+ struct device_node *np = chip->of_node;

len = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (len < 0 || len % 2 != 0)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d72218f..820e3e3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -296,7 +296,7 @@ static int gpiochip_init_valid_mask(struct
gpio_chip *gpiochip) { #ifdef CONFIG_OF_GPIO
int size;
- struct device_node *np = gpiochip->dev->of_node;
+ struct device_node *np = gpiochip->of_node;
This already changed by commit 726cb3ba49692bdae6caff457755e7cdb432efa4.
If we apply this, we need to revert and update commit baff4777cdb80.

size = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (size > 0 && size % 2 == 0) @@ -360,6 +360,9 @@ int
gpiochip_add_data(struct gpio_chip *chip, void
*data)

chip->data = data;

+ if ((!chip->of_node) && (chip->dev))
+ chip->of_node = chip->dev->of_node;
+
spin_lock_irqsave(&gpio_lock, flags);

if (base < 0) {

I think this is a good patch to solve the problem.
However, as a CIP, this patch that is not in upstream cannot be imported.
I think we need to apply the following patches (and others).

acc6e331b62275570d23b20ced6296812023967f
6ff0497402ef7269ee6a72f62eb85adaa7a4768e
All those patches were done in the context of gpiochip being real
devices, but that only happened in v4.6, please see
ff2b1359229927563addbf2f5ad480660c350903
Is that mean it's better to apply the following patches from v4.6 into v4.4.y-cip to fix the problem?
"acc6e331b62275570d23b20ced6296812023967f"
"6ff0497402ef7269ee6a72f62eb85adaa7a4768e"
"ff2b1359229927563addbf2f5ad480660c350903"
With the CIP project we tend to stay away from the subsystems and generic code as much as possible.
In the context of the patch that broke your platform we had no other choice because the RZ/G1C has an hole in its GPIOs layout, but as you have noticed touching generic code may destabilize the kernel.
Backporting those commits would mean touching code we shouldn't be touching in this project, and therefore I think it's a no go, I rather we fixed the patch that broke the kernel in the first place than introducing more code that may destabilize the kernel even more. I don't think we should be adding gpiochip devices support to 4.4, unless we really, really, really have to.

Thanks,
Fab



I did try going down the backporting route before coming up with a brand new patch, but unfortunately the context of the upstream
patches is not right for this due to the fact that we don't have gpiochip devices support in v4.4.y-cip gpiolib.

Thanks,
Fab


--
2.7.4
Best regards,
Nobuhiro
Thanks,
Johnson


Re: [RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

johnsonch.chen@moxa.com
 

Hi,

Hello Iwamatsu-san,

Thank you for your feedback!

From: nobuhiro1.iwamatsu@...
<nobuhiro1.iwamatsu@...>
Sent: 12 November 2019 00:30
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Hi,

-----Original Message-----
From: Fabrizio Castro [mailto:fabrizio.castro@...]
Sent: Monday, November 11, 2019 6:49 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@...>; pavel@...
Cc: JohnsonCH.Chen@...; cip-dev@...;
Fabrizio Castro <fabrizio.castro@...>; Chris Paterson
<Chris.Paterson2@...>; Biju Das <biju.das@...>
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix
bad of_node pointer

Hi guys,

We have got a good feedback from Johnson, what do you think about
this patch?

Thanks,
Fab

From: Fabrizio Castro <fabrizio.castro@...>
Sent: 08 November 2019 16:47
Subject: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Not every driver initialises of_node from struct gpio_chip,
therefore the replacement of of_node from struct gpio_chip with
dev->of_node in the below commit won't work on every
platform:
baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges'
property") The final result is that on some platforms the kernel
will try to dereference a NULL pointer, with obvious consequences.

This patch makes sure the pointer gets initialised before its
first usage.

Fixes: baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges'
property")
Reported-by: Johnson CH Chen <JohnsonCH.Chen@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>

---
v1->v2:
* v1 was for testing purposes only, but no point in sending
out a dirty patch, therefore cleaned it up
---
drivers/gpio/gpiolib-of.c | 2 +-
drivers/gpio/gpiolib.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c
b/drivers/gpio/gpiolib-of.c index ec642bf..6fa1818 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -338,7 +338,7 @@ static void
of_gpiochip_init_valid_mask(struct
gpio_chip *chip) {
int len, i;
u32 start, count;
- struct device_node *np = chip->dev->of_node;
+ struct device_node *np = chip->of_node;

len = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (len < 0 || len % 2 != 0)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d72218f..820e3e3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -296,7 +296,7 @@ static int gpiochip_init_valid_mask(struct
gpio_chip *gpiochip) { #ifdef CONFIG_OF_GPIO
int size;
- struct device_node *np = gpiochip->dev->of_node;
+ struct device_node *np = gpiochip->of_node;
This already changed by commit 726cb3ba49692bdae6caff457755e7cdb432efa4.
If we apply this, we need to revert and update commit baff4777cdb80.

size = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (size > 0 && size % 2 == 0) @@ -360,6 +360,9 @@ int
gpiochip_add_data(struct gpio_chip *chip, void
*data)

chip->data = data;

+ if ((!chip->of_node) && (chip->dev))
+ chip->of_node = chip->dev->of_node;
+
spin_lock_irqsave(&gpio_lock, flags);

if (base < 0) {

I think this is a good patch to solve the problem.
However, as a CIP, this patch that is not in upstream cannot be imported.
I think we need to apply the following patches (and others).

acc6e331b62275570d23b20ced6296812023967f
6ff0497402ef7269ee6a72f62eb85adaa7a4768e
All those patches were done in the context of gpiochip being real
devices, but that only happened in v4.6, please see
ff2b1359229927563addbf2f5ad480660c350903
Is that mean it's better to apply the following patches from v4.6 into v4.4.y-cip to fix the problem?
"acc6e331b62275570d23b20ced6296812023967f"
"6ff0497402ef7269ee6a72f62eb85adaa7a4768e"
"ff2b1359229927563addbf2f5ad480660c350903"


I did try going down the backporting route before coming up with a brand new patch, but unfortunately the context of the upstream patches is not right for this due to the fact that we don't have gpiochip devices support in v4.4.y-cip gpiolib.

Thanks,
Fab


--
2.7.4
Best regards,
Nobuhiro
Thanks,
Johnson


Re: Planned downtime for lab-cip-renesas on the 13th Nov

Chris Paterson
 

Just a reminder...

From: cip-dev-bounces@... <cip-dev-bounces@...
project.org> On Behalf Of Chris Paterson
Sent: 04 November 2019 11:13

Hello all,

Just a heads up that the Renesas LAVA lab (lab-cip-renesas) will be offline for 2/3
hours on the morning of the 13th November, from around 1000 GMT onwards.

Our hardware is being PAT tested.

Kind regards, Chris

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


Re: [RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Fabrizio Castro <fabrizio.castro@...>
 

Hello Iwamatsu-san,

Thank you for your feedback!

From: nobuhiro1.iwamatsu@... <nobuhiro1.iwamatsu@...>
Sent: 12 November 2019 00:30
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Hi,

-----Original Message-----
From: Fabrizio Castro [mailto:fabrizio.castro@...]
Sent: Monday, November 11, 2019 6:49 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@...>; pavel@...
Cc: JohnsonCH.Chen@...; cip-dev@...; Fabrizio
Castro <fabrizio.castro@...>; Chris Paterson
<Chris.Paterson2@...>; Biju Das <biju.das@...>
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Hi guys,

We have got a good feedback from Johnson, what do you think about this
patch?

Thanks,
Fab

From: Fabrizio Castro <fabrizio.castro@...>
Sent: 08 November 2019 16:47
Subject: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Not every driver initialises of_node from struct gpio_chip, therefore
the replacement of of_node from struct gpio_chip with dev->of_node in
the below commit won't work on every
platform:
baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges' property") The
final result is that on some platforms the kernel will try to
dereference a NULL pointer, with obvious consequences.

This patch makes sure the pointer gets initialised before its first
usage.

Fixes: baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges'
property")
Reported-by: Johnson CH Chen <JohnsonCH.Chen@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>

---
v1->v2:
* v1 was for testing purposes only, but no point in sending
out a dirty patch, therefore cleaned it up
---
drivers/gpio/gpiolib-of.c | 2 +-
drivers/gpio/gpiolib.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index ec642bf..6fa1818 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -338,7 +338,7 @@ static void of_gpiochip_init_valid_mask(struct
gpio_chip *chip) {
int len, i;
u32 start, count;
- struct device_node *np = chip->dev->of_node;
+ struct device_node *np = chip->of_node;

len = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (len < 0 || len % 2 != 0)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index
d72218f..820e3e3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -296,7 +296,7 @@ static int gpiochip_init_valid_mask(struct
gpio_chip *gpiochip) { #ifdef CONFIG_OF_GPIO
int size;
- struct device_node *np = gpiochip->dev->of_node;
+ struct device_node *np = gpiochip->of_node;
This already changed by commit 726cb3ba49692bdae6caff457755e7cdb432efa4.
If we apply this, we need to revert and update commit baff4777cdb80.

size = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (size > 0 && size % 2 == 0)
@@ -360,6 +360,9 @@ int gpiochip_add_data(struct gpio_chip *chip, void
*data)

chip->data = data;

+ if ((!chip->of_node) && (chip->dev))
+ chip->of_node = chip->dev->of_node;
+
spin_lock_irqsave(&gpio_lock, flags);

if (base < 0) {

I think this is a good patch to solve the problem.
However, as a CIP, this patch that is not in upstream cannot be imported.
I think we need to apply the following patches (and others).

acc6e331b62275570d23b20ced6296812023967f
6ff0497402ef7269ee6a72f62eb85adaa7a4768e
All those patches were done in the context of gpiochip being real devices,
but that only happened in v4.6, please see ff2b1359229927563addbf2f5ad480660c350903

I did try going down the backporting route before coming up with a brand new patch,
but unfortunately the context of the upstream patches is not right for this due
to the fact that we don't have gpiochip devices support in v4.4.y-cip gpiolib.

Thanks,
Fab


--
2.7.4
Best regards,
Nobuhiro


Re: Build fail for linux-4.4.y-rc

Chris Paterson
 

Hello all,

From: Pavel Machek <pavel@...>
Sent: 11 November 2019 13:48

Hi!

I've seen a failure this morning with our linux stable-rc build testing.

Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux 4.4.201-rc1
Thanks to Pavel's reporting, Greg has now fixed this build issue in Linux 4.4.201-rc2 (ca1d1b5f0f2a).
https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/347861814

Kind regards, Chris

Arch: arm
Config: moxa_mxc_defconfig

Pipeline: https://gitlab.com/cip-playground/linux-stable-rc-
ci/pipelines/95016985
Failure: https://gitlab.com/cip-playground/linux-stable-rc-
ci/pipelines/95016985/failures
Log: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
Config: https://gitlab.com/cip-playground/linux-stable-rc-ci/-
/jobs/346974180

All other configurations that we build were successful.
Thanks for heads-up!

I see warning during configuration:

HOSTLD  scripts/kconfig/conf
arch/arm/configs/moxa_mxc_defconfig:745:warning: symbol value 'm'
invalid for RTC_DRV_DS1374_WDT
#
This one seems to be reponsible. I have mailed author & lists...
.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date:   Tue Nov 5 21:16:27 2019 -0800

     mm, meminit: recalculate pcpu batch and high limits after init
     completes

  commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.

Best regards,
                                                              Pavel

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


Re: Build fail for linux-4.4.y-rc

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

Hi,

SZ Lin (林上智) <sz.lin@...> 於 2019年11月11日 週一 下午10:43寫道:

Hi Pavel,

Pavel Machek <pavel@...> 於 2019年11月11日 週一 下午9:47寫道:
<snip>


This one seems to be reponsible. I have mailed author & lists...
Ack with thanks!.

After using git bisect, I confirmed that the commit id
"23160bd11f183b0e77ea54befff63e5d2607155b" caused the failure,
the previous version of kernel works fine.
Regression occurred [1] with the same patch in the 4.14 stable kernel, but it
failed during the boot time instead of compile time.

[1] https://marc.info/?l=linux-kernel&m=157352880515619&w=2

SZ


The below modification in "mm/page_alloc.c" seems to be the root cause.

+ /*
+ * The number of managed pages has changed due to the initialisation
+ * so the pcpu batch and high limits needs to be updated or the limits
+ * will be artificially small.
+ */
+ for_each_populated_zone(zone)
+ zone_pcp_update(zone);
+

SZ

.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date: Tue Nov 5 21:16:27 2019 -0800

mm, meminit: recalculate pcpu batch and high limits after init
completes

commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Build fail for linux-4.4.y-rc

johnsonch.chen@moxa.com
 

Hi SZ,

Thanks your remind, I'll follow this and keep in mind :)

Thanks!
Johnson

Hi,

Johnson CH Chen (陳昭勳) <JohnsonCH.Chen@...> 於 2019年11月11日 週一 下午9:53寫道:

Hi Pavel,

Could you set “RTC_DRV_DS1374_WDT=y” in moxa_mxc_defconfig and then build again?
Let's wait for the reply from author :-)

Apart from that, please send the MR via gitlab [1] if you want to modify the kernel configuration.

[1] https://gitlab.com/cip-project/cip-kernel/cip-kernel-config

SZ


I can build uImage and kernel modules successfully with Linux 4.4.201-rc1 in my local part.

Thanks,
Johnson

取得 iOS 版 Outlook
________________________________
寄件者: cip-dev-bounces@...
<cip-dev-bounces@...> 代表 Pavel Machek
<pavel@...>
寄件日期: Monday, November 11, 2019 9:47:37 PM
收件者: Pavel Machek <pavel@...>
副本: cip-dev@... <cip-dev@...>
主旨: Re: [cip-dev] Build fail for linux-4.4.y-rc

Hi!

I've seen a failure this morning with our linux stable-rc build testing.

Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux
4.4.201-rc1
Arch: arm
Config: moxa_mxc_defconfig

Pipeline:
https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/950
16985
Failure:
https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/950
16985/failures
Log:
https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974
180
Config:
https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974
180

All other configurations that we build were successful.
Thanks for heads-up!

I see warning during configuration:

HOSTLD scripts/kconfig/conf
arch/arm/configs/moxa_mxc_defconfig:745:warning: symbol value 'm'
invalid for RTC_DRV_DS1374_WDT
#
This one seems to be reponsible. I have mailed author & lists...
.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date: Tue Nov 5 21:16:27 2019 -0800

mm, meminit: recalculate pcpu batch and high limits after init
completes

commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Fabrizio Castro [mailto:fabrizio.castro@...]
Sent: Monday, November 11, 2019 6:49 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@...>; pavel@...
Cc: JohnsonCH.Chen@...; cip-dev@...; Fabrizio
Castro <fabrizio.castro@...>; Chris Paterson
<Chris.Paterson2@...>; Biju Das <biju.das@...>
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Hi guys,

We have got a good feedback from Johnson, what do you think about this
patch?

Thanks,
Fab

From: Fabrizio Castro <fabrizio.castro@...>
Sent: 08 November 2019 16:47
Subject: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad
of_node pointer

Not every driver initialises of_node from struct gpio_chip, therefore
the replacement of of_node from struct gpio_chip with dev->of_node in
the below commit won't work on every
platform:
baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges' property") The
final result is that on some platforms the kernel will try to
dereference a NULL pointer, with obvious consequences.

This patch makes sure the pointer gets initialised before its first
usage.

Fixes: baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges'
property")
Reported-by: Johnson CH Chen <JohnsonCH.Chen@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>

---
v1->v2:
* v1 was for testing purposes only, but no point in sending
out a dirty patch, therefore cleaned it up
---
drivers/gpio/gpiolib-of.c | 2 +-
drivers/gpio/gpiolib.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index ec642bf..6fa1818 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -338,7 +338,7 @@ static void of_gpiochip_init_valid_mask(struct
gpio_chip *chip) {
int len, i;
u32 start, count;
- struct device_node *np = chip->dev->of_node;
+ struct device_node *np = chip->of_node;

len = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (len < 0 || len % 2 != 0)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index
d72218f..820e3e3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -296,7 +296,7 @@ static int gpiochip_init_valid_mask(struct
gpio_chip *gpiochip) { #ifdef CONFIG_OF_GPIO
int size;
- struct device_node *np = gpiochip->dev->of_node;
+ struct device_node *np = gpiochip->of_node;
This already changed by commit 726cb3ba49692bdae6caff457755e7cdb432efa4.
If we apply this, we need to revert and update commit baff4777cdb80.

size = of_property_count_u32_elems(np,
"gpio-reserved-ranges");
if (size > 0 && size % 2 == 0)
@@ -360,6 +360,9 @@ int gpiochip_add_data(struct gpio_chip *chip, void
*data)

chip->data = data;

+ if ((!chip->of_node) && (chip->dev))
+ chip->of_node = chip->dev->of_node;
+
spin_lock_irqsave(&gpio_lock, flags);

if (base < 0) {

I think this is a good patch to solve the problem.
However, as a CIP, this patch that is not in upstream cannot be imported.
I think we need to apply the following patches (and others).

acc6e331b62275570d23b20ced6296812023967f
6ff0497402ef7269ee6a72f62eb85adaa7a4768e

--
2.7.4
Best regards,
Nobuhiro


Re: Build fail for linux-4.4.y-rc

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

Hi,

Johnson CH Chen (陳昭勳) <JohnsonCH.Chen@...> 於 2019年11月11日 週一 下午9:53寫道:

Hi Pavel,

Could you set “RTC_DRV_DS1374_WDT=y” in moxa_mxc_defconfig and then build again?
Let's wait for the reply from author :-)

Apart from that, please send the MR via gitlab [1] if you want to
modify the kernel configuration.

[1] https://gitlab.com/cip-project/cip-kernel/cip-kernel-config

SZ


I can build uImage and kernel modules successfully with Linux 4.4.201-rc1 in my local part.

Thanks,
Johnson

取得 iOS 版 Outlook
________________________________
寄件者: cip-dev-bounces@... <cip-dev-bounces@...> 代表 Pavel Machek <pavel@...>
寄件日期: Monday, November 11, 2019 9:47:37 PM
收件者: Pavel Machek <pavel@...>
副本: cip-dev@... <cip-dev@...>
主旨: Re: [cip-dev] Build fail for linux-4.4.y-rc

Hi!

I've seen a failure this morning with our linux stable-rc build testing.

Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux 4.4.201-rc1
Arch: arm
Config: moxa_mxc_defconfig

Pipeline: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985
Failure: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985/failures
Log: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
Config: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180

All other configurations that we build were successful.
Thanks for heads-up!

I see warning during configuration:

HOSTLD scripts/kconfig/conf
arch/arm/configs/moxa_mxc_defconfig:745:warning: symbol value 'm'
invalid for RTC_DRV_DS1374_WDT
#
This one seems to be reponsible. I have mailed author & lists...
.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date: Tue Nov 5 21:16:27 2019 -0800

mm, meminit: recalculate pcpu batch and high limits after init
completes

commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Build fail for linux-4.4.y-rc

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

Hi Pavel,

Pavel Machek <pavel@...> 於 2019年11月11日 週一 下午9:47寫道:
<snip>


This one seems to be reponsible. I have mailed author & lists...
Ack with thanks!.

After using git bisect, I confirmed that the commit id
"23160bd11f183b0e77ea54befff63e5d2607155b" caused the failure,
the previous version of kernel works fine.

The below modification in "mm/page_alloc.c" seems to be the root cause.

+ /*
+ * The number of managed pages has changed due to the initialisation
+ * so the pcpu batch and high limits needs to be updated or the limits
+ * will be artificially small.
+ */
+ for_each_populated_zone(zone)
+ zone_pcp_update(zone);
+

SZ

.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date: Tue Nov 5 21:16:27 2019 -0800

mm, meminit: recalculate pcpu batch and high limits after init
completes

commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


[ANNOUNCE] v4.19.72-cip10-rt4

Pavel Machek
 

Hi!

v4.19.72-cip10-rt4 should be available at kernel.org. As of friday,
upstream -rt tree did not move from v4.19.72. If it stays there for
much longer, I'll need to figure out something.

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: Build fail for linux-4.4.y-rc

johnsonch.chen@moxa.com
 

Hi Pavel,

Could you set “RTC_DRV_DS1374_WDT=y” in moxa_mxc_defconfig and then build again?

I can build uImage and kernel modules successfully with Linux 4.4.201-rc1 in my local part.

Thanks,
Johnson


寄件者: cip-dev-bounces@... <cip-dev-bounces@...> 代表 Pavel Machek <pavel@...>
寄件日期: Monday, November 11, 2019 9:47:37 PM
收件者: Pavel Machek <pavel@...>
副本: cip-dev@... <cip-dev@...>
主旨: Re: [cip-dev] Build fail for linux-4.4.y-rc
 
Hi!

> > I've seen a failure this morning with our linux stable-rc build testing.
> >
> > Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux 4.4.201-rc1
> > Arch: arm
> > Config: moxa_mxc_defconfig
> >
> > Pipeline: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985
> > Failure: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985/failures
> > Log: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
> > Config: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
> >
> > All other configurations that we build were successful.
>
> Thanks for heads-up!
>
> I see warning during configuration:
>
> HOSTLD  scripts/kconfig/conf
> arch/arm/configs/moxa_mxc_defconfig:745:warning: symbol value 'm'
> invalid for RTC_DRV_DS1374_WDT
> #

This one seems to be reponsible. I have mailed author & lists...
.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date:   Tue Nov 5 21:16:27 2019 -0800

    mm, meminit: recalculate pcpu batch and high limits after init
    completes

 commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.
   
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 66/83] mmc: tmio: rename tmio_mmc_{pio => core}.c

Biju Das <biju.das@...>
 

Hi Pavel,


Subject: Re: [PATCH 4.4.y-cip 66/83] mmc: tmio: rename tmio_mmc_{pio =>
core}.c

Hi!

commit 426e95d1766bad20e59f219af64fdd50c39bcfee upstream.

Rename tmio_mmc_pio.c to tmio_mmc_core.c to more accurately
reflect its
function: to provide core code for the tmio-mmc and sh-mobole-sdhi
drivers.

Signed-off-by: Simon Horman <horms+renesas@...>
Acked-by: Arnd Bergmann <arnd@...>
Reviewed-by: Wolfram Sang <wsa+renesas@...>
Signed-off-by: Ulf Hansson <ulf.hansson@...>
Signed-off-by: Biju Das <biju.das@...>
---
drivers/mmc/host/Makefile | 1 -
drivers/mmc/host/tmio_mmc_core.c | 1394
++++++++++++++++++++++++++++++++++++++
drivers/mmc/host/tmio_mmc_pio.c | 1394
--------------------------------------
This patch creates tmio_mmc_core.c ...
yes, if you see the subec mmc: tmio: rename tmio_mmc_{pio => core}.c

Is it anything wrong? Am I missing something here?
There were more comments in my email, see below.

But reading them again, I see I was wrong. Makefile magic was used to turn
tmio_mmc_pio.c into tmio_mmc_core.o, so there's no bug here.

Sorry for the noise.
OK.

Cheers,
Biju

+++ b/drivers/mmc/host/Makefile
@@ -36,7 +36,6 @@ obj-$(CONFIG_MMC_S3C) += s3cmci.o
obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o
obj-$(CONFIG_MMC_TMIO) += tmio_mmc.o
obj-$(CONFIG_MMC_TMIO_CORE) += tmio_mmc_core.o
-tmio_mmc_core-y := tmio_mmc_pio.o
obj-$(CONFIG_MMC_SDHI) += sh_mobile_sdhi.o
tmio_mmc_dma.o
obj-$(CONFIG_MMC_CB710) += cb710-mmc.o
obj-$(CONFIG_MMC_VIA_SDMMC) += via-sdmmc.o
... which is already present in the Makefile before the patch. That
can't be right.
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: Build fail for linux-4.4.y-rc

Pavel Machek
 

Hi!

I've seen a failure this morning with our linux stable-rc build testing.

Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux 4.4.201-rc1
Arch: arm
Config: moxa_mxc_defconfig

Pipeline: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985
Failure: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985/failures
Log: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
Config: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180

All other configurations that we build were successful.
Thanks for heads-up!

I see warning during configuration:

HOSTLD scripts/kconfig/conf
arch/arm/configs/moxa_mxc_defconfig:745:warning: symbol value 'm'
invalid for RTC_DRV_DS1374_WDT
#
This one seems to be reponsible. I have mailed author & lists...
.

commit df82285ab4b974f2040f31dbabdd11e055a282c2
Author: Mel Gorman <mgorman@...>
Date: Tue Nov 5 21:16:27 2019 -0800

mm, meminit: recalculate pcpu batch and high limits after init
completes

commit 3e8fc0075e24338b1117cdff6a79477427b8dbed upstream.

Best regards,
Pavel

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


Re: [RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Fabrizio Castro <fabrizio.castro@...>
 

Hi guys,

We have got a good feedback from Johnson, what do you think
about this patch?

Thanks,
Fab

From: Fabrizio Castro <fabrizio.castro@...>
Sent: 08 November 2019 16:47
Subject: [cip-dev][RFT/RFC linux-4.4.y-cip v2] gpiolib: Fix bad of_node pointer

Not every driver initialises of_node from struct gpio_chip,
therefore the replacement of of_node from struct gpio_chip
with dev->of_node in the below commit won't work on every
platform:
baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges' property")
The final result is that on some platforms the kernel will
try to dereference a NULL pointer, with obvious consequences.

This patch makes sure the pointer gets initialised before its
first usage.

Fixes: baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges' property")
Reported-by: Johnson CH Chen <JohnsonCH.Chen@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>

---
v1->v2:
* v1 was for testing purposes only, but no point in sending
out a dirty patch, therefore cleaned it up
---
drivers/gpio/gpiolib-of.c | 2 +-
drivers/gpio/gpiolib.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index ec642bf..6fa1818 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -338,7 +338,7 @@ static void of_gpiochip_init_valid_mask(struct gpio_chip *chip)
{
int len, i;
u32 start, count;
- struct device_node *np = chip->dev->of_node;
+ struct device_node *np = chip->of_node;

len = of_property_count_u32_elems(np, "gpio-reserved-ranges");
if (len < 0 || len % 2 != 0)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d72218f..820e3e3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -296,7 +296,7 @@ static int gpiochip_init_valid_mask(struct gpio_chip *gpiochip)
{
#ifdef CONFIG_OF_GPIO
int size;
- struct device_node *np = gpiochip->dev->of_node;
+ struct device_node *np = gpiochip->of_node;

size = of_property_count_u32_elems(np, "gpio-reserved-ranges");
if (size > 0 && size % 2 == 0)
@@ -360,6 +360,9 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)

chip->data = data;

+ if ((!chip->of_node) && (chip->dev))
+ chip->of_node = chip->dev->of_node;
+
spin_lock_irqsave(&gpio_lock, flags);

if (base < 0) {
--
2.7.4


Re: [RFT/RFC linux-4.4.y-cip] gpiolib: Fix bad of_node pointer

Fabrizio Castro <fabrizio.castro@...>
 

Thank you for testing!

Cheers,
Fab

-----Original Message-----
From: Johnson CH Chen (陳昭勳) <JohnsonCH.Chen@...>
Sent: 11 November 2019 03:36
To: Fabrizio Castro <fabrizio.castro@...>; cip-dev@...
Cc: nobuhiro1.iwamatsu@...; pavel@...; Chris Paterson <Chris.Paterson2@...>; Biju Das
<biju.das@...>
Subject: RE: [cip-dev][RFT/RFC linux-4.4.y-cip] gpiolib: Fix bad of_node pointer

Hi Fab,

This patch is good for my system (ls1021a), so many thanks!

Thanks,
Johnson

-----Original Message-----
From: Fabrizio Castro <fabrizio.castro@...>
Sent: Saturday, November 9, 2019 12:37 AM
To: cip-dev@...
Cc: nobuhiro1.iwamatsu@...; pavel@...; Chris Paterson <Chris.Paterson2@...>; Biju Das
<biju.das@...>; Fabrizio Castro <fabrizio.castro@...>; Johnson CH Chen (陳昭勳)
<JohnsonCH.Chen@...>
Subject: [cip-dev][RFT/RFC linux-4.4.y-cip] gpiolib: Fix bad of_node pointer

Not every driver initialises of_node from struct gpio_chip, therefore the replacement of of_node from struct gpio_chip with dev-
of_node in the below commit won't work on every
platform:
baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges' property") The final result is that on some platforms the kernel will try to
dereference a NULL pointer, with obvious consequences.

This patch makes sure the pointer gets initialised before its first usage.

Fixes: baff4777cdb8 ("gpiolib: Support 'gpio-reserved-ranges' property")
Reported-by: Johnson CH Chen <JohnsonCH.Chen@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---

Hi Johnson,

could you please test this patch on your system?

Thanks,
Fab


drivers/gpio/gpiolib-of.c | 4 +++-
drivers/gpio/gpiolib.c | 6 +++++-
2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index ec642bf..36b60dd 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -338,7 +338,7 @@ static void of_gpiochip_init_valid_mask(struct gpio_chip *chip) {
int len, i;
u32 start, count;
- struct device_node *np = chip->dev->of_node;
+ struct device_node *np = chip->of_node;

len = of_property_count_u32_elems(np, "gpio-reserved-ranges");
if (len < 0 || len % 2 != 0)
@@ -445,8 +445,10 @@ int of_gpiochip_add(struct gpio_chip *chip) {
int status;

+ /*
if ((!chip->of_node) && (chip->dev))
chip->of_node = chip->dev->of_node;
+ */

if (!chip->of_node)
return 0;
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index d72218f..0fd443a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -296,7 +296,7 @@ static int gpiochip_init_valid_mask(struct gpio_chip *gpiochip) { #ifdef CONFIG_OF_GPIO
int size;
- struct device_node *np = gpiochip->dev->of_node;
+ struct device_node *np = gpiochip->of_node;

size = of_property_count_u32_elems(np, "gpio-reserved-ranges");
if (size > 0 && size % 2 == 0)
@@ -354,12 +354,16 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
int base = chip->base;
struct gpio_desc *descs;

+
descs = kcalloc(chip->ngpio, sizeof(descs[0]), GFP_KERNEL);
if (!descs)
return -ENOMEM;

chip->data = data;

+ if ((!chip->of_node) && (chip->dev))
+ chip->of_node = chip->dev->of_node;
+
spin_lock_irqsave(&gpio_lock, flags);

if (base < 0) {
--
2.7.4


Re: Build fail for linux-4.4.y-rc

Pavel Machek
 

Hi!

I've seen a failure this morning with our linux stable-rc build testing.

Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux 4.4.201-rc1
Arch: arm
Config: moxa_mxc_defconfig

Pipeline: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985
Failure: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985/failures
Log: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
Config: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180

All other configurations that we build were successful.
Thanks for heads-up!

I see warning during configuration:

HOSTLD scripts/kconfig/conf
arch/arm/configs/moxa_mxc_defconfig:745:warning: symbol value 'm'
invalid for RTC_DRV_DS1374_WDT
#

And this suggests a way to debug it. I'll try to do that.

MODPOST vmlinux.o
scripts/Makefile.modpost:97: recipe for target 'vmlinux.o' failed
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
FATAL: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
make[1]: *** [vmlinux.o] Error 1

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


Build fail for linux-4.4.y-rc

Chris Paterson
 

Hello maintainers,

I've seen a failure this morning with our linux stable-rc build testing.

Version: 4cb9b88c651a2fff886dd64b6d797343e7ddb4dd Linux 4.4.201-rc1
Arch: arm
Config: moxa_mxc_defconfig

Pipeline: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985
Failure: https://gitlab.com/cip-playground/linux-stable-rc-ci/pipelines/95016985/failures
Log: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180
Config: https://gitlab.com/cip-playground/linux-stable-rc-ci/-/jobs/346974180

All other configurations that we build were successful.

Kind regards, Chris


Re: [isar-cip-core PATCH 3/4] hihope-rzg2m: Add board support

Kazuhiro Hayashi
 

Hello Quirin,

On 11/7/19 3:29 AM, kazuhiro3.hayashi@... wrote:
Hello Quirin,

I will look into it using the cip-kernel-config instead of using copies
in isar.
Are you planning to "fetch" required config(s) for each target from cip-kernel-config?
or, keep copies of the configs in isar-cip-core then synchronize them at the specific point?
I try to fetch the configuration for each target from cip-kernel-config.
Thanks!
As the first step, I will do the same way in deby to use existing configs in cip-kernel-config.

Best regards,
Kazu

Currently I need to patch the config as Isar doesn't allow setting
CONFIG_LOCALVERSION in the kernel configuration.


Deby also has its own kernel configs (arm64 defconfig + Tiny hihope-rzg2m.config)
for HiHope RZG2M:
https://gitlab.com/cip-project/cip-core/deby/blob/cip-core-buster/meta-hihope-rzg2m/recipes-kernel/linux/linux-ba
se_git.bbappend
but they also should be replaced by the common kernel configs in CIP.
As the first step, I would provide configs by the same way as isar-cip-core.

Best regards,
Kazu

Quirin


Re: [PATCH] gpiolib: Support 'gpio-reserved-ranges' property

johnsonch.chen@moxa.com
 

Hi,

I try stable kernel (Linux 4.4.194) with my system. It's good and without gpio's kernel panic phenomena. Just for your reference.

Thanks,
Johnson

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Saturday, November 9, 2019 5:27 AM
To: Fabrizio Castro <fabrizio.castro@...>
Cc: Johnson CH Chen (陳昭勳) <JohnsonCH.Chen@...>; cip-dev@...; Biju Das <biju.das@...>
Subject: Re: [cip-dev] [PATCH] gpiolib: Support 'gpio-reserved-ranges' property

Hi!

Thank you for reporting this.
Is it -cip problem, or -stable problem?

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

6381 - 6400 of 10122