Re: writev error codes

[Michal Hocko]

On Thu 19-01-17 15:09:52, Michael Kerrisk wrote:
> Hello Michal,
> 
> On 19 January 2017 at 04:44, Michal Hocko  wrote:
> > Hi,
> > we have noticed that one of the LTP tests started to fail after
> > 99526912c934 ("fix iov_iter_fault_in_readable()"). The code has expected
> > EINVAL while it gets EFAULT. I believe the new behavior is reasonable,
> > but checking the man 2 writev, there is no mention about EFAULT,
> > and other errnos for that matter, so it seems this is rather under
> > documented and it can confuse users. LTP has been fixed in the meantime
> > [1] but this might come unexpected to others.
> >
> > In principle writev as a write
> > "multiplier" should be allowed all the error codes that write(2) allows,
> > right? I am not sure how we should reflect that. Either c what we have
> > in man 2 write or put a reference to it and only describe writev
> > specific, if there are any (I haven't checked that).
> >
> > [1] 
> > https://github.com/linux-test-project/ltp/commit/db19194527060a962955a7db54a2f5710e69bec9
> 
> Perhaps I am misunderstanding you, but in the writev(2) page there is the 
> text:
> 
> ERRORS
>The  errors  are  as given for read(2) and write(2).  Furthermore,
>preadv(), preadv2(), pwritev(), and pwritev2() can also  fail  for
>the  same reasons as lseek(2).

This has hit right to the blind spot. Sorry about the noise!

> 
> And in the write(2) page, we have:
> 
>EFAULT buf is outside your accessible address space.
> 
> Does this not cover the case you describe?

Yes

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA

[Pavel Machek]

On Wed 2017-01-18 17:29:05, Laura Abbott wrote:
> 
> Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option
> provides key security features that are to be expected on a modern
> system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more
> accurately describes what this option is intended to do.

I think this is bad change. CONFIG_DEBUG_RODATA is describing what it
does, CONFIG_HARDENED_PAGE_MAPPINGS is advertising.

We don't do advertising, and we don't force people to re-answer the
config questions without good reason.

CONFIG_HARDENED_RODATA might fix the first problem, but not the second
one.

Pavel


> Signed-off-by: Laura Abbott 
> ---
>  Documentation/DocBook/kgdb.tmpl|  8 
>  Documentation/security/self-protection.txt |  2 +-
>  arch/arm/Kconfig   |  1 +
>  arch/arm/configs/aspeed_g4_defconfig   |  2 +-
>  arch/arm/configs/aspeed_g5_defconfig   |  2 +-
>  arch/arm/include/asm/cacheflush.h  |  2 +-
>  arch/arm/kernel/patch.c|  2 +-
>  arch/arm/kernel/vmlinux.lds.S  |  8 
>  arch/arm/mm/Kconfig| 14 +-
>  arch/arm/mm/init.c |  4 ++--
>  arch/arm64/Kconfig |  4 +---
>  arch/arm64/Kconfig.debug   |  2 +-
>  arch/parisc/Kconfig|  1 +
>  arch/parisc/Kconfig.debug  | 11 ---
>  arch/parisc/configs/712_defconfig  |  2 +-
>  arch/parisc/configs/c3000_defconfig|  2 +-
>  arch/parisc/mm/init.c  |  2 +-
>  arch/s390/Kconfig  |  4 +---
>  arch/x86/Kconfig   |  4 +---
>  include/linux/init.h   |  4 ++--
>  init/main.c|  4 ++--
>  kernel/configs/android-recommended.config  |  2 +-
>  kernel/power/hibernate.c   |  2 +-
>  kernel/power/power.h   |  4 ++--
>  kernel/power/snapshot.c|  4 ++--
>  security/Kconfig   | 16 
>  26 files changed, 51 insertions(+), 62 deletions(-)
> 
> diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
> index f3abca7..a79b638 100644
> --- a/Documentation/DocBook/kgdb.tmpl
> +++ b/Documentation/DocBook/kgdb.tmpl
> @@ -115,12 +115,12 @@
>  
>  
>  If the architecture that you are using supports the kernel option
> -CONFIG_DEBUG_RODATA, you should consider turning it off.  This
> +CONFIG_HARDENED_PAGE_MAPPINGS, you should consider turning it off.  This
>  option will prevent the use of software breakpoints because it
>  marks certain regions of the kernel's memory space as read-only.
>  If kgdb supports it for the architecture you are using, you can
>  use hardware breakpoints if you desire to run with the
> -CONFIG_DEBUG_RODATA option turned on, else you need to turn off
> +CONFIG_HARDENED_PAGE_MAPPINGS option turned on, else you need to turn off
>  this option.
>  
>  
> @@ -135,7 +135,7 @@
>  Here is an example set of .config symbols to enable or
>  disable for kgdb:
>  
> -# CONFIG_DEBUG_RODATA is not set
> +# CONFIG_HARDENED_PAGE_MAPPINGS is not 
> set
>  CONFIG_FRAME_POINTER=y
>  CONFIG_KGDB=y
>  CONFIG_KGDB_SERIAL_CONSOLE=y
> @@ -166,7 +166,7 @@
>  
>  Here is an example set of .config symbols to enable/disable kdb:
>  
> -# CONFIG_DEBUG_RODATA is not set
> +# CONFIG_HARDENED_PAGE_MAPPINGS is not 
> set
>  CONFIG_FRAME_POINTER=y
>  CONFIG_KGDB=y
>  CONFIG_KGDB_SERIAL_CONSOLE=y
> diff --git a/Documentation/security/self-protection.txt 
> b/Documentation/security/self-protection.txt
> index 3010576..da8cb36 100644
> --- a/Documentation/security/self-protection.txt
> +++ b/Documentation/security/self-protection.txt
> @@ -51,7 +51,7 @@ kernel, they are implemented in a way where the memory is 
> temporarily
>  made writable during the update, and then returned to the original
>  permissions.)
>  
> -In support of this are (the poorly named) CONFIG_DEBUG_RODATA and
> +In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and
>  CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not
>  writable, data is not executable, and read-only data is neither writable
>  nor executable.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 186c4c2..09aff28 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,6 +7,7 @@ config ARM
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_HAVE_CUSTOM_GPIO_H
>   select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   

Re: writev error codes

[Michal Hocko]

On Thu 19-01-17 15:09:52, Michael Kerrisk wrote:
> Hello Michal,
> 
> On 19 January 2017 at 04:44, Michal Hocko  wrote:
> > Hi,
> > we have noticed that one of the LTP tests started to fail after
> > 99526912c934 ("fix iov_iter_fault_in_readable()"). The code has expected
> > EINVAL while it gets EFAULT. I believe the new behavior is reasonable,
> > but checking the man 2 writev, there is no mention about EFAULT,
> > and other errnos for that matter, so it seems this is rather under
> > documented and it can confuse users. LTP has been fixed in the meantime
> > [1] but this might come unexpected to others.
> >
> > In principle writev as a write
> > "multiplier" should be allowed all the error codes that write(2) allows,
> > right? I am not sure how we should reflect that. Either c what we have
> > in man 2 write or put a reference to it and only describe writev
> > specific, if there are any (I haven't checked that).
> >
> > [1] 
> > https://github.com/linux-test-project/ltp/commit/db19194527060a962955a7db54a2f5710e69bec9
> 
> Perhaps I am misunderstanding you, but in the writev(2) page there is the 
> text:
> 
> ERRORS
>The  errors  are  as given for read(2) and write(2).  Furthermore,
>preadv(), preadv2(), pwritev(), and pwritev2() can also  fail  for
>the  same reasons as lseek(2).

This has hit right to the blind spot. Sorry about the noise!

> 
> And in the write(2) page, we have:
> 
>EFAULT buf is outside your accessible address space.
> 
> Does this not cover the case you describe?

Yes

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA

[Pavel Machek]

On Wed 2017-01-18 17:29:05, Laura Abbott wrote:
> 
> Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option
> provides key security features that are to be expected on a modern
> system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more
> accurately describes what this option is intended to do.

I think this is bad change. CONFIG_DEBUG_RODATA is describing what it
does, CONFIG_HARDENED_PAGE_MAPPINGS is advertising.

We don't do advertising, and we don't force people to re-answer the
config questions without good reason.

CONFIG_HARDENED_RODATA might fix the first problem, but not the second
one.

Pavel


> Signed-off-by: Laura Abbott 
> ---
>  Documentation/DocBook/kgdb.tmpl|  8 
>  Documentation/security/self-protection.txt |  2 +-
>  arch/arm/Kconfig   |  1 +
>  arch/arm/configs/aspeed_g4_defconfig   |  2 +-
>  arch/arm/configs/aspeed_g5_defconfig   |  2 +-
>  arch/arm/include/asm/cacheflush.h  |  2 +-
>  arch/arm/kernel/patch.c|  2 +-
>  arch/arm/kernel/vmlinux.lds.S  |  8 
>  arch/arm/mm/Kconfig| 14 +-
>  arch/arm/mm/init.c |  4 ++--
>  arch/arm64/Kconfig |  4 +---
>  arch/arm64/Kconfig.debug   |  2 +-
>  arch/parisc/Kconfig|  1 +
>  arch/parisc/Kconfig.debug  | 11 ---
>  arch/parisc/configs/712_defconfig  |  2 +-
>  arch/parisc/configs/c3000_defconfig|  2 +-
>  arch/parisc/mm/init.c  |  2 +-
>  arch/s390/Kconfig  |  4 +---
>  arch/x86/Kconfig   |  4 +---
>  include/linux/init.h   |  4 ++--
>  init/main.c|  4 ++--
>  kernel/configs/android-recommended.config  |  2 +-
>  kernel/power/hibernate.c   |  2 +-
>  kernel/power/power.h   |  4 ++--
>  kernel/power/snapshot.c|  4 ++--
>  security/Kconfig   | 16 
>  26 files changed, 51 insertions(+), 62 deletions(-)
> 
> diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
> index f3abca7..a79b638 100644
> --- a/Documentation/DocBook/kgdb.tmpl
> +++ b/Documentation/DocBook/kgdb.tmpl
> @@ -115,12 +115,12 @@
>  
>  
>  If the architecture that you are using supports the kernel option
> -CONFIG_DEBUG_RODATA, you should consider turning it off.  This
> +CONFIG_HARDENED_PAGE_MAPPINGS, you should consider turning it off.  This
>  option will prevent the use of software breakpoints because it
>  marks certain regions of the kernel's memory space as read-only.
>  If kgdb supports it for the architecture you are using, you can
>  use hardware breakpoints if you desire to run with the
> -CONFIG_DEBUG_RODATA option turned on, else you need to turn off
> +CONFIG_HARDENED_PAGE_MAPPINGS option turned on, else you need to turn off
>  this option.
>  
>  
> @@ -135,7 +135,7 @@
>  Here is an example set of .config symbols to enable or
>  disable for kgdb:
>  
> -# CONFIG_DEBUG_RODATA is not set
> +# CONFIG_HARDENED_PAGE_MAPPINGS is not 
> set
>  CONFIG_FRAME_POINTER=y
>  CONFIG_KGDB=y
>  CONFIG_KGDB_SERIAL_CONSOLE=y
> @@ -166,7 +166,7 @@
>  
>  Here is an example set of .config symbols to enable/disable kdb:
>  
> -# CONFIG_DEBUG_RODATA is not set
> +# CONFIG_HARDENED_PAGE_MAPPINGS is not 
> set
>  CONFIG_FRAME_POINTER=y
>  CONFIG_KGDB=y
>  CONFIG_KGDB_SERIAL_CONSOLE=y
> diff --git a/Documentation/security/self-protection.txt 
> b/Documentation/security/self-protection.txt
> index 3010576..da8cb36 100644
> --- a/Documentation/security/self-protection.txt
> +++ b/Documentation/security/self-protection.txt
> @@ -51,7 +51,7 @@ kernel, they are implemented in a way where the memory is 
> temporarily
>  made writable during the update, and then returned to the original
>  permissions.)
>  
> -In support of this are (the poorly named) CONFIG_DEBUG_RODATA and
> +In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and
>  CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not
>  writable, data is not executable, and read-only data is neither writable
>  nor executable.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 186c4c2..09aff28 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,6 +7,7 @@ config ARM
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_HAVE_CUSTOM_GPIO_H
>   select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select 

Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

[Boris Brezillon]

On Wed, 18 Jan 2017 16:20:10 -0600
Rob Herring  wrote:

> On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> > Hello,
> > 
> > (Side note: you guys should learn about stripping irrelevant parts of
> > an e-mail when replying!)
> >
> > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
> >   
> > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > > as the oldest supported compatible and be done with it, no ? It looks a
> > > > bit crappy though, I admit that ...  
> > > 
> > > Let's stop bikeshedding and wait for DT maintainers feedback
> > > before taking a decision ;-).
> > > 
> > > Rob, Mark, any opinion?  
> >  
> 
> Sigh, is how to do compatibles really not yet understood?

Apparently not, and I fear this is not the last misunderstanding on my
side ;-).

>  
> > I agree that a clarification would be good. There are really two
> > options:
> > 
> >  1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.  
> 
> This. And no wildcards in the compatible string. 
> 
> >  2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.  
> 
> I wouldn't object to this from a DT perspective as I have no clue 
> generally if IP blocks are "the same" or not. Subsystem maintainers will 
> object though.
> 
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.  
> 
> They are both future-proof. #2 has the disadvantage of requiring a 
> kernel update for a new SoC. 
> 
> Rob

Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

[Boris Brezillon]

On Wed, 18 Jan 2017 16:20:10 -0600
Rob Herring  wrote:

> On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> > Hello,
> > 
> > (Side note: you guys should learn about stripping irrelevant parts of
> > an e-mail when replying!)
> >
> > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
> >   
> > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > > as the oldest supported compatible and be done with it, no ? It looks a
> > > > bit crappy though, I admit that ...  
> > > 
> > > Let's stop bikeshedding and wait for DT maintainers feedback
> > > before taking a decision ;-).
> > > 
> > > Rob, Mark, any opinion?  
> >  
> 
> Sigh, is how to do compatibles really not yet understood?

Apparently not, and I fear this is not the last misunderstanding on my
side ;-).

>  
> > I agree that a clarification would be good. There are really two
> > options:
> > 
> >  1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.  
> 
> This. And no wildcards in the compatible string. 
> 
> >  2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.  
> 
> I wouldn't object to this from a DT perspective as I have no clue 
> generally if IP blocks are "the same" or not. Subsystem maintainers will 
> object though.
> 
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.  
> 
> They are both future-proof. #2 has the disadvantage of requiring a 
> kernel update for a new SoC. 
> 
> Rob

[GIT PULL] xen: fix for 4.10 rc4

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.10-rc4-tag

It contains a fix for Xen running in nested virtualization environment.

Thanks.

Juergen

 drivers/xen/platform-pci.c | 71 ++
 1 file changed, 71 insertions(+)

Stefano Stabellini (1):
  partially revert "xen: Remove event channel notification through Xen PCI 
platform device"

[GIT PULL] xen: fix for 4.10 rc4

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.10-rc4-tag

It contains a fix for Xen running in nested virtualization environment.

Thanks.

Juergen

 drivers/xen/platform-pci.c | 71 ++
 1 file changed, 71 insertions(+)

Stefano Stabellini (1):
  partially revert "xen: Remove event channel notification through Xen PCI 
platform device"

Re: [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Juergen Gross]

On 18/01/17 21:14, Boris Ostrovsky wrote:
> On 01/16/2017 09:15 AM, Juergen Gross wrote:
>> +
>> +static uint32_t xs_request_enter(struct xb_req_data *req)
>> +{
>> +uint32_t rq_id;
>> +
>> +req->type = req->msg.type;
>> +
>> +spin_lock(_state_lock);
>> +for (;;) {
>> +if (req->msg.tx_id != 0)
>> +break;
>> +if (xs_suspend_active) {
>> +spin_unlock(_state_lock);
>> +wait_event(xs_state_enter_wq, xs_suspend_active == 0);
>> +spin_lock(_state_lock);
>> +continue;
>> +}
>> +if (req->type == XS_TRANSACTION_START)
>> +xs_state_users++;
>> +break;
>> +}
>> +xs_state_users++;
>> +rq_id = xs_request_id++;
>> +spin_unlock(_state_lock);
>> +
>> +return rq_id;
>> +}
> 
> I should have noticed this last time but I've been looking at this code
> again and I don't think I understand why you are incrementing count for
> XS_TRANSACTION_START inside the loop.
> 
> In fact, why not just 'while(xs_suspend_active) {}' loop?

That's a valid question.

I'll change it. The reason to have the larger loop body isn't existing
any longer.


Juergen

Re: [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Juergen Gross]

On 18/01/17 21:14, Boris Ostrovsky wrote:
> On 01/16/2017 09:15 AM, Juergen Gross wrote:
>> +
>> +static uint32_t xs_request_enter(struct xb_req_data *req)
>> +{
>> +uint32_t rq_id;
>> +
>> +req->type = req->msg.type;
>> +
>> +spin_lock(_state_lock);
>> +for (;;) {
>> +if (req->msg.tx_id != 0)
>> +break;
>> +if (xs_suspend_active) {
>> +spin_unlock(_state_lock);
>> +wait_event(xs_state_enter_wq, xs_suspend_active == 0);
>> +spin_lock(_state_lock);
>> +continue;
>> +}
>> +if (req->type == XS_TRANSACTION_START)
>> +xs_state_users++;
>> +break;
>> +}
>> +xs_state_users++;
>> +rq_id = xs_request_id++;
>> +spin_unlock(_state_lock);
>> +
>> +return rq_id;
>> +}
> 
> I should have noticed this last time but I've been looking at this code
> again and I don't think I understand why you are incrementing count for
> XS_TRANSACTION_START inside the loop.
> 
> In fact, why not just 'while(xs_suspend_active) {}' loop?

That's a valid question.

I'll change it. The reason to have the larger loop body isn't existing
any longer.


Juergen

Re: [PATCH V2 00/18] *** SUBJECT HERE ***

[Greg KH]

On Wed, Jan 18, 2017 at 04:44:32PM -0700, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 



"interesting" subject :(

Re: [PATCH V2 00/18] *** SUBJECT HERE ***

[Greg KH]

On Wed, Jan 18, 2017 at 04:44:32PM -0700, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 



"interesting" subject :(

Re: [PATCH v6 03/25] usb: ulpi: Support device discovery via DT

[Greg Kroah-Hartman]

On Thu, Jan 19, 2017 at 02:33:49PM +0800, Peter Chen wrote:
> On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> > The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> > product ID registers. This makes it impossible to make a ULPI
> > driver match against the ID registers. Add support to discover
> > the ULPI phys via DT help alleviate this problem. In the DT case,
> > we'll look for a ULPI bus node underneath the device registering
> > the ULPI viewport (or the parent of that device to support
> > chipidea's device layout) and then match up the phy node
> > underneath that with the ULPI device that's created.
> > 
> > The side benefit of this is that we can use standard properties
> > in the phy node like clks, regulators, gpios, etc. because we
> > don't have firmware like ACPI to turn these things on for us. And
> > we can use the DT phy binding to point our phy consumer to the
> > phy provider.
> > 
> > The ULPI bus code supports native enumeration by reading the
> > vendor ID and product ID registers at device creation time, but
> > we can't be certain that those register reads will succeed if the
> > phy is not powered up. To avoid any problems with reading the ID
> > registers before the phy is powered we fallback to DT matching
> > when the ID reads fail.
> > 
> > If the ULPI spec had some generic power sequencing for these
> > registers we could put that into the ULPI bus layer and power up
> > the device before reading the ID registers. Unfortunately this
> > doesn't exist and the power sequence is usually device specific.
> > By having the device matched up with DT we can avoid this
> > problem.
> > 
> > Cc: Greg Kroah-Hartman 
> > Acked-by: Heikki Krogerus 
> > Cc: 
> > Acked-by: Rob Herring 
> > Signed-off-by: Stephen Boyd 
> 
> Greg, is it ok I pick up this patch, and send it with chipidea
> changes together for 4.11-rc1 later?

No objection from me.

thanks,

greg k-h

Re: [PATCH v6 03/25] usb: ulpi: Support device discovery via DT

[Greg Kroah-Hartman]

On Thu, Jan 19, 2017 at 02:33:49PM +0800, Peter Chen wrote:
> On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> > The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> > product ID registers. This makes it impossible to make a ULPI
> > driver match against the ID registers. Add support to discover
> > the ULPI phys via DT help alleviate this problem. In the DT case,
> > we'll look for a ULPI bus node underneath the device registering
> > the ULPI viewport (or the parent of that device to support
> > chipidea's device layout) and then match up the phy node
> > underneath that with the ULPI device that's created.
> > 
> > The side benefit of this is that we can use standard properties
> > in the phy node like clks, regulators, gpios, etc. because we
> > don't have firmware like ACPI to turn these things on for us. And
> > we can use the DT phy binding to point our phy consumer to the
> > phy provider.
> > 
> > The ULPI bus code supports native enumeration by reading the
> > vendor ID and product ID registers at device creation time, but
> > we can't be certain that those register reads will succeed if the
> > phy is not powered up. To avoid any problems with reading the ID
> > registers before the phy is powered we fallback to DT matching
> > when the ID reads fail.
> > 
> > If the ULPI spec had some generic power sequencing for these
> > registers we could put that into the ULPI bus layer and power up
> > the device before reading the ID registers. Unfortunately this
> > doesn't exist and the power sequence is usually device specific.
> > By having the device matched up with DT we can avoid this
> > problem.
> > 
> > Cc: Greg Kroah-Hartman 
> > Acked-by: Heikki Krogerus 
> > Cc: 
> > Acked-by: Rob Herring 
> > Signed-off-by: Stephen Boyd 
> 
> Greg, is it ok I pick up this patch, and send it with chipidea
> changes together for 4.11-rc1 later?

No objection from me.

thanks,

greg k-h

Re: [PATCH 0/6 v4] adv7511 EDID probing improvements

[John Stultz]

On Wed, Jan 18, 2017 at 9:22 PM, Archit Taneja  wrote:
>
>
> On 01/19/2017 04:34 AM, Laurent Pinchart wrote:
>>
>> Hi John,
>>
>> Thank you for the patches.
>>
>> On Monday 16 Jan 2017 16:52:46 John Stultz wrote:
>>>
>>> Wanted to re-send out v4  of this patch set, integrating some
>>> changes suggested by Laurent, for consideration for merging for
>>> v4.11
>>>
>>> The first three patches are fixups that are hopefully straight
>>> forward, integrating feedback I got from Laurant, with minimal
>>> change from the previous versions.
>>>
>>> The last three patches try to clean up and rework the EDID
>>> probing code, to avoid issues seen on HiKey. I've reworked these
>>> more significantly since v3 to address feedback from Laurent.
>>>
>>> Thoughts and feedback would be appreciated!
>>
>>
>> For the whole series,
>>
>> Tested-by: Laurent Pinchart 
>
>
> Queued to drm-misc-next. Updated the commit messages for patches 5
> and 6 as suggested by Laurent.

Ah! Many thanks Archit! I was going to respin the patches tomorrow but
you beat me to it. :)

The help is much appreciated!
-john

Re: [PATCH 0/6 v4] adv7511 EDID probing improvements

[John Stultz]

On Wed, Jan 18, 2017 at 9:22 PM, Archit Taneja  wrote:
>
>
> On 01/19/2017 04:34 AM, Laurent Pinchart wrote:
>>
>> Hi John,
>>
>> Thank you for the patches.
>>
>> On Monday 16 Jan 2017 16:52:46 John Stultz wrote:
>>>
>>> Wanted to re-send out v4  of this patch set, integrating some
>>> changes suggested by Laurent, for consideration for merging for
>>> v4.11
>>>
>>> The first three patches are fixups that are hopefully straight
>>> forward, integrating feedback I got from Laurant, with minimal
>>> change from the previous versions.
>>>
>>> The last three patches try to clean up and rework the EDID
>>> probing code, to avoid issues seen on HiKey. I've reworked these
>>> more significantly since v3 to address feedback from Laurent.
>>>
>>> Thoughts and feedback would be appreciated!
>>
>>
>> For the whole series,
>>
>> Tested-by: Laurent Pinchart 
>
>
> Queued to drm-misc-next. Updated the commit messages for patches 5
> and 6 as suggested by Laurent.

Ah! Many thanks Archit! I was going to respin the patches tomorrow but
you beat me to it. :)

The help is much appreciated!
-john

tip.today - scheduler bam boom crash (cpu hotplug)

[Mike Galbraith]

Mindless testing only, too sick to work, not sick enough to be immune
to boredom.  Was verifying first warning wasn't somehow rt inspired,
but while doing so, plain nopreempt (and no rt patch set) went boom.

[  203.088255] smpboot: CPU 1 is now offline
[  203.168181] smpboot: CPU 2 is now offline
[  203.221461] x86: Booting SMP configuration:
[  203.221464] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  203.221728] [ cut here ]
[  203.221733] WARNING: CPU: 1 PID: 0 at kernel/sched/clock.c:149 
set_sched_clock_stable+0x43/0x50
[  203.221733] Modules linked in: nls_utf8(E) isofs(E) ebtable_filter(E) 
ebtables(E) fuse(E) nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E) br_netfilter(E) 
nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) af_packet(E) bridge(E) 
stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) 
nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) 
iptable_raw(E) xt_CT(E) iptable_filter(E) ip6table_mangle(E) 
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) 
ip6table_filter(E) ip6_tables(E) x_tables(E) nls_iso8859_1(E) 
snd_hda_codec_hdmi(E) nls_cp437(E) intel_rapl(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) coretemp(E) kvm_intel(E) snd_hda_codec_realtek(E) 
snd_hda_codec_generic(E) kvm(E) snd_hda_intel(E)
[  203.221748]  snd_hda_codec(E) irqbypass(E) crct10dif_pclmul(E) 
snd_hda_core(E) snd_hwdep(E) nfsd(E) crc32_pclmul(E) crc32c_intel(E) 
ghash_clmulni_intel(E) pcbc(E) snd_pcm(E) auth_rpcgss(E) aesni_intel(E) 
aes_x86_64(E) snd_timer(E) nfs_acl(E) joydev(E) crypto_simd(E) snd(E) lockd(E) 
grace(E) iTCO_wdt(E) iTCO_vendor_support(E) lpc_ich(E) mei_me(E) i2c_i801(E) 
mei(E) pcspkr(E) glue_helper(E) mfd_core(E) shpchp(E) intel_smartconnect(E) 
sunrpc(E) soundcore(E) tpm_infineon(E) fan(E) thermal(E) battery(E) cryptd(E) 
efivarfs(E) sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_logitech_dj(E) uas(E) 
usb_storage(E) hid_generic(E) usbhid(E) nouveau(E) wmi(E) i2c_algo_bit(E) 
drm_kms_helper(E) ahci(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) 
fb_sys_fops(E) libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E)
[  203.221765]  ttm(E) libata(E) r8169(E) mii(E) drm(E) usbcore(E) fjes(E) 
video(E) button(E) sd_mod(E) vfat(E) fat(E) ext4(E) crc16(E) jbd2(E) mbcache(E) 
dm_mod(E) loop(E) sg(E) scsi_mod(E) autofs4(E)
[  203.221773] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GE   
4.10.0-tip-default #29
[  203.221774] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 
09/23/2013
[  203.221774] Call Trace:
[  203.221778]  dump_stack+0x63/0x90
[  203.221780]  __warn+0xd1/0xf0
[  203.221782]  warn_slowpath_null+0x1d/0x20
[  203.221782]  set_sched_clock_stable+0x43/0x50
[  203.221784]  early_init_intel+0x225/0x360
[  203.221785]  init_intel+0x18/0x2d0
[  203.221786]  identify_cpu+0x2d1/0x4d0
[  203.221786]  identify_secondary_cpu+0x18/0x80
[  203.221789]  smp_store_cpu_info+0x3e/0x40
[  203.221790]  start_secondary+0x53/0x180
[  203.221791]  start_cpu+0x14/0x14
[  203.221792] ---[ end trace 262c7e4b746d5a76 ]---

