Re: [PATCH 4/6] bus: add driver for the Technologic Systems NBUS

[Linus Walleij]

On Thu, Dec 15, 2016 at 12:12 AM, Sebastien Bourdelin
 wrote:

> This driver implements a GPIOs bit-banged bus, called the NBUS by
> Technologic Systems. It is used to communicate with the peripherals in
> the FPGA on the TS-4600 SoM.
>
> Signed-off-by: Sebastien Bourdelin 
(...)

> +#include 

Use:
#include 
instead, and deal with the fallout.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Don't use this.

> +#include 
> +#include 
> +
> +static DEFINE_MUTEX(ts_nbus_lock);
> +static bool ts_nbus_ready;

Why not move this to the struct ts_nbus state container?

It seems to be per-bus not per-system.

> +#define TS_NBUS_READ_MODE  0
> +#define TS_NBUS_WRITE_MODE 1
> +#define TS_NBUS_DIRECTION_IN  0
> +#define TS_NBUS_DIRECTION_OUT 1
> +#define TS_NBUS_WRITE_ADR 0
> +#define TS_NBUS_WRITE_VAL 1
> +
> +struct ts_nbus {
> +   struct pwm_device *pwm;
> +   int num_data;
> +   int *data;
> +   int csn;
> +   int txrx;
> +   int strobe;
> +   int ale;
> +   int rdy;
> +};
> +
> +static struct ts_nbus *ts_nbus;

Nopes. No singletons please.

Use the state container pattern:
Documentation/driver-model/design-patterns.txt

> +/*
> + * request all gpios required by the bus.
> + */
> +static int ts_nbus_init(struct platform_device *pdev)
> +{
> +   int err;
> +   int i;
> +
> +   for (i = 0; i < ts_nbus->num_data; i++) {
> +   err = devm_gpio_request_one(>dev, ts_nbus->data[i],
> +   GPIOF_OUT_INIT_HIGH,
> +   "TS NBUS data");
> +   if (err)
> +   return err;
> +   }

DO not use the legacy GPIO API anywhere.

Reference the device and use gpiod_get() simple, fair and square.

Store struct gpio_desc * pointers in your state container instead.

> +static int ts_nbus_get_of_pdata(struct device *dev, struct device_node *np)
> +{
> +   int num_data;
> +   int *data;
> +   int ret;
> +   int i;
> +
> +   ret = of_gpio_named_count(np, "data-gpios");
> +   if (ret < 0) {
> +   dev_err(dev,
> +   "failed to count GPIOs in DT property data-gpios\n");
> +   return ret;
> +   }

Do not reinvent the wheel.

Use devm_gpiod_get_array().


> +   ret = of_get_named_gpio(np, "csn-gpios", 0);

And again use devm_gpiod_get(), and gpiod_* accessors.
Applies everywhere.

Yours,
Linus Walleij

Re: [PATCH 4/6] bus: add driver for the Technologic Systems NBUS

[Linus Walleij]

On Thu, Dec 15, 2016 at 12:12 AM, Sebastien Bourdelin
 wrote:

> This driver implements a GPIOs bit-banged bus, called the NBUS by
> Technologic Systems. It is used to communicate with the peripherals in
> the FPGA on the TS-4600 SoM.
>
> Signed-off-by: Sebastien Bourdelin 
(...)

> +#include 

Use:
#include 
instead, and deal with the fallout.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Don't use this.

> +#include 
> +#include 
> +
> +static DEFINE_MUTEX(ts_nbus_lock);
> +static bool ts_nbus_ready;

Why not move this to the struct ts_nbus state container?

It seems to be per-bus not per-system.

> +#define TS_NBUS_READ_MODE  0
> +#define TS_NBUS_WRITE_MODE 1
> +#define TS_NBUS_DIRECTION_IN  0
> +#define TS_NBUS_DIRECTION_OUT 1
> +#define TS_NBUS_WRITE_ADR 0
> +#define TS_NBUS_WRITE_VAL 1
> +
> +struct ts_nbus {
> +   struct pwm_device *pwm;
> +   int num_data;
> +   int *data;
> +   int csn;
> +   int txrx;
> +   int strobe;
> +   int ale;
> +   int rdy;
> +};
> +
> +static struct ts_nbus *ts_nbus;

Nopes. No singletons please.

Use the state container pattern:
Documentation/driver-model/design-patterns.txt

> +/*
> + * request all gpios required by the bus.
> + */
> +static int ts_nbus_init(struct platform_device *pdev)
> +{
> +   int err;
> +   int i;
> +
> +   for (i = 0; i < ts_nbus->num_data; i++) {
> +   err = devm_gpio_request_one(>dev, ts_nbus->data[i],
> +   GPIOF_OUT_INIT_HIGH,
> +   "TS NBUS data");
> +   if (err)
> +   return err;
> +   }

DO not use the legacy GPIO API anywhere.

Reference the device and use gpiod_get() simple, fair and square.

Store struct gpio_desc * pointers in your state container instead.

> +static int ts_nbus_get_of_pdata(struct device *dev, struct device_node *np)
> +{
> +   int num_data;
> +   int *data;
> +   int ret;
> +   int i;
> +
> +   ret = of_gpio_named_count(np, "data-gpios");
> +   if (ret < 0) {
> +   dev_err(dev,
> +   "failed to count GPIOs in DT property data-gpios\n");
> +   return ret;
> +   }

Do not reinvent the wheel.

Use devm_gpiod_get_array().


> +   ret = of_get_named_gpio(np, "csn-gpios", 0);

And again use devm_gpiod_get(), and gpiod_* accessors.
Applies everywhere.

Yours,
Linus Walleij

Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio

[Linus Walleij]

On Wed, Dec 14, 2016 at 6:41 PM, Peter Rosin  wrote:
> On 2016-12-14 18:01, Sebastian Reichel wrote:
>> [of course I forgot to actually add gpio people, let's try again]
>>
>> On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
>>> Hi,
>>>
>>> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
 If several parallel bq24735 chargers have their ac-detect gpios wired
 together (or if only one of the parallel bq24735 chargers have its
 ac-detect pin wired to a gpio, and the others are assumed to react the
 same), then all driver instances need to check the same gpio. But the
 gpio subsystem does not allow sharing gpios, so handle that locally.
>>>
>>> Adding GPIO subsystem people to see if they can come up with
>>> something in the gpiod API for this usecase.
>
> Right, I don't like how my new code steps away from gpio descriptors.

The issue of shared gpiods have come up over and over again.
For example the messy regulator code needs this too.

It is better if we implement something like gpiod_get_shared()
in the gpiolib of these cases.

Just put a refcount in struct gpio_desc in drivers/gpio/gpiolib.h
for this case I guess?

Yours,
Linus Walleij

Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio

[Linus Walleij]

On Wed, Dec 14, 2016 at 6:41 PM, Peter Rosin  wrote:
> On 2016-12-14 18:01, Sebastian Reichel wrote:
>> [of course I forgot to actually add gpio people, let's try again]
>>
>> On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
>>> Hi,
>>>
>>> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
 If several parallel bq24735 chargers have their ac-detect gpios wired
 together (or if only one of the parallel bq24735 chargers have its
 ac-detect pin wired to a gpio, and the others are assumed to react the
 same), then all driver instances need to check the same gpio. But the
 gpio subsystem does not allow sharing gpios, so handle that locally.
>>>
>>> Adding GPIO subsystem people to see if they can come up with
>>> something in the gpiod API for this usecase.
>
> Right, I don't like how my new code steps away from gpio descriptors.

The issue of shared gpiods have come up over and over again.
For example the messy regulator code needs this too.

It is better if we implement something like gpiod_get_shared()
in the gpiolib of these cases.

Just put a refcount in struct gpio_desc in drivers/gpio/gpiolib.h
for this case I guess?

Yours,
Linus Walleij

Re: [PATCH] pinctrl: fix DT bindings for marvell,kirkwood-pinctrl

[Linus Walleij]

On Wed, Dec 14, 2016 at 12:08 AM, Andreas Klinger  wrote:

> On Marvell mv88f6180 mpp pins range from 0 to 19 as well as from 35 to 44.
> This is already fixed in commit: 9573e7923007961799beff38bc5c5a7635634eef
>
> This is the documentation change for above commit.
>
> Signed-off-by: Andreas Klinger 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: fix DT bindings for marvell,kirkwood-pinctrl

[Linus Walleij]

On Wed, Dec 14, 2016 at 12:08 AM, Andreas Klinger  wrote:

> On Marvell mv88f6180 mpp pins range from 0 to 19 as well as from 35 to 44.
> This is already fixed in commit: 9573e7923007961799beff38bc5c5a7635634eef
>
> This is the documentation change for above commit.
>
> Signed-off-by: Andreas Klinger 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control

[Lothar Waßmann]

Hi,

On Thu, 29 Dec 2016 14:27:25 -0800 Steve Longerbeam wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
> 
> Signed-off-by: Steve Longerbeam 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> 
> v2:
> - documented optional reset-gpios property in
>   Documentation/devicetree/bindings/gpio/gpio-pca953x.txt.
> ---
>  Documentation/devicetree/bindings/gpio/gpio-pca953x.txt |  4 
>  drivers/gpio/gpio-pca953x.c | 17 
> +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index 08dd15f..da54f4c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -29,6 +29,10 @@ Required properties:
>   onsemi,pca9654
>   exar,xra1202
>  
> +Optional properties:
> + - reset-gpios: GPIO specification for the RESET input
> +
> +
>  Example:
>  
>  
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d5d72d8..d1c0bd5 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define PCA953X_INPUT0
>  #define PCA953X_OUTPUT   1
> @@ -133,6 +134,7 @@ struct pca953x_chip {
>   const char *const *names;
>   unsigned long driver_data;
>   struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
>  
>   const struct pca953x_reg_config *regs;
>  
> @@ -756,6 +758,21 @@ static int pca953x_probe(struct i2c_client *client,
>   } else {
>   chip->gpio_start = -1;
>   irq_base = 0;
> +
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(>dev,
> +"reset",
> +GPIOD_OUT_LOW);

> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(>dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
> +
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(>dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
>
The pin is already initialized to the inactive state thru the
GPIOD_OUT_LOW flag in devm_gpiod_get_optional(), so this call to
gpiod_set_value() is useless.


Lothar Waßmann

Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control

[Lothar Waßmann]

Hi,

On Thu, 29 Dec 2016 14:27:25 -0800 Steve Longerbeam wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
> 
> Signed-off-by: Steve Longerbeam 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> 
> v2:
> - documented optional reset-gpios property in
>   Documentation/devicetree/bindings/gpio/gpio-pca953x.txt.
> ---
>  Documentation/devicetree/bindings/gpio/gpio-pca953x.txt |  4 
>  drivers/gpio/gpio-pca953x.c | 17 
> +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index 08dd15f..da54f4c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -29,6 +29,10 @@ Required properties:
>   onsemi,pca9654
>   exar,xra1202
>  
> +Optional properties:
> + - reset-gpios: GPIO specification for the RESET input
> +
> +
>  Example:
>  
>  
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d5d72d8..d1c0bd5 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define PCA953X_INPUT0
>  #define PCA953X_OUTPUT   1
> @@ -133,6 +134,7 @@ struct pca953x_chip {
>   const char *const *names;
>   unsigned long driver_data;
>   struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
>  
>   const struct pca953x_reg_config *regs;
>  
> @@ -756,6 +758,21 @@ static int pca953x_probe(struct i2c_client *client,
>   } else {
>   chip->gpio_start = -1;
>   irq_base = 0;
> +
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(>dev,
> +"reset",
> +GPIOD_OUT_LOW);

> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(>dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
> +
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(>dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
>
The pin is already initialized to the inactive state thru the
GPIOD_OUT_LOW flag in devm_gpiod_get_optional(), so this call to
gpiod_set_value() is useless.


Lothar Waßmann

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

[Jaewon Kim]

Hello Michal Hocko and and Michal Nazarewichz

On 2016년 12월 29일 23:20, Michal Nazarewicz wrote:
> On Thu, Dec 29 2016, Michal Hocko wrote:
>> On Thu 29-12-16 11:28:02, Jaewon Kim wrote:
>>> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, 
>>> EINTR.
>>> This patch prints the error value and bitmap status to know available pages
>>> regarding fragmentation.
>>>
>>> This is an ENOMEM example with this patch.
>>> [   11.616321]  [2:   Binder:711_1:  740] cma: cma_alloc: alloc failed, 
>>> req-size: 256 pages, ret: -12
>>> [   11.616365]  [2:   Binder:711_1:  740] number of available pages: 
>>> 4+7+7+8+38+166+127=>357 pages, total: 2048 pages
>> Could you be more specific why this part is useful?
The first line is useful to know why the allocation failed.
Actually CMA internally try all available regions because some regions can be 
failed because of EBUSY.
The second showing bitmap status is useful to know in detail on both ENONEM and 
EBUSY;
 ENOMEM:  not tried at all because of no available region
 EBUSY:  tried some region but all failed
>>> Signed-off-by: Jaewon Kim 
>>> ---
>>>  mm/cma.c | 29 -
>>>  1 file changed, 28 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/cma.c b/mm/cma.c
>>> index c960459..535aa39 100644
>>> --- a/mm/cma.c
>>> +++ b/mm/cma.c
>>> @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>>> unsigned int align)
>>> unsigned long start = 0;
>>> unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>>> struct page *page = NULL;
>>> -   int ret;
>>> +   int ret = -ENOMEM;
>>>  
>>> if (!cma || !cma->count)
>>> return NULL;
>>> @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>>> unsigned int align)
>>> trace_cma_alloc(pfn, page, count, align);
>>>  
>>> pr_debug("%s(): returned %p\n", __func__, page);
>>> +
>>> +   if (ret != 0) {
>>> +   unsigned int nr, nr_total = 0;
>>> +   unsigned long next_set_bit;
>>> +
>>> +   pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
>>> +   __func__, count, ret);
>>> +   mutex_lock(>lock);
>>> +   printk("number of available pages: ");
>>> +   start = 0;
>>> +   for (;;) {
>>> +   bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, 
>>> start);
>>> +   next_set_bit = find_next_bit(cma->bitmap, cma->count, 
>>> bitmap_no);
>>> +   nr = next_set_bit - bitmap_no;
>>> +   if (bitmap_no >= cma->count)
>>> +   break;
> Put this just next to ‘bitmap_no = …’ line.  No need to call
> find_next_bit if we’re gonna break anyway.
thank you I fixed
>>> +   if (nr_total == 0)
>>> +   printk("%u", nr);
>>> +   else
>>> +   printk("+%u", nr);
> Perhaps also include location of the hole?  Something like:
>
>   pr_cont("%s%u@%u", nr_total ? "+" : "", nr, bitmap_no);
Thank you I fixed with @%lu
>
>>> +   nr_total += nr;
>>> +   start = bitmap_no + nr;
>>> +   }
>>> +   printk("=>%u pages, total: %lu pages\n", nr_total, cma->count);
>>> +   mutex_unlock(>lock);
>>> +   }
>>> +
> I wonder if this should be wrapped in
>
> #ifdef CMA_DEBUG
> …
> #endif
>
> On one hand it’s relatively expensive (even involving mutex locking) on
> the other it’s in allocation failure path.
bitmap status, I think, could be in side of CMA_DEBUG with the mutex
but the first error log, I hope, to be out of CMA_DEBUG.
>
>>> return page;
>>>  }
>>>  
>>> -- 
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>> the body to majord...@kvack.org.  For more info on Linux MM,
>>> see: http://www.linux-mm.org/ .
>>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>> -- 
>> Michal Hocko
>> SUSE Labs
This is fixed patch following your comment.
Please review again
If it is OK, let me know whether I need to resend this patch as a new mail 
thread.


>From 7577cc94da3af27907aa6eec590d2ef51e4b9d80 Mon Sep 17 00:00:00 2001
From: Jaewon Kim 
Date: Thu, 29 Dec 2016 11:00:16 +0900
Subject: [PATCH] mm: cma: print allocation failure reason and bitmap status

There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, EINTR.
But we did not know error reason so far. This patch prints the error value.

Additionally if CONFIG_CMA_DEBUG is enabled, this patch shows bitmap status to
know available pages. Actually CMA internally try all available regions because
some regions can be failed because of EBUSY. Bitmap status is useful to know in
detail on both ENONEM and EBUSY;
 ENOMEM: not tried at all because of no available region
 it could be too small total region or could be fragmentation issue
 EBUSY:  tried some region but all failed

This is an 

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

[Jaewon Kim]

Hello Michal Hocko and and Michal Nazarewichz

On 2016년 12월 29일 23:20, Michal Nazarewicz wrote:
> On Thu, Dec 29 2016, Michal Hocko wrote:
>> On Thu 29-12-16 11:28:02, Jaewon Kim wrote:
>>> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, 
>>> EINTR.
>>> This patch prints the error value and bitmap status to know available pages
>>> regarding fragmentation.
>>>
>>> This is an ENOMEM example with this patch.
>>> [   11.616321]  [2:   Binder:711_1:  740] cma: cma_alloc: alloc failed, 
>>> req-size: 256 pages, ret: -12
>>> [   11.616365]  [2:   Binder:711_1:  740] number of available pages: 
>>> 4+7+7+8+38+166+127=>357 pages, total: 2048 pages
>> Could you be more specific why this part is useful?
The first line is useful to know why the allocation failed.
Actually CMA internally try all available regions because some regions can be 
failed because of EBUSY.
The second showing bitmap status is useful to know in detail on both ENONEM and 
EBUSY;
 ENOMEM:  not tried at all because of no available region
 EBUSY:  tried some region but all failed
>>> Signed-off-by: Jaewon Kim 
>>> ---
>>>  mm/cma.c | 29 -
>>>  1 file changed, 28 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/cma.c b/mm/cma.c
>>> index c960459..535aa39 100644
>>> --- a/mm/cma.c
>>> +++ b/mm/cma.c
>>> @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>>> unsigned int align)
>>> unsigned long start = 0;
>>> unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>>> struct page *page = NULL;
>>> -   int ret;
>>> +   int ret = -ENOMEM;
>>>  
>>> if (!cma || !cma->count)
>>> return NULL;
>>> @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
>>> unsigned int align)
>>> trace_cma_alloc(pfn, page, count, align);
>>>  
>>> pr_debug("%s(): returned %p\n", __func__, page);
>>> +
>>> +   if (ret != 0) {
>>> +   unsigned int nr, nr_total = 0;
>>> +   unsigned long next_set_bit;
>>> +
>>> +   pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
>>> +   __func__, count, ret);
>>> +   mutex_lock(>lock);
>>> +   printk("number of available pages: ");
>>> +   start = 0;
>>> +   for (;;) {
>>> +   bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, 
>>> start);
>>> +   next_set_bit = find_next_bit(cma->bitmap, cma->count, 
>>> bitmap_no);
>>> +   nr = next_set_bit - bitmap_no;
>>> +   if (bitmap_no >= cma->count)
>>> +   break;
> Put this just next to ‘bitmap_no = …’ line.  No need to call
> find_next_bit if we’re gonna break anyway.
thank you I fixed
>>> +   if (nr_total == 0)
>>> +   printk("%u", nr);
>>> +   else
>>> +   printk("+%u", nr);
> Perhaps also include location of the hole?  Something like:
>
>   pr_cont("%s%u@%u", nr_total ? "+" : "", nr, bitmap_no);
Thank you I fixed with @%lu
>
>>> +   nr_total += nr;
>>> +   start = bitmap_no + nr;
>>> +   }
>>> +   printk("=>%u pages, total: %lu pages\n", nr_total, cma->count);
>>> +   mutex_unlock(>lock);
>>> +   }
>>> +
> I wonder if this should be wrapped in
>
> #ifdef CMA_DEBUG
> …
> #endif
>
> On one hand it’s relatively expensive (even involving mutex locking) on
> the other it’s in allocation failure path.
bitmap status, I think, could be in side of CMA_DEBUG with the mutex
but the first error log, I hope, to be out of CMA_DEBUG.
>
>>> return page;
>>>  }
>>>  
>>> -- 
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>> the body to majord...@kvack.org.  For more info on Linux MM,
>>> see: http://www.linux-mm.org/ .
>>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>> -- 
>> Michal Hocko
>> SUSE Labs
This is fixed patch following your comment.
Please review again
If it is OK, let me know whether I need to resend this patch as a new mail 
thread.


>From 7577cc94da3af27907aa6eec590d2ef51e4b9d80 Mon Sep 17 00:00:00 2001
From: Jaewon Kim 
Date: Thu, 29 Dec 2016 11:00:16 +0900
Subject: [PATCH] mm: cma: print allocation failure reason and bitmap status

There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, EINTR.
But we did not know error reason so far. This patch prints the error value.

Additionally if CONFIG_CMA_DEBUG is enabled, this patch shows bitmap status to
know available pages. Actually CMA internally try all available regions because
some regions can be failed because of EBUSY. Bitmap status is useful to know in
detail on both ENONEM and EBUSY;
 ENOMEM: not tried at all because of no available region
 it could be too small total region or could be fragmentation issue
 EBUSY:  tried some region but all failed

This is an ENOMEM example with this patch.
[   13.250961]  [1:   

Re: [PATCH] mm: Drop "PFNs busy" printk in an expected path.

[Michal Nazarewicz]

On Thu, Dec 29 2016, Eric Anholt wrote:
> Michal Nazarewicz  writes:
>
>> On Thu, Dec 29 2016, Eric Anholt wrote:
>>> Michal Hocko  writes:
>>>
 This has been already brought up
 http://lkml.kernel.org/r/20161130092239.gd18...@dhcp22.suse.cz and there
 was a proposed patch for that which ratelimited the output
 http://lkml.kernel.org/r/20161130132848.gg18...@dhcp22.suse.cz resp.
 http://lkml.kernel.org/r/robbat2-20161130t195244-9985399...@orbis-terrarum.net

 then the email thread just died out because the issue turned out to be a
 configuration issue. Michal indicated that the message might be useful
 so dropping it completely seems like a bad idea. I do agree that
 something has to be done about that though. Can we reconsider the
 ratelimit thing?
>>>
>>> I agree that the rate of the message has gone up during 4.9 -- it used
>>> to be a few per second.
>>
>> Sounds like a regression which should be fixed.
>>
>> This is why I don’t think removing the message is a good idea.  If you
>> suddenly see a lot of those messages, something changed for the worse.
>> If you remove this message, you will never know.
>>
>>> However, if this is an expected path during normal operation,
>>
>> This depends on your definition of ‘expected’ and ‘normal’.
>>
>> In general, I would argue that the fact those ever happen is a bug
>> somewhere in the kernel – if memory is allocated as movable, it should
>> be movable damn it!
>
> I was taking "expected" from dae803e165a11bc88ca8dbc07a11077caf97bbcb --
> if this is a actually a bug, how do we go about debugging it?

That’s why I’ve pointed out that this depends on the definition.  In my
opinion it’s a design bug which is now nearly impossible to fix in
efficient way.

The most likely issues is that some subsystem is allocating movable
memory but then either does not provide a way to actually move it
(that’s an obvious bug in the code IMO) or pins the memory while some
transaction is performed and at the same time CMA tries to move it.

The latter case is really unavoidable at this point which is why this
message is ‘expected’.

But if suddenly, the rate of the messages increases dramatically, you
have yourself a performance regression.

> I've had Raspbian carrying a patch downstream to remove the error
> message for 2 years now, and I either need to get this fixed or get this
> patch merged to Fedora and Debian as well, now that they're shipping
> some support for Raspberry Pi.

-- 
Best regards
ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: [PATCH] mm: Drop "PFNs busy" printk in an expected path.

[Michal Nazarewicz]

On Thu, Dec 29 2016, Eric Anholt wrote:
> Michal Nazarewicz  writes:
>
>> On Thu, Dec 29 2016, Eric Anholt wrote:
>>> Michal Hocko  writes:
>>>
 This has been already brought up
 http://lkml.kernel.org/r/20161130092239.gd18...@dhcp22.suse.cz and there
 was a proposed patch for that which ratelimited the output
 http://lkml.kernel.org/r/20161130132848.gg18...@dhcp22.suse.cz resp.
 http://lkml.kernel.org/r/robbat2-20161130t195244-9985399...@orbis-terrarum.net

 then the email thread just died out because the issue turned out to be a
 configuration issue. Michal indicated that the message might be useful
 so dropping it completely seems like a bad idea. I do agree that
 something has to be done about that though. Can we reconsider the
 ratelimit thing?
>>>
>>> I agree that the rate of the message has gone up during 4.9 -- it used
>>> to be a few per second.
>>
>> Sounds like a regression which should be fixed.
>>
>> This is why I don’t think removing the message is a good idea.  If you
>> suddenly see a lot of those messages, something changed for the worse.
>> If you remove this message, you will never know.
>>
>>> However, if this is an expected path during normal operation,
>>
>> This depends on your definition of ‘expected’ and ‘normal’.
>>
>> In general, I would argue that the fact those ever happen is a bug
>> somewhere in the kernel – if memory is allocated as movable, it should
>> be movable damn it!
>
> I was taking "expected" from dae803e165a11bc88ca8dbc07a11077caf97bbcb --
> if this is a actually a bug, how do we go about debugging it?

That’s why I’ve pointed out that this depends on the definition.  In my
opinion it’s a design bug which is now nearly impossible to fix in
efficient way.

The most likely issues is that some subsystem is allocating movable
memory but then either does not provide a way to actually move it
(that’s an obvious bug in the code IMO) or pins the memory while some
transaction is performed and at the same time CMA tries to move it.

The latter case is really unavoidable at this point which is why this
message is ‘expected’.

But if suddenly, the rate of the messages increases dramatically, you
have yourself a performance regression.

> I've had Raspbian carrying a patch downstream to remove the error
> message for 2 years now, and I either need to get this fixed or get this
> patch merged to Fedora and Debian as well, now that they're shipping
> some support for Raspberry Pi.

-- 
Best regards
ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline

[Shawn Guo]

On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> Found while reviewing Marvell dsa bindings usage.
> 
> Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch 
> interrupts")
> Cc: Andrew Lunn 
> Cc: David S. Miller 
> Signed-off-by: Andreas Färber 

Applied, thanks.

Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline

[Shawn Guo]

On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> Found while reviewing Marvell dsa bindings usage.
> 
> Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch 
> interrupts")
> Cc: Andrew Lunn 
> Cc: David S. Miller 
> Signed-off-by: Andreas Färber 

Applied, thanks.

Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline

[Shawn Guo]

On Sun, Nov 27, 2016 at 10:35:16PM +0100, Andrew Lunn wrote:
> On Sun, Nov 27, 2016 at 10:30:54PM +0100, Andreas Färber wrote:
> > Hi,
> > 
> > Am 27.11.2016 um 22:17 schrieb Andrew Lunn:
> > > On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> > >> Found while reviewing Marvell dsa bindings usage.
> > > 
> > > Hi Andreas
> > > 
> > > It is good practice to put the maintainer you expect to accept the
> > > patch on the To: line. You have at least two different maintainers on
> > > Cc: so it is currently ambiguous. And these lists can be high volume,
> > > so without a copy in the maintainers inbox, patches can be overlooked.
> > 
> > As a vf610 DT patch with LAKML in To I am expecting it to be handled by
> > Shawn or anyone from the NXP/ARM side.
> 
> So please have Shawn as To:
> 
> The patch you are fixing went through Dave Miller, who is also on Cc:,
> hence the ambiguity.

The good practice was broken from the beginning when patch "arm: vf610:
zii devel b: Add support for switch interrupts") went through net tree,
even without me on copy.

Shawn

Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline

[Shawn Guo]

On Sun, Nov 27, 2016 at 10:35:16PM +0100, Andrew Lunn wrote:
> On Sun, Nov 27, 2016 at 10:30:54PM +0100, Andreas Färber wrote:
> > Hi,
> > 
> > Am 27.11.2016 um 22:17 schrieb Andrew Lunn:
> > > On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> > >> Found while reviewing Marvell dsa bindings usage.
> > > 
> > > Hi Andreas
> > > 
> > > It is good practice to put the maintainer you expect to accept the
> > > patch on the To: line. You have at least two different maintainers on
> > > Cc: so it is currently ambiguous. And these lists can be high volume,
> > > so without a copy in the maintainers inbox, patches can be overlooked.
> > 
> > As a vf610 DT patch with LAKML in To I am expecting it to be handled by
> > Shawn or anyone from the NXP/ARM side.
> 
> So please have Shawn as To:
> 
> The patch you are fixing went through Dave Miller, who is also on Cc:,
> hence the ambiguity.

The good practice was broken from the beginning when patch "arm: vf610:
zii devel b: Add support for switch interrupts") went through net tree,
even without me on copy.

Shawn

[PATCH v3 2/2] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index db879f4..7434b22 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -252,11 +252,42 @@
reg = <1>;
 
dsi_out: endpoint {
+   remote-endpoint = <_in>;
samsung,burst-clock-frequency = <51200>;
samsung,esc-clock-frequency = <1600>;
};
};
};
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <1487>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <15>;
+   vsync-len = <1>;
+   };
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
 _0 {
-- 
1.9.1

[PATCH v3 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
---
Changes for V3:

- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

[1]: Documentation/devicetree/bindings/media/video-interfaces.txt

 .../bindings/display/panel/samsung,s6e3ha2.txt |  58 ++
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 +
 4 files changed, 806 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..6ce278a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,58 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Optional properties:
+  - display-timings: timings for the connected panel as described by [1]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <1487>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <15>;
+   vsync-len = <1>;
+   };
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..eea2902 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on  DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += 

[PATCH v3 2/2] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index db879f4..7434b22 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -252,11 +252,42 @@
reg = <1>;
 
dsi_out: endpoint {
+   remote-endpoint = <_in>;
samsung,burst-clock-frequency = <51200>;
samsung,esc-clock-frequency = <1600>;
};
};
};
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <1487>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <15>;
+   vsync-len = <1>;
+   };
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
 _0 {
-- 
1.9.1

[PATCH v3 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
---
Changes for V3:

- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

[1]: Documentation/devicetree/bindings/media/video-interfaces.txt

 .../bindings/display/panel/samsung,s6e3ha2.txt |  58 ++
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 +
 4 files changed, 806 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..6ce278a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,58 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Optional properties:
+  - display-timings: timings for the connected panel as described by [1]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <1487>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <15>;
+   vsync-len = <1>;
+   };
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..eea2902 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on  DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += 

[PATCH v3 0/2] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.

Changes for V3:

- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

[1]: Documentation/devicetree/bindings/media/video-interfaces.txt

Hoegeun Kwon (1):
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  58 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  31 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 +
 5 files changed, 837 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

[PATCH v3 0/2] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.

Changes for V3:

- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

[1]: Documentation/devicetree/bindings/media/video-interfaces.txt

Hoegeun Kwon (1):
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  58 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  31 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 +
 5 files changed, 837 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()

[Leon Romanovsky]

On Fri, Dec 30, 2016 at 12:50:11PM +0800, Kenneth Lee wrote:
> Hi, Leon,
>
> 1. I do change the title except for the version number itself:) But my English
> is quite bad, maybe the title is still quite stupid. I can update it according
> to your advice.

