Re: [PATCH V5 00/12] 52-bit kernel + user VAs

2019-08-14 Thread Bhupesh Sharma
Hi Will, Steve,

I still see the following issue on a 48-bit hardware (i.e. _non_
ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
d2d73d2fef421ca0d4 as the HEAD:

[   41.318745] Freeing initrd memory: 25856K
[   41.12] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7
counters available
[   41.341818] kvm [1]: IPA Size Limit: 44bits
[   41.346131] kvm [1]: GICv3: no GICV resource entry
[   41.350908] kvm [1]: disabling GICv2 emulation
[   41.355358] kvm [1]: GIC system register CPU interface enabled
[   41.363504] kvm [1]: vgic interrupt IRQ1
[   41.370029] kvm [1]: VHE mode initialized successfully
[   41.380484] Unable to handle kernel paging request at virtual
address ffe432c8
[   41.388401] Mem abort info:
[   41.391182]   ESR = 0x9606
[   41.394227]   Exception class = DABT (current EL), IL = 32 bits
[   41.400133]   SET = 0, FnV = 0
[   41.403176]   EA = 0, S1PTW = 0
[   41.406303] Data abort info:
[   41.409170]   ISV = 0, ISS = 0x0006
[   41.412994]   CM = 0, WnR = 0
[   41.415949] swapper pgtable: 64k pages, 48-bit VAs, pgdp=8123
[   41.422726] [ffe432c8] pgd=81890003,
pud=81890003, pmd=
[   41.431413] Internal error: Oops: 9606 [#1] SMP
[   41.436278] Modules linked in:
[   41.439321] CPU: 2 PID: 1357 Comm: modprobe Not tainted 5.3.0-rc3+ #1
[   41.445748] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
0ACKL025 01/18/2019
[   41.453738] pstate: 8049 (Nzcv daif +PAN -UAO)
[   41.458520] pc : __check_object_size+0xc8/0x1f8
[   41.463037] lr : __check_object_size+0xac/0x1f8
[   41.467553] sp : 800031b2fcf0
[   41.470854] x29: 800031b2fcf0 x28: 009f51c1c440
[   41.476153] x27:  x26: 2d29
[   41.481451] x25: 009f51c1c440 x24: 0018
[   41.486749] x23: 0004 x22: 800010cb1a19
[   41.492046] x21: 0001 x20: 0001
[   41.497344] x19: 800010cb1a18 x18: 
[   41.502641] x17:  x16: 
[   41.507939] x15:  x14: 
[   41.513236] x13:  x12: 
[   41.518533] x11:  x10: 
[   41.523831] x9 :  x8 : 
[   41.529129] x7 : 3fcf x6 : 0018
[   41.534426] x5 : 800011d22840 x4 : 800011d22828
[   41.539723] x3 : 0002 x2 : ffe432c0
[   41.545021] x1 : c000 x0 : ffdfffe0
[   41.550319] Call trace:
[   41.552753]  __check_object_size+0xc8/0x1f8
[   41.556923]  filldir64+0x1e0/0x2d8
[   41.560312]  dcache_readdir+0x60/0x180
[   41.564048]  iterate_dir+0x14c/0x1a0
[   41.567609]  ksys_getdents64+0xa0/0x170
[   41.571431]  __arm64_sys_getdents64+0x28/0x38
[   41.575777]  el0_svc_handler+0xb0/0x180
[   41.579601]  el0_svc+0x8/0xc
[   41.582472] Code: b26babe0 d350fc42 f2dffbe0 8b021802 (f9400440)
[   41.588639] ---[ end trace 1e1de241f266e888 ]---
[   41.593243] Kernel panic - not syncing: Fatal exception
[   41.598477] SMP: stopping secondary CPUs
[   41.602431] Kernel Offset: disabled
[   41.605907] CPU features: 0x0002,22000c38
[   41.609902] Memory Limit: none
[   41.612967] ---[ end Kernel panic - not syncing: Fatal exception ]---

- git bisect points to 14c127c957c1c6070 as the offending patch.

- Here is a brief snippet of my .config flags enabling 48-bit VA and 52-bit PA:

CONFIG_ARM64_64K_PAGES=y
CONFIG_ARM64_VA_BITS_48=y
CONFIG_ARM64_VA_BITS=48
CONFIG_ARM64_PA_BITS_52=y
CONFIG_ARM64_PA_BITS=52

- Any idea if this is the same issue as Geert observed? Or should I
debug it further to determine the offending code in the patch pointed
to by git bisect.

Thanks,
Bhupesh

On Tue, Aug 13, 2019 at 7:06 PM Geert Uytterhoeven  wrote:
>
> Hi Will,
>
> On Tue, Aug 13, 2019 at 3:10 PM Will Deacon  wrote:
> > On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Aug 9, 2019 at 6:47 PM Will Deacon  wrote:
> > > > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote:
> > > > > This patch series adds support for 52-bit kernel VAs using some of the
> > > > > machinery already introduced by the 52-bit userspace VA code in 5.0.
> > > >
> > > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one
> > > > small patch on top and Catalin's tags added.
> > >
> > > As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the
> > > kernel log is spammed with
> > >
> > > virt_to_phys used for non-linear address: (ptrval)
> > > (__func__.6603+0x14d681/0x17fb3d)
> > > WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15
> > > __virt_to_phys+0x28/0x58
> > > Modules linked in:
> > > CPU: 0 PID: 264 Comm: mdev Not tainted
> > > 5.3.0-rc3-rcar3-initrd-2-g14c127c957c1c607 #38
> > > Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT)
> > > pstate: 6005 (nZCv daif -PAN -UAO)
> > > pc : __virt_to_phy

PLEASE CONFIRM PURCHASE ORDER

2019-08-14 Thread Mr NARESH KUMAR
Could you please confirm if your recieved our purchase order last week.

If no please confirm let me resend it to you.




NARESH KUMAR

Executive Purchase Saiapextrading Ltd

Dubai, KSA.

(T/F): +96-2667-264 777 / 778

(Mo): +96 94284 02803

Website - http://www.saiapexgeneraltrading.com


Re: [PATCH V5 00/12] 52-bit kernel + user VAs

2019-08-14 Thread Will Deacon
On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> I still see the following issue on a 48-bit hardware (i.e. _non_
> ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> d2d73d2fef421ca0d4 as the HEAD:

Have you tried the patches I posted here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html

?

Whilst they're being reviewed, I've dropped the 52-bit branch from
linux-next (for-next/core) so that people don't keep running into this.

Will


[PATCH] can: rcar_can: Remove unused platform data support

2019-08-14 Thread Geert Uytterhoeven
All R-Car platforms use DT for describing CAN controllers.
R-Car CAN platform data support was never used in any upstream kernel.

Move the Clock Select Register settings enum into the driver, and remove
platform data support and the corresponding header file.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/can/rcar/rcar_can.c   | 22 +-
 include/linux/can/platform/rcar_can.h | 18 --
 2 files changed, 9 insertions(+), 31 deletions(-)
 delete mode 100644 include/linux/can/platform/rcar_can.h

diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index cf218949a8fb52d5..3c5e9c2c5342147f 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -15,11 +15,17 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define RCAR_CAN_DRV_NAME  "rcar_can"
 
+/* Clock Select Register settings */
+enum CLKR {
+   CLKR_CLKP1 = 0, /* Peripheral clock (clkp1) */
+   CLKR_CLKP2 = 1, /* Peripheral clock (clkp2) */
+   CLKR_CLKEXT = 3 /* Externally input clock */
+};
+
 #define RCAR_SUPPORTED_CLOCKS  (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
 BIT(CLKR_CLKEXT))
 
@@ -736,7 +742,6 @@ static const char * const clock_names[] = {
 
 static int rcar_can_probe(struct platform_device *pdev)
 {
-   struct rcar_can_platform_data *pdata;
struct rcar_can_priv *priv;
struct net_device *ndev;
struct resource *mem;
@@ -745,17 +750,8 @@ static int rcar_can_probe(struct platform_device *pdev)
int err = -ENODEV;
int irq;
 
-   if (pdev->dev.of_node) {
-   of_property_read_u32(pdev->dev.of_node,
-"renesas,can-clock-select", &clock_select);
-   } else {
-   pdata = dev_get_platdata(&pdev->dev);
-   if (!pdata) {
-   dev_err(&pdev->dev, "No platform data provided!\n");
-   goto fail;
-   }
-   clock_select = pdata->clock_select;
-   }
+   of_property_read_u32(pdev->dev.of_node, "renesas,can-clock-select",
+&clock_select);
 
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
diff --git a/include/linux/can/platform/rcar_can.h 
b/include/linux/can/platform/rcar_can.h
deleted file mode 100644
index a43dcd0cf79ee3ec..
--- a/include/linux/can/platform/rcar_can.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _CAN_PLATFORM_RCAR_CAN_H_
-#define _CAN_PLATFORM_RCAR_CAN_H_
-
-#include 
-
-/* Clock Select Register settings */
-enum CLKR {
-   CLKR_CLKP1 = 0, /* Peripheral clock (clkp1) */
-   CLKR_CLKP2 = 1, /* Peripheral clock (clkp2) */
-   CLKR_CLKEXT = 3 /* Externally input clock */
-};
-
-struct rcar_can_platform_data {
-   enum CLKR clock_select; /* Clock source select */
-};
-
-#endif /* !_CAN_PLATFORM_RCAR_CAN_H_ */
-- 
2.17.1



[PATCH 2/3] serial: mxs-auart: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
returning an error value.  A simple NULL check is sufficient.

This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/mxs-auart.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4c188f4079b3ea68..e3452597068292f9 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -969,10 +969,8 @@ static int mxs_auart_dma_init(struct mxs_auart_port *s)
 
 }
 
-#define RTS_AT_AUART() IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(s->gpios,\
-   UART_GPIO_RTS))
-#define CTS_AT_AUART() IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(s->gpios,\
-   UART_GPIO_CTS))
+#define RTS_AT_AUART() !mctrl_gpio_to_gpiod(s->gpios, UART_GPIO_RTS)
+#define CTS_AT_AUART() !mctrl_gpio_to_gpiod(s->gpios, UART_GPIO_CTS)
 static void mxs_auart_settermios(struct uart_port *u,
 struct ktermios *termios,
 struct ktermios *old)