[  207.525918] smpboot: CPU 2 is now offline
[  207.586516] smpboot: CPU 4 is now offline
[  207.642988] smpboot: CPU 6 is now offline
[  207.682207] x86: Booting SMP configuration:
[  207.682210] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  207.682505] sched_clock: Marking stable (207412639708, 0)->(207410993286, 
1646422)
[  207.706220] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  207.706502] sched_clock: Marking stable (207524564558, 0)->(207522917721, 
1646837)
[  207.730376] smpboot: Booting Node 0 Processor 4 APIC 0x1
[  207.730644] sched_clock: Marking stable (207585448402, 0)->(207583801309, 
1647093)
[  207.754593] smpboot: Booting Node 0 Processor 6 APIC 0x5
[  207.754881] sched_clock: Marking stable (207641939733, 0)->(207640292394, 
1647339)
[  207.802195] smpboot: CPU 3 is now offline
[  207.862396] smpboot: CPU 4 is now offline
[  207.927159] [ cut here ]
[  207.927163] WARNING: CPU: 6 PID: 45 at kernel/sched/sched.h:807 
assert_clock_updated.isra.62.part.63+0x25/0x27
[  207.927164] rq->clock_update_flags < RQCF_ACT_SKIP
[  207.927164] Modules linked in: nls_utf8(E) isofs(E) ebtable_filter(E) 
ebtables(E) fuse(E) nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E) br_netfilter(E) 
nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) af_packet(E) bridge(E) 
stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) 
nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) 
iptable_raw(E) xt_CT(E) iptable_filter(E) ip6table_mangle(E) 
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) 
ip6table_filter(E) ip6_tables(E) x_tables(E) nls_iso8859_1(E) 
snd_hda_codec_hdmi(E) nls_cp437(E) intel_rapl(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) coretemp(E) kvm_intel(E) 

tip.today - scheduler bam boom crash (cpu hotplug)

[Mike Galbraith]

Mindless testing only, too sick to work, not sick enough to be immune
to boredom.  Was verifying first warning wasn't somehow rt inspired,
but while doing so, plain nopreempt (and no rt patch set) went boom.

[  203.088255] smpboot: CPU 1 is now offline
[  203.168181] smpboot: CPU 2 is now offline
[  203.221461] x86: Booting SMP configuration:
[  203.221464] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  203.221728] [ cut here ]
[  203.221733] WARNING: CPU: 1 PID: 0 at kernel/sched/clock.c:149 
set_sched_clock_stable+0x43/0x50
[  203.221733] Modules linked in: nls_utf8(E) isofs(E) ebtable_filter(E) 
ebtables(E) fuse(E) nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E) br_netfilter(E) 
nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) af_packet(E) bridge(E) 
stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) 
nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) 
iptable_raw(E) xt_CT(E) iptable_filter(E) ip6table_mangle(E) 
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) 
ip6table_filter(E) ip6_tables(E) x_tables(E) nls_iso8859_1(E) 
snd_hda_codec_hdmi(E) nls_cp437(E) intel_rapl(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) coretemp(E) kvm_intel(E) snd_hda_codec_realtek(E) 
snd_hda_codec_generic(E) kvm(E) snd_hda_intel(E)
[  203.221748]  snd_hda_codec(E) irqbypass(E) crct10dif_pclmul(E) 
snd_hda_core(E) snd_hwdep(E) nfsd(E) crc32_pclmul(E) crc32c_intel(E) 
ghash_clmulni_intel(E) pcbc(E) snd_pcm(E) auth_rpcgss(E) aesni_intel(E) 
aes_x86_64(E) snd_timer(E) nfs_acl(E) joydev(E) crypto_simd(E) snd(E) lockd(E) 
grace(E) iTCO_wdt(E) iTCO_vendor_support(E) lpc_ich(E) mei_me(E) i2c_i801(E) 
mei(E) pcspkr(E) glue_helper(E) mfd_core(E) shpchp(E) intel_smartconnect(E) 
sunrpc(E) soundcore(E) tpm_infineon(E) fan(E) thermal(E) battery(E) cryptd(E) 
efivarfs(E) sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_logitech_dj(E) uas(E) 
usb_storage(E) hid_generic(E) usbhid(E) nouveau(E) wmi(E) i2c_algo_bit(E) 
drm_kms_helper(E) ahci(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) 
fb_sys_fops(E) libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E)
[  203.221765]  ttm(E) libata(E) r8169(E) mii(E) drm(E) usbcore(E) fjes(E) 
video(E) button(E) sd_mod(E) vfat(E) fat(E) ext4(E) crc16(E) jbd2(E) mbcache(E) 
dm_mod(E) loop(E) sg(E) scsi_mod(E) autofs4(E)
[  203.221773] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GE   
4.10.0-tip-default #29
[  203.221774] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 
09/23/2013
[  203.221774] Call Trace:
[  203.221778]  dump_stack+0x63/0x90
[  203.221780]  __warn+0xd1/0xf0
[  203.221782]  warn_slowpath_null+0x1d/0x20
[  203.221782]  set_sched_clock_stable+0x43/0x50
[  203.221784]  early_init_intel+0x225/0x360
[  203.221785]  init_intel+0x18/0x2d0
[  203.221786]  identify_cpu+0x2d1/0x4d0
[  203.221786]  identify_secondary_cpu+0x18/0x80
[  203.221789]  smp_store_cpu_info+0x3e/0x40
[  203.221790]  start_secondary+0x53/0x180
[  203.221791]  start_cpu+0x14/0x14
[  203.221792] ---[ end trace 262c7e4b746d5a76 ]---

[  207.525918] smpboot: CPU 2 is now offline
[  207.586516] smpboot: CPU 4 is now offline
[  207.642988] smpboot: CPU 6 is now offline
[  207.682207] x86: Booting SMP configuration:
[  207.682210] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  207.682505] sched_clock: Marking stable (207412639708, 0)->(207410993286, 
1646422)
[  207.706220] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  207.706502] sched_clock: Marking stable (207524564558, 0)->(207522917721, 
1646837)
[  207.730376] smpboot: Booting Node 0 Processor 4 APIC 0x1
[  207.730644] sched_clock: Marking stable (207585448402, 0)->(207583801309, 
1647093)
[  207.754593] smpboot: Booting Node 0 Processor 6 APIC 0x5
[  207.754881] sched_clock: Marking stable (207641939733, 0)->(207640292394, 
1647339)
[  207.802195] smpboot: CPU 3 is now offline
[  207.862396] smpboot: CPU 4 is now offline
[  207.927159] [ cut here ]
[  207.927163] WARNING: CPU: 6 PID: 45 at kernel/sched/sched.h:807 
assert_clock_updated.isra.62.part.63+0x25/0x27
[  207.927164] rq->clock_update_flags < RQCF_ACT_SKIP
[  207.927164] Modules linked in: nls_utf8(E) isofs(E) ebtable_filter(E) 
ebtables(E) fuse(E) nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E) br_netfilter(E) 
nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) af_packet(E) bridge(E) 
stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) 
nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) 
iptable_raw(E) xt_CT(E) iptable_filter(E) ip6table_mangle(E) 
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) 
ip6table_filter(E) ip6_tables(E) x_tables(E) nls_iso8859_1(E) 
snd_hda_codec_hdmi(E) nls_cp437(E) intel_rapl(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) coretemp(E) kvm_intel(E) 

linux-next 20170117 - lockdep whines and BUGs in ata_scsi_rbuf_fill()

[valdis . kletnieks]

linux-next 20170110 didn't exhibit this.

Am seeing at boot a lockdep whine, followed by 3 BUGs. ata_scsi_rbuf_fill() is
in the traceback for all of them.'git log' hints that it's one of 6 commits
against drivers/ata/libata-scsi.c by Christoph, but none of them spring out
as being the guilty party.  This ring any bells, or should I start
cherrypicking reverts and bisecting?

(-dirty due to a local patch to net/ipv6/addrconf.c for a VPN issue)

Lockdep:

[3.359133] =
[3.359162] [ INFO: inconsistent lock state ]
[3.359192] 4.10.0-rc4-next-20170117-dirty #375 Not tainted
[3.359229] -
[3.359258] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[3.359299] kworker/u8:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
[3.359334]  (&(>lock)->rlock){?.}, at: [] 
ata_scsi_queuecmd+0x4f/0x420
[3.359398] {IN-HARDIRQ-W} state was registered at:
[3.359431]
[3.359434] [] __lock_acquire+0x636/0x18b0
[3.359484]
[3.359486] [] lock_acquire+0x119/0x2d0
[3.359533]
[3.359535] [] _raw_spin_lock+0x41/0x80
[3.359582]
[3.359584] [] ahci_single_level_irq_intr+0x44/0x90
[3.359638]
[3.359640] [] __handle_irq_event_percpu+0x127/0x690
[3.359694]
[3.359696] [] handle_irq_event_percpu+0x34/0xb0
[3.359747]
[3.359749] [] handle_irq_event+0x4b/0xc0
[3.359797]
[3.359799] [] handle_edge_irq+0xb5/0x3d0
[3.359847]
[3.359849] [] handle_irq+0xa6/0x2c0
[3.359895]
[3.359897] [] do_IRQ+0x83/0x1b0
[3.359940]
[3.359942] [] ret_from_intr+0x0/0x19
[3.359989]
[3.359992] [] cpuidle_enter_state+0xe4/0x660
[3.360043]
[3.360045] [] cpuidle_enter+0x17/0x20
[3.360092]
[3.360095] [] do_idle+0x2f7/0x3d0
[3.360139]
[3.360142] [] cpu_startup_entry+0x7c/0x90
[3.360190]
[3.360193] [] rest_init+0x15c/0x170
[3.360239]
[3.360242] [] start_kernel+0x747/0x788
[3.360288]
[3.360291] [] x86_64_start_reservations+0x4f/0x70
[3.360344]
[3.360346] [] x86_64_start_kernel+0x344/0x38b
[3.360397]
[3.360400] [] verify_cpu+0x0/0xf1
[3.360445] irq event stamp: 160102
[3.360470] hardirqs last  enabled at (160101): [] 
_raw_spin_unlock_irq+0x2e/0x80
[3.360529] hardirqs last disabled at (160102): [] 
_raw_spin_lock_irqsave+0x1e/0x90
[3.360589] softirqs last  enabled at (159762): [] 
__do_softirq+0x55d/0xa39
[3.360644] softirqs last disabled at (159741): [] 
irq_exit+0x111/0x170
[3.360695]
   other info that might help us debug this:
[3.360737]  Possible unsafe locking scenario:

[3.360775]CPU0
[3.360793]
[3.360810]   lock(&(>lock)->rlock);
[3.360839]   
[3.360857] lock(&(>lock)->rlock);
[3.360887]
*** DEADLOCK ***

[3.360926] 4 locks held by kworker/u8:0/5:
[3.360954]  #0:  ("events_unbound"){.+.+.+}, at: [] 
process_one_work+0x347/0xe10
[3.361015]  #1:  ((>work)){+.+.+.}, at: [] 
process_one_work+0x347/0xe10
[3.361075]  #2:  (>scan_mutex){+.+.+.}, at: [] 
__scsi_add_device+0xac/0x150
[3.361137]  #3:  (&(>lock)->rlock){?.}, at: [] 
ata_scsi_queuecmd+0x4f/0x420
[3.362428] usbcore: registered new interface driver uvcvideo
[3.362429] USB Video Class driver (1.1.1)
[3.367023]
   stack backtrace:
[3.370918] CPU: 1 PID: 5 Comm: kworker/u8:0 Not tainted 
4.10.0-rc4-next-20170117-dirty #375
[3.372913] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A17 
08/19/2015
[3.374918] Workqueue: events_unbound async_run_entry_fn
[3.376925] Call Trace:
[3.378912]  dump_stack+0x7b/0xd1
[3.380888]  print_usage_bug+0x27b/0x330
[3.382850]  mark_lock+0x6ea/0x8a0
[3.384787]  ? print_shortest_lock_dependencies+0x380/0x380
[3.386726]  mark_held_locks+0x93/0x160
[3.388651]  ? add_lock_to_list.isra.17.constprop.33+0xa7/0x160
[3.390591]  ? cache_alloc_refill+0x9dd/0x1360
[3.392533]  trace_hardirqs_on_caller+0x103/0x2c0
[3.394464]  trace_hardirqs_on+0xd/0x10
[3.396390]  cache_alloc_refill+0x9dd/0x1360
[3.398301]  ? ___might_sleep+0x1e2/0x300
[3.400203]  ? __might_sleep+0x66/0x1f0
[3.402091]  kmem_cache_alloc_trace+0xf3/0x4f0
[3.403976]  ? ata_scsiop_inq_00+0x160/0x160
[3.405854]  ata_scsi_rbuf_fill+0x39/0x110
[3.407696]  ata_scsi_simulate+0x2e8/0x4b0
[3.409533]  ata_scsi_queuecmd+0x303/0x420
[3.411350]  scsi_dispatch_cmd+0x188/0x690
[3.413154]  scsi_request_fn+0x709/0xd00
[3.414958]  __blk_run_queue+0x7e/0xb0
[3.416733]  blk_execute_rq_nowait+0x1c5/0x210
[3.418515]  ? blk_execute_rq_nowait+0x210/0x210
[3.420304]  blk_execute_rq+0x14b/0x210
[3.422088]  ? blk_rq_append_bio+0x9d/0x100
[3.423864]  ? blk_rq_map_kern+0x11b/0x200
[3.425584]  ? blk_get_request+0x149/0x290
[3.427285]  __scsi_execute+0x148/0x210
[3.429035]  scsi_execute_req_flags+0x98/0x110
[3.430786]  

linux-next 20170117 - lockdep whines and BUGs in ata_scsi_rbuf_fill()

[valdis . kletnieks]

linux-next 20170110 didn't exhibit this.

Am seeing at boot a lockdep whine, followed by 3 BUGs. ata_scsi_rbuf_fill() is
in the traceback for all of them.'git log' hints that it's one of 6 commits
against drivers/ata/libata-scsi.c by Christoph, but none of them spring out
as being the guilty party.  This ring any bells, or should I start
cherrypicking reverts and bisecting?

(-dirty due to a local patch to net/ipv6/addrconf.c for a VPN issue)

Lockdep:

[3.359133] =
[3.359162] [ INFO: inconsistent lock state ]
[3.359192] 4.10.0-rc4-next-20170117-dirty #375 Not tainted
[3.359229] -
[3.359258] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[3.359299] kworker/u8:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
[3.359334]  (&(>lock)->rlock){?.}, at: [] 
ata_scsi_queuecmd+0x4f/0x420
[3.359398] {IN-HARDIRQ-W} state was registered at:
[3.359431]
[3.359434] [] __lock_acquire+0x636/0x18b0
[3.359484]
[3.359486] [] lock_acquire+0x119/0x2d0
[3.359533]
[3.359535] [] _raw_spin_lock+0x41/0x80
[3.359582]
[3.359584] [] ahci_single_level_irq_intr+0x44/0x90
[3.359638]
[3.359640] [] __handle_irq_event_percpu+0x127/0x690
[3.359694]
[3.359696] [] handle_irq_event_percpu+0x34/0xb0
[3.359747]
[3.359749] [] handle_irq_event+0x4b/0xc0
[3.359797]
[3.359799] [] handle_edge_irq+0xb5/0x3d0
[3.359847]
[3.359849] [] handle_irq+0xa6/0x2c0
[3.359895]
[3.359897] [] do_IRQ+0x83/0x1b0
[3.359940]
[3.359942] [] ret_from_intr+0x0/0x19
[3.359989]
[3.359992] [] cpuidle_enter_state+0xe4/0x660
[3.360043]
[3.360045] [] cpuidle_enter+0x17/0x20
[3.360092]
[3.360095] [] do_idle+0x2f7/0x3d0
[3.360139]
[3.360142] [] cpu_startup_entry+0x7c/0x90
[3.360190]
[3.360193] [] rest_init+0x15c/0x170
[3.360239]
[3.360242] [] start_kernel+0x747/0x788
[3.360288]
[3.360291] [] x86_64_start_reservations+0x4f/0x70
[3.360344]
[3.360346] [] x86_64_start_kernel+0x344/0x38b
[3.360397]
[3.360400] [] verify_cpu+0x0/0xf1
[3.360445] irq event stamp: 160102
[3.360470] hardirqs last  enabled at (160101): [] 
_raw_spin_unlock_irq+0x2e/0x80
[3.360529] hardirqs last disabled at (160102): [] 
_raw_spin_lock_irqsave+0x1e/0x90
[3.360589] softirqs last  enabled at (159762): [] 
__do_softirq+0x55d/0xa39
[3.360644] softirqs last disabled at (159741): [] 
irq_exit+0x111/0x170
[3.360695]
   other info that might help us debug this:
[3.360737]  Possible unsafe locking scenario:

[3.360775]CPU0
[3.360793]
[3.360810]   lock(&(>lock)->rlock);
[3.360839]   
[3.360857] lock(&(>lock)->rlock);
[3.360887]
*** DEADLOCK ***

[3.360926] 4 locks held by kworker/u8:0/5:
[3.360954]  #0:  ("events_unbound"){.+.+.+}, at: [] 
process_one_work+0x347/0xe10
[3.361015]  #1:  ((>work)){+.+.+.}, at: [] 
process_one_work+0x347/0xe10
[3.361075]  #2:  (>scan_mutex){+.+.+.}, at: [] 
__scsi_add_device+0xac/0x150
[3.361137]  #3:  (&(>lock)->rlock){?.}, at: [] 
ata_scsi_queuecmd+0x4f/0x420
[3.362428] usbcore: registered new interface driver uvcvideo
[3.362429] USB Video Class driver (1.1.1)
[3.367023]
   stack backtrace:
[3.370918] CPU: 1 PID: 5 Comm: kworker/u8:0 Not tainted 
4.10.0-rc4-next-20170117-dirty #375
[3.372913] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A17 
08/19/2015
[3.374918] Workqueue: events_unbound async_run_entry_fn
[3.376925] Call Trace:
[3.378912]  dump_stack+0x7b/0xd1
[3.380888]  print_usage_bug+0x27b/0x330
[3.382850]  mark_lock+0x6ea/0x8a0
[3.384787]  ? print_shortest_lock_dependencies+0x380/0x380
[3.386726]  mark_held_locks+0x93/0x160
[3.388651]  ? add_lock_to_list.isra.17.constprop.33+0xa7/0x160
[3.390591]  ? cache_alloc_refill+0x9dd/0x1360
[3.392533]  trace_hardirqs_on_caller+0x103/0x2c0
[3.394464]  trace_hardirqs_on+0xd/0x10
[3.396390]  cache_alloc_refill+0x9dd/0x1360
[3.398301]  ? ___might_sleep+0x1e2/0x300
[3.400203]  ? __might_sleep+0x66/0x1f0
[3.402091]  kmem_cache_alloc_trace+0xf3/0x4f0
[3.403976]  ? ata_scsiop_inq_00+0x160/0x160
[3.405854]  ata_scsi_rbuf_fill+0x39/0x110
[3.407696]  ata_scsi_simulate+0x2e8/0x4b0
[3.409533]  ata_scsi_queuecmd+0x303/0x420
[3.411350]  scsi_dispatch_cmd+0x188/0x690
[3.413154]  scsi_request_fn+0x709/0xd00
[3.414958]  __blk_run_queue+0x7e/0xb0
[3.416733]  blk_execute_rq_nowait+0x1c5/0x210
[3.418515]  ? blk_execute_rq_nowait+0x210/0x210
[3.420304]  blk_execute_rq+0x14b/0x210
[3.422088]  ? blk_rq_append_bio+0x9d/0x100
[3.423864]  ? blk_rq_map_kern+0x11b/0x200
[3.425584]  ? blk_get_request+0x149/0x290
[3.427285]  __scsi_execute+0x148/0x210
[3.429035]  scsi_execute_req_flags+0x98/0x110
[3.430786]  

