[PATCH] tools: Fix str_error_r() Werror=restrict build

[Sergey Senozhatsky]

Commit c8b5f2c96d1bf6c ("tools: Introduce str_error_r()") added
an str_error_r() wrapper which makes gcc8 unhappy due to
restrict-qualified parameter aliasing violation:

../lib/str_error_r.c: In function ‘str_error_r’:
../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
parameter aliases with argument 5 [-Werror=restrict]
   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, 
buf, buflen, err);
   ^~~~
cc1: all warnings being treated as errors

Workaround that aliasing error by creating an additional stack
variable which holds the buf pointer value we passed to strerror_r().

Signed-off-by: Sergey Senozhatsky 
---
 tools/lib/str_error_r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/lib/str_error_r.c b/tools/lib/str_error_r.c
index d6d65537b0d9..11c3425f272b 100644
--- a/tools/lib/str_error_r.c
+++ b/tools/lib/str_error_r.c
@@ -21,7 +21,12 @@
 char *str_error_r(int errnum, char *buf, size_t buflen)
 {
int err = strerror_r(errnum, buf, buflen);
-   if (err)
-   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, 
%zd)=%d", errnum, buf, buflen, err);
+   if (err) {
+   char *err_buf = buf;
+
+   snprintf(err_buf, buflen,
+"INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d",
+errnum, buf, buflen, err);
+   }
return buf;
 }
-- 
2.16.2

[PATCH] tools: Fix str_error_r() Werror=restrict build

[Sergey Senozhatsky]

Commit c8b5f2c96d1bf6c ("tools: Introduce str_error_r()") added
an str_error_r() wrapper which makes gcc8 unhappy due to
restrict-qualified parameter aliasing violation:

../lib/str_error_r.c: In function ‘str_error_r’:
../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
parameter aliases with argument 5 [-Werror=restrict]
   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, 
buf, buflen, err);
   ^~~~
cc1: all warnings being treated as errors

Workaround that aliasing error by creating an additional stack
variable which holds the buf pointer value we passed to strerror_r().

Signed-off-by: Sergey Senozhatsky 
---
 tools/lib/str_error_r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/lib/str_error_r.c b/tools/lib/str_error_r.c
index d6d65537b0d9..11c3425f272b 100644
--- a/tools/lib/str_error_r.c
+++ b/tools/lib/str_error_r.c
@@ -21,7 +21,12 @@
 char *str_error_r(int errnum, char *buf, size_t buflen)
 {
int err = strerror_r(errnum, buf, buflen);
-   if (err)
-   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, 
%zd)=%d", errnum, buf, buflen, err);
+   if (err) {
+   char *err_buf = buf;
+
+   snprintf(err_buf, buflen,
+"INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d",
+errnum, buf, buflen, err);
+   }
return buf;
 }
-- 
2.16.2

RE: [PATCH] vmbus: use put_device() if device_register fail

[KY Srinivasan]

> -Original Message-
> From: Michael Kelley (EOSG)
> Sent: Sunday, March 18, 2018 8:40 PM
> To: KY Srinivasan ; Arvind Yadav
> ; Stephen Hemminger
> ; Haiyang Zhang 
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] vmbus: use put_device() if device_register fail
> 
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf
> > Of KY Srinivasan
> > Sent: Sunday, March 18, 2018 8:02 PM
> > To: Arvind Yadav ; Stephen Hemminger
> > ; Haiyang Zhang 
> > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> > Subject: RE: [PATCH] vmbus: use put_device() if device_register fail
> >
> > > -Original Message-
> > > From: devel  On
> Behalf
> > > Of Arvind Yadav
> > > Sent: Saturday, March 17, 2018 11:48 PM
> > > To: Stephen Hemminger ; Haiyang Zhang
> > > 
> > > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> > > Subject: [PATCH] vmbus: use put_device() if device_register fail
> > >
> > > if device_register() returned an error. Always use put_device()
> > > to give up the reference initialized.
> > >
> > > Signed-off-by: Arvind Yadav 
> > > ---
> > >  drivers/hv/vmbus_drv.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > > index bc65c4d..25da2f3 100644
> > > --- a/drivers/hv/vmbus_drv.c
> > > +++ b/drivers/hv/vmbus_drv.c
> > > @@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
> > > *child_device_obj)
> > >   ret = device_register(_device_obj->device);
> > >   if (ret) {
> > >   pr_err("Unable to register child device\n");
> > > + put_device(_device_obj->device);
> >
> > If the registration failed; we would not have acquired the reference on the
> device and so
> > we should not be dropping the reference in the failure path.
> 
> Looking at the code for device_register() and its constituent parts
> device_initialize() and device_add(), Arvind is correct.  device_initialize()
> creates the object with a reference count of 1.  device_add() does not
> decrement that reference count or free the object, even if it fails.  The
> comments for device_register() call this out as well.

Yes; agreed. I will take this patch.

K. Y
> 
> Michael
> 
> >
> > K. Y
> > >   return ret;
> > >   }
> > >
> > > --
> > > 2.7.4

RE: [PATCH] vmbus: use put_device() if device_register fail

[KY Srinivasan]

> -Original Message-
> From: Michael Kelley (EOSG)
> Sent: Sunday, March 18, 2018 8:40 PM
> To: KY Srinivasan ; Arvind Yadav
> ; Stephen Hemminger
> ; Haiyang Zhang 
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] vmbus: use put_device() if device_register fail
> 
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf
> > Of KY Srinivasan
> > Sent: Sunday, March 18, 2018 8:02 PM
> > To: Arvind Yadav ; Stephen Hemminger
> > ; Haiyang Zhang 
> > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> > Subject: RE: [PATCH] vmbus: use put_device() if device_register fail
> >
> > > -Original Message-
> > > From: devel  On
> Behalf
> > > Of Arvind Yadav
> > > Sent: Saturday, March 17, 2018 11:48 PM
> > > To: Stephen Hemminger ; Haiyang Zhang
> > > 
> > > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> > > Subject: [PATCH] vmbus: use put_device() if device_register fail
> > >
> > > if device_register() returned an error. Always use put_device()
> > > to give up the reference initialized.
> > >
> > > Signed-off-by: Arvind Yadav 
> > > ---
> > >  drivers/hv/vmbus_drv.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > > index bc65c4d..25da2f3 100644
> > > --- a/drivers/hv/vmbus_drv.c
> > > +++ b/drivers/hv/vmbus_drv.c
> > > @@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
> > > *child_device_obj)
> > >   ret = device_register(_device_obj->device);
> > >   if (ret) {
> > >   pr_err("Unable to register child device\n");
> > > + put_device(_device_obj->device);
> >
> > If the registration failed; we would not have acquired the reference on the
> device and so
> > we should not be dropping the reference in the failure path.
> 
> Looking at the code for device_register() and its constituent parts
> device_initialize() and device_add(), Arvind is correct.  device_initialize()
> creates the object with a reference count of 1.  device_add() does not
> decrement that reference count or free the object, even if it fails.  The
> comments for device_register() call this out as well.

Yes; agreed. I will take this patch.

K. Y
> 
> Michael
> 
> >
> > K. Y
> > >   return ret;
> > >   }
> > >
> > > --
> > > 2.7.4

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

[Michael Ellerman]

Dave Hansen  writes:

> On 03/17/2018 02:12 AM, Thomas Gleixner wrote:
>>> This is a bit nicer than what Ram proposed because it is simpler
>>> and removes special-casing for pkey 0.  On the other hand, it does
>>> allow applciations to pkey_free() pkey-0, but that's just a silly
>>> thing to do, so we are not going to protect against it.
>> What's the consequence of that? Application crashing and burning itself or
>> something more subtle?
>
> You would have to:
>
>   pkey_free(0)
>   ... later
>   new_key = pkey_alloc();
>   // now new_key=0
>   pkey_deny_access(new_key); // or whatever
>
> At which point most apps would probably croak because its stack is
> inaccessible.  The free itself does not make the key inaccessible, *but*
> we could also do that within the existing ABI if we want.  I think I
> called out that behavior as undefined in the manpage.

Allowing key 0 to be freed introduces some pretty weird API IMHO. For
example this part of the manpage:

  An application should not call pkey_free() on any protection key
  which has been assigned to an address range by pkey_mprotect(2)
  and which is still in use. The behavior in this case is undefined
  and may result in an error.

You basically can't avoid hitting undefined behaviour with pkey 0,
because even if you never assigned pkey 0 to an address range, it *is
still in use* - because it's used as the default key for every address
range that doesn't have another key.

So I don't really think it makes sense to allow pkey 0 to be freed. But
I won't die in a ditch over it, I just look forward to a manpage update
that can sensibly describe the semantics.

cheers

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

[Michael Ellerman]

Dave Hansen  writes:

> On 03/17/2018 02:12 AM, Thomas Gleixner wrote:
>>> This is a bit nicer than what Ram proposed because it is simpler
>>> and removes special-casing for pkey 0.  On the other hand, it does
>>> allow applciations to pkey_free() pkey-0, but that's just a silly
>>> thing to do, so we are not going to protect against it.
>> What's the consequence of that? Application crashing and burning itself or
>> something more subtle?
>
> You would have to:
>
>   pkey_free(0)
>   ... later
>   new_key = pkey_alloc();
>   // now new_key=0
>   pkey_deny_access(new_key); // or whatever
>
> At which point most apps would probably croak because its stack is
> inaccessible.  The free itself does not make the key inaccessible, *but*
> we could also do that within the existing ABI if we want.  I think I
> called out that behavior as undefined in the manpage.

Allowing key 0 to be freed introduces some pretty weird API IMHO. For
example this part of the manpage:

  An application should not call pkey_free() on any protection key
  which has been assigned to an address range by pkey_mprotect(2)
  and which is still in use. The behavior in this case is undefined
  and may result in an error.

You basically can't avoid hitting undefined behaviour with pkey 0,
because even if you never assigned pkey 0 to an address range, it *is
still in use* - because it's used as the default key for every address
range that doesn't have another key.

So I don't really think it makes sense to allow pkey 0 to be freed. But
I won't die in a ditch over it, I just look forward to a manpage update
that can sensibly describe the semantics.

cheers

Re: linux-next: build warning after merge of the crypto tree

[Harsh Jain]