-- 
2.17.1



[PATCH 0/3] serial: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Hi Greg, Jiri,

Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check in serial drivers if
mctrl_gpio_to_gpiod() returns an error value.  A simple NULL check is
sufficient.

This series follows the spirit of commit 445df7ff3fd1a0a9 ("serial:
mctrl-gpio: drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Thanks!

Geert Uytterhoeven (3):
  serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error
  serial: mxs-auart: Don't check for mctrl_gpio_to_gpiod() returning
error
  serial: sh-sci: Don't check for mctrl_gpio_to_gpiod() returning error

 drivers/tty/serial/atmel_serial.c | 12 
 drivers/tty/serial/mxs-auart.c|  6 ++
 drivers/tty/serial/sh-sci.c   | 12 +---
 3 files changed, 11 insertions(+), 19 deletions(-)

-- 
2.17.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
returning an error value.  A simple NULL check is sufficient.

This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/atmel_serial.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index 19a85d6fe3d20541..e9620a81166b7dc1 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct 
uart_port *port)
 
mctrl_gpio_get(atmel_port->gpios, &ret);
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_CTS))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
if (ret & TIOCM_CTS)
status &= ~ATMEL_US_CTS;
else
status |= ATMEL_US_CTS;
}
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_DSR))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_DSR)) {
if (ret & TIOCM_DSR)
status &= ~ATMEL_US_DSR;
else
status |= ATMEL_US_DSR;
}
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_RI))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_RI)) {
if (ret & TIOCM_RI)
status &= ~ATMEL_US_RI;
else
status |= ATMEL_US_RI;
}
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_DCD))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_DCD)) {
if (ret & TIOCM_CD)
status &= ~ATMEL_US_DCD;
else
-- 
2.17.1



[PATCH 3/3] serial: sh-sci: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
returning an error value.  A simple NULL check is sufficient.

This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/sh-sci.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7f565fcbf1ca4c5e..4e754a4850e6db63 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2099,12 +2099,12 @@ static unsigned int sci_get_mctrl(struct uart_port 
*port)
if (s->autorts) {
if (sci_get_cts(port))
mctrl |= TIOCM_CTS;
-   } else if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS))) {
+   } else if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)) {
mctrl |= TIOCM_CTS;
}
-   if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR)))
+   if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR))
mctrl |= TIOCM_DSR;
-   if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD)))
+   if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD))
mctrl |= TIOCM_CAR;
 