Re: [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled

[Vlastimil Babka]

On 01/18/2017 10:51 PM, David Rientjes wrote:
> The patch "mm, page_alloc: warn_alloc print nodemask" implicitly sets the 
> allocation nodemask to cpuset_current_mems_allowed when there is no 
> effective mempolicy.  cpuset_current_mems_allowed is only effective when 
> cpusets are enabled, which is also printed by warn_alloc(), so setting 
> the nodemask to cpuset_current_mems_allowed is redundant and prevents 
> debugging issues where ac->nodemask is not set properly in the page 
> allocator.
> 
> This provides better debugging output since 
> cpuset_print_current_mems_allowed() is already provided.
> 
> Signed-off-by: David Rientjes 

Yes, with my current cpuset vs mempolicy debugging experience, this is
more useful (except how both nodemask and mems_allowed can change under
us, so what we print here is not necessarily the same that what
get_page_from_freelist() has seen, but that's another thing...).

But I would suggest you change the oom killer's dump_header() the same
way than warn_alloc().

Thanks,
Vlastimil

> ---
>  mm/page_alloc.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3037,7 +3037,6 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, 
> const char *fmt, ...)
>   va_list args;
>   static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);
> - nodemask_t *nm = (nodemask) ? nodemask : _current_mems_allowed;
>  
>   if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs) ||
>   debug_guardpage_minorder() > 0)
> @@ -3051,11 +3050,16 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, 
> const char *fmt, ...)
>   pr_cont("%pV", );
>   va_end(args);
>  
> - pr_cont(", mode:%#x(%pGg), nodemask=%*pbl\n", gfp_mask, _mask, 
> nodemask_pr_args(nm));
> + pr_cont(", mode:%#x(%pGg), nodemask=", gfp_mask, _mask);
> + if (nodemask)
> + pr_cont("%*pbl\n", nodemask_pr_args(nodemask));
> + else
> + pr_cont("(null)\n");
> +
>   cpuset_print_current_mems_allowed();
>  
>   dump_stack();
> - warn_alloc_show_mem(gfp_mask, nm);
> + warn_alloc_show_mem(gfp_mask, nodemask);
>  }
>  
>  static inline struct page *
> 

Re: [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled

[Vlastimil Babka]

On 01/18/2017 10:51 PM, David Rientjes wrote:
> The patch "mm, page_alloc: warn_alloc print nodemask" implicitly sets the 
> allocation nodemask to cpuset_current_mems_allowed when there is no 
> effective mempolicy.  cpuset_current_mems_allowed is only effective when 
> cpusets are enabled, which is also printed by warn_alloc(), so setting 
> the nodemask to cpuset_current_mems_allowed is redundant and prevents 
> debugging issues where ac->nodemask is not set properly in the page 
> allocator.
> 
> This provides better debugging output since 
> cpuset_print_current_mems_allowed() is already provided.
> 
> Signed-off-by: David Rientjes 

Yes, with my current cpuset vs mempolicy debugging experience, this is
more useful (except how both nodemask and mems_allowed can change under
us, so what we print here is not necessarily the same that what
get_page_from_freelist() has seen, but that's another thing...).

But I would suggest you change the oom killer's dump_header() the same
way than warn_alloc().

Thanks,
Vlastimil

> ---
>  mm/page_alloc.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3037,7 +3037,6 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, 
> const char *fmt, ...)
>   va_list args;
>   static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);
> - nodemask_t *nm = (nodemask) ? nodemask : _current_mems_allowed;
>  
>   if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs) ||
>   debug_guardpage_minorder() > 0)
> @@ -3051,11 +3050,16 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, 
> const char *fmt, ...)
>   pr_cont("%pV", );
>   va_end(args);
>  
> - pr_cont(", mode:%#x(%pGg), nodemask=%*pbl\n", gfp_mask, _mask, 
> nodemask_pr_args(nm));
> + pr_cont(", mode:%#x(%pGg), nodemask=", gfp_mask, _mask);
> + if (nodemask)
> + pr_cont("%*pbl\n", nodemask_pr_args(nodemask));
> + else
> + pr_cont("(null)\n");
> +
>   cpuset_print_current_mems_allowed();
>  
>   dump_stack();
> - warn_alloc_show_mem(gfp_mask, nm);
> + warn_alloc_show_mem(gfp_mask, nodemask);
>  }
>  
>  static inline struct page *
> 