Yes, please
The main points are:
1. Remove "bugifix", it is not needed.
2. Use description in the title and not function names.

>
> 2. I catched the bug by reading the final code, not by bisect-ing the old
> commit. Do you means I should find out which commit introducing the bug? It 
> will
> not be easily to say which it is because it is a "missing bug", rather than a
> "introduced bug". Indicate the commit may not help to remove a patch/commit 
> from
> the stable tree.

The fixes line won't cause for removal of commit, but to addition of
yours on top of their code base.

git blame is your friend.

one fixes line is:
Fixes: 8ada2c1c0c1d ("IB/core: Add support for on demand paging regions")

and the second line is ! NOT !, you need to go deeper in the logs !!
Fixes: f7c6a7b5d599 ("IB/uverbs: Export ib_umem_get()/ib_umem_release() to 
modules")

>
> Could you please give more suggestion? Thanks.

Please, don't use top-posting for this mailing list.
It is really-really annoying.

>
> On Thu, Dec 29, 2016 at 10:17:56AM +0200, Leon Romanovsky wrote:
> > Date: Thu, 29 Dec 2016 10:17:56 +0200
> > From: Leon Romanovsky 
> > To: Kenneth Lee 
> > CC: dledf...@redhat.com, sean.he...@intel.com, hal.rosenst...@gmail.com,
> >  robin.mur...@arm.com, jroe...@suse.de, egtv...@samfundet.no,
> >  vgu...@synopsys.com, dave.han...@linux.intel.com, lstoa...@gmail.com,
> >  k...@kernel.org, seb...@linux.vnet.ibm.com, ma...@mellanox.com,
> >  linux-r...@vger.kernel.org, linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()
> > User-Agent: Mutt/1.7.2 (2016-11-26)
> > Message-ID: <20161229081756.GI26885@mtr-leonro.local>
> >
> > On Thu, Dec 29, 2016 at 04:27:28PM +0800, Kenneth Lee wrote:
> > > There are two bugfixes in this patch:
> > >
> > > 1. When the execution go to the ib_umem_odp_get() path, pid should be put
> > >back.
> > > 2. When the memory allocation fail, the pid also should be put back before
> > >exit.
> > >
> > > Signed-off-by: Kenneth Lee 
> > > Reviewed-by: Haggai Eran 
> > > ---
> > > Change from v1 to v2:
> > >   Correcting the patch title and description
> >
> > I don't see any changes except version in the title.
> > What about anything like this?
> > [PATCH v3] IB/umem: Release pid in error and ODP flows
> >
> > And Fixes line please, it will help to forward it to stable trees.
> >
> > Thanks
>
>
>
> --
>   -Kenneth(Hisilicon)


signature.asc
Description: PGP signature

Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()

[Leon Romanovsky]

On Fri, Dec 30, 2016 at 12:50:11PM +0800, Kenneth Lee wrote:
> Hi, Leon,
>
> 1. I do change the title except for the version number itself:) But my English
> is quite bad, maybe the title is still quite stupid. I can update it according
> to your advice.

Yes, please
The main points are:
1. Remove "bugifix", it is not needed.
2. Use description in the title and not function names.

>
> 2. I catched the bug by reading the final code, not by bisect-ing the old
> commit. Do you means I should find out which commit introducing the bug? It 
> will
> not be easily to say which it is because it is a "missing bug", rather than a
> "introduced bug". Indicate the commit may not help to remove a patch/commit 
> from
> the stable tree.

The fixes line won't cause for removal of commit, but to addition of
yours on top of their code base.

git blame is your friend.

one fixes line is:
Fixes: 8ada2c1c0c1d ("IB/core: Add support for on demand paging regions")