return mctrl;
@@ -3285,10 +3285,8 @@ static int sci_probe_single(struct platform_device *dev,
return PTR_ERR(sciport->gpios);
 
if (sciport->has_rtscts) {
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
-   UART_GPIO_CTS)) ||
-   !IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
-   UART_GPIO_RTS))) {
+   if (mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_CTS) ||
+   mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_RTS)) {
dev_err(&dev->dev, "Conflicting RTS/CTS config\n");
return -EINVAL;
}
-- 
2.17.1



[PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
returning an error value.  A simple NULL check is sufficient.

This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/atmel_serial.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index 19a85d6fe3d20541..e9620a81166b7dc1 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct 
uart_port *port)
 
mctrl_gpio_get(atmel_port->gpios, &ret);
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_CTS))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
if (ret & TIOCM_CTS)
status &= ~ATMEL_US_CTS;
else
status |= ATMEL_US_CTS;
}
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_DSR))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_DSR)) {
if (ret & TIOCM_DSR)
status &= ~ATMEL_US_DSR;
else
status |= ATMEL_US_DSR;
}
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_RI))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_RI)) {
if (ret & TIOCM_RI)
status &= ~ATMEL_US_RI;
else
status |= ATMEL_US_RI;
}
 
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
-   UART_GPIO_DCD))) {
+   if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_DCD)) {
if (ret & TIOCM_CD)
status &= ~ATMEL_US_DCD;
else
-- 
2.17.1



[PATCH 0/3] serial: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Hi Greg, Jiri,

Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check in serial drivers if
mctrl_gpio_to_gpiod() returns an error value.  A simple NULL check is
sufficient.

This series follows the spirit of commit 445df7ff3fd1a0a9 ("serial:
mctrl-gpio: drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Thanks!

Geert Uytterhoeven (3):
  serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error
  serial: mxs-auart: Don't check for mctrl_gpio_to_gpiod() returning
error
  serial: sh-sci: Don't check for mctrl_gpio_to_gpiod() returning error

 drivers/tty/serial/atmel_serial.c | 12 
 drivers/tty/serial/mxs-auart.c|  6 ++
 drivers/tty/serial/sh-sci.c   | 12 +---
 3 files changed, 11 insertions(+), 19 deletions(-)

-- 
2.17.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH 2/3] serial: mxs-auart: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
returning an error value.  A simple NULL check is sufficient.

This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/mxs-auart.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4c188f4079b3ea68..e3452597068292f9 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -969,10 +969,8 @@ static int mxs_auart_dma_init(struct mxs_auart_port *s)
 
 }
 