Re: [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2

[Krzysztof Kozlowski]

On Thu, Jan 19, 2017 at 12:47 AM, Dmitry Torokhov
 wrote:
> On Tue, Jan 17, 2017 at 08:10:56PM +0200, Krzysztof Kozlowski wrote:
>> On Tue, Jan 17, 2017 at 10:06:27AM -0800, Dmitry Torokhov wrote:
>> > On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski  
>> > wrote:
>> > > On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
>> > >> This patch adds support for the TM2 touch key and led
>> > >> functionality.
>> > >>
>> > >> The driver interfaces with userspace through an input device and
>> > >> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
>> > >> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>> > >>
>> > >> Signed-off-by: Beomho Seo 
>> > >> Signed-off-by: Jaechul Lee 
>> > >> Reviewed-by: Javier Martinez Canillas 
>> > >> Reviewed-by: Andi Shyti 
>> > >> Reviewed-by: Chanwoo Choi 
>> > >> Tested-by: Chanwoo Choi 
>> > >> Acked-by: Krzysztof Kozlowski 
>> > >> Signed-off-by: Dmitry Torokhov 
>> > >
>> > > This looks unusual. How did Dmitry's Sob end here?
>> >
>> > I sent Jaechul a version of the patch to try out.
>>
>> Ah, makes sense then.
>
> I picked up (and folded) the binding doc and driver patches, DTS should
> go through some other tree I believe.

Yes, I will take it. I waited for driver and bindings to be accepted.

Thanks,
Krzysztof

Re: [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2

[Krzysztof Kozlowski]

On Thu, Jan 19, 2017 at 12:47 AM, Dmitry Torokhov
 wrote:
> On Tue, Jan 17, 2017 at 08:10:56PM +0200, Krzysztof Kozlowski wrote:
>> On Tue, Jan 17, 2017 at 10:06:27AM -0800, Dmitry Torokhov wrote:
>> > On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski  
>> > wrote:
>> > > On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
>> > >> This patch adds support for the TM2 touch key and led
>> > >> functionality.
>> > >>
>> > >> The driver interfaces with userspace through an input device and
>> > >> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
>> > >> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>> > >>
>> > >> Signed-off-by: Beomho Seo 
>> > >> Signed-off-by: Jaechul Lee 
>> > >> Reviewed-by: Javier Martinez Canillas 
>> > >> Reviewed-by: Andi Shyti 
>> > >> Reviewed-by: Chanwoo Choi 
>> > >> Tested-by: Chanwoo Choi 
>> > >> Acked-by: Krzysztof Kozlowski 
>> > >> Signed-off-by: Dmitry Torokhov 
>> > >
>> > > This looks unusual. How did Dmitry's Sob end here?
>> >
>> > I sent Jaechul a version of the patch to try out.
>>
>> Ah, makes sense then.
>
> I picked up (and folded) the binding doc and driver patches, DTS should
> go through some other tree I believe.

Yes, I will take it. I waited for driver and bindings to be accepted.

Thanks,
Krzysztof

[PATCH 4/6] media: ti-vpe: cal: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/media/platform/ti-vpe/cal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 7a058b6..ebf11b4 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1701,7 +1701,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, 
int inst)
asd->match_type = V4L2_ASYNC_MATCH_OF;
asd->match.of.node = sensor_node;
 
-   remote_ep = of_parse_phandle(ep_node, "remote-endpoint", 0);
+   remote_ep = of_graph_get_remote_endpoint(ep_node);
if (!remote_ep) {
ctx_dbg(3, ctx, "can't get remote-endpoint\n");
goto cleanup_exit;
-- 
1.9.1

[PATCH 4/6] media: ti-vpe: cal: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/media/platform/ti-vpe/cal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 7a058b6..ebf11b4 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1701,7 +1701,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, 
int inst)
asd->match_type = V4L2_ASYNC_MATCH_OF;
asd->match.of.node = sensor_node;
 
-   remote_ep = of_parse_phandle(ep_node, "remote-endpoint", 0);
+   remote_ep = of_graph_get_remote_endpoint(ep_node);
if (!remote_ep) {
ctx_dbg(3, ctx, "can't get remote-endpoint\n");
goto cleanup_exit;
-- 
1.9.1

[PATCH 2/6] drm/omapdrm: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e96..f49f2ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "omapdss.h"
@@ -127,7 +128,7 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
 {
struct device_node *np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
 
-- 
1.9.1

[PATCH 2/6] drm/omapdrm: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e96..f49f2ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "omapdss.h"
@@ -127,7 +128,7 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
 {
struct device_node *np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
 
-- 
1.9.1

Re: [PATCH] kprobes: move kprobe declarations to asm-generic/kprobes.h

[Masami Hiramatsu]

On Thu, 19 Jan 2017 10:38:12 +0900
Masami Hiramatsu  wrote:

> Hi Luis,
> 
> On Wed, 18 Jan 2017 09:48:40 -0800
> "Luis R. Rodriguez"  wrote:
> 
> > Often all is needed is these small helpers, instead of compiler.h
> > or a full kprobes.h. This is important for asm helpers, in fact even
> > some asm/kprobes.h make use of these helpers... instead just keep a
> > generic asm file with helpers useful for asm code with the least amount
> > of clutter as possible.
> > 
> > Likewise we need now to also address what to do about this file for both
> > when architectures have CONFIG_HAVE_KPROBES, and when they do not. Then
> > for when architectures have CONFIG_HAVE_KPROBES but have disabled
> > CONFIG_KPROBES.
> > 
> > Right now most asm/kprobes.h do not have guards against CONFIG_KPROBES,
> > this means most architecture code cannot include asm/kprobes.h safely.
> 
> Just from curiosity, would you have any actual issue (like compile error)
> about that?
> 
> > Correct this and add guards for architectures missing them. Additionally
> > provide architectures that not have kprobes support with the default
> > asm-generic solution. This lets us force asm/kprobes.h on the header
> > include/linux/kprobes.h always, but most importantly we can now safely
> > include just asm/kprobes.h on architecture code without bringing
> > the full kitchen sink of header files.
> 
> It is fine to me to separate it into asm-generic/kprobes.h.
> 
> > Two architectures already provided a guard against CONFIG_KPROBES on
> > its kprobes.h: sh, arch. The rest of the architectures needed gaurds
> > added. We avoid including any not-needed headers on asm/kprobes.h
> > unless kprobes have been enabled.
> > 
> > In a subsequent atomic change we can try now to remove compiler.h from
> > include/linux/kprobes.h.
> 
> Nice :)
> 
> > 
> > During this sweep I've also identified a few architectures defining
> > a common macro needed for both kprobes and ftrace, that of the
> > definition of the breakput instruction up. Some refer to this as
> > BREAKPOINT_INSTRUCTION. This must be kept outside of the #ifdef
> > CONFIG_KPROBES guard.
> 
> Hmm, since it depends on ftrace arch-depend implementation, I would
> like to ask you to split this part into other patches for each arch,
> with a build failure log.

Ah, I understand. This becomes new issue when you make the #ifdef 
guards on asm/kprobes.h. 

OK, then it is OK to me.

Acked-by: Masami Hiramatsu 

Thank you,


> 
> Thank you,
> 
> > 
> > v5:
> > 
> > o fix BREAKPOINT_INSTRUCTION dependency with kernel architecture
> >   ftrace implementations:  Although its correct to #ifdef CONFIG_KPROBES
> >   on the architecture arch/$(ARCH)/include/asm/kprobes.h when
> >   architectures support ftrace they will rely on the
> >   BREAKPOINT_INSTRUCTION definition, this needs to be kept out from
> >   CONFIG_KPROBES as ftrace can be enabled without kprobes. This
> >   fixes compilation on x86 where kprobes is disabled but ftrace is
> >   left enabled.
> > 
> > o include  on arch/arm64/kernel/probes/decode-insn.h
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> > 
> > This was part of the linker table series [0], but I'm going to split up
> > patches further there. This is an atomic change which is independent
> > so sending this separately now.
> > 
> > [0] https://lkml.kernel.org/r/20170115211057.17167-1-mcg...@kernel.org
> > 
> >  MAINTAINERS|  1 +
> >  arch/alpha/include/asm/Kbuild  |  1 +
> >  arch/arc/include/asm/kprobes.h |  6 --
> >  arch/arm/include/asm/kprobes.h |  4 
> >  arch/arm/probes/decode.h   |  1 +
> >  arch/arm64/include/asm/kprobes.h   |  4 
> >  arch/arm64/kernel/insn.c   |  1 +
> >  arch/arm64/kernel/probes/decode-insn.h |  2 ++
> >  arch/avr32/include/asm/kprobes.h   |  7 ++-
> >  arch/blackfin/include/asm/Kbuild   |  1 +
> >  arch/c6x/include/asm/Kbuild|  1 +
> >  arch/cris/include/asm/Kbuild   |  1 +
> >  arch/frv/include/asm/Kbuild|  1 +
> >  arch/h8300/include/asm/Kbuild  |  1 +
> >  arch/hexagon/include/asm/Kbuild|  1 +
> >  arch/ia64/include/asm/kprobes.h| 12 +---
> >  arch/m32r/include/asm/Kbuild   |  1 +
> >  arch/m68k/include/asm/Kbuild   |  1 +
> >  arch/metag/include/asm/Kbuild  |  1 +
> >  arch/microblaze/include/asm/Kbuild |  1 +
> >  arch/mips/include/asm/kprobes.h|  6 +-
> >  arch/mn10300/include/asm/kprobes.h |  7 ++-
> >  arch/nios2/include/asm/Kbuild  |  1 +
> >  arch/openrisc/include/asm/Kbuild   |  1 +
> >  arch/parisc/include/asm/Kbuild |  1 +
> >  arch/powerpc/include/asm/kprobes.h |  3 +++
> >  arch/s390/include/asm/kprobes.h|  7 ++-
> >  arch/score/include/asm/Kbuild  |  1 +
> >  arch/sh/include/asm/kprobes.h  |  5 -

Re: [PATCH] kprobes: move kprobe declarations to asm-generic/kprobes.h

[Masami Hiramatsu]

On Thu, 19 Jan 2017 10:38:12 +0900
Masami Hiramatsu  wrote:

> Hi Luis,
> 
> On Wed, 18 Jan 2017 09:48:40 -0800
> "Luis R. Rodriguez"  wrote:
> 
> > Often all is needed is these small helpers, instead of compiler.h
> > or a full kprobes.h. This is important for asm helpers, in fact even
> > some asm/kprobes.h make use of these helpers... instead just keep a
> > generic asm file with helpers useful for asm code with the least amount
> > of clutter as possible.
> > 
> > Likewise we need now to also address what to do about this file for both
> > when architectures have CONFIG_HAVE_KPROBES, and when they do not. Then
> > for when architectures have CONFIG_HAVE_KPROBES but have disabled
> > CONFIG_KPROBES.
> > 
> > Right now most asm/kprobes.h do not have guards against CONFIG_KPROBES,
> > this means most architecture code cannot include asm/kprobes.h safely.
> 
> Just from curiosity, would you have any actual issue (like compile error)
> about that?
> 
> > Correct this and add guards for architectures missing them. Additionally
> > provide architectures that not have kprobes support with the default
> > asm-generic solution. This lets us force asm/kprobes.h on the header
> > include/linux/kprobes.h always, but most importantly we can now safely
> > include just asm/kprobes.h on architecture code without bringing
> > the full kitchen sink of header files.
> 
> It is fine to me to separate it into asm-generic/kprobes.h.
> 
> > Two architectures already provided a guard against CONFIG_KPROBES on
> > its kprobes.h: sh, arch. The rest of the architectures needed gaurds
> > added. We avoid including any not-needed headers on asm/kprobes.h
> > unless kprobes have been enabled.
> > 
> > In a subsequent atomic change we can try now to remove compiler.h from
> > include/linux/kprobes.h.
> 
> Nice :)
> 
> > 
> > During this sweep I've also identified a few architectures defining
> > a common macro needed for both kprobes and ftrace, that of the
> > definition of the breakput instruction up. Some refer to this as
> > BREAKPOINT_INSTRUCTION. This must be kept outside of the #ifdef
> > CONFIG_KPROBES guard.
> 
> Hmm, since it depends on ftrace arch-depend implementation, I would
> like to ask you to split this part into other patches for each arch,
> with a build failure log.

Ah, I understand. This becomes new issue when you make the #ifdef 
guards on asm/kprobes.h. 

OK, then it is OK to me.

Acked-by: Masami Hiramatsu 

Thank you,


> 
> Thank you,
> 
> > 
> > v5:
> > 
> > o fix BREAKPOINT_INSTRUCTION dependency with kernel architecture
> >   ftrace implementations:  Although its correct to #ifdef CONFIG_KPROBES
> >   on the architecture arch/$(ARCH)/include/asm/kprobes.h when
> >   architectures support ftrace they will rely on the
> >   BREAKPOINT_INSTRUCTION definition, this needs to be kept out from
> >   CONFIG_KPROBES as ftrace can be enabled without kprobes. This
> >   fixes compilation on x86 where kprobes is disabled but ftrace is
> >   left enabled.
> > 
> > o include  on arch/arm64/kernel/probes/decode-insn.h
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> > 
> > This was part of the linker table series [0], but I'm going to split up
> > patches further there. This is an atomic change which is independent
> > so sending this separately now.
> > 
> > [0] https://lkml.kernel.org/r/20170115211057.17167-1-mcg...@kernel.org
> > 
> >  MAINTAINERS|  1 +
> >  arch/alpha/include/asm/Kbuild  |  1 +
> >  arch/arc/include/asm/kprobes.h |  6 --
> >  arch/arm/include/asm/kprobes.h |  4 
> >  arch/arm/probes/decode.h   |  1 +
> >  arch/arm64/include/asm/kprobes.h   |  4 
> >  arch/arm64/kernel/insn.c   |  1 +
> >  arch/arm64/kernel/probes/decode-insn.h |  2 ++
> >  arch/avr32/include/asm/kprobes.h   |  7 ++-
> >  arch/blackfin/include/asm/Kbuild   |  1 +
> >  arch/c6x/include/asm/Kbuild|  1 +
> >  arch/cris/include/asm/Kbuild   |  1 +
> >  arch/frv/include/asm/Kbuild|  1 +
> >  arch/h8300/include/asm/Kbuild  |  1 +
> >  arch/hexagon/include/asm/Kbuild|  1 +
> >  arch/ia64/include/asm/kprobes.h| 12 +---
> >  arch/m32r/include/asm/Kbuild   |  1 +
> >  arch/m68k/include/asm/Kbuild   |  1 +
> >  arch/metag/include/asm/Kbuild  |  1 +
> >  arch/microblaze/include/asm/Kbuild |  1 +
> >  arch/mips/include/asm/kprobes.h|  6 +-
> >  arch/mn10300/include/asm/kprobes.h |  7 ++-
> >  arch/nios2/include/asm/Kbuild  |  1 +
> >  arch/openrisc/include/asm/Kbuild   |  1 +
> >  arch/parisc/include/asm/Kbuild |  1 +
> >  arch/powerpc/include/asm/kprobes.h |  3 +++
> >  arch/s390/include/asm/kprobes.h|  7 ++-
> >  arch/score/include/asm/Kbuild  |  1 +
> >  arch/sh/include/asm/kprobes.h  |  5 -
> >  arch/sparc/include/asm/kprobes.h   | 10 --
> >  

[PATCH 5/6] v4l: of: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/media/v4l2-core/v4l2-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index 93b3368..b2ed4b3 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -284,7 +285,7 @@ int v4l2_of_parse_link(const struct device_node *node,
np = of_get_next_parent(np);
link->local_node = np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np) {
of_node_put(link->local_node);
return -ENOLINK;
-- 
1.9.1

[PATCH 5/6] v4l: of: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/media/v4l2-core/v4l2-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index 93b3368..b2ed4b3 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -284,7 +285,7 @@ int v4l2_of_parse_link(const struct device_node *node,
np = of_get_next_parent(np);
link->local_node = np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np) {
of_node_put(link->local_node);
return -ENOLINK;
-- 
1.9.1

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

[Stephane Eranian]

On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner  wrote:
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
>> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints
>> > > zeros or arbitrary numbers.
>> > >
>> > > Fix: Patches fix this by just throwing an error if the mode is not
>> > > supported.
>> > > The modes supported is task monitoring and cgroup monitoring.
>> > > Also the per package
>> > > data for say socket x is returned with the -C  -G cgrpy
>> > > option.
>> > > The systemwide data can be looked up by monitoring root cgroup.
>> >
>> > Fine. That just lacks any comment in the implementation. Otherwise I would
>> > not have asked the question about cpu monitoring. Though I fundamentaly
>> > hate the idea of requiring cgroups for this to work.
>> >
>> > If I just want to look at CPU X why on earth do I have to set up all that
>> > cgroup muck? Just because your main focus is cgroups?
>>
>> The upstream per cpu data is broken because its not overriding the other task
>> event RMIDs on that cpu with the cpu event RMID.
>>
>> Can be fixed by adding a percpu struct to hold the RMID thats affinitized
>> to the cpu, however then we miss all the task llc_occupancy in that - still
>> evaluating it.
>
> The point here is that CQM is closely connected to the cache allocation
> technology. After a lengthy discussion we ended up having
>
>   - per cpu CLOSID
>   - per task CLOSID
>
> where all tasks which do not have a CLOSID assigned use the CLOSID which is
> assigned to the CPU they are running on.
>
> So if I configure a system by simply partitioning the cache per cpu, which
> is the proper way to do it for HPC and RT usecases where workloads are
> partitioned on CPUs as well, then I really want to have an equaly simple
> way to monitor the occupancy for that reservation.
>
Your use case is specific to HPC and not Web workloads we run.
Jobs run in cgroups which may span all the CPUs of the machine.
CAT may be used to partition the cache. Cgroups would run inside a partition.
There may be multiple cgroups running in the same partition. I can
understand the value
of tracking occupancy per CLOSID, however that granularity is not
enough for our use case.
Inside a partition, we want to know the occupancy of each cgroup to be
able to assign blame
to the top consumer. Thus, there needs to be a way to monitor
occupancy per cgroup. I'd like to
understand how your proposal would cover this use case.

Another important aspect is that CQM measures new allocations, thus to
get total occupancy you need
to be able to monitor the thread, CPU, CLOSid or cgroup from the
beginning of execution. In the case
of a cgroup from the moment where the first thread is scheduled into
the cgroup. To do this a RMID
needs to be assigned from the beginning to the entity to be monitored.
It could be by creating a CQM event
just to cause an RMID to be assigned as discussed earlier on this
thread. And then if a perf stat is launched
later it will get the same RMID and report full occupancy. But that
requires the first event to remain alive, i.e.,
some process must keep the file descriptor open, i.e., need some
daemon or a perf stat running in the background.

There are also use cases where you want CQM without necessarily
enabling CAT, for instance, if you want
to know the cache footprint of a workload to estimate how if it could
be co-located with others.

I think any viable proposal needs to be able to support your use case
as well as the ones I described above.

> And looking at that from the CAT point of view, which is the proper way to
> do it, makes it obvious that CQM should be modeled to match CAT.
>
> So lets assume the following:
>
>CPU 0-3 default CLOSID 0
>CPU 4   CLOSID 1
>CPU 5   CLOSID 2
>CPU 6   CLOSID 3
>CPU 7   CLOSID 3
>
>T1  CLOSID 4
>T2  CLOSID 5
>T3  CLOSID 6
>T4  CLOSID 6
>
>All other tasks use the per cpu defaults, i.e. the CLOSID of the CPU
>they run on.
>
> then the obvious basic monitoring requirement is to have a RMID for each
> CLOSID.
>
> So when I monitor CPU4, i.e. CLOSID 1 and T1 runs on CPU4, then I do not
> care at all about the occupancy of T1 simply because that is running on a
> seperate reservation. Trying to make that an aggregated value in the first
> place is completely wrong. If you want an aggregate, which is pretty much
> useless, then user space tools can generate it easily.
>
> The whole approach you and David have taken is to whack some desired cgroup
> functionality and whatever into CQM without rethinking the overall
> design. And that's fundamentaly broken because it does not take cache (and
> memory bandwidth) allocation into account.
>
> I seriously doubt, that the existing CQM/MBM code can be 

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

[Stephane Eranian]

On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner  wrote:
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
>> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints
>> > > zeros or arbitrary numbers.
>> > >
>> > > Fix: Patches fix this by just throwing an error if the mode is not
>> > > supported.
>> > > The modes supported is task monitoring and cgroup monitoring.
>> > > Also the per package
>> > > data for say socket x is returned with the -C  -G cgrpy
>> > > option.
>> > > The systemwide data can be looked up by monitoring root cgroup.
>> >
>> > Fine. That just lacks any comment in the implementation. Otherwise I would
>> > not have asked the question about cpu monitoring. Though I fundamentaly
>> > hate the idea of requiring cgroups for this to work.
>> >
>> > If I just want to look at CPU X why on earth do I have to set up all that
>> > cgroup muck? Just because your main focus is cgroups?
>>
>> The upstream per cpu data is broken because its not overriding the other task
>> event RMIDs on that cpu with the cpu event RMID.
>>
>> Can be fixed by adding a percpu struct to hold the RMID thats affinitized
>> to the cpu, however then we miss all the task llc_occupancy in that - still
>> evaluating it.
>
> The point here is that CQM is closely connected to the cache allocation
> technology. After a lengthy discussion we ended up having
>
>   - per cpu CLOSID
>   - per task CLOSID
>
> where all tasks which do not have a CLOSID assigned use the CLOSID which is
> assigned to the CPU they are running on.
>
> So if I configure a system by simply partitioning the cache per cpu, which
> is the proper way to do it for HPC and RT usecases where workloads are
> partitioned on CPUs as well, then I really want to have an equaly simple
> way to monitor the occupancy for that reservation.
>
Your use case is specific to HPC and not Web workloads we run.
Jobs run in cgroups which may span all the CPUs of the machine.
CAT may be used to partition the cache. Cgroups would run inside a partition.
There may be multiple cgroups running in the same partition. I can
understand the value
of tracking occupancy per CLOSID, however that granularity is not
enough for our use case.
Inside a partition, we want to know the occupancy of each cgroup to be
able to assign blame
to the top consumer. Thus, there needs to be a way to monitor
occupancy per cgroup. I'd like to
understand how your proposal would cover this use case.

Another important aspect is that CQM measures new allocations, thus to
get total occupancy you need
to be able to monitor the thread, CPU, CLOSid or cgroup from the
beginning of execution. In the case
of a cgroup from the moment where the first thread is scheduled into
the cgroup. To do this a RMID
needs to be assigned from the beginning to the entity to be monitored.
It could be by creating a CQM event
just to cause an RMID to be assigned as discussed earlier on this
thread. And then if a perf stat is launched
later it will get the same RMID and report full occupancy. But that
requires the first event to remain alive, i.e.,
some process must keep the file descriptor open, i.e., need some
daemon or a perf stat running in the background.

There are also use cases where you want CQM without necessarily
enabling CAT, for instance, if you want
to know the cache footprint of a workload to estimate how if it could
be co-located with others.

I think any viable proposal needs to be able to support your use case
as well as the ones I described above.

> And looking at that from the CAT point of view, which is the proper way to
> do it, makes it obvious that CQM should be modeled to match CAT.
>
> So lets assume the following:
>
>CPU 0-3 default CLOSID 0
>CPU 4   CLOSID 1
>CPU 5   CLOSID 2
>CPU 6   CLOSID 3
>CPU 7   CLOSID 3
>
>T1  CLOSID 4
>T2  CLOSID 5
>T3  CLOSID 6
>T4  CLOSID 6
>
>All other tasks use the per cpu defaults, i.e. the CLOSID of the CPU
>they run on.
>
> then the obvious basic monitoring requirement is to have a RMID for each
> CLOSID.
>
> So when I monitor CPU4, i.e. CLOSID 1 and T1 runs on CPU4, then I do not
> care at all about the occupancy of T1 simply because that is running on a
> seperate reservation. Trying to make that an aggregated value in the first
> place is completely wrong. If you want an aggregate, which is pretty much
> useless, then user space tools can generate it easily.
>
> The whole approach you and David have taken is to whack some desired cgroup
> functionality and whatever into CQM without rethinking the overall
> design. And that's fundamentaly broken because it does not take cache (and
> memory bandwidth) allocation into account.
>
> I seriously doubt, that the existing CQM/MBM code can be refactored in any
> 

Re: [PATCH v6 03/25] usb: ulpi: Support device discovery via DT

[Peter Chen]

On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> product ID registers. This makes it impossible to make a ULPI
> driver match against the ID registers. Add support to discover
> the ULPI phys via DT help alleviate this problem. In the DT case,
> we'll look for a ULPI bus node underneath the device registering
> the ULPI viewport (or the parent of that device to support
> chipidea's device layout) and then match up the phy node
> underneath that with the ULPI device that's created.
> 
> The side benefit of this is that we can use standard properties
> in the phy node like clks, regulators, gpios, etc. because we
> don't have firmware like ACPI to turn these things on for us. And
> we can use the DT phy binding to point our phy consumer to the
> phy provider.
> 
> The ULPI bus code supports native enumeration by reading the
> vendor ID and product ID registers at device creation time, but
> we can't be certain that those register reads will succeed if the
> phy is not powered up. To avoid any problems with reading the ID
> registers before the phy is powered we fallback to DT matching
> when the ID reads fail.
> 
> If the ULPI spec had some generic power sequencing for these
> registers we could put that into the ULPI bus layer and power up
> the device before reading the ID registers. Unfortunately this
> doesn't exist and the power sequence is usually device specific.
> By having the device matched up with DT we can avoid this
> problem.
> 
> Cc: Greg Kroah-Hartman 
> Acked-by: Heikki Krogerus 
> Cc: 
> Acked-by: Rob Herring 
> Signed-off-by: Stephen Boyd 

Greg, is it ok I pick up this patch, and send it with chipidea
changes together for 4.11-rc1 later?

Peter

> ---
>  Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++
>  drivers/usb/common/ulpi.c  | 79 
> --
>  2 files changed, 93 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt 
> b/Documentation/devicetree/bindings/usb/ulpi.txt
> new file mode 100644
> index ..ca179dc4bd50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> @@ -0,0 +1,20 @@
> +ULPI bus binding
> +
> +
> +Phys that are behind a ULPI connection can be described with the following
> +binding. The host controller shall have a "ulpi" named node as a child, and
> +that node shall have one enabled node underneath it representing the ulpi
> +device on the bus.
> +
> +EXAMPLE
> +---
> +
> +usb {
> + compatible = "vendor,usb-controller";
> +
> + ulpi {
> + phy {
> + compatible = "vendor,phy";
> + };
> + };
> +};
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 8b317702d761..c9480d77810c 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -16,6 +16,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  /* 
> -- */
>  
> @@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct 
> device_driver *driver)
>   struct ulpi *ulpi = to_ulpi_dev(dev);
>   const struct ulpi_device_id *id;
>  
> + /* Some ULPI devices don't have a vendor id so rely on OF match */
> + if (ulpi->id.vendor == 0)
> + return of_driver_match_device(dev, driver);
> +
>   for (id = drv->id_table; id->vendor; id++)
>   if (id->vendor == ulpi->id.vendor &&
>   id->product == ulpi->id.product)
> @@ -50,6 +57,11 @@ static int ulpi_match(struct device *dev, struct 
> device_driver *driver)
>  static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
>  {
>   struct ulpi *ulpi = to_ulpi_dev(dev);
> + int ret;
> +
> + ret = of_device_uevent_modalias(dev, env);
> + if (ret != -ENODEV)
> + return ret;
>  
>   if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
>  ulpi->id.vendor, ulpi->id.product))
> @@ -60,6 +72,11 @@ static int ulpi_uevent(struct device *dev, struct 
> kobj_uevent_env *env)
>  static int ulpi_probe(struct device *dev)
>  {
>   struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
> + int ret;
> +
> + ret = of_clk_set_defaults(dev->of_node, false);
> + if (ret < 0)
> + return ret;
>  
>   return drv->probe(to_ulpi_dev(dev));
>  }
> @@ -87,8 +104,13 @@ static struct bus_type ulpi_bus = {
>  static ssize_t modalias_show(struct device *dev, struct device_attribute 
> *attr,
>char *buf)
>  {
> + int len;
>   struct ulpi *ulpi = to_ulpi_dev(dev);
>  
> + len = 

Re: [PATCH v6 03/25] usb: ulpi: Support device discovery via DT

[Peter Chen]

On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> product ID registers. This makes it impossible to make a ULPI
> driver match against the ID registers. Add support to discover
> the ULPI phys via DT help alleviate this problem. In the DT case,
> we'll look for a ULPI bus node underneath the device registering
> the ULPI viewport (or the parent of that device to support
> chipidea's device layout) and then match up the phy node
> underneath that with the ULPI device that's created.
> 
> The side benefit of this is that we can use standard properties
> in the phy node like clks, regulators, gpios, etc. because we
> don't have firmware like ACPI to turn these things on for us. And
> we can use the DT phy binding to point our phy consumer to the
> phy provider.
> 
> The ULPI bus code supports native enumeration by reading the
> vendor ID and product ID registers at device creation time, but
> we can't be certain that those register reads will succeed if the
> phy is not powered up. To avoid any problems with reading the ID
> registers before the phy is powered we fallback to DT matching
> when the ID reads fail.
> 
> If the ULPI spec had some generic power sequencing for these
> registers we could put that into the ULPI bus layer and power up
> the device before reading the ID registers. Unfortunately this
> doesn't exist and the power sequence is usually device specific.
> By having the device matched up with DT we can avoid this
> problem.
> 
> Cc: Greg Kroah-Hartman 
> Acked-by: Heikki Krogerus 
> Cc: 
> Acked-by: Rob Herring 
> Signed-off-by: Stephen Boyd 

Greg, is it ok I pick up this patch, and send it with chipidea
changes together for 4.11-rc1 later?

Peter

> ---
>  Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++
>  drivers/usb/common/ulpi.c  | 79 
> --
>  2 files changed, 93 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt 
> b/Documentation/devicetree/bindings/usb/ulpi.txt
> new file mode 100644
> index ..ca179dc4bd50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> @@ -0,0 +1,20 @@
> +ULPI bus binding
> +
> +
> +Phys that are behind a ULPI connection can be described with the following
> +binding. The host controller shall have a "ulpi" named node as a child, and
> +that node shall have one enabled node underneath it representing the ulpi
> +device on the bus.
> +
> +EXAMPLE
> +---
> +
> +usb {
> + compatible = "vendor,usb-controller";
> +
> + ulpi {
> + phy {
> + compatible = "vendor,phy";
> + };
> + };
> +};
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 8b317702d761..c9480d77810c 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -16,6 +16,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  /* 
> -- */
>  
> @@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct 
> device_driver *driver)
>   struct ulpi *ulpi = to_ulpi_dev(dev);
>   const struct ulpi_device_id *id;
>  
> + /* Some ULPI devices don't have a vendor id so rely on OF match */
> + if (ulpi->id.vendor == 0)
> + return of_driver_match_device(dev, driver);
> +
>   for (id = drv->id_table; id->vendor; id++)
>   if (id->vendor == ulpi->id.vendor &&
>   id->product == ulpi->id.product)
> @@ -50,6 +57,11 @@ static int ulpi_match(struct device *dev, struct 
> device_driver *driver)
>  static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
>  {
>   struct ulpi *ulpi = to_ulpi_dev(dev);
> + int ret;
> +
> + ret = of_device_uevent_modalias(dev, env);
> + if (ret != -ENODEV)
> + return ret;
>  
>   if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
>  ulpi->id.vendor, ulpi->id.product))
> @@ -60,6 +72,11 @@ static int ulpi_uevent(struct device *dev, struct 
> kobj_uevent_env *env)
>  static int ulpi_probe(struct device *dev)
>  {
>   struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
> + int ret;
> +
> + ret = of_clk_set_defaults(dev->of_node, false);
> + if (ret < 0)
> + return ret;
>  
>   return drv->probe(to_ulpi_dev(dev));
>  }
> @@ -87,8 +104,13 @@ static struct bus_type ulpi_bus = {
>  static ssize_t modalias_show(struct device *dev, struct device_attribute 
> *attr,
>char *buf)
>  {
> + int len;
>   struct ulpi *ulpi = to_ulpi_dev(dev);
>  
> + len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
> + if (len != -ENODEV)
> + return len;
> +
>   return sprintf(buf, 

Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver

[Linus Walleij]

On Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil  wrote:

> One problem still unresolved: the pinctrl framework does not allow us to
> configure each pin on demand (someone please prove me wrong), when the
> various PWM channels are requested or released. For instance, the PWM
> channels can be configured from sysfs, which would require all PWM pins
> to be configured properly beforehand for the PWM function, eventually
> causing conflicts with other platform or board drivers.

Why do you think this?

- Pincontrol handles can be obtained at runtime.
- Pincontrol states can be changed at runtime.

The fact that a the handle is retrived by the device core and set to
the states named "init" or "default" during boot is just a convenience.

You can have as many and as fine-grained states as you want. They
can pertain to just one pin too.

Linus Walleij

[PATCH 6/6] omapfb: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index d356a25..f1eb8b0 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -128,7 +129,7 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
 {
struct device_node *np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
 
-- 
1.9.1

[PATCH 6/6] omapfb: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index d356a25..f1eb8b0 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -128,7 +129,7 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
 {
struct device_node *np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
 
-- 
1.9.1

Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver

[Linus Walleij]

On Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil  wrote:

> One problem still unresolved: the pinctrl framework does not allow us to
> configure each pin on demand (someone please prove me wrong), when the
> various PWM channels are requested or released. For instance, the PWM
> channels can be configured from sysfs, which would require all PWM pins
> to be configured properly beforehand for the PWM function, eventually
> causing conflicts with other platform or board drivers.

Why do you think this?

- Pincontrol handles can be obtained at runtime.
- Pincontrol states can be changed at runtime.

The fact that a the handle is retrived by the device core and set to
the states named "init" or "default" during boot is just a convenience.

You can have as many and as fine-grained states as you want. They
can pertain to just one pin too.

Linus Walleij

[PATCH 2/6] drm/omapdrm: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e96..f49f2ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "omapdss.h"
@@ -127,7 +128,7 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
 {
struct device_node *np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
 
-- 
1.9.1

[PATCH 3/6] drm: rcar-du: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 7a6bd8b..2ba728b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -391,7 +391,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
return -ENODEV;
}
 
-   entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
+   entity_ep_node = of_graph_get_remote_endpoint(ep->local_node);
 
for_each_endpoint_of_node(entity, ep_node) {
if (ep_node == entity_ep_node)
-- 
1.9.1

[PATCH 2/6] drm/omapdrm: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e96..f49f2ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "omapdss.h"
@@ -127,7 +128,7 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
 {
struct device_node *np;
 
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
 
-- 
1.9.1

[PATCH 3/6] drm: rcar-du: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 7a6bd8b..2ba728b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -391,7 +391,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
return -ENODEV;
}
 
-   entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
+   entity_ep_node = of_graph_get_remote_endpoint(ep->local_node);
 
for_each_endpoint_of_node(entity, ep_node) {
if (ep_node == entity_ep_node)
-- 
1.9.1

[PATCH 1/6] of_graph: add of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

It should use same method to get same result.
To getting remote-endpoint node,
let's use of_graph_get_remote_endpoint()

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 18 --
 include/linux/of_graph.h |  8 
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c..5391a9b5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2426,6 +2426,20 @@ struct device_node *of_graph_get_endpoint_by_regs(
 EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
 
 /**
+ * of_graph_get_remote_endpoint() - get remote endpoint node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: Remote endpoint node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_remote_endpoint(const struct device_node 
*node)
+{
+   /* Get remote endpoint node. */
+   return of_parse_phandle(node, "remote-endpoint", 0);
+}
+EXPORT_SYMBOL(of_graph_get_remote_endpoint);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2439,7 +2453,7 @@ struct device_node *of_graph_get_remote_port_parent(
unsigned int depth;
 
/* Get remote endpoint node. */
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
 
/* Walk 3 levels up only if there is 'ports' node. */
for (depth = 3; depth && np; depth--) {
@@ -2463,7 +2477,7 @@ struct device_node *of_graph_get_remote_port(const struct 
device_node *node)
struct device_node *np;
 
/* Get remote endpoint node. */
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
return of_get_next_parent(np);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2..d9d6d9c 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -48,6 +48,8 @@ struct device_node *of_graph_get_next_endpoint(const struct 
device_node *parent,
struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg);
+struct device_node *of_graph_get_remote_endpoint(
+   const struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -78,6 +80,12 @@ static inline struct device_node 
*of_graph_get_endpoint_by_regs(
return NULL;
 }
 
+static inline struct device_node *of_graph_get_remote_endpoint(
+   const struct device_node *node)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1

[PATCH 1/6] of_graph: add of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

It should use same method to get same result.
To getting remote-endpoint node,
let's use of_graph_get_remote_endpoint()

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 18 --
 include/linux/of_graph.h |  8 
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c..5391a9b5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2426,6 +2426,20 @@ struct device_node *of_graph_get_endpoint_by_regs(
 EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
 
 /**
+ * of_graph_get_remote_endpoint() - get remote endpoint node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: Remote endpoint node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_remote_endpoint(const struct device_node 
*node)
+{
+   /* Get remote endpoint node. */
+   return of_parse_phandle(node, "remote-endpoint", 0);
+}
+EXPORT_SYMBOL(of_graph_get_remote_endpoint);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2439,7 +2453,7 @@ struct device_node *of_graph_get_remote_port_parent(
unsigned int depth;
 
/* Get remote endpoint node. */
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
 
/* Walk 3 levels up only if there is 'ports' node. */
for (depth = 3; depth && np; depth--) {
@@ -2463,7 +2477,7 @@ struct device_node *of_graph_get_remote_port(const struct 
device_node *node)
struct device_node *np;
 
/* Get remote endpoint node. */
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
return of_get_next_parent(np);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2..d9d6d9c 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -48,6 +48,8 @@ struct device_node *of_graph_get_next_endpoint(const struct 
device_node *parent,
struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg);
+struct device_node *of_graph_get_remote_endpoint(
+   const struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -78,6 +80,12 @@ static inline struct device_node 
*of_graph_get_endpoint_by_regs(
return NULL;
 }
 
+static inline struct device_node *of_graph_get_remote_endpoint(
+   const struct device_node *node)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1

[PATCH 0/6] of_graph_get_remote_endpoint()

[Kuninori Morimoto]

Hi Rob

Now many driver is getting remote-endpoint by manually,
but we should use same method to get same result IMO.
Thus this patch adds of_graph_get_remote_endpoint() for this purpose.
And use it on several drivers

Kuninori Morimoto (6):
  of_graph: add of_graph_get_remote_endpoint()
  drm/omapdrm: use of_graph_get_remote_endpoint()
  drm: rcar-du: use of_graph_get_remote_endpoint()
  media: ti-vpe: cal: use of_graph_get_remote_endpoint()
  v4l: of: use of_graph_get_remote_endpoint()
  omapfb: use of_graph_get_remote_endpoint()

 drivers/gpu/drm/omapdrm/dss/dss-of.c  |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  2 +-
 drivers/media/platform/ti-vpe/cal.c   |  2 +-
 drivers/media/v4l2-core/v4l2-of.c |  3 ++-
 drivers/of/base.c | 18 --
 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c |  3 ++-
 include/linux/of_graph.h  |  8 
 7 files changed, 32 insertions(+), 7 deletions(-)

-- 
1.9.1

[PATCH 0/6] of_graph_get_remote_endpoint()

[Kuninori Morimoto]

Hi Rob

Now many driver is getting remote-endpoint by manually,
but we should use same method to get same result IMO.
Thus this patch adds of_graph_get_remote_endpoint() for this purpose.
And use it on several drivers

Kuninori Morimoto (6):
  of_graph: add of_graph_get_remote_endpoint()
  drm/omapdrm: use of_graph_get_remote_endpoint()
  drm: rcar-du: use of_graph_get_remote_endpoint()
  media: ti-vpe: cal: use of_graph_get_remote_endpoint()
  v4l: of: use of_graph_get_remote_endpoint()
  omapfb: use of_graph_get_remote_endpoint()

 drivers/gpu/drm/omapdrm/dss/dss-of.c  |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  2 +-
 drivers/media/platform/ti-vpe/cal.c   |  2 +-
 drivers/media/v4l2-core/v4l2-of.c |  3 ++-
 drivers/of/base.c | 18 --
 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c |  3 ++-
 include/linux/of_graph.h  |  8 
 7 files changed, 32 insertions(+), 7 deletions(-)

-- 
1.9.1

Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

[Peter Chen]

On Wed, Jan 18, 2017 at 02:57:27PM -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 2:54 PM, Stephen Boyd  wrote:
> > Quoting Peter Chen (2017-01-17 23:34:32)
> >> On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> >> > Quoting Peter Chen (2017-01-15 19:45:51)
> >> > >
> >> > > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> >> > > to port it to generic phy framework.
> >> > >
> >> >
> >> > Ok. I'll look into that. Can the other patches in this series be picked
> >> > up? Otherwise I can resend them all again once I fix the phy_set_mode()
> >> > call location and introduce a new phy op.
> >>
> >> I can pick up chipidea patches after you test the patch I supplied at:
> >>
> >> [PATCH v6 11/25] usb: chipidea: vbus event may exist before 
> >> starting
> >> gadget
> >
> > Ok. I've confirmed that this updated patch works fine for me. You can
> > have my Tested-by and Reviewed-by there.
> >
> >>
> >> You may ping other maintainers to pick up other patches.
> >>
> >
> > I was hoping you could pick the beginning of the series up until the PHY
> > drivers, which can go via Kishon's tree. That would mean applying the
> > drivers/of/ part. Rob is that ok?
> 
> Peter, If there's a dependency then please take the patches I've
> acked. That's why I acked them.
> 

Ok, I will do it.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

[Peter Chen]

On Wed, Jan 18, 2017 at 02:57:27PM -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 2:54 PM, Stephen Boyd  wrote:
> > Quoting Peter Chen (2017-01-17 23:34:32)
> >> On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> >> > Quoting Peter Chen (2017-01-15 19:45:51)
> >> > >
> >> > > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> >> > > to port it to generic phy framework.
> >> > >
> >> >
> >> > Ok. I'll look into that. Can the other patches in this series be picked
> >> > up? Otherwise I can resend them all again once I fix the phy_set_mode()
> >> > call location and introduce a new phy op.
> >>
> >> I can pick up chipidea patches after you test the patch I supplied at:
> >>
> >> [PATCH v6 11/25] usb: chipidea: vbus event may exist before 
> >> starting
> >> gadget
> >
> > Ok. I've confirmed that this updated patch works fine for me. You can
> > have my Tested-by and Reviewed-by there.
> >
> >>
> >> You may ping other maintainers to pick up other patches.
> >>
> >
> > I was hoping you could pick the beginning of the series up until the PHY
> > drivers, which can go via Kishon's tree. That would mean applying the
> > drivers/of/ part. Rob is that ok?
> 
> Peter, If there's a dependency then please take the patches I've
> acked. That's why I acked them.
> 

Ok, I will do it.

-- 

Best Regards,
Peter Chen

Re: [PATCH] stmmac: adding EEE to GMAC4

[Rayagond Kokatanur]

On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto  wrote:
> This patch adds Energy Efficiency Ethernet to GMAC4.
>
> Signed-off-by: Joao Pinto 
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 12 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 
> +++
>  2 files changed, 71 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index b524598..73d1dab 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -90,6 +90,18 @@ enum power_event {
> power_down = 0x0001,
>  };
>
> +/* Energy Efficient Ethernet (EEE) for GMAC4
> + *
> + * LPI status, timer and control register offset
> + */
> +#define GMAC4_LPI_CTRL_STATUS  0xd0
> +#define GMAC4_LPI_TIMER_CTRL   0xd4
> +
> +/* LPI control and status defines */
> +#define GMAC4_LPI_CTRL_STATUS_LPITXA   BIT(19) /* Enable LPI TX Automate */
> +#define GMAC4_LPI_CTRL_STATUS_PLS  BIT(17) /* PHY Link Status */
> +#define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
> +
>  /* MAC Debug bitmap */
>  #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>  #define GMAC_DEBUG_TFCSTS_SHIFT17
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index ecfbf57..02eab79 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info 
> *hw,
>GMAC_ADDR_LOW(reg_n));
>  }
>
> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   /* Enable the link status receive on RGMII, SGMII ore SMII
> +* receive path and instruct the transmit to enter in LPI
> +* state.
> +*/
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +   value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
> +
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +   value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | 
> GMAC4_LPI_CTRL_STATUS_LPITXA);
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +
> +   if (link)
> +   value |= GMAC4_LPI_CTRL_STATUS_PLS;
> +   else
> +   value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
> +
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);

If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
should AND 0x3ff.

int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);

> +
> +   /* Program the timers in the LPI timer control register:
> +* LS: minimum time (ms) for which the link
> +*  status from PHY should be ok before transmitting
> +*  the LPI pattern.
> +* TW: minimum time (us) for which the core waits
> +*  after it has stopped transmitting the LPI pattern.
> +*/
> +   writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
> +}
> +
>  static void dwmac4_set_filter(struct mac_device_info *hw,
>   struct net_device *dev)
>  {
> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
> .pmt = dwmac4_pmt,
> .set_umac_addr = dwmac4_set_umac_addr,
> .get_umac_addr = dwmac4_get_umac_addr,
> +   .set_eee_mode = dwmac4_set_eee_mode,
> +   .reset_eee_mode = dwmac4_reset_eee_mode,
> +   .set_eee_timer = dwmac4_set_eee_timer,
> +   .set_eee_pls = dwmac4_set_eee_pls,
> .pcs_ctrl_ane = dwmac4_ctrl_ane,
> .pcs_rane = dwmac4_rane,
> .pcs_get_adv_lp = dwmac4_get_adv_lp,
> --
> 2.9.3
>



-- 
wwr
Rayagond

Re: [PATCH] stmmac: adding EEE to GMAC4

[Rayagond Kokatanur]

On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto  wrote:
> This patch adds Energy Efficiency Ethernet to GMAC4.
>
> Signed-off-by: Joao Pinto 
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 12 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 
> +++
>  2 files changed, 71 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index b524598..73d1dab 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -90,6 +90,18 @@ enum power_event {
> power_down = 0x0001,
>  };
>
> +/* Energy Efficient Ethernet (EEE) for GMAC4
> + *
> + * LPI status, timer and control register offset
> + */
> +#define GMAC4_LPI_CTRL_STATUS  0xd0
> +#define GMAC4_LPI_TIMER_CTRL   0xd4
> +
> +/* LPI control and status defines */
> +#define GMAC4_LPI_CTRL_STATUS_LPITXA   BIT(19) /* Enable LPI TX Automate */
> +#define GMAC4_LPI_CTRL_STATUS_PLS  BIT(17) /* PHY Link Status */
> +#define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
> +
>  /* MAC Debug bitmap */
>  #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>  #define GMAC_DEBUG_TFCSTS_SHIFT17
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index ecfbf57..02eab79 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info 
> *hw,
>GMAC_ADDR_LOW(reg_n));
>  }
>
> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   /* Enable the link status receive on RGMII, SGMII ore SMII
> +* receive path and instruct the transmit to enter in LPI
> +* state.
> +*/
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +   value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
> +
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +   value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | 
> GMAC4_LPI_CTRL_STATUS_LPITXA);
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +
> +   if (link)
> +   value |= GMAC4_LPI_CTRL_STATUS_PLS;
> +   else
> +   value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
> +
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);

If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
should AND 0x3ff.

int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);

> +
> +   /* Program the timers in the LPI timer control register:
> +* LS: minimum time (ms) for which the link
> +*  status from PHY should be ok before transmitting
> +*  the LPI pattern.
> +* TW: minimum time (us) for which the core waits
> +*  after it has stopped transmitting the LPI pattern.
> +*/
> +   writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
> +}
> +
>  static void dwmac4_set_filter(struct mac_device_info *hw,
>   struct net_device *dev)
>  {
> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
> .pmt = dwmac4_pmt,
> .set_umac_addr = dwmac4_set_umac_addr,
> .get_umac_addr = dwmac4_get_umac_addr,
> +   .set_eee_mode = dwmac4_set_eee_mode,
> +   .reset_eee_mode = dwmac4_reset_eee_mode,
> +   .set_eee_timer = dwmac4_set_eee_timer,
> +   .set_eee_pls = dwmac4_set_eee_pls,
> .pcs_ctrl_ane = dwmac4_ctrl_ane,
> .pcs_rane = dwmac4_rane,
> .pcs_get_adv_lp = dwmac4_get_adv_lp,
> --
> 2.9.3
>



-- 
wwr
Rayagond

Re: How to improve PCI bug tracking?

[Lukas Wunner]

On Wed, Jan 18, 2017 at 06:29:15PM -0500, Sinan Kaya wrote:
> On 1/18/2017 5:53 PM, Bjorn Helgaas wrote:
> > I want to improve PCI bug tracking.  It feels like our bugs don't get
> > the attention they need, and I'm soliciting ideas for how to improve
> > this.
> > 
> > Current situation:
> > 
> >   - People often report bugs via email to linux-pci.  I think this
> > is good because everybody can see it.
> > 
> >   - Even after an email report, I often request a bugzilla because
> > (1) it helps keep things from being forgotten, (2) it's a
> > convenient place to store bulky data, and (3) I like to have a
> > bugzilla URL to include in the changelog of a patch that fixes the
> > bug.
> > 
> >   - Sometimes people open a bugzilla directly.  I get email about
> > these (along with one or two other people), but this is sort of a
> > problem because linux-pci never sees it, sometimes I miss it, and
> > things tend to languish.
> > 
> >   - Discussion on a bugzilla is only seen by people listed in the
> > bugzilla, not on linux-pci.
> > 
> > I'm contemplating changing this so the bugzilla mail would also go to
> > linux-pci.
> 
> I have seen this happening on linux-scsi.
> 
> http://www.spinics.net/lists/linux-scsi/msg103272.html

Same for dri-devel@ / nouv...@lists.freedesktop.org.

Go for it.

Lukas

Re: How to improve PCI bug tracking?

[Lukas Wunner]

On Wed, Jan 18, 2017 at 06:29:15PM -0500, Sinan Kaya wrote:
> On 1/18/2017 5:53 PM, Bjorn Helgaas wrote:
> > I want to improve PCI bug tracking.  It feels like our bugs don't get
> > the attention they need, and I'm soliciting ideas for how to improve
> > this.
> > 
> > Current situation:
> > 
> >   - People often report bugs via email to linux-pci.  I think this
> > is good because everybody can see it.
> > 
> >   - Even after an email report, I often request a bugzilla because
> > (1) it helps keep things from being forgotten, (2) it's a
> > convenient place to store bulky data, and (3) I like to have a
> > bugzilla URL to include in the changelog of a patch that fixes the
> > bug.
> > 
> >   - Sometimes people open a bugzilla directly.  I get email about
> > these (along with one or two other people), but this is sort of a
> > problem because linux-pci never sees it, sometimes I miss it, and
> > things tend to languish.
> > 
> >   - Discussion on a bugzilla is only seen by people listed in the
> > bugzilla, not on linux-pci.
> > 
> > I'm contemplating changing this so the bugzilla mail would also go to
> > linux-pci.
> 
> I have seen this happening on linux-scsi.
> 
> http://www.spinics.net/lists/linux-scsi/msg103272.html

Same for dri-devel@ / nouv...@lists.freedesktop.org.

Go for it.

Lukas

Re: [PATCH perf/core 1/6] tools lib bpf: Fix map offsets in relocation

[Wangnan (F)]

On 2017/1/19 7:57, Joe Stringer wrote:

Commit 4708bbda5cb2 ("tools lib bpf: Fix maps resolution") attempted to
fix map resolution by identifying the number of symbols that point to
maps, and using this number to resolve each of the maps.

However, during relocation the original definition of the map size was
still in use.



Oops... Didn't realize that.



  For up to two maps, the calculation was correct if there
was a small difference in size between the map definition in libbpf and
the one that the client library uses. However if the difference was
large, particularly if more than two maps were used in the BPF program,
the relocation would fail.

For example, when using a map definition with size 28, with three maps,
map relocation would count
 (sym_offset / sizeof(struct bpf_map_def) => map_idx)
 (0 / 16 => 0), ie map_idx = 0
 (28 / 16 => 1), ie map_idx = 1
 (56 / 16 => 3), ie map_idx = 3

So, libbpf reports:
 libbpf: bpf relocation: map_idx 3 large than 2


Understand.


Fix map relocation by tracking the size of the map definition during
map counting, then reuse this instead of the size of the libbpf map
structure.


Then we add a restriction that map size is fixed
in one object, but we don't have to. During relocating,
we can get exact map positioning information from
sym.st_value. I think finding a map with exact offset
from the map array would be better.

I'll write a patch to replace this one.

Thank you.


  With this patch applied, libbpf will accept such ELFs.

Fixes: 4708bbda5cb2 ("tools lib bpf: Fix maps resolution")
Signed-off-by: Joe Stringer 
---
  tools/lib/bpf/libbpf.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 84e6b35da4bd..350ee4c59f85 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -201,6 +201,7 @@ struct bpf_object {
size_t nr_programs;
struct bpf_map *maps;
size_t nr_maps;
+   size_t map_len;
  
  	bool loaded;
  
@@ -379,6 +380,7 @@ static struct bpf_object *bpf_object__new(const char *path,

obj->efile.maps_shndx = -1;
  
  	obj->loaded = false;

+   obj->map_len = sizeof(struct bpf_map_def);
  
  	INIT_LIST_HEAD(>list);

list_add(>list, _objects_list);
@@ -602,6 +604,7 @@ bpf_object__init_maps(struct bpf_object *obj)
return -ENOMEM;
}
obj->nr_maps = nr_maps;
+   obj->map_len = data->d_size / nr_maps;
  
  	/*

 * fill all fd with -1 so won't close incorrect
@@ -829,7 +832,7 @@ bpf_program__collect_reloc(struct bpf_program *prog,
return -LIBBPF_ERRNO__RELOC;
}
  
-		map_idx = sym.st_value / sizeof(struct bpf_map_def);

+   map_idx = sym.st_value / prog->obj->map_len;
if (map_idx >= nr_maps) {
pr_warning("bpf relocation: map_idx %d large than %d\n",
   (int)map_idx, (int)nr_maps - 1);

Re: [PATCH perf/core 1/6] tools lib bpf: Fix map offsets in relocation

[Wangnan (F)]

On 2017/1/19 7:57, Joe Stringer wrote:

Commit 4708bbda5cb2 ("tools lib bpf: Fix maps resolution") attempted to
fix map resolution by identifying the number of symbols that point to
maps, and using this number to resolve each of the maps.

However, during relocation the original definition of the map size was
still in use.



Oops... Didn't realize that.



  For up to two maps, the calculation was correct if there
was a small difference in size between the map definition in libbpf and
the one that the client library uses. However if the difference was
large, particularly if more than two maps were used in the BPF program,
the relocation would fail.

For example, when using a map definition with size 28, with three maps,
map relocation would count
 (sym_offset / sizeof(struct bpf_map_def) => map_idx)
 (0 / 16 => 0), ie map_idx = 0
 (28 / 16 => 1), ie map_idx = 1
 (56 / 16 => 3), ie map_idx = 3

So, libbpf reports:
 libbpf: bpf relocation: map_idx 3 large than 2


Understand.


Fix map relocation by tracking the size of the map definition during
map counting, then reuse this instead of the size of the libbpf map
structure.


Then we add a restriction that map size is fixed
in one object, but we don't have to. During relocating,
we can get exact map positioning information from
sym.st_value. I think finding a map with exact offset
from the map array would be better.

I'll write a patch to replace this one.

Thank you.


  With this patch applied, libbpf will accept such ELFs.

Fixes: 4708bbda5cb2 ("tools lib bpf: Fix maps resolution")
Signed-off-by: Joe Stringer 
---
  tools/lib/bpf/libbpf.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 84e6b35da4bd..350ee4c59f85 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -201,6 +201,7 @@ struct bpf_object {
size_t nr_programs;
struct bpf_map *maps;
size_t nr_maps;
+   size_t map_len;
  
  	bool loaded;
  
@@ -379,6 +380,7 @@ static struct bpf_object *bpf_object__new(const char *path,

obj->efile.maps_shndx = -1;
  
  	obj->loaded = false;

+   obj->map_len = sizeof(struct bpf_map_def);
  
  	INIT_LIST_HEAD(>list);

list_add(>list, _objects_list);
@@ -602,6 +604,7 @@ bpf_object__init_maps(struct bpf_object *obj)
return -ENOMEM;
}
obj->nr_maps = nr_maps;
+   obj->map_len = data->d_size / nr_maps;
  
  	/*

 * fill all fd with -1 so won't close incorrect
@@ -829,7 +832,7 @@ bpf_program__collect_reloc(struct bpf_program *prog,
return -LIBBPF_ERRNO__RELOC;
}
  
-		map_idx = sym.st_value / sizeof(struct bpf_map_def);

+   map_idx = sym.st_value / prog->obj->map_len;
if (map_idx >= nr_maps) {
pr_warning("bpf relocation: map_idx %d large than %d\n",
   (int)map_idx, (int)nr_maps - 1);

linux-next: Tree for Jan 19

[Stephen Rothwell]

Hi all,

Changes since 20170118:

The audit tree gained a conflict against Linus' tree.

The tip tree gained a conflict against the security tree.

The rcu tree gained a semantic conflict against the net-next tree for
which I applied a merge fix patch.

I dropped 4 patches from the akpm tree that turned up in the tip tree.

Non-merge commits (relative to Linus' tree): 3931
 4740 files changed, 146960 insertions(+), 87918 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 251 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (fa19a769f82f Merge branch 'fixes' of 
git://git.armlinux.org.uk/~rmk/linux-arm)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (eb1357d942e5 ARC: module: Fix 
!CONFIG_ARC_DW2_UNWIND builds)
Merging arm-current/fixes (90f92c631b21 ARM: 8613/1: Fix the uaccess crash on 
PB11MPCore)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (27593d72c4ad powerpc/perf: Use MSR to report 
privilege level on P9 DD1)
Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced 
panicing with panicking)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (d407bd25a204 bpf: don't trigger OOM killer under pressure 
with map alloc)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (3fd0b634de7d netfilter: ipt_CLUSTERIP: fix build 
error without procfs)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (7195439d1d71 Revert "bcma: init serial console 
directly from ChipCommon code")
Merging mac80211/master (dbef53621116 mac80211: prevent skb/txq mismatch)
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (ea2a7fb12093 Revert "PCI: Add runtime PM support 
for PCIe ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (833674a45ec7 Merge tag 'fixes-for-v4.10-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (49def1853334 Linux 4.10-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (a121103c9228 Linux 4.10-rc3)
Merging char-misc.current/char-misc-linus (49def1853334 Linux 4.10-rc4)
Merging input-current/for-linus (1c3415a06b10 Input: elants_i2c - avoid divide 
by 0 errors on bad touchscreen data)
Merging crypto-current/

linux-next: Tree for Jan 19

[Stephen Rothwell]

Hi all,

Changes since 20170118:

The audit tree gained a conflict against Linus' tree.

The tip tree gained a conflict against the security tree.

The rcu tree gained a semantic conflict against the net-next tree for
which I applied a merge fix patch.

I dropped 4 patches from the akpm tree that turned up in the tip tree.

Non-merge commits (relative to Linus' tree): 3931
 4740 files changed, 146960 insertions(+), 87918 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 251 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (fa19a769f82f Merge branch 'fixes' of 
git://git.armlinux.org.uk/~rmk/linux-arm)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (eb1357d942e5 ARC: module: Fix 
!CONFIG_ARC_DW2_UNWIND builds)
Merging arm-current/fixes (90f92c631b21 ARM: 8613/1: Fix the uaccess crash on 
PB11MPCore)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (27593d72c4ad powerpc/perf: Use MSR to report 
privilege level on P9 DD1)
Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced 
panicing with panicking)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (d407bd25a204 bpf: don't trigger OOM killer under pressure 
with map alloc)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (3fd0b634de7d netfilter: ipt_CLUSTERIP: fix build 
error without procfs)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (7195439d1d71 Revert "bcma: init serial console 
directly from ChipCommon code")
Merging mac80211/master (dbef53621116 mac80211: prevent skb/txq mismatch)
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (ea2a7fb12093 Revert "PCI: Add runtime PM support 
for PCIe ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (833674a45ec7 Merge tag 'fixes-for-v4.10-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (49def1853334 Linux 4.10-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (a121103c9228 Linux 4.10-rc3)
Merging char-misc.current/char-misc-linus (49def1853334 Linux 4.10-rc4)
Merging input-current/for-linus (1c3415a06b10 Input: elants_i2c - avoid divide 
by 0 errors on bad touchscreen data)
Merging crypto-current/

Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role

[Baolin Wang]

Hi John,

On 19 January 2017 at 11:31, John Youn  wrote:
> On 1/18/2017 7:12 PM, Baolin Wang wrote:
>> Hi John,
>>
>> On 19 January 2017 at 09:33, John Youn  wrote:
>>> On 1/16/2017 2:38 AM, Felipe Balbi wrote:

 Hi,

 John Youn  writes:
>> Baolin Wang  writes:
 Baolin Wang  writes:
> When dwc3 controller acts as host role with attaching slow speed 
> device
> (like mouse or keypad). Then if we plugged out the slow speed device,
> it will timeout to run the deconfiguration endpoint command to drop 
> the
> endpoint's resources. Some xHCI command timeout log as below when
> disconnecting one slow device:
>
> [   99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1
> [   99.814699] c0 xhci-hcd.0.auto: resume root hub
> [   99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port
>  polling.
> [   99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 
> status
>  = 0x202a0
> [   99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100
> [   99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual
>  port 0 status  = 0x2a0
> [   99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1,
>  ep 0x81, starting at offset 
> 0xc406d210
> [   99.869645] c0 xhci-hcd.0.auto: // Ding dong!
> [   99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB
> [   99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at
>  0xc406d210 (dma).
> [   99.889012] c0 xhci-hcd.0.auto: Finding endpoint context
> [   99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1
> [   99.900519] c0 xhci-hcd.0.auto: New dequeue segment =
>  ffc1112f0880 (virtual)
> [   99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 
> (DMA)
> [   99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg =
>  ffc1112f0880 (0xc406d000 dma),
>  new deq ptr = ff8002175220
>  (0xc406d220 dma), new cycle = 1
> [   99.931242] c0 xhci-hcd.0.auto: // Ding dong!
> [   99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd,
>  deq = @c406d220
> [   99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port
>  polling.
> [  100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev
>  ffc01ae08800
> [  100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop
>  flags = 0x8, new add flags = 0x0
> [  100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for 
> udev
>  ffc01ae08800
> [  100.076868] c0 xhci-hcd.0.auto: New Input Control Context:
>
> ..
>
> [  100.427252] c0 xhci-hcd.0.auto: // Ding dong!
> [  105.430728] c0 xhci-hcd.0.auto: Command timeout
> [  105.436029] c0 xhci-hcd.0.auto: Abort command ring
> [  113.558223] c0 xhci-hcd.0.auto: Command completion event does not 
> match
>  command
> [  113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure
>  endpoint command
>
> The reason is it will suspend USB phy to disable phy clock when
> disconnecting the slow USB decice, that will hang on the xHCI commands
> executing which depends on the phy clock.
>
> Thus we should disable USB2.0 phy suspend feature when dwc3 acts as 
> host
> role.
>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/usb/dwc3/core.c |   14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 9a4a5e4..0b646cf 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
>   if (dwc->revision > DWC3_REVISION_194A)
>   reg |= DWC3_GUSB2PHYCFG_SUSPHY;
>
> + /*
> +  * When dwc3 controller acts as host role with attaching one 
> slow speed
> +  * 

Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role

[Baolin Wang]

Hi John,

On 19 January 2017 at 11:31, John Youn  wrote:
> On 1/18/2017 7:12 PM, Baolin Wang wrote:
>> Hi John,
>>
>> On 19 January 2017 at 09:33, John Youn  wrote:
>>> On 1/16/2017 2:38 AM, Felipe Balbi wrote:

 Hi,

 John Youn  writes:
>> Baolin Wang  writes:
 Baolin Wang  writes:
> When dwc3 controller acts as host role with attaching slow speed 
> device
> (like mouse or keypad). Then if we plugged out the slow speed device,
> it will timeout to run the deconfiguration endpoint command to drop 
> the
> endpoint's resources. Some xHCI command timeout log as below when
> disconnecting one slow device:
>
> [   99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1
> [   99.814699] c0 xhci-hcd.0.auto: resume root hub
> [   99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port
>  polling.
> [   99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 
> status
>  = 0x202a0
> [   99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100
> [   99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual
>  port 0 status  = 0x2a0
> [   99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1,
>  ep 0x81, starting at offset 
> 0xc406d210
> [   99.869645] c0 xhci-hcd.0.auto: // Ding dong!
> [   99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB
> [   99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at
>  0xc406d210 (dma).
> [   99.889012] c0 xhci-hcd.0.auto: Finding endpoint context
> [   99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1
> [   99.900519] c0 xhci-hcd.0.auto: New dequeue segment =
>  ffc1112f0880 (virtual)
> [   99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 
> (DMA)
> [   99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg =
>  ffc1112f0880 (0xc406d000 dma),
>  new deq ptr = ff8002175220
>  (0xc406d220 dma), new cycle = 1
> [   99.931242] c0 xhci-hcd.0.auto: // Ding dong!
> [   99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd,
>  deq = @c406d220
> [   99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port
>  polling.
> [  100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev
>  ffc01ae08800
> [  100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop
>  flags = 0x8, new add flags = 0x0
> [  100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for 
> udev
>  ffc01ae08800
> [  100.076868] c0 xhci-hcd.0.auto: New Input Control Context:
>
> ..
>
> [  100.427252] c0 xhci-hcd.0.auto: // Ding dong!
> [  105.430728] c0 xhci-hcd.0.auto: Command timeout
> [  105.436029] c0 xhci-hcd.0.auto: Abort command ring
> [  113.558223] c0 xhci-hcd.0.auto: Command completion event does not 
> match
>  command
> [  113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure
>  endpoint command
>
> The reason is it will suspend USB phy to disable phy clock when
> disconnecting the slow USB decice, that will hang on the xHCI commands
> executing which depends on the phy clock.
>
> Thus we should disable USB2.0 phy suspend feature when dwc3 acts as 
> host
> role.
>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/usb/dwc3/core.c |   14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 9a4a5e4..0b646cf 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
>   if (dwc->revision > DWC3_REVISION_194A)
>   reg |= DWC3_GUSB2PHYCFG_SUSPHY;
>
> + /*
> +  * When dwc3 controller acts as host role with attaching one 
> slow speed
> +  * device (like mouse or keypad). Then if we plugged out the 
> slow speed
> +  * device, it will timeout to run the 

Re: [PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
> 
> Signed-off-by: YT Shen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  8 
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  6 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 17 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  7 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 29 
> +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  |  1 +
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  6 ++
>  7 files changed, 74 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4552178..a14d7d6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,6 +35,7 @@
>  #define DISP_REG_OVL_PITCH(n)(0x0044 + 0x20 * (n))
>  #define DISP_REG_OVL_RDMA_CTRL(n)(0x00c0 + 0x20 * (n))
>  #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> +#define DISP_REG_OVL_ADDR_MT2701 0x0040
>  #define DISP_REG_OVL_ADDR_MT8173 0x0f40
>  #define DISP_REG_OVL_ADDR(ovl, n)((ovl)->data->addr + 0x20 * (n))
>  
> @@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT2701,
> + .fmt_rgb565_is_0 = false,
> +};
> +
>  static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
>   .addr = DISP_REG_OVL_ADDR_MT8173,
>   .fmt_rgb565_is_0 = true,
>  };
>  
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> +   .data = _ovl_driver_data},
>   { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
>   {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index e5e5318..b68a513 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> + .fifo_size = SZ_4K,
> +};
> +
>  static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
>   .fifo_size = SZ_8K,
>  };
>  
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> +   .data = _rdma_driver_data},
>   { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
>   {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a9b209c..8130f3d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -60,6 +60,13 @@
>  #define MT8173_MUTEX_MOD_DISP_PWM1   BIT(24)
>  #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>  
> +#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA   BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR  BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0  BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1  BIT(12)
> +
>  #define MUTEX_SOF_SINGLE_MODE0
>  #define MUTEX_SOF_DSI0   1
>  #define MUTEX_SOF_DSI1   2
> @@ -92,6 +99,15 @@ struct mtk_ddp {
>   const unsigned int  *mutex_mod;
>  };
>  
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
>  static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
>   [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
>   [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id ddp_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
>   { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
>   {},
>  };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index f6e853a..8b52416 100644
> --- 

Re: [PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
> 
> Signed-off-by: YT Shen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  8 
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  6 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 17 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  7 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 29 
> +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  |  1 +
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  6 ++
>  7 files changed, 74 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4552178..a14d7d6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,6 +35,7 @@
>  #define DISP_REG_OVL_PITCH(n)(0x0044 + 0x20 * (n))
>  #define DISP_REG_OVL_RDMA_CTRL(n)(0x00c0 + 0x20 * (n))
>  #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> +#define DISP_REG_OVL_ADDR_MT2701 0x0040
>  #define DISP_REG_OVL_ADDR_MT8173 0x0f40
>  #define DISP_REG_OVL_ADDR(ovl, n)((ovl)->data->addr + 0x20 * (n))
>  
> @@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT2701,
> + .fmt_rgb565_is_0 = false,
> +};
> +
>  static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
>   .addr = DISP_REG_OVL_ADDR_MT8173,
>   .fmt_rgb565_is_0 = true,
>  };
>  
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> +   .data = _ovl_driver_data},
>   { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
>   {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index e5e5318..b68a513 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> + .fifo_size = SZ_4K,
> +};
> +
>  static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
>   .fifo_size = SZ_8K,
>  };
>  
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> +   .data = _rdma_driver_data},
>   { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
>   {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a9b209c..8130f3d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -60,6 +60,13 @@
>  #define MT8173_MUTEX_MOD_DISP_PWM1   BIT(24)
>  #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>  
> +#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA   BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR  BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0  BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1  BIT(12)
> +
>  #define MUTEX_SOF_SINGLE_MODE0
>  #define MUTEX_SOF_DSI0   1
>  #define MUTEX_SOF_DSI1   2
> @@ -92,6 +99,15 @@ struct mtk_ddp {
>   const unsigned int  *mutex_mod;
>  };
>  
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
>  static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
>   [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
>   [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id ddp_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
>   { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
>   {},
>  };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index f6e853a..8b52416 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ 

Re: [PATCH 0/6 v4] adv7511 EDID probing improvements

[Archit Taneja]

On 01/19/2017 04:34 AM, Laurent Pinchart wrote:

Hi John,

Thank you for the patches.

On Monday 16 Jan 2017 16:52:46 John Stultz wrote:

Wanted to re-send out v4  of this patch set, integrating some
changes suggested by Laurent, for consideration for merging for
v4.11

The first three patches are fixups that are hopefully straight
forward, integrating feedback I got from Laurant, with minimal
change from the previous versions.

The last three patches try to clean up and rework the EDID
probing code, to avoid issues seen on HiKey. I've reworked these
more significantly since v3 to address feedback from Laurent.

Thoughts and feedback would be appreciated!


For the whole series,

Tested-by: Laurent Pinchart 


Queued to drm-misc-next. Updated the commit messages for patches 5
and 6 as suggested by Laurent.

Thanks,
Archit




New in v4:
* Tweaked connector.status assignment to avoid race, as
  suggested by Laurent
* Reworked the __adv7511_power_on helpers to avoid calling
  regcache_sync in the EDID probe path
* Added new patch to set EDID_I2C_ADDR register before doing
  EDID read.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-de...@lists.freedesktop.org

Archit Taneja (1):
  drm/bridge: adv7511: Enable HPD interrupts to support hotplug and
improve monitor detection

John Stultz (5):
  drm/bridge: adv7511: Use work_struct to defer hotplug handing to out
of irq context
  drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
  drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be
reused internally
  drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
  drm/bridge: adv7511: Re-write the i2c address before EDID probing

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  2 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 67
 2 files changed, 51 insertions(+), 18
deletions(-)




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

Re: [PATCH 0/6 v4] adv7511 EDID probing improvements

[Archit Taneja]

On 01/19/2017 04:34 AM, Laurent Pinchart wrote:

Hi John,

Thank you for the patches.

On Monday 16 Jan 2017 16:52:46 John Stultz wrote:

Wanted to re-send out v4  of this patch set, integrating some
changes suggested by Laurent, for consideration for merging for
v4.11

The first three patches are fixups that are hopefully straight
forward, integrating feedback I got from Laurant, with minimal
change from the previous versions.

The last three patches try to clean up and rework the EDID
probing code, to avoid issues seen on HiKey. I've reworked these
more significantly since v3 to address feedback from Laurent.

Thoughts and feedback would be appreciated!


For the whole series,

Tested-by: Laurent Pinchart 


Queued to drm-misc-next. Updated the commit messages for patches 5
and 6 as suggested by Laurent.

Thanks,
Archit




New in v4:
* Tweaked connector.status assignment to avoid race, as
  suggested by Laurent
* Reworked the __adv7511_power_on helpers to avoid calling
  regcache_sync in the EDID probe path
* Added new patch to set EDID_I2C_ADDR register before doing
  EDID read.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-de...@lists.freedesktop.org

Archit Taneja (1):
  drm/bridge: adv7511: Enable HPD interrupts to support hotplug and
improve monitor detection

John Stultz (5):
  drm/bridge: adv7511: Use work_struct to defer hotplug handing to out
of irq context
  drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
  drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be
reused internally
  drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
  drm/bridge: adv7511: Re-write the i2c address before EDID probing

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  2 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 67
 2 files changed, 51 insertions(+), 18
deletions(-)




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

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

On 01/19/2017 06:10 AM, Stephen Boyd wrote:

On 01/18, Bjorn Andersson wrote:

On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote:

On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

[..]

+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";

Each lane has a separate clock, separate reset.. why not create sub-nodes for
each lane?

Yes, each lane has separate pipe clock and resets.
I can have a binding such as written below.

+1


Does it makes sense to pull in the tx, rx and pcs offsets as well
to the child node, and iomap the entire address space of the phy ?


Note that you don't have to follow the same structure in your device
driver as you describe your hardware in devicetree.

I would suggest that you replace the lane-offset and various lane
specific resources with subnodes, but keep the driver "as is".


Didn't we already move away from subnodes for lanes in an earlier
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.


Yea, we started out without having any sub-nodes and we
argued that we don't require them since the qmp device is
represented by the qmp node itself.
The lanes otoh are representative of gen_phys and related properties.

In the driver -
"struct qmp_phy " represents the lanes and holds "struct phy",
"struct qcom_qmp" represents the qmp block as a whole and holds "struct 
device"

Does this make lanes qualify to be childs of qmp ?

"phy as a bus" (just trying to understand here) -
let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
So, should this phy controller be a bus providing two ports (and so we 
will have

couple of child nodes to the phy controller) ?


Regards
Vivek

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

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

On 01/19/2017 06:10 AM, Stephen Boyd wrote:

On 01/18, Bjorn Andersson wrote:

On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote:

On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

[..]

+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";

Each lane has a separate clock, separate reset.. why not create sub-nodes for
each lane?

Yes, each lane has separate pipe clock and resets.
I can have a binding such as written below.

+1


Does it makes sense to pull in the tx, rx and pcs offsets as well
to the child node, and iomap the entire address space of the phy ?


Note that you don't have to follow the same structure in your device
driver as you describe your hardware in devicetree.

I would suggest that you replace the lane-offset and various lane
specific resources with subnodes, but keep the driver "as is".


Didn't we already move away from subnodes for lanes in an earlier
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.


Yea, we started out without having any sub-nodes and we
argued that we don't require them since the qmp device is
represented by the qmp node itself.
The lanes otoh are representative of gen_phys and related properties.

In the driver -
"struct qmp_phy " represents the lanes and holds "struct phy",
"struct qcom_qmp" represents the qmp block as a whole and holds "struct 
device"

Does this make lanes qualify to be childs of qmp ?

"phy as a bus" (just trying to understand here) -
let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
So, should this phy controller be a bus providing two ports (and so we 
will have

couple of child nodes to the phy controller) ?


Regards
Vivek

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

Re: [PATCH v2] PCI: pciehp: Optimize PCIe root resume time

[Lukas Wunner]

On Thu, Jan 19, 2017 at 02:57:26AM +, Shankar, Vaibhav wrote:
> > From: Lukas Wunner [mailto:lu...@wunner.de]
> > Sent: Tuesday, January 17, 2017 9:14 PM
> > On Wed, Jan 18, 2017 at 01:32:13AM +, Shankar, Vaibhav wrote:
> > > > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > > > Sent: Wednesday, January 11, 2017 10:37 AM On Mon, Dec 12, 2016 at
> > > > 04:32:25PM -0800, Vaibhav Shankar wrote:
> > > > > On Apollolake platforms, PCIe rootport takes a long time to resume
> > > > > from S3. With 100ms delay before read pci conf, rootport takes
> > > > > ~200ms during resume.
> > > > >
> > > > > commit 2f5d8e4ff947 ("PCI: pciehp: replace unconditional sleep
> > > > > with config space access check") is the one that added the 100ms
> > > > > delay before reading pci conf.
> > > > >
> > > > > This patch includes a condition check for 100ms dealy before
> > > > > reading PCIe conf. This delay in included only when PCIe
> > > > > max_bus_speed > 5.0 GT/s. Root port takes ~16ms during resume.
> > > >
> > > > This patch reduces the delay by 100ms for devices that don't support
> > > > 5.0 GT/s.  Please include references to the specs about the
> > > > necessary delays and explain why we don't need this 100ms delay.
> > > >
> > > > Presumably there's something in the spec about needing extra delay
> > > > when supporting 5.0 GT/s.
> > > >
> > > > This is generic code, so we can't make changes based on specific
> > > > devices like Apollolake.  We have to make the code follow the spec
> > > > so it works for everybody.
> > > >
> > > > > With 100ms delay:
> > > > > [  155.102713] calling  :00:14.0+ @ 70, parent: pci:00, cb:
> > > > > pci_pm_resume_noirq [  155.119337] call :00:14.0+ returned 0
> > > > > after
> > > > > 16231 usecs [  155.119467] calling  :01:00.0+ @ 5845, parent:
> > > > > :00:14.0, cb: pci_pm_resume_noirq [  155.321670] call
> > > > > :00:14.0+ returned 0 after 185327 usecs [  155.321743] calling
> > > > > :01:00.0+ @ 5849, parent: :00:14.0, cb: pci_pm_resume
> > > > >
> > > > > With Condition check:
> > > > > [   36.624709] calling :00:14.0+ @ 4434, parent: pci:00, cb:
> > > > pci_pm_resume_noirq
> > > > > [   36.641367] call :00:14.0+ returned 0 after 16263 usecs
> > > > > [   36.652458] calling :00:14.0+ @ 4443, parent: pci:00, cb:
> > > > pci_pm_resume
> > > > > [   36.652673] call :00:14.0+ returned 0 after 208 usecs
> > > > > [   36.652863] calling  :01:00.0+ @ 4442, parent: :00:14.0, 
> > > > > cb:
> > > > pci_pm_resume
> > > > >
> > > > > Signed-off-by: Vaibhav Shankar 
> > > > > ---
> > > > > changes in v2:
> > > > > - Modify patch description.
> > > > > - Add condition check for 100ms delay before read pci conf as
> > > > >   suggested by Yinghai.
> > > > >
> > > > >  drivers/pci/hotplug/pciehp_hpc.c |   11 +--
> > > > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> > > > > b/drivers/pci/hotplug/pciehp_hpc.c
> > > > > index b57fc6d..2b10e5f 100644
> > > > > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > > > > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > > > > @@ -311,8 +311,15 @@ int pciehp_check_link_status(struct
> > > > > controller
> > > > *ctrl)
> > > > >   else
> > > > >   msleep(1000);
> > > > >
> > > > > - /* wait 100ms before read pci conf, and try in 1s */
> > > > > - msleep(100);
> > > > > + /*
> > > > > +  * If the port supports Link speeds greater than 5.0 GT/s, we
> > > > > +  * must wait for 100 ms after Link training completes before
> > > > > +  * sending configuration request.
> > > > > +  */
> > > > > + if (ctrl->pcie->port->subordinate->max_bus_speed >
> > > > PCIE_SPEED_5_0GT)
> > > > > + msleep(100);
> > > > > +
> > > > > + /* try in 1s */
> > > > >   found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
> > > > >   PCI_DEVFN(0, 0));
> > > > >
> > >
> > > Please find the details from regarding delays from PCIe spec 3.0:
> > >
> > > 1)  With a Downstream Port that does not support Link speeds greater
> > > than 5.0 GT/s, software  must wait a minimum of 100 ms before sending
> > > a Configuration Request to the device immediately below that Port.
> > >
> > > 2)  With a Downstream Port that supports Link speeds greater than 5.0
> > > GT/s, software must wait a minimum of 100 ms after Link training
> > > completes before sending a Configuration Request to the device
> > > immediately below that Port. Software can determine when Link training
> > > completes by polling the Data Link Layer Link Active bit or by setting up 
> > > an
> > associated interrupt (see Section 6.7.3.3).
> > >
> > > 3) A system must guarantee that all components intended to be software
> > > visible at boot time are ready to receive Configuration Requests
> > > within the applicable minimum period 

Re: [PATCH v2] PCI: pciehp: Optimize PCIe root resume time

[Lukas Wunner]

On Thu, Jan 19, 2017 at 02:57:26AM +, Shankar, Vaibhav wrote:
> > From: Lukas Wunner [mailto:lu...@wunner.de]
> > Sent: Tuesday, January 17, 2017 9:14 PM
> > On Wed, Jan 18, 2017 at 01:32:13AM +, Shankar, Vaibhav wrote:
> > > > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > > > Sent: Wednesday, January 11, 2017 10:37 AM On Mon, Dec 12, 2016 at
> > > > 04:32:25PM -0800, Vaibhav Shankar wrote:
> > > > > On Apollolake platforms, PCIe rootport takes a long time to resume
> > > > > from S3. With 100ms delay before read pci conf, rootport takes
> > > > > ~200ms during resume.
> > > > >
> > > > > commit 2f5d8e4ff947 ("PCI: pciehp: replace unconditional sleep
> > > > > with config space access check") is the one that added the 100ms
> > > > > delay before reading pci conf.
> > > > >
> > > > > This patch includes a condition check for 100ms dealy before
> > > > > reading PCIe conf. This delay in included only when PCIe
> > > > > max_bus_speed > 5.0 GT/s. Root port takes ~16ms during resume.
> > > >
> > > > This patch reduces the delay by 100ms for devices that don't support
> > > > 5.0 GT/s.  Please include references to the specs about the
> > > > necessary delays and explain why we don't need this 100ms delay.
> > > >
> > > > Presumably there's something in the spec about needing extra delay
> > > > when supporting 5.0 GT/s.
> > > >
> > > > This is generic code, so we can't make changes based on specific
> > > > devices like Apollolake.  We have to make the code follow the spec
> > > > so it works for everybody.
> > > >
> > > > > With 100ms delay:
> > > > > [  155.102713] calling  :00:14.0+ @ 70, parent: pci:00, cb:
> > > > > pci_pm_resume_noirq [  155.119337] call :00:14.0+ returned 0
> > > > > after
> > > > > 16231 usecs [  155.119467] calling  :01:00.0+ @ 5845, parent:
> > > > > :00:14.0, cb: pci_pm_resume_noirq [  155.321670] call
> > > > > :00:14.0+ returned 0 after 185327 usecs [  155.321743] calling
> > > > > :01:00.0+ @ 5849, parent: :00:14.0, cb: pci_pm_resume
> > > > >
> > > > > With Condition check:
> > > > > [   36.624709] calling :00:14.0+ @ 4434, parent: pci:00, cb:
> > > > pci_pm_resume_noirq
> > > > > [   36.641367] call :00:14.0+ returned 0 after 16263 usecs
> > > > > [   36.652458] calling :00:14.0+ @ 4443, parent: pci:00, cb:
> > > > pci_pm_resume
> > > > > [   36.652673] call :00:14.0+ returned 0 after 208 usecs
> > > > > [   36.652863] calling  :01:00.0+ @ 4442, parent: :00:14.0, 
> > > > > cb:
> > > > pci_pm_resume
> > > > >
> > > > > Signed-off-by: Vaibhav Shankar 
> > > > > ---
> > > > > changes in v2:
> > > > > - Modify patch description.
> > > > > - Add condition check for 100ms delay before read pci conf as
> > > > >   suggested by Yinghai.
> > > > >
> > > > >  drivers/pci/hotplug/pciehp_hpc.c |   11 +--
> > > > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> > > > > b/drivers/pci/hotplug/pciehp_hpc.c
> > > > > index b57fc6d..2b10e5f 100644
> > > > > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > > > > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > > > > @@ -311,8 +311,15 @@ int pciehp_check_link_status(struct
> > > > > controller
> > > > *ctrl)
> > > > >   else
> > > > >   msleep(1000);
> > > > >
> > > > > - /* wait 100ms before read pci conf, and try in 1s */
> > > > > - msleep(100);
> > > > > + /*
> > > > > +  * If the port supports Link speeds greater than 5.0 GT/s, we
> > > > > +  * must wait for 100 ms after Link training completes before
> > > > > +  * sending configuration request.
> > > > > +  */
> > > > > + if (ctrl->pcie->port->subordinate->max_bus_speed >
> > > > PCIE_SPEED_5_0GT)
> > > > > + msleep(100);
> > > > > +
> > > > > + /* try in 1s */
> > > > >   found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
> > > > >   PCI_DEVFN(0, 0));
> > > > >
> > >
> > > Please find the details from regarding delays from PCIe spec 3.0:
> > >
> > > 1)  With a Downstream Port that does not support Link speeds greater
> > > than 5.0 GT/s, software  must wait a minimum of 100 ms before sending
> > > a Configuration Request to the device immediately below that Port.
> > >
> > > 2)  With a Downstream Port that supports Link speeds greater than 5.0
> > > GT/s, software must wait a minimum of 100 ms after Link training
> > > completes before sending a Configuration Request to the device
> > > immediately below that Port. Software can determine when Link training
> > > completes by polling the Data Link Layer Link Active bit or by setting up 
> > > an
> > associated interrupt (see Section 6.7.3.3).
> > >
> > > 3) A system must guarantee that all components intended to be software
> > > visible at boot time are ready to receive Configuration Requests
> > > within the applicable minimum period based on the end of 