and the second line is ! NOT !, you need to go deeper in the logs !!
Fixes: f7c6a7b5d599 ("IB/uverbs: Export ib_umem_get()/ib_umem_release() to 
modules")

>
> Could you please give more suggestion? Thanks.

Please, don't use top-posting for this mailing list.
It is really-really annoying.

>
> On Thu, Dec 29, 2016 at 10:17:56AM +0200, Leon Romanovsky wrote:
> > Date: Thu, 29 Dec 2016 10:17:56 +0200
> > From: Leon Romanovsky 
> > To: Kenneth Lee 
> > CC: dledf...@redhat.com, sean.he...@intel.com, hal.rosenst...@gmail.com,
> >  robin.mur...@arm.com, jroe...@suse.de, egtv...@samfundet.no,
> >  vgu...@synopsys.com, dave.han...@linux.intel.com, lstoa...@gmail.com,
> >  k...@kernel.org, seb...@linux.vnet.ibm.com, ma...@mellanox.com,
> >  linux-r...@vger.kernel.org, linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()
> > User-Agent: Mutt/1.7.2 (2016-11-26)
> > Message-ID: <20161229081756.GI26885@mtr-leonro.local>
> >
> > On Thu, Dec 29, 2016 at 04:27:28PM +0800, Kenneth Lee wrote:
> > > There are two bugfixes in this patch:
> > >
> > > 1. When the execution go to the ib_umem_odp_get() path, pid should be put
> > >back.
> > > 2. When the memory allocation fail, the pid also should be put back before
> > >exit.
> > >
> > > Signed-off-by: Kenneth Lee 
> > > Reviewed-by: Haggai Eran 
> > > ---
> > > Change from v1 to v2:
> > >   Correcting the patch title and description
> >
> > I don't see any changes except version in the title.
> > What about anything like this?
> > [PATCH v3] IB/umem: Release pid in error and ODP flows
> >
> > And Fixes line please, it will help to forward it to stable trees.
> >
> > Thanks
>
>
>
> --
>   -Kenneth(Hisilicon)


signature.asc
Description: PGP signature

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

[Chanwoo Choi]

Hi Felipe,

On 2016년 12월 30일 11:46, Chanwoo Choi wrote:
> Hi Felipe,
> 
> On 2016년 12월 02일 18:03, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Chanwoo Choi  writes:
>>> Hi Felipe,
>>>
>>> On 2016년 11월 30일 19:36, Felipe Balbi wrote:

 Hi,

 Chanwoo Choi  writes:
> This patch uses the resource-managed extcon API for 
> extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi 

 Acked-by: Felipe Balbi 

>>>
>>> Thanks for your review.
>>>
>>> Each patch has no any dependency among patches.
>>> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
>>
>> my tree is closed for v4.10, I can pick it up for v4.11
> 
> Could you please pick up these patches(patch6/8/9/10/11/12)?
> These patches were already reviewed by you.
> 

I sent v2 patchset.
[1] https://www.spinics.net/lists/kernel/msg2410950.html
- "[PATCH v2 0/6] usb: Replace the deprecated extcon API"

-- 
Regards,
Chanwoo Choi

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

[Chanwoo Choi]

Hi Felipe,

On 2016년 12월 30일 11:46, Chanwoo Choi wrote:
> Hi Felipe,
> 
> On 2016년 12월 02일 18:03, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Chanwoo Choi  writes:
>>> Hi Felipe,
>>>
>>> On 2016년 11월 30일 19:36, Felipe Balbi wrote:

 Hi,

 Chanwoo Choi  writes:
> This patch uses the resource-managed extcon API for 
> extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi 

 Acked-by: Felipe Balbi 

>>>
>>> Thanks for your review.
>>>
>>> Each patch has no any dependency among patches.
>>> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
>>
>> my tree is closed for v4.10, I can pick it up for v4.11
> 
> Could you please pick up these patches(patch6/8/9/10/11/12)?
> These patches were already reviewed by you.
> 

I sent v2 patchset.
[1] https://www.spinics.net/lists/kernel/msg2410950.html
- "[PATCH v2 0/6] usb: Replace the deprecated extcon API"

-- 
Regards,
Chanwoo Choi

Re: [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

[Chanwoo Choi]

Hi Andi,

Looks good to me. I tested these patches for booting on TM2 board.
Reviewed-by: Chanwoo Choi 

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:14, Andi Shyti wrote:
> Change the PIN() macro definition so that it can use the macros
> from pinctrl/samsung.h header file.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  25 +-
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 
> ++---
>  2 files changed, 133 insertions(+), 146 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index 2af854b11644..d49879bd34bb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -14,25 +14,12 @@
>  
>  #include 
>  
> -#define PIN_PULL_NONE0
> -#define PIN_PULL_DOWN1
> -#define PIN_PULL_UP  3
> -
> -#define PIN_DRV_LV1  0
> -#define PIN_DRV_LV2  2
> -#define PIN_DRV_LV3  1
> -#define PIN_DRV_LV4  3
> -
> -#define PIN_IN   0
> -#define PIN_OUT  1
> -#define PIN_FUNC12
> -
> -#define PIN(_func, _pin, _pull, _drv)\
> - _pin {  \
> - samsung,pins = #_pin;   \
> - samsung,pin-function = ;  \
> - samsung,pin-pud = ;  \
> - samsung,pin-drv = ;\
> +#define PIN(_func, _pin, _pull, _drv)
> \
> + _pin {  \
> + samsung,pins = #_pin;   \
> + samsung,pin-function = ;  \
> + samsung,pin-pud = ;   \
> + samsung,pin-drv = ; \
>   }
>  
>  _alive {
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index f21bdc2ff834..66c4d5959881 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -742,77 +742,77 @@
>   pinctrl-0 = <_alive>;
>  
>   initial_alive: initial-state {
> - PIN(IN, gpa0-0, DOWN, LV1);
> - PIN(IN, gpa0-1, NONE, LV1);
> - PIN(IN, gpa0-2, DOWN, LV1);
> - PIN(IN, gpa0-3, NONE, LV1);
> - PIN(IN, gpa0-4, NONE, LV1);
> - PIN(IN, gpa0-5, DOWN, LV1);
> - PIN(IN, gpa0-6, NONE, LV1);
> - PIN(IN, gpa0-7, NONE, LV1);
> -
> - PIN(IN, gpa1-0, UP, LV1);
> - PIN(IN, gpa1-1, NONE, LV1);
> - PIN(IN, gpa1-2, NONE, LV1);
> - PIN(IN, gpa1-3, DOWN, LV1);
> - PIN(IN, gpa1-4, DOWN, LV1);
> - PIN(IN, gpa1-5, NONE, LV1);
> - PIN(IN, gpa1-6, NONE, LV1);
> - PIN(IN, gpa1-7, NONE, LV1);
> -
> - PIN(IN, gpa2-0, NONE, LV1);
> - PIN(IN, gpa2-1, NONE, LV1);
> - PIN(IN, gpa2-2, NONE, LV1);
> - PIN(IN, gpa2-3, DOWN, LV1);
> - PIN(IN, gpa2-4, NONE, LV1);
> - PIN(IN, gpa2-5, DOWN, LV1);
> - PIN(IN, gpa2-6, DOWN, LV1);
> - PIN(IN, gpa2-7, NONE, LV1);
> -
> - PIN(IN, gpa3-0, DOWN, LV1);
> - PIN(IN, gpa3-1, DOWN, LV1);
> - PIN(IN, gpa3-2, NONE, LV1);
> - PIN(IN, gpa3-3, DOWN, LV1);
> - PIN(IN, gpa3-4, NONE, LV1);
> - PIN(IN, gpa3-5, DOWN, LV1);
> - PIN(IN, gpa3-6, DOWN, LV1);
> - PIN(IN, gpa3-7, DOWN, LV1);
> -
> - PIN(IN, gpf1-0, NONE, LV1);
> - PIN(IN, gpf1-1, NONE, LV1);
> - PIN(IN, gpf1-2, DOWN, LV1);
> - PIN(IN, gpf1-4, UP, LV1);
> - PIN(OUT, gpf1-5, NONE, LV1);
> - PIN(IN, gpf1-6, DOWN, LV1);
> - PIN(IN, gpf1-7, DOWN, LV1);
> -
> - PIN(IN, gpf2-0, DOWN, LV1);
> - PIN(IN, gpf2-1, DOWN, LV1);
> - PIN(IN, gpf2-2, DOWN, LV1);
> - PIN(IN, gpf2-3, DOWN, LV1);
> -
> - PIN(IN, gpf3-0, DOWN, LV1);
> - PIN(IN, gpf3-1, DOWN, LV1);
> - PIN(IN, gpf3-2, NONE, LV1);
> - PIN(IN, gpf3-3, DOWN, LV1);
> -
> - PIN(IN, gpf4-0, DOWN, LV1);
> - PIN(IN, gpf4-1, DOWN, LV1);
> - PIN(IN, gpf4-2, DOWN, LV1);
> - PIN(IN, gpf4-3, DOWN, LV1);
> - PIN(IN, gpf4-4, DOWN, LV1);
> - PIN(IN, gpf4-5, DOWN, LV1);
> - PIN(IN, gpf4-6, DOWN, LV1);
> - PIN(IN, gpf4-7, DOWN, LV1);
> -
> - PIN(IN, gpf5-0, DOWN, LV1);
> - PIN(IN, gpf5-1, DOWN, LV1);
> - PIN(IN, gpf5-2, DOWN, LV1);
> - PIN(IN, gpf5-3, DOWN, LV1);
> - PIN(OUT, gpf5-4, 

Re: [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

[Chanwoo Choi]

Hi Andi,

Looks good to me. I tested these patches for booting on TM2 board.
Reviewed-by: Chanwoo Choi 

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:14, Andi Shyti wrote:
> Change the PIN() macro definition so that it can use the macros
> from pinctrl/samsung.h header file.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  25 +-
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 
> ++---
>  2 files changed, 133 insertions(+), 146 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index 2af854b11644..d49879bd34bb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -14,25 +14,12 @@
>  
>  #include 
>  
> -#define PIN_PULL_NONE0
> -#define PIN_PULL_DOWN1
> -#define PIN_PULL_UP  3
> -
> -#define PIN_DRV_LV1  0
> -#define PIN_DRV_LV2  2
> -#define PIN_DRV_LV3  1
> -#define PIN_DRV_LV4  3
> -
> -#define PIN_IN   0
> -#define PIN_OUT  1
> -#define PIN_FUNC12
> -
> -#define PIN(_func, _pin, _pull, _drv)\
> - _pin {  \
> - samsung,pins = #_pin;   \
> - samsung,pin-function = ;  \
> - samsung,pin-pud = ;  \
> - samsung,pin-drv = ;\
> +#define PIN(_func, _pin, _pull, _drv)
> \
> + _pin {  \
> + samsung,pins = #_pin;   \
> + samsung,pin-function = ;  \
> + samsung,pin-pud = ;   \
> + samsung,pin-drv = ; \
>   }
>  
>  _alive {
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index f21bdc2ff834..66c4d5959881 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -742,77 +742,77 @@
>   pinctrl-0 = <_alive>;
>  
>   initial_alive: initial-state {
> - PIN(IN, gpa0-0, DOWN, LV1);
> - PIN(IN, gpa0-1, NONE, LV1);
> - PIN(IN, gpa0-2, DOWN, LV1);
> - PIN(IN, gpa0-3, NONE, LV1);
> - PIN(IN, gpa0-4, NONE, LV1);
> - PIN(IN, gpa0-5, DOWN, LV1);
> - PIN(IN, gpa0-6, NONE, LV1);
> - PIN(IN, gpa0-7, NONE, LV1);
> -
> - PIN(IN, gpa1-0, UP, LV1);
> - PIN(IN, gpa1-1, NONE, LV1);
> - PIN(IN, gpa1-2, NONE, LV1);
> - PIN(IN, gpa1-3, DOWN, LV1);
> - PIN(IN, gpa1-4, DOWN, LV1);
> - PIN(IN, gpa1-5, NONE, LV1);
> - PIN(IN, gpa1-6, NONE, LV1);
> - PIN(IN, gpa1-7, NONE, LV1);
> -
> - PIN(IN, gpa2-0, NONE, LV1);
> - PIN(IN, gpa2-1, NONE, LV1);
> - PIN(IN, gpa2-2, NONE, LV1);
> - PIN(IN, gpa2-3, DOWN, LV1);
> - PIN(IN, gpa2-4, NONE, LV1);
> - PIN(IN, gpa2-5, DOWN, LV1);
> - PIN(IN, gpa2-6, DOWN, LV1);
> - PIN(IN, gpa2-7, NONE, LV1);
> -
> - PIN(IN, gpa3-0, DOWN, LV1);
> - PIN(IN, gpa3-1, DOWN, LV1);
> - PIN(IN, gpa3-2, NONE, LV1);
> - PIN(IN, gpa3-3, DOWN, LV1);
> - PIN(IN, gpa3-4, NONE, LV1);
> - PIN(IN, gpa3-5, DOWN, LV1);
> - PIN(IN, gpa3-6, DOWN, LV1);
> - PIN(IN, gpa3-7, DOWN, LV1);
> -
> - PIN(IN, gpf1-0, NONE, LV1);
> - PIN(IN, gpf1-1, NONE, LV1);
> - PIN(IN, gpf1-2, DOWN, LV1);
> - PIN(IN, gpf1-4, UP, LV1);
> - PIN(OUT, gpf1-5, NONE, LV1);
> - PIN(IN, gpf1-6, DOWN, LV1);
> - PIN(IN, gpf1-7, DOWN, LV1);
> -
> - PIN(IN, gpf2-0, DOWN, LV1);
> - PIN(IN, gpf2-1, DOWN, LV1);
> - PIN(IN, gpf2-2, DOWN, LV1);
> - PIN(IN, gpf2-3, DOWN, LV1);
> -
> - PIN(IN, gpf3-0, DOWN, LV1);
> - PIN(IN, gpf3-1, DOWN, LV1);
> - PIN(IN, gpf3-2, NONE, LV1);
> - PIN(IN, gpf3-3, DOWN, LV1);
> -
> - PIN(IN, gpf4-0, DOWN, LV1);
> - PIN(IN, gpf4-1, DOWN, LV1);
> - PIN(IN, gpf4-2, DOWN, LV1);
> - PIN(IN, gpf4-3, DOWN, LV1);
> - PIN(IN, gpf4-4, DOWN, LV1);
> - PIN(IN, gpf4-5, DOWN, LV1);
> - PIN(IN, gpf4-6, DOWN, LV1);
> - PIN(IN, gpf4-7, DOWN, LV1);
> -
> - PIN(IN, gpf5-0, DOWN, LV1);
> - PIN(IN, gpf5-1, DOWN, LV1);
> - PIN(IN, gpf5-2, DOWN, LV1);
> - PIN(IN, gpf5-3, DOWN, LV1);
> - PIN(OUT, gpf5-4, NONE, LV1);
> - PIN(IN, gpf5-5, 

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Chanwoo Choi]

Hi Andi,

Looks good to me.
Reviewed-by: Chanwoo Choi 

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:14, Andi Shyti wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 
> +++--
>  1 file changed, 175 insertions(+), 173 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index ad71247b074f..2af854b11644 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -12,6 +12,8 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include 
> +
>  #define PIN_PULL_NONE0
>  #define PIN_PULL_DOWN1
>  #define PIN_PULL_UP  3
> @@ -145,23 +147,23 @@
>   i2s0_bus: i2s0-bus {
>   samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
>   "gpz0-4", "gpz0-5", "gpz0-6";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   pcm0_bus: pcm0-bus {
>   samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
> - samsung,pin-function = <3>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   uart_aud_bus: uart-aud-bus {
>   samsung,pins = "gpz1-3", "gpz1-2", "gpz1-1", "gpz1-0";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  };
>  
> @@ -196,16 +198,16 @@
>  
>   spi2_bus: spi2-bus {
>   samsung,pins = "gpd5-0", "gpd5-2", "gpd5-3";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   hs_i2c6_bus: hs-i2c6-bus {
>   samsung,pins = "gpd5-3", "gpd5-2";
> - samsung,pin-function = <4>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  };
>  
> @@ -260,141 +262,141 @@
>  
>   sd0_clk: sd0-clk {
>   samsung,pins = "gpr0-0";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_cmd: sd0-cmd {
>   samsung,pins = "gpr0-1";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_rdqs: sd0-rdqs {
>   samsung,pins = "gpr0-2";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_qrdy: sd0-qrdy {
>   samsung,pins = "gpr0-3";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_bus1: sd0-bus-width1 {
>   samsung,pins = "gpr1-0";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_bus4: sd0-bus-width4 {
>   samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_bus8: sd0-bus-width8 {
>   samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - 

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Chanwoo Choi]

Hi Andi,

Looks good to me.
Reviewed-by: Chanwoo Choi 

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:14, Andi Shyti wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 
> +++--
>  1 file changed, 175 insertions(+), 173 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index ad71247b074f..2af854b11644 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -12,6 +12,8 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include 
> +
>  #define PIN_PULL_NONE0
>  #define PIN_PULL_DOWN1
>  #define PIN_PULL_UP  3
> @@ -145,23 +147,23 @@
>   i2s0_bus: i2s0-bus {
>   samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
>   "gpz0-4", "gpz0-5", "gpz0-6";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   pcm0_bus: pcm0-bus {
>   samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
> - samsung,pin-function = <3>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   uart_aud_bus: uart-aud-bus {
>   samsung,pins = "gpz1-3", "gpz1-2", "gpz1-1", "gpz1-0";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  };
>  
> @@ -196,16 +198,16 @@
>  
>   spi2_bus: spi2-bus {
>   samsung,pins = "gpd5-0", "gpd5-2", "gpd5-3";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   hs_i2c6_bus: hs-i2c6-bus {
>   samsung,pins = "gpd5-3", "gpd5-2";
> - samsung,pin-function = <4>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <0>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  };
>  
> @@ -260,141 +262,141 @@
>  
>   sd0_clk: sd0-clk {
>   samsung,pins = "gpr0-0";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_cmd: sd0-cmd {
>   samsung,pins = "gpr0-1";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_rdqs: sd0-rdqs {
>   samsung,pins = "gpr0-2";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_qrdy: sd0-qrdy {
>   samsung,pins = "gpr0-3";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <1>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_bus1: sd0-bus-width1 {
>   samsung,pins = "gpr1-0";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_bus4: sd0-bus-width4 {
>   samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
>   };
>  
>   sd0_bus8: sd0-bus-width8 {
>   samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7";
> - samsung,pin-function = <2>;
> - samsung,pin-pud = <3>;
> - samsung,pin-drv = <3>;
> + samsung,pin-function 

Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

[Chanwoo Choi]

Hi Andi,

On 2016년 12월 30일 13:14, Andi Shyti wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
> 
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
> 
> Signed-off-by: Andi Shyti 
> ---
>  include/dt-bindings/pinctrl/samsung.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/dt-bindings/pinctrl/samsung.h 
> b/include/dt-bindings/pinctrl/samsung.h
> index 6276eb785e2b..e0ebb20ffdd3 100644
> --- a/include/dt-bindings/pinctrl/samsung.h
> +++ b/include/dt-bindings/pinctrl/samsung.h
> @@ -45,6 +45,20 @@
>  #define EXYNOS5420_PIN_DRV_LV3   2
>  #define EXYNOS5420_PIN_DRV_LV4   3
>  
> +/* Drive strengths for Exynos5433 */
> +#define EXYNOS5433_PIN_DRV_FAST_SR1  0
> +#define EXYNOS5433_PIN_DRV_FAST_SR2  1
> +#define EXYNOS5433_PIN_DRV_FAST_SR3  2
> +#define EXYNOS5433_PIN_DRV_FAST_SR4  3
> +#define EXYNOS5433_PIN_DRV_FAST_SR5  4
> +#define EXYNOS5433_PIN_DRV_FAST_SR6  5
> +#define EXYNOS5433_PIN_DRV_SLOW_SR1  8
> +#define EXYNOS5433_PIN_DRV_SLOW_SR2  9
> +#define EXYNOS5433_PIN_DRV_SLOW_SR3  0xa
> +#define EXYNOS5433_PIN_DRV_SLOW_SR4  0xb
> +#define EXYNOS5433_PIN_DRV_SLOW_SR5  0xc
> +#define EXYNOS5433_PIN_DRV_SLOW_SR6  0xf
> +
>  #define EXYNOS_PIN_FUNC_INPUT0
>  #define EXYNOS_PIN_FUNC_OUTPUT   1
>  #define EXYNOS_PIN_FUNC_22
> 

Looks good to me. ('SR' means "Slew Rate".)
Reviewed-by: Chanwoo Choi 

-- 
Regards,
Chanwoo Choi

Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

[Chanwoo Choi]

Hi Andi,

On 2016년 12월 30일 13:14, Andi Shyti wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
> 
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
> 
> Signed-off-by: Andi Shyti 
> ---
>  include/dt-bindings/pinctrl/samsung.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/dt-bindings/pinctrl/samsung.h 
> b/include/dt-bindings/pinctrl/samsung.h
> index 6276eb785e2b..e0ebb20ffdd3 100644
> --- a/include/dt-bindings/pinctrl/samsung.h
> +++ b/include/dt-bindings/pinctrl/samsung.h
> @@ -45,6 +45,20 @@
>  #define EXYNOS5420_PIN_DRV_LV3   2
>  #define EXYNOS5420_PIN_DRV_LV4   3
>  
> +/* Drive strengths for Exynos5433 */
> +#define EXYNOS5433_PIN_DRV_FAST_SR1  0
> +#define EXYNOS5433_PIN_DRV_FAST_SR2  1
> +#define EXYNOS5433_PIN_DRV_FAST_SR3  2
> +#define EXYNOS5433_PIN_DRV_FAST_SR4  3
> +#define EXYNOS5433_PIN_DRV_FAST_SR5  4
> +#define EXYNOS5433_PIN_DRV_FAST_SR6  5
> +#define EXYNOS5433_PIN_DRV_SLOW_SR1  8
> +#define EXYNOS5433_PIN_DRV_SLOW_SR2  9
> +#define EXYNOS5433_PIN_DRV_SLOW_SR3  0xa
> +#define EXYNOS5433_PIN_DRV_SLOW_SR4  0xb
> +#define EXYNOS5433_PIN_DRV_SLOW_SR5  0xc
> +#define EXYNOS5433_PIN_DRV_SLOW_SR6  0xf
> +
>  #define EXYNOS_PIN_FUNC_INPUT0
>  #define EXYNOS_PIN_FUNC_OUTPUT   1
>  #define EXYNOS_PIN_FUNC_22
> 

Looks good to me. ('SR' means "Slew Rate".)
Reviewed-by: Chanwoo Choi 

-- 
Regards,
Chanwoo Choi

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

[Jaewon Kim]

On 2016년 12월 29일 18:43, Michal Hocko wrote:
> On Thu 29-12-16 18:26:38, Jaewon Kim wrote:
>>
>> On 2016년 12월 29일 18:14, Michal Hocko wrote:
>>> On Thu 29-12-16 11:28:02, Jaewon Kim wrote:
 There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, 
 EINTR.
 This patch prints the error value and bitmap status to know available pages
 regarding fragmentation.

 This is an ENOMEM example with this patch.
 [   11.616321]  [2:   Binder:711_1:  740] cma: cma_alloc: alloc failed, 
 req-size: 256 pages, ret: -12
 [   11.616365]  [2:   Binder:711_1:  740] number of available pages: 
 4+7+7+8+38+166+127=>357 pages, total: 2048 pages
>>> Could you be more specific why this part is useful?
>> Hi
>> Without this patch we do not know why CMA allocation failed.
> Yes, I understand the first part
>
>> Additionally in case of ENOMEM, with bitmap status we can figure out that
> The code doesn't seem to check for ENOMEM though
Yes actually I wanted to look both ENOMEM case and EBUSY case.
Even in EBUSY case, we can look how much available pages existed, but all 
failed on those region because of EBUSY.
We may not need EINTR case, but I hope to look.
>
>> if it is too small CMA region issue or if it is fragmentation issue.
> then please describe that in the changelog. If I got it right the above
> would tell us that the fragmentation is the problem, right?
Yes fragmentation can be A problem, but bitmap status will explain EBUSY case 
too as I explained above.
>
>>>  
 Signed-off-by: Jaewon Kim 
 ---
  mm/cma.c | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

 diff --git a/mm/cma.c b/mm/cma.c
 index c960459..535aa39 100644
 --- a/mm/cma.c
 +++ b/mm/cma.c
 @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
 unsigned int align)
unsigned long start = 0;
unsigned long bitmap_maxno, bitmap_no, bitmap_count;
struct page *page = NULL;
 -  int ret;
 +  int ret = -ENOMEM;
  
if (!cma || !cma->count)
return NULL;
 @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
 unsigned int align)
trace_cma_alloc(pfn, page, count, align);
  
pr_debug("%s(): returned %p\n", __func__, page);
 +
 +  if (ret != 0) {
 +  unsigned int nr, nr_total = 0;
 +  unsigned long next_set_bit;
 +
 +  pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
 +  __func__, count, ret);
 +  mutex_lock(>lock);
 +  printk("number of available pages: ");
> I guess you want pr_info (or maybe pr_debug) here
Thank you I will change as you and Michal Nazarewichz commented.
>
 +  start = 0;
 +  for (;;) {
 +  bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, 
 start);
 +  next_set_bit = find_next_bit(cma->bitmap, cma->count, 
 bitmap_no);
 +  nr = next_set_bit - bitmap_no;
 +  if (bitmap_no >= cma->count)
 +  break;
 +  if (nr_total == 0)
 +  printk("%u", nr);
 +  else
 +  printk("+%u", nr);
> pr_cont
>
 +  nr_total += nr;
 +  start = bitmap_no + nr;
 +  }
 +  printk("=>%u pages, total: %lu pages\n", nr_total, cma->count);
> pr_cont
>
 +  mutex_unlock(>lock);
 +  }
 +
return page;
  }
  
 -- 
 1.9.1

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

[Jaewon Kim]

On 2016년 12월 29일 18:43, Michal Hocko wrote:
> On Thu 29-12-16 18:26:38, Jaewon Kim wrote:
>>
>> On 2016년 12월 29일 18:14, Michal Hocko wrote:
>>> On Thu 29-12-16 11:28:02, Jaewon Kim wrote:
 There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, 
 EINTR.
 This patch prints the error value and bitmap status to know available pages
 regarding fragmentation.

 This is an ENOMEM example with this patch.
 [   11.616321]  [2:   Binder:711_1:  740] cma: cma_alloc: alloc failed, 
 req-size: 256 pages, ret: -12
 [   11.616365]  [2:   Binder:711_1:  740] number of available pages: 
 4+7+7+8+38+166+127=>357 pages, total: 2048 pages
>>> Could you be more specific why this part is useful?
>> Hi
>> Without this patch we do not know why CMA allocation failed.
> Yes, I understand the first part
>
>> Additionally in case of ENOMEM, with bitmap status we can figure out that
> The code doesn't seem to check for ENOMEM though
Yes actually I wanted to look both ENOMEM case and EBUSY case.
Even in EBUSY case, we can look how much available pages existed, but all 
failed on those region because of EBUSY.
We may not need EINTR case, but I hope to look.
>
>> if it is too small CMA region issue or if it is fragmentation issue.
> then please describe that in the changelog. If I got it right the above
> would tell us that the fragmentation is the problem, right?
Yes fragmentation can be A problem, but bitmap status will explain EBUSY case 
too as I explained above.
>
>>>  
 Signed-off-by: Jaewon Kim 
 ---
  mm/cma.c | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

 diff --git a/mm/cma.c b/mm/cma.c
 index c960459..535aa39 100644
 --- a/mm/cma.c
 +++ b/mm/cma.c
 @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
 unsigned int align)
unsigned long start = 0;
unsigned long bitmap_maxno, bitmap_no, bitmap_count;
struct page *page = NULL;
 -  int ret;
 +  int ret = -ENOMEM;
  
if (!cma || !cma->count)
return NULL;
 @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
 unsigned int align)
trace_cma_alloc(pfn, page, count, align);
  
pr_debug("%s(): returned %p\n", __func__, page);
 +
 +  if (ret != 0) {
 +  unsigned int nr, nr_total = 0;
 +  unsigned long next_set_bit;
 +
 +  pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
 +  __func__, count, ret);
 +  mutex_lock(>lock);
 +  printk("number of available pages: ");
> I guess you want pr_info (or maybe pr_debug) here
Thank you I will change as you and Michal Nazarewichz commented.
>
 +  start = 0;
 +  for (;;) {
 +  bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, 
 start);
 +  next_set_bit = find_next_bit(cma->bitmap, cma->count, 
 bitmap_no);
 +  nr = next_set_bit - bitmap_no;
 +  if (bitmap_no >= cma->count)
 +  break;
 +  if (nr_total == 0)
 +  printk("%u", nr);
 +  else
 +  printk("+%u", nr);
> pr_cont
>
 +  nr_total += nr;
 +  start = bitmap_no + nr;
 +  }
 +  printk("=>%u pages, total: %lu pages\n", nr_total, cma->count);
> pr_cont
>
 +  mutex_unlock(>lock);
 +  }
 +
return page;
  }
  
 -- 
 1.9.1

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

[PATCH v2] drm/mediatek: Support UYVY and YUYV format for overlay

[Bibby Hsieh]

MT8173 overlay can support UYVY and YUYV format,
we add the format in DRM driver.

Signed-off-by: Bibby Hsieh 
Reviewed-by: Daniel Kurtz 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 21 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c |  2 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index c703102..de05845 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -40,10 +40,13 @@
 #defineOVL_RDMA_MEM_GMC0x40402020
 
 #define OVL_CON_BYTE_SWAP  BIT(24)
+#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
 #define OVL_CON_CLRFMT_RGB565  (0 << 12)
 #define OVL_CON_CLRFMT_RGB888  (1 << 12)
 #define OVL_CON_CLRFMT_RGBA(2 << 12)
 #define OVL_CON_CLRFMT_ARGB(3 << 12)
+#define OVL_CON_CLRFMT_UYVY(4 << 12)
+#define OVL_CON_CLRFMT_YUYV(5 << 12)
 #defineOVL_CON_AEN BIT(8)
 #defineOVL_CON_ALPHA   0xff
 
@@ -162,6 +165,21 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
+   case DRM_FORMAT_UYVY:
+   return OVL_CON_CLRFMT_UYVY;
+   case DRM_FORMAT_YUYV:
+   return OVL_CON_CLRFMT_YUYV;
+   }
+}
+
+static bool ovl_yuv_space(unsigned int fmt)
+{
+   switch (fmt) {
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_YUYV:
+   return true;
+   default:
+   return false;
}
 }
 
@@ -183,6 +201,9 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
 
+   if (ovl_yuv_space(fmt))
+   con |= OVL_CON_MTX_YUV_TO_RGB;
+
writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index c461a23..8c02d1d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -28,6 +28,8 @@
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_RGB565,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_YUYV,
 };
 
 static void mtk_plane_reset(struct drm_plane *plane)
-- 
1.9.1

[PATCH v2] drm/mediatek: Support UYVY and YUYV format for overlay

[Bibby Hsieh]

MT8173 overlay can support UYVY and YUYV format,
we add the format in DRM driver.

Signed-off-by: Bibby Hsieh 
Reviewed-by: Daniel Kurtz 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 21 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c |  2 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index c703102..de05845 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -40,10 +40,13 @@
 #defineOVL_RDMA_MEM_GMC0x40402020
 
 #define OVL_CON_BYTE_SWAP  BIT(24)
+#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
 #define OVL_CON_CLRFMT_RGB565  (0 << 12)
 #define OVL_CON_CLRFMT_RGB888  (1 << 12)
 #define OVL_CON_CLRFMT_RGBA(2 << 12)
 #define OVL_CON_CLRFMT_ARGB(3 << 12)
+#define OVL_CON_CLRFMT_UYVY(4 << 12)
+#define OVL_CON_CLRFMT_YUYV(5 << 12)
 #defineOVL_CON_AEN BIT(8)
 #defineOVL_CON_ALPHA   0xff
 
@@ -162,6 +165,21 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
+   case DRM_FORMAT_UYVY:
+   return OVL_CON_CLRFMT_UYVY;
+   case DRM_FORMAT_YUYV:
+   return OVL_CON_CLRFMT_YUYV;
+   }
+}
+
+static bool ovl_yuv_space(unsigned int fmt)
+{
+   switch (fmt) {
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_YUYV:
+   return true;
+   default:
+   return false;
}
 }
 
@@ -183,6 +201,9 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
 
+   if (ovl_yuv_space(fmt))
+   con |= OVL_CON_MTX_YUV_TO_RGB;
+
writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index c461a23..8c02d1d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -28,6 +28,8 @@
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_RGB565,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_YUYV,
 };
 
 static void mtk_plane_reset(struct drm_plane *plane)
-- 
1.9.1

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 06:49 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>>
>>> Hi,
>>>
>>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
> wrote:
>> As discussed during our LPC discussions, I'm posting the rename 
>> patch
>> here. I'll post the rest of EP series before the next merge 
>> window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW 
> after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the 
 PCI Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

 right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit 
>>> long
>>> and while I suppose it technically does include the concept of the 
>>> PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first 
>>> place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 
>> Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

 right, each IP have a separate directory in USB. I thought of doing 
 something
 similar for PCI but decided against it since that would involve 
 identifying all
 the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device 
>> functions
>> are extended from the gadget/ package in which you can use 
>> mass_storage and
>> other types of functions.

 That would be similar for PCI endpoint. All endpoint specific core
 functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci 
>> and the host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>> vendor drivers
>
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the 
> specific vendor
> drivers
>
>>  drivers/pci/ -> here would be the drivers for vendorN 
>> controller
>
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN 
> controller
>
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>> endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific 
>> endpoint ops

 There are some parts of the dwc driver that is common to both root 
 complex and
 endpoint. Where should that be? I'm sure no one wants to duplicate the 
 common
 piece in both root complex and endpoint.
>>>
>>> You are right, the config space is almost the same and some ops also 
>>> common.
>>> I would suggest:
>>>
>>> drivers/pci
>>>   drivers/pci/core/
>>>   

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 06:49 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>>
>>> Hi,
>>>
>>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
> wrote:
>> As discussed during our LPC discussions, I'm posting the rename 
>> patch
>> here. I'll post the rest of EP series before the next merge 
>> window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW 
> after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the 
 PCI Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

 right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit 
>>> long
>>> and while I suppose it technically does include the concept of the 
>>> PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first 
>>> place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 
>> Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

 right, each IP have a separate directory in USB. I thought of doing 
 something
 similar for PCI but decided against it since that would involve 
 identifying all
 the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device 
>> functions
>> are extended from the gadget/ package in which you can use 
>> mass_storage and
>> other types of functions.

 That would be similar for PCI endpoint. All endpoint specific core
 functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci 
>> and the host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>> vendor drivers
>
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the 
> specific vendor
> drivers
>
>>  drivers/pci/ -> here would be the drivers for vendorN 
>> controller
>
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN 
> controller
>
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>> endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific 
>> endpoint ops

 There are some parts of the dwc driver that is common to both root 
 complex and
 endpoint. Where should that be? I'm sure no one wants to duplicate the 
 common
 piece in both root complex and endpoint.
>>>
>>> You are right, the config space is almost the same and some ops also 
>>> common.
>>> I would suggest:
>>>
>>> drivers/pci
>>>   drivers/pci/core/
>>>   

Re: [PATCH 1/1] usb: xhci: clear EINT bit in status correctly

[kbuild test robot]

Hi Lu,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.10-rc1 next-20161224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-xhci-clear-EINT-bit-in-status-correctly/20161230-133444
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   In file included from include/linux/swab.h:4:0,
from include/uapi/linux/byteorder/big_endian.h:12,
from include/linux/byteorder/big_endian.h:4,
from arch/m68k/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
from arch/m68k/include/asm/bitops.h:518,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/pci.h:25,
from drivers/usb/host/xhci.c:23:
   drivers/usb/host/xhci.c: In function 'xhci_stop':
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:116:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'out_le32'
#define writel(val,addr) out_le32((addr),(val))
 ^
   drivers/usb/host/xhci.c:724:2: note: in expansion of macro 'writel'
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:17:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0x00ffUL) << 24) |  \
   ^
   include/uapi/linux/byteorder/big_endian.h:32:43: note: in expansion of macro 
'__swab32'
#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'out_le32'
#define writel(val,addr) out_le32((addr),(val))
 ^
   drivers/usb/host/xhci.c:724:2: note: in expansion of macro 'writel'
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:18:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0xff00UL) <<  8) |  \
   ^
   include/uapi/linux/byteorder/big_endian.h:32:43: note: in expansion of macro 
'__swab32'
#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'out_le32'
#define writel(val,addr) out_le32((addr),(val))
 ^
   drivers/usb/host/xhci.c:724:2: note: in expansion of macro 'writel'
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:19:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0x00ffUL) >>  8) |  \
   ^
   include/uapi/linux/byteorder/big_endian.h:32:43: note: in expansion of macro 
'__swab32'
#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> 

Re: [PATCH 1/1] usb: xhci: clear EINT bit in status correctly

[kbuild test robot]

Hi Lu,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.10-rc1 next-20161224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-xhci-clear-EINT-bit-in-status-correctly/20161230-133444
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   In file included from include/linux/swab.h:4:0,
from include/uapi/linux/byteorder/big_endian.h:12,
from include/linux/byteorder/big_endian.h:4,
from arch/m68k/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
from arch/m68k/include/asm/bitops.h:518,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/pci.h:25,
from drivers/usb/host/xhci.c:23:
   drivers/usb/host/xhci.c: In function 'xhci_stop':
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:116:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'out_le32'
#define writel(val,addr) out_le32((addr),(val))
 ^
   drivers/usb/host/xhci.c:724:2: note: in expansion of macro 'writel'
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:17:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0x00ffUL) << 24) |  \
   ^
   include/uapi/linux/byteorder/big_endian.h:32:43: note: in expansion of macro 
'__swab32'
#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'out_le32'
#define writel(val,addr) out_le32((addr),(val))
 ^
   drivers/usb/host/xhci.c:724:2: note: in expansion of macro 'writel'
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:18:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0xff00UL) <<  8) |  \
   ^
   include/uapi/linux/byteorder/big_endian.h:32:43: note: in expansion of macro 
'__swab32'
#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'out_le32'
#define writel(val,addr) out_le32((addr),(val))
 ^
   drivers/usb/host/xhci.c:724:2: note: in expansion of macro 'writel'
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ^
   include/uapi/linux/swab.h:19:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0x00ffUL) >>  8) |  \
   ^
   include/uapi/linux/byteorder/big_endian.h:32:43: note: in expansion of macro 