-#define RTS_AT_AUART() IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(s->gpios,\
-   UART_GPIO_RTS))
-#define CTS_AT_AUART() IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(s->gpios,\
-   UART_GPIO_CTS))
+#define RTS_AT_AUART() !mctrl_gpio_to_gpiod(s->gpios, UART_GPIO_RTS)
+#define CTS_AT_AUART() !mctrl_gpio_to_gpiod(s->gpios, UART_GPIO_CTS)
 static void mxs_auart_settermios(struct uart_port *u,
 struct ktermios *termios,
 struct ktermios *old)
-- 
2.17.1



[PATCH 3/3] serial: sh-sci: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
routine"), mctrl_gpio_init() returns failure if the assignment to any
member of the gpio array results in an error pointer.
Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
!CONFIG_GPIOLIB case.
Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
returning an error value.  A simple NULL check is sufficient.

This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/sh-sci.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7f565fcbf1ca4c5e..4e754a4850e6db63 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2099,12 +2099,12 @@ static unsigned int sci_get_mctrl(struct uart_port 
*port)
if (s->autorts) {
if (sci_get_cts(port))
mctrl |= TIOCM_CTS;
-   } else if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS))) {
+   } else if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)) {
mctrl |= TIOCM_CTS;
}
-   if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR)))
+   if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR))
mctrl |= TIOCM_DSR;
-   if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD)))
+   if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD))
mctrl |= TIOCM_CAR;
 