Re: [PATCH 00/33] Input: Automated coccinelle cleanup

[Joe Perches]

On Wed, 2017-01-18 at 21:04 -0800, Guenter Roeck wrote:
> On 01/18/2017 05:42 PM, Joe Perches wrote:
> > On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote:
> > > The conversion was done automatically with coccinelle using several 
> > > semantic
> > > patches. The semantic patches and the scripts used to generate this commit
> > > log are available at https://github.com/groeck/coccinelle-patches.
> > 
> > It'd be better to include the script in this 0/n patch
> > so that if github entry changes, the 0/n patch is useful.
> > 
> For this set it would have been possible, though even the rules used here add
> up to more than 1,000 lines.

How many errors do you think are in the script?
1000+ lines, likely there 10+ errors/defects.

Re: [PATCH 00/33] Input: Automated coccinelle cleanup

[Joe Perches]

On Wed, 2017-01-18 at 21:04 -0800, Guenter Roeck wrote:
> On 01/18/2017 05:42 PM, Joe Perches wrote:
> > On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote:
> > > The conversion was done automatically with coccinelle using several 
> > > semantic
> > > patches. The semantic patches and the scripts used to generate this commit
> > > log are available at https://github.com/groeck/coccinelle-patches.
> > 
> > It'd be better to include the script in this 0/n patch
> > so that if github entry changes, the 0/n patch is useful.
> > 
> For this set it would have been possible, though even the rules used here add
> up to more than 1,000 lines.