'__swab32'
#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
  ^
   include/linux/byteorder/generic.h:87:21: note: in expansion of macro 
'__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^
>> 

Re: [PATCH 1/1] usb: xhci: clear EINT bit in status correctly

[kbuild test robot]

Hi Lu,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.10-rc1 next-20161224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-xhci-clear-EINT-bit-in-status-correctly/20161230-133444
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-randconfig-x003-201652 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/usb/host/xhci.c: In function 'xhci_stop':
>> drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
>> arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
~^
   drivers/usb/host/xhci.c: In function 'xhci_resume':
   drivers/usb/host/xhci.c:1057:15: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
  writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ~^

vim +724 drivers/usb/host/xhci.c

   708  
   709  /* Deleting Compliance Mode Recovery Timer */
   710  if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
   711  (!(xhci_all_ports_seen_u0(xhci {
   712  del_timer_sync(>comp_mode_recovery_timer);
   713  xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
   714  "%s: compliance mode recovery timer 
deleted",
   715  __func__);
   716  }
   717  
   718  if (xhci->quirks & XHCI_AMD_PLL_FIX)
   719  usb_amd_dev_put();
   720  
   721  xhci_dbg_trace(xhci, trace_xhci_dbg_init,
   722  "// Disabling event ring interrupts");
   723  temp = readl(>op_regs->status);
 > 724  writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
   725  temp = readl(>ir_set->irq_pending);
   726  writel(ER_IRQ_DISABLE(temp), >ir_set->irq_pending);
   727  xhci_print_ir_set(xhci, 0);
   728  
   729  xhci_dbg_trace(xhci, trace_xhci_dbg_init, "cleaning up memory");
   730  xhci_mem_cleanup(xhci);
   731  xhci_dbg_trace(xhci, trace_xhci_dbg_init,
   732  "xhci_stop completed - status = %x",

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/1] usb: xhci: clear EINT bit in status correctly

[kbuild test robot]

Hi Lu,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.10-rc1 next-20161224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-xhci-clear-EINT-bit-in-status-correctly/20161230-133444
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-randconfig-x003-201652 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/usb/host/xhci.c: In function 'xhci_stop':
>> drivers/usb/host/xhci.c:724:14: warning: suggest parentheses around 
>> arithmetic in operand of '|' [-Wparentheses]
 writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
~^
   drivers/usb/host/xhci.c: In function 'xhci_resume':
   drivers/usb/host/xhci.c:1057:15: warning: suggest parentheses around 
arithmetic in operand of '|' [-Wparentheses]
  writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
 ~^

vim +724 drivers/usb/host/xhci.c

   708  
   709  /* Deleting Compliance Mode Recovery Timer */
   710  if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
   711  (!(xhci_all_ports_seen_u0(xhci {
   712  del_timer_sync(>comp_mode_recovery_timer);
   713  xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
   714  "%s: compliance mode recovery timer 
deleted",
   715  __func__);
   716  }
   717  
   718  if (xhci->quirks & XHCI_AMD_PLL_FIX)
   719  usb_amd_dev_put();
   720  
   721  xhci_dbg_trace(xhci, trace_xhci_dbg_init,
   722  "// Disabling event ring interrupts");
   723  temp = readl(>op_regs->status);
 > 724  writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
   725  temp = readl(>ir_set->irq_pending);
   726  writel(ER_IRQ_DISABLE(temp), >ir_set->irq_pending);
   727  xhci_print_ir_set(xhci, 0);
   728  
   729  xhci_dbg_trace(xhci, trace_xhci_dbg_init, "cleaning up memory");
   730  xhci_mem_cleanup(xhci);
   731  xhci_dbg_trace(xhci, trace_xhci_dbg_init,
   732  "xhci_stop completed - status = %x",

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH 1/1] usb: xhci: clear EINT bit in status correctly

[Lu Baolu]

EINT(Event Interrupt) is a write-1-to-clear type of bit in xhci
status register. It should be cleared by writing a 1. Writing 0
to this bit has no effect.

Xhci driver tries to clear this bit by writing 0 to it. This is
not the right way to go. This patch corrects this by reading the
register first, then clearing all RO/RW1C/RsvZ bits and setting
the clearing bit, and writing back the new value at last.

Xhci spec requires that software that uses EINT shall clear it
prior to clearing any IP flags in section 5.4.2. This is the
reason why this patch is CC'ed stable as well.

Cc:  # v3.14+
CC: Felipe Balbi 
Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1cd5641..18ea6b8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -721,7 +721,7 @@ void xhci_stop(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"// Disabling event ring interrupts");
temp = readl(>op_regs->status);
-   writel(temp & ~STS_EINT, >op_regs->status);
+   writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
temp = readl(>ir_set->irq_pending);
writel(ER_IRQ_DISABLE(temp), >ir_set->irq_pending);
xhci_print_ir_set(xhci, 0);
@@ -1054,7 +1054,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
xhci_dbg(xhci, "// Disabling event ring interrupts\n");
temp = readl(>op_regs->status);
-   writel(temp & ~STS_EINT, >op_regs->status);
+   writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
temp = readl(>ir_set->irq_pending);
writel(ER_IRQ_DISABLE(temp), >ir_set->irq_pending);
xhci_print_ir_set(xhci, 0);
-- 
2.1.4

[PATCH 1/1] usb: xhci: clear EINT bit in status correctly

[Lu Baolu]

EINT(Event Interrupt) is a write-1-to-clear type of bit in xhci
status register. It should be cleared by writing a 1. Writing 0
to this bit has no effect.

Xhci driver tries to clear this bit by writing 0 to it. This is
not the right way to go. This patch corrects this by reading the
register first, then clearing all RO/RW1C/RsvZ bits and setting
the clearing bit, and writing back the new value at last.

Xhci spec requires that software that uses EINT shall clear it
prior to clearing any IP flags in section 5.4.2. This is the
reason why this patch is CC'ed stable as well.

Cc:  # v3.14+
CC: Felipe Balbi 
Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1cd5641..18ea6b8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -721,7 +721,7 @@ void xhci_stop(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"// Disabling event ring interrupts");
temp = readl(>op_regs->status);
-   writel(temp & ~STS_EINT, >op_regs->status);
+   writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
temp = readl(>ir_set->irq_pending);
writel(ER_IRQ_DISABLE(temp), >ir_set->irq_pending);
xhci_print_ir_set(xhci, 0);
@@ -1054,7 +1054,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
xhci_dbg(xhci, "// Disabling event ring interrupts\n");
temp = readl(>op_regs->status);
-   writel(temp & ~STS_EINT, >op_regs->status);
+   writel(temp & ~0x1fff | STS_EINT, >op_regs->status);
temp = readl(>ir_set->irq_pending);
writel(ER_IRQ_DISABLE(temp), >ir_set->irq_pending);
xhci_print_ir_set(xhci, 0);
-- 
2.1.4

Re: [v2 5/7] x86: Add emulation code for UMIP instructions

[Ricardo Neri]

On Tue, 2016-12-27 at 16:48 -0800, Andy Lutomirski wrote:
> On Tue, Dec 27, 2016 at 4:39 PM, Ricardo Neri
>  wrote:
> > On Fri, 2016-12-23 at 18:11 -0800, Andy Lutomirski wrote:
> >> On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
> >>  wrote:
> >> > The feature User-Mode Instruction Prevention present in recent Intel
> >> > processor prevents a group of instructions from being executed with
> >> > CPL > 0. Otherwise, a general protection fault is issued.
> >> >
> >> > Rather than relaying this fault to the user space (in the form of a 
> >> > SIGSEGV
> >> > signal), the instructions protected by UMIP can be emulated to provide
> >> > dummy results. This allows to conserve the current kernel behavior and 
> >> > not
> >> > reveal the system resources that UMIP intends to protect (the global
> >> > descriptor and interrupt descriptor tables, the segment selectors of the
> >> > local descriptor table and the task state and the machine status word).
> >> >
> >> > This emulation is needed because certain applications (e.g., WineHQ) rely
> >> > on this subset of instructions to function.
> >> >
> >> > The instructions protected by UMIP can be split in two groups. Those who
> >> > return a kernel memory address (sgdt and sidt) and those who return a
> >> > value (sldt, str and smsw).
> >> >
> >> > For the instructions that return a kernel memory address, the result is
> >> > emulated as the location of a dummy variable in the kernel memory space.
> >> > This is needed as applications such as WineHQ rely on the result being
> >> > located in the kernel memory space function. The limit for the GDT and 
> >> > the
> >> > IDT are set to zero.
> >>
> >> Nak.  This is a trivial KASLR bypass.  Just give them hardcoded
> >> values.  For x86_64, I would suggest 0xfffe and
> >> 0x.
> >
> > I see. I assume you are suggesting these values for x86_64 because they
> > lie in an unused hole. That makes sense to me.
> >
> > For the case of x86_32, I have trouble finding a suitable place as there
> > are not many available holes. It could be put before VMALLOC_START or
> > after VMALLOC_END but this would reveal the position of the vmalloc
> > area. Although, to my knowledge, randomized memory is not available for
> > x86_32. Without randomization, does it hurt to make sidt/sgdt return the
> > address of a kernel static variable?
> 
> I would just use the same addresses, truncated.  There's no reason
> that the address needs to be truly not present -- it just needs to be
> inaccessible to user code.  Anything near the top of the address space
> should work.

Right. Then I will reuse the same addresses.
> 
> >
> >>
> >> >
> >> > The instructions sldt and str return a segment selector relative to the
> >> > base address of the global descriptor table. Since the actual address of
> >> > such table is not revealed, it makes sense to emulate the result as zero.
> >>
> >> Hmm, now I wonder if anything uses SLDT to see if there is an LDT.  If
> >> so, we could emulate it better, but I doubt this matters.
> >
> > So you are saying that the emulated sldt should return a different value
> > based on the presence/absence of a LDT? This could reveal this very
> > fact.
> 
> User code knows whether the LDT exists because an LDT only exists if
> the program called modify_ldt().  But I doubt this matters in
> practice.

In such a case sldt would return a non-null segment selector. I will
keep giving the null segment selector in all cases and make a note in
the code.

> 
> >> > +static int __emulate_umip_insn(struct insn *insn, enum umip_insn 
> >> > umip_inst,
> >> > +  unsigned char *data, int *data_size)
> >> > +{
> >> > +   unsigned long const *dummy_base_addr;
> >> > +   unsigned short dummy_limit = 0;
> >> > +   unsigned short dummy_value = 0;
> >> > +
> >> > +   switch (umip_inst) {
> >> > +   /*
> >> > +* These two instructions return the base address and limit of 
> >> > the
> >> > +* global and interrupt descriptor table. The base address can be
> >> > +* 32-bit or 64-bit. Limit is always 16-bit.
> >> > +*/
> >> > +   case UMIP_SGDT:
> >> > +   case UMIP_SIDT:
> >> > +   if (umip_inst == UMIP_SGDT)
> >> > +   dummy_base_addr = _dummy_gdt_base;
> >> > +   else
> >> > +   dummy_base_addr = _dummy_idt_base;
> >> > +   if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> >> > +   WARN_ONCE(1, "SGDT cannot take register as 
> >> > argument!\n");
> >>
> >> No warnings please.
> >
> > I'll. Remove it.
> 
> Thanks.  In general, WARN_ONCE, etc are supposed to indicate kernel
> bugs, not user bugs.

Agreed. Your statement makes it very clear. I didn't have it that clear
in my mind.

> 
> >> > +   int not_copied, nr_copied, reg_offset, dummy_data_size;
> >> > +

Re: [v2 5/7] x86: Add emulation code for UMIP instructions

[Ricardo Neri]

On Tue, 2016-12-27 at 16:48 -0800, Andy Lutomirski wrote:
> On Tue, Dec 27, 2016 at 4:39 PM, Ricardo Neri
>  wrote:
> > On Fri, 2016-12-23 at 18:11 -0800, Andy Lutomirski wrote:
> >> On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
> >>  wrote:
> >> > The feature User-Mode Instruction Prevention present in recent Intel
> >> > processor prevents a group of instructions from being executed with
> >> > CPL > 0. Otherwise, a general protection fault is issued.
> >> >
> >> > Rather than relaying this fault to the user space (in the form of a 
> >> > SIGSEGV
> >> > signal), the instructions protected by UMIP can be emulated to provide
> >> > dummy results. This allows to conserve the current kernel behavior and 
> >> > not
> >> > reveal the system resources that UMIP intends to protect (the global
> >> > descriptor and interrupt descriptor tables, the segment selectors of the
> >> > local descriptor table and the task state and the machine status word).
> >> >
> >> > This emulation is needed because certain applications (e.g., WineHQ) rely
> >> > on this subset of instructions to function.
> >> >
> >> > The instructions protected by UMIP can be split in two groups. Those who
> >> > return a kernel memory address (sgdt and sidt) and those who return a
> >> > value (sldt, str and smsw).
> >> >
> >> > For the instructions that return a kernel memory address, the result is
> >> > emulated as the location of a dummy variable in the kernel memory space.
> >> > This is needed as applications such as WineHQ rely on the result being
> >> > located in the kernel memory space function. The limit for the GDT and 
> >> > the
> >> > IDT are set to zero.
> >>
> >> Nak.  This is a trivial KASLR bypass.  Just give them hardcoded
> >> values.  For x86_64, I would suggest 0xfffe and
> >> 0x.
> >
> > I see. I assume you are suggesting these values for x86_64 because they
> > lie in an unused hole. That makes sense to me.
> >
> > For the case of x86_32, I have trouble finding a suitable place as there
> > are not many available holes. It could be put before VMALLOC_START or
> > after VMALLOC_END but this would reveal the position of the vmalloc
> > area. Although, to my knowledge, randomized memory is not available for
> > x86_32. Without randomization, does it hurt to make sidt/sgdt return the
> > address of a kernel static variable?
> 
> I would just use the same addresses, truncated.  There's no reason
> that the address needs to be truly not present -- it just needs to be
> inaccessible to user code.  Anything near the top of the address space
> should work.

Right. Then I will reuse the same addresses.
> 
> >
> >>
> >> >
> >> > The instructions sldt and str return a segment selector relative to the
> >> > base address of the global descriptor table. Since the actual address of
> >> > such table is not revealed, it makes sense to emulate the result as zero.
> >>
> >> Hmm, now I wonder if anything uses SLDT to see if there is an LDT.  If
> >> so, we could emulate it better, but I doubt this matters.
> >
> > So you are saying that the emulated sldt should return a different value
> > based on the presence/absence of a LDT? This could reveal this very
> > fact.
> 
> User code knows whether the LDT exists because an LDT only exists if
> the program called modify_ldt().  But I doubt this matters in
> practice.

In such a case sldt would return a non-null segment selector. I will
keep giving the null segment selector in all cases and make a note in
the code.

> 
> >> > +static int __emulate_umip_insn(struct insn *insn, enum umip_insn 
> >> > umip_inst,
> >> > +  unsigned char *data, int *data_size)
> >> > +{
> >> > +   unsigned long const *dummy_base_addr;
> >> > +   unsigned short dummy_limit = 0;
> >> > +   unsigned short dummy_value = 0;
> >> > +
> >> > +   switch (umip_inst) {
> >> > +   /*
> >> > +* These two instructions return the base address and limit of 
> >> > the
> >> > +* global and interrupt descriptor table. The base address can be
> >> > +* 32-bit or 64-bit. Limit is always 16-bit.
> >> > +*/
> >> > +   case UMIP_SGDT:
> >> > +   case UMIP_SIDT:
> >> > +   if (umip_inst == UMIP_SGDT)
> >> > +   dummy_base_addr = _dummy_gdt_base;
> >> > +   else
> >> > +   dummy_base_addr = _dummy_idt_base;
> >> > +   if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> >> > +   WARN_ONCE(1, "SGDT cannot take register as 
> >> > argument!\n");
> >>
> >> No warnings please.
> >
> > I'll. Remove it.
> 
> Thanks.  In general, WARN_ONCE, etc are supposed to indicate kernel
> bugs, not user bugs.

Agreed. Your statement makes it very clear. I didn't have it that clear
in my mind.

> 
> >> > +   int not_copied, nr_copied, reg_offset, dummy_data_size;
> >> > +   void __user *uaddr;
> >> > +   unsigned long *reg_addr;
> >> > +   

Re: [PATCH net-next V2 3/3] tun: rx batching

[Jason Wang]

On 2016年12月30日 00:35, David Miller wrote:

From: Jason Wang 
Date: Wed, 28 Dec 2016 16:09:31 +0800


+   spin_lock(>lock);
+   qlen = skb_queue_len(queue);
+   if (qlen > rx_batched)
+   goto drop;
+   __skb_queue_tail(queue, skb);
+   if (!more || qlen + 1 > rx_batched) {
+   __skb_queue_head_init(_queue);
+   skb_queue_splice_tail_init(queue, _queue);
+   rcv = true;
+   }
+   spin_unlock(>lock);

Since you always clear the 'queue' when you insert the skb that hits
the limit, I don't see how the "goto drop" path can be possibly taken.


True, will fix this.

Thanks

Re: [PATCH net-next V2 3/3] tun: rx batching

[Jason Wang]

On 2016年12月30日 00:35, David Miller wrote:

From: Jason Wang 
Date: Wed, 28 Dec 2016 16:09:31 +0800


+   spin_lock(>lock);
+   qlen = skb_queue_len(queue);
+   if (qlen > rx_batched)
+   goto drop;
+   __skb_queue_tail(queue, skb);
+   if (!more || qlen + 1 > rx_batched) {
+   __skb_queue_head_init(_queue);
+   skb_queue_splice_tail_init(queue, _queue);
+   rcv = true;
+   }
+   spin_unlock(>lock);

Since you always clear the 'queue' when you insert the skb that hits
the limit, I don't see how the "goto drop" path can be possibly taken.


True, will fix this.

Thanks

Re: [PATCH v2 1/3] introduce memcpy_nocache()

[Dan Williams]

On Thu, Dec 29, 2016 at 7:52 PM, Al Viro  wrote:
> On Thu, Dec 29, 2016 at 10:23:15AM -0800, Dan Williams wrote:
>
>> > BTW, your "it's iovec, only non-temporal stores there" logics in
>> > arch_copy_from_iter_pmem() is simply wrong - for one thing, unaligned
>> > copies will have parts done via normal stores, for another 32bit will
>> > _not_ go for non-caching codepath for short copies.  What semantics do
>> > we really need there?
>>
>> For typical pmem platforms we need to make sure all the writes are on
>> the way to memory such than a later sfence can guarantee that all
>> previous writes are visible to the platform "ADR" logic.  ADR handles
>> flushing memory controller write buffers to media. At a minimum
>> arch_copy_from_iter_pmem() needs to trigger a clwb (unordered cache
>> line writeback) of each touched cache line if it is not using a cache
>> bypassing store.
>
> Um...  Then we do have a problem - nocache variant of uaccess primitives
> does *not* guarantee that clwb is redundant.
>
> What about the requirements of e.g. tcp_sendmsg() with its use of
> skb_add_data_nocache()?  What warranties do we need there?

Yes, we need to distinguish the existing "nocache" that tries to avoid
unnecessary cache pollution and this new "must write through" semantic
for writing to persistent memory. I suspect usages of
skb_add_data_nocache() are ok since they are in the transmit path.
Receiving directly into a buffer that is expected to be persisted
immediately is where we would need to be careful, but that is already
backstopped by dirty cacheline tracking. So as far as I can see, we
should only need a new memcpy_writethrough() (?) for the pmem
direct-i/o path at present.

Re: [PATCH v2 1/3] introduce memcpy_nocache()

[Dan Williams]

On Thu, Dec 29, 2016 at 7:52 PM, Al Viro  wrote:
> On Thu, Dec 29, 2016 at 10:23:15AM -0800, Dan Williams wrote:
>
>> > BTW, your "it's iovec, only non-temporal stores there" logics in
>> > arch_copy_from_iter_pmem() is simply wrong - for one thing, unaligned
>> > copies will have parts done via normal stores, for another 32bit will
>> > _not_ go for non-caching codepath for short copies.  What semantics do
>> > we really need there?
>>
>> For typical pmem platforms we need to make sure all the writes are on
>> the way to memory such than a later sfence can guarantee that all
>> previous writes are visible to the platform "ADR" logic.  ADR handles
>> flushing memory controller write buffers to media. At a minimum
>> arch_copy_from_iter_pmem() needs to trigger a clwb (unordered cache
>> line writeback) of each touched cache line if it is not using a cache
>> bypassing store.
>
> Um...  Then we do have a problem - nocache variant of uaccess primitives
> does *not* guarantee that clwb is redundant.
>
> What about the requirements of e.g. tcp_sendmsg() with its use of
> skb_add_data_nocache()?  What warranties do we need there?

Yes, we need to distinguish the existing "nocache" that tries to avoid
unnecessary cache pollution and this new "must write through" semantic
for writing to persistent memory. I suspect usages of
skb_add_data_nocache() are ok since they are in the transmit path.
Receiving directly into a buffer that is expected to be persisted
immediately is where we would need to be careful, but that is already
backstopped by dirty cacheline tracking. So as far as I can see, we
should only need a new memcpy_writethrough() (?) for the pmem
direct-i/o path at present.

Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()

[Kenneth Lee]

Hi, Leon,

1. I do change the title except for the version number itself:) But my English
is quite bad, maybe the title is still quite stupid. I can update it according
to your advice.

2. I catched the bug by reading the final code, not by bisect-ing the old
commit. Do you means I should find out which commit introducing the bug? It will
not be easily to say which it is because it is a "missing bug", rather than a
"introduced bug". Indicate the commit may not help to remove a patch/commit from
the stable tree.

Could you please give more suggestion? Thanks.

On Thu, Dec 29, 2016 at 10:17:56AM +0200, Leon Romanovsky wrote:
> Date: Thu, 29 Dec 2016 10:17:56 +0200
> From: Leon Romanovsky 
> To: Kenneth Lee 
> CC: dledf...@redhat.com, sean.he...@intel.com, hal.rosenst...@gmail.com,
>  robin.mur...@arm.com, jroe...@suse.de, egtv...@samfundet.no,
>  vgu...@synopsys.com, dave.han...@linux.intel.com, lstoa...@gmail.com,
>  k...@kernel.org, seb...@linux.vnet.ibm.com, ma...@mellanox.com,
>  linux-r...@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()
> User-Agent: Mutt/1.7.2 (2016-11-26)
> Message-ID: <20161229081756.GI26885@mtr-leonro.local>
> 
> On Thu, Dec 29, 2016 at 04:27:28PM +0800, Kenneth Lee wrote:
> > There are two bugfixes in this patch:
> >
> > 1. When the execution go to the ib_umem_odp_get() path, pid should be put
> >back.
> > 2. When the memory allocation fail, the pid also should be put back before
> >exit.
> >
> > Signed-off-by: Kenneth Lee 
> > Reviewed-by: Haggai Eran 
> > ---
> > Change from v1 to v2:
> >   Correcting the patch title and description
> 
> I don't see any changes except version in the title.
> What about anything like this?
> [PATCH v3] IB/umem: Release pid in error and ODP flows
> 
> And Fixes line please, it will help to forward it to stable trees.
> 
> Thanks



-- 
-Kenneth(Hisilicon)

Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()

[Kenneth Lee]

Hi, Leon,

1. I do change the title except for the version number itself:) But my English
is quite bad, maybe the title is still quite stupid. I can update it according
to your advice.

2. I catched the bug by reading the final code, not by bisect-ing the old
commit. Do you means I should find out which commit introducing the bug? It will
not be easily to say which it is because it is a "missing bug", rather than a
"introduced bug". Indicate the commit may not help to remove a patch/commit from
the stable tree.

Could you please give more suggestion? Thanks.

On Thu, Dec 29, 2016 at 10:17:56AM +0200, Leon Romanovsky wrote:
> Date: Thu, 29 Dec 2016 10:17:56 +0200
> From: Leon Romanovsky 
> To: Kenneth Lee 
> CC: dledf...@redhat.com, sean.he...@intel.com, hal.rosenst...@gmail.com,
>  robin.mur...@arm.com, jroe...@suse.de, egtv...@samfundet.no,
>  vgu...@synopsys.com, dave.han...@linux.intel.com, lstoa...@gmail.com,
>  k...@kernel.org, seb...@linux.vnet.ibm.com, ma...@mellanox.com,
>  linux-r...@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] ib umem: bugfix: mixed put_pid()s in ib_umem_get()
> User-Agent: Mutt/1.7.2 (2016-11-26)
> Message-ID: <20161229081756.GI26885@mtr-leonro.local>
> 
> On Thu, Dec 29, 2016 at 04:27:28PM +0800, Kenneth Lee wrote:
> > There are two bugfixes in this patch:
> >
> > 1. When the execution go to the ib_umem_odp_get() path, pid should be put
> >back.
> > 2. When the memory allocation fail, the pid also should be put back before
> >exit.
> >
> > Signed-off-by: Kenneth Lee 
> > Reviewed-by: Haggai Eran 
> > ---
> > Change from v1 to v2:
> >   Correcting the patch title and description
> 
> I don't see any changes except version in the title.
> What about anything like this?
> [PATCH v3] IB/umem: Release pid in error and ODP flows
> 
> And Fixes line please, it will help to forward it to stable trees.
> 
> Thanks



-- 
-Kenneth(Hisilicon)

[PATCH v2] usb: musb: sunxi: Uses the resource-managed extcon API when registering extcon notifier

[Chanwoo Choi]

This patch just uses the resource-managed extcon API when registering
the extcon notifier.

Signed-off-by: Chanwoo Choi 
Acked-by: Maxime Ripard 
Acked-by: Bin Liu 
---
Changes from v1:
- Rebase this patch based on v4.10-rc1.
- Add acked-by tag from Maxime Ripard and Bin Lin.
- Drop the phy/power-supply/chipidea patches.

 drivers/usb/musb/sunxi.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index d0be0eadd0d9..2332294dee0f 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -251,14 +251,14 @@ static int sunxi_musb_init(struct musb *musb)
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0);
 
/* Register notifier before calling phy_init() */
-   ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
+   ret = devm_extcon_register_notifier(glue->dev, glue->extcon,
+   EXTCON_USB_HOST, >host_nb);
if (ret)
goto error_reset_assert;
 
ret = phy_init(glue->phy);
if (ret)
-   goto error_unregister_notifier;
+   goto error_reset_assert;
 
musb->isr = sunxi_musb_interrupt;
 
@@ -267,9 +267,6 @@ static int sunxi_musb_init(struct musb *musb)
 
return 0;
 
-error_unregister_notifier:
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
 error_reset_assert:
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
@@ -293,9 +290,6 @@ static int sunxi_musb_exit(struct musb *musb)
 
phy_exit(glue->phy);
 
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
-
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
 
-- 
1.9.1

[PATCH v2] usb: musb: sunxi: Uses the resource-managed extcon API when registering extcon notifier

[Chanwoo Choi]

This patch just uses the resource-managed extcon API when registering
the extcon notifier.

Signed-off-by: Chanwoo Choi 
Acked-by: Maxime Ripard 
Acked-by: Bin Liu 
---
Changes from v1:
- Rebase this patch based on v4.10-rc1.
- Add acked-by tag from Maxime Ripard and Bin Lin.
- Drop the phy/power-supply/chipidea patches.

 drivers/usb/musb/sunxi.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index d0be0eadd0d9..2332294dee0f 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -251,14 +251,14 @@ static int sunxi_musb_init(struct musb *musb)
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0);
 
/* Register notifier before calling phy_init() */
-   ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
+   ret = devm_extcon_register_notifier(glue->dev, glue->extcon,
+   EXTCON_USB_HOST, >host_nb);
if (ret)
goto error_reset_assert;
 
ret = phy_init(glue->phy);
if (ret)
-   goto error_unregister_notifier;
+   goto error_reset_assert;
 
musb->isr = sunxi_musb_interrupt;
 
@@ -267,9 +267,6 @@ static int sunxi_musb_init(struct musb *musb)
 
return 0;
 
-error_unregister_notifier:
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
 error_reset_assert:
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
@@ -293,9 +290,6 @@ static int sunxi_musb_exit(struct musb *musb)
 
phy_exit(glue->phy);
 
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
-
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
 
-- 
1.9.1

[PATCH v2 2/6] usb: phy: msm: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-msm-usb.c | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8a34759727bb..a15a89d4235d 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1742,14 +1742,14 @@ static int msm_otg_read_dt(struct platform_device 
*pdev, struct msm_otg *motg)
if (!IS_ERR(ext_vbus)) {
motg->vbus.extcon = ext_vbus;
motg->vbus.nb.notifier_call = msm_otg_vbus_notifier;
-   ret = extcon_register_notifier(ext_vbus, EXTCON_USB,
-   >vbus.nb);
+   ret = devm_extcon_register_notifier(>dev, ext_vbus,
+   EXTCON_USB, >vbus.nb);
if (ret < 0) {
dev_err(>dev, "register VBUS notifier failed\n");
return ret;
}
 
-   ret = extcon_get_cable_state_(ext_vbus, EXTCON_USB);
+   ret = extcon_get_state(ext_vbus, EXTCON_USB);
if (ret)
set_bit(B_SESS_VLD, >inputs);
else
@@ -1759,16 +1759,14 @@ static int msm_otg_read_dt(struct platform_device 
*pdev, struct msm_otg *motg)
if (!IS_ERR(ext_id)) {
motg->id.extcon = ext_id;
motg->id.nb.notifier_call = msm_otg_id_notifier;
-   ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
-   >id.nb);
+   ret = devm_extcon_register_notifier(>dev, ext_id,
+   EXTCON_USB_HOST, >id.nb);
if (ret < 0) {
dev_err(>dev, "register ID notifier failed\n");
-   extcon_unregister_notifier(motg->vbus.extcon,
-  EXTCON_USB, >vbus.nb);
return ret;
}
 
-   ret = extcon_get_cable_state_(ext_id, EXTCON_USB_HOST);
+   ret = extcon_get_state(ext_id, EXTCON_USB_HOST);
if (ret)
clear_bit(ID, >inputs);
else
@@ -1883,10 +1881,9 @@ static int msm_otg_probe(struct platform_device *pdev)
 */
if (motg->phy_number) {
phy_select = devm_ioremap_nocache(>dev, USB2_PHY_SEL, 4);
-   if (!phy_select) {
-   ret = -ENOMEM;
-   goto unregister_extcon;
-   }
+   if (!phy_select)
+   return -ENOMEM;
+
/* Enable second PHY with the OTG port */
writel(0x1, phy_select);
}
@@ -1897,7 +1894,7 @@ static int msm_otg_probe(struct platform_device *pdev)
if (motg->irq < 0) {
dev_err(>dev, "platform_get_irq failed\n");
ret = motg->irq;
-   goto unregister_extcon;
+   return motg->irq;
}
 
regs[0].supply = "vddcx";
@@ -1906,7 +1903,7 @@ static int msm_otg_probe(struct platform_device *pdev)
 
ret = devm_regulator_bulk_get(motg->phy.dev, ARRAY_SIZE(regs), regs);
if (ret)
-   goto unregister_extcon;
+   return ret;
 
motg->vddcx = regs[0].consumer;
motg->v3p3  = regs[1].consumer;
@@ -2003,11 +2000,6 @@ static int msm_otg_probe(struct platform_device *pdev)
clk_disable_unprepare(motg->clk);
if (!IS_ERR(motg->core_clk))
clk_disable_unprepare(motg->core_clk);
-unregister_extcon:
-   extcon_unregister_notifier(motg->id.extcon,
-  EXTCON_USB_HOST, >id.nb);
-   extcon_unregister_notifier(motg->vbus.extcon,
-  EXTCON_USB, >vbus.nb);
 
return ret;
 }
@@ -2029,9 +2021,6 @@ static int msm_otg_remove(struct platform_device *pdev)
 */
gpiod_set_value_cansleep(motg->switch_gpio, 0);
 
-   extcon_unregister_notifier(motg->id.extcon, EXTCON_USB_HOST, 
>id.nb);
-   extcon_unregister_notifier(motg->vbus.extcon, EXTCON_USB, 
>vbus.nb);
-
msm_otg_debugfs_cleanup();
cancel_delayed_work_sync(>chg_work);
cancel_work_sync(>sm_work);
-- 
1.9.1

[PATCH v2 2/6] usb: phy: msm: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-msm-usb.c | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8a34759727bb..a15a89d4235d 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1742,14 +1742,14 @@ static int msm_otg_read_dt(struct platform_device 
*pdev, struct msm_otg *motg)
if (!IS_ERR(ext_vbus)) {
motg->vbus.extcon = ext_vbus;
motg->vbus.nb.notifier_call = msm_otg_vbus_notifier;
-   ret = extcon_register_notifier(ext_vbus, EXTCON_USB,
-   >vbus.nb);
+   ret = devm_extcon_register_notifier(>dev, ext_vbus,
+   EXTCON_USB, >vbus.nb);
if (ret < 0) {
dev_err(>dev, "register VBUS notifier failed\n");
return ret;
}
 
-   ret = extcon_get_cable_state_(ext_vbus, EXTCON_USB);
+   ret = extcon_get_state(ext_vbus, EXTCON_USB);
if (ret)
set_bit(B_SESS_VLD, >inputs);
else
@@ -1759,16 +1759,14 @@ static int msm_otg_read_dt(struct platform_device 
*pdev, struct msm_otg *motg)
if (!IS_ERR(ext_id)) {
motg->id.extcon = ext_id;
motg->id.nb.notifier_call = msm_otg_id_notifier;
-   ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
-   >id.nb);
+   ret = devm_extcon_register_notifier(>dev, ext_id,
+   EXTCON_USB_HOST, >id.nb);
if (ret < 0) {
dev_err(>dev, "register ID notifier failed\n");
-   extcon_unregister_notifier(motg->vbus.extcon,
-  EXTCON_USB, >vbus.nb);
return ret;
}
 
-   ret = extcon_get_cable_state_(ext_id, EXTCON_USB_HOST);
+   ret = extcon_get_state(ext_id, EXTCON_USB_HOST);
if (ret)
clear_bit(ID, >inputs);
else
@@ -1883,10 +1881,9 @@ static int msm_otg_probe(struct platform_device *pdev)
 */
if (motg->phy_number) {
phy_select = devm_ioremap_nocache(>dev, USB2_PHY_SEL, 4);
-   if (!phy_select) {
-   ret = -ENOMEM;
-   goto unregister_extcon;
-   }
+   if (!phy_select)
+   return -ENOMEM;
+
/* Enable second PHY with the OTG port */
writel(0x1, phy_select);
}
@@ -1897,7 +1894,7 @@ static int msm_otg_probe(struct platform_device *pdev)
if (motg->irq < 0) {
dev_err(>dev, "platform_get_irq failed\n");
ret = motg->irq;
-   goto unregister_extcon;
+   return motg->irq;
}
 
regs[0].supply = "vddcx";
@@ -1906,7 +1903,7 @@ static int msm_otg_probe(struct platform_device *pdev)
 
ret = devm_regulator_bulk_get(motg->phy.dev, ARRAY_SIZE(regs), regs);
if (ret)
-   goto unregister_extcon;
+   return ret;
 
motg->vddcx = regs[0].consumer;
motg->v3p3  = regs[1].consumer;
@@ -2003,11 +2000,6 @@ static int msm_otg_probe(struct platform_device *pdev)
clk_disable_unprepare(motg->clk);
if (!IS_ERR(motg->core_clk))
clk_disable_unprepare(motg->core_clk);
-unregister_extcon:
-   extcon_unregister_notifier(motg->id.extcon,
-  EXTCON_USB_HOST, >id.nb);
-   extcon_unregister_notifier(motg->vbus.extcon,
-  EXTCON_USB, >vbus.nb);
 
return ret;
 }
@@ -2029,9 +2021,6 @@ static int msm_otg_remove(struct platform_device *pdev)
 */
gpiod_set_value_cansleep(motg->switch_gpio, 0);
 
-   extcon_unregister_notifier(motg->id.extcon, EXTCON_USB_HOST, 
>id.nb);
-   extcon_unregister_notifier(motg->vbus.extcon, EXTCON_USB, 
>vbus.nb);
-
msm_otg_debugfs_cleanup();
cancel_delayed_work_sync(>chg_work);
cancel_work_sync(>sm_work);
-- 
1.9.1

[PATCH v2 0/4] Use Exynos macros for pinctrl settings

[Andi Shyti]

Hi,

This patchset fixes the width and offsets of the PINCFG_TYPE_DRV
bitfields for the Exynos5433 SoC.

Moreover it refactors the pinctrl definitions by using the
dt-bindings/pinctrl/samsung.h definitions introduced by Krzysztof
in 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
values used for configuration").

It would be nice to see in the future all the PIN related macros
in the same file, as they more or less do the same thing.

Changelog v1 -> v2
==
V1: https://lkml.org/lkml/2016/12/29/40

- Added Chanwoo's patch for fixing the slew rate register width.
- Patch 4 is squashed with the patch3 and 4 of v1.

Thanks,
Andi

Andi Shyti (3):
  pinctrl: dt-bindings: samsung: add drive strength macros for
Exynos5433
  ARM64: dts: exynos5433: use macros for pinctrl configuration on
Exynos5433
  ARM64: dts: TM2: comply to the samsung pinctrl naming convention

Chanwoo Choi (1):
  pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for
Exynos5433

 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 373 ++---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 +++---
 drivers/pinctrl/samsung/pinctrl-exynos.c   |  91 ++---
 drivers/pinctrl/samsung/pinctrl-exynos.h   |  31 ++
 include/dt-bindings/pinctrl/samsung.h  |  14 +
 5 files changed, 404 insertions(+), 359 deletions(-)

-- 
2.11.0

[PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

[Andi Shyti]

Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
values used for configuration") has added a header file for defining the
pinctrl values in order to avoid hardcoded settings in the Exynos
DTS related files.

Extend samsung.h to the Exynos5433 for drive strength values
which are strictly related to the particular SoC and may defer
from others.

Signed-off-by: Andi Shyti 
---
 include/dt-bindings/pinctrl/samsung.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/dt-bindings/pinctrl/samsung.h 
b/include/dt-bindings/pinctrl/samsung.h
index 6276eb785e2b..e0ebb20ffdd3 100644
--- a/include/dt-bindings/pinctrl/samsung.h
+++ b/include/dt-bindings/pinctrl/samsung.h
@@ -45,6 +45,20 @@
 #define EXYNOS5420_PIN_DRV_LV3 2
 #define EXYNOS5420_PIN_DRV_LV4 3
 
+/* Drive strengths for Exynos5433 */
+#define EXYNOS5433_PIN_DRV_FAST_SR10
+#define EXYNOS5433_PIN_DRV_FAST_SR21
+#define EXYNOS5433_PIN_DRV_FAST_SR32
+#define EXYNOS5433_PIN_DRV_FAST_SR43
+#define EXYNOS5433_PIN_DRV_FAST_SR54
+#define EXYNOS5433_PIN_DRV_FAST_SR65
+#define EXYNOS5433_PIN_DRV_SLOW_SR18
+#define EXYNOS5433_PIN_DRV_SLOW_SR29
+#define EXYNOS5433_PIN_DRV_SLOW_SR30xa
+#define EXYNOS5433_PIN_DRV_SLOW_SR40xb
+#define EXYNOS5433_PIN_DRV_SLOW_SR50xc
+#define EXYNOS5433_PIN_DRV_SLOW_SR60xf
+
 #define EXYNOS_PIN_FUNC_INPUT  0
 #define EXYNOS_PIN_FUNC_OUTPUT 1
 #define EXYNOS_PIN_FUNC_2  2
-- 
2.11.0

[PATCH v2 0/4] Use Exynos macros for pinctrl settings

[Andi Shyti]

Hi,

This patchset fixes the width and offsets of the PINCFG_TYPE_DRV
bitfields for the Exynos5433 SoC.

Moreover it refactors the pinctrl definitions by using the
dt-bindings/pinctrl/samsung.h definitions introduced by Krzysztof
in 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
values used for configuration").

It would be nice to see in the future all the PIN related macros
in the same file, as they more or less do the same thing.

Changelog v1 -> v2
==
V1: https://lkml.org/lkml/2016/12/29/40

- Added Chanwoo's patch for fixing the slew rate register width.
- Patch 4 is squashed with the patch3 and 4 of v1.

Thanks,
Andi

Andi Shyti (3):
  pinctrl: dt-bindings: samsung: add drive strength macros for
Exynos5433
  ARM64: dts: exynos5433: use macros for pinctrl configuration on
Exynos5433
  ARM64: dts: TM2: comply to the samsung pinctrl naming convention

Chanwoo Choi (1):
  pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for
Exynos5433

 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 373 ++---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 +++---
 drivers/pinctrl/samsung/pinctrl-exynos.c   |  91 ++---
 drivers/pinctrl/samsung/pinctrl-exynos.h   |  31 ++
 include/dt-bindings/pinctrl/samsung.h  |  14 +
 5 files changed, 404 insertions(+), 359 deletions(-)

-- 
2.11.0

[PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

[Andi Shyti]

Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
values used for configuration") has added a header file for defining the
pinctrl values in order to avoid hardcoded settings in the Exynos
DTS related files.

Extend samsung.h to the Exynos5433 for drive strength values
which are strictly related to the particular SoC and may defer
from others.

Signed-off-by: Andi Shyti 
---
 include/dt-bindings/pinctrl/samsung.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/dt-bindings/pinctrl/samsung.h 
b/include/dt-bindings/pinctrl/samsung.h
index 6276eb785e2b..e0ebb20ffdd3 100644
--- a/include/dt-bindings/pinctrl/samsung.h
+++ b/include/dt-bindings/pinctrl/samsung.h
@@ -45,6 +45,20 @@
 #define EXYNOS5420_PIN_DRV_LV3 2
 #define EXYNOS5420_PIN_DRV_LV4 3
 
+/* Drive strengths for Exynos5433 */
+#define EXYNOS5433_PIN_DRV_FAST_SR10
+#define EXYNOS5433_PIN_DRV_FAST_SR21
+#define EXYNOS5433_PIN_DRV_FAST_SR32
+#define EXYNOS5433_PIN_DRV_FAST_SR43
+#define EXYNOS5433_PIN_DRV_FAST_SR54
+#define EXYNOS5433_PIN_DRV_FAST_SR65
+#define EXYNOS5433_PIN_DRV_SLOW_SR18
+#define EXYNOS5433_PIN_DRV_SLOW_SR29
+#define EXYNOS5433_PIN_DRV_SLOW_SR30xa
+#define EXYNOS5433_PIN_DRV_SLOW_SR40xb
+#define EXYNOS5433_PIN_DRV_SLOW_SR50xc
+#define EXYNOS5433_PIN_DRV_SLOW_SR60xf
+
 #define EXYNOS_PIN_FUNC_INPUT  0
 #define EXYNOS_PIN_FUNC_OUTPUT 1
 #define EXYNOS_PIN_FUNC_2  2
-- 
2.11.0

[PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

[Andi Shyti]

Change the PIN() macro definition so that it can use the macros
from pinctrl/samsung.h header file.

Signed-off-by: Andi Shyti 
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  25 +-
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 ++---
 2 files changed, 133 insertions(+), 146 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
index 2af854b11644..d49879bd34bb 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -14,25 +14,12 @@
 
 #include 
 
-#define PIN_PULL_NONE  0
-#define PIN_PULL_DOWN  1
-#define PIN_PULL_UP3
-
-#define PIN_DRV_LV10
-#define PIN_DRV_LV22
-#define PIN_DRV_LV31
-#define PIN_DRV_LV43
-
-#define PIN_IN 0
-#define PIN_OUT1
-#define PIN_FUNC1  2
-
-#define PIN(_func, _pin, _pull, _drv)  \
-   _pin {  \
-   samsung,pins = #_pin;   \
-   samsung,pin-function = ;  \
-   samsung,pin-pud = ;  \
-   samsung,pin-drv = ;\
+#define PIN(_func, _pin, _pull, _drv)  \
+   _pin {  \
+   samsung,pins = #_pin;   \
+   samsung,pin-function = ;  \
+   samsung,pin-pud = ;   \
+   samsung,pin-drv = ; \
}
 
 _alive {
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index f21bdc2ff834..66c4d5959881 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -742,77 +742,77 @@
pinctrl-0 = <_alive>;
 
initial_alive: initial-state {
-   PIN(IN, gpa0-0, DOWN, LV1);
-   PIN(IN, gpa0-1, NONE, LV1);
-   PIN(IN, gpa0-2, DOWN, LV1);
-   PIN(IN, gpa0-3, NONE, LV1);
-   PIN(IN, gpa0-4, NONE, LV1);
-   PIN(IN, gpa0-5, DOWN, LV1);
-   PIN(IN, gpa0-6, NONE, LV1);
-   PIN(IN, gpa0-7, NONE, LV1);
-
-   PIN(IN, gpa1-0, UP, LV1);
-   PIN(IN, gpa1-1, NONE, LV1);
-   PIN(IN, gpa1-2, NONE, LV1);
-   PIN(IN, gpa1-3, DOWN, LV1);
-   PIN(IN, gpa1-4, DOWN, LV1);
-   PIN(IN, gpa1-5, NONE, LV1);
-   PIN(IN, gpa1-6, NONE, LV1);
-   PIN(IN, gpa1-7, NONE, LV1);
-
-   PIN(IN, gpa2-0, NONE, LV1);
-   PIN(IN, gpa2-1, NONE, LV1);
-   PIN(IN, gpa2-2, NONE, LV1);
-   PIN(IN, gpa2-3, DOWN, LV1);
-   PIN(IN, gpa2-4, NONE, LV1);
-   PIN(IN, gpa2-5, DOWN, LV1);
-   PIN(IN, gpa2-6, DOWN, LV1);
-   PIN(IN, gpa2-7, NONE, LV1);
-
-   PIN(IN, gpa3-0, DOWN, LV1);
-   PIN(IN, gpa3-1, DOWN, LV1);
-   PIN(IN, gpa3-2, NONE, LV1);
-   PIN(IN, gpa3-3, DOWN, LV1);
-   PIN(IN, gpa3-4, NONE, LV1);
-   PIN(IN, gpa3-5, DOWN, LV1);
-   PIN(IN, gpa3-6, DOWN, LV1);
-   PIN(IN, gpa3-7, DOWN, LV1);
-
-   PIN(IN, gpf1-0, NONE, LV1);
-   PIN(IN, gpf1-1, NONE, LV1);
-   PIN(IN, gpf1-2, DOWN, LV1);
-   PIN(IN, gpf1-4, UP, LV1);
-   PIN(OUT, gpf1-5, NONE, LV1);
-   PIN(IN, gpf1-6, DOWN, LV1);
-   PIN(IN, gpf1-7, DOWN, LV1);
-
-   PIN(IN, gpf2-0, DOWN, LV1);
-   PIN(IN, gpf2-1, DOWN, LV1);
-   PIN(IN, gpf2-2, DOWN, LV1);
-   PIN(IN, gpf2-3, DOWN, LV1);
-
-   PIN(IN, gpf3-0, DOWN, LV1);
-   PIN(IN, gpf3-1, DOWN, LV1);
-   PIN(IN, gpf3-2, NONE, LV1);
-   PIN(IN, gpf3-3, DOWN, LV1);
-
-   PIN(IN, gpf4-0, DOWN, LV1);
-   PIN(IN, gpf4-1, DOWN, LV1);
-   PIN(IN, gpf4-2, DOWN, LV1);
-   PIN(IN, gpf4-3, DOWN, LV1);
-   PIN(IN, gpf4-4, DOWN, LV1);
-   PIN(IN, gpf4-5, DOWN, LV1);
-   PIN(IN, gpf4-6, DOWN, LV1);
-   PIN(IN, gpf4-7, DOWN, LV1);
-
-   PIN(IN, gpf5-0, DOWN, LV1);
-   PIN(IN, gpf5-1, DOWN, LV1);
-   PIN(IN, gpf5-2, DOWN, LV1);
-   PIN(IN, gpf5-3, DOWN, LV1);
-   PIN(OUT, gpf5-4, NONE, LV1);
-   PIN(IN, gpf5-5, DOWN, LV1);
-   PIN(IN, gpf5-6, DOWN, LV1);
-   PIN(IN, gpf5-7, DOWN, LV1);
+   PIN(INPUT, gpa0-0, DOWN, FAST_SR1);
+   PIN(INPUT, gpa0-1, NONE, FAST_SR1);
+   PIN(INPUT, gpa0-2, DOWN, FAST_SR1);
+  

[PATCH v2] usb: chipdata: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Cc: Peter Chen 
Signed-off-by: Chanwoo Choi 
---
Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Drop the phy/power-supply/dwc3/omap patches.

 drivers/usb/chipidea/core.c | 30 ++
 1 file changed, 6 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3dbb4a21ab44..5c35f25e9bce 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
cable->edev = ext_vbus;
 
if (!IS_ERR(ext_vbus)) {
-   ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
+   ret = extcon_get_state(cable->edev, EXTCON_USB);
if (ret)
cable->state = true;
else
@@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
cable->edev = ext_id;
 
if (!IS_ERR(ext_id)) {
-   ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
+   ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
if (ret)
cable->state = false;
else
@@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
id = >platdata->id_extcon;
id->ci = ci;
if (!IS_ERR(id->edev)) {
-   ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
-  >nb);
+   ret = devm_extcon_register_notifier(ci->dev, id->edev,
+   EXTCON_USB_HOST, >nb);
if (ret < 0) {
dev_err(ci->dev, "register ID failed\n");
return ret;
@@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
vbus = >platdata->vbus_extcon;
vbus->ci = ci;
if (!IS_ERR(vbus->edev)) {
-   ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
-  >nb);
+   ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
+   EXTCON_USB, >nb);
if (ret < 0) {
-   extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
-  >nb);
dev_err(ci->dev, "register VBUS failed\n");
return ret;
}
@@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
return 0;
 }
 
-static void ci_extcon_unregister(struct ci_hdrc *ci)
-{
-   struct ci_hdrc_cable *cable;
-
-   cable = >platdata->id_extcon;
-   if (!IS_ERR(cable->edev))
-   extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
-  >nb);
-
-   cable = >platdata->vbus_extcon;
-   if (!IS_ERR(cable->edev))
-   extcon_unregister_notifier(cable->edev, EXTCON_USB, >nb);
-}
-
 static DEFINE_IDA(ci_ida);
 
 struct platform_device *ci_hdrc_add_device(struct device *dev,
@@ -1054,7 +1038,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ret)
return 0;
 
-   ci_extcon_unregister(ci);
 stop:
ci_role_destroy(ci);
 deinit_phy:
@@ -1074,7 +1057,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
}
 
dbg_remove_files(ci);
-   ci_extcon_unregister(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
ci_usb_phy_exit(ci);
-- 
1.9.1

[PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

[Andi Shyti]

Change the PIN() macro definition so that it can use the macros
from pinctrl/samsung.h header file.

Signed-off-by: Andi Shyti 
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  25 +-
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 ++---
 2 files changed, 133 insertions(+), 146 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
index 2af854b11644..d49879bd34bb 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -14,25 +14,12 @@
 
 #include 
 
-#define PIN_PULL_NONE  0
-#define PIN_PULL_DOWN  1
-#define PIN_PULL_UP3
-
-#define PIN_DRV_LV10
-#define PIN_DRV_LV22
-#define PIN_DRV_LV31
-#define PIN_DRV_LV43
-
-#define PIN_IN 0
-#define PIN_OUT1
-#define PIN_FUNC1  2
-
-#define PIN(_func, _pin, _pull, _drv)  \
-   _pin {  \
-   samsung,pins = #_pin;   \
-   samsung,pin-function = ;  \
-   samsung,pin-pud = ;  \
-   samsung,pin-drv = ;\
+#define PIN(_func, _pin, _pull, _drv)  \
+   _pin {  \
+   samsung,pins = #_pin;   \
+   samsung,pin-function = ;  \
+   samsung,pin-pud = ;   \
+   samsung,pin-drv = ; \
}
 
 _alive {
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index f21bdc2ff834..66c4d5959881 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -742,77 +742,77 @@
pinctrl-0 = <_alive>;
 
initial_alive: initial-state {
-   PIN(IN, gpa0-0, DOWN, LV1);
-   PIN(IN, gpa0-1, NONE, LV1);
-   PIN(IN, gpa0-2, DOWN, LV1);
-   PIN(IN, gpa0-3, NONE, LV1);
-   PIN(IN, gpa0-4, NONE, LV1);
-   PIN(IN, gpa0-5, DOWN, LV1);
-   PIN(IN, gpa0-6, NONE, LV1);
-   PIN(IN, gpa0-7, NONE, LV1);
-
-   PIN(IN, gpa1-0, UP, LV1);
-   PIN(IN, gpa1-1, NONE, LV1);
-   PIN(IN, gpa1-2, NONE, LV1);
-   PIN(IN, gpa1-3, DOWN, LV1);
-   PIN(IN, gpa1-4, DOWN, LV1);
-   PIN(IN, gpa1-5, NONE, LV1);
-   PIN(IN, gpa1-6, NONE, LV1);
-   PIN(IN, gpa1-7, NONE, LV1);
-
-   PIN(IN, gpa2-0, NONE, LV1);
-   PIN(IN, gpa2-1, NONE, LV1);
-   PIN(IN, gpa2-2, NONE, LV1);
-   PIN(IN, gpa2-3, DOWN, LV1);
-   PIN(IN, gpa2-4, NONE, LV1);
-   PIN(IN, gpa2-5, DOWN, LV1);
-   PIN(IN, gpa2-6, DOWN, LV1);
-   PIN(IN, gpa2-7, NONE, LV1);
-
-   PIN(IN, gpa3-0, DOWN, LV1);
-   PIN(IN, gpa3-1, DOWN, LV1);
-   PIN(IN, gpa3-2, NONE, LV1);
-   PIN(IN, gpa3-3, DOWN, LV1);
-   PIN(IN, gpa3-4, NONE, LV1);
-   PIN(IN, gpa3-5, DOWN, LV1);
-   PIN(IN, gpa3-6, DOWN, LV1);
-   PIN(IN, gpa3-7, DOWN, LV1);
-
-   PIN(IN, gpf1-0, NONE, LV1);
-   PIN(IN, gpf1-1, NONE, LV1);
-   PIN(IN, gpf1-2, DOWN, LV1);
-   PIN(IN, gpf1-4, UP, LV1);
-   PIN(OUT, gpf1-5, NONE, LV1);
-   PIN(IN, gpf1-6, DOWN, LV1);
-   PIN(IN, gpf1-7, DOWN, LV1);
-
-   PIN(IN, gpf2-0, DOWN, LV1);
-   PIN(IN, gpf2-1, DOWN, LV1);
-   PIN(IN, gpf2-2, DOWN, LV1);
-   PIN(IN, gpf2-3, DOWN, LV1);
-
-   PIN(IN, gpf3-0, DOWN, LV1);
-   PIN(IN, gpf3-1, DOWN, LV1);
-   PIN(IN, gpf3-2, NONE, LV1);
-   PIN(IN, gpf3-3, DOWN, LV1);
-
-   PIN(IN, gpf4-0, DOWN, LV1);
-   PIN(IN, gpf4-1, DOWN, LV1);
-   PIN(IN, gpf4-2, DOWN, LV1);
-   PIN(IN, gpf4-3, DOWN, LV1);
-   PIN(IN, gpf4-4, DOWN, LV1);
-   PIN(IN, gpf4-5, DOWN, LV1);
-   PIN(IN, gpf4-6, DOWN, LV1);
-   PIN(IN, gpf4-7, DOWN, LV1);
-
-   PIN(IN, gpf5-0, DOWN, LV1);
-   PIN(IN, gpf5-1, DOWN, LV1);
-   PIN(IN, gpf5-2, DOWN, LV1);
-   PIN(IN, gpf5-3, DOWN, LV1);
-   PIN(OUT, gpf5-4, NONE, LV1);
-   PIN(IN, gpf5-5, DOWN, LV1);
-   PIN(IN, gpf5-6, DOWN, LV1);
-   PIN(IN, gpf5-7, DOWN, LV1);
+   PIN(INPUT, gpa0-0, DOWN, FAST_SR1);
+   PIN(INPUT, gpa0-1, NONE, FAST_SR1);
+   PIN(INPUT, gpa0-2, DOWN, FAST_SR1);
+   PIN(INPUT, gpa0-3, 

[PATCH v2] usb: chipdata: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Cc: Peter Chen 
Signed-off-by: Chanwoo Choi 
---
Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Drop the phy/power-supply/dwc3/omap patches.

 drivers/usb/chipidea/core.c | 30 ++
 1 file changed, 6 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3dbb4a21ab44..5c35f25e9bce 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
cable->edev = ext_vbus;
 
if (!IS_ERR(ext_vbus)) {
-   ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
+   ret = extcon_get_state(cable->edev, EXTCON_USB);
if (ret)
cable->state = true;
else
@@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
cable->edev = ext_id;
 
if (!IS_ERR(ext_id)) {
-   ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
+   ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
if (ret)
cable->state = false;
else
@@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
id = >platdata->id_extcon;
id->ci = ci;
if (!IS_ERR(id->edev)) {
-   ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
-  >nb);
+   ret = devm_extcon_register_notifier(ci->dev, id->edev,
+   EXTCON_USB_HOST, >nb);
if (ret < 0) {
dev_err(ci->dev, "register ID failed\n");
return ret;
@@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
vbus = >platdata->vbus_extcon;
vbus->ci = ci;
if (!IS_ERR(vbus->edev)) {
-   ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
-  >nb);
+   ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
+   EXTCON_USB, >nb);
if (ret < 0) {
-   extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
-  >nb);
dev_err(ci->dev, "register VBUS failed\n");
return ret;
}
@@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
return 0;
 }
 
-static void ci_extcon_unregister(struct ci_hdrc *ci)
-{
-   struct ci_hdrc_cable *cable;
-
-   cable = >platdata->id_extcon;
-   if (!IS_ERR(cable->edev))
-   extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
-  >nb);
-
-   cable = >platdata->vbus_extcon;
-   if (!IS_ERR(cable->edev))
-   extcon_unregister_notifier(cable->edev, EXTCON_USB, >nb);
-}
-
 static DEFINE_IDA(ci_ida);
 
 struct platform_device *ci_hdrc_add_device(struct device *dev,
@@ -1054,7 +1038,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ret)
return 0;
 
-   ci_extcon_unregister(ci);
 stop:
ci_role_destroy(ci);
 deinit_phy:
@@ -1074,7 +1057,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
}
 
dbg_remove_files(ci);
-   ci_extcon_unregister(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
ci_usb_phy_exit(ci);
-- 
1.9.1

[PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433

[Andi Shyti]

From: Chanwoo Choi 

This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.

Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
Cc: sta...@vger.kernel.org
Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Linus Walleij 
Cc: Kukjin Kim 
Cc: Javier Martinez Canillas 
Signed-off-by: Chanwoo Choi 
---
 drivers/pinctrl/samsung/pinctrl-exynos.c | 91 ++--
 drivers/pinctrl/samsung/pinctrl-exynos.h | 31 +++
 2 files changed, 82 insertions(+), 40 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 12f7d1eb65bc..07409fde02b2 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -56,6 +56,17 @@ static const struct samsung_pin_bank_type bank_type_alive = {
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
 };
 
+/* Exynos5433 has the 4bit widths for PINCFG_TYPE_DRV bitfields. */
+static const struct samsung_pin_bank_type exynos5433_bank_type_off = {
+   .fld_width = { 4, 1, 2, 4, 2, 2, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+static const struct samsung_pin_bank_type exynos5433_bank_type_alive = {
+   .fld_width = { 4, 1, 2, 4, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
 static void exynos_irq_mask(struct irq_data *irqd)
 {
struct irq_chip *chip = irq_data_get_irq_chip(irqd);
@@ -1335,82 +1346,82 @@ const struct samsung_pin_ctrl exynos5420_pin_ctrl[] 
__initconst = {
 
 /* pin banks of exynos5433 pin-controller - ALIVE */
 static const struct samsung_pin_bank_data exynos5433_pin_banks0[] = {
-   EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
-   EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
-   EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
-   EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
-   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1),
 };
 
 /* pin banks of exynos5433 pin-controller - AUD */
 static const struct samsung_pin_bank_data exynos5433_pin_banks1[] = {
-   EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
-   EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
+   EXYNOS5433_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
 };
 
 /* pin banks of exynos5433 pin-controller - CPIF */
 static const struct samsung_pin_bank_data exynos5433_pin_banks2[] = {
-   EXYNOS_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - eSE */
 static const struct samsung_pin_bank_data exynos5433_pin_banks3[] = {
-   EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - FINGER */
 static const struct samsung_pin_bank_data exynos5433_pin_banks4[] = {
-   EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - FSYS */
 static const struct samsung_pin_bank_data exynos5433_pin_banks5[] = {
-   EXYNOS_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
-   EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
-   EXYNOS_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
-   EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
-   EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
-   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpr3", 0x14),
+   EXYNOS5433_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
+   EXYNOS5433_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
+   EXYNOS5433_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
+   EXYNOS5433_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
+   EXYNOS5433_PIN_BANK_EINTG(8, 0x0a0, 

[PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Andi Shyti]

Use the macros defined in include/dt-bindings/pinctrl/samsung.h
instead of hardcoded values.

Signed-off-by: Andi Shyti 
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 +++--
 1 file changed, 175 insertions(+), 173 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
index ad71247b074f..2af854b11644 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -12,6 +12,8 @@
  * published by the Free Software Foundation.
  */
 
+#include 
+
 #define PIN_PULL_NONE  0
 #define PIN_PULL_DOWN  1
 #define PIN_PULL_UP3
@@ -145,23 +147,23 @@
i2s0_bus: i2s0-bus {
samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
"gpz0-4", "gpz0-5", "gpz0-6";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
pcm0_bus: pcm0-bus {
samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
-   samsung,pin-function = <3>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
uart_aud_bus: uart-aud-bus {
samsung,pins = "gpz1-3", "gpz1-2", "gpz1-1", "gpz1-0";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 };
 
@@ -196,16 +198,16 @@
 
spi2_bus: spi2-bus {
samsung,pins = "gpd5-0", "gpd5-2", "gpd5-3";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
hs_i2c6_bus: hs-i2c6-bus {
samsung,pins = "gpd5-3", "gpd5-2";
-   samsung,pin-function = <4>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 };
 
@@ -260,141 +262,141 @@
 
sd0_clk: sd0-clk {
samsung,pins = "gpr0-0";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_cmd: sd0-cmd {
samsung,pins = "gpr0-1";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_rdqs: sd0-rdqs {
samsung,pins = "gpr0-2";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_qrdy: sd0-qrdy {
samsung,pins = "gpr0-3";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_bus1: sd0-bus-width1 {
samsung,pins = "gpr1-0";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_bus4: sd0-bus-width4 {
samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_bus8: sd0-bus-width8 {
samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd1_clk: sd1-clk {
samsung,pins = "gpr2-0";
-   

[PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433

[Andi Shyti]

From: Chanwoo Choi 

This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.

Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
Cc: sta...@vger.kernel.org
Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Linus Walleij 
Cc: Kukjin Kim 
Cc: Javier Martinez Canillas 
Signed-off-by: Chanwoo Choi 
---
 drivers/pinctrl/samsung/pinctrl-exynos.c | 91 ++--
 drivers/pinctrl/samsung/pinctrl-exynos.h | 31 +++
 2 files changed, 82 insertions(+), 40 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 12f7d1eb65bc..07409fde02b2 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -56,6 +56,17 @@ static const struct samsung_pin_bank_type bank_type_alive = {
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
 };
 
+/* Exynos5433 has the 4bit widths for PINCFG_TYPE_DRV bitfields. */
+static const struct samsung_pin_bank_type exynos5433_bank_type_off = {
+   .fld_width = { 4, 1, 2, 4, 2, 2, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+static const struct samsung_pin_bank_type exynos5433_bank_type_alive = {
+   .fld_width = { 4, 1, 2, 4, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
 static void exynos_irq_mask(struct irq_data *irqd)
 {
struct irq_chip *chip = irq_data_get_irq_chip(irqd);
@@ -1335,82 +1346,82 @@ const struct samsung_pin_ctrl exynos5420_pin_ctrl[] 
__initconst = {
 
 /* pin banks of exynos5433 pin-controller - ALIVE */
 static const struct samsung_pin_bank_data exynos5433_pin_banks0[] = {
-   EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
-   EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
-   EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
-   EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
-   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1),
-   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
+   EXYNOS5433_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1),
+   EXYNOS5433_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1),
 };
 
 /* pin banks of exynos5433 pin-controller - AUD */
 static const struct samsung_pin_bank_data exynos5433_pin_banks1[] = {
-   EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
-   EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
+   EXYNOS5433_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
 };
 
 /* pin banks of exynos5433 pin-controller - CPIF */
 static const struct samsung_pin_bank_data exynos5433_pin_banks2[] = {
-   EXYNOS_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - eSE */
 static const struct samsung_pin_bank_data exynos5433_pin_banks3[] = {
-   EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - FINGER */
 static const struct samsung_pin_bank_data exynos5433_pin_banks4[] = {
-   EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - FSYS */
 static const struct samsung_pin_bank_data exynos5433_pin_banks5[] = {
-   EXYNOS_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
-   EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
-   EXYNOS_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
-   EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
-   EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
-   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpr3", 0x14),
+   EXYNOS5433_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
+   EXYNOS5433_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
+   EXYNOS5433_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
+   EXYNOS5433_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
+   EXYNOS5433_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
+   EXYNOS5433_PIN_BANK_EINTG(8, 0x0a0, "gpr3", 0x14),
 };
 
 /* pin banks of exynos5433 pin-controller - IMEM */
 static const struct samsung_pin_bank_data exynos5433_pin_banks6[] = {
-   EXYNOS_PIN_BANK_EINTG(8, 

[PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Andi Shyti]

Use the macros defined in include/dt-bindings/pinctrl/samsung.h
instead of hardcoded values.

Signed-off-by: Andi Shyti 
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 +++--
 1 file changed, 175 insertions(+), 173 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
index ad71247b074f..2af854b11644 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -12,6 +12,8 @@
  * published by the Free Software Foundation.
  */
 
+#include 
+
 #define PIN_PULL_NONE  0
 #define PIN_PULL_DOWN  1
 #define PIN_PULL_UP3
@@ -145,23 +147,23 @@
i2s0_bus: i2s0-bus {
samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
"gpz0-4", "gpz0-5", "gpz0-6";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
pcm0_bus: pcm0-bus {
samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
-   samsung,pin-function = <3>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
uart_aud_bus: uart-aud-bus {
samsung,pins = "gpz1-3", "gpz1-2", "gpz1-1", "gpz1-0";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 };
 
@@ -196,16 +198,16 @@
 
spi2_bus: spi2-bus {
samsung,pins = "gpd5-0", "gpd5-2", "gpd5-3";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
hs_i2c6_bus: hs-i2c6-bus {
samsung,pins = "gpd5-3", "gpd5-2";
-   samsung,pin-function = <4>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 };
 
@@ -260,141 +262,141 @@
 
sd0_clk: sd0-clk {
samsung,pins = "gpr0-0";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_cmd: sd0-cmd {
samsung,pins = "gpr0-1";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_rdqs: sd0-rdqs {
samsung,pins = "gpr0-2";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_qrdy: sd0-qrdy {
samsung,pins = "gpr0-3";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_bus1: sd0-bus-width1 {
samsung,pins = "gpr1-0";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_bus4: sd0-bus-width4 {
samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd0_bus8: sd0-bus-width8 {
samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7";
-   samsung,pin-function = <2>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <3>;
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
};
 
sd1_clk: sd1-clk {
samsung,pins = "gpr2-0";
-   samsung,pin-function = <2>;
-

[PATCH v2 1/2] phy: rcar-gen3-usb2: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()

Signed-off-by: Chanwoo Choi 
Acked-by: Yoshihiro Shimoda 
---
 drivers/phy/phy-rcar-gen3-usb2.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index c63da1b955c1..54a83675f0a8 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -94,11 +94,11 @@ static void rcar_gen3_phy_usb2_work(struct work_struct 
*work)
 work);
 
if (ch->extcon_host) {
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
} else {
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
}
 }
 
-- 
1.9.1

[PATCH v2 1/2] phy: rcar-gen3-usb2: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()

Signed-off-by: Chanwoo Choi 
Acked-by: Yoshihiro Shimoda 
---
 drivers/phy/phy-rcar-gen3-usb2.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index c63da1b955c1..54a83675f0a8 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -94,11 +94,11 @@ static void rcar_gen3_phy_usb2_work(struct work_struct 
*work)
 work);
 
if (ch->extcon_host) {
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
} else {
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
+   extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
}
 }
 
-- 
1.9.1

[PATCH v2 0/2] phy: Replace the deprecated extcon API

[Chanwoo Choi]

This patches just replace the deprecated extcon API without any change
of extcon operation and use the resource-managed function for
extcon_register_notifier().

The new extcon API instead of deprecated API.
- extcon_set_cable_state_() -> extcon_set_state_sync();
- extcon_get_cable_state_() -> extcon_get_state();

Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Drop the usb/power-supply/chipidea patches.

Chanwoo Choi (2):
  phy: rcar-gen3-usb2: Replace the deprecated extcon API
  phy: sun4i-usb: Replace the deprecated extcon API

 drivers/phy/phy-rcar-gen3-usb2.c | 8 
 drivers/phy/phy-sun4i-usb.c  | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH v2 0/2] phy: Replace the deprecated extcon API

[Chanwoo Choi]

This patches just replace the deprecated extcon API without any change
of extcon operation and use the resource-managed function for
extcon_register_notifier().

The new extcon API instead of deprecated API.
- extcon_set_cable_state_() -> extcon_set_state_sync();
- extcon_get_cable_state_() -> extcon_get_state();

Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Drop the usb/power-supply/chipidea patches.

Chanwoo Choi (2):
  phy: rcar-gen3-usb2: Replace the deprecated extcon API
  phy: sun4i-usb: Replace the deprecated extcon API

 drivers/phy/phy-rcar-gen3-usb2.c | 8 
 drivers/phy/phy-sun4i-usb.c  | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH v2 6/6] usb: renesas_usbhs: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Cc: Rob Herring 
Cc: Geert Uytterhoeven 
Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
Acked-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index 012a37aa3e0d..623c51300393 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -389,7 +389,7 @@ static void usbhsc_hotplug(struct usbhs_priv *priv)
 
if (enable && !mod) {
if (priv->edev) {
-   cable = extcon_get_cable_state_(priv->edev, 
EXTCON_USB_HOST);
+   cable = extcon_get_state(priv->edev, EXTCON_USB_HOST);
if ((cable > 0 && id != USBHS_HOST) ||
(!cable && id != USBHS_GADGET)) {
dev_info(>dev,
-- 
1.9.1

[PATCH v2 2/2] phy: sun4i-usb: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()

Cc: Kishon Vijay Abraham I 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Signed-off-by: Chanwoo Choi 
---
 drivers/phy/phy-sun4i-usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bf28a0fdd569..eae171e18043 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -534,7 +534,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
mutex_unlock(>mutex);
 
if (id_notify) {
-   extcon_set_cable_state_(data->extcon, EXTCON_USB_HOST,
+   extcon_set_state_sync(data->extcon, EXTCON_USB_HOST,
!id_det);
/* When leaving host mode force end the session here */
if (force_session_end && id_det == 1) {
@@ -547,7 +547,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
}
 
if (vbus_notify)
-   extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
+   extcon_set_state_sync(data->extcon, EXTCON_USB, vbus_det);
 
if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, >detect, POLL_TIME);
-- 
1.9.1

[PATCH v2 6/6] usb: renesas_usbhs: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Cc: Rob Herring 
Cc: Geert Uytterhoeven 
Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
Acked-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index 012a37aa3e0d..623c51300393 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -389,7 +389,7 @@ static void usbhsc_hotplug(struct usbhs_priv *priv)
 
if (enable && !mod) {
if (priv->edev) {
-   cable = extcon_get_cable_state_(priv->edev, 
EXTCON_USB_HOST);
+   cable = extcon_get_state(priv->edev, EXTCON_USB_HOST);
if ((cable > 0 && id != USBHS_HOST) ||
(!cable && id != USBHS_GADGET)) {
dev_info(>dev,
-- 
1.9.1

[PATCH v2 2/2] phy: sun4i-usb: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()

Cc: Kishon Vijay Abraham I 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Signed-off-by: Chanwoo Choi 
---
 drivers/phy/phy-sun4i-usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bf28a0fdd569..eae171e18043 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -534,7 +534,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
mutex_unlock(>mutex);
 
if (id_notify) {
-   extcon_set_cable_state_(data->extcon, EXTCON_USB_HOST,
+   extcon_set_state_sync(data->extcon, EXTCON_USB_HOST,
!id_det);
/* When leaving host mode force end the session here */
if (force_session_end && id_det == 1) {
@@ -547,7 +547,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
}
 
if (vbus_notify)
-   extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
+   extcon_set_state_sync(data->extcon, EXTCON_USB, vbus_det);
 
if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, >detect, POLL_TIME);
-- 
1.9.1

[PATCH v2 4/6] usb: phy: qcom-8x16-usb: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-qcom-8x16-usb.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c 
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index d8593adb3621..fdf686398772 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -187,7 +187,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
 
-   state = extcon_get_cable_state_(qphy->vbus_edev, EXTCON_USB);
+   state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -316,23 +316,20 @@ static int phy_8x16_probe(struct platform_device *pdev)
goto off_clks;
 
qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
-   ret = extcon_register_notifier(qphy->vbus_edev, EXTCON_USB,
-  >vbus_notify);
+   ret = devm_extcon_register_notifier(>dev, qphy->vbus_edev,
+   EXTCON_USB, >vbus_notify);
if (ret < 0)
goto off_power;
 
ret = usb_add_phy_dev(>phy);
if (ret)
-   goto off_extcon;
+   goto off_power;
 
qphy->reboot_notify.notifier_call = phy_8x16_reboot_notify;
register_reboot_notifier(>reboot_notify);
 
return 0;
 
-off_extcon:
-   extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
-  >vbus_notify);
 off_power:
regulator_bulk_disable(ARRAY_SIZE(qphy->regulator), qphy->regulator);
 off_clks:
@@ -347,8 +344,6 @@ static int phy_8x16_remove(struct platform_device *pdev)
struct phy_8x16 *qphy = platform_get_drvdata(pdev);
 
unregister_reboot_notifier(>reboot_notify);
-   extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
-  >vbus_notify);
 
/*
 * Ensure that D+/D- lines are routed to uB connector, so
-- 
1.9.1

[PATCH v2 0/6] usb: Replace the deprecated extcon API

[Chanwoo Choi]

This patches just replace the deprecated extcon API without any change
of extcon operation and use the resource-managed function for
extcon_register_notifier().

The new extcon API instead of deprecated API.
- extcon_set_cable_state_() -> extcon_set_state_sync();
- extcon_get_cable_state_() -> extcon_get_state();

Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Add acked-by tag from usb maintainer and reviewer.
- Drop the phy/power-supply/chipidea patches.

Chanwoo Choi (6):
  usb: dwc3: omap: Replace the extcon API
  usb: phy: msm: Replace the extcon API
  usb: phy: omap-otg: Replace the extcon API
  usb: phy: qcom-8x16-usb: Replace the extcon API
  usb: phy: tahvo: Replace the deprecated extcon API
  usb: renesas_usbhs: Replace the deprecated extcon API

 drivers/usb/dwc3/dwc3-omap.c| 20 +++-
 drivers/usb/phy/phy-msm-usb.c   | 33 +++--
 drivers/usb/phy/phy-omap-otg.c  | 24 ++--
 drivers/usb/phy/phy-qcom-8x16-usb.c | 13 -
 drivers/usb/phy/phy-tahvo.c | 10 +-
 drivers/usb/renesas_usbhs/common.c  |  2 +-
 6 files changed, 34 insertions(+), 68 deletions(-)

-- 
1.9.1

[PATCH v2 4/6] usb: phy: qcom-8x16-usb: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-qcom-8x16-usb.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c 
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index d8593adb3621..fdf686398772 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -187,7 +187,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
 
-   state = extcon_get_cable_state_(qphy->vbus_edev, EXTCON_USB);
+   state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -316,23 +316,20 @@ static int phy_8x16_probe(struct platform_device *pdev)
goto off_clks;
 
qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
-   ret = extcon_register_notifier(qphy->vbus_edev, EXTCON_USB,
-  >vbus_notify);
+   ret = devm_extcon_register_notifier(>dev, qphy->vbus_edev,
+   EXTCON_USB, >vbus_notify);
if (ret < 0)
goto off_power;
 
ret = usb_add_phy_dev(>phy);
if (ret)
-   goto off_extcon;
+   goto off_power;
 
qphy->reboot_notify.notifier_call = phy_8x16_reboot_notify;
register_reboot_notifier(>reboot_notify);
 
return 0;
 
-off_extcon:
-   extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
-  >vbus_notify);
 off_power:
regulator_bulk_disable(ARRAY_SIZE(qphy->regulator), qphy->regulator);
 off_clks:
@@ -347,8 +344,6 @@ static int phy_8x16_remove(struct platform_device *pdev)
struct phy_8x16 *qphy = platform_get_drvdata(pdev);
 
unregister_reboot_notifier(>reboot_notify);
-   extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
-  >vbus_notify);
 
/*
 * Ensure that D+/D- lines are routed to uB connector, so
-- 
1.9.1

[PATCH v2 0/6] usb: Replace the deprecated extcon API

[Chanwoo Choi]

This patches just replace the deprecated extcon API without any change
of extcon operation and use the resource-managed function for
extcon_register_notifier().

The new extcon API instead of deprecated API.
- extcon_set_cable_state_() -> extcon_set_state_sync();
- extcon_get_cable_state_() -> extcon_get_state();

Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Add acked-by tag from usb maintainer and reviewer.
- Drop the phy/power-supply/chipidea patches.

Chanwoo Choi (6):
  usb: dwc3: omap: Replace the extcon API
  usb: phy: msm: Replace the extcon API
  usb: phy: omap-otg: Replace the extcon API
  usb: phy: qcom-8x16-usb: Replace the extcon API
  usb: phy: tahvo: Replace the deprecated extcon API
  usb: renesas_usbhs: Replace the deprecated extcon API

 drivers/usb/dwc3/dwc3-omap.c| 20 +++-
 drivers/usb/phy/phy-msm-usb.c   | 33 +++--
 drivers/usb/phy/phy-omap-otg.c  | 24 ++--
 drivers/usb/phy/phy-qcom-8x16-usb.c | 13 -
 drivers/usb/phy/phy-tahvo.c | 10 +-
 drivers/usb/renesas_usbhs/common.c  |  2 +-
 6 files changed, 34 insertions(+), 68 deletions(-)

-- 
1.9.1

[PATCH v2 1/6] usb: dwc3: omap: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-omap.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc9b634..2d2e9aa1db08 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -425,20 +425,20 @@ static int dwc3_omap_extcon_register(struct dwc3_omap 
*omap)
}
 
omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
-   ret = extcon_register_notifier(edev, EXTCON_USB,
-   >vbus_nb);
+   ret = devm_extcon_register_notifier(omap->dev, edev,
+   EXTCON_USB, >vbus_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for 
USB\n");
 
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
-   ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
-   >id_nb);
+   ret = devm_extcon_register_notifier(omap->dev, edev,
+   EXTCON_USB_HOST, >id_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for 
USB-HOST\n");
 
-   if (extcon_get_cable_state_(edev, EXTCON_USB) == true)
+   if (extcon_get_state(edev, EXTCON_USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
-   if (extcon_get_cable_state_(edev, EXTCON_USB_HOST) == true)
+   if (extcon_get_state(edev, EXTCON_USB_HOST) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
 
omap->edev = edev;
@@ -527,17 +527,13 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(>dev, "failed to create dwc3 core\n");
-   goto err2;
+   goto err1;
}
 
dwc3_omap_enable_irqs(omap);
 
return 0;
 
-err2:
-   extcon_unregister_notifier(omap->edev, EXTCON_USB, >vbus_nb);
-   extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, >id_nb);
-
 err1:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -549,8 +545,6 @@ static int dwc3_omap_remove(struct platform_device *pdev)
 {
struct dwc3_omap*omap = platform_get_drvdata(pdev);
 
-   extcon_unregister_notifier(omap->edev, EXTCON_USB, >vbus_nb);
-   extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, >id_nb);
dwc3_omap_disable_irqs(omap);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(>dev);
-- 
1.9.1

1f6e761378: RIP:call_usermodehelper_exec_work

[kernel test robot]

FYI, we noticed the following commit:

commit: 1f6e761378c2e6dcf1b12ee7d54a0ef799c2b32e ("Make 
call_usermodehelper_exec possible to set namespaces")
url: 
https://github.com/0day-ci/linux/commits/Cao-Shufeng/Make-core_pattern-support-namespace/20161207-024824


in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 320M

caused below changes:


+-+++
| | 
bc3913a537 | 1f6e761378 |
+-+++
| boot_successes  | 
484| 81 |
| boot_failures   | 
1513   | 37 |
| invoked_oom-killer:gfp_mask=0x  | 
1513   ||
| Mem-Info| 
1513   ||
| BUG:unable_to_handle_kernel | 
56 ||
| Oops| 
56 ||
| RIP:copy_process| 
42 ||
| Kernel_panic-not_syncing:Fatal_exception| 
108| 36 |
| general_protection_fault:#[##]SMP   | 
61 | 36 |
| RIP:__lock_acquire  | 
39 ||
| RIP:radix_tree_load_root| 
4  ||
| RIP:__remove_shared_vm_struct   | 
28 ||
| Out_of_memory:Kill_process  | 
2  ||
| BUG_filp(Tainted:G_D):Poison_overwritten| 
2  ||
| INFO:#-#.First_byte#instead_of  | 
3  ||
| INFO:Allocated_in_get_empty_filp_age=#cpu=#pid= | 
3  ||
| INFO:Freed_in_file_free_rcu_age=#cpu=#pid=  | 
3  ||
| INFO:Slab#objects=#used=#fp=0x(null)flags=  | 
3  ||
| INFO:Object#@offset=#fp=0x(null)| 
1  ||
| INFO:Object#@offset=#fp=| 
2  ||
| BUG_filp(Not_tainted):Poison_overwritten| 
1  ||
| RIP:down_write  | 
1  ||
| page_allocation_failure:order:#,mode:#(GFP_ATOMIC|__GFP_COMP|__GFP_NOTRACK) | 
3  ||
| RIP:call_usermodehelper_exec_work   | 
0  | 36 |
| BUG:kernel_reboot-without-warning_in_test_stage | 
0  | 1  |
+-+++



[1.016008] ACPI: bus type PCI registered
[1.018564] dca service started, version 1.12.1
[1.020508] PCI: Using configuration type 1 for base access
[1.119145] general protection fault:  [#1] SMP
[1.120926] Modules linked in:
[1.122422] CPU: 1 PID: 18 Comm: kworker/u4:1 Not tainted 
4.9.0-rc8-00052-g1f6e761 #82
[1.125729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[1.129199] Workqueue: events_unbound call_usermodehelper_exec_work
[1.131284] task: 880011e48040 task.stack: c916
[1.133244] RIP: 0010:[]  [] 
call_usermodehelper_exec_work+0xad/0xc6
[1.136621] RSP: :c9163d60  EFLAGS: 00010202
[1.138372] RAX: 6b6b6b6b6b6b6b6b RBX: 88001185a848 RCX: c9163ba8
[1.140474] RDX: 0001 RSI: 880011e488d8 RDI: 88001185a848
[1.143019] RBP: c9163d78 R08: 86f52214 R09: 0001
[1.145686] R10: c9163c28 R11: 810ccb2e R12: 0197
[1.148246] R13: 880012425d28 R14: 0001 R15: 880011d88100
[1.150764] FS:  () GS:880012c0() 
knlGS:
[1.152975] CS:  0010 DS:  ES:  CR0: 80050033
[1.154366] CR2: c915c000 CR3: 0241e000 CR4: 06e0
[1.155924] Stack:
[1.156662]   880011e176b8 88001185a848 
c9163de8
[1.158963]  810be601 

[PATCH v2 1/6] usb: dwc3: omap: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-omap.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc9b634..2d2e9aa1db08 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -425,20 +425,20 @@ static int dwc3_omap_extcon_register(struct dwc3_omap 
*omap)
}
 
omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
-   ret = extcon_register_notifier(edev, EXTCON_USB,
-   >vbus_nb);
+   ret = devm_extcon_register_notifier(omap->dev, edev,
+   EXTCON_USB, >vbus_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for 
USB\n");
 
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
-   ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
-   >id_nb);
+   ret = devm_extcon_register_notifier(omap->dev, edev,
+   EXTCON_USB_HOST, >id_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for 
USB-HOST\n");
 
-   if (extcon_get_cable_state_(edev, EXTCON_USB) == true)
+   if (extcon_get_state(edev, EXTCON_USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
-   if (extcon_get_cable_state_(edev, EXTCON_USB_HOST) == true)
+   if (extcon_get_state(edev, EXTCON_USB_HOST) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
 
omap->edev = edev;
@@ -527,17 +527,13 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(>dev, "failed to create dwc3 core\n");
-   goto err2;
+   goto err1;
}
 
dwc3_omap_enable_irqs(omap);
 
return 0;
 
-err2:
-   extcon_unregister_notifier(omap->edev, EXTCON_USB, >vbus_nb);
-   extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, >id_nb);
-
 err1:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -549,8 +545,6 @@ static int dwc3_omap_remove(struct platform_device *pdev)
 {
struct dwc3_omap*omap = platform_get_drvdata(pdev);
 
-   extcon_unregister_notifier(omap->edev, EXTCON_USB, >vbus_nb);
-   extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, >id_nb);
dwc3_omap_disable_irqs(omap);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(>dev);
-- 
1.9.1

1f6e761378: RIP:call_usermodehelper_exec_work

[kernel test robot]

FYI, we noticed the following commit:

commit: 1f6e761378c2e6dcf1b12ee7d54a0ef799c2b32e ("Make 
call_usermodehelper_exec possible to set namespaces")
url: 
https://github.com/0day-ci/linux/commits/Cao-Shufeng/Make-core_pattern-support-namespace/20161207-024824


in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 320M

caused below changes:


+-+++
| | 
bc3913a537 | 1f6e761378 |
+-+++
| boot_successes  | 
484| 81 |
| boot_failures   | 
1513   | 37 |
| invoked_oom-killer:gfp_mask=0x  | 
1513   ||
| Mem-Info| 
1513   ||
| BUG:unable_to_handle_kernel | 
56 ||
| Oops| 
56 ||
| RIP:copy_process| 
42 ||
| Kernel_panic-not_syncing:Fatal_exception| 
108| 36 |
| general_protection_fault:#[##]SMP   | 
61 | 36 |
| RIP:__lock_acquire  | 
39 ||
| RIP:radix_tree_load_root| 
4  ||
| RIP:__remove_shared_vm_struct   | 
28 ||
| Out_of_memory:Kill_process  | 
2  ||
| BUG_filp(Tainted:G_D):Poison_overwritten| 
2  ||
| INFO:#-#.First_byte#instead_of  | 
3  ||
| INFO:Allocated_in_get_empty_filp_age=#cpu=#pid= | 
3  ||
| INFO:Freed_in_file_free_rcu_age=#cpu=#pid=  | 
3  ||
| INFO:Slab#objects=#used=#fp=0x(null)flags=  | 
3  ||
| INFO:Object#@offset=#fp=0x(null)| 
1  ||
| INFO:Object#@offset=#fp=| 
2  ||
| BUG_filp(Not_tainted):Poison_overwritten| 
1  ||
| RIP:down_write  | 
1  ||
| page_allocation_failure:order:#,mode:#(GFP_ATOMIC|__GFP_COMP|__GFP_NOTRACK) | 
3  ||
| RIP:call_usermodehelper_exec_work   | 
0  | 36 |
| BUG:kernel_reboot-without-warning_in_test_stage | 
0  | 1  |
+-+++



[1.016008] ACPI: bus type PCI registered
[1.018564] dca service started, version 1.12.1
[1.020508] PCI: Using configuration type 1 for base access
[1.119145] general protection fault:  [#1] SMP
[1.120926] Modules linked in:
[1.122422] CPU: 1 PID: 18 Comm: kworker/u4:1 Not tainted 
4.9.0-rc8-00052-g1f6e761 #82
[1.125729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[1.129199] Workqueue: events_unbound call_usermodehelper_exec_work
[1.131284] task: 880011e48040 task.stack: c916
[1.133244] RIP: 0010:[]  [] 
call_usermodehelper_exec_work+0xad/0xc6
[1.136621] RSP: :c9163d60  EFLAGS: 00010202
[1.138372] RAX: 6b6b6b6b6b6b6b6b RBX: 88001185a848 RCX: c9163ba8
[1.140474] RDX: 0001 RSI: 880011e488d8 RDI: 88001185a848
[1.143019] RBP: c9163d78 R08: 86f52214 R09: 0001
[1.145686] R10: c9163c28 R11: 810ccb2e R12: 0197
[1.148246] R13: 880012425d28 R14: 0001 R15: 880011d88100
[1.150764] FS:  () GS:880012c0() 
knlGS:
[1.152975] CS:  0010 DS:  ES:  CR0: 80050033
[1.154366] CR2: c915c000 CR3: 0241e000 CR4: 06e0
[1.155924] Stack:
[1.156662]   880011e176b8 88001185a848 
c9163de8
[1.158963]  810be601 

[PATCH v2 3/6] usb: phy: omap-otg: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-omap-otg.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 6523af4f8f93..800d1d90753d 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -118,19 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->id_nb.notifier_call = omap_otg_id_notifier;
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
 
-   ret = extcon_register_notifier(extcon, EXTCON_USB_HOST, 
_dev->id_nb);
+   ret = devm_extcon_register_notifier(>dev, extcon,
+   EXTCON_USB_HOST, _dev->id_nb);
if (ret)
return ret;
 
-   ret = extcon_register_notifier(extcon, EXTCON_USB, _dev->vbus_nb);
+   ret = devm_extcon_register_notifier(>dev, extcon,
+   EXTCON_USB, _dev->vbus_nb);
if (ret) {
-   extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
-   _dev->id_nb);
return ret;
}
 
-   otg_dev->id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
-   otg_dev->vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
+   otg_dev->id = extcon_get_state(extcon, EXTCON_USB_HOST);
+   otg_dev->vbus = extcon_get_state(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
 
rev = readl(otg_dev->base);
@@ -145,20 +145,8 @@ static int omap_otg_probe(struct platform_device *pdev)
return 0;
 }
 
-static int omap_otg_remove(struct platform_device *pdev)
-{
-   struct otg_device *otg_dev = platform_get_drvdata(pdev);
-   struct extcon_dev *edev = otg_dev->extcon;
-
-   extcon_unregister_notifier(edev, EXTCON_USB_HOST, _dev->id_nb);
-   extcon_unregister_notifier(edev, EXTCON_USB, _dev->vbus_nb);
-
-   return 0;
-}
-
 static struct platform_driver omap_otg_driver = {
.probe  = omap_otg_probe,
-   .remove = omap_otg_remove,
.driver = {
.name   = "omap_otg",
},
-- 
1.9.1

[PATCH v2 5/6] usb: phy: tahvo: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-tahvo.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index ab5d364f6e8c..a31c8682e998 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -121,7 +121,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu->vbus_state;
tu->vbus_state = reg & TAHVO_STAT_VBUS;
if (prev_state != tu->vbus_state) {
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
sysfs_notify(>pt_dev->dev.kobj, NULL, "vbus_state");
}
 }
@@ -130,7 +130,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, true);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, true);
 
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -149,7 +149,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb 
*tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, false);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, false);
 
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -379,9 +379,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
 
/* Set the initial cable state. */
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST,
+   extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST,
   tu->tahvo_mode == TAHVO_MODE_HOST);
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
 
/* Create OTG interface */
tahvo_usb_power_off(tu);
-- 
1.9.1

[PATCH v2 3/6] usb: phy: omap-otg: Replace the extcon API

[Chanwoo Choi]

This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-omap-otg.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 6523af4f8f93..800d1d90753d 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -118,19 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->id_nb.notifier_call = omap_otg_id_notifier;
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
 
-   ret = extcon_register_notifier(extcon, EXTCON_USB_HOST, 
_dev->id_nb);
+   ret = devm_extcon_register_notifier(>dev, extcon,
+   EXTCON_USB_HOST, _dev->id_nb);
if (ret)
return ret;
 
-   ret = extcon_register_notifier(extcon, EXTCON_USB, _dev->vbus_nb);
+   ret = devm_extcon_register_notifier(>dev, extcon,
+   EXTCON_USB, _dev->vbus_nb);
if (ret) {
-   extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
-   _dev->id_nb);
return ret;
}
 
-   otg_dev->id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
-   otg_dev->vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
+   otg_dev->id = extcon_get_state(extcon, EXTCON_USB_HOST);
+   otg_dev->vbus = extcon_get_state(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
 
rev = readl(otg_dev->base);
@@ -145,20 +145,8 @@ static int omap_otg_probe(struct platform_device *pdev)
return 0;
 }
 
-static int omap_otg_remove(struct platform_device *pdev)
-{
-   struct otg_device *otg_dev = platform_get_drvdata(pdev);
-   struct extcon_dev *edev = otg_dev->extcon;
-
-   extcon_unregister_notifier(edev, EXTCON_USB_HOST, _dev->id_nb);
-   extcon_unregister_notifier(edev, EXTCON_USB, _dev->vbus_nb);
-
-   return 0;
-}
-
 static struct platform_driver omap_otg_driver = {
.probe  = omap_otg_probe,
-   .remove = omap_otg_remove,
.driver = {
.name   = "omap_otg",
},
-- 
1.9.1

[PATCH v2 5/6] usb: phy: tahvo: Replace the deprecated extcon API

[Chanwoo Choi]

This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()

Signed-off-by: Chanwoo Choi 
Acked-by: Felipe Balbi 
---
 drivers/usb/phy/phy-tahvo.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index ab5d364f6e8c..a31c8682e998 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -121,7 +121,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu->vbus_state;
tu->vbus_state = reg & TAHVO_STAT_VBUS;
if (prev_state != tu->vbus_state) {
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
sysfs_notify(>pt_dev->dev.kobj, NULL, "vbus_state");
}
 }
@@ -130,7 +130,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, true);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, true);
 
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -149,7 +149,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb 
*tu)
 {
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
 
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, false);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, false);
 
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -379,9 +379,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
 
/* Set the initial cable state. */
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST,
+   extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST,
   tu->tahvo_mode == TAHVO_MODE_HOST);
-   extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+   extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
 
/* Create OTG interface */
tahvo_usb_power_off(tu);
-- 
1.9.1

Re: [PATCH] drm/amd/amdgpu: fix spelling mistake: "comleted" -> "completed"

[Edward O'Callaghan]

Reviewed-by: Edward O'Callaghan 

On 12/30/2016 12:39 PM, Zhou, David(ChunMing) wrote:
> +amd-gfx, patch is Reviewed-by: Chunming Zhou 
> 
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com] 
> Sent: Thursday, December 29, 2016 11:47 PM
> To: Deucher, Alexander ; Koenig, Christian 
> ; David Airlie ; Zhou, 
> David(ChunMing) ; StDenis, Tom ; 
> Liu, Monk ; dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] drm/amd/amdgpu: fix spelling mistake: "comleted" -> 
> "completed"
> 
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in WARN message
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 60bd4af..9ca3167 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2335,7 +2335,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)
>   if (fence) {
>   r = dma_fence_wait(fence, false);
>   if (r) {
> - WARN(r, "recovery from shadow 
> isn't comleted\n");
> + WARN(r, "recovery from shadow 
> isn't completed\n");
>   break;
>   }
>   }
> @@ -2347,7 +2347,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)
>   if (fence) {
>   r = dma_fence_wait(fence, false);
>   if (r)
> - WARN(r, "recovery from shadow isn't 
> comleted\n");
> + WARN(r, "recovery from shadow isn't 
> completed\n");
>   }
>   dma_fence_put(fence);
>   }
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 1/3] introduce memcpy_nocache()

[Al Viro]

On Thu, Dec 29, 2016 at 10:23:15AM -0800, Dan Williams wrote:

> > BTW, your "it's iovec, only non-temporal stores there" logics in
> > arch_copy_from_iter_pmem() is simply wrong - for one thing, unaligned
> > copies will have parts done via normal stores, for another 32bit will
> > _not_ go for non-caching codepath for short copies.  What semantics do
> > we really need there?
> 
> For typical pmem platforms we need to make sure all the writes are on
> the way to memory such than a later sfence can guarantee that all
> previous writes are visible to the platform "ADR" logic.  ADR handles
> flushing memory controller write buffers to media. At a minimum
> arch_copy_from_iter_pmem() needs to trigger a clwb (unordered cache
> line writeback) of each touched cache line if it is not using a cache
> bypassing store.

Um...  Then we do have a problem - nocache variant of uaccess primitives
does *not* guarantee that clwb is redundant.

What about the requirements of e.g. tcp_sendmsg() with its use of
skb_add_data_nocache()?  What warranties do we need there?

Re: [PATCH] drm/amd/amdgpu: fix spelling mistake: "comleted" -> "completed"

[Edward O'Callaghan]

Reviewed-by: Edward O'Callaghan 

On 12/30/2016 12:39 PM, Zhou, David(ChunMing) wrote:
> +amd-gfx, patch is Reviewed-by: Chunming Zhou 
> 
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com] 
> Sent: Thursday, December 29, 2016 11:47 PM
> To: Deucher, Alexander ; Koenig, Christian 
> ; David Airlie ; Zhou, 
> David(ChunMing) ; StDenis, Tom ; 
> Liu, Monk ; dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] drm/amd/amdgpu: fix spelling mistake: "comleted" -> 
> "completed"
> 
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in WARN message
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 60bd4af..9ca3167 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2335,7 +2335,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)
>   if (fence) {
>   r = dma_fence_wait(fence, false);
>   if (r) {
> - WARN(r, "recovery from shadow 
> isn't comleted\n");
> + WARN(r, "recovery from shadow 
> isn't completed\n");
>   break;
>   }
>   }
> @@ -2347,7 +2347,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)
>   if (fence) {
>   r = dma_fence_wait(fence, false);
>   if (r)
> - WARN(r, "recovery from shadow isn't 
> comleted\n");
> + WARN(r, "recovery from shadow isn't 
> completed\n");
>   }
>   dma_fence_put(fence);
>   }
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 1/3] introduce memcpy_nocache()

[Al Viro]

On Thu, Dec 29, 2016 at 10:23:15AM -0800, Dan Williams wrote:

> > BTW, your "it's iovec, only non-temporal stores there" logics in
> > arch_copy_from_iter_pmem() is simply wrong - for one thing, unaligned
> > copies will have parts done via normal stores, for another 32bit will
> > _not_ go for non-caching codepath for short copies.  What semantics do
> > we really need there?
> 
> For typical pmem platforms we need to make sure all the writes are on
> the way to memory such than a later sfence can guarantee that all
> previous writes are visible to the platform "ADR" logic.  ADR handles
> flushing memory controller write buffers to media. At a minimum
> arch_copy_from_iter_pmem() needs to trigger a clwb (unordered cache
> line writeback) of each touched cache line if it is not using a cache
> bypassing store.

Um...  Then we do have a problem - nocache variant of uaccess primitives
does *not* guarantee that clwb is redundant.

What about the requirements of e.g. tcp_sendmsg() with its use of
skb_add_data_nocache()?  What warranties do we need there?

Re: 4.10rc1 ipc locking bug.

[Mike Galbraith]

On Thu, 2016-12-29 at 21:47 -0500, Dave Jones wrote:
> This is a new one for me..
> 
> =
> [ BUG: bad unlock balance detected! ]
> 4.10.0-rc1-think+ #8 Not tainted
> -
> trinity-c47/31138 is trying to release lock (
> [CONT START] &(>lock)->rlock
> [CONT START] ) at:
> [] SYSC_semtimedop+0x97f/0x11d0
> but there are no more locks to release!

This?

From:   Manfred Spraul 
Subject: [PATCH] ipc/sem.c: fix semop()/semop() locking failure
Date:   Sun, 18 Dec 2016 19:38:45 +0100

Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt

The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.

This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout

With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, the call at the syscall return locks
the global spinlock.

The fix is trivial: Use the return value from sem_lock.

Reported-by: dvyu...@google.com
Signed-off-by: Manfred Spraul 
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: d...@stgolabs.net
---
 ipc/sem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid,
}
 
rcu_read_lock();
-   sem_lock(sma, sops, nsops);
+   locknum = sem_lock(sma, sops, nsops);
 
if (!ipc_valid_object(>sem_perm))
goto out_unlock_free;

Re: 4.10rc1 ipc locking bug.

[Mike Galbraith]

On Thu, 2016-12-29 at 21:47 -0500, Dave Jones wrote:
> This is a new one for me..
> 
> =
> [ BUG: bad unlock balance detected! ]
> 4.10.0-rc1-think+ #8 Not tainted
> -
> trinity-c47/31138 is trying to release lock (
> [CONT START] &(>lock)->rlock
> [CONT START] ) at:
> [] SYSC_semtimedop+0x97f/0x11d0
> but there are no more locks to release!

This?

From:   Manfred Spraul 
Subject: [PATCH] ipc/sem.c: fix semop()/semop() locking failure
Date:   Sun, 18 Dec 2016 19:38:45 +0100

Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt

The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.

This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout

With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, the call at the syscall return locks
the global spinlock.

The fix is trivial: Use the return value from sem_lock.

Reported-by: dvyu...@google.com
Signed-off-by: Manfred Spraul 
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: d...@stgolabs.net
---
 ipc/sem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid,
}
 
rcu_read_lock();
-   sem_lock(sma, sops, nsops);
+   locknum = sem_lock(sma, sops, nsops);
 
if (!ipc_valid_object(>sem_perm))
goto out_unlock_free;

ppp_generic.c crash. linux 4.4.y

[bmajal222]

Dear Sir,

I am having lots of trouble PPP crashing in the kernel.
I am using ubuntu 16.04 based on linux kernel 4.4.y.

The BUG is already fixed in 4.8.y branch and 3.12.y branch.
I have included the link here for your reference.

Please import this bug-fix patch in to 4.4.y branch.

BUG:
ppp: defer netns reference release for ppp channel

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.12.y=e550951c8b8b1acb30e31c22ac3404648c9aa213

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.8.y=205e1e255c479f3fd77446415706463b282f94e4

Regards,
BMajal

ppp_generic.c crash. linux 4.4.y

[bmajal222]

Dear Sir,

I am having lots of trouble PPP crashing in the kernel.
I am using ubuntu 16.04 based on linux kernel 4.4.y.

The BUG is already fixed in 4.8.y branch and 3.12.y branch.
I have included the link here for your reference.

Please import this bug-fix patch in to 4.4.y branch.

BUG:
ppp: defer netns reference release for ppp channel

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.12.y=e550951c8b8b1acb30e31c22ac3404648c9aa213

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.8.y=205e1e255c479f3fd77446415706463b282f94e4

Regards,
BMajal

Re: [PATCH] ceph: fix spelling mistake: "enabing" -> "enabling"

[Yan, Zheng]

On Fri, Dec 30, 2016 at 4:19 AM, Colin King  wrote:
> From: Colin Ian King 
>
> trivial fix to spelling mistake in debug message
>
> Signed-off-by: Colin Ian King 
> ---
>  fs/ceph/cache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
> index 5bc5d37..4e7421c 100644
> --- a/fs/ceph/cache.c
> +++ b/fs/ceph/cache.c
> @@ -234,7 +234,7 @@ void ceph_fscache_file_set_cookie(struct inode *inode, 
> struct file *filp)
> fscache_enable_cookie(ci->fscache, ceph_fscache_can_enable,
> inode);
> if (fscache_cookie_enabled(ci->fscache)) {
> -   dout("fscache_file_set_cookie %p %p enabing cache\n",
> +   dout("fscache_file_set_cookie %p %p enabling cache\n",
>  inode, filp);
> }
> }
> --
> 2.10.2

Applied, thanks

Yan, Zheng

>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ceph: fix spelling mistake: "enabing" -> "enabling"

[Yan, Zheng]

On Fri, Dec 30, 2016 at 4:19 AM, Colin King  wrote:
> From: Colin Ian King 
>
> trivial fix to spelling mistake in debug message
>
> Signed-off-by: Colin Ian King 
> ---
>  fs/ceph/cache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
> index 5bc5d37..4e7421c 100644
> --- a/fs/ceph/cache.c
> +++ b/fs/ceph/cache.c
> @@ -234,7 +234,7 @@ void ceph_fscache_file_set_cookie(struct inode *inode, 
> struct file *filp)
> fscache_enable_cookie(ci->fscache, ceph_fscache_can_enable,
> inode);
> if (fscache_cookie_enabled(ci->fscache)) {
> -   dout("fscache_file_set_cookie %p %p enabing cache\n",
> +   dout("fscache_file_set_cookie %p %p enabling cache\n",
>  inode, filp);
> }
> }
> --
> 2.10.2

Applied, thanks

Yan, Zheng

>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] net: dsa: Implement ndo_get_phys_port_id

[David Miller]

From: Florian Fainelli 
Date: Thu, 29 Dec 2016 14:20:56 -0800

> Implement ndo_get_phys_port_id() by returning the physical port number
> of the switch this per-port DSA created network interface corresponds
> to.
> 
> Signed-off-by: Florian Fainelli 

Applied, thanks.

Re: [PATCH net-next] net: dsa: Implement ndo_get_phys_port_id

[David Miller]

From: Florian Fainelli 
Date: Thu, 29 Dec 2016 14:20:56 -0800

> Implement ndo_get_phys_port_id() by returning the physical port number
> of the switch this per-port DSA created network interface corresponds
> to.
> 
> Signed-off-by: Florian Fainelli 

Applied, thanks.