return mctrl;
@@ -3285,10 +3285,8 @@ static int sci_probe_single(struct platform_device *dev,
return PTR_ERR(sciport->gpios);
 
if (sciport->has_rtscts) {
-   if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
-   UART_GPIO_CTS)) ||
-   !IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
-   UART_GPIO_RTS))) {
+   if (mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_CTS) ||
+   mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_RTS)) {
dev_err(&dev->dev, "Conflicting RTS/CTS config\n");
return -EINVAL;
}
-- 
2.17.1



Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Uwe Kleine-König
Hello,

[adding the Atmel guys to Cc]

On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
> Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> routine"), mctrl_gpio_init() returns failure if the assignment to any
> member of the gpio array results in an error pointer.
> Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> !CONFIG_GPIOLIB case.
> Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> returning an error value.  A simple NULL check is sufficient.
> 
> This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/tty/serial/atmel_serial.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c 
> b/drivers/tty/serial/atmel_serial.c
> index 19a85d6fe3d20541..e9620a81166b7dc1 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct 
> uart_port *port)
>  
>   mctrl_gpio_get(atmel_port->gpios, &ret);
>  
> - if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
> - UART_GPIO_CTS))) {
> + if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
>   if (ret & TIOCM_CTS)
>   status &= ~ATMEL_US_CTS;
>   else
>   status |= ATMEL_US_CTS;
>   }

The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
as expected (at least as expected by me). IMHO driving the hardware
function of the CTS pin shouldn't be conditional on the presence of a
cts-gpio. Is there a reason not to just drop the if completely?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH] can: rcar_can: Remove unused platform data support

2019-08-14 Thread Wolfram Sang
On Wed, Aug 14, 2019 at 11:22:21AM +0200, Geert Uytterhoeven wrote:
> All R-Car platforms use DT for describing CAN controllers.
> R-Car CAN platform data support was never used in any upstream kernel.
> 
> Move the Clock Select Register settings enum into the driver, and remove
> platform data support and the corresponding header file.
> 
> Signed-off-by: Geert Uytterhoeven 

Not tested on HW, but double-checked there are no users in-tree, there
is no dangling pdata pointer left in the driver, visual review of the
moved block, and build-tested.

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature


Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Geert Uytterhoeven
Hi Uwe,

On Wed, Aug 14, 2019 at 11:36 AM Uwe Kleine-König
 wrote:
> On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
> > Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> > routine"), mctrl_gpio_init() returns failure if the assignment to any
> > member of the gpio array results in an error pointer.
> > Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> > in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> > !CONFIG_GPIOLIB case.
> > Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> > returning an error value.  A simple NULL check is sufficient.
> >
> > This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> > drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
> >
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> >  drivers/tty/serial/atmel_serial.c | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/tty/serial/atmel_serial.c 
> > b/drivers/tty/serial/atmel_serial.c
> > index 19a85d6fe3d20541..e9620a81166b7dc1 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct 
> > uart_port *port)
> >
> >   mctrl_gpio_get(atmel_port->gpios, &ret);
> >
> > - if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
> > - UART_GPIO_CTS))) {
> > + if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> >   if (ret & TIOCM_CTS)
> >   status &= ~ATMEL_US_CTS;
> >   else
> >   status |= ATMEL_US_CTS;
> >   }
>
> The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
> as expected (at least as expected by me). IMHO driving the hardware
> function of the CTS pin shouldn't be conditional on the presence of a
> cts-gpio. Is there a reason not to just drop the if completely?