How many errors do you think are in the script?
1000+ lines, likely there 10+ errors/defects.

Re: [PATCH 00/33] Input: Automated coccinelle cleanup

[Guenter Roeck]

On 01/18/2017 05:42 PM, Joe Perches wrote:

On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote:

The conversion was done automatically with coccinelle using several semantic
patches. The semantic patches and the scripts used to generate this commit
log are available at https://github.com/groeck/coccinelle-patches.


It'd be better to include the script in this 0/n patch
so that if github entry changes, the 0/n patch is useful.



For this set it would have been possible, though even the rules used here add
up to more than 1,000 lines. The underlying larger set (the one I am using
to generate devm transformations) currently has ~5,000 lines of coccinelle 
rules.
Are you sure you want to see that in an e-mail ? It might make more sense if I
add the reference SHA from the repository.

Thanks,
Guenter

Re: [PATCH 00/33] Input: Automated coccinelle cleanup

[Guenter Roeck]

On 01/18/2017 05:42 PM, Joe Perches wrote:

On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote:

The conversion was done automatically with coccinelle using several semantic
patches. The semantic patches and the scripts used to generate this commit
log are available at https://github.com/groeck/coccinelle-patches.


It'd be better to include the script in this 0/n patch
so that if github entry changes, the 0/n patch is useful.



For this set it would have been possible, though even the rules used here add
up to more than 1,000 lines. The underlying larger set (the one I am using
to generate devm transformations) currently has ~5,000 lines of coccinelle 
rules.
Are you sure you want to see that in an e-mail ? It might make more sense if I
add the reference SHA from the repository.

Thanks,
Guenter

Re: [PATCH 2/5] dmaengine: Add support for custom data mapping

[Vinod Koul]

On Mon, Jan 02, 2017 at 10:12:33AM -0600, Andy Gross wrote:
> On Mon, Jan 02, 2017 at 07:55:37PM +0530, Abhishek Sahu wrote:
> > >>> So a couple of thoughts on how to deal with this:
> > >>>
> > >>> 1) Define a virtual channel for the command descriptors vs a normal 
> > >>> DMA
> > >>> transaction.  This lets you use the same hardware channel, but lets 
> > >>> you discern
> > >>> which descriptor format you need to use.  The only issue I see with 
> > >>> this is the
> > >>> required change in device tree binding to target the right type of 
> > >>> channel (cmd
> > >>> vs normal).
> > >>
> > >>Or mark the descriptor is cmd and write accordingly...
> > >
> > >The only issue i see with that is knowing how much to pre-allocate 
> > >during
> > >the
> > >prep call.  The flag set API would be called on the allocated tx
> > >descriptor.  So
> > >you'd have to know up front and be able to specify it.
> > >
> > >>
> > >>>
> > >>> 2) Provide an API to set flags for the descriptor on a whole 
> > >>> descriptor basis.
> > >>>
> > >>> 3) If you have a set of transactions described by an sgl that has 
> > >>> disparate use
> > >>> of flags, you split the list and use a separate transaction.  In 
> > >>> other words, we
> > >>> need to enforce that the flag set API will be applied to all 
> > >>> descriptors
> > >>> described by an sgl.  This means that the whole transaction may be 
> > >>> comprised of
> > >>> multiple async TX descriptors.
> > 
> > Each async TX descriptor will generate the BAM interrupt so we are
> > deviating
> > from main purpose of DMA where ideally we should get the interrupt at
> > the
> > end
> > of transfer. This is the main reason for going for this patch.
> > >>>
> > >>>If the client queues 1 descriptor or 5 descriptors, it doesn't matter 
> > >>>that
> > >>>much.
> > >>>The client knows when it is done by waiting for the descriptors to
> > >>>complete.  It
> > >>>is less efficient than grouping them all, but it should still work.
> > >>>
> > >>Yes. client will wait for final descriptor completion. But these
> > >>interrupts
> > >>will be overhead for CPU. For 1-2 page it won't matter much I guess it
> > >>will
> > >>be
> > >>significant for complete chip read/write(during boot and FS i.e JFFS
> > >>operations).
> > 
> > With the submitted patch, only 1 interrupt per channel is required for
> > complete NAND page and it solves the setting of BAM specific flags also.
> > Only issue with this patch is adding new API in DMA framework itself.
> > But
> > this API can be used by other DMA engines in future for which mapping
> > cannot
> > be done with available APIs and if this mapping is vendor specific.
> > >>>
> > >>>I guess the key point in all of this is that the DMA operation being done
> > >>>is not
> > >>>a normal data flow to/from the device.  It's direct remote register 
> > >>>access
> > >>>to
> > >>>the device using address information contained in the sgl.  And you are
> > >>>collating the standard data access along with the special command access
> > >>>in the
> > >>>same API call.
> > >>Yes. Normally DMA engine (QCA ADM DMA engine also) allows to read/write
> > >>memory mapped
> > >>registers just like data. But BAM is different (Since it is not a global
> > >>DMA
> > >>Engine
> > >>and coupled with peripheral). Also, this different flag requirement is
> > >>not
> > >>just
> > >>for command descriptors but for data descriptors also.
> > >>
> > >>BAM data access and command access differs only with flag and register
> > >>read/write
> > >>list. The register read and write list will be simply array of
> > >>struct bam_cmd_element added in patch
> > >>struct bam_cmd_element {
> > >>__le32 addr:24;
> > >>__le32 command:8;
> > >>__le32 data;
> > >>__le32 mask;
> > >>__le32 reserved;
> > >>};
> > >>
> > >>The address and size of the array will be passed in data and size field
> > >>of
> > >>SGL.
> > >>If we want to form the SGL for mentioned list then we will have SGL of
> > >>size
> > >>15
> > >>with just one descriptor.
> > >>
> > >>Now we require different flag for each SG entry. currently SG does not
> > >>have
> > >>flag parameter and we can't add flag parameter just for our requirement
> > >>in
> > >>generic SG. So we have added the custom mapping function and passed
> > >>modified
> > >>SG
> > >>as parameter which is generic SG and flag.
> > >
> > >I really think that we need some additional API that allows for the flag
> > >munging
> > >for the descriptors instead of overriding the prep_slave_sg.  We already
> > >needed
> > >to change the way the flags are passed anyway.  And instead of building up
> > >a
> > >special sg list, the API should take a structure that has a 1:1 mapping of
> > >the
> > >flags to the descriptors.  And you would 