On 19-03-2018 06:34, Stephen Rothwell wrote:
> Hi Herbert,
>
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from drivers/crypto/chelsio/chcr_ipsec.c:66:0:
> drivers/crypto/chelsio/chcr_crypto.h:343:12: warning: 'chcr_ahash_continue' 
> declared 'static' but never defined [-Wunused-function]
>  static int chcr_ahash_continue(struct ahash_request *req);
> ^~~
>
> Introduced by commit
>
>   5110e65536f3 ("crypto: chelsio -Split Hash requests for large scatter 
> gather list")
>
Hi Stephen/Herbert,

I will submit the fix to cryptodev tree.

Thanks & Regards
Harsh Jain

Re: linux-next: build warning after merge of the crypto tree

[Harsh Jain]

On 19-03-2018 06:34, Stephen Rothwell wrote:
> Hi Herbert,
>
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from drivers/crypto/chelsio/chcr_ipsec.c:66:0:
> drivers/crypto/chelsio/chcr_crypto.h:343:12: warning: 'chcr_ahash_continue' 
> declared 'static' but never defined [-Wunused-function]
>  static int chcr_ahash_continue(struct ahash_request *req);
> ^~~
>
> Introduced by commit
>
>   5110e65536f3 ("crypto: chelsio -Split Hash requests for large scatter 
> gather list")
>
Hi Stephen/Herbert,

I will submit the fix to cryptodev tree.

Thanks & Regards
Harsh Jain

Re: [PATCH 4.15 000/128] 4.15.11-stable review

[Guenter Roeck]

On 03/18/2018 08:39 PM, Dan Rue wrote:

On Sun, Mar 18, 2018 at 12:15:23PM +0100, Greg Kroah-Hartman wrote:

On Sun, Mar 18, 2018 at 11:25:26AM +0100, Greg Kroah-Hartman wrote:

On Fri, Mar 16, 2018 at 04:22:21PM +0100, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.15.11 release.
There are 128 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Mar 18 15:22:57 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc1.gz


-rc2 is out to fix a build error on some configs:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc2.gz


And -rc3 is out that at least builds properly:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc3.gz


Sorry to say, this one doesn't build properly either.

I tested the previous build issue on arm64 only, but arm32 is still
failing on 4.14/4.15 due to the following:

 07f498834a53 ("clk: ti: clkctrl: add support for retrying failed init")

I'll reply to the patch directly as well.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

...

../drivers/clk/ti/clkctrl.c: In function ‘_ti_omap4_clkctrl_setup’:
../drivers/clk/ti/clkctrl.c:497:27: error: passing argument 2 of 
‘ti_clk_retry_init’ from incompatible pointer type
  [-Werror=incompatible-pointer-types]
ti_clk_retry_init(node, provider, _clkctrl_add_provider);
^~~~
In file included from ../drivers/clk/ti/clkctrl.c:24:0:
../drivers/clk/ti/clock.h:265:5: note: expected ‘struct clk_hw *’ but argument 
is of type ‘struct omap_clkctrl_prov
ider *’
  int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
  ^ 
../drivers/clk/ti/clkctrl.c:497:37: error: 
passing argument 3 of ‘ti_clk_retry_init’ from incompatible pointer type
  [-Werror=incompatible-pointer-types]
ti_clk_retry_init(node, provider, _clkctrl_add_provider);
  ^
In file included from ../drivers/clk/ti/clkctrl.c:24:0: 
   ../drivers/clk/ti/clock.h:265:5: note: 
expected ‘ti_of_clk_init_cb_t {aka void (*)(struct clk_hw *, struct device_n
ode *)}’ but argument is of type ‘void (*)(void *, struct device_node *)’
  int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
  ^
cc1: some warnings being treated as errors
make[4]: *** [../scripts/Makefile.build:329: drivers/clk/ti/clkctrl.o] Error 1
make[3]: *** [../scripts/Makefile.build:587: drivers/clk/ti] Error 2
make[2]: *** [../scripts/Makefile.build:587: drivers/clk] Error 2
make[1]: *** [/home/drue/src/linux/4.14-rc/Makefile:1031: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.14-rc/build-arm'
make: *** [Makefile:146: sub-make] Error 2




You are right. Difference in my build is that my version of gcc doesn't produce
and error but just a warning.

Guenter

Re: [PATCH 4.15 000/128] 4.15.11-stable review

[Guenter Roeck]

On 03/18/2018 08:39 PM, Dan Rue wrote:

On Sun, Mar 18, 2018 at 12:15:23PM +0100, Greg Kroah-Hartman wrote:

On Sun, Mar 18, 2018 at 11:25:26AM +0100, Greg Kroah-Hartman wrote:

On Fri, Mar 16, 2018 at 04:22:21PM +0100, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.15.11 release.
There are 128 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Mar 18 15:22:57 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc1.gz


-rc2 is out to fix a build error on some configs:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc2.gz


And -rc3 is out that at least builds properly:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc3.gz


Sorry to say, this one doesn't build properly either.

I tested the previous build issue on arm64 only, but arm32 is still
failing on 4.14/4.15 due to the following:

 07f498834a53 ("clk: ti: clkctrl: add support for retrying failed init")

I'll reply to the patch directly as well.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

...

../drivers/clk/ti/clkctrl.c: In function ‘_ti_omap4_clkctrl_setup’:
../drivers/clk/ti/clkctrl.c:497:27: error: passing argument 2 of 
‘ti_clk_retry_init’ from incompatible pointer type
  [-Werror=incompatible-pointer-types]
ti_clk_retry_init(node, provider, _clkctrl_add_provider);
^~~~
In file included from ../drivers/clk/ti/clkctrl.c:24:0:
../drivers/clk/ti/clock.h:265:5: note: expected ‘struct clk_hw *’ but argument 
is of type ‘struct omap_clkctrl_prov
ider *’
  int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
  ^ 
../drivers/clk/ti/clkctrl.c:497:37: error: 
passing argument 3 of ‘ti_clk_retry_init’ from incompatible pointer type
  [-Werror=incompatible-pointer-types]
ti_clk_retry_init(node, provider, _clkctrl_add_provider);
  ^
In file included from ../drivers/clk/ti/clkctrl.c:24:0: 
   ../drivers/clk/ti/clock.h:265:5: note: 
expected ‘ti_of_clk_init_cb_t {aka void (*)(struct clk_hw *, struct device_n
ode *)}’ but argument is of type ‘void (*)(void *, struct device_node *)’
  int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
  ^
cc1: some warnings being treated as errors
make[4]: *** [../scripts/Makefile.build:329: drivers/clk/ti/clkctrl.o] Error 1
make[3]: *** [../scripts/Makefile.build:587: drivers/clk/ti] Error 2
make[2]: *** [../scripts/Makefile.build:587: drivers/clk] Error 2
make[1]: *** [/home/drue/src/linux/4.14-rc/Makefile:1031: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.14-rc/build-arm'
make: *** [Makefile:146: sub-make] Error 2




You are right. Difference in my build is that my version of gcc doesn't produce
and error but just a warning.

Guenter

[PATCH v2] staging: media: davinci_vpfe: add error handling on kmalloc failure

[Ji-Hun Kim]

There is no failure checking on the param value which will be allocated
memory by kmalloc. Add a null pointer checking statement. Then goto error:
and return -ENOMEM error code when kmalloc is failed.

Signed-off-by: Ji-Hun Kim 
---
Changes since v1:
  - Return with -ENOMEM directly, instead of goto error: then return.

 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434c..ffcd86d 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1280,6 +1280,9 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
 
params = kmalloc(sizeof(struct ipipe_module_params),
 GFP_KERNEL);
+   if (!params)
+   return -ENOMEM;
+
to = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
@@ -1323,6 +1326,9 @@ static int ipipe_g_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
 
params =  kmalloc(sizeof(struct ipipe_module_params),
GFP_KERNEL);
+   if (!params)
+   return -ENOMEM;
+
from = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
-- 
1.9.1

[PATCH v2] staging: media: davinci_vpfe: add error handling on kmalloc failure

[Ji-Hun Kim]

There is no failure checking on the param value which will be allocated
memory by kmalloc. Add a null pointer checking statement. Then goto error:
and return -ENOMEM error code when kmalloc is failed.

Signed-off-by: Ji-Hun Kim 
---
Changes since v1:
  - Return with -ENOMEM directly, instead of goto error: then return.

 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434c..ffcd86d 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1280,6 +1280,9 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
 
params = kmalloc(sizeof(struct ipipe_module_params),
 GFP_KERNEL);
+   if (!params)
+   return -ENOMEM;
+
to = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
@@ -1323,6 +1326,9 @@ static int ipipe_g_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
 
params =  kmalloc(sizeof(struct ipipe_module_params),
GFP_KERNEL);
+   if (!params)
+   return -ENOMEM;
+
from = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
-- 
1.9.1

RE: [PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

[Madalin-cristian Bucur]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Geert Uytterhoeven
> Sent: Friday, March 16, 2018 3:52 PM
> To: Christoph Hellwig ; Marek Szyprowski
> ; Robin Murphy ;
> Felipe Balbi ; Greg Kroah-Hartman
> ; James E . J . Bottomley
> ; Martin K . Petersen
> ; Andrew Morton  foundation.org>; Mark Brown ; Liam Girdwood
> ; Tejun Heo ; Herbert Xu
> ; David S . Miller ;
> Bartlomiej Zolnierkiewicz ; Stefan Richter
> ; Alan Tull ; Moritz Fischer
> ; Wolfram Sang ; Jonathan Cameron
> ; Joerg Roedel ; Matias Bjorling
> ; Jassi Brar ; Mauro Carvalho
> Chehab ; Ulf Hansson ; David
> Woodhouse ; Brian Norris
> ; Marek Vasut ;
> Cyrille Pitchen ; Boris Brezillon
> ; Richard Weinberger ;
> Kalle Valo ; Ohad Ben-Cohen ;
> Bjorn Andersson ; Eric Anholt ;
> Stefan Wahren 
> Cc: io...@lists.linux-foundation.org; linux-...@vger.kernel.org; linux-
> s...@vger.kernel.org; alsa-de...@alsa-project.org; linux-...@vger.kernel.org;
> linux-cry...@vger.kernel.org; linux-fb...@vger.kernel.org; linux1394-
> de...@lists.sourceforge.net; linux-f...@vger.kernel.org; linux-
> i...@vger.kernel.org; linux-...@vger.kernel.org; linux-bl...@vger.kernel.org;
> linux-me...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> m...@lists.infradead.org; net...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; linux-ser...@vger.kernel.org; linux-
> s...@vger.kernel.org; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; Geert Uytterhoeven 
> Subject: [PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of
> platform dependency
> 
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on
> another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
> 
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
> 
> This simplifies the dependencies, and allows to improve compile-testing.
> 
> Notes:
>   - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
> which does not exist if HAS_DMA=n (Do we need a dummy? The use of
> set_dma_ops() in this driver is questionable),

Hi,

The set_dma_ops() is no longer required in the fsl/fman, I'll send a patch to 
remove it.

Thanks

>   - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
> dependency on HAS_DMA, as they are selected from
> SND_SOC_APQ8016_SBC.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 
> ---
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/lightnvm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
> index 10c08982185a572f..9c03f35d9df113c6 100644
> --- a/drivers/lightnvm/Kconfig
> +++ b/drivers/lightnvm/Kconfig
> @@ -4,7 +4,7 @@
> 
>  menuconfig NVM
>   bool "Open-Channel SSD target support"
> - depends on BLOCK && HAS_DMA && PCI
> + depends on BLOCK && PCI
>   select BLK_DEV_NVME
>   help
> Say Y here to get to enable Open-channel SSDs.
> --
> 2.7.4

RE: [PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

[Madalin-cristian Bucur]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Geert Uytterhoeven
> Sent: Friday, March 16, 2018 3:52 PM
> To: Christoph Hellwig ; Marek Szyprowski
> ; Robin Murphy ;
> Felipe Balbi ; Greg Kroah-Hartman
> ; James E . J . Bottomley
> ; Martin K . Petersen
> ; Andrew Morton  foundation.org>; Mark Brown ; Liam Girdwood
> ; Tejun Heo ; Herbert Xu
> ; David S . Miller ;
> Bartlomiej Zolnierkiewicz ; Stefan Richter
> ; Alan Tull ; Moritz Fischer
> ; Wolfram Sang ; Jonathan Cameron
> ; Joerg Roedel ; Matias Bjorling
> ; Jassi Brar ; Mauro Carvalho
> Chehab ; Ulf Hansson ; David
> Woodhouse ; Brian Norris
> ; Marek Vasut ;
> Cyrille Pitchen ; Boris Brezillon
> ; Richard Weinberger ;
> Kalle Valo ; Ohad Ben-Cohen ;
> Bjorn Andersson ; Eric Anholt ;
> Stefan Wahren 
> Cc: io...@lists.linux-foundation.org; linux-...@vger.kernel.org; linux-
> s...@vger.kernel.org; alsa-de...@alsa-project.org; linux-...@vger.kernel.org;
> linux-cry...@vger.kernel.org; linux-fb...@vger.kernel.org; linux1394-
> de...@lists.sourceforge.net; linux-f...@vger.kernel.org; linux-
> i...@vger.kernel.org; linux-...@vger.kernel.org; linux-bl...@vger.kernel.org;
> linux-me...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> m...@lists.infradead.org; net...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; linux-ser...@vger.kernel.org; linux-
> s...@vger.kernel.org; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; Geert Uytterhoeven 
> Subject: [PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of
> platform dependency
> 
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on
> another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
> 
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
> 
> This simplifies the dependencies, and allows to improve compile-testing.
> 
> Notes:
>   - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
> which does not exist if HAS_DMA=n (Do we need a dummy? The use of
> set_dma_ops() in this driver is questionable),

Hi,

The set_dma_ops() is no longer required in the fsl/fman, I'll send a patch to 
remove it.

Thanks

>   - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
> dependency on HAS_DMA, as they are selected from
> SND_SOC_APQ8016_SBC.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 
> ---
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/lightnvm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
> index 10c08982185a572f..9c03f35d9df113c6 100644
> --- a/drivers/lightnvm/Kconfig
> +++ b/drivers/lightnvm/Kconfig
> @@ -4,7 +4,7 @@
> 
>  menuconfig NVM
>   bool "Open-Channel SSD target support"
> - depends on BLOCK && HAS_DMA && PCI
> + depends on BLOCK && PCI
>   select BLK_DEV_NVME
>   help
> Say Y here to get to enable Open-channel SSDs.
> --
> 2.7.4

[PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

This patch replace list_entry with list_{next/prev}_entry as it makes
the code more clear to read.
Done using coccinelle:

@@
expression e1;
identifier e3;
type t;
@@
(
- list_entry(e1->e3.next,t,e3)
+ list_next_entry(e1,e3)
|
- list_entry(e1->e3.prev,t,e3)
+ list_prev_entry(e1,e3)
)

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/drm_lease.c| 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 1402c0e..4dcfb5f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
break;
 
/* Over */
-   master = list_entry(master->lessee_list.next, struct 
drm_master, lessee_list);
+   master = list_next_entry(master, lessee_list);
}
}
 }
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index e4c8d31..81c3567 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
   nvkm_volt_map(volt, volt->max2_id, clk->temp));
 
for (cstate = start; >head != >list;
-cstate = list_entry(cstate->head.prev, typeof(*cstate), head)) {
+cstate = list_prev_entry(cstate, head)) {
if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
break;
}
-- 
2.7.4

[PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

This patch replace list_entry with list_{next/prev}_entry as it makes
the code more clear to read.
Done using coccinelle:

@@
expression e1;
identifier e3;
type t;
@@
(
- list_entry(e1->e3.next,t,e3)
+ list_next_entry(e1,e3)
|
- list_entry(e1->e3.prev,t,e3)
+ list_prev_entry(e1,e3)
)

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/drm_lease.c| 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 1402c0e..4dcfb5f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
break;
 
/* Over */
-   master = list_entry(master->lessee_list.next, struct 
drm_master, lessee_list);
+   master = list_next_entry(master, lessee_list);
}
}
 }
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index e4c8d31..81c3567 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
   nvkm_volt_map(volt, volt->max2_id, clk->temp));
 
for (cstate = start; >head != >list;
-cstate = list_entry(cstate->head.prev, typeof(*cstate), head)) {
+cstate = list_prev_entry(cstate, head)) {
if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
break;
}
-- 
2.7.4

Re: [PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

[Eric Dumazet]

On Sun, Mar 18, 2018 at 10:14 AM kbuild test robot  wrote:

> Hi Eric,

> Thank you for the patch! Yet something to improve:

> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16-rc5 next-20180316]
> [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/Eric-Dumazet/x86-msr-add-rdmsr_safe_on_cpu_resched-and-use-it-in-msr_read/20180319-001007
> config: i386-randconfig-s1-201811 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
>  # save the attached .config to linux build tree
>  make ARCH=i386

> All errors (new ones prefixed by >>):

> arch/x86/kernel/msr.c: In function 'msr_read':
> >> arch/x86/kernel/msr.c:63:9: error: implicit declaration of function
'rdmsr_safe_on_cpu_resched' [-Werror=implicit-function-declaration]
>err = rdmsr_safe_on_cpu_resched(cpu, reg, [0], [1]);
>  ^
> cc1: some warnings being treated as errors

I guess I will have to add in V2 this missing part :

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index
117a286660c61cf9c10e68f0b48d27e2de17deab..15e220243a4d5e9da524fb7733e23e2766b6eb12
100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -363,6 +363,11 @@ static inline int rdmsr_safe_on_cpu(unsigned int cpu,
u32 msr_no,
  {
 return rdmsr_safe(msr_no, l, h);
  }
+static inline int rdmsr_safe_on_cpu_resched(unsigned int cpu, u32 msr_no,
+   u32 *l, u32 *h)
+{
+   return rdmsr_safe(msr_no, l, h);
+}
  static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 l,
u32 h)
  {
 return wrmsr_safe(msr_no, l, h);

Re: [PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

[Eric Dumazet]

On Sun, Mar 18, 2018 at 10:14 AM kbuild test robot  wrote:

> Hi Eric,

> Thank you for the patch! Yet something to improve:

> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16-rc5 next-20180316]
> [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/Eric-Dumazet/x86-msr-add-rdmsr_safe_on_cpu_resched-and-use-it-in-msr_read/20180319-001007
> config: i386-randconfig-s1-201811 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
>  # save the attached .config to linux build tree
>  make ARCH=i386

> All errors (new ones prefixed by >>):

> arch/x86/kernel/msr.c: In function 'msr_read':
> >> arch/x86/kernel/msr.c:63:9: error: implicit declaration of function
'rdmsr_safe_on_cpu_resched' [-Werror=implicit-function-declaration]
>err = rdmsr_safe_on_cpu_resched(cpu, reg, [0], [1]);
>  ^
> cc1: some warnings being treated as errors

I guess I will have to add in V2 this missing part :

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index
117a286660c61cf9c10e68f0b48d27e2de17deab..15e220243a4d5e9da524fb7733e23e2766b6eb12
100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -363,6 +363,11 @@ static inline int rdmsr_safe_on_cpu(unsigned int cpu,
u32 msr_no,
  {
 return rdmsr_safe(msr_no, l, h);
  }
+static inline int rdmsr_safe_on_cpu_resched(unsigned int cpu, u32 msr_no,
+   u32 *l, u32 *h)
+{
+   return rdmsr_safe(msr_no, l, h);
+}
  static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 l,
u32 h)
  {
 return wrmsr_safe(msr_no, l, h);

Re: [PATCH v2] exec: Set file unwritable before LSM check

[James Morris]

On Fri, 9 Mar 2018, Kees Cook wrote:

> The LSM check should happen after the file has been confirmed to be
> unchanging. Without this, we could have a race between the Time of Check
> (the call to security_kernel_read_file() which could read the file and
> make access policy decisions) and the Time of Use (starting with
> kernel_read_file()'s reading of the file contents). In theory, file
> contents could change between the two.
> 
> Signed-off-by: Kees Cook 
> ---
> v2: Clarify the ToC/ToU race (Linus)

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
next-general
and next-testing


-- 
James Morris

Re: [PATCH v2] exec: Set file unwritable before LSM check

[James Morris]

On Fri, 9 Mar 2018, Kees Cook wrote:

> The LSM check should happen after the file has been confirmed to be
> unchanging. Without this, we could have a race between the Time of Check
> (the call to security_kernel_read_file() which could read the file and
> make access policy decisions) and the Time of Use (starting with
> kernel_read_file()'s reading of the file contents). In theory, file
> contents could change between the two.
> 
> Signed-off-by: Kees Cook 
> ---
> v2: Clarify the ToC/ToU race (Linus)

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
next-general
and next-testing


-- 
James Morris

Re: [PATCH 5/6] dt-bindings: phy-qcom-usb2: Update bindings for sdm845

[Manu Gautam]

Hi,


On 3/18/2018 6:22 PM, Rob Herring wrote:
> On Fri, Mar 16, 2018 at 03:14:58PM +0530, Manu Gautam wrote:
>> Update compatible strings for USB2 PHYs on sdm845.
>> There are two QUSB2 PHYs present on sdm845. Few PHY registers
>> programming is different for these PHYs related to electrical
>> parameters, otherwise both are same.
> Register locations are different or tuning values are different? For the 
> latter, is that something that could be DT properties?

There are only register values changes. Corresponding driver change:
https://patchwork.kernel.org/patch/10286803/


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 5/6] dt-bindings: phy-qcom-usb2: Update bindings for sdm845

[Manu Gautam]

Hi,


On 3/18/2018 6:22 PM, Rob Herring wrote:
> On Fri, Mar 16, 2018 at 03:14:58PM +0530, Manu Gautam wrote:
>> Update compatible strings for USB2 PHYs on sdm845.
>> There are two QUSB2 PHYs present on sdm845. Few PHY registers
>> programming is different for these PHYs related to electrical
>> parameters, otherwise both are same.
> Register locations are different or tuning values are different? For the 
> latter, is that something that could be DT properties?

There are only register values changes. Corresponding driver change:
https://patchwork.kernel.org/patch/10286803/


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 3/4] arm64: Implement page table free interfaces

[Chintan Pandya]

On 3/15/2018 6:48 PM, Mark Rutland wrote:

On Thu, Mar 15, 2018 at 06:15:05PM +0530, Chintan Pandya wrote:

Implement pud_free_pmd_page() and pmd_free_pte_page().

Make sure, that they are indeed a page table before
taking them to free.


As mentioned on the prior patch, if the tables we're freeing contain
valid entries, then we need additional TLB maintenance to ensure that
all of these entries have been removed from TLBs.

Either, we always invalidate the entire range, or we walk the tables
and invalidate as we remove them.


Right. I'll send v3 and ensure this. Thinking like, we can
invalidate page table in PMD case and invalidate range if it's pud.
Will see if that also can be optimized.



Thanks,
Mark.



Signed-off-by: Chintan Pandya 
---
  arch/arm64/mm/mmu.c | 20 ++--
  1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..6f21a65 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -45,6 +46,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define NO_BLOCK_MAPPINGS	BIT(0)

  #define NO_CONT_MAPPINGS  BIT(1)
@@ -975,10 +977,24 @@ int pmd_clear_huge(pmd_t *pmdp)
  
  int pud_free_pmd_page(pud_t *pud)

  {
-   return pud_none(*pud);
+   pmd_t *pmd;
+   int i;
+
+   pmd = __va(pud_val(*pud));
+   if (pud_val(*pud) && !pud_huge(*pud)) {
+   for (i = 0; i < PTRS_PER_PMD; i++)
+   pmd_free_pte_page([i]);
+
+   free_page((unsigned long)pmd);
+   }
+
+   return 1;
  }
  
  int pmd_free_pte_page(pmd_t *pmd)

  {
-   return pmd_none(*pmd);
+   if (pmd_val(*pmd) && !pmd_huge(*pmd))
+   free_page((unsigned long)__va(pmd_val(*pmd)));
+
+   return 1;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project



Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH v2 3/4] arm64: Implement page table free interfaces

[Chintan Pandya]

On 3/15/2018 6:48 PM, Mark Rutland wrote:

On Thu, Mar 15, 2018 at 06:15:05PM +0530, Chintan Pandya wrote:

Implement pud_free_pmd_page() and pmd_free_pte_page().

Make sure, that they are indeed a page table before
taking them to free.


As mentioned on the prior patch, if the tables we're freeing contain
valid entries, then we need additional TLB maintenance to ensure that
all of these entries have been removed from TLBs.

Either, we always invalidate the entire range, or we walk the tables
and invalidate as we remove them.


Right. I'll send v3 and ensure this. Thinking like, we can
invalidate page table in PMD case and invalidate range if it's pud.
Will see if that also can be optimized.



Thanks,
Mark.



Signed-off-by: Chintan Pandya 
---
  arch/arm64/mm/mmu.c | 20 ++--
  1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..6f21a65 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -45,6 +46,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define NO_BLOCK_MAPPINGS	BIT(0)

  #define NO_CONT_MAPPINGS  BIT(1)
@@ -975,10 +977,24 @@ int pmd_clear_huge(pmd_t *pmdp)
  
  int pud_free_pmd_page(pud_t *pud)

  {
-   return pud_none(*pud);
+   pmd_t *pmd;
+   int i;
+
+   pmd = __va(pud_val(*pud));
+   if (pud_val(*pud) && !pud_huge(*pud)) {
+   for (i = 0; i < PTRS_PER_PMD; i++)
+   pmd_free_pte_page([i]);
+
+   free_page((unsigned long)pmd);
+   }
+
+   return 1;
  }
  
  int pmd_free_pte_page(pmd_t *pmd)

  {
-   return pmd_none(*pmd);
+   if (pmd_val(*pmd) && !pmd_huge(*pmd))
+   free_page((unsigned long)__va(pmd_val(*pmd)));
+
+   return 1;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project



Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

Hi Oleg,

On 03/14/2018 10:29 PM, Oleg Nesterov wrote:
> On 03/13, Ravi Bangoria wrote:
>> +static bool sdt_valid_vma(struct trace_uprobe *tu, struct vm_area_struct 
>> *vma)
>> +{
>> +unsigned long vaddr = vma_offset_to_vaddr(vma, tu->ref_ctr_offset);
>> +
>> +return tu->ref_ctr_offset &&
>> +vma->vm_file &&
>> +file_inode(vma->vm_file) == tu->inode &&
>> +vma->vm_flags & VM_WRITE &&
>> +vma->vm_start <= vaddr &&
>> +vma->vm_end > vaddr;
>> +}
> Perhaps in this case a simple
>
>   ref_ctr_offset < vma->vm_end - vma->vm_start
>
> check without vma_offset_to_vaddr() makes more sense, but I won't insist.
>

I still don't get this. This seems a comparison between file offset and size
of the vma. Shouldn't we need to consider pg_off here?

Thanks,
Ravi

Re: [PATCH v2 2/4] ioremap: Implement TLB_INV before huge mapping

[Chintan Pandya]

On 3/16/2018 8:20 PM, Kani, Toshi wrote:

On Fri, 2018-03-16 at 13:10 +0530, Chintan Pandya wrote:


On 3/15/2018 9:42 PM, Kani, Toshi wrote:

On Thu, 2018-03-15 at 18:15 +0530, Chintan Pandya wrote:

Huge mapping changes PMD/PUD which could have
valid previous entries. This requires proper
TLB maintanance on some architectures, like
ARM64.

Implent BBM (break-before-make) safe TLB
invalidation.

Here, I've used flush_tlb_pgtable() instead
of flush_kernel_range() because invalidating
intermediate page_table entries could have
been optimized for specific arch. That's the
case with ARM64 at least.

Signed-off-by: Chintan Pandya 
---
   lib/ioremap.c | 25 +++--
   1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bba..55f8648 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -13,6 +13,7 @@
   #include 
   #include 
   #include 
+#include 
   
   #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP

   static int __read_mostly ioremap_p4d_capable;
@@ -80,6 +81,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long 
addr,
unsigned long end, phys_addr_t phys_addr, pgprot_t prot)
   {
pmd_t *pmd;
+   pmd_t old_pmd;
unsigned long next;
   
   	phys_addr -= addr;

@@ -91,10 +93,15 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned 
long addr,
   
   		if (ioremap_pmd_enabled() &&

((next - addr) == PMD_SIZE) &&
-   IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
-   pmd_free_pte_page(pmd)) {
-   if (pmd_set_huge(pmd, phys_addr + addr, prot))
+   IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
+   old_pmd = *pmd;
+   pmd_clear(pmd);


pmd_clear() is one of the operations pmd_free_pte_page() needs to do.
See the x86 version.


+   flush_tlb_pgtable(_mm, addr);


You can call it in pmd_free_pte_page() on arm64 as well.


+   if (pmd_set_huge(pmd, phys_addr + addr, prot)) {
+   pmd_free_pte_page(_pmd);
continue;
+   } else
+   set_pmd(pmd, old_pmd);


I do not understand why you needed to make this change.
pmd_free_pte_page() is defined as an arch-specific function so that you
can additionally perform TLB purges on arm64.  Please try to make proper
arm64 implementation of this interface.  And if you find any issue in
this interface, please let me know.


TLB ops require VA at least. And this interface passes just the PMD/PUD.


You can add 'addr' as the 2nd arg.  Such minor tweak is expected when
implementing on multiple arches.


Second is, if we clear the previous table entry inside the arch specific
code and then we fail in pmd/pud_set_huge, we can't fallback (x86 case).

So, we can do something like this (following Mark's suggestion),

if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
pmd_can_set_huge(pmd, phys_addr + addr, prot)) {
/*
 * Clear existing table entry,
 * Invalidate,
 * Free the page table
 * inside this code
 */
pmd_free_pte_page(pmd, addr, addr + PMD_SIZE);
pmd_set_huge(...) //without fail
continue;
}


That's not necessary.  pmd being none is a legitimate state.  In fact,
it is the case when pmd_alloc() allocated and populated a new pmd.


Alright. I'll send v3 today.



Thanks,
-Toshi



Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH v2 2/4] ioremap: Implement TLB_INV before huge mapping

[Chintan Pandya]

On 3/16/2018 8:20 PM, Kani, Toshi wrote:

On Fri, 2018-03-16 at 13:10 +0530, Chintan Pandya wrote:


On 3/15/2018 9:42 PM, Kani, Toshi wrote:

On Thu, 2018-03-15 at 18:15 +0530, Chintan Pandya wrote:

Huge mapping changes PMD/PUD which could have
valid previous entries. This requires proper
TLB maintanance on some architectures, like
ARM64.

Implent BBM (break-before-make) safe TLB
invalidation.

Here, I've used flush_tlb_pgtable() instead
of flush_kernel_range() because invalidating
intermediate page_table entries could have
been optimized for specific arch. That's the
case with ARM64 at least.

Signed-off-by: Chintan Pandya 
---
   lib/ioremap.c | 25 +++--
   1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bba..55f8648 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -13,6 +13,7 @@
   #include 
   #include 
   #include 
+#include 
   
   #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP

   static int __read_mostly ioremap_p4d_capable;
@@ -80,6 +81,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long 
addr,
unsigned long end, phys_addr_t phys_addr, pgprot_t prot)
   {
pmd_t *pmd;
+   pmd_t old_pmd;
unsigned long next;
   
   	phys_addr -= addr;

@@ -91,10 +93,15 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned 
long addr,
   
   		if (ioremap_pmd_enabled() &&

((next - addr) == PMD_SIZE) &&
-   IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
-   pmd_free_pte_page(pmd)) {
-   if (pmd_set_huge(pmd, phys_addr + addr, prot))
+   IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
+   old_pmd = *pmd;
+   pmd_clear(pmd);


pmd_clear() is one of the operations pmd_free_pte_page() needs to do.
See the x86 version.


+   flush_tlb_pgtable(_mm, addr);


You can call it in pmd_free_pte_page() on arm64 as well.


+   if (pmd_set_huge(pmd, phys_addr + addr, prot)) {
+   pmd_free_pte_page(_pmd);
continue;
+   } else
+   set_pmd(pmd, old_pmd);


I do not understand why you needed to make this change.
pmd_free_pte_page() is defined as an arch-specific function so that you
can additionally perform TLB purges on arm64.  Please try to make proper
arm64 implementation of this interface.  And if you find any issue in
this interface, please let me know.


TLB ops require VA at least. And this interface passes just the PMD/PUD.


You can add 'addr' as the 2nd arg.  Such minor tweak is expected when
implementing on multiple arches.


Second is, if we clear the previous table entry inside the arch specific
code and then we fail in pmd/pud_set_huge, we can't fallback (x86 case).

So, we can do something like this (following Mark's suggestion),

if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
pmd_can_set_huge(pmd, phys_addr + addr, prot)) {
/*
 * Clear existing table entry,
 * Invalidate,
 * Free the page table
 * inside this code
 */
pmd_free_pte_page(pmd, addr, addr + PMD_SIZE);
pmd_set_huge(...) //without fail
continue;
}


That's not necessary.  pmd being none is a legitimate state.  In fact,
it is the case when pmd_alloc() allocated and populated a new pmd.


Alright. I'll send v3 today.



Thanks,
-Toshi



Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

Hi Oleg,

On 03/14/2018 10:29 PM, Oleg Nesterov wrote:
> On 03/13, Ravi Bangoria wrote:
>> +static bool sdt_valid_vma(struct trace_uprobe *tu, struct vm_area_struct 
>> *vma)
>> +{
>> +unsigned long vaddr = vma_offset_to_vaddr(vma, tu->ref_ctr_offset);
>> +
>> +return tu->ref_ctr_offset &&
>> +vma->vm_file &&
>> +file_inode(vma->vm_file) == tu->inode &&
>> +vma->vm_flags & VM_WRITE &&
>> +vma->vm_start <= vaddr &&
>> +vma->vm_end > vaddr;
>> +}
> Perhaps in this case a simple
>
>   ref_ctr_offset < vma->vm_end - vma->vm_start
>
> check without vma_offset_to_vaddr() makes more sense, but I won't insist.
>

I still don't get this. This seems a comparison between file offset and size
of the vma. Shouldn't we need to consider pg_off here?

Thanks,
Ravi

Re: [PATCH 19/19] irqchip: add irq-nationalchip.c and irq-csky.c

[Mark Rutland]

On Mon, Mar 19, 2018 at 03:51:41AM +0800, Guo Ren wrote:
> +static unsigned int intc_reg;

This should be a void __iomem *ptr;

> +
> +#define CK_VA_INTC_ICR   (void *)(intc_reg + 0x00)   /* 
> Interrupt control register(High 16bits) */
> +#define CK_VA_INTC_ISR   (void *)(intc_reg + 0x00)   /* 
> Interrupt status register(Low 16bits) */
> +#define CK_VA_INTC_NEN31_00  (void *)(intc_reg + 0x10)   /* Normal 
> interrupt enable register Low */
> +#define  CK_VA_INTC_NEN63_32 (void *)(intc_reg + 0x28)   /* 
> Normal interrupt enable register High */
> +#define CK_VA_INTC_IFR31_00  (void *)(intc_reg + 0x08)   /* Normal 
> interrupt force register Low */
> +#define CK_VA_INTC_IFR63_32  (void *)(intc_reg + 0x20)   /* Normal 
> interrupt force register High */
> +#define  CK_VA_INTC_SOURCE   (void *)(intc_reg + 0x40)   /* 
> Proiority Level Select Registers 0 */

Please use mnemonics for the offsets, and add the base address in the IO
accessors.

[...]

> + temp = __raw_readl(CK_VA_INTC_NEN31_00);

Please use readl_relaxed() rather than __raw_readl().

> + __raw_writel(temp, CK_VA_INTC_NEN31_00);

Likewise, please use writel_relaxed() rather than __raw_writel().

[...]

> +static int __init
> +__intc_init(struct device_node *np, struct device_node *parent, bool ave)
> +{
> + struct irq_domain *root_domain;
> + int i;
> +
> + csky_get_auto_irqno = ck_get_irqno;
> +
> + if (parent)
> + panic("pic not a root intc\n");
> +
> + intc_reg = (unsigned int)of_iomap(np, 0);
> + if (!intc_reg)
> + panic("%s, of_iomap err.\n", __func__);
> +
> + __raw_writel(0, CK_VA_INTC_NEN31_00);
> + __raw_writel(0, CK_VA_INTC_NEN63_32);
> +
> + if (ave == true)
> + __raw_writel( 0xc000, CK_VA_INTC_ICR);
> + else
> + __raw_writel( 0x0, CK_VA_INTC_ICR);
> + /*
> +  * csky irq ctrl has 64 sources.
> +  */
> + #define INTC_IRQS 64
> + for (i=0; i + __raw_writel((i+3)|((i+2)<<8)|((i+1)<<16)|(i<<24),
> + CK_VA_INTC_SOURCE + i);
> +
> + root_domain = irq_domain_add_legacy(np, INTC_IRQS, 0, 0, _irq_ops, 
> NULL);
> + if (!root_domain)
> + panic("root irq domain not available\n");
> +
> + irq_set_default_host(root_domain);
> +
> + return 0;
> +}
> +
> +static int __init
> +intc_init(struct device_node *np, struct device_node *parent)
> +{
> +
> + return __intc_init(np, parent, false);
> +}
> +IRQCHIP_DECLARE(csky_intc_v1, "csky,intc-v1", intc_init);
> +
> +/*
> + * use auto vector exceptions 10 for interrupt.
> + */
> +static int __init
> +intc_init_ave(struct device_node *np, struct device_node *parent)
> +{
> + return __intc_init(np, parent, true);
> +}
> +IRQCHIP_DECLARE(csky_intc_v1_ave, "csky,intc-v1,ave", intc_init_ave);

These need devicetree bindings. Please see
Documentation/devicetree/bindings/submitting-patches.txt.

[...]

> +inline int ff1_64(unsigned int hi, unsigned int lo)
> +{
> + int result;
> + asm volatile(
> + "ff1 %0\n"
> + :"=r"(hi)
> + :"r"(hi)
> + :
> + );
> +
> + asm volatile(
> + "ff1 %0\n"
> + :"=r"(lo)
> + :"r"(lo)
> + :
> + );
> + if( lo != 32 )
> + result = 31-lo;
> + else if( hi != 32 ) result = 31-hi + 32;
> + else {
> + printk("nc_get_irqno error hi:%x, lo:%x.\n", hi, lo);
> + result = NR_IRQS;
> + }
> + return result;
> +}

Please avoid assembly in generic driver code. Here you cna use __ffs64() after
combining the two halves into a 64-bit quantity, or you could use ffs() on each
half.

> +static int __init
> +intc_init(struct device_node *intc, struct device_node *parent)
> +{
> + struct irq_domain *root_domain;
> + unsigned int i;
> +
> + if (parent)
> + panic("DeviceTree incore intc not a root irq controller\n");
> +
> + csky_get_auto_irqno = nc_get_irqno;
> +
> + intc_reg = (unsigned int) of_iomap(intc, 0);
> + if (!intc_reg)
> + panic("Nationalchip Intc Reg: %x.\n", intc_reg);
> +
> + __raw_writel(0x, NC_VA_INTC_NENCLR31_00);
> + __raw_writel(0x, NC_VA_INTC_NENCLR63_32);
> + __raw_writel(0x, NC_VA_INTC_NMASK31_00);
> + __raw_writel(0x, NC_VA_INTC_NMASK63_32);
> +
> + /*
> +  * nationalchip irq ctrl has 64 sources.
> +  */
> + #define INTC_IRQS 64
> + for (i=0; i + __raw_writel(i|((i+1)<<8)|((i+2)<<16)|((i+3)<<24),
> + NC_VA_INTC_SOURCE + i);
> +
> + root_domain = irq_domain_add_legacy(intc, INTC_IRQS, 0, 0,
> + _irq_ops, NULL);
> + if (!root_domain)
> + panic("root irq domain not avail\n");
> +
> + 

Re: [PATCH 19/19] irqchip: add irq-nationalchip.c and irq-csky.c

[Mark Rutland]

On Mon, Mar 19, 2018 at 03:51:41AM +0800, Guo Ren wrote:
> +static unsigned int intc_reg;

This should be a void __iomem *ptr;

> +
> +#define CK_VA_INTC_ICR   (void *)(intc_reg + 0x00)   /* 
> Interrupt control register(High 16bits) */
> +#define CK_VA_INTC_ISR   (void *)(intc_reg + 0x00)   /* 
> Interrupt status register(Low 16bits) */
> +#define CK_VA_INTC_NEN31_00  (void *)(intc_reg + 0x10)   /* Normal 
> interrupt enable register Low */
> +#define  CK_VA_INTC_NEN63_32 (void *)(intc_reg + 0x28)   /* 
> Normal interrupt enable register High */
> +#define CK_VA_INTC_IFR31_00  (void *)(intc_reg + 0x08)   /* Normal 
> interrupt force register Low */
> +#define CK_VA_INTC_IFR63_32  (void *)(intc_reg + 0x20)   /* Normal 
> interrupt force register High */
> +#define  CK_VA_INTC_SOURCE   (void *)(intc_reg + 0x40)   /* 
> Proiority Level Select Registers 0 */

Please use mnemonics for the offsets, and add the base address in the IO
accessors.

[...]

> + temp = __raw_readl(CK_VA_INTC_NEN31_00);

Please use readl_relaxed() rather than __raw_readl().

> + __raw_writel(temp, CK_VA_INTC_NEN31_00);

Likewise, please use writel_relaxed() rather than __raw_writel().

[...]

> +static int __init
> +__intc_init(struct device_node *np, struct device_node *parent, bool ave)
> +{
> + struct irq_domain *root_domain;
> + int i;
> +
> + csky_get_auto_irqno = ck_get_irqno;
> +
> + if (parent)
> + panic("pic not a root intc\n");
> +
> + intc_reg = (unsigned int)of_iomap(np, 0);
> + if (!intc_reg)
> + panic("%s, of_iomap err.\n", __func__);
> +
> + __raw_writel(0, CK_VA_INTC_NEN31_00);
> + __raw_writel(0, CK_VA_INTC_NEN63_32);
> +
> + if (ave == true)
> + __raw_writel( 0xc000, CK_VA_INTC_ICR);
> + else
> + __raw_writel( 0x0, CK_VA_INTC_ICR);
> + /*
> +  * csky irq ctrl has 64 sources.
> +  */
> + #define INTC_IRQS 64
> + for (i=0; i + __raw_writel((i+3)|((i+2)<<8)|((i+1)<<16)|(i<<24),
> + CK_VA_INTC_SOURCE + i);
> +
> + root_domain = irq_domain_add_legacy(np, INTC_IRQS, 0, 0, _irq_ops, 
> NULL);
> + if (!root_domain)
> + panic("root irq domain not available\n");
> +
> + irq_set_default_host(root_domain);
> +
> + return 0;
> +}
> +
> +static int __init
> +intc_init(struct device_node *np, struct device_node *parent)
> +{
> +
> + return __intc_init(np, parent, false);
> +}
> +IRQCHIP_DECLARE(csky_intc_v1, "csky,intc-v1", intc_init);
> +
> +/*
> + * use auto vector exceptions 10 for interrupt.
> + */
> +static int __init
> +intc_init_ave(struct device_node *np, struct device_node *parent)
> +{
> + return __intc_init(np, parent, true);
> +}
> +IRQCHIP_DECLARE(csky_intc_v1_ave, "csky,intc-v1,ave", intc_init_ave);

These need devicetree bindings. Please see
Documentation/devicetree/bindings/submitting-patches.txt.

[...]

> +inline int ff1_64(unsigned int hi, unsigned int lo)
> +{
> + int result;
> + asm volatile(
> + "ff1 %0\n"
> + :"=r"(hi)
> + :"r"(hi)
> + :
> + );
> +
> + asm volatile(
> + "ff1 %0\n"
> + :"=r"(lo)
> + :"r"(lo)
> + :
> + );
> + if( lo != 32 )
> + result = 31-lo;
> + else if( hi != 32 ) result = 31-hi + 32;
> + else {
> + printk("nc_get_irqno error hi:%x, lo:%x.\n", hi, lo);
> + result = NR_IRQS;
> + }
> + return result;
> +}

Please avoid assembly in generic driver code. Here you cna use __ffs64() after
combining the two halves into a 64-bit quantity, or you could use ffs() on each
half.

> +static int __init
> +intc_init(struct device_node *intc, struct device_node *parent)
> +{
> + struct irq_domain *root_domain;
> + unsigned int i;
> +
> + if (parent)
> + panic("DeviceTree incore intc not a root irq controller\n");
> +
> + csky_get_auto_irqno = nc_get_irqno;
> +
> + intc_reg = (unsigned int) of_iomap(intc, 0);
> + if (!intc_reg)
> + panic("Nationalchip Intc Reg: %x.\n", intc_reg);
> +
> + __raw_writel(0x, NC_VA_INTC_NENCLR31_00);
> + __raw_writel(0x, NC_VA_INTC_NENCLR63_32);
> + __raw_writel(0x, NC_VA_INTC_NMASK31_00);
> + __raw_writel(0x, NC_VA_INTC_NMASK63_32);
> +
> + /*
> +  * nationalchip irq ctrl has 64 sources.
> +  */
> + #define INTC_IRQS 64
> + for (i=0; i + __raw_writel(i|((i+1)<<8)|((i+2)<<16)|((i+3)<<24),
> + NC_VA_INTC_SOURCE + i);
> +
> + root_domain = irq_domain_add_legacy(intc, INTC_IRQS, 0, 0,
> + _irq_ops, NULL);
> + if (!root_domain)
> + panic("root irq domain not avail\n");
> +
> + irq_set_default_host(root_domain);
> +
> + return 0;
> +}
> +
> 

Re: Re: [PATCH] staging: media: davinci_vpfe: add error handling on kmalloc failure

[Ji-Hun Kim]

On Fri, Mar 16, 2018 at 11:32:34AM +0300, Dan Carpenter wrote:
> On Fri, Mar 16, 2018 at 01:58:23PM +0900, Ji-Hun Kim wrote:
> > There is no failure checking on the param value which will be allocated
> > memory by kmalloc. Add a null pointer checking statement. Then goto error:
> > and return -ENOMEM error code when kmalloc is failed.
> > 
> > Signed-off-by: Ji-Hun Kim 
> > ---
> >  drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
> > b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > index 6a3434c..55a922c 100644
> > --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > @@ -1280,6 +1280,10 @@ static int ipipe_s_config(struct v4l2_subdev *sd, 
> > struct vpfe_ipipe_config *cfg)
> >  
> > params = kmalloc(sizeof(struct ipipe_module_params),
> >  GFP_KERNEL);
> > +   if (!params) {
> > +   rval = -ENOMEM;
> > +   goto error;
> ^^
> 
> What does "goto error" do, do you think?  It's not clear from the name.
> When you have an unclear goto like this it often means the error
> handling is going to be buggy.
> 
> In this case, it does nothing so a direct "return -ENOMEM;" would be
> more clear.  But the rest of the error handling is buggy.
Hi Dan,
I appreciate for your specific feedbacks. It looks more clear. And I'd
like you to see my question below. I will send the patch v2.

> 
>   1263  static int ipipe_s_config(struct v4l2_subdev *sd, struct 
> vpfe_ipipe_config *cfg)
>   1264  {
>   1265  struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
>   1266  unsigned int i;
>   1267  int rval = 0;
>   1268  
>   1269  for (i = 0; i < ARRAY_SIZE(ipipe_modules); i++) {
>   1270  unsigned int bit = 1 << i;
>   1271  
>   1272  if (cfg->flag & bit) {
>   1273  const struct ipipe_module_if *module_if =
>   1274  _modules[i];
>   1275  struct ipipe_module_params *params;
>   1276  void __user *from = *(void * __user *)
>   1277  ((void *)cfg + 
> module_if->config_offset);
>   1278  size_t size;
>   1279  void *to;
>   1280  
>   1281  params = kmalloc(sizeof(struct 
> ipipe_module_params),
>   1282   GFP_KERNEL);
> 
> Do a direct return:
> 
>   if (!params)
>   return -ENOMEM;
> 
>   1283  to = (void *)params + module_if->param_offset;
>   1284  size = module_if->param_size;
>   1285  
>   1286  if (to && from && size) {
>   1287  if (copy_from_user(to, from, size)) {
>   1288  rval = -EFAULT;
>   1289  break;
> 
> The most recent thing we allocated is "params" so lets do a
> "goto free_params;".  We'll have to declare "params" at the start of the
> function instead inside this block.
> 
>   1290  }
>   1291  rval = module_if->set(ipipe, to);
>   1292  if (rval)
>   1293  goto error;
> 
> goto free_params again since params is still the most recent thing we
> allocated.
> 
>   1294  } else if (to && !from && size) {
>   1295  rval = module_if->set(ipipe, NULL);
>   1296  if (rval)
>   1297  goto error;
> 
> And here again goto free_params.
> 
>   1298  }
>   1299  kfree(params);
>   1300  }
>   1301  }
>   1302  error:
>   1303  return rval;
> 
> 
> Change this to:
> 
>   return 0;
Instead of returning rval, returning 0 would be fine? It looks that should
return rval in normal case.

> 
> free_params:
>   kfree(params);
>   return rval;
> 
>   1304  }
> 
> regards,
> dan carpenter
> 
> 
Thanks,
Ji-Hun

Re: Re: [PATCH] staging: media: davinci_vpfe: add error handling on kmalloc failure

[Ji-Hun Kim]

On Fri, Mar 16, 2018 at 11:32:34AM +0300, Dan Carpenter wrote:
> On Fri, Mar 16, 2018 at 01:58:23PM +0900, Ji-Hun Kim wrote:
> > There is no failure checking on the param value which will be allocated
> > memory by kmalloc. Add a null pointer checking statement. Then goto error:
> > and return -ENOMEM error code when kmalloc is failed.
> > 
> > Signed-off-by: Ji-Hun Kim 
> > ---
> >  drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
> > b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > index 6a3434c..55a922c 100644
> > --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > @@ -1280,6 +1280,10 @@ static int ipipe_s_config(struct v4l2_subdev *sd, 
> > struct vpfe_ipipe_config *cfg)
> >  
> > params = kmalloc(sizeof(struct ipipe_module_params),
> >  GFP_KERNEL);
> > +   if (!params) {
> > +   rval = -ENOMEM;
> > +   goto error;
> ^^
> 
> What does "goto error" do, do you think?  It's not clear from the name.
> When you have an unclear goto like this it often means the error
> handling is going to be buggy.
> 
> In this case, it does nothing so a direct "return -ENOMEM;" would be
> more clear.  But the rest of the error handling is buggy.
Hi Dan,
I appreciate for your specific feedbacks. It looks more clear. And I'd
like you to see my question below. I will send the patch v2.

> 
>   1263  static int ipipe_s_config(struct v4l2_subdev *sd, struct 
> vpfe_ipipe_config *cfg)
>   1264  {
>   1265  struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
>   1266  unsigned int i;
>   1267  int rval = 0;
>   1268  
>   1269  for (i = 0; i < ARRAY_SIZE(ipipe_modules); i++) {
>   1270  unsigned int bit = 1 << i;
>   1271  
>   1272  if (cfg->flag & bit) {
>   1273  const struct ipipe_module_if *module_if =
>   1274  _modules[i];
>   1275  struct ipipe_module_params *params;
>   1276  void __user *from = *(void * __user *)
>   1277  ((void *)cfg + 
> module_if->config_offset);
>   1278  size_t size;
>   1279  void *to;
>   1280  
>   1281  params = kmalloc(sizeof(struct 
> ipipe_module_params),
>   1282   GFP_KERNEL);
> 
> Do a direct return:
> 
>   if (!params)
>   return -ENOMEM;
> 
>   1283  to = (void *)params + module_if->param_offset;
>   1284  size = module_if->param_size;
>   1285  
>   1286  if (to && from && size) {
>   1287  if (copy_from_user(to, from, size)) {
>   1288  rval = -EFAULT;
>   1289  break;
> 
> The most recent thing we allocated is "params" so lets do a
> "goto free_params;".  We'll have to declare "params" at the start of the
> function instead inside this block.
> 
>   1290  }
>   1291  rval = module_if->set(ipipe, to);
>   1292  if (rval)
>   1293  goto error;
> 
> goto free_params again since params is still the most recent thing we
> allocated.
> 
>   1294  } else if (to && !from && size) {
>   1295  rval = module_if->set(ipipe, NULL);
>   1296  if (rval)
>   1297  goto error;
> 
> And here again goto free_params.
> 
>   1298  }
>   1299  kfree(params);
>   1300  }
>   1301  }
>   1302  error:
>   1303  return rval;
> 
> 
> Change this to:
> 
>   return 0;
Instead of returning rval, returning 0 would be fine? It looks that should
return rval in normal case.

> 
> free_params:
>   kfree(params);
>   return rval;
> 
>   1304  }
> 
> regards,
> dan carpenter
> 
> 
Thanks,
Ji-Hun

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

[Al Viro]

On Sun, Mar 18, 2018 at 06:18:48PM +, Al Viro wrote:

> I'd done some digging in that area, will find the notes and post.

OK, found:

We have two ABIs in the game - syscall and normal C.  The latter
(for all targets we support) can be described in the following
terms:
* there is a series of word-sized objects used to pass
arguments, some in registers, some on stack.  Arguments are
mapped on that sequence.  Anything up to word size simply takes
the next available word, so on 64bit it's all there is - nth
argument goes into the nth object, types simply do not matter.
On 32bit it's not that simple - there 64bit arguments occupy
two objects.  They are still picked from the same sequence;
on little-endian the lower half goes first, on big-endian -
the higher one.  For some architectures that's all there is to it.
However, on quite a few there's an extra complication - not every
pair can be used for 64bit value.  Rules for those are arch-dependent.
One variety is "pairs should be aligned", i.e. "if we'd consumed
an odd number of slots, add a dummy one before eating a pair".
Another is "don't let a pair span the registers/stack boundary";
surprisingly enough, that's not universal.

The syscall ABI can considerably differ from C one.  First of all,
we really do *not* want to pass anything on stack - it's a major
headache at syscall entry.  See mips/o32 for the scale of that headache.
Not fun.  OTOH, the registers that can be used are a limited resource.
i386 can't pass more than 6 words and that has served as an upper
limit.  If we encode the argument sizes (W - word, D - 64bit) we
have the following variants among the syscalls:
* no arguments at all (SYSCALL_DEFINE0)
* W (SYSCALL_DEFINE1)
* WW (SYSCALL_DEFINE2)
* WWW (SYSCALL_DEFINE3)
*  (SYSCALL_DEFINE4)
* W (SYSCALL_DEFINE5)
* WW (SYSCALL_DEFINE6)
* WD (SYSCALL_DEFINE2, truncate64, ftruncate64)
* DWW (SYSCALL_DEFINE3, lookup_dcookie)
* WDW (SYSCALL_DEFINE3, readahead)
* WWWD (SYSCALL_DEFINE4, pread64, pwrite64)
* WWDD (SYSCALL_DEFINE4, fallocate, sync_file_range2)
* WDDW (SYSCALL_DEFINE4, sync_file_range, fadvise64_64)
* WDWW (SYSCALL_DEFINE4, fadvise64)
* WWDWW (SYSCALL_DEFINE5, fanotify_mark)

The list for each long long-passing variant might be incomplete, but
they really are rare.  And a source of headache; not just for biarch
architectures - e.g. c6x and metag are not biarch and these syscalls
are exactly what stinks them up.

One thing we *really* don't want is syscall-dependent mapping from
syscall ABI registers to C ABI sequence.  Inside a syscall (or in
per-syscall glue) - sure, we can do it (if not happily).  In the
syscall dispatcher - fuck no, too much PITA.  mips/o32 used to be
a horrible example of why not, then they went for "copy from userland
stack whether we need it or not"...

For simple syscalls (first 7 classes in the above, each argument fits
into word) we simply map registers to the first 6 slots of the sequence
and we are done.  It's bloody tempting to use the same mapping for
the rest - use the same code that calls simple syscalls and have it
call sys_readahead() instead of sys_mkdir(), etc.  For something like
x86 or sparc that works perfectly - these guys have no padding for 64bit
arguments, so we are good (provided that userland sets those registers
sanely, that is).

OTOH, consider arm.  There we have
* r0, r1, r2, r3, [sp,#8], [sp,#12], [sp,#16]... is the sequence
of objects used to pass arguments
* 32bit and less - pick the next available slot
* 64bit - skip a slot if we'd already taken an odd number, then use
the next two slots for lower and upper 32 bits of the argument.

So our classes take
simple n-argument:  0 to 6 slots
WD  4 slots
DWW 4 slots
WDW 5 slots
WWDD6 slots
WDWW5 slots
WWWD6 slots
WWDWW   6 slots
WDDW7 slots (!)  Also , , !@#!@#!@#!# and other nice
and well-deserved comments from arch maintainers, some of them even printable:
/* It would be nice if people remember that not all the world's an i386
   when they introduce new system calls */
SYSCALL_DEFINE4(sync_file_range2, int, fd, unsigned int, flags,
 loff_t, offset, loff_t, nbytes)

No idea why that hadn't been done to fadvise64_64() - that got
/*
 * Since loff_t is a 64 bit type we avoid a lot of ABI hassle
 * with a different argument ordering.
 */
asmlinkage long sys_arm_fadvise64_64(int fd, int advice,
 loff_t offset, loff_t len)
{
return sys_fadvise64_64(fd, offset, len, advice);
}
long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low,
  u32 len_high, u32 len_low)
{
return sys_fadvise64(fd, 

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

[Al Viro]

On Sun, Mar 18, 2018 at 06:18:48PM +, Al Viro wrote:

> I'd done some digging in that area, will find the notes and post.

OK, found:

We have two ABIs in the game - syscall and normal C.  The latter
(for all targets we support) can be described in the following
terms:
* there is a series of word-sized objects used to pass
arguments, some in registers, some on stack.  Arguments are
mapped on that sequence.  Anything up to word size simply takes
the next available word, so on 64bit it's all there is - nth
argument goes into the nth object, types simply do not matter.
On 32bit it's not that simple - there 64bit arguments occupy
two objects.  They are still picked from the same sequence;
on little-endian the lower half goes first, on big-endian -
the higher one.  For some architectures that's all there is to it.
However, on quite a few there's an extra complication - not every
pair can be used for 64bit value.  Rules for those are arch-dependent.
One variety is "pairs should be aligned", i.e. "if we'd consumed
an odd number of slots, add a dummy one before eating a pair".
Another is "don't let a pair span the registers/stack boundary";
surprisingly enough, that's not universal.

The syscall ABI can considerably differ from C one.  First of all,
we really do *not* want to pass anything on stack - it's a major
headache at syscall entry.  See mips/o32 for the scale of that headache.
Not fun.  OTOH, the registers that can be used are a limited resource.
i386 can't pass more than 6 words and that has served as an upper
limit.  If we encode the argument sizes (W - word, D - 64bit) we
have the following variants among the syscalls:
* no arguments at all (SYSCALL_DEFINE0)
* W (SYSCALL_DEFINE1)
* WW (SYSCALL_DEFINE2)
* WWW (SYSCALL_DEFINE3)
*  (SYSCALL_DEFINE4)
* W (SYSCALL_DEFINE5)
* WW (SYSCALL_DEFINE6)
* WD (SYSCALL_DEFINE2, truncate64, ftruncate64)
* DWW (SYSCALL_DEFINE3, lookup_dcookie)
* WDW (SYSCALL_DEFINE3, readahead)
* WWWD (SYSCALL_DEFINE4, pread64, pwrite64)
* WWDD (SYSCALL_DEFINE4, fallocate, sync_file_range2)
* WDDW (SYSCALL_DEFINE4, sync_file_range, fadvise64_64)
* WDWW (SYSCALL_DEFINE4, fadvise64)
* WWDWW (SYSCALL_DEFINE5, fanotify_mark)

The list for each long long-passing variant might be incomplete, but
they really are rare.  And a source of headache; not just for biarch
architectures - e.g. c6x and metag are not biarch and these syscalls
are exactly what stinks them up.

One thing we *really* don't want is syscall-dependent mapping from
syscall ABI registers to C ABI sequence.  Inside a syscall (or in
per-syscall glue) - sure, we can do it (if not happily).  In the
syscall dispatcher - fuck no, too much PITA.  mips/o32 used to be
a horrible example of why not, then they went for "copy from userland
stack whether we need it or not"...

For simple syscalls (first 7 classes in the above, each argument fits
into word) we simply map registers to the first 6 slots of the sequence
and we are done.  It's bloody tempting to use the same mapping for
the rest - use the same code that calls simple syscalls and have it
call sys_readahead() instead of sys_mkdir(), etc.  For something like
x86 or sparc that works perfectly - these guys have no padding for 64bit
arguments, so we are good (provided that userland sets those registers
sanely, that is).

OTOH, consider arm.  There we have
* r0, r1, r2, r3, [sp,#8], [sp,#12], [sp,#16]... is the sequence
of objects used to pass arguments
* 32bit and less - pick the next available slot
* 64bit - skip a slot if we'd already taken an odd number, then use
the next two slots for lower and upper 32 bits of the argument.

So our classes take
simple n-argument:  0 to 6 slots
WD  4 slots
DWW 4 slots
WDW 5 slots
WWDD6 slots
WDWW5 slots
WWWD6 slots
WWDWW   6 slots
WDDW7 slots (!)  Also , , !@#!@#!@#!# and other nice
and well-deserved comments from arch maintainers, some of them even printable:
/* It would be nice if people remember that not all the world's an i386
   when they introduce new system calls */
SYSCALL_DEFINE4(sync_file_range2, int, fd, unsigned int, flags,
 loff_t, offset, loff_t, nbytes)

No idea why that hadn't been done to fadvise64_64() - that got
/*
 * Since loff_t is a 64 bit type we avoid a lot of ABI hassle
 * with a different argument ordering.
 */
asmlinkage long sys_arm_fadvise64_64(int fd, int advice,
 loff_t offset, loff_t len)
{
return sys_fadvise64_64(fd, offset, len, advice);
}
long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low,
  u32 len_high, u32 len_low)
{
return sys_fadvise64(fd, 

Re: [PATCH v1 1/2] dt-bindings: usb: Update documentation for Qualcomm DWC3 driver

[Manu Gautam]

Hi,


On 3/18/2018 6:19 PM, Rob Herring wrote:
> On Tue, Mar 13, 2018 at 04:06:00PM +0530, Manu Gautam wrote:
>> Existing documentation has lot of incorrect information as it
>> was originally added for a driver that no longer exists.
>>
>> Signed-off-by: Manu Gautam 
>> ---
>>  .../devicetree/bindings/usb/qcom,dwc3.txt  | 87 
>> +++---
>>  1 file changed, 59 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
>> b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>> index bc8a2fa..df312f7 100644
>> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>> @@ -1,54 +1,85 @@
>>  Qualcomm SuperSpeed DWC3 USB SoC controller
>>  
>>  Required properties:
>> -- compatible:   should contain "qcom,dwc3"
>> -- clocks:   A list of phandle + clock-specifier pairs for the
>> -clocks listed in clock-names
>> -- clock-names:  Should contain the following:
>> -  "core"Master/Core clock, have to be >= 125 MHz for SS
>> -operation and >= 60MHz for HS operation
>> -
>> -Optional clocks:
>> -  "iface"   System bus AXI clock.  Not present on all platforms
>> -  "sleep"   Sleep clock, used when USB3 core goes into low
>> -power mode (U3).
>> +- compatible:   should contain "qcom,dwc3"
>> +- reg:  offset and length of register set for QSCRATCH 
>> wrapper
>> +- reg-names:should be "qscratch"
> reg-names is pointless for a single range.
Ok. Will change this.

>
>> +- power-domains:specifies a phandle to PM domain provider node
>> +- clocks:   list of phandle + clock-specifier pairs
> How many clocks and what are they?
I will add description of the clocks in next version of patchset.


>
>> +- assigned-clocks:  should be:
>> +MOCK_UTMI_CLK
>> +MASTER_CLK
>> +- assigned-clock-rates: should be:
>> +19.2Mhz (19200) for MOCK_UTMI_CLK
>> +>=125Mhz (12500) for MASTER_CLK in SS 
>> mode
>> +>=60Mhz (6000) for MASTER_CLK in HS mode
>> +
>> +Optional properties:
>> +- resets:   list of phandle and reset specifier pairs
>> +- interrupts:   specifies interrupts from controller wrapper 
>> used
>> +to wakeup from low power/susepnd state. Must contain
>> +one or more entry for interrupt-names property
>> +- interrupt-names:  Must include the following entries:
>> +- "hs_phy_irq": The interrupt that is asserted when a
>> +   wakeup event is received on USB2 bus
>> +- "ss_phy_irq": The interrupt that is asserted when a
>> +   wakeup event is received on USB3 bus
>> +- "dm_hs_phy_irq" and "dp_hs_phy_irq": Separate
>> +   interrupts for any wakeup event on DM and DP lines
>> +- qcom,select-utmi-as-pipe-clk: if present, disable USB3 pipe_clk 
>> requirement.
>> +Used when dwc3 operates without SSPHY and only
>> +HS/FS/LS modes are supported.
>>  
>>  Required child node:
>>  A child node must exist to represent the core DWC3 IP block. The name of
>>  the node is not important. The content of the node is defined in dwc3.txt.
>>  
>>  Phy documentation is provided in the following places:
>> -Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
>> +Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt   - USB3 QMP PHY
>> +Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt - USB2 QUSB2 PHY

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v1 1/2] dt-bindings: usb: Update documentation for Qualcomm DWC3 driver

[Manu Gautam]

Hi,


On 3/18/2018 6:19 PM, Rob Herring wrote:
> On Tue, Mar 13, 2018 at 04:06:00PM +0530, Manu Gautam wrote:
>> Existing documentation has lot of incorrect information as it
>> was originally added for a driver that no longer exists.
>>
>> Signed-off-by: Manu Gautam 
>> ---
>>  .../devicetree/bindings/usb/qcom,dwc3.txt  | 87 
>> +++---
>>  1 file changed, 59 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
>> b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>> index bc8a2fa..df312f7 100644
>> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>> @@ -1,54 +1,85 @@
>>  Qualcomm SuperSpeed DWC3 USB SoC controller
>>  
>>  Required properties:
>> -- compatible:   should contain "qcom,dwc3"
>> -- clocks:   A list of phandle + clock-specifier pairs for the
>> -clocks listed in clock-names
>> -- clock-names:  Should contain the following:
>> -  "core"Master/Core clock, have to be >= 125 MHz for SS
>> -operation and >= 60MHz for HS operation
>> -
>> -Optional clocks:
>> -  "iface"   System bus AXI clock.  Not present on all platforms
>> -  "sleep"   Sleep clock, used when USB3 core goes into low
>> -power mode (U3).
>> +- compatible:   should contain "qcom,dwc3"
>> +- reg:  offset and length of register set for QSCRATCH 
>> wrapper
>> +- reg-names:should be "qscratch"
> reg-names is pointless for a single range.
Ok. Will change this.

>
>> +- power-domains:specifies a phandle to PM domain provider node
>> +- clocks:   list of phandle + clock-specifier pairs
> How many clocks and what are they?
I will add description of the clocks in next version of patchset.


>
>> +- assigned-clocks:  should be:
>> +MOCK_UTMI_CLK
>> +MASTER_CLK
>> +- assigned-clock-rates: should be:
>> +19.2Mhz (19200) for MOCK_UTMI_CLK
>> +>=125Mhz (12500) for MASTER_CLK in SS 
>> mode
>> +>=60Mhz (6000) for MASTER_CLK in HS mode
>> +
>> +Optional properties:
>> +- resets:   list of phandle and reset specifier pairs
>> +- interrupts:   specifies interrupts from controller wrapper 
>> used
>> +to wakeup from low power/susepnd state. Must contain
>> +one or more entry for interrupt-names property
>> +- interrupt-names:  Must include the following entries:
>> +- "hs_phy_irq": The interrupt that is asserted when a
>> +   wakeup event is received on USB2 bus
>> +- "ss_phy_irq": The interrupt that is asserted when a
>> +   wakeup event is received on USB3 bus
>> +- "dm_hs_phy_irq" and "dp_hs_phy_irq": Separate
>> +   interrupts for any wakeup event on DM and DP lines
>> +- qcom,select-utmi-as-pipe-clk: if present, disable USB3 pipe_clk 
>> requirement.
>> +Used when dwc3 operates without SSPHY and only
>> +HS/FS/LS modes are supported.
>>  
>>  Required child node:
>>  A child node must exist to represent the core DWC3 IP block. The name of
>>  the node is not important. The content of the node is defined in dwc3.txt.
>>  
>>  Phy documentation is provided in the following places:
>> -Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
>> +Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt   - USB3 QMP PHY
>> +Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt - USB2 QUSB2 PHY

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] ASoC: uniphier: evea: add switch for changing source of line-in

[Katsuhiro Suzuki]

Hello Mark,

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, March 15, 2018 1:26 AM
> To: Suzuki, Katsuhiro 
> Cc: alsa-de...@alsa-project.org; Masami Hiramatsu
;
> Jassi Brar ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ASoC: uniphier: evea: add switch for changing source of
line-in
> 
> On Wed, Mar 14, 2018 at 09:39:00PM +0900, Katsuhiro Suzuki wrote:
> > This patch adds mixer switch for changing audio source of line-in.
> > We can choose one of LIN1, 2, 3, default is LIN1.
> 
> I'll apply for now but this should really be a DAPM control so that we
> can power down things connected to the disconnected line inputs when
> recording.

Thanks a lot for your suggestion. I tried to change the implementation to DAPM
control as follows:

--
static const char * const linsw1_sel1_text[] = {
"LIN1", "LIN2", "LIN3"
};

static SOC_ENUM_SINGLE_DECL(linsw1_sel1_enum,
ALINSW1, ALINSW1_SEL1_SHIFT,
linsw1_sel1_text);

static const struct snd_kcontrol_new linesw1_mux =
SOC_DAPM_ENUM("Line In 1 Source", linsw1_sel1_enum);

static const struct snd_soc_dapm_widget evea_widgets[] = {
SND_SOC_DAPM_ADC("ADC", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_MUX("Line In 1 Mux", SND_SOC_NOPM, 0, 0, _mux),
SND_SOC_DAPM_INPUT("LIN1_LP"),
SND_SOC_DAPM_INPUT("LIN1_RP"),
SND_SOC_DAPM_INPUT("LIN2_LP"),
SND_SOC_DAPM_INPUT("LIN2_RP"),
SND_SOC_DAPM_INPUT("LIN3_LP"),
SND_SOC_DAPM_INPUT("LIN3_RP"),

SND_SOC_DAPM_DAC("DAC HP", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_DAC("DAC LO1", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_DAC("DAC LO2", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_OUTPUT("HP1_L"),
SND_SOC_DAPM_OUTPUT("HP1_R"),
SND_SOC_DAPM_OUTPUT("LO2_L"),
SND_SOC_DAPM_OUTPUT("LO2_R"),
};

static const struct snd_soc_dapm_route evea_routes[] = {
{ "Line In 1", NULL, "ADC" },
{ "ADC", NULL, "Line In 1 Mux" },
{ "Line In 1 Mux", NULL, "LIN1_LP" },
{ "Line In 1 Mux", NULL, "LIN1_RP" },
{ "Line In 1 Mux", NULL, "LIN2_LP" },
{ "Line In 1 Mux", NULL, "LIN2_RP" },
{ "Line In 1 Mux", NULL, "LIN3_LP" },
{ "Line In 1 Mux", NULL, "LIN3_RP" },

{ "DAC HP", NULL, "Headphone 1" },
{ "DAC LO1", NULL, "Line Out 1" },
{ "DAC LO2", NULL, "Line Out 2" },
{ "HP1_L", NULL, "DAC HP" },
{ "HP1_R", NULL, "DAC HP" },
{ "LO2_L", NULL, "DAC LO2" },
{ "LO2_R", NULL, "DAC LO2" },
};
--

I can see the value of ALINSW1 register at 'Line In 1 Mux',0 using
  amixer get 'Line In 1 Mux',0

But I can't change the value.
  amixer set 'Line In 1 Mux',0 LIN2
  Simple mixer control 'Line In 1 Mux',0
Capabilities: enum
Items: 'LIN1' 'LIN2' 'LIN3'
Item0: 'LIN1'

Would you tell me what is wrong...


Regards,
--
Katsuhiro Suzuki

Re: [PATCH] ASoC: uniphier: evea: add switch for changing source of line-in

[Katsuhiro Suzuki]

Hello Mark,

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, March 15, 2018 1:26 AM
> To: Suzuki, Katsuhiro 
> Cc: alsa-de...@alsa-project.org; Masami Hiramatsu
;
> Jassi Brar ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ASoC: uniphier: evea: add switch for changing source of
line-in
> 
> On Wed, Mar 14, 2018 at 09:39:00PM +0900, Katsuhiro Suzuki wrote:
> > This patch adds mixer switch for changing audio source of line-in.
> > We can choose one of LIN1, 2, 3, default is LIN1.
> 
> I'll apply for now but this should really be a DAPM control so that we
> can power down things connected to the disconnected line inputs when
> recording.

Thanks a lot for your suggestion. I tried to change the implementation to DAPM
control as follows:

--
static const char * const linsw1_sel1_text[] = {
"LIN1", "LIN2", "LIN3"
};

static SOC_ENUM_SINGLE_DECL(linsw1_sel1_enum,
ALINSW1, ALINSW1_SEL1_SHIFT,
linsw1_sel1_text);

static const struct snd_kcontrol_new linesw1_mux =
SOC_DAPM_ENUM("Line In 1 Source", linsw1_sel1_enum);

static const struct snd_soc_dapm_widget evea_widgets[] = {
SND_SOC_DAPM_ADC("ADC", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_MUX("Line In 1 Mux", SND_SOC_NOPM, 0, 0, _mux),
SND_SOC_DAPM_INPUT("LIN1_LP"),
SND_SOC_DAPM_INPUT("LIN1_RP"),
SND_SOC_DAPM_INPUT("LIN2_LP"),
SND_SOC_DAPM_INPUT("LIN2_RP"),
SND_SOC_DAPM_INPUT("LIN3_LP"),
SND_SOC_DAPM_INPUT("LIN3_RP"),

SND_SOC_DAPM_DAC("DAC HP", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_DAC("DAC LO1", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_DAC("DAC LO2", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_OUTPUT("HP1_L"),
SND_SOC_DAPM_OUTPUT("HP1_R"),
SND_SOC_DAPM_OUTPUT("LO2_L"),
SND_SOC_DAPM_OUTPUT("LO2_R"),
};

static const struct snd_soc_dapm_route evea_routes[] = {
{ "Line In 1", NULL, "ADC" },
{ "ADC", NULL, "Line In 1 Mux" },
{ "Line In 1 Mux", NULL, "LIN1_LP" },
{ "Line In 1 Mux", NULL, "LIN1_RP" },
{ "Line In 1 Mux", NULL, "LIN2_LP" },
{ "Line In 1 Mux", NULL, "LIN2_RP" },
{ "Line In 1 Mux", NULL, "LIN3_LP" },
{ "Line In 1 Mux", NULL, "LIN3_RP" },

{ "DAC HP", NULL, "Headphone 1" },
{ "DAC LO1", NULL, "Line Out 1" },
{ "DAC LO2", NULL, "Line Out 2" },
{ "HP1_L", NULL, "DAC HP" },
{ "HP1_R", NULL, "DAC HP" },
{ "LO2_L", NULL, "DAC LO2" },
{ "LO2_R", NULL, "DAC LO2" },
};
--

I can see the value of ALINSW1 register at 'Line In 1 Mux',0 using
  amixer get 'Line In 1 Mux',0

But I can't change the value.
  amixer set 'Line In 1 Mux',0 LIN2
  Simple mixer control 'Line In 1 Mux',0
Capabilities: enum
Items: 'LIN1' 'LIN2' 'LIN3'
Item0: 'LIN1'

Would you tell me what is wrong...


Regards,
--
Katsuhiro Suzuki

Re: [PATCH 18/19] clocksource: add timer-nationalchip.c

[Mark Rutland]

Hi,

On Mon, Mar 19, 2018 at 03:51:40AM +0800, Guo Ren wrote:
> +#define NC_VA_COUNTER_1_STATUS   (void *)(timer_reg + 0x00)
> +#define NC_VA_COUNTER_1_VALUE(void *)(timer_reg + 0x04)
> +#define NC_VA_COUNTER_1_CONTROL  (void *)(timer_reg + 0x10)
> +#define NC_VA_COUNTER_1_CONFIG   (void *)(timer_reg + 0x20)
> +#define NC_VA_COUNTER_1_PRE  (void *)(timer_reg + 0x24)
> +#define NC_VA_COUNTER_1_INI  (void *)(timer_reg + 0x28)
> +#define NC_VA_COUNTER_2_STATUS   (void *)(timer_reg + 0x40)
> +#define NC_VA_COUNTER_2_VALUE(void *)(timer_reg + 0x44)
> +#define NC_VA_COUNTER_2_CONTROL  (void *)(timer_reg + 0x50)
> +#define NC_VA_COUNTER_2_CONFIG   (void *)(timer_reg + 0x60)
> +#define NC_VA_COUNTER_2_PRE  (void *)(timer_reg + 0x64)
> +#define NC_VA_COUNTER_2_INI  (void *)(timer_reg + 0x68)
> +#define NC_VA_COUNTER_3_STATUS   (void *)(timer_reg + 0x80)
> +#define NC_VA_COUNTER_3_VALUE(void *)(timer_reg + 0x84)
> +#define NC_VA_COUNTER_3_CONTROL  (void *)(timer_reg + 0x90)
> +#define NC_VA_COUNTER_3_CONFIG   (void *)(timer_reg + 0xa0)
> +#define NC_VA_COUNTER_3_PRE  (void *)(timer_reg + 0xa4)
> +#define NC_VA_COUNTER_3_INI  (void *)(timer_reg + 0xa8)

Please define the offsets alone, e.g.

#define NC_VA_COUNTER_1_STATUS  0x00
#define NC_VA_COUNTER_1_VALUE   0x04

... the base address should be added when calling the io accessor. Please see
below.

> +static unsigned int timer_reg;

This should be a void __iomem *, e.g.

static void __iomem *timer_base;

... though it would be better for this to be associated with the instance of
the clock_event_device, so that there can be multiple instances in a system.

> +
> +static inline void timer_reset(void)
> +{
> + __raw_writel(0x1,   NC_VA_COUNTER_1_CONTROL);
> + __raw_writel(0x0,   NC_VA_COUNTER_1_CONTROL);
> + __raw_writel(0x3,   NC_VA_COUNTER_1_CONFIG);
> + __raw_writel(26,NC_VA_COUNTER_1_PRE);

Should this be 26 or 0x26?

It would be nice to have mnemonics for these magic numbers.

Please use writel_relaxed() rather than __raw_writel(). e.g.

writel_relaxed(0x1, timer_base + NC_VA_COUNTER_1_CONTROL);
writel_relaxed(0x0, timer_base + NC_VA_COUNTER_1_CONTROL);
writel_relaxed(0x3, timer_base + NC_VA_COUNTER_1_CONTROL);
writel_relaxed(26, timer_base + NC_VA_COUNTER_1_PRE);

[...]

> +static int __init nc_timer_init(struct device_node *np)
> +{
> + unsigned int irq;
> + unsigned int freq;
> +
> + /* parse from devicetree */
> + timer_reg = (unsigned int) of_iomap(np, 0);
> + if (!timer_reg)
> + panic("%s, of_iomap err.\n", __func__);
> +
> + irq = irq_of_parse_and_map(np, 0);
> + if (!irq)
> + panic("%s, irq_parse err.\n", __func__);
> +
> + if (of_property_read_u32(np, "clock-frequency", ))
> + panic("%s, clock-frequency error.\n", __func__);
> +
> + pr_info("Nationalchip Timer Init, reg: %x, irq: %d, freq: %d.\n",
> + timer_reg, irq, freq);
> +
> + /* setup irq */
> + if (request_irq(irq, timer_interrupt, IRQF_TIMER, np->name, _ced))
> + panic("%s timer_interrupt error.\n", __func__);
> +
> + /* register */
> + clockevents_config_and_register(_ced, freq, 1, ULONG_MAX);
> +
> + nc_csd_enable();
> + clocksource_mmio_init(NC_VA_COUNTER_2_VALUE, "nationalchip-clksource", 
> freq, 200, 32, clocksource_mmio_readl_up);
> +
> + sched_clock_register(nc_sched_clock_read, 32, freq);
> +
> + return 0;
> +}
> +CLOCKSOURCE_OF_DECLARE(nc_timer, "nationalchip,timer-v1", nc_timer_init);

This needs a devicetree binding document. Please see 
Documentation/devicetree/bindings/submitting-patches.txt.

Thanks,
Mark

Re: [PATCH 18/19] clocksource: add timer-nationalchip.c

[Mark Rutland]

Hi,

On Mon, Mar 19, 2018 at 03:51:40AM +0800, Guo Ren wrote:
> +#define NC_VA_COUNTER_1_STATUS   (void *)(timer_reg + 0x00)
> +#define NC_VA_COUNTER_1_VALUE(void *)(timer_reg + 0x04)
> +#define NC_VA_COUNTER_1_CONTROL  (void *)(timer_reg + 0x10)
> +#define NC_VA_COUNTER_1_CONFIG   (void *)(timer_reg + 0x20)
> +#define NC_VA_COUNTER_1_PRE  (void *)(timer_reg + 0x24)
> +#define NC_VA_COUNTER_1_INI  (void *)(timer_reg + 0x28)
> +#define NC_VA_COUNTER_2_STATUS   (void *)(timer_reg + 0x40)
> +#define NC_VA_COUNTER_2_VALUE(void *)(timer_reg + 0x44)
> +#define NC_VA_COUNTER_2_CONTROL  (void *)(timer_reg + 0x50)
> +#define NC_VA_COUNTER_2_CONFIG   (void *)(timer_reg + 0x60)
> +#define NC_VA_COUNTER_2_PRE  (void *)(timer_reg + 0x64)
> +#define NC_VA_COUNTER_2_INI  (void *)(timer_reg + 0x68)
> +#define NC_VA_COUNTER_3_STATUS   (void *)(timer_reg + 0x80)
> +#define NC_VA_COUNTER_3_VALUE(void *)(timer_reg + 0x84)
> +#define NC_VA_COUNTER_3_CONTROL  (void *)(timer_reg + 0x90)
> +#define NC_VA_COUNTER_3_CONFIG   (void *)(timer_reg + 0xa0)
> +#define NC_VA_COUNTER_3_PRE  (void *)(timer_reg + 0xa4)
> +#define NC_VA_COUNTER_3_INI  (void *)(timer_reg + 0xa8)

Please define the offsets alone, e.g.

#define NC_VA_COUNTER_1_STATUS  0x00
#define NC_VA_COUNTER_1_VALUE   0x04

... the base address should be added when calling the io accessor. Please see
below.

> +static unsigned int timer_reg;

This should be a void __iomem *, e.g.

static void __iomem *timer_base;

... though it would be better for this to be associated with the instance of
the clock_event_device, so that there can be multiple instances in a system.

> +
> +static inline void timer_reset(void)
> +{
> + __raw_writel(0x1,   NC_VA_COUNTER_1_CONTROL);
> + __raw_writel(0x0,   NC_VA_COUNTER_1_CONTROL);
> + __raw_writel(0x3,   NC_VA_COUNTER_1_CONFIG);
> + __raw_writel(26,NC_VA_COUNTER_1_PRE);

Should this be 26 or 0x26?

It would be nice to have mnemonics for these magic numbers.

Please use writel_relaxed() rather than __raw_writel(). e.g.

writel_relaxed(0x1, timer_base + NC_VA_COUNTER_1_CONTROL);
writel_relaxed(0x0, timer_base + NC_VA_COUNTER_1_CONTROL);
writel_relaxed(0x3, timer_base + NC_VA_COUNTER_1_CONTROL);
writel_relaxed(26, timer_base + NC_VA_COUNTER_1_PRE);

[...]

> +static int __init nc_timer_init(struct device_node *np)
> +{
> + unsigned int irq;
> + unsigned int freq;
> +
> + /* parse from devicetree */
> + timer_reg = (unsigned int) of_iomap(np, 0);
> + if (!timer_reg)
> + panic("%s, of_iomap err.\n", __func__);
> +
> + irq = irq_of_parse_and_map(np, 0);
> + if (!irq)
> + panic("%s, irq_parse err.\n", __func__);
> +
> + if (of_property_read_u32(np, "clock-frequency", ))
> + panic("%s, clock-frequency error.\n", __func__);
> +
> + pr_info("Nationalchip Timer Init, reg: %x, irq: %d, freq: %d.\n",
> + timer_reg, irq, freq);
> +
> + /* setup irq */
> + if (request_irq(irq, timer_interrupt, IRQF_TIMER, np->name, _ced))
> + panic("%s timer_interrupt error.\n", __func__);
> +
> + /* register */
> + clockevents_config_and_register(_ced, freq, 1, ULONG_MAX);
> +
> + nc_csd_enable();
> + clocksource_mmio_init(NC_VA_COUNTER_2_VALUE, "nationalchip-clksource", 
> freq, 200, 32, clocksource_mmio_readl_up);
> +
> + sched_clock_register(nc_sched_clock_read, 32, freq);
> +
> + return 0;
> +}
> +CLOCKSOURCE_OF_DECLARE(nc_timer, "nationalchip,timer-v1", nc_timer_init);

This needs a devicetree binding document. Please see 
Documentation/devicetree/bindings/submitting-patches.txt.

Thanks,
Mark

[PATCH][v4] PM / sleep: Do not delay the synchronization of MTRR during resume

[Yu Chen]

From: Chen Yu 

Sometimes it is too late for the APs to adjust their MTRRs
to the valid ones saved before suspend - currently this
action is performed by set_mtrr_state() after all the APs
have been brought up. In some cases the BIOS might scribble
the MTRR across suspend, as a result we might get invalid
MTRR after resumed back, thus every instruction runs on
this AP would be extremely slow if it happended to be a
'uncached' MTRR. It is necessary to synchronize the MTRR
as early as possible to get it fixed during each AP's
online - this is what this patch does.

Moreover, since we have put the synchronization earlier, there is
a side effect that, during each AP's online, the previous APs already
been brought up will be forced to run mtrr_rendezvous_handler() and
reprogram the MTRR again and again. This symptom can be mitigated
by checking if this cpu has already run the synchronization
during the enable_nonboot_cpus() stage, if it is, we can safely
bypass the reprogramming action. (We can not bypass the
mtrr_rendezvous_handler(), because the other online cpus must be
stopped running the VMX transaction while one cpu is updating
its MTRR, which is described here:
Commit d0af9eed5aa9 ("x86, pat/mtrr: Rendezvous all the cpus for
MTRR/PAT init")

This patch does not impact the normal boot up nor cpu hotplug.

On a platform with invalid MTRR after resumed,
1. before this patch:
   [  619.810899] Enabling non-boot CPUs ...
   [  619.825537] smpboot: Booting Node 0 Processor 1 APIC 0x2
   [  621.723809] CPU1 is up
   [  621.840228] smpboot: Booting Node 0 Processor 3 APIC 0x3
   [  626.690900] CPU3 is up

It took cpu1 621.723809 - 619.825537 = 1898.272 ms, and
cpu3 626.690900 - 621.840228 = 4850.672 ms.

2. after this patch:
   [  106.931790] smpboot: Booting Node 0 Processor 1 APIC 0x2
   [  106.948360] CPU1 is up
   [  106.986534] smpboot: Booting Node 0 Processor 3 APIC 0x3
   [  106.990702] CPU3 is up

It took cpu1 106.948360 - 106.931790 = 16.57 ms, and
cpu3 106.990702 - 106.986534 = 4.16 ms.

For comparison, suspend on a 88 cpus Xeon Broadwell
platform is also tested, and the result shows that
with this patch applied, the overall APs online time has
decreased a little bit, this is because since the synchronizing
of MTRR has been performed earlier, the MTRRs get updated
to the correct value earlier.

Tested 5 times, data illustrated below:

1. before this patch:

[   64.549430] Enabling non-boot CPUs ...
[   66.253304] End enabling non-boot CPUs
overall cpu online: 1.703874 second

[   62.159063] Enabling non-boot CPUs ...
[   64.483443] End enabling non-boot CPUs
overall cpu online: 2.32438 second

[   58.351449] Enabling non-boot CPUs ...
[   60.796951] End enabling non-boot CPUs
overall cpu online: 2.445502 second

[   64.491317] Enabling non-boot CPUs ...
[   66.996208] End enabling non-boot CPUs
overall cpu online: 2.504891 second

[   60.593235] Enabling non-boot CPUs ...
[   63.397886] End enabling non-boot CPUs
overall cpu online: 2.804651 second

Average: 2.3566596 second

2. after this patch:

[   66.077368] Enabling non-boot CPUs ...
[   68.343374] End enabling non-boot CPUs
overall cpu online: 2.266006 second

[   64.594605] Enabling non-boot CPUs ...
[   66.092688] End enabling non-boot CPUs
overall cpu online: 1.498083 second

[   64.778546] Enabling non-boot CPUs ...
[   66.277577] End enabling non-boot CPUs
overall cpu online: 1.499031 second

[   63.773091] Enabling non-boot CPUs ...
[   65.601637] End enabling non-boot CPUs
overall cpu online: 1.828546 second

[   64.638855] Enabling non-boot CPUs ...
[   66.327098] End enabling non-boot CPUs
overall cpu online: 1.688243 second

Average: 1.7559818 second

With the patch applied, the cpu online time during resume
has decreased by about 6 seconds on a bogus MTRR platform,
and decreased by about 600ms on a 88 cpus Xeon platform after
resumed.

Quote from Lukas:
"Just for the record, this series cuts down resume time from system sleep
by 4-5 seconds on my MacBookPro9,1.  Great work, looking forward to this
being respun and merged."

Suggested-by: Rafael J. Wysocki 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Rui Zhang 
Tested-by: Lukas Wunner 
Signed-off-by: Chen Yu 
---
 arch/x86/include/asm/mtrr.h |  2 ++
 arch/x86/kernel/cpu/mtrr/main.c | 29 ++---
 arch/x86/kernel/smpboot.c   |  4 ++--
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index dbff1456d215..182cc96f79cb 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -49,6 +49,7 @@ extern void mtrr_aps_init(void);
 extern void mtrr_bp_restore(void);
 extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 extern int amd_special_default_mtrr(void);
+extern void set_mtrr_aps_check(bool enable);
 #  else
 

[PATCH][v4] PM / sleep: Do not delay the synchronization of MTRR during resume

[Yu Chen]

From: Chen Yu 

Sometimes it is too late for the APs to adjust their MTRRs
to the valid ones saved before suspend - currently this
action is performed by set_mtrr_state() after all the APs
have been brought up. In some cases the BIOS might scribble
the MTRR across suspend, as a result we might get invalid
MTRR after resumed back, thus every instruction runs on
this AP would be extremely slow if it happended to be a
'uncached' MTRR. It is necessary to synchronize the MTRR
as early as possible to get it fixed during each AP's
online - this is what this patch does.

Moreover, since we have put the synchronization earlier, there is
a side effect that, during each AP's online, the previous APs already
been brought up will be forced to run mtrr_rendezvous_handler() and
reprogram the MTRR again and again. This symptom can be mitigated
by checking if this cpu has already run the synchronization
during the enable_nonboot_cpus() stage, if it is, we can safely
bypass the reprogramming action. (We can not bypass the
mtrr_rendezvous_handler(), because the other online cpus must be
stopped running the VMX transaction while one cpu is updating
its MTRR, which is described here:
Commit d0af9eed5aa9 ("x86, pat/mtrr: Rendezvous all the cpus for
MTRR/PAT init")

This patch does not impact the normal boot up nor cpu hotplug.

On a platform with invalid MTRR after resumed,
1. before this patch:
   [  619.810899] Enabling non-boot CPUs ...
   [  619.825537] smpboot: Booting Node 0 Processor 1 APIC 0x2
   [  621.723809] CPU1 is up
   [  621.840228] smpboot: Booting Node 0 Processor 3 APIC 0x3
   [  626.690900] CPU3 is up

It took cpu1 621.723809 - 619.825537 = 1898.272 ms, and
cpu3 626.690900 - 621.840228 = 4850.672 ms.

2. after this patch:
   [  106.931790] smpboot: Booting Node 0 Processor 1 APIC 0x2
   [  106.948360] CPU1 is up
   [  106.986534] smpboot: Booting Node 0 Processor 3 APIC 0x3
   [  106.990702] CPU3 is up

It took cpu1 106.948360 - 106.931790 = 16.57 ms, and
cpu3 106.990702 - 106.986534 = 4.16 ms.

For comparison, suspend on a 88 cpus Xeon Broadwell
platform is also tested, and the result shows that
with this patch applied, the overall APs online time has
decreased a little bit, this is because since the synchronizing
of MTRR has been performed earlier, the MTRRs get updated
to the correct value earlier.

Tested 5 times, data illustrated below:

1. before this patch:

[   64.549430] Enabling non-boot CPUs ...
[   66.253304] End enabling non-boot CPUs
overall cpu online: 1.703874 second

[   62.159063] Enabling non-boot CPUs ...
[   64.483443] End enabling non-boot CPUs
overall cpu online: 2.32438 second

[   58.351449] Enabling non-boot CPUs ...
[   60.796951] End enabling non-boot CPUs
overall cpu online: 2.445502 second

[   64.491317] Enabling non-boot CPUs ...
[   66.996208] End enabling non-boot CPUs
overall cpu online: 2.504891 second

[   60.593235] Enabling non-boot CPUs ...
[   63.397886] End enabling non-boot CPUs
overall cpu online: 2.804651 second

Average: 2.3566596 second

2. after this patch:

[   66.077368] Enabling non-boot CPUs ...
[   68.343374] End enabling non-boot CPUs
overall cpu online: 2.266006 second

[   64.594605] Enabling non-boot CPUs ...
[   66.092688] End enabling non-boot CPUs
overall cpu online: 1.498083 second

[   64.778546] Enabling non-boot CPUs ...
[   66.277577] End enabling non-boot CPUs
overall cpu online: 1.499031 second

[   63.773091] Enabling non-boot CPUs ...
[   65.601637] End enabling non-boot CPUs
overall cpu online: 1.828546 second

[   64.638855] Enabling non-boot CPUs ...
[   66.327098] End enabling non-boot CPUs
overall cpu online: 1.688243 second

Average: 1.7559818 second

With the patch applied, the cpu online time during resume
has decreased by about 6 seconds on a bogus MTRR platform,
and decreased by about 600ms on a 88 cpus Xeon platform after
resumed.

Quote from Lukas:
"Just for the record, this series cuts down resume time from system sleep
by 4-5 seconds on my MacBookPro9,1.  Great work, looking forward to this
being respun and merged."

Suggested-by: Rafael J. Wysocki 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Rui Zhang 
Tested-by: Lukas Wunner 
Signed-off-by: Chen Yu 
---
 arch/x86/include/asm/mtrr.h |  2 ++
 arch/x86/kernel/cpu/mtrr/main.c | 29 ++---
 arch/x86/kernel/smpboot.c   |  4 ++--
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index dbff1456d215..182cc96f79cb 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -49,6 +49,7 @@ extern void mtrr_aps_init(void);
 extern void mtrr_bp_restore(void);
 extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 extern int amd_special_default_mtrr(void);
+extern void set_mtrr_aps_check(bool enable);
 #  else
 static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
 {
@@ -93,6 +94,7 @@ static inline void mtrr_bp_init(void)
 #define 

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Daniel Drake]

On Mon, Mar 19, 2018 at 6:36 AM, Rafael J. Wysocki  wrote:
> On Fri, Mar 16, 2018 at 10:06 AM, Mathias Nyman
>  wrote:
>> Adding Rafael directly to CC
>>
>> In short, if _S3D and _S3W are missing in DSDT then a PCI device
>> stays in D0 during suspend in Linux, but goes to D3 in Windows.
>>
>> USB wake doesn't work in Geminilake because of this.
>>
>> Should this be changed? reasoning below.
>
> It can be changed if that doesn't cause problems to happen.

I double checked that Windows 10 is going into S3 suspend and that USB
wakeup works fine on this platform - it works fine there.
Device manager for the XHCI controller clearly shows D3 being used for
S3 suspend: https://imgur.com/lF9U3V0

Current power state:
D0

Power capabilities:
0089
PDCAP_D0_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D3_SUPPORTED

Power state mappings:
S0 -> D0
S1 -> Unspecified
S2 -> Unspecified
S3 -> D3
S4 -> D3
S5 -> D3

The biggest risk of my proposed change is that we would now end up
putting a wakeup-enabled device into a too low power state where it
can no longer wake up the system. On the other hand, it solves this
issue affecting 2 different vendors, and may even result in some power
savings in general.

Perhaps we can consider the change for inclusion in Linux-4.17, giving
2-3 months of testing time.

I'll submit the patch shortly.

Thanks
Daniel

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Daniel Drake]

On Mon, Mar 19, 2018 at 6:36 AM, Rafael J. Wysocki  wrote:
> On Fri, Mar 16, 2018 at 10:06 AM, Mathias Nyman
>  wrote:
>> Adding Rafael directly to CC
>>
>> In short, if _S3D and _S3W are missing in DSDT then a PCI device
>> stays in D0 during suspend in Linux, but goes to D3 in Windows.
>>
>> USB wake doesn't work in Geminilake because of this.
>>
>> Should this be changed? reasoning below.
>
> It can be changed if that doesn't cause problems to happen.

I double checked that Windows 10 is going into S3 suspend and that USB
wakeup works fine on this platform - it works fine there.
Device manager for the XHCI controller clearly shows D3 being used for
S3 suspend: https://imgur.com/lF9U3V0

Current power state:
D0

Power capabilities:
0089
PDCAP_D0_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D3_SUPPORTED

Power state mappings:
S0 -> D0
S1 -> Unspecified
S2 -> Unspecified
S3 -> D3
S4 -> D3
S5 -> D3

The biggest risk of my proposed change is that we would now end up
putting a wakeup-enabled device into a too low power state where it
can no longer wake up the system. On the other hand, it solves this
issue affecting 2 different vendors, and may even result in some power
savings in general.

Perhaps we can consider the change for inclusion in Linux-4.17, giving
2-3 months of testing time.

I'll submit the patch shortly.

Thanks
Daniel

Re: [PATCH v5 3/4] clk: lpc32xx: Set name of regmap_config

[JeffyChen]

Hi Vladimir,

On 03/19/2018 05:57 AM, Vladimir Zapolskiy wrote:

>  static struct regmap_config lpc32xx_scb_regmap_config = {
>+   .name = "lpc32xx-scb",

please rename it to "scb", LPC32xx SoC name is already known from the context.

When it's done, feel free to add to the next version my

Acked-by: Vladimir Zapolskiy



ok, will do, thanks:)

Re: [PATCH v5 3/4] clk: lpc32xx: Set name of regmap_config

[JeffyChen]

Hi Vladimir,

On 03/19/2018 05:57 AM, Vladimir Zapolskiy wrote:

>  static struct regmap_config lpc32xx_scb_regmap_config = {
>+   .name = "lpc32xx-scb",

please rename it to "scb", LPC32xx SoC name is already known from the context.

When it's done, feel free to add to the next version my

Acked-by: Vladimir Zapolskiy



ok, will do, thanks:)

[PATCH v6] clk: lpc32xx: Set name of regmap_config

[Jeffy Chen]

We are now allowing to register debugfs without a valid device, and not
having a valid name will end up using "dummy*" to create debugfs dir.

Signed-off-by: Jeffy Chen 
Acked-by: Vladimir Zapolskiy 
---

Changes in v6:
Modify name as Vladimir suggested.

 drivers/clk/nxp/clk-lpc32xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index f5d815f577e0..5eeecee17b69 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -67,6 +67,7 @@
 #define LPC32XX_USB_CLK_STS0xF8
 
 static struct regmap_config lpc32xx_scb_regmap_config = {
+   .name = "scb",
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
-- 
2.11.0

[PATCH v6] clk: lpc32xx: Set name of regmap_config

[Jeffy Chen]

We are now allowing to register debugfs without a valid device, and not
having a valid name will end up using "dummy*" to create debugfs dir.

Signed-off-by: Jeffy Chen 
Acked-by: Vladimir Zapolskiy 
---

Changes in v6:
Modify name as Vladimir suggested.

 drivers/clk/nxp/clk-lpc32xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index f5d815f577e0..5eeecee17b69 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -67,6 +67,7 @@
 #define LPC32XX_USB_CLK_STS0xF8
 
 static struct regmap_config lpc32xx_scb_regmap_config = {
+   .name = "scb",
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
-- 
2.11.0

Re: linux-next: manual merge of the kvms390 tree with the nds32 tree

[Stephen Rothwell]

Hi all,

On Mon, 26 Feb 2018 13:34:45 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   drivers/video/console/Kconfig
> 
> between commit:
> 
>   2312dbf7462b ("drivers/video/concole: add negative dependency for 
> VGA_CONSOLE on nds32")
> 
> from the nds32 tree and commits:
> 
>   8da93aca3729 ("Kconfig : Remove HAS_IOMEM dependency for Graphics support")
>   416b744f4494 ("s390/setup : enable display support for KVM guest")
> 
> from the kvms390 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/video/console/Kconfig
> index 27bb893cf6b2,b9c2c916247e..
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@@ -9,7 -9,7 +9,7 @@@ config VGA_CONSOL
>   depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
>   !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
>   (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) 
> && \
> - !ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !NDS32
>  -!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && HAS_IOMEM && !S390
> ++!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !NDS32 && 
> HAS_IOMEM && !S390
>   default y
>   help
> Saying Y here will allow you to use Linux in text mode through a

This conflict is now between the kvm tree and the nds32 tree.

-- 
Cheers,
Stephen Rothwell


pgpVwDDAbzRXf.pgp
Description: OpenPGP digital signature

[PATCH 1/2] staging: typec: rt1711h typec chip driver

[ShuFan Lee]

From: ShuFan Lee 

Richtek RT1711H Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and
USB Type-C functionalities.
Add definition of TCPC_CC_STATUS_TOGGLING.

Signed-off-by: ShuFan Lee 
---
 drivers/staging/typec/Kconfig |   8 +
 drivers/staging/typec/Makefile|   1 +
 drivers/staging/typec/tcpci.h |   1 +
 drivers/staging/typec/tcpci_rt1711h.c | 329 ++
 4 files changed, 339 insertions(+)
 create mode 100644 drivers/staging/typec/tcpci_rt1711h.c

 changelogs between v1 and v2
 - use gpiod_* instead of gpio_*

diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 5359f556d203..3aa981fbc8f5 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -9,6 +9,14 @@ config TYPEC_TCPCI
help
  Type-C Port Controller driver for TCPCI-compliant controller.
 
+config TYPEC_RT1711H
+   tristate "Richtek RT1711H Type-C chip driver"
+   select TYPEC_TCPCI
+   help
+ Richtek RT1711H Type-C chip driver that works with
+ Type-C Port Controller Manager to provide USB PD and USB
+ Type-C functionalities.
+
 endif
 
 endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index 53d649abcb53..7803d485e1b3 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
+obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
diff --git a/drivers/staging/typec/tcpci.h b/drivers/staging/typec/tcpci.h
index 34c865f0dcf6..303ebde26546 100644
--- a/drivers/staging/typec/tcpci.h
+++ b/drivers/staging/typec/tcpci.h
@@ -59,6 +59,7 @@
 #define TCPC_POWER_CTRL_VCONN_ENABLE   BIT(0)
 
 #define TCPC_CC_STATUS 0x1d
+#define TCPC_CC_STATUS_TOGGLINGBIT(5)
 #define TCPC_CC_STATUS_TERMBIT(4)
 #define TCPC_CC_STATUS_CC2_SHIFT   2
 #define TCPC_CC_STATUS_CC2_MASK0x3
diff --git a/drivers/staging/typec/tcpci_rt1711h.c 
b/drivers/staging/typec/tcpci_rt1711h.c
new file mode 100644
index ..12afac363d6d
--- /dev/null
+++ b/drivers/staging/typec/tcpci_rt1711h.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Richtek Technology Corporation
+ *
+ * Richtek RT1711H Type-C Chip Driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "tcpci.h"
+
+#define RT1711H_RTCTRL80x9B
+
+/* Autoidle timeout = (tout * 2 + 1) * 6.4ms */
+#define RT1711H_RTCTRL8_SET(ck300, ship_off, auto_idle, tout) \
+   (((ck300) << 7) | ((ship_off) << 5) | \
+   ((auto_idle) << 3) | ((tout) & 0x07))
+
+#define RT1711H_RTCTRL11   0x9E
+
+/* I2C timeout = (tout + 1) * 12.5ms */
+#define RT1711H_RTCTRL11_SET(en, tout) \
+(((en) << 7) | ((tout) & 0x0F))
+
+#define RT1711H_RTCTRL13   0xA0
+#define RT1711H_RTCTRL14   0xA1
+#define RT1711H_RTCTRL15   0xA2
+#define RT1711H_RTCTRL16   0xA3
+
+struct rt1711h_chip {
+   struct tcpci_data data;
+   struct tcpci *tcpci;
+   struct device *dev;
+   int irq;
+};
+
+static int rt1711h_read16(struct rt1711h_chip *chip, unsigned int reg, u16 
*val)
+{
+   return regmap_raw_read(chip->data.regmap, reg, val, sizeof(u16));
+}
+
+static int rt1711h_write16(struct rt1711h_chip *chip, unsigned int reg, u16 
val)
+{
+   return regmap_raw_write(chip->data.regmap, reg, , sizeof(u16));
+}
+
+static int rt1711h_read8(struct rt1711h_chip *chip, unsigned int reg, u8 *val)
+{
+   return regmap_raw_read(chip->data.regmap, reg, val, sizeof(u8));
+}
+
+static int rt1711h_write8(struct rt1711h_chip *chip, unsigned int reg, u8 val)
+{
+   return regmap_raw_write(chip->data.regmap, reg, , sizeof(u8));
+}
+
+static const struct regmap_config rt1711h_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = 0xFF, /* 0x80 .. 0xFF are vendor defined */
+};
+
+static struct rt1711h_chip *tdata_to_rt1711h(struct tcpci_data *tdata)
+{
+   return container_of(tdata, struct rt1711h_chip, data);
+}
+
+static int rt1711h_init(struct tcpci *tcpci, struct tcpci_data *tdata)
+{
+   int ret;
+   struct rt1711h_chip *chip = tdata_to_rt1711h(tdata);
+
+   /* CK 300K from 320K, shipping off, auto_idle enable, tout = 32ms */
+   ret = rt1711h_write8(chip, RT1711H_RTCTRL8,
+RT1711H_RTCTRL8_SET(0, 1, 1, 2));
+   if (ret < 0)
+   return ret;
+
+   /* I2C reset : (val + 1) * 12.5ms */
+   ret = rt1711h_write8(chip, RT1711H_RTCTRL11,
+RT1711H_RTCTRL11_SET(1, 0x0F));
+   if (ret < 0)
+   return ret;
+
+   /* tTCPCfilter : (26.7 * val) us */
+   ret = rt1711h_write8(chip, RT1711H_RTCTRL14, 0x0F);
+   if (ret < 0)

[PATCH 1/2] staging: typec: rt1711h typec chip driver

[ShuFan Lee]

From: ShuFan Lee 

Richtek RT1711H Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and
USB Type-C functionalities.
Add definition of TCPC_CC_STATUS_TOGGLING.

Signed-off-by: ShuFan Lee 
---
 drivers/staging/typec/Kconfig |   8 +
 drivers/staging/typec/Makefile|   1 +
 drivers/staging/typec/tcpci.h |   1 +
 drivers/staging/typec/tcpci_rt1711h.c | 329 ++
 4 files changed, 339 insertions(+)
 create mode 100644 drivers/staging/typec/tcpci_rt1711h.c

 changelogs between v1 and v2
 - use gpiod_* instead of gpio_*

diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 5359f556d203..3aa981fbc8f5 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -9,6 +9,14 @@ config TYPEC_TCPCI
help
  Type-C Port Controller driver for TCPCI-compliant controller.
 
+config TYPEC_RT1711H
+   tristate "Richtek RT1711H Type-C chip driver"
+   select TYPEC_TCPCI
+   help
+ Richtek RT1711H Type-C chip driver that works with
+ Type-C Port Controller Manager to provide USB PD and USB
+ Type-C functionalities.
+
 endif
 
 endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index 53d649abcb53..7803d485e1b3 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
+obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
diff --git a/drivers/staging/typec/tcpci.h b/drivers/staging/typec/tcpci.h
index 34c865f0dcf6..303ebde26546 100644
--- a/drivers/staging/typec/tcpci.h
+++ b/drivers/staging/typec/tcpci.h
@@ -59,6 +59,7 @@
 #define TCPC_POWER_CTRL_VCONN_ENABLE   BIT(0)
 
 #define TCPC_CC_STATUS 0x1d
+#define TCPC_CC_STATUS_TOGGLINGBIT(5)
 #define TCPC_CC_STATUS_TERMBIT(4)
 #define TCPC_CC_STATUS_CC2_SHIFT   2
 #define TCPC_CC_STATUS_CC2_MASK0x3
diff --git a/drivers/staging/typec/tcpci_rt1711h.c 
b/drivers/staging/typec/tcpci_rt1711h.c
new file mode 100644
index ..12afac363d6d
--- /dev/null
+++ b/drivers/staging/typec/tcpci_rt1711h.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Richtek Technology Corporation
+ *
+ * Richtek RT1711H Type-C Chip Driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "tcpci.h"
+
+#define RT1711H_RTCTRL80x9B
+
+/* Autoidle timeout = (tout * 2 + 1) * 6.4ms */
+#define RT1711H_RTCTRL8_SET(ck300, ship_off, auto_idle, tout) \
+   (((ck300) << 7) | ((ship_off) << 5) | \
+   ((auto_idle) << 3) | ((tout) & 0x07))
+
+#define RT1711H_RTCTRL11   0x9E
+
+/* I2C timeout = (tout + 1) * 12.5ms */
+#define RT1711H_RTCTRL11_SET(en, tout) \
+(((en) << 7) | ((tout) & 0x0F))
+
+#define RT1711H_RTCTRL13   0xA0
+#define RT1711H_RTCTRL14   0xA1
+#define RT1711H_RTCTRL15   0xA2
+#define RT1711H_RTCTRL16   0xA3
+
+struct rt1711h_chip {
+   struct tcpci_data data;
+   struct tcpci *tcpci;
+   struct device *dev;
+   int irq;
+};
+
+static int rt1711h_read16(struct rt1711h_chip *chip, unsigned int reg, u16 
*val)
+{
+   return regmap_raw_read(chip->data.regmap, reg, val, sizeof(u16));
+}
+
+static int rt1711h_write16(struct rt1711h_chip *chip, unsigned int reg, u16 
val)
+{
+   return regmap_raw_write(chip->data.regmap, reg, , sizeof(u16));
+}
+
+static int rt1711h_read8(struct rt1711h_chip *chip, unsigned int reg, u8 *val)
+{
+   return regmap_raw_read(chip->data.regmap, reg, val, sizeof(u8));
+}
+
+static int rt1711h_write8(struct rt1711h_chip *chip, unsigned int reg, u8 val)
+{
+   return regmap_raw_write(chip->data.regmap, reg, , sizeof(u8));
+}
+
+static const struct regmap_config rt1711h_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = 0xFF, /* 0x80 .. 0xFF are vendor defined */
+};
+
+static struct rt1711h_chip *tdata_to_rt1711h(struct tcpci_data *tdata)
+{
+   return container_of(tdata, struct rt1711h_chip, data);
+}
+
+static int rt1711h_init(struct tcpci *tcpci, struct tcpci_data *tdata)
+{
+   int ret;
+   struct rt1711h_chip *chip = tdata_to_rt1711h(tdata);
+
+   /* CK 300K from 320K, shipping off, auto_idle enable, tout = 32ms */
+   ret = rt1711h_write8(chip, RT1711H_RTCTRL8,
+RT1711H_RTCTRL8_SET(0, 1, 1, 2));
+   if (ret < 0)
+   return ret;
+
+   /* I2C reset : (val + 1) * 12.5ms */
+   ret = rt1711h_write8(chip, RT1711H_RTCTRL11,
+RT1711H_RTCTRL11_SET(1, 0x0F));
+   if (ret < 0)
+   return ret;
+
+   /* tTCPCfilter : (26.7 * val) us */
+   ret = rt1711h_write8(chip, RT1711H_RTCTRL14, 0x0F);
+   if (ret < 0)
+   return ret;
+
+   /*  tDRP : 

Re: linux-next: manual merge of the kvms390 tree with the nds32 tree

[Stephen Rothwell]

Hi all,

On Mon, 26 Feb 2018 13:34:45 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   drivers/video/console/Kconfig
> 
> between commit:
> 
>   2312dbf7462b ("drivers/video/concole: add negative dependency for 
> VGA_CONSOLE on nds32")
> 
> from the nds32 tree and commits:
> 
>   8da93aca3729 ("Kconfig : Remove HAS_IOMEM dependency for Graphics support")
>   416b744f4494 ("s390/setup : enable display support for KVM guest")
> 
> from the kvms390 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/video/console/Kconfig
> index 27bb893cf6b2,b9c2c916247e..
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@@ -9,7 -9,7 +9,7 @@@ config VGA_CONSOL
>   depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
>   !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
>   (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) 
> && \
> - !ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !NDS32
>  -!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && HAS_IOMEM && !S390
> ++!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !NDS32 && 
> HAS_IOMEM && !S390
>   default y
>   help
> Saying Y here will allow you to use Linux in text mode through a

This conflict is now between the kvm tree and the nds32 tree.

-- 
Cheers,
Stephen Rothwell


pgpVwDDAbzRXf.pgp
Description: OpenPGP digital signature

[PATCH 0/2] staging: typec: rt1711h typec driver and dt-bindings

[ShuFan Lee]

From: ShuFan Lee 

This patch series add rt1711h typec chip driver and dt-bindings

changelogs between v1 & v2
- use gpiod_* instead of gpio_*

changelogs between v2 & v3
- add dt-bindings for rt1711h typec driver

ShuFan Lee (2):
  staging: typec: rt1711h typec chip driver
  dt-bindings: usb: rt1711h device tree binding document

 .../devicetree/bindings/usb/richtek,rt1711h.txt|  30 ++
 drivers/staging/typec/Kconfig  |   8 +
 drivers/staging/typec/Makefile |   1 +
 drivers/staging/typec/tcpci.h  |   1 +
 drivers/staging/typec/tcpci_rt1711h.c  | 329 +
 5 files changed, 369 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
 create mode 100644 drivers/staging/typec/tcpci_rt1711h.c

-- 
1.9.1

[PATCH 2/2] dt-bindings: usb: rt1711h device tree binding document

[ShuFan Lee]

From: ShuFan Lee 

Add device tree binding document for Richtek RT1711H Type-C chip driver

Signed-off-by: ShuFan Lee 
---
 .../devicetree/bindings/usb/richtek,rt1711h.txt| 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1711h.txt

 changelogs between v2 & v3
 - add dt-bindings document for rt1711h typec chip driver

diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt 
b/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
new file mode 100644
index ..7da4dac78ea7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
@@ -0,0 +1,30 @@
+Richtek RT1711H TypeC PD Controller.
+
+Required properties:
+ - compatible : Must be "richtek,rt1711h".
+ - reg : Must be 0x4e, it's slave address of RT1711H.
+
+Recommended properties :
+ - interrupt-parent : the phandle for the interrupt controller that
+   provides interrupts for this device.
+ - interrupts :  where a is the interrupt number and b represents an
+   encoding of the sense and level information for the interrupt.
+
+Optional properties :
+ - rt,intr-gpios : IRQ GPIO pin that's connected to RT1711H interrupt.
+   if interrupt-parent & interrupts are not defined, use this property instead.
+
+Example :
+rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+};
+
+Example using rt,intr-gpios :
+rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   rt,intr-gpios = < 0 0x0>;
+};
-- 
1.9.1

[PATCH 0/2] staging: typec: rt1711h typec driver and dt-bindings

[ShuFan Lee]

From: ShuFan Lee 

This patch series add rt1711h typec chip driver and dt-bindings

changelogs between v1 & v2
- use gpiod_* instead of gpio_*

changelogs between v2 & v3
- add dt-bindings for rt1711h typec driver

ShuFan Lee (2):
  staging: typec: rt1711h typec chip driver
  dt-bindings: usb: rt1711h device tree binding document

 .../devicetree/bindings/usb/richtek,rt1711h.txt|  30 ++
 drivers/staging/typec/Kconfig  |   8 +
 drivers/staging/typec/Makefile |   1 +
 drivers/staging/typec/tcpci.h  |   1 +
 drivers/staging/typec/tcpci_rt1711h.c  | 329 +
 5 files changed, 369 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
 create mode 100644 drivers/staging/typec/tcpci_rt1711h.c

-- 
1.9.1

[PATCH 2/2] dt-bindings: usb: rt1711h device tree binding document

[ShuFan Lee]

From: ShuFan Lee 

Add device tree binding document for Richtek RT1711H Type-C chip driver

Signed-off-by: ShuFan Lee 
---
 .../devicetree/bindings/usb/richtek,rt1711h.txt| 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1711h.txt

 changelogs between v2 & v3
 - add dt-bindings document for rt1711h typec chip driver

diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt 
b/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
new file mode 100644
index ..7da4dac78ea7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
@@ -0,0 +1,30 @@
+Richtek RT1711H TypeC PD Controller.
+
+Required properties:
+ - compatible : Must be "richtek,rt1711h".
+ - reg : Must be 0x4e, it's slave address of RT1711H.
+
+Recommended properties :
+ - interrupt-parent : the phandle for the interrupt controller that
+   provides interrupts for this device.
+ - interrupts :  where a is the interrupt number and b represents an
+   encoding of the sense and level information for the interrupt.
+
+Optional properties :
+ - rt,intr-gpios : IRQ GPIO pin that's connected to RT1711H interrupt.
+   if interrupt-parent & interrupts are not defined, use this property instead.
+
+Example :
+rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+};
+
+Example using rt,intr-gpios :
+rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   rt,intr-gpios = < 0 0x0>;
+};
-- 
1.9.1

Re: [PATCH 4.14 056/109] clk: ti: clkctrl: add support for retrying failed init

[Dan Rue]

On Fri, Mar 16, 2018 at 04:23:25PM +0100, Greg Kroah-Hartman wrote:
> 4.14-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Tero Kristo 
> 
> 
> [ Upstream commit 729e13bf58e643b9accd2a14c55b555958702fb0 ]
> 
> In case the clkctrl node contains assigned-clock-* entries, registering
> the provider can fail with -EPROBE_DEFER. In this case, add the
> provider to the retry_init clock list so it will be cleaned up later.
> 
> Signed-off-by: Tero Kristo 
> Acked-by: Stephen Boyd 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Greg Kroah-Hartman 

This fails to build for me on arm32:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

...

../drivers/clk/ti/clkctrl.c: In function ‘_ti_omap4_clkctrl_setup’:
../drivers/clk/ti/clkctrl.c:497:27: error: passing argument 2 of 
‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
   ^~~~
In file included from ../drivers/clk/ti/clkctrl.c:24:0:
../drivers/clk/ti/clock.h:265:5: note: expected ‘struct clk_hw *’ but argument 
is of type ‘struct omap_clkctrl_prov
ider *’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^  
   ../drivers/clk/ti/clkctrl.c:497:37: error: 
passing argument 3 of ‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
 ^
In file included from ../drivers/clk/ti/clkctrl.c:24:0: 
   ../drivers/clk/ti/clock.h:265:5: note: 
expected ‘ti_of_clk_init_cb_t {aka void (*)(struct clk_hw *, struct device_n
ode *)}’ but argument is of type ‘void (*)(void *, struct device_node *)’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^
cc1: some warnings being treated as errors
make[4]: *** [../scripts/Makefile.build:329: drivers/clk/ti/clkctrl.o] Error 1
make[3]: *** [../scripts/Makefile.build:587: drivers/clk/ti] Error 2
make[2]: *** [../scripts/Makefile.build:587: drivers/clk] Error 2
make[1]: *** [/home/drue/src/linux/4.14-rc/Makefile:1031: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.14-rc/build-arm'
make: *** [Makefile:146: sub-make] Error 2

> ---
>  drivers/clk/ti/clkctrl.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> --- a/drivers/clk/ti/clkctrl.c
> +++ b/drivers/clk/ti/clkctrl.c
> @@ -400,6 +400,12 @@ _ti_clkctrl_setup_subclks(struct omap_cl
>   }
>  }
>  
> +static void __init _clkctrl_add_provider(void *data,
> +  struct device_node *np)
> +{
> + of_clk_add_hw_provider(np, _ti_omap4_clkctrl_xlate, data);
> +}
> +
>  static void __init _ti_omap4_clkctrl_setup(struct device_node *node)
>  {
>   struct omap_clkctrl_provider *provider;
> @@ -411,6 +417,7 @@ static void __init _ti_omap4_clkctrl_set
>   struct omap_clkctrl_clk *clkctrl_clk;
>   const __be32 *addrp;
>   u32 addr;
> + int ret;
>  
>   addrp = of_get_address(node, 0, NULL, NULL);
>   addr = (u32)of_translate_address(node, addrp);
> @@ -485,7 +492,10 @@ static void __init _ti_omap4_clkctrl_set
>   reg_data++;
>   }
>  
> - of_clk_add_hw_provider(node, _ti_omap4_clkctrl_xlate, provider);
> + ret = of_clk_add_hw_provider(node, _ti_omap4_clkctrl_xlate, provider);
> + if (ret == -EPROBE_DEFER)
> + ti_clk_retry_init(node, provider, _clkctrl_add_provider);
> +
>   return;
>  
>  cleanup:
> 
> 

Re: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with GFP_KERNEL in hv_pci_onchannelcallback

[Jia-Ju Bai]

On 2018/3/19 10:52, KY Srinivasan wrote:



-Original Message-
From: Jia-Ju Bai 
Sent: Sunday, March 18, 2018 7:53 AM
To: KY Srinivasan ; Haiyang Zhang
; Stephen Hemminger
; bhelg...@google.com
Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
ker...@vger.kernel.org; Jia-Ju Bai 
Subject: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with
GFP_KERNEL in hv_pci_onchannelcallback

hv_pci_onchannelcallback() is not called in atomic context.

The call chain ending up at hv_pci_onchannelcallback() is:
[1] hv_pci_onchannelcallback() <- hv_pci_probe()
hv_pci_probe() is only set as ".probe" in hv_driver
structure "hv_pci_drv".

This function is setup as the function to handle interrupts on the channel. 
Hence the
need for GFP_ATOMIC.



Oh, sorry for my incorrect patch.
Thanks for your reply :)


Best wishes,
Jia-Ju Bai

Re: [PATCH 4.14 056/109] clk: ti: clkctrl: add support for retrying failed init

[Dan Rue]

On Fri, Mar 16, 2018 at 04:23:25PM +0100, Greg Kroah-Hartman wrote:
> 4.14-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Tero Kristo 
> 
> 
> [ Upstream commit 729e13bf58e643b9accd2a14c55b555958702fb0 ]
> 
> In case the clkctrl node contains assigned-clock-* entries, registering
> the provider can fail with -EPROBE_DEFER. In this case, add the
> provider to the retry_init clock list so it will be cleaned up later.
> 
> Signed-off-by: Tero Kristo 
> Acked-by: Stephen Boyd 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Greg Kroah-Hartman 

This fails to build for me on arm32:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

...

../drivers/clk/ti/clkctrl.c: In function ‘_ti_omap4_clkctrl_setup’:
../drivers/clk/ti/clkctrl.c:497:27: error: passing argument 2 of 
‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
   ^~~~
In file included from ../drivers/clk/ti/clkctrl.c:24:0:
../drivers/clk/ti/clock.h:265:5: note: expected ‘struct clk_hw *’ but argument 
is of type ‘struct omap_clkctrl_prov
ider *’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^  
   ../drivers/clk/ti/clkctrl.c:497:37: error: 
passing argument 3 of ‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
 ^
In file included from ../drivers/clk/ti/clkctrl.c:24:0: 
   ../drivers/clk/ti/clock.h:265:5: note: 
expected ‘ti_of_clk_init_cb_t {aka void (*)(struct clk_hw *, struct device_n
ode *)}’ but argument is of type ‘void (*)(void *, struct device_node *)’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^
cc1: some warnings being treated as errors
make[4]: *** [../scripts/Makefile.build:329: drivers/clk/ti/clkctrl.o] Error 1
make[3]: *** [../scripts/Makefile.build:587: drivers/clk/ti] Error 2
make[2]: *** [../scripts/Makefile.build:587: drivers/clk] Error 2
make[1]: *** [/home/drue/src/linux/4.14-rc/Makefile:1031: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.14-rc/build-arm'
make: *** [Makefile:146: sub-make] Error 2

> ---
>  drivers/clk/ti/clkctrl.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> --- a/drivers/clk/ti/clkctrl.c
> +++ b/drivers/clk/ti/clkctrl.c
> @@ -400,6 +400,12 @@ _ti_clkctrl_setup_subclks(struct omap_cl
>   }
>  }
>  
> +static void __init _clkctrl_add_provider(void *data,
> +  struct device_node *np)
> +{
> + of_clk_add_hw_provider(np, _ti_omap4_clkctrl_xlate, data);
> +}
> +
>  static void __init _ti_omap4_clkctrl_setup(struct device_node *node)
>  {
>   struct omap_clkctrl_provider *provider;
> @@ -411,6 +417,7 @@ static void __init _ti_omap4_clkctrl_set
>   struct omap_clkctrl_clk *clkctrl_clk;
>   const __be32 *addrp;
>   u32 addr;
> + int ret;
>  
>   addrp = of_get_address(node, 0, NULL, NULL);
>   addr = (u32)of_translate_address(node, addrp);
> @@ -485,7 +492,10 @@ static void __init _ti_omap4_clkctrl_set
>   reg_data++;
>   }
>  
> - of_clk_add_hw_provider(node, _ti_omap4_clkctrl_xlate, provider);
> + ret = of_clk_add_hw_provider(node, _ti_omap4_clkctrl_xlate, provider);
> + if (ret == -EPROBE_DEFER)
> + ti_clk_retry_init(node, provider, _clkctrl_add_provider);
> +
>   return;
>  
>  cleanup:
> 
> 

Re: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with GFP_KERNEL in hv_pci_onchannelcallback

[Jia-Ju Bai]

On 2018/3/19 10:52, KY Srinivasan wrote:



-Original Message-
From: Jia-Ju Bai 
Sent: Sunday, March 18, 2018 7:53 AM
To: KY Srinivasan ; Haiyang Zhang
; Stephen Hemminger
; bhelg...@google.com
Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
ker...@vger.kernel.org; Jia-Ju Bai 
Subject: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with
GFP_KERNEL in hv_pci_onchannelcallback

hv_pci_onchannelcallback() is not called in atomic context.

The call chain ending up at hv_pci_onchannelcallback() is:
[1] hv_pci_onchannelcallback() <- hv_pci_probe()
hv_pci_probe() is only set as ".probe" in hv_driver
structure "hv_pci_drv".

This function is setup as the function to handle interrupts on the channel. 
Hence the
need for GFP_ATOMIC.



Oh, sorry for my incorrect patch.
Thanks for your reply :)


Best wishes,
Jia-Ju Bai

RE: [PATCH] vmbus: use put_device() if device_register fail

[Michael Kelley (EOSG)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org  
> On Behalf
> Of KY Srinivasan
> Sent: Sunday, March 18, 2018 8:02 PM
> To: Arvind Yadav ; Stephen Hemminger
> ; Haiyang Zhang 
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] vmbus: use put_device() if device_register fail
> 
> > -Original Message-
> > From: devel  On Behalf
> > Of Arvind Yadav
> > Sent: Saturday, March 17, 2018 11:48 PM
> > To: Stephen Hemminger ; Haiyang Zhang
> > 
> > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH] vmbus: use put_device() if device_register fail
> >
> > if device_register() returned an error. Always use put_device()
> > to give up the reference initialized.
> >
> > Signed-off-by: Arvind Yadav 
> > ---
> >  drivers/hv/vmbus_drv.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > index bc65c4d..25da2f3 100644
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
> > *child_device_obj)
> > ret = device_register(_device_obj->device);
> > if (ret) {
> > pr_err("Unable to register child device\n");
> > +   put_device(_device_obj->device);
> 
> If the registration failed; we would not have acquired the reference on the 
> device and so
> we should not be dropping the reference in the failure path.

Looking at the code for device_register() and its constituent parts
device_initialize() and device_add(), Arvind is correct.  device_initialize()
creates the object with a reference count of 1.  device_add() does not
decrement that reference count or free the object, even if it fails.  The
comments for device_register() call this out as well.

Michael  

> 
> K. Y
> > return ret;
> > }
> >
> > --
> > 2.7.4

RE: [PATCH] vmbus: use put_device() if device_register fail

[Michael Kelley (EOSG)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org  
> On Behalf
> Of KY Srinivasan
> Sent: Sunday, March 18, 2018 8:02 PM
> To: Arvind Yadav ; Stephen Hemminger
> ; Haiyang Zhang 
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] vmbus: use put_device() if device_register fail
> 
> > -Original Message-
> > From: devel  On Behalf
> > Of Arvind Yadav
> > Sent: Saturday, March 17, 2018 11:48 PM
> > To: Stephen Hemminger ; Haiyang Zhang
> > 
> > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH] vmbus: use put_device() if device_register fail
> >
> > if device_register() returned an error. Always use put_device()
> > to give up the reference initialized.
> >
> > Signed-off-by: Arvind Yadav 
> > ---
> >  drivers/hv/vmbus_drv.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > index bc65c4d..25da2f3 100644
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
> > *child_device_obj)
> > ret = device_register(_device_obj->device);
> > if (ret) {
> > pr_err("Unable to register child device\n");
> > +   put_device(_device_obj->device);
> 
> If the registration failed; we would not have acquired the reference on the 
> device and so
> we should not be dropping the reference in the failure path.

Looking at the code for device_register() and its constituent parts
device_initialize() and device_add(), Arvind is correct.  device_initialize()
creates the object with a reference count of 1.  device_add() does not
decrement that reference count or free the object, even if it fails.  The
comments for device_register() call this out as well.

Michael  

> 
> K. Y
> > return ret;
> > }
> >
> > --
> > 2.7.4

Re: [PATCH 4.15 000/128] 4.15.11-stable review

[Dan Rue]

On Sun, Mar 18, 2018 at 12:15:23PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 18, 2018 at 11:25:26AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 16, 2018 at 04:22:21PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.15.11 release.
> > > There are 128 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun Mar 18 15:22:57 UTC 2018.
> > > Anything received after that time might be too late.
> > > 
> > > The whole patch series can be found in one patch at:
> > >   
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc1.gz
> > 
> > -rc2 is out to fix a build error on some configs:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc2.gz
> 
> And -rc3 is out that at least builds properly:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc3.gz

Sorry to say, this one doesn't build properly either.

I tested the previous build issue on arm64 only, but arm32 is still
failing on 4.14/4.15 due to the following:

07f498834a53 ("clk: ti: clkctrl: add support for retrying failed init")

I'll reply to the patch directly as well.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

...

../drivers/clk/ti/clkctrl.c: In function ‘_ti_omap4_clkctrl_setup’:
../drivers/clk/ti/clkctrl.c:497:27: error: passing argument 2 of 
‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
   ^~~~
In file included from ../drivers/clk/ti/clkctrl.c:24:0:
../drivers/clk/ti/clock.h:265:5: note: expected ‘struct clk_hw *’ but argument 
is of type ‘struct omap_clkctrl_prov
ider *’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^  
   ../drivers/clk/ti/clkctrl.c:497:37: error: 
passing argument 3 of ‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
 ^
In file included from ../drivers/clk/ti/clkctrl.c:24:0: 
   ../drivers/clk/ti/clock.h:265:5: note: 
expected ‘ti_of_clk_init_cb_t {aka void (*)(struct clk_hw *, struct device_n
ode *)}’ but argument is of type ‘void (*)(void *, struct device_node *)’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^
cc1: some warnings being treated as errors
make[4]: *** [../scripts/Makefile.build:329: drivers/clk/ti/clkctrl.o] Error 1
make[3]: *** [../scripts/Makefile.build:587: drivers/clk/ti] Error 2
make[2]: *** [../scripts/Makefile.build:587: drivers/clk] Error 2
make[1]: *** [/home/drue/src/linux/4.14-rc/Makefile:1031: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.14-rc/build-arm'
make: *** [Makefile:146: sub-make] Error 2

Re: [PATCH 4.15 000/128] 4.15.11-stable review

[Dan Rue]

On Sun, Mar 18, 2018 at 12:15:23PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 18, 2018 at 11:25:26AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 16, 2018 at 04:22:21PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.15.11 release.
> > > There are 128 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun Mar 18 15:22:57 UTC 2018.
> > > Anything received after that time might be too late.
> > > 
> > > The whole patch series can be found in one patch at:
> > >   
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc1.gz
> > 
> > -rc2 is out to fix a build error on some configs:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc2.gz
> 
> And -rc3 is out that at least builds properly:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.11-rc3.gz

Sorry to say, this one doesn't build properly either.

I tested the previous build issue on arm64 only, but arm32 is still
failing on 4.14/4.15 due to the following:

07f498834a53 ("clk: ti: clkctrl: add support for retrying failed init")

I'll reply to the patch directly as well.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

...

../drivers/clk/ti/clkctrl.c: In function ‘_ti_omap4_clkctrl_setup’:
../drivers/clk/ti/clkctrl.c:497:27: error: passing argument 2 of 
‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
   ^~~~
In file included from ../drivers/clk/ti/clkctrl.c:24:0:
../drivers/clk/ti/clock.h:265:5: note: expected ‘struct clk_hw *’ but argument 
is of type ‘struct omap_clkctrl_prov
ider *’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^  
   ../drivers/clk/ti/clkctrl.c:497:37: error: 
passing argument 3 of ‘ti_clk_retry_init’ from incompatible pointer type
 [-Werror=incompatible-pointer-types]
   ti_clk_retry_init(node, provider, _clkctrl_add_provider);
 ^
In file included from ../drivers/clk/ti/clkctrl.c:24:0: 
   ../drivers/clk/ti/clock.h:265:5: note: 
expected ‘ti_of_clk_init_cb_t {aka void (*)(struct clk_hw *, struct device_n
ode *)}’ but argument is of type ‘void (*)(void *, struct device_node *)’
 int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw,
 ^
cc1: some warnings being treated as errors
make[4]: *** [../scripts/Makefile.build:329: drivers/clk/ti/clkctrl.o] Error 1
make[3]: *** [../scripts/Makefile.build:587: drivers/clk/ti] Error 2
make[2]: *** [../scripts/Makefile.build:587: drivers/clk] Error 2
make[1]: *** [/home/drue/src/linux/4.14-rc/Makefile:1031: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.14-rc/build-arm'
make: *** [Makefile:146: sub-make] Error 2

Re: [PATCH v2 3/3] dt-bindings: phy-mtk-tphy: add properties for U2 slew rate calibrate

[Chunfeng Yun]

On Sun, 2018-03-18 at 07:48 -0500, Rob Herring wrote:
> On Mon, Mar 12, 2018 at 01:25:40PM +0800, Chunfeng Yun wrote:
> > Add two properties of ref_clk and coefficient used by U2 slew rate
> > calibrate which may vary on different SoCs
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index 41e09ed..0d34b2b 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -27,6 +27,10 @@ Optional properties (controller (parent) node):
> >   - reg : offset and length of register shared by multiple 
> > ports,
> >   exclude port's private register. It is needed on mt2701
> >   and mt8173, but not on mt2712.
> > + - mediatek,src-ref-clk-mhz: frequency of reference clock for slew 
> > rate
> > + calibrate
> > + - mediatek,src-coef   : coefficient for slew rate calibrate, depends 
> > on
> > + SoC process
> 
> What are valid values? This is one cell?
Yes, one cell, integer type. If need, I'll send a new patch

Thanks
> 
> >  
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> > -- 
> > 1.9.1
> > 

Re: [PATCH v2 3/3] dt-bindings: phy-mtk-tphy: add properties for U2 slew rate calibrate

[Chunfeng Yun]

On Sun, 2018-03-18 at 07:48 -0500, Rob Herring wrote:
> On Mon, Mar 12, 2018 at 01:25:40PM +0800, Chunfeng Yun wrote:
> > Add two properties of ref_clk and coefficient used by U2 slew rate
> > calibrate which may vary on different SoCs
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index 41e09ed..0d34b2b 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -27,6 +27,10 @@ Optional properties (controller (parent) node):
> >   - reg : offset and length of register shared by multiple 
> > ports,
> >   exclude port's private register. It is needed on mt2701
> >   and mt8173, but not on mt2712.
> > + - mediatek,src-ref-clk-mhz: frequency of reference clock for slew 
> > rate
> > + calibrate
> > + - mediatek,src-coef   : coefficient for slew rate calibrate, depends 
> > on
> > + SoC process
> 
> What are valid values? This is one cell?
Yes, one cell, integer type. If need, I'll send a new patch

Thanks
> 
> >  
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> > -- 
> > 1.9.1
> > 

[PATCH] irqchip: irq-gic-v4: return real error code

[Peng Hao]

__irq_domain_alloc_irqs will return some different error code, so we
should return real error code in its_alloc_vcpu_irqs.

Signed-off-by: Peng Hao 
---
 drivers/irqchip/irq-gic-v4.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index dba9d67..ecd170d 100644
--- a/drivers/irqchip/irq-gic-v4.c
+++ b/drivers/irqchip/irq-gic-v4.c
@@ -99,7 +99,7 @@
 
 int its_alloc_vcpu_irqs(struct its_vm *vm)
 {
-   int vpe_base_irq, i;
+   int vpe_base_irq, i, ret = -ENOMEM;
 
vm->fwnode = irq_domain_alloc_named_id_fwnode("GICv4-vpe",
  task_pid_nr(current));
@@ -120,8 +120,10 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
vpe_base_irq = __irq_domain_alloc_irqs(vm->domain, -1, vm->nr_vpes,
   NUMA_NO_NODE, vm,
   false, NULL);
-   if (vpe_base_irq <= 0)
+   if (vpe_base_irq <= 0) {
+   ret = vpe_base_irq;
goto err;
+   }
 
for (i = 0; i < vm->nr_vpes; i++)
vm->vpes[i]->irq = vpe_base_irq + i;
@@ -134,7 +136,7 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
if (vm->fwnode)
irq_domain_free_fwnode(vm->fwnode);
 
-   return -ENOMEM;
+   return ret;
 }
 
 void its_free_vcpu_irqs(struct its_vm *vm)
-- 
1.8.3.1

[PATCH] irqchip: irq-gic-v4: return real error code

[Peng Hao]

__irq_domain_alloc_irqs will return some different error code, so we
should return real error code in its_alloc_vcpu_irqs.

Signed-off-by: Peng Hao 
---
 drivers/irqchip/irq-gic-v4.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index dba9d67..ecd170d 100644
--- a/drivers/irqchip/irq-gic-v4.c
+++ b/drivers/irqchip/irq-gic-v4.c
@@ -99,7 +99,7 @@
 
 int its_alloc_vcpu_irqs(struct its_vm *vm)
 {
-   int vpe_base_irq, i;
+   int vpe_base_irq, i, ret = -ENOMEM;
 
vm->fwnode = irq_domain_alloc_named_id_fwnode("GICv4-vpe",
  task_pid_nr(current));
@@ -120,8 +120,10 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
vpe_base_irq = __irq_domain_alloc_irqs(vm->domain, -1, vm->nr_vpes,
   NUMA_NO_NODE, vm,
   false, NULL);
-   if (vpe_base_irq <= 0)
+   if (vpe_base_irq <= 0) {
+   ret = vpe_base_irq;
goto err;
+   }
 
for (i = 0; i < vm->nr_vpes; i++)
vm->vpes[i]->irq = vpe_base_irq + i;
@@ -134,7 +136,7 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
if (vm->fwnode)
irq_domain_free_fwnode(vm->fwnode);
 
-   return -ENOMEM;
+   return ret;
 }
 
 void its_free_vcpu_irqs(struct its_vm *vm)
-- 
1.8.3.1

[PATCH] ARM: dts: imx7d-pinfunc: update sai select input value

[Anson Huang]

Update SAI select input daisy chain value according to
Reference Manual.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx7d-pinfunc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h 
b/arch/arm/boot/dts/imx7d-pinfunc.h
index f2493bc..aa9dbea 100644
--- a/arch/arm/boot/dts/imx7d-pinfunc.h
+++ b/arch/arm/boot/dts/imx7d-pinfunc.h
@@ -592,7 +592,7 @@
 #define MX7D_PAD_UART2_RX_DATA__UART2_DCE_RX  0x0130 
0x03A0 0x06FC 0x0 0x2
 #define MX7D_PAD_UART2_RX_DATA__UART2_DTE_TX  0x0130 
0x03A0 0x 0x0 0x0
 #define MX7D_PAD_UART2_RX_DATA__I2C2_SCL  0x0130 
0x03A0 0x05DC 0x1 0x0
-#define MX7D_PAD_UART2_RX_DATA__SAI3_RX_BCLK  0x0130 
0x03A0 0x 0x2 0x0
+#define MX7D_PAD_UART2_RX_DATA__SAI3_RX_BCLK  0x0130 
0x03A0 0x06C4 0x2 0x0
 #define MX7D_PAD_UART2_RX_DATA__ECSPI1_SS30x0130 
0x03A0 0x 0x3 0x0
 #define MX7D_PAD_UART2_RX_DATA__ENET2_1588_EVENT1_IN  0x0130 
0x03A0 0x 0x4 0x0
 #define MX7D_PAD_UART2_RX_DATA__GPIO4_IO2 0x0130 
0x03A0 0x 0x5 0x0
@@ -1112,13 +1112,13 @@
 #define MX7D_PAD_ENET1_RGMII_TD3__GPIO7_IO9   0x0250 
0x04C0 0x 0x5 0x0
 #define MX7D_PAD_ENET1_RGMII_TD3__CAAM_RNG_OSC_OBS0x0250 
0x04C0 0x 0x7 0x0
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL   0x0254 
0x04C4 0x 0x0 0x0
-#define MX7D_PAD_ENET1_RGMII_TX_CTL__SAI1_RX_SYNC 0x0254 
0x04C4 0x 0x2 0x0
+#define MX7D_PAD_ENET1_RGMII_TX_CTL__SAI1_RX_SYNC 0x0254 
0x04C4 0x06A4 0x2 0x1
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__GPT2_COMPARE10x0254 
0x04C4 0x 0x3 0x0
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__EPDC_PWR_CTRL2   0x0254 
0x04C4 0x 0x4 0x0
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__GPIO7_IO10   0x0254 
0x04C4 0x 0x5 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x0258 
0x04C8 0x 0x0 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__ENET1_TX_ER 0x0258 
0x04C8 0x 0x1 0x0
-#define MX7D_PAD_ENET1_RGMII_TXC__SAI1_RX_BCLK0x0258 
0x04C8 0x 0x2 0x0
+#define MX7D_PAD_ENET1_RGMII_TXC__SAI1_RX_BCLK0x0258 
0x04C8 0x069C 0x2 0x1
 #define MX7D_PAD_ENET1_RGMII_TXC__GPT2_COMPARE2   0x0258 
0x04C8 0x 0x3 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__EPDC_PWR_CTRL3  0x0258 
0x04C8 0x 0x4 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__GPIO7_IO11  0x0258 
0x04C8 0x 0x5 0x0
-- 
2.7.4

[PATCH] ARM: dts: imx7d-pinfunc: update sai select input value

[Anson Huang]

Update SAI select input daisy chain value according to
Reference Manual.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx7d-pinfunc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h 
b/arch/arm/boot/dts/imx7d-pinfunc.h
index f2493bc..aa9dbea 100644
--- a/arch/arm/boot/dts/imx7d-pinfunc.h
+++ b/arch/arm/boot/dts/imx7d-pinfunc.h
@@ -592,7 +592,7 @@
 #define MX7D_PAD_UART2_RX_DATA__UART2_DCE_RX  0x0130 
0x03A0 0x06FC 0x0 0x2
 #define MX7D_PAD_UART2_RX_DATA__UART2_DTE_TX  0x0130 
0x03A0 0x 0x0 0x0
 #define MX7D_PAD_UART2_RX_DATA__I2C2_SCL  0x0130 
0x03A0 0x05DC 0x1 0x0
-#define MX7D_PAD_UART2_RX_DATA__SAI3_RX_BCLK  0x0130 
0x03A0 0x 0x2 0x0
+#define MX7D_PAD_UART2_RX_DATA__SAI3_RX_BCLK  0x0130 
0x03A0 0x06C4 0x2 0x0
 #define MX7D_PAD_UART2_RX_DATA__ECSPI1_SS30x0130 
0x03A0 0x 0x3 0x0
 #define MX7D_PAD_UART2_RX_DATA__ENET2_1588_EVENT1_IN  0x0130 
0x03A0 0x 0x4 0x0
 #define MX7D_PAD_UART2_RX_DATA__GPIO4_IO2 0x0130 
0x03A0 0x 0x5 0x0
@@ -1112,13 +1112,13 @@
 #define MX7D_PAD_ENET1_RGMII_TD3__GPIO7_IO9   0x0250 
0x04C0 0x 0x5 0x0
 #define MX7D_PAD_ENET1_RGMII_TD3__CAAM_RNG_OSC_OBS0x0250 
0x04C0 0x 0x7 0x0
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL   0x0254 
0x04C4 0x 0x0 0x0
-#define MX7D_PAD_ENET1_RGMII_TX_CTL__SAI1_RX_SYNC 0x0254 
0x04C4 0x 0x2 0x0
+#define MX7D_PAD_ENET1_RGMII_TX_CTL__SAI1_RX_SYNC 0x0254 
0x04C4 0x06A4 0x2 0x1
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__GPT2_COMPARE10x0254 
0x04C4 0x 0x3 0x0
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__EPDC_PWR_CTRL2   0x0254 
0x04C4 0x 0x4 0x0
 #define MX7D_PAD_ENET1_RGMII_TX_CTL__GPIO7_IO10   0x0254 
0x04C4 0x 0x5 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x0258 
0x04C8 0x 0x0 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__ENET1_TX_ER 0x0258 
0x04C8 0x 0x1 0x0
-#define MX7D_PAD_ENET1_RGMII_TXC__SAI1_RX_BCLK0x0258 
0x04C8 0x 0x2 0x0
+#define MX7D_PAD_ENET1_RGMII_TXC__SAI1_RX_BCLK0x0258 
0x04C8 0x069C 0x2 0x1
 #define MX7D_PAD_ENET1_RGMII_TXC__GPT2_COMPARE2   0x0258 
0x04C8 0x 0x3 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__EPDC_PWR_CTRL3  0x0258 
0x04C8 0x 0x4 0x0
 #define MX7D_PAD_ENET1_RGMII_TXC__GPIO7_IO11  0x0258 
0x04C8 0x 0x5 0x0
-- 
2.7.4

Re: [PATCH] mm: add config for readahead window

[Wei Wang]

On Sun, Mar 18, 2018 at 7:37 PM Huang, Ying  wrote:

> Wei Wang  writes:

> > Android devices boot time benefits by bigger readahead window setting
from
> > init. This patch will make readahead window a config so early boot can
> > benefit by it as well.

> Can you change the source code of init to call ioctl(BLKRASET) early?

> Best Regards,
> Huang, Ying

Yes, I am sure we can work this out by not touching it in mainline kernel.
One reason to bring it up again is that we found some SoC vendor has always
set a different value than default (128) in their kernel tree.

Thanks,
Wei Wang

Re: [PATCH] mm: add config for readahead window

[Wei Wang]

On Sun, Mar 18, 2018 at 7:37 PM Huang, Ying  wrote:

> Wei Wang  writes:

> > Android devices boot time benefits by bigger readahead window setting
from
> > init. This patch will make readahead window a config so early boot can
> > benefit by it as well.

> Can you change the source code of init to call ioctl(BLKRASET) early?

> Best Regards,
> Huang, Ying

Yes, I am sure we can work this out by not touching it in mainline kernel.
One reason to bring it up again is that we found some SoC vendor has always
set a different value than default (128) in their kernel tree.

Thanks,
Wei Wang

Re: [PATCH] f2fs: don't put dentry page in pagecache into highmem

[Yunlong Song]

Hi, Jaegeuk,
I find this patch is removed from current branch of dev-test
recently, why? Any bugs?

On 2018/2/28 20:31, Yunlong Song wrote:

Previous dentry page uses highmem, which will cause panic in platforms
using highmem (such as arm), since the address space of dentry pages
from highmem directly goes into the decryption path via the function
fscrypt_fname_disk_to_usr. But sg_init_one assumes the address is not
from highmem, and then cause panic since it doesn't call kmap_high but
kunmap_high is triggered at the end. To fix this problem in a simple
way, this patch avoids to put dentry page in pagecache into highmem.

Signed-off-by: Yunlong Song 
---
  fs/f2fs/dir.c   | 23 +--
  fs/f2fs/f2fs.h  |  6 --
  fs/f2fs/inline.c|  3 +--
  fs/f2fs/inode.c |  2 +-
  fs/f2fs/namei.c | 14 +-
  fs/f2fs/recovery.c  | 11 +--
  include/linux/f2fs_fs.h |  1 -
  7 files changed, 13 insertions(+), 47 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index f00b5ed..797eb05 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -94,14 +94,12 @@ static struct f2fs_dir_entry *find_in_block(struct page 
*dentry_page,
struct f2fs_dir_entry *de;
struct f2fs_dentry_ptr d;
  
-	dentry_blk = (struct f2fs_dentry_block *)kmap(dentry_page);

+   dentry_blk = (struct f2fs_dentry_block *)page_address(dentry_page);
  
  	make_dentry_ptr_block(NULL, , dentry_blk);

de = find_target_dentry(fname, namehash, max_slots, );
if (de)
*res_page = dentry_page;
-   else
-   kunmap(dentry_page);
  
  	return de;

  }
@@ -287,7 +285,6 @@ ino_t f2fs_inode_by_name(struct inode *dir, const struct 
qstr *qstr,
de = f2fs_find_entry(dir, qstr, page);
if (de) {
res = le32_to_cpu(de->ino);
-   f2fs_dentry_kunmap(dir, *page);
f2fs_put_page(*page, 0);
}
  
@@ -302,7 +299,6 @@ void f2fs_set_link(struct inode *dir, struct f2fs_dir_entry *de,

f2fs_wait_on_page_writeback(page, type, true);
de->ino = cpu_to_le32(inode->i_ino);
set_de_type(de, inode->i_mode);
-   f2fs_dentry_kunmap(dir, page);
set_page_dirty(page);
  
  	dir->i_mtime = dir->i_ctime = current_time(dir);

@@ -350,13 +346,11 @@ static int make_empty_dir(struct inode *inode,
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
  
-	dentry_blk = kmap_atomic(dentry_page);

+   dentry_blk = page_address(dentry_page);
  
  	make_dentry_ptr_block(NULL, , dentry_blk);

do_make_empty_dir(inode, parent, );
  
-	kunmap_atomic(dentry_blk);

-
set_page_dirty(dentry_page);
f2fs_put_page(dentry_page, 1);
return 0;
@@ -547,13 +541,12 @@ int f2fs_add_regular_entry(struct inode *dir, const 
struct qstr *new_name,
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
  
-		dentry_blk = kmap(dentry_page);

+   dentry_blk = page_address(dentry_page);
bit_pos = room_for_filename(_blk->dentry_bitmap,
slots, NR_DENTRY_IN_BLOCK);
if (bit_pos < NR_DENTRY_IN_BLOCK)
goto add_dentry;
  
-		kunmap(dentry_page);

f2fs_put_page(dentry_page, 1);
}
  
@@ -588,7 +581,6 @@ int f2fs_add_regular_entry(struct inode *dir, const struct qstr *new_name,

if (inode)
up_write(_I(inode)->i_sem);
  
-	kunmap(dentry_page);

f2fs_put_page(dentry_page, 1);
  
  	return err;

@@ -642,7 +634,6 @@ int __f2fs_add_link(struct inode *dir, const struct qstr 
*name,
F2FS_I(dir)->task = NULL;
}
if (de) {
-   f2fs_dentry_kunmap(dir, page);
f2fs_put_page(page, 0);
err = -EEXIST;
} else if (IS_ERR(page)) {
@@ -730,7 +721,6 @@ void f2fs_delete_entry(struct f2fs_dir_entry *dentry, 
struct page *page,
bit_pos = find_next_bit_le(_blk->dentry_bitmap,
NR_DENTRY_IN_BLOCK,
0);
-   kunmap(page); /* kunmap - pair of f2fs_find_entry */
set_page_dirty(page);
  
  	dir->i_ctime = dir->i_mtime = current_time(dir);

@@ -775,7 +765,7 @@ bool f2fs_empty_dir(struct inode *dir)
return false;
}
  
-		dentry_blk = kmap_atomic(dentry_page);

+   dentry_blk = page_address(dentry_page);
if (bidx == 0)
bit_pos = 2;
else
@@ -783,7 +773,6 @@ bool f2fs_empty_dir(struct inode *dir)
bit_pos = find_next_bit_le(_blk->dentry_bitmap,
NR_DENTRY_IN_BLOCK,
bit_pos);
-   kunmap_atomic(dentry_blk);
  
  		f2fs_put_page(dentry_page, 1);
  
@@ -901,19 +890,17 

Re: [PATCH] f2fs: don't put dentry page in pagecache into highmem

[Yunlong Song]

Hi, Jaegeuk,
I find this patch is removed from current branch of dev-test
recently, why? Any bugs?

On 2018/2/28 20:31, Yunlong Song wrote:

Previous dentry page uses highmem, which will cause panic in platforms
using highmem (such as arm), since the address space of dentry pages
from highmem directly goes into the decryption path via the function
fscrypt_fname_disk_to_usr. But sg_init_one assumes the address is not
from highmem, and then cause panic since it doesn't call kmap_high but
kunmap_high is triggered at the end. To fix this problem in a simple
way, this patch avoids to put dentry page in pagecache into highmem.

Signed-off-by: Yunlong Song 
---
  fs/f2fs/dir.c   | 23 +--
  fs/f2fs/f2fs.h  |  6 --
  fs/f2fs/inline.c|  3 +--
  fs/f2fs/inode.c |  2 +-
  fs/f2fs/namei.c | 14 +-
  fs/f2fs/recovery.c  | 11 +--
  include/linux/f2fs_fs.h |  1 -
  7 files changed, 13 insertions(+), 47 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index f00b5ed..797eb05 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -94,14 +94,12 @@ static struct f2fs_dir_entry *find_in_block(struct page 
*dentry_page,
struct f2fs_dir_entry *de;
struct f2fs_dentry_ptr d;
  
-	dentry_blk = (struct f2fs_dentry_block *)kmap(dentry_page);

+   dentry_blk = (struct f2fs_dentry_block *)page_address(dentry_page);
  
  	make_dentry_ptr_block(NULL, , dentry_blk);

de = find_target_dentry(fname, namehash, max_slots, );
if (de)
*res_page = dentry_page;
-   else
-   kunmap(dentry_page);
  
  	return de;

  }
@@ -287,7 +285,6 @@ ino_t f2fs_inode_by_name(struct inode *dir, const struct 
qstr *qstr,
de = f2fs_find_entry(dir, qstr, page);
if (de) {
res = le32_to_cpu(de->ino);
-   f2fs_dentry_kunmap(dir, *page);
f2fs_put_page(*page, 0);
}
  
@@ -302,7 +299,6 @@ void f2fs_set_link(struct inode *dir, struct f2fs_dir_entry *de,

f2fs_wait_on_page_writeback(page, type, true);
de->ino = cpu_to_le32(inode->i_ino);
set_de_type(de, inode->i_mode);
-   f2fs_dentry_kunmap(dir, page);
set_page_dirty(page);
  
  	dir->i_mtime = dir->i_ctime = current_time(dir);

@@ -350,13 +346,11 @@ static int make_empty_dir(struct inode *inode,
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
  
-	dentry_blk = kmap_atomic(dentry_page);

+   dentry_blk = page_address(dentry_page);
  
  	make_dentry_ptr_block(NULL, , dentry_blk);

do_make_empty_dir(inode, parent, );
  
-	kunmap_atomic(dentry_blk);

-
set_page_dirty(dentry_page);
f2fs_put_page(dentry_page, 1);
return 0;
@@ -547,13 +541,12 @@ int f2fs_add_regular_entry(struct inode *dir, const 
struct qstr *new_name,
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
  
-		dentry_blk = kmap(dentry_page);

+   dentry_blk = page_address(dentry_page);
bit_pos = room_for_filename(_blk->dentry_bitmap,
slots, NR_DENTRY_IN_BLOCK);
if (bit_pos < NR_DENTRY_IN_BLOCK)
goto add_dentry;
  
-		kunmap(dentry_page);

f2fs_put_page(dentry_page, 1);
}
  
@@ -588,7 +581,6 @@ int f2fs_add_regular_entry(struct inode *dir, const struct qstr *new_name,

if (inode)
up_write(_I(inode)->i_sem);
  
-	kunmap(dentry_page);

f2fs_put_page(dentry_page, 1);
  
  	return err;

@@ -642,7 +634,6 @@ int __f2fs_add_link(struct inode *dir, const struct qstr 
*name,
F2FS_I(dir)->task = NULL;
}
if (de) {
-   f2fs_dentry_kunmap(dir, page);
f2fs_put_page(page, 0);
err = -EEXIST;
} else if (IS_ERR(page)) {
@@ -730,7 +721,6 @@ void f2fs_delete_entry(struct f2fs_dir_entry *dentry, 
struct page *page,
bit_pos = find_next_bit_le(_blk->dentry_bitmap,
NR_DENTRY_IN_BLOCK,
0);
-   kunmap(page); /* kunmap - pair of f2fs_find_entry */
set_page_dirty(page);
  
  	dir->i_ctime = dir->i_mtime = current_time(dir);

@@ -775,7 +765,7 @@ bool f2fs_empty_dir(struct inode *dir)
return false;
}
  
-		dentry_blk = kmap_atomic(dentry_page);

+   dentry_blk = page_address(dentry_page);
if (bidx == 0)
bit_pos = 2;
else
@@ -783,7 +773,6 @@ bool f2fs_empty_dir(struct inode *dir)
bit_pos = find_next_bit_le(_blk->dentry_bitmap,
NR_DENTRY_IN_BLOCK,
bit_pos);
-   kunmap_atomic(dentry_blk);
  
  		f2fs_put_page(dentry_page, 1);
  
@@ -901,19 +890,17 @@ static int 

linux-next: manual merge of the tip tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/bus/arm-cci.c

between commit:

  3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver")

from the arm-soc tree and commit:

  edb39592a587 ("perf: Fix sibling iteration")

from the tip tree.

I fixed it up (I added the following merge fix patch) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Mon, 19 Mar 2018 14:04:52 +1100
Subject: [PATCH] perf/core: another merge fix for "drivers/bus: Split Arm CCI
 driver"

Signed-off-by: Stephen Rothwell 
---
 drivers/perf/arm-cci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 192d23b760a0..383b2d3dcbc6 100644
--- a/drivers/perf/arm-cci.c
+++ b/drivers/perf/arm-cci.c
@@ -1265,7 +1265,7 @@ static int validate_group(struct perf_event *event)
if (!validate_event(event->pmu, _pmu, leader))
return -EINVAL;
 
-   list_for_each_entry(sibling, >sibling_list, sibling_list) {
+   for_each_sibling_event(sibling, leader) {
if (!validate_event(event->pmu, _pmu, sibling))
return -EINVAL;
}
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgp4GtMP2IMwp.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the tip tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/bus/arm-cci.c

between commit:

  3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver")

from the arm-soc tree and commit:

  edb39592a587 ("perf: Fix sibling iteration")

from the tip tree.

I fixed it up (I added the following merge fix patch) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Mon, 19 Mar 2018 14:04:52 +1100
Subject: [PATCH] perf/core: another merge fix for "drivers/bus: Split Arm CCI
 driver"

Signed-off-by: Stephen Rothwell 
---
 drivers/perf/arm-cci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 192d23b760a0..383b2d3dcbc6 100644
--- a/drivers/perf/arm-cci.c
+++ b/drivers/perf/arm-cci.c
@@ -1265,7 +1265,7 @@ static int validate_group(struct perf_event *event)
if (!validate_event(event->pmu, _pmu, leader))
return -EINVAL;
 
-   list_for_each_entry(sibling, >sibling_list, sibling_list) {
+   for_each_sibling_event(sibling, leader) {
if (!validate_event(event->pmu, _pmu, sibling))
return -EINVAL;
}
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgp4GtMP2IMwp.pgp
Description: OpenPGP digital signature

Re: [PATCH 4.14 064/109] dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free

[Vinod Koul]

On Sun, Mar 18, 2018 at 11:44:51AM +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 18, 2018 at 11:24:17AM +0100, Greg Kroah-Hartman wrote:
> > > > This patch is causing a build error on arm and arm64 per i.e.
> > > > https://kernelci.org/build/id/5aac017e59b5141cb1b3a4d5/
> > > > 
> > > > Builds are also failing for arm/arm64 on 4.15 and this patch seems to 
> > > > be a
> > > > problem there as well, but I have not verified it yet.
> > > 
> > > I think we are missing commit 1c7f072d94e8. Pls cherrypick that as well
> > > 
> > > commit 1c7f072d94e8b697fd9b70cdb268622a18faf522
> > > Author: Peter Ujfalusi 
> > > Date:   Tue Nov 14 16:32:04 2017 +0200
> > > 
> > > dmaengine: virt-dma: Support for race free transfer termination
> > > 
> > > This adds vchan_terminate_vdesc API..
> > 
> > Thanks, that helped.  I've now added this and send out a -rc2 for this
> > kernel.
> 
> Oops, no, that broke the build for all arches :(
> 
> Let me just go drop this patch, and the two dmaengine patches that
> relied on this one.  If you think these should be applied to the stable
> trees, can you send me a series of working patches?

Okay let me grab your tree and cherry-pick all that is required and send
you. Stay tuned...

Thanks
-- 
~Vinod

Re: [PATCH 4.14 064/109] dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free

[Vinod Koul]

On Sun, Mar 18, 2018 at 11:44:51AM +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 18, 2018 at 11:24:17AM +0100, Greg Kroah-Hartman wrote:
> > > > This patch is causing a build error on arm and arm64 per i.e.
> > > > https://kernelci.org/build/id/5aac017e59b5141cb1b3a4d5/
> > > > 
> > > > Builds are also failing for arm/arm64 on 4.15 and this patch seems to 
> > > > be a
> > > > problem there as well, but I have not verified it yet.
> > > 
> > > I think we are missing commit 1c7f072d94e8. Pls cherrypick that as well
> > > 
> > > commit 1c7f072d94e8b697fd9b70cdb268622a18faf522
> > > Author: Peter Ujfalusi 
> > > Date:   Tue Nov 14 16:32:04 2017 +0200
> > > 
> > > dmaengine: virt-dma: Support for race free transfer termination
> > > 
> > > This adds vchan_terminate_vdesc API..
> > 
> > Thanks, that helped.  I've now added this and send out a -rc2 for this
> > kernel.
> 
> Oops, no, that broke the build for all arches :(
> 
> Let me just go drop this patch, and the two dmaengine patches that
> relied on this one.  If you think these should be applied to the stable
> trees, can you send me a series of working patches?

Okay let me grab your tree and cherry-pick all that is required and send
you. Stay tuned...

Thanks
-- 
~Vinod

RE: [PATCH] vmbus: use put_device() if device_register fail

[KY Srinivasan]

> -Original Message-
> From: devel  On Behalf
> Of Arvind Yadav
> Sent: Saturday, March 17, 2018 11:48 PM
> To: Stephen Hemminger ; Haiyang Zhang
> 
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] vmbus: use put_device() if device_register fail
> 
> if device_register() returned an error. Always use put_device()
> to give up the reference initialized.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/hv/vmbus_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index bc65c4d..25da2f3 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
> *child_device_obj)
>   ret = device_register(_device_obj->device);
>   if (ret) {
>   pr_err("Unable to register child device\n");
> + put_device(_device_obj->device);

If the registration failed; we would not have acquired the reference on the 
device and so
we should not be dropping the reference in the failure path.

K. Y
>   return ret;
>   }
> 
> --
> 2.7.4
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdriverd
> ev.linuxdriverproject.org%2Fmailman%2Flistinfo%2Fdriverdev-
> devel=04%7C01%7Ckys%40microsoft.com%7Caf95bfab917f4e1fa4b008
> d58c9c3b72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63656952
> 5011478334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
> 1=%2FEb%2FMTY2SMh8sY1tar2c8Om2uKPUZAXIUQkrG0q07CA%3D
> eserved=0

RE: [PATCH] vmbus: use put_device() if device_register fail

[KY Srinivasan]

> -Original Message-
> From: devel  On Behalf
> Of Arvind Yadav
> Sent: Saturday, March 17, 2018 11:48 PM
> To: Stephen Hemminger ; Haiyang Zhang
> 
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] vmbus: use put_device() if device_register fail
> 
> if device_register() returned an error. Always use put_device()
> to give up the reference initialized.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/hv/vmbus_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index bc65c4d..25da2f3 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
> *child_device_obj)
>   ret = device_register(_device_obj->device);
>   if (ret) {
>   pr_err("Unable to register child device\n");
> + put_device(_device_obj->device);

If the registration failed; we would not have acquired the reference on the 
device and so
we should not be dropping the reference in the failure path.

K. Y
>   return ret;
>   }
> 
> --
> 2.7.4
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdriverd
> ev.linuxdriverproject.org%2Fmailman%2Flistinfo%2Fdriverdev-
> devel=04%7C01%7Ckys%40microsoft.com%7Caf95bfab917f4e1fa4b008
> d58c9c3b72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63656952
> 5011478334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
> 1=%2FEb%2FMTY2SMh8sY1tar2c8Om2uKPUZAXIUQkrG0q07CA%3D
> eserved=0

[PATCH] init: no need to wait device probe

[ning . a . zhang]

From: Zhang Ning 

there are 2 reasons for no need to wait device probe

reason 1:
mount root device is very late in kernel initial stage.
all initcalls are finished. that means most of probe functions
are returned.

and deferred probe are also finished by late_initcall.
only async probe driver are possible in  probing.

no block devices, device-mapper or nfs are use async probe.
so no need to wait device probe.

reason 2:
let's check dd.c, probe_count is increased and decreased only
in really_probe, and when really_probe returns, probe_count
always be 0.

when someone really wants to wait device-B probe.
but code looks like:

thread-1:   thread-2:
probe device-A; wait_for_device_probe();
msleep(30);
probe device-B

when device-A probe finishes, thread-2 will be wakeup,
but device-B is not probed.

wait_for_device_probe can't make sure the device you want is probed.

based on above 2 reasons, no need to wait for device probe.

Signed-off-by: Zhang Ning 
---
 init/do_mounts.c| 9 -
 init/do_mounts_md.c | 2 --
 2 files changed, 11 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..a9fb2ad44964 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -555,15 +555,6 @@ void __init prepare_namespace(void)
ssleep(root_delay);
}
 
-   /*
-* wait for the known devices to complete their probing
-*
-* Note: this is a potential source of long boot delays.
-* For example, it is not atypical to wait 5 seconds here
-* for the touchpad of a laptop to initialize.
-*/
-   wait_for_device_probe();
-
md_run_setup();
 
if (saved_root_name[0]) {
diff --git a/init/do_mounts_md.c b/init/do_mounts_md.c
index 3f733c760a8c..4aab3492e71d 100644
--- a/init/do_mounts_md.c
+++ b/init/do_mounts_md.c
@@ -292,8 +292,6 @@ static void __init autodetect_raid(void)
printk(KERN_INFO "md: Waiting for all devices to be available before 
autodetect\n");
printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n");
 
-   wait_for_device_probe();
-
fd = sys_open("/dev/md0", 0, 0);
if (fd >= 0) {
sys_ioctl(fd, RAID_AUTORUN, raid_autopart);
-- 
2.14.2

[PATCH] init: no need to wait device probe

[ning . a . zhang]

From: Zhang Ning 

there are 2 reasons for no need to wait device probe

reason 1:
mount root device is very late in kernel initial stage.
all initcalls are finished. that means most of probe functions
are returned.

and deferred probe are also finished by late_initcall.
only async probe driver are possible in  probing.

no block devices, device-mapper or nfs are use async probe.
so no need to wait device probe.

reason 2:
let's check dd.c, probe_count is increased and decreased only
in really_probe, and when really_probe returns, probe_count
always be 0.

when someone really wants to wait device-B probe.
but code looks like:

thread-1:   thread-2:
probe device-A; wait_for_device_probe();
msleep(30);
probe device-B

when device-A probe finishes, thread-2 will be wakeup,
but device-B is not probed.

wait_for_device_probe can't make sure the device you want is probed.

based on above 2 reasons, no need to wait for device probe.

Signed-off-by: Zhang Ning 
---
 init/do_mounts.c| 9 -
 init/do_mounts_md.c | 2 --
 2 files changed, 11 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..a9fb2ad44964 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -555,15 +555,6 @@ void __init prepare_namespace(void)
ssleep(root_delay);
}
 
-   /*
-* wait for the known devices to complete their probing
-*
-* Note: this is a potential source of long boot delays.
-* For example, it is not atypical to wait 5 seconds here
-* for the touchpad of a laptop to initialize.
-*/
-   wait_for_device_probe();
-
md_run_setup();
 
if (saved_root_name[0]) {
diff --git a/init/do_mounts_md.c b/init/do_mounts_md.c
index 3f733c760a8c..4aab3492e71d 100644
--- a/init/do_mounts_md.c
+++ b/init/do_mounts_md.c
@@ -292,8 +292,6 @@ static void __init autodetect_raid(void)
printk(KERN_INFO "md: Waiting for all devices to be available before 
autodetect\n");
printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n");
 
-   wait_for_device_probe();
-
fd = sys_open("/dev/md0", 0, 0);
if (fd >= 0) {
sys_ioctl(fd, RAID_AUTORUN, raid_autopart);
-- 
2.14.2

RE: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with GFP_KERNEL in hv_pci_onchannelcallback

[KY Srinivasan]

> -Original Message-
> From: Jia-Ju Bai 
> Sent: Sunday, March 18, 2018 7:53 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; bhelg...@google.com
> Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Jia-Ju Bai 
> Subject: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with
> GFP_KERNEL in hv_pci_onchannelcallback
> 
> hv_pci_onchannelcallback() is not called in atomic context.
> 
> The call chain ending up at hv_pci_onchannelcallback() is:
> [1] hv_pci_onchannelcallback() <- hv_pci_probe()
> hv_pci_probe() is only set as ".probe" in hv_driver
> structure "hv_pci_drv".

This function is setup as the function to handle interrupts on the channel. 
Hence the
need for GFP_ATOMIC.

K. Y
> 
> Despite never getting called from atomic context,
> hv_pci_onchannelcallback() calls kmalloc with GFP_ATOMIC,
> which waits busily for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL
> to avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/host/pci-hyperv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 0fe3ea1..c5c8a99 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1887,7 +1887,7 @@ static void hv_pci_onchannelcallback(void
> *context)
>   struct pci_dev_incoming *dev_message;
>   struct hv_pci_dev *hpdev;
> 
> - buffer = kmalloc(bufferlen, GFP_ATOMIC);
> + buffer = kmalloc(bufferlen, GFP_KERNEL);
>   if (!buffer)
>   return;
> 
> @@ -1899,7 +1899,7 @@ static void hv_pci_onchannelcallback(void
> *context)
>   kfree(buffer);
>   /* Handle large packet */
>   bufferlen = bytes_recvd;
> - buffer = kmalloc(bytes_recvd, GFP_ATOMIC);
> + buffer = kmalloc(bytes_recvd, GFP_KERNEL);
>   if (!buffer)
>   return;
>   continue;
> --
> 1.9.1

RE: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with GFP_KERNEL in hv_pci_onchannelcallback

[KY Srinivasan]

> -Original Message-
> From: Jia-Ju Bai 
> Sent: Sunday, March 18, 2018 7:53 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; bhelg...@google.com
> Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Jia-Ju Bai 
> Subject: [PATCH 1/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with
> GFP_KERNEL in hv_pci_onchannelcallback
> 
> hv_pci_onchannelcallback() is not called in atomic context.
> 
> The call chain ending up at hv_pci_onchannelcallback() is:
> [1] hv_pci_onchannelcallback() <- hv_pci_probe()
> hv_pci_probe() is only set as ".probe" in hv_driver
> structure "hv_pci_drv".

This function is setup as the function to handle interrupts on the channel. 
Hence the
need for GFP_ATOMIC.

K. Y
> 
> Despite never getting called from atomic context,
> hv_pci_onchannelcallback() calls kmalloc with GFP_ATOMIC,
> which waits busily for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL
> to avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/host/pci-hyperv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 0fe3ea1..c5c8a99 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1887,7 +1887,7 @@ static void hv_pci_onchannelcallback(void
> *context)
>   struct pci_dev_incoming *dev_message;
>   struct hv_pci_dev *hpdev;
> 
> - buffer = kmalloc(bufferlen, GFP_ATOMIC);
> + buffer = kmalloc(bufferlen, GFP_KERNEL);
>   if (!buffer)
>   return;
> 
> @@ -1899,7 +1899,7 @@ static void hv_pci_onchannelcallback(void
> *context)
>   kfree(buffer);
>   /* Handle large packet */
>   bufferlen = bytes_recvd;
> - buffer = kmalloc(bytes_recvd, GFP_ATOMIC);
> + buffer = kmalloc(bytes_recvd, GFP_KERNEL);
>   if (!buffer)
>   return;
>   continue;
> --
> 1.9.1

Re: [PATCH v1 02/19] dt-bindings: cpufreq: mediatek: use - instead of _ in examples

[Sean Wang]

Hi, Matthias

I'm worried you missed the patch which already got both tags Reviewed-by
from Rob and Acked-by: Viresh and thus I thought it
should be ready for your tree.

For the other patches in the same series, I will have v2 to refine them
according to these suggestions and comments in v1 and let them easy to
review.

Really thanks for your effort!

Sean


On Mon, 2018-02-26 at 09:43 +0530, Viresh Kumar wrote:
> On 23-02-18, 18:16, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > It should be good that no use "_" is in examples. Consequently,
> > those nodes in certain files which have an inappropriate name containing
> > "_" are all being replaced with "-".
> > 
> > Signed-off-by: Sean Wang 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Viresh Kumar 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: linux...@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > ---
> >  Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
> > b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> > index d36f07e..38cfbb5 100644
> > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> > @@ -26,7 +26,7 @@ Optional properties:
> >  
> >  Example 1 (MT7623 SoC):
> >  
> > -   cpu_opp_table: opp_table {
> > +   cpu_opp_table: opp-table {
> > compatible = "operating-points-v2";
> > opp-shared;
> >  
> > @@ -86,7 +86,7 @@ Example 1 (MT7623 SoC):
> > };
> >  
> >  Example 2 (MT8173 SoC):
> > -   cpu_opp_table_a: opp_table_a {
> > +   cpu_opp_table_a: opp-table-a {
> > compatible = "operating-points-v2";
> > opp-shared;
> >  
> > @@ -131,7 +131,7 @@ Example 2 (MT8173 SoC):
> > };
> > };
> >  
> > -   cpu_opp_table_b: opp_table_b {
> > +   cpu_opp_table_b: opp-table-b {
> > compatible = "operating-points-v2";
> > opp-shared;
> 
> Acked-by: Viresh Kumar 
> 

Re: [PATCH v1 02/19] dt-bindings: cpufreq: mediatek: use - instead of _ in examples

[Sean Wang]

Hi, Matthias

I'm worried you missed the patch which already got both tags Reviewed-by
from Rob and Acked-by: Viresh and thus I thought it
should be ready for your tree.

For the other patches in the same series, I will have v2 to refine them
according to these suggestions and comments in v1 and let them easy to
review.

Really thanks for your effort!

Sean


On Mon, 2018-02-26 at 09:43 +0530, Viresh Kumar wrote:
> On 23-02-18, 18:16, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > It should be good that no use "_" is in examples. Consequently,
> > those nodes in certain files which have an inappropriate name containing
> > "_" are all being replaced with "-".
> > 
> > Signed-off-by: Sean Wang 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Viresh Kumar 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: linux...@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > ---
> >  Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
> > b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> > index d36f07e..38cfbb5 100644
> > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> > @@ -26,7 +26,7 @@ Optional properties:
> >  
> >  Example 1 (MT7623 SoC):
> >  
> > -   cpu_opp_table: opp_table {
> > +   cpu_opp_table: opp-table {
> > compatible = "operating-points-v2";
> > opp-shared;
> >  
> > @@ -86,7 +86,7 @@ Example 1 (MT7623 SoC):
> > };
> >  
> >  Example 2 (MT8173 SoC):
> > -   cpu_opp_table_a: opp_table_a {
> > +   cpu_opp_table_a: opp-table-a {
> > compatible = "operating-points-v2";
> > opp-shared;
> >  
> > @@ -131,7 +131,7 @@ Example 2 (MT8173 SoC):
> > };
> > };
> >  
> > -   cpu_opp_table_b: opp_table_b {
> > +   cpu_opp_table_b: opp-table-b {
> > compatible = "operating-points-v2";
> > opp-shared;
> 
> Acked-by: Viresh Kumar 
> 

Re: kbuild: move cc-option and cc-disable-warning after incl. arch Makefile

[Masahiro Yamada]

2018-03-19 9:41 GMT+09:00 Stefan Agner :
> Hi Masahiro,
>
> On 27.11.2017 13:15, Masahiro Yamada wrote:
>> Geert reported commit ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before
>> incl. arch Makefile") broke cross-compilation using a cross-compiler
>> that supports less compiler options than the host compiler.
>>
>> For example,
>>
>>   cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"
>>
>> This problem happens on architectures that setup CROSS_COMPILE in their
>> arch/*/Makefile.
>>
>> Move the cc-option and cc-disable-warning back to the original position,
>> but keep the Clang target options.
>
> This seems to break arm (32-bit) clang support for me. It seems to break
> correct compiler flag detection in some way.
>
> Just moving no-integrated-as back to before including the arch Makefile
> seems to fix the issue:

Sorry, looks like I broke it.



> --- a/Makefile
> +++ b/Makefile
> @@ -487,6 +487,7 @@ CLANG_GCC_TC:=
> --gcc-toolchain=$(GCC_TOOLCHAIN)
>  endif
>  KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC)
>  KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC)
> +KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
>  endif
>
>  RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
> -mindirect-branch-register
> @@ -744,7 +745,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning,
> tautological-compare)
>  # See modpost pattern 2
>  KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
>  KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
> -KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
>  KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
>  else
>
> Does that sound like a reasonable fix?


Yes, I think so.


For consistency, please move
KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
as well.




-- 
Best Regards
Masahiro Yamada

Re: kbuild: move cc-option and cc-disable-warning after incl. arch Makefile

[Masahiro Yamada]

2018-03-19 9:41 GMT+09:00 Stefan Agner :
> Hi Masahiro,
>
> On 27.11.2017 13:15, Masahiro Yamada wrote:
>> Geert reported commit ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before
>> incl. arch Makefile") broke cross-compilation using a cross-compiler
>> that supports less compiler options than the host compiler.
>>
>> For example,
>>
>>   cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"
>>
>> This problem happens on architectures that setup CROSS_COMPILE in their
>> arch/*/Makefile.
>>
>> Move the cc-option and cc-disable-warning back to the original position,
>> but keep the Clang target options.
>
> This seems to break arm (32-bit) clang support for me. It seems to break
> correct compiler flag detection in some way.
>
> Just moving no-integrated-as back to before including the arch Makefile
> seems to fix the issue:

Sorry, looks like I broke it.



> --- a/Makefile
> +++ b/Makefile
> @@ -487,6 +487,7 @@ CLANG_GCC_TC:=
> --gcc-toolchain=$(GCC_TOOLCHAIN)
>  endif
>  KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC)
>  KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC)
> +KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
>  endif
>
>  RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
> -mindirect-branch-register
> @@ -744,7 +745,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning,
> tautological-compare)
>  # See modpost pattern 2
>  KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
>  KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
> -KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
>  KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
>  else
>
> Does that sound like a reasonable fix?


Yes, I think so.


For consistency, please move
KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
as well.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] f2fs: Set GF_NOFS in read_cache_page_gfp while doing f2fs_quota_read

[Chao Yu]

On 2018/3/16 21:23, Ritesh Harjani wrote:
> Quota code itself is serializing the operations by taking mutex_lock.
> It seems a below deadlock can happen if GF_NOFS is not used in
> f2fs_quota_read
> 
> __switch_to+0x88
> __schedule+0x5b0
> schedule+0x78
> schedule_preempt_disabled+0x20
> __mutex_lock_slowpath+0xdc//mutex owner is itself
> mutex_lock+0x2c
> dquot_commit+0x30 //mutex_lock(>dqio_mutex);
> dqput+0xe0
> __dquot_drop+0x80
> dquot_drop+0x48
> f2fs_evict_inode+0x218
> evict+0xa8
> dispose_list+0x3c
> prune_icache_sb+0x58
> super_cache_scan+0xf4
> do_shrink_slab+0x208
> shrink_slab.part.40+0xac
> shrink_zone+0x1b0
> do_try_to_free_pages+0x25c
> try_to_free_pages+0x164
> __alloc_pages_nodemask+0x534
> do_read_cache_page+0x6c
> read_cache_page+0x14
> f2fs_quota_read+0xa4
> read_blk+0x54
> find_tree_dqentry+0xe4
> find_tree_dqentry+0xb8
> find_tree_dqentry+0xb8
> find_tree_dqentry+0xb8
> qtree_read_dquot+0x68
> v2_read_dquot+0x24
> dquot_acquire+0x5c// mutex_lock(>dqio_mutex);
> dqget+0x238
> __dquot_initialize+0xd4
> dquot_initialize+0x10
> dquot_file_open+0x34
> f2fs_file_open+0x6c
> do_dentry_open+0x1e4
> vfs_open+0x6c
> path_openat+0xa20
> do_filp_open+0x4c
> do_sys_open+0x178
> 
> Signed-off-by: Ritesh Harjani 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH] f2fs: Set GF_NOFS in read_cache_page_gfp while doing f2fs_quota_read

[Chao Yu]

On 2018/3/16 21:23, Ritesh Harjani wrote:
> Quota code itself is serializing the operations by taking mutex_lock.
> It seems a below deadlock can happen if GF_NOFS is not used in
> f2fs_quota_read
> 
> __switch_to+0x88
> __schedule+0x5b0
> schedule+0x78
> schedule_preempt_disabled+0x20
> __mutex_lock_slowpath+0xdc//mutex owner is itself
> mutex_lock+0x2c
> dquot_commit+0x30 //mutex_lock(>dqio_mutex);
> dqput+0xe0
> __dquot_drop+0x80
> dquot_drop+0x48
> f2fs_evict_inode+0x218
> evict+0xa8
> dispose_list+0x3c
> prune_icache_sb+0x58
> super_cache_scan+0xf4
> do_shrink_slab+0x208
> shrink_slab.part.40+0xac
> shrink_zone+0x1b0
> do_try_to_free_pages+0x25c
> try_to_free_pages+0x164
> __alloc_pages_nodemask+0x534
> do_read_cache_page+0x6c
> read_cache_page+0x14
> f2fs_quota_read+0xa4
> read_blk+0x54
> find_tree_dqentry+0xe4
> find_tree_dqentry+0xb8
> find_tree_dqentry+0xb8
> find_tree_dqentry+0xb8
> qtree_read_dquot+0x68
> v2_read_dquot+0x24
> dquot_acquire+0x5c// mutex_lock(>dqio_mutex);
> dqget+0x238
> __dquot_initialize+0xd4
> dquot_initialize+0x10
> dquot_file_open+0x34
> f2fs_file_open+0x6c
> do_dentry_open+0x1e4
> vfs_open+0x6c
> path_openat+0xa20
> do_filp_open+0x4c
> do_sys_open+0x178
> 
> Signed-off-by: Ritesh Harjani 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH] mm: add config for readahead window

[Huang, Ying]

Wei Wang  writes:

> Android devices boot time benefits by bigger readahead window setting from
> init. This patch will make readahead window a config so early boot can
> benefit by it as well.

Can you change the source code of init to call ioctl(BLKRASET) early?

Best Regards,
Huang, Ying

Re: [PATCH] mm: add config for readahead window

[Huang, Ying]

Wei Wang  writes:

> Android devices boot time benefits by bigger readahead window setting from
> init. This patch will make readahead window a config so early boot can
> benefit by it as well.

Can you change the source code of init to call ioctl(BLKRASET) early?

Best Regards,
Huang, Ying

[PATCH V2 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree

[Anson Huang]

i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
And this lvds2, along with lvds1, can be used to provide
external clock source to the internal pll, such as pll4_audio
and pll5_video.

This patch mainly adds the lvds2 to the clock tree and fix its
relationship with pll accordingly.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
---
 drivers/clk/imx/clk-imx6sx.c | 8 ++--
 include/dt-bindings/clock/imx6sx-clock.h | 6 +-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index e6d389e..478ad0d 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
"arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", 
"pll5_video_div",
"dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
 };
-static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
+static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", "lvds2_in", 
"dummy", };
 static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
 static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
 static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
@@ -158,8 +158,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node, "ipp_di0");
clks[IMX6SX_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node, "ipp_di1");
 
-   /* Clock source from external clock via CLK1 PAD */
+   /* Clock source from external clock via CLK1/2 PAD */
clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
+   clks[IMX6SX_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sx-anatop");
base = of_iomap(np, 0);
@@ -228,7 +229,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_PCIE_REF_125M] = imx_clk_gate("pcie_ref_125m", 
"pcie_ref", base + 0xe0, 19);
 
clks[IMX6SX_CLK_LVDS1_OUT] = imx_clk_gate_exclusive("lvds1_out", 
"lvds1_sel", base + 0x160, 10, BIT(12));
+   clks[IMX6SX_CLK_LVDS2_OUT] = imx_clk_gate_exclusive("lvds2_out", 
"lvds2_sel", base + 0x160, 11, BIT(13));
clks[IMX6SX_CLK_LVDS1_IN]  = imx_clk_gate_exclusive("lvds1_in",  
"anaclk1",   base + 0x160, 12, BIT(10));
+   clks[IMX6SX_CLK_LVDS2_IN]  = imx_clk_gate_exclusive("lvds2_in",  
"anaclk2",   base + 0x160, 13, BIT(11));
 
clks[IMX6SX_CLK_ENET_REF] = clk_register_divider_table(NULL, 
"enet_ref", "pll6_enet", 0,
base + 0xe0, 0, 2, 0, clk_enet_ref_table,
@@ -270,6 +273,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/*name
reg   shift   width   parent_names   num_parents */
clks[IMX6SX_CLK_LVDS1_SEL]  = imx_clk_mux("lvds1_sel",
base + 0x160, 0,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
+   clks[IMX6SX_CLK_LVDS2_SEL]  = imx_clk_mux("lvds2_sel",
base + 0x160, 5,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
 
np = ccm_node;
base = of_iomap(np, 0);
diff --git a/include/dt-bindings/clock/imx6sx-clock.h 
b/include/dt-bindings/clock/imx6sx-clock.h
index 36f0324..cd2d6c5 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -275,6 +275,10 @@
 #define IMX6SX_PLL6_BYPASS 262
 #define IMX6SX_PLL7_BYPASS 263
 #define IMX6SX_CLK_SPDIF_GCLK  264
-#define IMX6SX_CLK_CLK_END 265
+#define IMX6SX_CLK_LVDS2_SEL   265
+#define IMX6SX_CLK_LVDS2_OUT   266
+#define IMX6SX_CLK_LVDS2_IN267
+#define IMX6SX_CLK_ANACLK2 268
+#define IMX6SX_CLK_CLK_END 269
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
-- 
2.7.4

[PATCH V2 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree

[Anson Huang]

i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
And this lvds2, along with lvds1, can be used to provide
external clock source to the internal pll, such as pll4_audio
and pll5_video.

This patch mainly adds the lvds2 to the clock tree and fix its
relationship with pll accordingly.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
---
 drivers/clk/imx/clk-imx6sx.c | 8 ++--
 include/dt-bindings/clock/imx6sx-clock.h | 6 +-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index e6d389e..478ad0d 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
"arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", 
"pll5_video_div",
"dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
 };
-static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
+static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", "lvds2_in", 
"dummy", };
 static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
 static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
 static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
@@ -158,8 +158,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node, "ipp_di0");
clks[IMX6SX_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node, "ipp_di1");
 
-   /* Clock source from external clock via CLK1 PAD */
+   /* Clock source from external clock via CLK1/2 PAD */
clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
+   clks[IMX6SX_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sx-anatop");
base = of_iomap(np, 0);
@@ -228,7 +229,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_PCIE_REF_125M] = imx_clk_gate("pcie_ref_125m", 
"pcie_ref", base + 0xe0, 19);
 
clks[IMX6SX_CLK_LVDS1_OUT] = imx_clk_gate_exclusive("lvds1_out", 
"lvds1_sel", base + 0x160, 10, BIT(12));
+   clks[IMX6SX_CLK_LVDS2_OUT] = imx_clk_gate_exclusive("lvds2_out", 
"lvds2_sel", base + 0x160, 11, BIT(13));
clks[IMX6SX_CLK_LVDS1_IN]  = imx_clk_gate_exclusive("lvds1_in",  
"anaclk1",   base + 0x160, 12, BIT(10));
+   clks[IMX6SX_CLK_LVDS2_IN]  = imx_clk_gate_exclusive("lvds2_in",  
"anaclk2",   base + 0x160, 13, BIT(11));
 
clks[IMX6SX_CLK_ENET_REF] = clk_register_divider_table(NULL, 
"enet_ref", "pll6_enet", 0,
base + 0xe0, 0, 2, 0, clk_enet_ref_table,
@@ -270,6 +273,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/*name
reg   shift   width   parent_names   num_parents */
clks[IMX6SX_CLK_LVDS1_SEL]  = imx_clk_mux("lvds1_sel",
base + 0x160, 0,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
+   clks[IMX6SX_CLK_LVDS2_SEL]  = imx_clk_mux("lvds2_sel",
base + 0x160, 5,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
 
np = ccm_node;
base = of_iomap(np, 0);
diff --git a/include/dt-bindings/clock/imx6sx-clock.h 
b/include/dt-bindings/clock/imx6sx-clock.h
index 36f0324..cd2d6c5 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -275,6 +275,10 @@
 #define IMX6SX_PLL6_BYPASS 262
 #define IMX6SX_PLL7_BYPASS 263
 #define IMX6SX_CLK_SPDIF_GCLK  264
-#define IMX6SX_CLK_CLK_END 265
+#define IMX6SX_CLK_LVDS2_SEL   265
+#define IMX6SX_CLK_LVDS2_OUT   266
+#define IMX6SX_CLK_LVDS2_IN267
+#define IMX6SX_CLK_ANACLK2 268
+#define IMX6SX_CLK_CLK_END 269
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
-- 
2.7.4

[PATCH V2 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

[Anson Huang]

On i.MX6SX SabreAuto board, there is external 24MHz clock
source for analog clock2, add this clock source to clock tree.

Signed-off-by: Anson Huang 
---
changes since V1:
remove unnecessary clocks container.
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 72da5ac..a3b022b 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,12 @@
reg = <0x8000 0x8000>;
};
 
+   codec_osc: anaclk2 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.7.4

[PATCH V2 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

[Anson Huang]

On i.MX6SX SabreAuto board, there is external 24MHz clock
source for analog clock2, add this clock source to clock tree.

Signed-off-by: Anson Huang 
---
changes since V1:
remove unnecessary clocks container.
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 72da5ac..a3b022b 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,12 @@
reg = <0x8000 0x8000>;
};
 
+   codec_osc: anaclk2 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.7.4

[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping

[Jason Cai (Xiang Feng)]

When using vfio to pass through a PCIe device (e.g. a GPU card) that
has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
pinning because PFNs of PCI BAR are not backed by struct page, and
the corresponding VMA has flag VM_PFNMAP.

With this change, when pinning a region which is a raw PFN mapping,
it can skip unnecessary user memory pinning process, and thus, can
significantly improve VM's boot up time when passing through devices
via VFIO. In my test on a Xeon E5 2.6GHz, the time mapping a 16GB
BAR was reduced from about 0.4s to 1.5us.

Signed-off-by: Jason Cai (Xiang Feng) 
---
 drivers/vfio/vfio_iommu_type1.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45657e2b1ff7..0658f35318b8 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -397,7 +397,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
 {
unsigned long pfn = 0;
long ret, pinned = 0, lock_acct = 0;
-   bool rsvd;
dma_addr_t iova = vaddr - dma->vaddr + dma->iova;

/* This code path is only user initiated */
@@ -408,14 +407,22 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
return ret;

+   if (is_invalid_reserved_pfn(*pfn_base)) {
+   struct vm_area_struct *vma;
+   down_read(>mm->mmap_sem);
+   vma = find_vma_intersection(current->mm, vaddr, vaddr + 1);
+   pinned = min(npage, (long)vma_pages(vma));
+   up_read(>mm->mmap_sem);
+   return pinned;
+   }
+
pinned++;
-   rsvd = is_invalid_reserved_pfn(*pfn_base);

/*
 * Reserved pages aren't counted against the user, externally pinned
 * pages are already counted against the user.
 */
-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap && current->mm->locked_vm + 1 > limit) {
put_pfn(*pfn_base, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
@@ -435,13 +442,12 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
break;

-   if (pfn != *pfn_base + pinned ||
-   rsvd != is_invalid_reserved_pfn(pfn)) {
+   if (pfn != *pfn_base + pinned) {
put_pfn(pfn, dma->prot);
break;
}

-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap &&
current->mm->locked_vm + lock_acct + 1 > limit) {
put_pfn(pfn, dma->prot);
@@ -459,10 +465,8 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,

 unpin_out:
if (ret) {
-   if (!rsvd) {
-   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
-   put_pfn(pfn, dma->prot);
-   }
+   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
+   put_pfn(pfn, dma->prot);

return ret;
}
--
2.13.6

[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping

[Jason Cai (Xiang Feng)]

When using vfio to pass through a PCIe device (e.g. a GPU card) that
has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
pinning because PFNs of PCI BAR are not backed by struct page, and
the corresponding VMA has flag VM_PFNMAP.

With this change, when pinning a region which is a raw PFN mapping,
it can skip unnecessary user memory pinning process, and thus, can
significantly improve VM's boot up time when passing through devices
via VFIO. In my test on a Xeon E5 2.6GHz, the time mapping a 16GB
BAR was reduced from about 0.4s to 1.5us.

Signed-off-by: Jason Cai (Xiang Feng) 
---
 drivers/vfio/vfio_iommu_type1.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45657e2b1ff7..0658f35318b8 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -397,7 +397,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
 {
unsigned long pfn = 0;
long ret, pinned = 0, lock_acct = 0;
-   bool rsvd;
dma_addr_t iova = vaddr - dma->vaddr + dma->iova;

/* This code path is only user initiated */
@@ -408,14 +407,22 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
return ret;

+   if (is_invalid_reserved_pfn(*pfn_base)) {
+   struct vm_area_struct *vma;
+   down_read(>mm->mmap_sem);
+   vma = find_vma_intersection(current->mm, vaddr, vaddr + 1);
+   pinned = min(npage, (long)vma_pages(vma));
+   up_read(>mm->mmap_sem);
+   return pinned;
+   }
+
pinned++;
-   rsvd = is_invalid_reserved_pfn(*pfn_base);

/*
 * Reserved pages aren't counted against the user, externally pinned
 * pages are already counted against the user.
 */
-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap && current->mm->locked_vm + 1 > limit) {
put_pfn(*pfn_base, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
@@ -435,13 +442,12 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
break;

-   if (pfn != *pfn_base + pinned ||
-   rsvd != is_invalid_reserved_pfn(pfn)) {
+   if (pfn != *pfn_base + pinned) {
put_pfn(pfn, dma->prot);
break;
}

-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap &&
current->mm->locked_vm + lock_acct + 1 > limit) {
put_pfn(pfn, dma->prot);
@@ -459,10 +465,8 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,

 unpin_out:
if (ret) {
-   if (!rsvd) {
-   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
-   put_pfn(pfn, dma->prot);
-   }
+   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
+   put_pfn(pfn, dma->prot);

return ret;
}
--
2.13.6

Re: [PATCH 0/2] drm/sun4i: Fix some error handling paths in 'sun4i_hdmi_bind()'

[Chen-Yu Tsai]

On Mon, Mar 19, 2018 at 6:48 AM, Christophe JAILLET
 wrote:
> I've splitted these fixes into 2 patches becasue they do not fixe the same
> commit.
>
> Christophe JAILLET (2):
>   drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
>   drm/sun4i: hdmi: Fix another error handling path in
> 'sun4i_hdmi_bind()'

Reviewed-by: Chen-Yu Tsai 

for both patches.

Re: [PATCH 0/2] drm/sun4i: Fix some error handling paths in 'sun4i_hdmi_bind()'

[Chen-Yu Tsai]

On Mon, Mar 19, 2018 at 6:48 AM, Christophe JAILLET
 wrote:
> I've splitted these fixes into 2 patches becasue they do not fixe the same
> commit.
>
> Christophe JAILLET (2):
>   drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
>   drm/sun4i: hdmi: Fix another error handling path in
> 'sun4i_hdmi_bind()'

Reviewed-by: Chen-Yu Tsai 

for both patches.