The above code returns the hardware status if CTS is not a GPIO, and
returns (overrides with) the GPIO status if CTS is a GPIO.
Isn't that correct, or am I missing something?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error

2019-08-14 Thread Uwe Kleine-König
On Wed, Aug 14, 2019 at 12:20:33PM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
> 
> On Wed, Aug 14, 2019 at 11:36 AM Uwe Kleine-König
>  wrote:
> > On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
> > > Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> > > routine"), mctrl_gpio_init() returns failure if the assignment to any
> > > member of the gpio array results in an error pointer.
> > > Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> > > in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> > > !CONFIG_GPIOLIB case.
> > > Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> > > returning an error value.  A simple NULL check is sufficient.
> > >
> > > This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> > > drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
> > >
> > > Signed-off-by: Geert Uytterhoeven 
> > > ---
> > >  drivers/tty/serial/atmel_serial.c | 12 
> > >  1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/atmel_serial.c 
> > > b/drivers/tty/serial/atmel_serial.c
> > > index 19a85d6fe3d20541..e9620a81166b7dc1 100644
> > > --- a/drivers/tty/serial/atmel_serial.c
> > > +++ b/drivers/tty/serial/atmel_serial.c
> > > @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct 
> > > uart_port *port)
> > >
> > >   mctrl_gpio_get(atmel_port->gpios, &ret);
> > >
> > > - if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
> > > - UART_GPIO_CTS))) {
> > > + if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> > >   if (ret & TIOCM_CTS)
> > >   status &= ~ATMEL_US_CTS;
> > >   else
> > >   status |= ATMEL_US_CTS;
> > >   }
> >
> > The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
> > as expected (at least as expected by me). IMHO driving the hardware
> > function of the CTS pin shouldn't be conditional on the presence of a
> > cts-gpio. Is there a reason not to just drop the if completely?
> 
> The above code returns the hardware status if CTS is not a GPIO, and
> returns (overrides with) the GPIO status if CTS is a GPIO.
> Isn't that correct, or am I missing something?

I took a deeper look into this driver now. The task for
atmel_get_lines_status() isn't to implement the get_mctrl() callback.

Instead this is called in the irqhandler to set ATMEL_US_RI in a
"pending" value that then later in atmel_handle_status() is translated
to a "ring" event that is handled there.

So the right cleanup would be to let atmel_get_lines_status() just be

return atmel_uart_readl(port, ATMEL_US_CSR);

. If something happend on the lines implemented as gpio the driver's irq
function isn't called anyhow.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH V5 00/12] 52-bit kernel + user VAs