Re: [PATCH 2/5] dmaengine: Add support for custom data mapping

[Vinod Koul]

On Mon, Jan 02, 2017 at 10:12:33AM -0600, Andy Gross wrote:
> On Mon, Jan 02, 2017 at 07:55:37PM +0530, Abhishek Sahu wrote:
> > >>> So a couple of thoughts on how to deal with this:
> > >>>
> > >>> 1) Define a virtual channel for the command descriptors vs a normal 
> > >>> DMA
> > >>> transaction.  This lets you use the same hardware channel, but lets 
> > >>> you discern
> > >>> which descriptor format you need to use.  The only issue I see with 
> > >>> this is the
> > >>> required change in device tree binding to target the right type of 
> > >>> channel (cmd
> > >>> vs normal).
> > >>
> > >>Or mark the descriptor is cmd and write accordingly...
> > >
> > >The only issue i see with that is knowing how much to pre-allocate 
> > >during
> > >the
> > >prep call.  The flag set API would be called on the allocated tx
> > >descriptor.  So
> > >you'd have to know up front and be able to specify it.
> > >
> > >>
> > >>>
> > >>> 2) Provide an API to set flags for the descriptor on a whole 
> > >>> descriptor basis.
> > >>>
> > >>> 3) If you have a set of transactions described by an sgl that has 
> > >>> disparate use
> > >>> of flags, you split the list and use a separate transaction.  In 
> > >>> other words, we
> > >>> need to enforce that the flag set API will be applied to all 
> > >>> descriptors
> > >>> described by an sgl.  This means that the whole transaction may be 
> > >>> comprised of
> > >>> multiple async TX descriptors.
> > 
> > Each async TX descriptor will generate the BAM interrupt so we are
> > deviating
> > from main purpose of DMA where ideally we should get the interrupt at
> > the
> > end
> > of transfer. This is the main reason for going for this patch.
> > >>>
> > >>>If the client queues 1 descriptor or 5 descriptors, it doesn't matter 
> > >>>that
> > >>>much.
> > >>>The client knows when it is done by waiting for the descriptors to
> > >>>complete.  It
> > >>>is less efficient than grouping them all, but it should still work.
> > >>>
> > >>Yes. client will wait for final descriptor completion. But these
> > >>interrupts
> > >>will be overhead for CPU. For 1-2 page it won't matter much I guess it
> > >>will
> > >>be
> > >>significant for complete chip read/write(during boot and FS i.e JFFS
> > >>operations).
> > 
> > With the submitted patch, only 1 interrupt per channel is required for
> > complete NAND page and it solves the setting of BAM specific flags also.
> > Only issue with this patch is adding new API in DMA framework itself.
> > But
> > this API can be used by other DMA engines in future for which mapping
> > cannot
> > be done with available APIs and if this mapping is vendor specific.
> > >>>
> > >>>I guess the key point in all of this is that the DMA operation being done
> > >>>is not
> > >>>a normal data flow to/from the device.  It's direct remote register 
> > >>>access
> > >>>to
> > >>>the device using address information contained in the sgl.  And you are
> > >>>collating the standard data access along with the special command access
> > >>>in the
> > >>>same API call.
> > >>Yes. Normally DMA engine (QCA ADM DMA engine also) allows to read/write
> > >>memory mapped
> > >>registers just like data. But BAM is different (Since it is not a global
> > >>DMA
> > >>Engine
> > >>and coupled with peripheral). Also, this different flag requirement is
> > >>not
> > >>just
> > >>for command descriptors but for data descriptors also.
> > >>
> > >>BAM data access and command access differs only with flag and register
> > >>read/write
> > >>list. The register read and write list will be simply array of
> > >>struct bam_cmd_element added in patch
> > >>struct bam_cmd_element {
> > >>__le32 addr:24;
> > >>__le32 command:8;
> > >>__le32 data;
> > >>__le32 mask;
> > >>__le32 reserved;
> > >>};
> > >>
> > >>The address and size of the array will be passed in data and size field
> > >>of
> > >>SGL.
> > >>If we want to form the SGL for mentioned list then we will have SGL of
> > >>size
> > >>15
> > >>with just one descriptor.
> > >>
> > >>Now we require different flag for each SG entry. currently SG does not
> > >>have
> > >>flag parameter and we can't add flag parameter just for our requirement
> > >>in
> > >>generic SG. So we have added the custom mapping function and passed
> > >>modified
> > >>SG
> > >>as parameter which is generic SG and flag.
> > >
> > >I really think that we need some additional API that allows for the flag
> > >munging
> > >for the descriptors instead of overriding the prep_slave_sg.  We already
> > >needed
> > >to change the way the flags are passed anyway.  And instead of building up
> > >a
> > >special sg list, the API should take a structure that has a 1:1 mapping of
> > >the
> > >flags to the descriptors.  And you would 

Re: [PATCH 13/33] Input: bfin_rotary - Use 'dev' instead of dereferencing it and other changes

[Joe Perches]

On Wed, 2017-01-18 at 12:35 -0800, Guenter Roeck wrote:
> On Wed, Jan 18, 2017 at 11:39:52AM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 18, 2017 at 09:46:34AM -0800, Guenter Roeck wrote:
[]
> > > diff --git a/drivers/input/misc/bfin_rotary.c 
> > > b/drivers/input/misc/bfin_rotary.c
[]
> > > @@ -141,25 +141,23 @@ static int bfin_rotary_probe(struct platform_device 
> > > *pdev)
> > >  
> > >   /* Basic validation */
> > >   if ((pdata->rotary_up_key && !pdata->rotary_down_key) ||
> > > - (!pdata->rotary_up_key && pdata->rotary_down_key)) {
> > > + (!pdata->rotary_up_key && pdata->rotary_down_key))

maybe just use ^ 

if (!pdata->rotary_up_key ^ !pdata->rotary_down_key)

Re: [PATCH 13/33] Input: bfin_rotary - Use 'dev' instead of dereferencing it and other changes

[Joe Perches]

On Wed, 2017-01-18 at 12:35 -0800, Guenter Roeck wrote:
> On Wed, Jan 18, 2017 at 11:39:52AM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 18, 2017 at 09:46:34AM -0800, Guenter Roeck wrote:
[]
> > > diff --git a/drivers/input/misc/bfin_rotary.c 
> > > b/drivers/input/misc/bfin_rotary.c
[]
> > > @@ -141,25 +141,23 @@ static int bfin_rotary_probe(struct platform_device 
> > > *pdev)
> > >  
> > >   /* Basic validation */
> > >   if ((pdata->rotary_up_key && !pdata->rotary_down_key) ||
> > > - (!pdata->rotary_up_key && pdata->rotary_down_key)) {
> > > + (!pdata->rotary_up_key && pdata->rotary_down_key))

maybe just use ^ 

if (!pdata->rotary_up_key ^ !pdata->rotary_down_key)

Re: [PATCH net-next] macb: Common code to enable ptp support for SAMA5Dx platforms.

[Harini Katakam]

On Wed, Jan 18, 2017 at 11:02 PM, Nicolas Ferre  wrote:
> Le 18/01/2017 à 09:57, Andrei Pistirica a écrit :
>> This patch does the following:
>> - add GEM-PTP interface
>> - registers and bitfields for TSU are named according to SAMA5Dx data sheet
>> - PTP support based on platform capability
>
> The $subject will certainly never match reality, sadly "enable ptp
> support for SAMA5Dx platforms". So, you'd better change it.
> (no "." at the end BTW).
>
>> Signed-off-by: Andrei Pistirica 
>> ---
>> This is just the common code for GEM-PTP support. Code is based on the 
>> comments
>> related to the following patch series:
>> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM.
>> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx 
>> platforms.
>>
>> Note: Patch on net-next: January 18.
>>
>> Rafal/Harini, you can continue the work for GME-GXL.

Thanks Andrei.


>
> Otherwise, I'm okay with the rest.
>
> I suggest to people that will keep the ball rolling on this topic to
> take advantage of the chunks of code that Andrei developed with the help
> of Richard and the best practices discussed. I think particularly, if it
> makes sense with HW, about:
> - gem_ptp_do_[rt]xstamp(bp, skb) dereference scheme
> - gem_ptp_adjfine() rationale
> - gem_get_ptp_peer() if needed
>

Sure, will patch on top of this.

Regards,
Harini

> Regards,
> --
> Nicolas Ferre

Re: [PATCH net-next] macb: Common code to enable ptp support for SAMA5Dx platforms.

[Harini Katakam]

On Wed, Jan 18, 2017 at 11:02 PM, Nicolas Ferre  wrote:
> Le 18/01/2017 à 09:57, Andrei Pistirica a écrit :
>> This patch does the following:
>> - add GEM-PTP interface
>> - registers and bitfields for TSU are named according to SAMA5Dx data sheet
>> - PTP support based on platform capability
>
> The $subject will certainly never match reality, sadly "enable ptp
> support for SAMA5Dx platforms". So, you'd better change it.
> (no "." at the end BTW).
>
>> Signed-off-by: Andrei Pistirica 
>> ---
>> This is just the common code for GEM-PTP support. Code is based on the 
>> comments
>> related to the following patch series:
>> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM.
>> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx 
>> platforms.
>>
>> Note: Patch on net-next: January 18.
>>
>> Rafal/Harini, you can continue the work for GME-GXL.

Thanks Andrei.


>
> Otherwise, I'm okay with the rest.
>
> I suggest to people that will keep the ball rolling on this topic to
> take advantage of the chunks of code that Andrei developed with the help
> of Richard and the best practices discussed. I think particularly, if it
> makes sense with HW, about:
> - gem_ptp_do_[rt]xstamp(bp, skb) dereference scheme
> - gem_ptp_adjfine() rationale
> - gem_get_ptp_peer() if needed
>

Sure, will patch on top of this.

Regards,
Harini

> Regards,
> --
> Nicolas Ferre

Re: [RFC PATCH v3] crypto: Add IV generation algorithms

[Binoy Jayan]

Hi Gilad,

On 18 January 2017 at 20:51, Gilad Ben-Yossef  wrote:
> I have some review comments and a bug report -

Thank you very much for testing this on ARM and for the comments.

> I'm pretty sure this needs to be
>
>  n2 = bio_segments(ctx->bio_out);

Yes you are right, that was a typo :)

>> +
>> +   rinfo.is_write = bio_data_dir(ctx->bio_in) == WRITE;
>
> Please consider wrapping the above boolean expression in parenthesis.

Well, I can do that to enhance the clarity.

>> +   rinfo.iv_sector = ctx->cc_sector;
>> +   rinfo.nents = nents;
>> +   rinfo.iv = iv;
>> +
>> +   skcipher_request_set_crypt(req, dmreq->sg_in, dmreq->sg_out,
>
> Also, where do the scatterlist src2 and dst2 that you use
> sg_set_page() get sg_init_table() called on?
> I couldn't figure it out...

Thank you pointing this out. I missed out to add sg_init_table(src2, 1)
and sg_init_table(dst2, 1), but sg_set_page is used in geniv_iter_block.
This is probably the reason for the panic on ARM platform. However it
ran fine under qemu-x86. May be I should setup an arm platform too
for testing.

Regards,
Binoy

Re: [RFC PATCH v3] crypto: Add IV generation algorithms

[Binoy Jayan]

Hi Gilad,

On 18 January 2017 at 20:51, Gilad Ben-Yossef  wrote:
> I have some review comments and a bug report -

Thank you very much for testing this on ARM and for the comments.

> I'm pretty sure this needs to be
>
>  n2 = bio_segments(ctx->bio_out);

Yes you are right, that was a typo :)

>> +
>> +   rinfo.is_write = bio_data_dir(ctx->bio_in) == WRITE;
>
> Please consider wrapping the above boolean expression in parenthesis.

Well, I can do that to enhance the clarity.

>> +   rinfo.iv_sector = ctx->cc_sector;
>> +   rinfo.nents = nents;
>> +   rinfo.iv = iv;
>> +
>> +   skcipher_request_set_crypt(req, dmreq->sg_in, dmreq->sg_out,
>
> Also, where do the scatterlist src2 and dst2 that you use
> sg_set_page() get sg_init_table() called on?
> I couldn't figure it out...

Thank you pointing this out. I missed out to add sg_init_table(src2, 1)
and sg_init_table(dst2, 1), but sg_set_page is used in geniv_iter_block.
This is probably the reason for the panic on ARM platform. However it
ran fine under qemu-x86. May be I should setup an arm platform too
for testing.

Regards,
Binoy

Re: [PATCH 4/6] PM / domain: Register for PM QOS performance notifier

[Viresh Kumar]

On 03-01-17, 16:36, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
> 
> This patch registers the power domain framework for PM QOS performance
> notifier in order to manage performance state of power domains.
> 
> This also allows the power domain drivers to implement a
> ->set_performance_state() callback, which will be called by the power
> domain core from the notifier routine.

Rajendra helped me testing this stuff on his Qualcomm board and this patch has
received some updates to support the hierarchy of power domains, i.e. subdomains
withing power domains. Below is the new patch which worked for him.

-- 
viresh

-8<-

From: Viresh Kumar 
Date: Wed, 23 Nov 2016 11:00:41 +0530
Subject: [PATCH] PM / domain: Register for PM QOS performance notifier

Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.

This patch registers the power domain framework for PM QOS performance
notifier in order to manage performance state of power domains.

This also allows the power domain drivers to implement a
->set_performance_state() callback, which will be called by the power
domain core from the notifier routine.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 99 -
 include/linux/pm_domain.h   |  5 +++
 2 files changed, 102 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 12f16d9b6b55..12ec1f8c42ed 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -367,6 +367,88 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block 
*nb,
return NOTIFY_DONE;
 }
 
+static void update_domain_performance_state(struct generic_pm_domain *genpd,
+   int depth)
+{
+   struct generic_pm_domain_data *pd_data;
+   struct generic_pm_domain *subdomain;
+   struct pm_domain_data *pdd;
+   unsigned int state = 0;
+   struct gpd_link *link;
+
+   /* Traverse all devices within the domain */
+   list_for_each_entry(pdd, >dev_list, list_node) {
+   pd_data = to_gpd_data(pdd);
+
+   if (pd_data->performance_state > state)
+   state = pd_data->performance_state;
+   }
+
+   /* Traverse all subdomains within the domain */
+   list_for_each_entry(link, >master_links, master_node) {
+   subdomain = link->slave;
+
+   if (subdomain->performance_state > state)
+   state = subdomain->performance_state;
+   }
+
+   if (genpd->performance_state == state)
+   return;
+
+   genpd->performance_state = state;
+
+   if (genpd->set_performance_state) {
+   genpd->set_performance_state(genpd, state);
+   return;
+   }
+
+   /* Propagate only if this domain has a single parent */
+   if (list_is_singular(>slave_links)) {
+   /* Performance levels are managed by parent power domain */
+
+   struct generic_pm_domain *master;
+
+   link = list_first_entry(>slave_links, struct gpd_link, 
slave_node);
+   master = link->master;
+
+   genpd_lock_nested(master, depth + 1);
+   update_domain_performance_state(master, depth + 1);
+   genpd_unlock(master);
+   }
+}
+
+static int genpd_dev_pm_qos_perf_notifier(struct notifier_block *nb,
+ unsigned long val, void *ptr)
+{
+   struct generic_pm_domain_data *gpd_data;
+   struct generic_pm_domain *genpd = ERR_PTR(-ENODATA);
+   struct pm_domain_data *pdd;
+   struct device *dev;
+
+   gpd_data = container_of(nb, struct generic_pm_domain_data, perf_nb);
+   dev = gpd_data->base.dev;
+
+   spin_lock_irq(>power.lock);
+
+   pdd = dev->power.subsys_data ?
+   dev->power.subsys_data->domain_data : NULL;
+
+   if (pdd && pdd->dev)
+   genpd = dev_to_genpd(dev);
+
+   spin_unlock_irq(>power.lock);
+
+   if (IS_ERR(genpd))
+   return NOTIFY_DONE;
+
+   genpd_lock(genpd);
+   gpd_data->performance_state = val;
+   update_domain_performance_state(genpd, 0);
+   genpd_unlock(genpd);
+
+   return NOTIFY_DONE;
+}
+
 /**
  * genpd_poweroff - Remove power from a given PM domain.
  * @genpd: PM domain to power down.
@@ -578,6 +660,7 @@ static int genpd_runtime_suspend(struct device *dev)
return 0;
 
genpd_lock(genpd);
+
genpd_poweroff(genpd, false);

Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones

[Kevin Hilman]

Andreas Färber  writes:

> Am 19.01.2017 um 01:20 schrieb Andreas Färber:
>> Hi,
>> 
>> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds these reserved zones.
>>>
>>> Without such reserved memory zones, running the following stress command :
>>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>>> multiple times:
>>>
>>> Could lead to the following kernel crashes :
>>> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf00 
>>> -- SError
>>> ...
>>> [   47.058536] Internal error: Attempting to execute userspace memory: 
>>> 860f [#3] PREEMPT SMP
>>> ...
>>> Instead of the OOM killer.
>>>
>> 
>> I miss a Fixes: or Cc: here for the backport you desired. To have it
>> fixed back to my very introduction:
>> 
>> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>> 
>> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
>> transition for 4.9 down to 4.6, which seems fairly straightforward.
>> 
>>> Signed-off-by: Neil Armstrong 
>>> ---
>>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++
>>>  1 file changed, 18 insertions(+)
>>>
>>> Changes since v4 at [5]:
>>> - Move start of ddr memory to reserved-memory node
>>> - Drop memory node move
>>> - Fix typo in sizes
>>>
>>> Changes since resent v2 at [4]:
>>> - Fix invalid comment of useable memory attributes
>>>
>>> Changes since original v2 at [3]:
>>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>>
>>> Changes since v2 at [2]:
>>> - Moved all memory node out of dtsi
>>> - Added comment about useable memory
>>> - Fixed comment about secmon reserved zone
>>>
>>> Changes since v1 at [1] :
>>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>>> - only kept secmon memory zone
>>>
>>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
>>> [2] 
>>> http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstr...@baylibre.com
>>> [3] 
>>> http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstr...@baylibre.com
>>> [4] 
>>> http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstr...@baylibre.com
>>> [5] 
>>> http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstr...@baylibre.com
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
>>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> index eada0b5..63d52b7 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> @@ -55,6 +55,24 @@
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>  
>>> +   reserved-memory {
>>> +   #address-cells = <2>;
>>> +   #size-cells = <2>;
>>> +   ranges;
>>> +
>>> +   /* 16 MiB reserved for Hardware ROM Firmware */
>>> +   hwrom: hwrom {
>> 
>> Both sub-nodes get a label that is unused, but reserved-memory itself
>> does not (my v4 remark). Intentional?
>> 
>>> +   reg = <0x0 0x0 0x0 0x100>;
>>> +   no-map;
>>> +   };
>>> +
>>> +   /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>>> +   secmon: secmon {
>> 
>> I note that this .dtsi further down has a node /firmware/secure-monitor
>> with label sm.
>> a) Is there any naming convention such as secmon_mem to adopt here to
>> avoid mixups with sm?
>> b) Should this secmon node be referenced in the secure-monitor node via
>> memory-node = <>; to model their connection, thereby giving the
>> label a use? Or should we maybe merge the two nodes by moving the
>> compatible string here?
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> Answering my own question: the example labels use _reserved suffix.
>
>>> +   reg = <0x0 0x1000 0x0 0x20>;
>
> And since we use a reg property here, the node name should get a unit
> address to avoid future dtc warnings/errors. Ditto for hwrom.

OK, I added Fixes:, your Reviewed-by, added the _reserved suffix and
unit address and applied to v4.10/fixes.

Update patch below for reference.

Other cleanups/fixups (like adding a phandle from secure monitor) can be
done as add-ons, as they are not strictly related to this fix.

Kevin

>From ecb88f3001ed9ee8c53450d971de8c18bcbf7925 Mon Sep 17 00:00:00 2001
From: Neil Armstrong 
Date: Wed, 18 Jan 2017 17:50:45 +0100
Subject: [PATCH] ARM64: dts: meson-gx: Add firmware reserved memory zones
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.

Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:

Could lead to the 

Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones

[Kevin Hilman]

Andreas Färber  writes:

> Am 19.01.2017 um 01:20 schrieb Andreas Färber:
>> Hi,
>> 
>> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds these reserved zones.
>>>
>>> Without such reserved memory zones, running the following stress command :
>>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>>> multiple times:
>>>
>>> Could lead to the following kernel crashes :
>>> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf00 
>>> -- SError
>>> ...
>>> [   47.058536] Internal error: Attempting to execute userspace memory: 
>>> 860f [#3] PREEMPT SMP
>>> ...
>>> Instead of the OOM killer.
>>>
>> 
>> I miss a Fixes: or Cc: here for the backport you desired. To have it
>> fixed back to my very introduction:
>> 
>> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>> 
>> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
>> transition for 4.9 down to 4.6, which seems fairly straightforward.
>> 
>>> Signed-off-by: Neil Armstrong 
>>> ---
>>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++
>>>  1 file changed, 18 insertions(+)
>>>
>>> Changes since v4 at [5]:
>>> - Move start of ddr memory to reserved-memory node
>>> - Drop memory node move
>>> - Fix typo in sizes
>>>
>>> Changes since resent v2 at [4]:
>>> - Fix invalid comment of useable memory attributes
>>>
>>> Changes since original v2 at [3]:
>>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>>
>>> Changes since v2 at [2]:
>>> - Moved all memory node out of dtsi
>>> - Added comment about useable memory
>>> - Fixed comment about secmon reserved zone
>>>
>>> Changes since v1 at [1] :
>>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>>> - only kept secmon memory zone
>>>
>>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
>>> [2] 
>>> http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstr...@baylibre.com
>>> [3] 
>>> http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstr...@baylibre.com
>>> [4] 
>>> http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstr...@baylibre.com
>>> [5] 
>>> http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstr...@baylibre.com
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
>>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> index eada0b5..63d52b7 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> @@ -55,6 +55,24 @@
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>  
>>> +   reserved-memory {
>>> +   #address-cells = <2>;
>>> +   #size-cells = <2>;
>>> +   ranges;
>>> +
>>> +   /* 16 MiB reserved for Hardware ROM Firmware */
>>> +   hwrom: hwrom {
>> 
>> Both sub-nodes get a label that is unused, but reserved-memory itself
>> does not (my v4 remark). Intentional?
>> 
>>> +   reg = <0x0 0x0 0x0 0x100>;
>>> +   no-map;
>>> +   };
>>> +
>>> +   /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>>> +   secmon: secmon {
>> 
>> I note that this .dtsi further down has a node /firmware/secure-monitor
>> with label sm.
>> a) Is there any naming convention such as secmon_mem to adopt here to
>> avoid mixups with sm?
>> b) Should this secmon node be referenced in the secure-monitor node via
>> memory-node = <>; to model their connection, thereby giving the
>> label a use? Or should we maybe merge the two nodes by moving the
>> compatible string here?
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> Answering my own question: the example labels use _reserved suffix.
>
>>> +   reg = <0x0 0x1000 0x0 0x20>;
>
> And since we use a reg property here, the node name should get a unit
> address to avoid future dtc warnings/errors. Ditto for hwrom.

OK, I added Fixes:, your Reviewed-by, added the _reserved suffix and
unit address and applied to v4.10/fixes.

Update patch below for reference.

Other cleanups/fixups (like adding a phandle from secure monitor) can be
done as add-ons, as they are not strictly related to this fix.

Kevin

>From ecb88f3001ed9ee8c53450d971de8c18bcbf7925 Mon Sep 17 00:00:00 2001
From: Neil Armstrong 
Date: Wed, 18 Jan 2017 17:50:45 +0100
Subject: [PATCH] ARM64: dts: meson-gx: Add firmware reserved memory zones
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.

Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:

Could lead to the following kernel crashes :
[   46.937975] Bad mode in Error handler 

Re: [PATCH 4/6] PM / domain: Register for PM QOS performance notifier

[Viresh Kumar]

On 03-01-17, 16:36, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
> 
> This patch registers the power domain framework for PM QOS performance
> notifier in order to manage performance state of power domains.
> 
> This also allows the power domain drivers to implement a
> ->set_performance_state() callback, which will be called by the power
> domain core from the notifier routine.

Rajendra helped me testing this stuff on his Qualcomm board and this patch has
received some updates to support the hierarchy of power domains, i.e. subdomains
withing power domains. Below is the new patch which worked for him.

-- 
viresh

-8<-

From: Viresh Kumar 
Date: Wed, 23 Nov 2016 11:00:41 +0530
Subject: [PATCH] PM / domain: Register for PM QOS performance notifier

Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.

This patch registers the power domain framework for PM QOS performance
notifier in order to manage performance state of power domains.

This also allows the power domain drivers to implement a
->set_performance_state() callback, which will be called by the power
domain core from the notifier routine.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 99 -
 include/linux/pm_domain.h   |  5 +++
 2 files changed, 102 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 12f16d9b6b55..12ec1f8c42ed 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -367,6 +367,88 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block 
*nb,
return NOTIFY_DONE;
 }
 