2019-08-14 Thread Bhupesh Sharma
On Wed, Aug 14, 2019 at 1:51 PM Will Deacon  wrote:
>
> On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> > I still see the following issue on a 48-bit hardware (i.e. _non_
> > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> > d2d73d2fef421ca0d4 as the HEAD:
>
> Have you tried the patches I posted here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html
>
> ?
>
> Whilst they're being reviewed, I've dropped the 52-bit branch from
> linux-next (for-next/core) so that people don't keep running into this.

Thanks will try the above and get back with my results.

However just to make sure that the 52-bit changes are tested properly
(before landing up linux-next) - as we had issues with the 52-bit User
space VA + PA changes in the past (which broke userspace), I was
wondering if we can have a dedicated branch to have the v5 patches
from Steve + fixes, so that they can be easily tested and issues (if
any) reported with easy reference.

Or, if such a branch already exists, kindly share the pointer to the
same as well.

Thanks,
Bhupesh


Re: [PATCH V5 00/12] 52-bit kernel + user VAs

2019-08-14 Thread Will Deacon
[+Mark]

On Wed, Aug 14, 2019 at 05:29:09PM +0530, Bhupesh Sharma wrote:
> On Wed, Aug 14, 2019 at 1:51 PM Will Deacon  wrote:
> >
> > On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> > > I still see the following issue on a 48-bit hardware (i.e. _non_
> > > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> > > d2d73d2fef421ca0d4 as the HEAD:
> >
> > Have you tried the patches I posted here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html
> >
> > ?
> >
> > Whilst they're being reviewed, I've dropped the 52-bit branch from
> > linux-next (for-next/core) so that people don't keep running into this.
> 
> Thanks will try the above and get back with my results.
> 
> However just to make sure that the 52-bit changes are tested properly
> (before landing up linux-next) - as we had issues with the 52-bit User
> space VA + PA changes in the past (which broke userspace), I was
> wondering if we can have a dedicated branch to have the v5 patches
> from Steve + fixes, so that they can be easily tested and issues (if
> any) reported with easy reference.
> 
> Or, if such a branch already exists, kindly share the pointer to the
> same as well.

I've pushed the current round of fixes on top of:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/52-bit-kva

Mark has spotted a couple of other issues, but they shoudn't hold up your
testing (although I'm going to hold off putting this back into -next until
we've got them resolved).

Mark -- please use the branch above as a basis for any additional fixes.
HEAD should be d0b3c32ed922.

Thanks,

Will


Re: [PATCH] i2c: rcar: avoid race when unregistering slave client

2019-08-14 Thread Wolfram Sang
On Thu, Aug 08, 2019 at 09:39:10PM +0200, Wolfram Sang wrote:
> After we disabled interrupts, there might still be an active one
> running. Sync before clearing the pointer to the slave device.
> 
> Reported-by: Krzysztof Adamski 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: PGP signature


Re: [PATCH RFT] i2c: emev2: avoid race when unregistering slave client

2019-08-14 Thread Wolfram Sang
On Thu, Aug 08, 2019 at 09:54:17PM +0200, Wolfram Sang wrote:
> After we disabled interrupts, there might still be an active one
> running. Sync before clearing the pointer to the slave device.
> 
> Fixes: c31d0a00021d ("i2c: emev2: add slave support")
> Reported-by: Krzysztof Adamski 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: PGP signature


Re: [PATCH v2 0/4] dt-bindings: i2c: renesas: Rename bindings documentation files

2019-08-14 Thread Wolfram Sang
On Fri, Aug 09, 2019 at 02:30:00PM -0700, Simon Horman wrote:
> Rename the bindings documentation file for Renesas I2C controllers.
> 
> This is part of an ongoing effort to name bindings documentation files for
> Renesas IP blocks consistently, in line with the compat strings they
> document.
> 
> Based on v5.3-rc1
> 
> Changes since v1
> * Accumulate review tags
> * Correct changelogs
> 
> Simon Horman (4):
>   dt-bindings: i2c: sh_mobile: Rename bindings documentation file
>   dt-bindings: i2c: rcar: Rename bindings documentation file
>   dt-bindings: i2c: riic: Rename bindings documentation file
>   dt-bindings: i2c: i2c-emev2: Rename bindings documentation file

Applied to for-next, thanks!



signature.asc
Description: PGP signature


TODAY, Wed, Aug 14, 2019 I AM READY FOR COMING TO YOUR ADDRESS WITH THIS ATM CARD

2019-08-14 Thread MS. MARYANNA B. THOMASON
ATTN DEAR PARCEL BENEFICIARY.

I AM CATHY JONES,DIPLOMATIC AGENT ASIGNED ON THE DELIVERY OF YOUR ATM
CARD THROUGH MS. MARYANNA B. THOMASON, DHL MANAGEMENT DIRECTOR NEW
YORK.
TODAY, Wed, Aug 14, 2019 I AM READY FOR COMING TO YOUR ADDRESS WITH
THIS ATM CARD, So before i deliver I want you to send me.
official diplomatic agent delivery fee sum of $150.00 us
 only. I am here at JFK Airport,Florida. USA

SEND THIS FEE BY WESTERN UNION OR MONEY WITH RECEIVER'S NAME AND ADDRESS BELOW.

RECEIVER'S NAME-ERROL PRINGLE
ADDRESS3500 OLD DENTON RD APT 208; CARROLLTON, TEXAS 75007
COUNTRYUSA
AMOUNT$150.00 ONLY
TEST QUESTIONWHO IS THE CREATOR
ANSWER--GOD
 meanwhile this $150.00 is required by the Custom Service,USA Homeland
Security,for protection of your delivery, it will make the ATM CARD
and funds worth $15.8MILLION US DOLLARS secure, Beleiev me, this is my
word, remark my word,you will receive your delivery from me, Mrs.
Cathy Jones once you send this only $150.00 today.
I WAIT ON YOUR PAYMENT CONFIRMATION, ONCE I GOT YOUR PAYMENT, I WILL
FINALLY ARRIVE TO YOUR NEAREST ADDRESS. today
THANKS AND MAY GOD BLESS  YOU
CATHY JONES,DIPLOMATIC AGENT
EMAIL; katerinejone...@gmail.com
CALL OR TEXT ME, DIPLOMATIC AGENT MS. CATHY JONES
Phone Number; (408) 650-6103,


[PATCH] pinctrl: rza1: Add of_node_put() before return

2019-08-14 Thread Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return in
three places.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/pinctrl/pinctrl-rza1.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
index 021e37b7689e..8eeb9545137b 100644
--- a/drivers/pinctrl/pinctrl-rza1.c
+++ b/drivers/pinctrl/pinctrl-rza1.c
@@ -866,8 +866,10 @@ static int rza1_dt_node_pin_count(struct device_node *np)
npins = 0;
for_each_child_of_node(np, child) {
of_pins = of_find_property(child, "pinmux", NULL);
-   if (!of_pins)
+   if (!of_pins) {
+   of_node_put(child);
return -EINVAL;
+   }
 
npins += of_pins->length / sizeof(u32);
}
@@ -1025,8 +1027,10 @@ static int rza1_dt_node_to_map(struct pinctrl_dev 
*pctldev,
for_each_child_of_node(np, child) {
ret = rza1_parse_pinmux_node(rza1_pctl, child, mux_conf,
 grpin);
-   if (ret < 0)
+   if (ret < 0) {
+   of_node_put(child);
return ret;
+   }
 
grpin += ret;
mux_conf += ret;
@@ -1272,8 +1276,10 @@ static int rza1_gpio_register(struct rza1_pinctrl 
*rza1_pctl)
 
ret = rza1_parse_gpiochip(rza1_pctl, child, &gpio_chips[i],
  &gpio_ranges[i]);
-   if (ret)
+   if (ret) {
+   of_node_put(child);
return ret;
+   }
 
++i;
}
-- 
2.19.1



[PATCH] soc: renesas: rcar-sysc: Add goto to of_node_put() before return

2019-08-14 Thread Nishka Dasgupta
The local variable np in function rcar_sysc_pd_init takes the return
value of of_find_matching_node_and_match, which gets a node but does not
put it. If np is not put before the function returns, it may cause a
memory leak. Hence, remove the return statement that does not
immediately follow a putting of np. Replace it with a goto pointing to a
pre-existing label that first puts np and then returns the required
value.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/soc/renesas/rcar-sysc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 0c80fab4f8de..8a53f18d0429 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -346,7 +346,7 @@ static int __init rcar_sysc_pd_init(void)
if (info->init) {
error = info->init();
if (error)
-   return error;
+   goto out_put;
}
 
has_cpg_mstp = of_find_compatible_node(NULL, NULL,
-- 
2.19.1