+static void update_domain_performance_state(struct generic_pm_domain *genpd,
+   int depth)
+{
+   struct generic_pm_domain_data *pd_data;
+   struct generic_pm_domain *subdomain;
+   struct pm_domain_data *pdd;
+   unsigned int state = 0;
+   struct gpd_link *link;
+
+   /* Traverse all devices within the domain */
+   list_for_each_entry(pdd, >dev_list, list_node) {
+   pd_data = to_gpd_data(pdd);
+
+   if (pd_data->performance_state > state)
+   state = pd_data->performance_state;
+   }
+
+   /* Traverse all subdomains within the domain */
+   list_for_each_entry(link, >master_links, master_node) {
+   subdomain = link->slave;
+
+   if (subdomain->performance_state > state)
+   state = subdomain->performance_state;
+   }
+
+   if (genpd->performance_state == state)
+   return;
+
+   genpd->performance_state = state;
+
+   if (genpd->set_performance_state) {
+   genpd->set_performance_state(genpd, state);
+   return;
+   }
+
+   /* Propagate only if this domain has a single parent */
+   if (list_is_singular(>slave_links)) {
+   /* Performance levels are managed by parent power domain */
+
+   struct generic_pm_domain *master;
+
+   link = list_first_entry(>slave_links, struct gpd_link, 
slave_node);
+   master = link->master;
+
+   genpd_lock_nested(master, depth + 1);
+   update_domain_performance_state(master, depth + 1);
+   genpd_unlock(master);
+   }
+}
+
+static int genpd_dev_pm_qos_perf_notifier(struct notifier_block *nb,
+ unsigned long val, void *ptr)
+{
+   struct generic_pm_domain_data *gpd_data;
+   struct generic_pm_domain *genpd = ERR_PTR(-ENODATA);
+   struct pm_domain_data *pdd;
+   struct device *dev;
+
+   gpd_data = container_of(nb, struct generic_pm_domain_data, perf_nb);
+   dev = gpd_data->base.dev;
+
+   spin_lock_irq(>power.lock);
+
+   pdd = dev->power.subsys_data ?
+   dev->power.subsys_data->domain_data : NULL;
+
+   if (pdd && pdd->dev)
+   genpd = dev_to_genpd(dev);
+
+   spin_unlock_irq(>power.lock);
+
+   if (IS_ERR(genpd))
+   return NOTIFY_DONE;
+
+   genpd_lock(genpd);
+   gpd_data->performance_state = val;
+   update_domain_performance_state(genpd, 0);
+   genpd_unlock(genpd);
+
+   return NOTIFY_DONE;
+}
+
 /**
  * genpd_poweroff - Remove power from a given PM domain.
  * @genpd: PM domain to power down.
@@ -578,6 +660,7 @@ static int genpd_runtime_suspend(struct device *dev)
return 0;
 
genpd_lock(genpd);
+
genpd_poweroff(genpd, false);
genpd_unlock(genpd);
 
@@ -1127,6 +1210,9 @@ static struct 

Re: linux-next: manual merge of the audit tree with Linus' tree

[Richard Guy Briggs]

On 2017-01-19 13:51, Stephen Rothwell wrote:
> Hi Paul,

Hi Stephen,

> Today's linux-next merge of the audit tree got a conflict in:
> 
>   include/uapi/linux/audit.h
> 
> between commits:
> 
>   7ff89ac608d9 ("audit: add exclude filter extension to feature bitmap")
>   dcdaa2f9480c ("Merge branch 'stable-4.10' of 
> git://git.infradead.org/users/pcmoore/audit")
> 
> from Linus' tree and commit:
> 
>   92c82e8a322b ("audit: add feature audit_lost reset")
> 
> from the audit tree.

This merge conflict was expected.

Your fix below looks as expected.

Thanks!  Sorry for the trouble.

> 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 include/uapi/linux/audit.h
> index 1c107cb1c83f,3f24110ae63c..
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@@ -330,13 -331,14 +331,16 @@@ enum 
>   #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT  0x0001
>   #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME  0x0002
>   #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH0x0004
>  +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x0008
>   #define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER   0x0010
> + #define AUDIT_FEATURE_BITMAP_LOST_RESET 0x0020
> + 
>   #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
>  +  AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
> -   AUDIT_FEATURE_BITMAP_SESSIONID_FILTER)
> +   AUDIT_FEATURE_BITMAP_SESSIONID_FILTER | \
> +   AUDIT_FEATURE_BITMAP_LOST_RESET)
>   
>   /* deprecated: AUDIT_VERSION_* */
>   #define AUDIT_VERSION_LATESTAUDIT_FEATURE_BITMAP_ALL

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: linux-next: manual merge of the audit tree with Linus' tree

[Richard Guy Briggs]

On 2017-01-19 13:51, Stephen Rothwell wrote:
> Hi Paul,

Hi Stephen,

> Today's linux-next merge of the audit tree got a conflict in:
> 
>   include/uapi/linux/audit.h
> 
> between commits:
> 
>   7ff89ac608d9 ("audit: add exclude filter extension to feature bitmap")
>   dcdaa2f9480c ("Merge branch 'stable-4.10' of 
> git://git.infradead.org/users/pcmoore/audit")
> 
> from Linus' tree and commit:
> 
>   92c82e8a322b ("audit: add feature audit_lost reset")
> 
> from the audit tree.

This merge conflict was expected.

Your fix below looks as expected.

Thanks!  Sorry for the trouble.

> 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 include/uapi/linux/audit.h
> index 1c107cb1c83f,3f24110ae63c..
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@@ -330,13 -331,14 +331,16 @@@ enum 
>   #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT  0x0001
>   #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME  0x0002
>   #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH0x0004
>  +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x0008
>   #define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER   0x0010
> + #define AUDIT_FEATURE_BITMAP_LOST_RESET 0x0020
> + 
>   #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
>  +  AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
> -   AUDIT_FEATURE_BITMAP_SESSIONID_FILTER)
> +   AUDIT_FEATURE_BITMAP_SESSIONID_FILTER | \
> +   AUDIT_FEATURE_BITMAP_LOST_RESET)
>   
>   /* deprecated: AUDIT_VERSION_* */
>   #define AUDIT_VERSION_LATESTAUDIT_FEATURE_BITMAP_ALL

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[PATCH v2] tools build: add tools tree support for 'make -s'

[Josh Poimboeuf]

When doing a kernel build with 'make -s', everything is silenced except
the objtool build.  That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
  tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
  recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
  the top-level Makefile.  This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
  recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
  copied from the top-level Makefile.  This silences all the object
  compile/link messages.

Reported-by: Peter Zijlstra 
Signed-off-by: Josh Poimboeuf 
---
v2:
- add 'ifndef' indent level and 'make-3.8x' comment in Makefile.include

 Makefile   |  6 --
 tools/build/Makefile.build | 10 ++
 tools/scripts/Makefile.include | 12 +++-
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 96e2352..b10e794 100644
--- a/Makefile
+++ b/Makefile
@@ -87,10 +87,12 @@ endif
 ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
   quiet=silent_
+  tools_silent=s
 endif
 else   # make-3.8x
 ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
+  tools_silent=-s
 endif
 endif
 
@@ -1607,11 +1609,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/ $*
 
 # Single targets
 # ---
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 99c0ccd..e279a71 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,6 +19,16 @@ else
   Q=@
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  quiet=silent_
+endif
+endif
+
 build-dir := $(srctree)/tools/build
 
 # Define $(fixdep) for dep-cmd function
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 8abbef1..19edc1a 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -46,6 +46,16 @@ else
 NO_SUBDIR = :
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  silent=1
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  silent=1
+endif
+endif
+
 #
 # Define a callable command for descending to a new directory
 #
@@ -58,7 +68,7 @@ descend = \
 QUIET_SUBDIR0  = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir
 QUIET_SUBDIR1  =
 
-ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifneq ($(silent),1)
   ifneq ($(V),1)
QUIET_CC   = @echo '  CC   '$@;
QUIET_CC_FPIC  = @echo '  CC FPIC  '$@;
-- 
2.7.4

[PATCH v2] tools build: add tools tree support for 'make -s'

[Josh Poimboeuf]

When doing a kernel build with 'make -s', everything is silenced except
the objtool build.  That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
  tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
  recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
  the top-level Makefile.  This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
  recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
  copied from the top-level Makefile.  This silences all the object
  compile/link messages.

Reported-by: Peter Zijlstra 
Signed-off-by: Josh Poimboeuf 
---
v2:
- add 'ifndef' indent level and 'make-3.8x' comment in Makefile.include

 Makefile   |  6 --
 tools/build/Makefile.build | 10 ++
 tools/scripts/Makefile.include | 12 +++-
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 96e2352..b10e794 100644
--- a/Makefile
+++ b/Makefile
@@ -87,10 +87,12 @@ endif
 ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
   quiet=silent_
+  tools_silent=s
 endif
 else   # make-3.8x
 ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
+  tools_silent=-s
 endif
 endif
 
@@ -1607,11 +1609,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/ $*
 
 # Single targets
 # ---
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 99c0ccd..e279a71 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,6 +19,16 @@ else
   Q=@
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  quiet=silent_
+endif
+endif
+
 build-dir := $(srctree)/tools/build
 
 # Define $(fixdep) for dep-cmd function
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 8abbef1..19edc1a 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -46,6 +46,16 @@ else
 NO_SUBDIR = :
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  silent=1
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  silent=1
+endif
+endif
+
 #
 # Define a callable command for descending to a new directory
 #
@@ -58,7 +68,7 @@ descend = \
 QUIET_SUBDIR0  = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir
 QUIET_SUBDIR1  =
 
-ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifneq ($(silent),1)
   ifneq ($(V),1)
QUIET_CC   = @echo '  CC   '$@;
QUIET_CC_FPIC  = @echo '  CC FPIC  '$@;
-- 
2.7.4

linux-next: build failure after merge of the rcu tree

[Stephen Rothwell]

Hi Paul,

After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a 
function)
  .slab_flags = SLAB_DESTROY_BY_RCU,
^

Caused by commit

  c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  ac7138746e14 ("smc: establish new socket family")

from the net-next tree.

I have applied the following merge fix patch (someone will need to
remember to mention this to Linus):

From: Stephen Rothwell 
Date: Thu, 19 Jan 2017 14:29:12 +1100
Subject: [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to 
SLAB_TYPESAFE_BY_RCU"

Signed-off-by: Stephen Rothwell 
---
 net/smc/af_smc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 4875e65f0c4a..a48260f9ebb7 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -99,7 +99,7 @@ struct proto smc_proto = {
.unhash = smc_unhash_sk,
.obj_size   = sizeof(struct smc_sock),
.h.smc_hash = _v4_hashinfo,
-   .slab_flags = SLAB_DESTROY_BY_RCU,
+   .slab_flags = SLAB_TYPESAFE_BY_RCU,
 };
 EXPORT_SYMBOL_GPL(smc_proto);
 
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the rcu tree

[Stephen Rothwell]

Hi Paul,

After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a 
function)
  .slab_flags = SLAB_DESTROY_BY_RCU,
^

Caused by commit

  c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

interacting with commit

  ac7138746e14 ("smc: establish new socket family")

from the net-next tree.

I have applied the following merge fix patch (someone will need to
remember to mention this to Linus):

From: Stephen Rothwell 
Date: Thu, 19 Jan 2017 14:29:12 +1100
Subject: [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to 
SLAB_TYPESAFE_BY_RCU"

Signed-off-by: Stephen Rothwell 
---
 net/smc/af_smc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 4875e65f0c4a..a48260f9ebb7 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -99,7 +99,7 @@ struct proto smc_proto = {
.unhash = smc_unhash_sk,
.obj_size   = sizeof(struct smc_sock),
.h.smc_hash = _v4_hashinfo,
-   .slab_flags = SLAB_DESTROY_BY_RCU,
+   .slab_flags = SLAB_TYPESAFE_BY_RCU,
 };
 EXPORT_SYMBOL_GPL(smc_proto);
 
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

[PATCH] arm64: dts: msm8996: Add ADSP PIL node

[Sarangdhar Joshi]

Add ADSP node required for Qualcomm ADSP Peripheral Image Loader.

Signed-off-by: Sarangdhar Joshi 
---

This patch uses "xo_board" clock for now. We would have to move to
rpmcc once it is available.

 arch/arm64/boot/dts/qcom/msm8996.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index c9c7fd7..7cebf63 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -181,6 +181,26 @@
method = "smc";
};
 
+   adsp-pil {
+   compatible = "qcom,msm8996-adsp-pil";
+
+   interrupts-extended = < 0 162 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_region>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+   };
+
adsp-smp2p {
compatible = "qcom,smp2p";
qcom,smem = <443>, <429>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 08/33] Input: spear-keyboard - Drop unnecessary error messages and other changes

[Viresh Kumar]

On Wed, Jan 18, 2017 at 11:16 PM, Guenter Roeck  wrote:
> Error messages after memory allocation failures are unnecessary and
> can be dropped.
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Drop unnecessary braces around conditional return statements
> - Drop error message after devm_kzalloc() failure
>
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/input/keyboard/spear-keyboard.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Acked-by: Viresh Kumar 

[PATCH] arm64: dts: msm8996: Add ADSP PIL node

[Sarangdhar Joshi]

Add ADSP node required for Qualcomm ADSP Peripheral Image Loader.

Signed-off-by: Sarangdhar Joshi 
---

This patch uses "xo_board" clock for now. We would have to move to
rpmcc once it is available.

 arch/arm64/boot/dts/qcom/msm8996.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index c9c7fd7..7cebf63 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -181,6 +181,26 @@
method = "smc";
};
 
+   adsp-pil {
+   compatible = "qcom,msm8996-adsp-pil";
+
+   interrupts-extended = < 0 162 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_region>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+   };
+
adsp-smp2p {
compatible = "qcom,smp2p";
qcom,smem = <443>, <429>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 08/33] Input: spear-keyboard - Drop unnecessary error messages and other changes

[Viresh Kumar]

On Wed, Jan 18, 2017 at 11:16 PM, Guenter Roeck  wrote:
> Error messages after memory allocation failures are unnecessary and
> can be dropped.
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Drop unnecessary braces around conditional return statements
> - Drop error message after devm_kzalloc() failure
>
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/input/keyboard/spear-keyboard.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Acked-by: Viresh Kumar 

Re: [PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC

[Christian Kujau]

On Mon, 16 Jan 2017, Christophe Leroy wrote:
>  Christian, can you test it ?

OK, so with that applied to v4.10-rc4, compilation still fails with GCC 
4.9.2 and CC_STACKPROTECTOR_STRONG=y, see below. But it compiles just fine 
with CC_STACKPROTECTOR_REGULAR=y and boots to!

Cross-compiling the same with GCC 5.2.0 works, even for 
CC_STACKPROTECTOR_STRONG=y and the system boots just fine.

So, with that limitation, feel free to add:

 Tested-by: Christian Kujau 


Thanks for the fix!
Christian.



$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-10) 4.9.2

$ grep CC_STACKPROTECTOR_STRONG $DIR/.config
CONFIG_CC_STACKPROTECTOR_STRONG=y

$ make O=$DIR V=1 bindeb-pkg
[...]
+ ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T 
./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o 
arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o 
arch/powerpc/kernel/prom_init.o init/built-in.o --start-group 
usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o 
arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o 
arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o 
arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o 
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o 
ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o 
lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o 
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
arch/powerpc/platforms/built-in.o: In function `bootx_printf':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: 
undefined reference to `__stack_chk_fail_local' 
arch/powerpc/platforms/built-in.o: In function `bootx_scan_dt_build_struct':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_init':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: 
undefined reference to `__stack_chk_fail_local'
/usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' 
isn't defined
/usr/bin/ld.bfd.real: final link failed: Bad value

-- 
BOFH excuse #66:

bit bucket overflow

Re: [PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC

[Christian Kujau]

On Mon, 16 Jan 2017, Christophe Leroy wrote:
>  Christian, can you test it ?

OK, so with that applied to v4.10-rc4, compilation still fails with GCC 
4.9.2 and CC_STACKPROTECTOR_STRONG=y, see below. But it compiles just fine 
with CC_STACKPROTECTOR_REGULAR=y and boots to!

Cross-compiling the same with GCC 5.2.0 works, even for 
CC_STACKPROTECTOR_STRONG=y and the system boots just fine.

So, with that limitation, feel free to add:

 Tested-by: Christian Kujau 


Thanks for the fix!
Christian.



$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-10) 4.9.2

$ grep CC_STACKPROTECTOR_STRONG $DIR/.config
CONFIG_CC_STACKPROTECTOR_STRONG=y

$ make O=$DIR V=1 bindeb-pkg
[...]
+ ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T 
./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o 
arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o 
arch/powerpc/kernel/prom_init.o init/built-in.o --start-group 
usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o 
arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o 
arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o 
arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o 
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o 
ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o 
lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o 
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
arch/powerpc/platforms/built-in.o: In function `bootx_printf':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: 
undefined reference to `__stack_chk_fail_local' 
arch/powerpc/platforms/built-in.o: In function `bootx_scan_dt_build_struct':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_init':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: 
undefined reference to `__stack_chk_fail_local'
/usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' 
isn't defined
/usr/bin/ld.bfd.real: final link failed: Bad value

-- 
BOFH excuse #66:

bit bucket overflow

[PATCH] tools build: add tools tree support for 'make -s'

[Josh Poimboeuf]

When doing a kernel build with 'make -s', everything is silenced except
the objtool build.  That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
  tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
  recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
  the top-level Makefile.  This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
  recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
  copied from the top-level Makefile.  This silences all the object
  compile/link messages.

Reported-by: Peter Zijlstra 
Signed-off-by: Josh Poimboeuf 
---
 Makefile   |  6 --
 tools/build/Makefile.build | 10 ++
 tools/scripts/Makefile.include | 12 +++-
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 96e2352..b10e794 100644
--- a/Makefile
+++ b/Makefile
@@ -87,10 +87,12 @@ endif
 ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
   quiet=silent_
+  tools_silent=s
 endif
 else   # make-3.8x
 ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
+  tools_silent=-s
 endif
 endif
 
@@ -1607,11 +1609,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/ $*
 
 # Single targets
 # ---
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 99c0ccd..e279a71 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,6 +19,16 @@ else
   Q=@
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  quiet=silent_
+endif
+endif
+
 build-dir := $(srctree)/tools/build
 
 # Define $(fixdep) for dep-cmd function
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 8abbef1..08f81f4 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -46,6 +46,16 @@ else
 NO_SUBDIR = :
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+silent=1
+endif
+else
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+silent=1
+endif
+endif
+
 #
 # Define a callable command for descending to a new directory
 #
@@ -58,7 +68,7 @@ descend = \
 QUIET_SUBDIR0  = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir
 QUIET_SUBDIR1  =
 
-ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifneq ($(silent),1)
   ifneq ($(V),1)
QUIET_CC   = @echo '  CC   '$@;
QUIET_CC_FPIC  = @echo '  CC FPIC  '$@;
-- 
2.7.4

Re: [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

[Chris Packham]

On 19/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..59be3ca0464f 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops 
>> __initconst = {
>>
>>  CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>>_xp_smp_ops);
>> +
>> +struct resume_controller {
>> +u32 resume_control;
>> +u32 resume_boot_addr;
>> +};
>> +
>> +static const struct resume_controller mv98dx3336_resume_controller = {
>> +.resume_control = 0x08,
>> +.resume_boot_addr = 0x04,
>> +};
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> +{
>> +.compatible = "marvell,98dx3336-resume-ctrl",
>> +.data = (void *)_resume_controller,
>
> Useless cast?
>
>> +},
>> +{ /* end of list */ },
>> +};
>> +
>> +static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> +const struct of_device_id *match;
>> +struct device_node *np;
>> +void __iomem *base;
>> +struct resume_controller *rc;
>> +
>> +WARN_ON(hw_cpu != 1);
>> +
>> +np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
>> + );
>> +if (!np)
>> +return -ENODEV;
>> +
>> +base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> +rc = (struct resume_controller *)match->data;
>
> Useless cast?
>
>> +of_node_put(np);
>> +if (IS_ERR(base))
>> +return PTR_ERR(base);
>> +
>> +writel(0, base + rc->resume_control);
>> +writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
>> +
>
> Otherwise
>
> Reviewed-by: Stephen Boyd 
>

Thanks for the review. Changes will be in v5.

[PATCH] tools build: add tools tree support for 'make -s'

[Josh Poimboeuf]

When doing a kernel build with 'make -s', everything is silenced except
the objtool build.  That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
  tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
  recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
  the top-level Makefile.  This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
  recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
  copied from the top-level Makefile.  This silences all the object
  compile/link messages.

Reported-by: Peter Zijlstra 
Signed-off-by: Josh Poimboeuf 
---
 Makefile   |  6 --
 tools/build/Makefile.build | 10 ++
 tools/scripts/Makefile.include | 12 +++-
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 96e2352..b10e794 100644
--- a/Makefile
+++ b/Makefile
@@ -87,10 +87,12 @@ endif
 ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
   quiet=silent_
+  tools_silent=s
 endif
 else   # make-3.8x
 ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
+  tools_silent=-s
 endif
 endif
 
@@ -1607,11 +1609,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% 
-j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C 
$(src)/tools/ $*
 
 # Single targets
 # ---
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 99c0ccd..e279a71 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,6 +19,16 @@ else
   Q=@
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+else   # make-3.8x
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+  quiet=silent_
+endif
+endif
+
 build-dir := $(srctree)/tools/build
 
 # Define $(fixdep) for dep-cmd function
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 8abbef1..08f81f4 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -46,6 +46,16 @@ else
 NO_SUBDIR = :
 endif
 
+ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
+ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+silent=1
+endif
+else
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
+silent=1
+endif
+endif
+
 #
 # Define a callable command for descending to a new directory
 #
@@ -58,7 +68,7 @@ descend = \
 QUIET_SUBDIR0  = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir
 QUIET_SUBDIR1  =
 
-ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifneq ($(silent),1)
   ifneq ($(V),1)
QUIET_CC   = @echo '  CC   '$@;
QUIET_CC_FPIC  = @echo '  CC FPIC  '$@;
-- 
2.7.4

Re: [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

[Chris Packham]

On 19/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..59be3ca0464f 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops 
>> __initconst = {
>>
>>  CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>>_xp_smp_ops);
>> +
>> +struct resume_controller {
>> +u32 resume_control;
>> +u32 resume_boot_addr;
>> +};
>> +
>> +static const struct resume_controller mv98dx3336_resume_controller = {
>> +.resume_control = 0x08,
>> +.resume_boot_addr = 0x04,
>> +};
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> +{
>> +.compatible = "marvell,98dx3336-resume-ctrl",
>> +.data = (void *)_resume_controller,
>
> Useless cast?
>
>> +},
>> +{ /* end of list */ },
>> +};
>> +
>> +static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> +const struct of_device_id *match;
>> +struct device_node *np;
>> +void __iomem *base;
>> +struct resume_controller *rc;
>> +
>> +WARN_ON(hw_cpu != 1);
>> +
>> +np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
>> + );
>> +if (!np)
>> +return -ENODEV;
>> +
>> +base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> +rc = (struct resume_controller *)match->data;
>
> Useless cast?
>
>> +of_node_put(np);
>> +if (IS_ERR(base))
>> +return PTR_ERR(base);
>> +
>> +writel(0, base + rc->resume_control);
>> +writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
>> +
>
> Otherwise
>
> Reviewed-by: Stephen Boyd 
>

Thanks for the review. Changes will be in v5.