Re: [PATCH] f2fs: add new wraper function for reading inline data

[Shawn Lin]

On 2016/2/19 15:35, Chao Yu wrote:

Hi Shawn,


-Original Message-
From: Shawn Lin [mailto:shawn@rock-chips.com]
Sent: Friday, February 19, 2016 10:50 AM
To: Jaegeuk Kim; Changman Lee
Cc: Chao Yu; linux-f2fs-de...@lists.sourceforge.net; 
linux-kernel@vger.kernel.org; Shawn Lin
Subject: [PATCH] f2fs: add new wraper function for reading inline data

This patch add __read_inline_data which will no check
PageUptodate and page->index. This can be reused by
f2fs_convert_inline_page to reduce the redundant code
copied from read_inline_data.

Signed-off-by: Shawn Lin 
---

  fs/f2fs/inline.c | 26 --
  1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index d27347e..39eeff1 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -42,15 +42,11 @@ bool f2fs_may_inline_dentry(struct inode *inode)
return true;
  }

-void read_inline_data(struct page *page, struct page *ipage)
+static inline void __read_inline_data(struct page *page,
+ struct page *ipage)
  {
void *src_addr, *dst_addr;

-   if (PageUptodate(page))
-   return;
-
-   f2fs_bug_on(F2FS_P_SB(page), page->index);
-
zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);

/* Copy the whole inline data block */
@@ -61,6 +57,15 @@ void read_inline_data(struct page *page, struct page *ipage)
kunmap_atomic(dst_addr);
SetPageUptodate(page);
  }
+void read_inline_data(struct page *page, struct page *ipage)
+{
+   if (PageUptodate(page))
+   return;
+
+   f2fs_bug_on(F2FS_P_SB(page), page->index);
+
+   __read_inline_data(page, ipage);
+}

  bool truncate_inline_inode(struct page *ipage, u64 from)
  {
@@ -128,15 +133,8 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, 
struct page *page)
if (PageUptodate(page))
goto no_update;


Seems we can remove above check and below 'no_update' tag completely
if we use read_inline_data here.

So what about using read_inline_data to clean up codes in
f2fs_convert_inline_page?


yep, it does make sense. I will respin v2 to the list later.
Thanks for sharing your thought.



Thanks,



-   zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);
+   __read_inline_data(page, dn->inode_page);

-   /* Copy the whole inline data block */
-   src_addr = inline_data_addr(dn->inode_page);
-   dst_addr = kmap_atomic(page);
-   memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
-   flush_dcache_page(page);
-   kunmap_atomic(dst_addr);
-   SetPageUptodate(page);
  no_update:
set_page_dirty(page);

--
2.3.7










--
Best Regards
Shawn Lin

Re: [PATCH] f2fs: add new wraper function for reading inline data

[Shawn Lin]

On 2016/2/19 15:35, Chao Yu wrote:

Hi Shawn,


-Original Message-
From: Shawn Lin [mailto:shawn@rock-chips.com]
Sent: Friday, February 19, 2016 10:50 AM
To: Jaegeuk Kim; Changman Lee
Cc: Chao Yu; linux-f2fs-de...@lists.sourceforge.net; 
linux-kernel@vger.kernel.org; Shawn Lin
Subject: [PATCH] f2fs: add new wraper function for reading inline data

This patch add __read_inline_data which will no check
PageUptodate and page->index. This can be reused by
f2fs_convert_inline_page to reduce the redundant code
copied from read_inline_data.

Signed-off-by: Shawn Lin 
---

  fs/f2fs/inline.c | 26 --
  1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index d27347e..39eeff1 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -42,15 +42,11 @@ bool f2fs_may_inline_dentry(struct inode *inode)
return true;
  }

-void read_inline_data(struct page *page, struct page *ipage)
+static inline void __read_inline_data(struct page *page,
+ struct page *ipage)
  {
void *src_addr, *dst_addr;

-   if (PageUptodate(page))
-   return;
-
-   f2fs_bug_on(F2FS_P_SB(page), page->index);
-
zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);

/* Copy the whole inline data block */
@@ -61,6 +57,15 @@ void read_inline_data(struct page *page, struct page *ipage)
kunmap_atomic(dst_addr);
SetPageUptodate(page);
  }
+void read_inline_data(struct page *page, struct page *ipage)
+{
+   if (PageUptodate(page))
+   return;
+
+   f2fs_bug_on(F2FS_P_SB(page), page->index);
+
+   __read_inline_data(page, ipage);
+}

  bool truncate_inline_inode(struct page *ipage, u64 from)
  {
@@ -128,15 +133,8 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, 
struct page *page)
if (PageUptodate(page))
goto no_update;


Seems we can remove above check and below 'no_update' tag completely
if we use read_inline_data here.

So what about using read_inline_data to clean up codes in
f2fs_convert_inline_page?


yep, it does make sense. I will respin v2 to the list later.
Thanks for sharing your thought.



Thanks,



-   zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);
+   __read_inline_data(page, dn->inode_page);

-   /* Copy the whole inline data block */
-   src_addr = inline_data_addr(dn->inode_page);
-   dst_addr = kmap_atomic(page);
-   memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
-   flush_dcache_page(page);
-   kunmap_atomic(dst_addr);
-   SetPageUptodate(page);
  no_update:
set_page_dirty(page);

--
2.3.7










--
Best Regards
Shawn Lin

Re: [PATCH] b43: fix memory leak

[Kalle Valo]

Michael Büsch  writes:

> On Thu, 18 Feb 2016 18:04:36 +0530
> Sudip Mukherjee  wrote:
>
>> From: Sudip Mukherjee 
>> 
>> On error we jumped to the label bcma_out and returned the error code but
>> we missed freeing dev.
>> 
>> Signed-off-by: Sudip Mukherjee 
>> ---
>>  drivers/net/wireless/broadcom/b43/main.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/net/wireless/broadcom/b43/main.c 
>> b/drivers/net/wireless/broadcom/b43/main.c
>> index c279211..78f670a 100644
>> --- a/drivers/net/wireless/broadcom/b43/main.c
>> +++ b/drivers/net/wireless/broadcom/b43/main.c
>> @@ -5671,6 +5671,7 @@ static int b43_bcma_probe(struct bcma_device *core)
>>  wl = b43_wireless_init(dev);
>>  if (IS_ERR(wl)) {
>>  err = PTR_ERR(wl);
>> +kfree(dev);
>>  goto bcma_out;
>>  }
>>  
>
> We recently had a patch that fixes this, among more leaks. Subject:
> [PATCH v2 resend] b43: Fix memory leaks in b43_bus_dev_ssb_init and
> b43_bus_dev_bcma_init
>
> Please test that patch instead, so we can finally apply it.
>
> It needs to be tested on both ssb and bcma. Come on. This isn't too
> hard. :) Please somebody with any hardware test it. (I currently don't
> have any b43 hardware)

And the patch can be downloaded from patchwork:

https://patchwork.kernel.org/patch/8049041/

-- 
Kalle Valo

Re: [PATCH] b43: fix memory leak

[Kalle Valo]

Michael Büsch  writes:

> On Thu, 18 Feb 2016 18:04:36 +0530
> Sudip Mukherjee  wrote:
>
>> From: Sudip Mukherjee 
>> 
>> On error we jumped to the label bcma_out and returned the error code but
>> we missed freeing dev.
>> 
>> Signed-off-by: Sudip Mukherjee 
>> ---
>>  drivers/net/wireless/broadcom/b43/main.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/net/wireless/broadcom/b43/main.c 
>> b/drivers/net/wireless/broadcom/b43/main.c
>> index c279211..78f670a 100644
>> --- a/drivers/net/wireless/broadcom/b43/main.c
>> +++ b/drivers/net/wireless/broadcom/b43/main.c
>> @@ -5671,6 +5671,7 @@ static int b43_bcma_probe(struct bcma_device *core)
>>  wl = b43_wireless_init(dev);
>>  if (IS_ERR(wl)) {
>>  err = PTR_ERR(wl);
>> +kfree(dev);
>>  goto bcma_out;
>>  }
>>  
>
> We recently had a patch that fixes this, among more leaks. Subject:
> [PATCH v2 resend] b43: Fix memory leaks in b43_bus_dev_ssb_init and
> b43_bus_dev_bcma_init
>
> Please test that patch instead, so we can finally apply it.
>
> It needs to be tested on both ssb and bcma. Come on. This isn't too
> hard. :) Please somebody with any hardware test it. (I currently don't
> have any b43 hardware)

And the patch can be downloaded from patchwork:

https://patchwork.kernel.org/patch/8049041/

-- 
Kalle Valo

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Krzysztof Kozlowski]

On 19.02.2016 15:51, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 19 February 2016 at 11:39, Krzysztof Kozlowski
>  wrote:
>> 2016-02-19 4:14 GMT+09:00 Anand Moon :
>>> Hi Peter,
>>>
>>> On 18 February 2016 at 23:18, Peter Hurley  wrote:
 Hi Anand,

 On 02/18/2016 09:40 AM, Anand Moon wrote:
> From: Anand Moon 
>
> changes fix the correct order of the spin_lock_irqrestore/save.
>
> Signed-off-by: Anand Moon 
> ---
>  drivers/tty/serial/samsung.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index d72cd73..96fe14d 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, 
> void *id)
>   }
>
>   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
> - spin_unlock(>lock);
> + spin_unlock_irqrestore(>lock, flags);
>   uart_write_wakeup(port);
> - spin_lock(>lock);
> + spin_lock_irqsave(>lock, flags);

 This driver shouldn't be dropping the spin lock at for write wakeup.
 If this is causing lock-ups in a line discipline, the line discipline
 needs fixed.

>>>
>>> Thanks for pointing out.
>>> Their is no lock up, just the inconstancy of the spin_lock.
>>> Then I will resend this patch dropping the spin_unlock/spin_lock
>>> around uart_write_wakeup.
>>> Is that ok with you.
>>
>> Anand, before doing that, can you check Peter's second sentence? I
>> mean the "If this is causing lock-ups in a line discipline, the line
>> discipline needs fixed.".
>> Don't drop the spin-locks "just because". I would be happy to see more
>> detailed explanation in changelog.
>>
>> Best regards,
>> Krzysztof
> 
> Yes I understood the meaning of the sentence. Already the
> s3c24xx_serial_tx_chars function.
> holds the lock port->lock for safe IRQ execution.

I am sorry but I don't get your explanation. I mentioned Peter's
thoughts about lockups after adding locking over uart_write(). However
you are referring to s3c24xx_serial_tx_chars() holding the spin lock...
I am missing the point...

Best regards,
Krzysztof

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Krzysztof Kozlowski]

On 19.02.2016 15:51, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 19 February 2016 at 11:39, Krzysztof Kozlowski
>  wrote:
>> 2016-02-19 4:14 GMT+09:00 Anand Moon :
>>> Hi Peter,
>>>
>>> On 18 February 2016 at 23:18, Peter Hurley  wrote:
 Hi Anand,

 On 02/18/2016 09:40 AM, Anand Moon wrote:
> From: Anand Moon 
>
> changes fix the correct order of the spin_lock_irqrestore/save.
>
> Signed-off-by: Anand Moon 
> ---
>  drivers/tty/serial/samsung.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index d72cd73..96fe14d 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, 
> void *id)
>   }
>
>   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
> - spin_unlock(>lock);
> + spin_unlock_irqrestore(>lock, flags);
>   uart_write_wakeup(port);
> - spin_lock(>lock);
> + spin_lock_irqsave(>lock, flags);

 This driver shouldn't be dropping the spin lock at for write wakeup.
 If this is causing lock-ups in a line discipline, the line discipline
 needs fixed.

>>>
>>> Thanks for pointing out.
>>> Their is no lock up, just the inconstancy of the spin_lock.
>>> Then I will resend this patch dropping the spin_unlock/spin_lock
>>> around uart_write_wakeup.
>>> Is that ok with you.
>>
>> Anand, before doing that, can you check Peter's second sentence? I
>> mean the "If this is causing lock-ups in a line discipline, the line
>> discipline needs fixed.".
>> Don't drop the spin-locks "just because". I would be happy to see more
>> detailed explanation in changelog.
>>
>> Best regards,
>> Krzysztof
> 
> Yes I understood the meaning of the sentence. Already the
> s3c24xx_serial_tx_chars function.
> holds the lock port->lock for safe IRQ execution.

I am sorry but I don't get your explanation. I mentioned Peter's
thoughts about lockups after adding locking over uart_write(). However
you are referring to s3c24xx_serial_tx_chars() holding the spin lock...
I am missing the point...

Best regards,
Krzysztof

RE: [PATCH] f2fs: add new wraper function for reading inline data

[Chao Yu]

Hi Shawn,

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, February 19, 2016 10:50 AM
> To: Jaegeuk Kim; Changman Lee
> Cc: Chao Yu; linux-f2fs-de...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org; Shawn Lin
> Subject: [PATCH] f2fs: add new wraper function for reading inline data
> 
> This patch add __read_inline_data which will no check
> PageUptodate and page->index. This can be reused by
> f2fs_convert_inline_page to reduce the redundant code
> copied from read_inline_data.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
>  fs/f2fs/inline.c | 26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
> index d27347e..39eeff1 100644
> --- a/fs/f2fs/inline.c
> +++ b/fs/f2fs/inline.c
> @@ -42,15 +42,11 @@ bool f2fs_may_inline_dentry(struct inode *inode)
>   return true;
>  }
> 
> -void read_inline_data(struct page *page, struct page *ipage)
> +static inline void __read_inline_data(struct page *page,
> +   struct page *ipage)
>  {
>   void *src_addr, *dst_addr;
> 
> - if (PageUptodate(page))
> - return;
> -
> - f2fs_bug_on(F2FS_P_SB(page), page->index);
> -
>   zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);
> 
>   /* Copy the whole inline data block */
> @@ -61,6 +57,15 @@ void read_inline_data(struct page *page, struct page 
> *ipage)
>   kunmap_atomic(dst_addr);
>   SetPageUptodate(page);
>  }
> +void read_inline_data(struct page *page, struct page *ipage)
> +{
> + if (PageUptodate(page))
> + return;
> +
> + f2fs_bug_on(F2FS_P_SB(page), page->index);
> +
> + __read_inline_data(page, ipage);
> +}
> 
>  bool truncate_inline_inode(struct page *ipage, u64 from)
>  {
> @@ -128,15 +133,8 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, 
> struct page *page)
>   if (PageUptodate(page))
>   goto no_update;

Seems we can remove above check and below 'no_update' tag completely
if we use read_inline_data here.

So what about using read_inline_data to clean up codes in
f2fs_convert_inline_page?

Thanks,

> 
> - zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);
> + __read_inline_data(page, dn->inode_page);
> 
> - /* Copy the whole inline data block */
> - src_addr = inline_data_addr(dn->inode_page);
> - dst_addr = kmap_atomic(page);
> - memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
> - flush_dcache_page(page);
> - kunmap_atomic(dst_addr);
> - SetPageUptodate(page);
>  no_update:
>   set_page_dirty(page);
> 
> --
> 2.3.7
> 

RE: [PATCH] f2fs: add new wraper function for reading inline data

[Chao Yu]

Hi Shawn,

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, February 19, 2016 10:50 AM
> To: Jaegeuk Kim; Changman Lee
> Cc: Chao Yu; linux-f2fs-de...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org; Shawn Lin
> Subject: [PATCH] f2fs: add new wraper function for reading inline data
> 
> This patch add __read_inline_data which will no check
> PageUptodate and page->index. This can be reused by
> f2fs_convert_inline_page to reduce the redundant code
> copied from read_inline_data.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
>  fs/f2fs/inline.c | 26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
> index d27347e..39eeff1 100644
> --- a/fs/f2fs/inline.c
> +++ b/fs/f2fs/inline.c
> @@ -42,15 +42,11 @@ bool f2fs_may_inline_dentry(struct inode *inode)
>   return true;
>  }
> 
> -void read_inline_data(struct page *page, struct page *ipage)
> +static inline void __read_inline_data(struct page *page,
> +   struct page *ipage)
>  {
>   void *src_addr, *dst_addr;
> 
> - if (PageUptodate(page))
> - return;
> -
> - f2fs_bug_on(F2FS_P_SB(page), page->index);
> -
>   zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);
> 
>   /* Copy the whole inline data block */
> @@ -61,6 +57,15 @@ void read_inline_data(struct page *page, struct page 
> *ipage)
>   kunmap_atomic(dst_addr);
>   SetPageUptodate(page);
>  }
> +void read_inline_data(struct page *page, struct page *ipage)
> +{
> + if (PageUptodate(page))
> + return;
> +
> + f2fs_bug_on(F2FS_P_SB(page), page->index);
> +
> + __read_inline_data(page, ipage);
> +}
> 
>  bool truncate_inline_inode(struct page *ipage, u64 from)
>  {
> @@ -128,15 +133,8 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, 
> struct page *page)
>   if (PageUptodate(page))
>   goto no_update;

Seems we can remove above check and below 'no_update' tag completely
if we use read_inline_data here.

So what about using read_inline_data to clean up codes in
f2fs_convert_inline_page?

Thanks,

> 
> - zero_user_segment(page, MAX_INLINE_DATA, PAGE_CACHE_SIZE);
> + __read_inline_data(page, dn->inode_page);
> 
> - /* Copy the whole inline data block */
> - src_addr = inline_data_addr(dn->inode_page);
> - dst_addr = kmap_atomic(page);
> - memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
> - flush_dcache_page(page);
> - kunmap_atomic(dst_addr);
> - SetPageUptodate(page);
>  no_update:
>   set_page_dirty(page);
> 
> --
> 2.3.7
> 

Re: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific information in a structure

[Wei Huang]

On 02/11/2016 09:33 AM, Julien Grall wrote:
> Introduce a structure which are filled up by the arch timer driver and
> used by the virtual timer in KVM.
> 
> The first member of this structure will be the timecounter. More members
> will be added later.
> 
> This is also dropping arch_timer_get_timecounter as it was only used by
> the KVM code. Furthermore, a stub for the new helper hasn't been
> introduced because KVM is requiring the arch timer for both ARM64 and
> ARM32.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Cc: Daniel Lezcano 
> Cc: Thomas Gleixner 
> Cc: Christoffer Dall 
> Cc: Marc Zyngier 
> Cc: Gleb Natapov 
> Cc: Paolo Bonzini 
> ---
>  drivers/clocksource/arm_arch_timer.c |  9 +
>  include/clocksource/arm_arch_timer.h | 12 ++--
>  virt/kvm/arm/arch_timer.c|  6 +++---
>  3 files changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c 
> b/drivers/clocksource/arm_arch_timer.c
> index c64d543..6eb2c5d 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -447,11 +447,11 @@ static struct cyclecounter cyclecounter = {
>   .mask   = CLOCKSOURCE_MASK(56),
>  };
>  
> -static struct timecounter timecounter;
> +static struct arch_timer_kvm_info arch_timer_kvm_info;
>  
> -struct timecounter *arch_timer_get_timecounter(void)
> +struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
>  {
> - return 
> + return _timer_kvm_info;
>  }
>  
>  static void __init arch_counter_register(unsigned type)
> @@ -479,7 +479,8 @@ static void __init arch_counter_register(unsigned type)
>   clocksource_register_hz(_counter, arch_timer_rate);
>   cyclecounter.mult = clocksource_counter.mult;
>   cyclecounter.shift = clocksource_counter.shift;
> - timecounter_init(, , start_count);
> + timecounter_init(_timer_kvm_info.timecounter,
> +  , start_count);
>  
>   /* 56 bits minimum, so we assume worst case rollover */
>   sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
> diff --git a/include/clocksource/arm_arch_timer.h 
> b/include/clocksource/arm_arch_timer.h
> index 25d0914..4d487f8 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -49,11 +49,16 @@ enum arch_timer_reg {
>  
>  #define ARCH_TIMER_EVT_STREAM_FREQ   1   /* 100us */
>  
> +struct arch_timer_kvm_info {
> + struct timecounter timecounter;
> +};
> +
>  #ifdef CONFIG_ARM_ARCH_TIMER
>  
>  extern u32 arch_timer_get_rate(void);
>  extern u64 (*arch_timer_read_counter)(void);
> -extern struct timecounter *arch_timer_get_timecounter(void);
> +
> +extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
>  
>  #else
>  
> @@ -67,11 +72,6 @@ static inline u64 arch_timer_read_counter(void)
>   return 0;
>  }
>  
> -static inline struct timecounter *arch_timer_get_timecounter(void)
> -{
> - return NULL;
> -}
> -

Most parts are OK. Regarding removing this function from the #else area,
is there a possibility to have CONFIG_ARM_ARCH_TIMER=n and CONFIG_KVM=y.
If so, will the compilation fails here?

-Wei

>  #endif
>  
>  #endif
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 69bca18..a669c6a 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -385,11 +385,11 @@ int kvm_timer_hyp_init(void)
>  {
>   struct device_node *np;
>   unsigned int ppi;
> + struct arch_timer_kvm_info *info;
>   int err;
>  
> - timecounter = arch_timer_get_timecounter();
> - if (!timecounter)
> - return -ENODEV;
> + info = arch_timer_get_kvm_info();
> + timecounter = >timecounter;
>  
>   np = of_find_matching_node(NULL, arch_timer_of_match);
>   if (!np) {
> 

Re: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific information in a structure

[Wei Huang]

On 02/11/2016 09:33 AM, Julien Grall wrote:
> Introduce a structure which are filled up by the arch timer driver and
> used by the virtual timer in KVM.
> 
> The first member of this structure will be the timecounter. More members
> will be added later.
> 
> This is also dropping arch_timer_get_timecounter as it was only used by
> the KVM code. Furthermore, a stub for the new helper hasn't been
> introduced because KVM is requiring the arch timer for both ARM64 and
> ARM32.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Cc: Daniel Lezcano 
> Cc: Thomas Gleixner 
> Cc: Christoffer Dall 
> Cc: Marc Zyngier 
> Cc: Gleb Natapov 
> Cc: Paolo Bonzini 
> ---
>  drivers/clocksource/arm_arch_timer.c |  9 +
>  include/clocksource/arm_arch_timer.h | 12 ++--
>  virt/kvm/arm/arch_timer.c|  6 +++---
>  3 files changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c 
> b/drivers/clocksource/arm_arch_timer.c
> index c64d543..6eb2c5d 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -447,11 +447,11 @@ static struct cyclecounter cyclecounter = {
>   .mask   = CLOCKSOURCE_MASK(56),
>  };
>  
> -static struct timecounter timecounter;
> +static struct arch_timer_kvm_info arch_timer_kvm_info;
>  
> -struct timecounter *arch_timer_get_timecounter(void)
> +struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
>  {
> - return 
> + return _timer_kvm_info;
>  }
>  
>  static void __init arch_counter_register(unsigned type)
> @@ -479,7 +479,8 @@ static void __init arch_counter_register(unsigned type)
>   clocksource_register_hz(_counter, arch_timer_rate);
>   cyclecounter.mult = clocksource_counter.mult;
>   cyclecounter.shift = clocksource_counter.shift;
> - timecounter_init(, , start_count);
> + timecounter_init(_timer_kvm_info.timecounter,
> +  , start_count);
>  
>   /* 56 bits minimum, so we assume worst case rollover */
>   sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
> diff --git a/include/clocksource/arm_arch_timer.h 
> b/include/clocksource/arm_arch_timer.h
> index 25d0914..4d487f8 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -49,11 +49,16 @@ enum arch_timer_reg {
>  
>  #define ARCH_TIMER_EVT_STREAM_FREQ   1   /* 100us */
>  
> +struct arch_timer_kvm_info {
> + struct timecounter timecounter;
> +};
> +
>  #ifdef CONFIG_ARM_ARCH_TIMER
>  
>  extern u32 arch_timer_get_rate(void);
>  extern u64 (*arch_timer_read_counter)(void);
> -extern struct timecounter *arch_timer_get_timecounter(void);
> +
> +extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
>  
>  #else
>  
> @@ -67,11 +72,6 @@ static inline u64 arch_timer_read_counter(void)
>   return 0;
>  }
>  
> -static inline struct timecounter *arch_timer_get_timecounter(void)
> -{
> - return NULL;
> -}
> -

Most parts are OK. Regarding removing this function from the #else area,
is there a possibility to have CONFIG_ARM_ARCH_TIMER=n and CONFIG_KVM=y.
If so, will the compilation fails here?

-Wei

>  #endif
>  
>  #endif
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 69bca18..a669c6a 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -385,11 +385,11 @@ int kvm_timer_hyp_init(void)
>  {
>   struct device_node *np;
>   unsigned int ppi;
> + struct arch_timer_kvm_info *info;
>   int err;
>  
> - timecounter = arch_timer_get_timecounter();
> - if (!timecounter)
> - return -ENODEV;
> + info = arch_timer_get_kvm_info();
> + timecounter = >timecounter;
>  
>   np = of_find_matching_node(NULL, arch_timer_of_match);
>   if (!np) {
> 

Re: [PATCH v2 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

[Paul Walmsley]

On Fri, 19 Feb 2016, Keerthy wrote:

> The patch adds rtc hwmod. RTC module The RTC module is physically
> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
> disabled. A secure RTC is used instead on these devices, where needed.
> . Hence adding it selectively using a seprate list to get RTC Module
> functional on the other am43x SoCs used on am437x-gp-evm and
> am437x-sk-evm.
> 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
> Inverted the checking logic to accommodate registering for all
> the SoCs compatible to am4372 and removed the negating am438x logic
> to register rtc hwmods as suggested by Paul.
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)

OK thanks; I've queued the following patch for v4.6 or if I get unlucky, 
v4.7.

- Paul

From: Keerthy 
Date: Fri, 19 Feb 2016 10:08:55 +0530
Subject: [PATCH] ARM: AM43XX: hwmod: Add rtc hwmod

The patch registers the rtc hwmod on AM437x chips.  The RTC module is
physically present on the AM438x SoC used on AM43X-EPOS-EVM, but it is
permanently disabled. A secure RTC is used instead on these devices,
where needed. Hence adding it selectively using a separate list to get
RTC Module functional on the other am43x SoCs used on am437x-gp-evm
and am437x-sk-evm.

Signed-off-by: Keerthy 
[p...@pwsan.com: cleaned up patch description]
Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894b5f88..97fd399202dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
NULL,
 };
 
+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+   _l4_wkup__rtc,
+   NULL,
+};
+
 int __init am43xx_hwmod_init(void)
 {
+   int ret;
+
omap_hwmod_am43xx_reg();
omap_hwmod_init();
-   return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+   ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+   if (!ret && of_machine_is_compatible("ti,am4372"))
+   ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+   return ret;
 }
-- 
2.7.0

Re: [PATCH v2 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

[Paul Walmsley]

On Fri, 19 Feb 2016, Keerthy wrote:

> The patch adds rtc hwmod. RTC module The RTC module is physically
> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
> disabled. A secure RTC is used instead on these devices, where needed.
> . Hence adding it selectively using a seprate list to get RTC Module
> functional on the other am43x SoCs used on am437x-gp-evm and
> am437x-sk-evm.
> 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
> Inverted the checking logic to accommodate registering for all
> the SoCs compatible to am4372 and removed the negating am438x logic
> to register rtc hwmods as suggested by Paul.
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)

OK thanks; I've queued the following patch for v4.6 or if I get unlucky, 
v4.7.

- Paul

From: Keerthy 
Date: Fri, 19 Feb 2016 10:08:55 +0530
Subject: [PATCH] ARM: AM43XX: hwmod: Add rtc hwmod

The patch registers the rtc hwmod on AM437x chips.  The RTC module is
physically present on the AM438x SoC used on AM43X-EPOS-EVM, but it is
permanently disabled. A secure RTC is used instead on these devices,
where needed. Hence adding it selectively using a separate list to get
RTC Module functional on the other am43x SoCs used on am437x-gp-evm
and am437x-sk-evm.

Signed-off-by: Keerthy 
[p...@pwsan.com: cleaned up patch description]
Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894b5f88..97fd399202dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
NULL,
 };
 
+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+   _l4_wkup__rtc,
+   NULL,
+};
+
 int __init am43xx_hwmod_init(void)
 {
+   int ret;
+
omap_hwmod_am43xx_reg();
omap_hwmod_init();
-   return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+   ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+   if (!ret && of_machine_is_compatible("ti,am4372"))
+   ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+   return ret;
 }
-- 
2.7.0

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore

[Krzysztof Kozlowski]

On 19.02.2016 15:39, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 19 February 2016 at 11:36, Krzysztof Kozlowski
>  wrote:
>> 2016-02-19 2:21 GMT+09:00 Anand Moon :
>>> From: Anand Moon 
>>>
>>> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking.
>>> It's safe to initialize pl330_tasklet tasklet after release of the locking.
>>
>> This is tasklet init, not tasklet execution (which you are referring
>> to in first sentence). I don't get how usage of spinlock during
>> execution guarantees the safeness during init... Please describe why
>> this is safe.
>>
>> Best regards,
>> Krzysztof
>>
> 
> http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972
> 
> pl330_tasklet function which is initiated by tasklet_init is trying to lock
> using same spin_unlock_irqsave/restore pch->lock.

tasklet_init does not call pl330_tasklet (if this is what you mean by
"initiated"). What is the correlation? Why are you referring to the
locks in pl330_tasklet?

> So better release the pch->lock and then initialize  the tasklet_init.

Why "better"?

Best regards,
Krzysztof

> 
>>>
>>> Signed-off-by: Anand Moon 
>>> ---
>>>  drivers/dma/pl330.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>>> index 17ee758..df2cab1 100644
>>> --- a/drivers/dma/pl330.c
>>> +++ b/drivers/dma/pl330.c
>>> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct 
>>> dma_chan *chan)
>>> return -ENOMEM;
>>> }
>>>
>>> -   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>>> -
>>> spin_unlock_irqrestore(>lock, flags);
>>>
>>> +   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>>> +
>>> return 1;
>>>  }
>>>
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore

[Krzysztof Kozlowski]

On 19.02.2016 15:39, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 19 February 2016 at 11:36, Krzysztof Kozlowski
>  wrote:
>> 2016-02-19 2:21 GMT+09:00 Anand Moon :
>>> From: Anand Moon 
>>>
>>> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking.
>>> It's safe to initialize pl330_tasklet tasklet after release of the locking.
>>
>> This is tasklet init, not tasklet execution (which you are referring
>> to in first sentence). I don't get how usage of spinlock during
>> execution guarantees the safeness during init... Please describe why
>> this is safe.
>>
>> Best regards,
>> Krzysztof
>>
> 
> http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972
> 
> pl330_tasklet function which is initiated by tasklet_init is trying to lock
> using same spin_unlock_irqsave/restore pch->lock.

tasklet_init does not call pl330_tasklet (if this is what you mean by
"initiated"). What is the correlation? Why are you referring to the
locks in pl330_tasklet?

> So better release the pch->lock and then initialize  the tasklet_init.

Why "better"?

Best regards,
Krzysztof

> 
>>>
>>> Signed-off-by: Anand Moon 
>>> ---
>>>  drivers/dma/pl330.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>>> index 17ee758..df2cab1 100644
>>> --- a/drivers/dma/pl330.c
>>> +++ b/drivers/dma/pl330.c
>>> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct 
>>> dma_chan *chan)
>>> return -ENOMEM;
>>> }
>>>
>>> -   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>>> -
>>> spin_unlock_irqrestore(>lock, flags);
>>>
>>> +   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>>> +
>>> return 1;
>>>  }
>>>
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Sascha Hauer]

Hi Matthias,

On Thu, Feb 18, 2016 at 05:18:49PM +0100, Matthias Brugger wrote:
> Hi Sascha,
> 
> On 30/11/15 12:42, Sascha Hauer wrote:
> >This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> >dtsi file.
> >
> >Signed-off-by: Sascha Hauer 
> >Reviewed-by: Daniel Kurtz 
> >---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +
> >  1 file changed, 17 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> >b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >index 06a1564..e2ddd03 100644
> >--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >@@ -277,6 +277,11 @@
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > };
> >
> >+auxadc: auxadc@11001000 {
> >+compatible = "mediatek,mt8173-auxadc";
> 
> Can you please write a small Documentation about the binding.
> I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

Just did that.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes

[Sascha Hauer]

Hi Matthias,

On Thu, Feb 18, 2016 at 05:18:49PM +0100, Matthias Brugger wrote:
> Hi Sascha,
> 
> On 30/11/15 12:42, Sascha Hauer wrote:
> >This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> >dtsi file.
> >
> >Signed-off-by: Sascha Hauer 
> >Reviewed-by: Daniel Kurtz 
> >---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +
> >  1 file changed, 17 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> >b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >index 06a1564..e2ddd03 100644
> >--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >@@ -277,6 +277,11 @@
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > };
> >
> >+auxadc: auxadc@11001000 {
> >+compatible = "mediatek,mt8173-auxadc";
> 
> Can you please write a small Documentation about the binding.
> I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

Just did that.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH V2 2/2] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for MT7623

[John Crispin]

Add the driver and header files required to make pinctrl work on MediaTek
MT7623.

Signed-off-by: John Crispin 
---
please apply to the devel-mt2701 branch

Changes in V2
* fix typo in Kconfig
* move mt7623-pinfunc.h into 1/2

 drivers/pinctrl/mediatek/Kconfig  |6 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt7623.c |  380 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h | 1936 +
 4 files changed, 2323 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7623.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 13e9939..78654a8 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -15,6 +15,12 @@ config PINCTRL_MT2701
default MACH_MT2701
select PINCTRL_MTK_COMMON
 
+config PINCTRL_MT7623
+   bool "Mediatek MT7623 pin control" if COMPILE_TEST && !MACH_MT7623
+   depends on OF
+   default MACH_MT7623
+   select PINCTRL_MTK_COMMON
+
 config PINCTRL_MT8135
bool "Mediatek MT8135 pin control" if COMPILE_TEST && !MACH_MT8135
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index da30314..1be2f3f 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PINCTRL_MTK_COMMON)+= pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT7623)   += pinctrl-mt7623.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c 
b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
new file mode 100644
index 000..bf0d05b
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
@@ -0,0 +1,380 @@
+/*
+ * Copyright (c) 2016 John Crispin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt7623.h"
+
+static const struct mtk_drv_group_desc mt7623_drv_grp[] =  {
+   /* 0E4E8SR 4/8/12/16 */
+   MTK_DRV_GRP(4, 16, 1, 2, 4),
+   /* 0E2E4SR  2/4/6/8 */
+   MTK_DRV_GRP(2, 8, 1, 2, 2),
+   /* E8E4E2  2/4/6/8/10/12/14/16 */
+   MTK_DRV_GRP(2, 16, 0, 2, 2)
+};
+
+#define DRV_SEL0   0xf50
+#define DRV_SEL1   0xf60
+#define DRV_SEL2   0xf70
+#define DRV_SEL3   0xf80
+#define DRV_SEL4   0xf90
+#define DRV_SEL5   0xfa0
+#define DRV_SEL6   0xfb0
+#define DRV_SEL7   0xfe0
+#define DRV_SEL8   0xfd0
+#define DRV_SEL9   0xff0
+#define DRV_SEL10  0xf00
+
+#define MSDC0_CTRL00xcc0
+#define MSDC0_CTRL10xcd0
+#define MSDC0_CTRL20xce0
+#define MSDC0_CTRL30xcf0
+#define MSDC0_CTRL40xd00
+#define MSDC0_CTRL50xd10
+#define MSDC0_CTRL60xd20
+#define MSDC1_CTRL00xd30
+#define MSDC1_CTRL10xd40
+#define MSDC1_CTRL20xd50
+#define MSDC1_CTRL30xd60
+#define MSDC1_CTRL40xd70
+#define MSDC1_CTRL50xd80
+#define MSDC1_CTRL60xd90
+
+#define IES_EN00xb20
+#define IES_EN10xb30
+#define IES_EN20xb40
+
+#define SMT_EN00xb50
+#define SMT_EN10xb60
+#define SMT_EN20xb70
+
+static const struct mtk_pin_drv_grp mt7623_pin_drv[] = {
+   MTK_PIN_DRV_GRP(0, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(1, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(2, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(3, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(4, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(5, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(6, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(7, DRV_SEL0, 4, 1),
+   MTK_PIN_DRV_GRP(8, DRV_SEL0, 4, 1),
+   MTK_PIN_DRV_GRP(9, DRV_SEL0, 4, 1),
+   MTK_PIN_DRV_GRP(10, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(11, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(12, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(13, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(14, DRV_SEL0, 12, 0),
+   MTK_PIN_DRV_GRP(15, DRV_SEL0, 12, 0),
+   MTK_PIN_DRV_GRP(18, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(19, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(20, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(21, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(22, DRV_SEL1, 

[PATCH V2 2/2] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for MT7623

[John Crispin]

Add the driver and header files required to make pinctrl work on MediaTek
MT7623.

Signed-off-by: John Crispin 
---
please apply to the devel-mt2701 branch

Changes in V2
* fix typo in Kconfig
* move mt7623-pinfunc.h into 1/2

 drivers/pinctrl/mediatek/Kconfig  |6 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt7623.c |  380 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h | 1936 +
 4 files changed, 2323 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7623.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 13e9939..78654a8 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -15,6 +15,12 @@ config PINCTRL_MT2701
default MACH_MT2701
select PINCTRL_MTK_COMMON
 
+config PINCTRL_MT7623
+   bool "Mediatek MT7623 pin control" if COMPILE_TEST && !MACH_MT7623
+   depends on OF
+   default MACH_MT7623
+   select PINCTRL_MTK_COMMON
+
 config PINCTRL_MT8135
bool "Mediatek MT8135 pin control" if COMPILE_TEST && !MACH_MT8135
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index da30314..1be2f3f 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PINCTRL_MTK_COMMON)+= pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT7623)   += pinctrl-mt7623.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c 
b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
new file mode 100644
index 000..bf0d05b
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
@@ -0,0 +1,380 @@
+/*
+ * Copyright (c) 2016 John Crispin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt7623.h"
+
+static const struct mtk_drv_group_desc mt7623_drv_grp[] =  {
+   /* 0E4E8SR 4/8/12/16 */
+   MTK_DRV_GRP(4, 16, 1, 2, 4),
+   /* 0E2E4SR  2/4/6/8 */
+   MTK_DRV_GRP(2, 8, 1, 2, 2),
+   /* E8E4E2  2/4/6/8/10/12/14/16 */
+   MTK_DRV_GRP(2, 16, 0, 2, 2)
+};
+
+#define DRV_SEL0   0xf50
+#define DRV_SEL1   0xf60
+#define DRV_SEL2   0xf70
+#define DRV_SEL3   0xf80
+#define DRV_SEL4   0xf90
+#define DRV_SEL5   0xfa0
+#define DRV_SEL6   0xfb0
+#define DRV_SEL7   0xfe0
+#define DRV_SEL8   0xfd0
+#define DRV_SEL9   0xff0
+#define DRV_SEL10  0xf00
+
+#define MSDC0_CTRL00xcc0
+#define MSDC0_CTRL10xcd0
+#define MSDC0_CTRL20xce0
+#define MSDC0_CTRL30xcf0
+#define MSDC0_CTRL40xd00
+#define MSDC0_CTRL50xd10
+#define MSDC0_CTRL60xd20
+#define MSDC1_CTRL00xd30
+#define MSDC1_CTRL10xd40
+#define MSDC1_CTRL20xd50
+#define MSDC1_CTRL30xd60
+#define MSDC1_CTRL40xd70
+#define MSDC1_CTRL50xd80
+#define MSDC1_CTRL60xd90
+
+#define IES_EN00xb20
+#define IES_EN10xb30
+#define IES_EN20xb40
+
+#define SMT_EN00xb50
+#define SMT_EN10xb60
+#define SMT_EN20xb70
+
+static const struct mtk_pin_drv_grp mt7623_pin_drv[] = {
+   MTK_PIN_DRV_GRP(0, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(1, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(2, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(3, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(4, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(5, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(6, DRV_SEL0, 0, 1),
+   MTK_PIN_DRV_GRP(7, DRV_SEL0, 4, 1),
+   MTK_PIN_DRV_GRP(8, DRV_SEL0, 4, 1),
+   MTK_PIN_DRV_GRP(9, DRV_SEL0, 4, 1),
+   MTK_PIN_DRV_GRP(10, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(11, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(12, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(13, DRV_SEL0, 8, 1),
+   MTK_PIN_DRV_GRP(14, DRV_SEL0, 12, 0),
+   MTK_PIN_DRV_GRP(15, DRV_SEL0, 12, 0),
+   MTK_PIN_DRV_GRP(18, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(19, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(20, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(21, DRV_SEL1, 4, 0),
+   MTK_PIN_DRV_GRP(22, DRV_SEL1, 8, 0),
+   MTK_PIN_DRV_GRP(23, 

[PATCH V2 1/2] pinctrl: mediatek: Modify pinctrl bindings for mt7623

[John Crispin]

Signed-off-by: John Crispin 
Cc: devicet...@vger.kernel.org
---
please apply to the devel-mt2701 branch

Changes in V2
* make mt7623-pinfunc.h part of patch 1/2
* make sure the list stays sorted

 .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |1 +
 include/dt-bindings/pinctrl/mt7623-pinfunc.h   |  520 
 2 files changed, 521 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/mt7623-pinfunc.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
index 9ffb0b2..17631d0 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
@@ -6,6 +6,7 @@ Required properties:
 - compatible: value should be one of the following.
"mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
"mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
+   "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl.
"mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
"mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
"mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
diff --git a/include/dt-bindings/pinctrl/mt7623-pinfunc.h 
b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
new file mode 100644
index 000..2f00bdc
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
@@ -0,0 +1,520 @@
+#ifndef __DTS_MT7623_PINFUNC_H
+#define __DTS_MT7623_PINFUNC_H
+
+#include 
+
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_PWRAP_SPIDO (MTK_PIN_NO(0) | 1)
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_PWRAP_SPIDI (MTK_PIN_NO(0) | 2)
+
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_PWRAP_SPIDI (MTK_PIN_NO(1) | 1)
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_PWRAP_SPIDO (MTK_PIN_NO(1) | 2)
+
+#define MT7623_PIN_2_PWRAP_INT_FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT7623_PIN_2_PWRAP_INT_FUNC_PWRAP_INT (MTK_PIN_NO(2) | 1)
+
+#define MT7623_PIN_3_PWRAP_SPI0_CK_FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT7623_PIN_3_PWRAP_SPI0_CK_FUNC_PWRAP_SPICK_I (MTK_PIN_NO(3) | 1)
+
+#define MT7623_PIN_4_PWRAP_SPI0_CSN_FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT7623_PIN_4_PWRAP_SPI0_CSN_FUNC_PWRAP_SPICS_B_I (MTK_PIN_NO(4) | 1)
+
+#define MT7623_PIN_5_PWRAP_SPI0_CK2_FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT7623_PIN_5_PWRAP_SPI0_CK2_FUNC_PWRAP_SPICK2_I (MTK_PIN_NO(5) | 1)
+
+#define MT7623_PIN_6_PWRAP_SPI0_CSN2_FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT7623_PIN_6_PWRAP_SPI0_CSN2_FUNC_PWRAP_SPICS2_B_I (MTK_PIN_NO(6) | 1)
+
+#define MT7623_PIN_7_SPI1_CSN_FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT7623_PIN_7_SPI1_CSN_FUNC_SPI1_CS (MTK_PIN_NO(7) | 1)
+
+#define MT7623_PIN_8_SPI1_MI_FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT7623_PIN_8_SPI1_MI_FUNC_SPI1_MI (MTK_PIN_NO(8) | 1)
+#define MT7623_PIN_8_SPI1_MI_FUNC_SPI1_MO (MTK_PIN_NO(8) | 2)
+
+#define MT7623_PIN_9_SPI1_MO_FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define MT7623_PIN_9_SPI1_MO_FUNC_SPI1_MO (MTK_PIN_NO(9) | 1)
+#define MT7623_PIN_9_SPI1_MO_FUNC_SPI1_MI (MTK_PIN_NO(9) | 2)
+
+#define MT7623_PIN_10_RTC32K_CK_FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define MT7623_PIN_10_RTC32K_CK_FUNC_RTC32K_CK (MTK_PIN_NO(10) | 1)
+
+#define MT7623_PIN_11_WATCHDOG_FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define MT7623_PIN_11_WATCHDOG_FUNC_WATCHDOG (MTK_PIN_NO(11) | 1)
+
+#define MT7623_PIN_12_SRCLKENA_FUNC_GPIO12 (MTK_PIN_NO(12) | 0)
+#define MT7623_PIN_12_SRCLKENA_FUNC_SRCLKENA (MTK_PIN_NO(12) | 1)
+
+#define MT7623_PIN_13_SRCLKENAI_FUNC_GPIO13 (MTK_PIN_NO(13) | 0)
+#define MT7623_PIN_13_SRCLKENAI_FUNC_SRCLKENAI (MTK_PIN_NO(13) | 1)
+
+#define MT7623_PIN_14_GPIO14_FUNC_GPIO14 (MTK_PIN_NO(14) | 0)
+#define MT7623_PIN_14_GPIO14_FUNC_URXD2 (MTK_PIN_NO(14) | 1)
+#define MT7623_PIN_14_GPIO14_FUNC_UTXD2 (MTK_PIN_NO(14) | 2)
+
+#define MT7623_PIN_15_GPIO15_FUNC_GPIO15 (MTK_PIN_NO(15) | 0)
+#define MT7623_PIN_15_GPIO15_FUNC_UTXD2 (MTK_PIN_NO(15) | 1)
+#define MT7623_PIN_15_GPIO15_FUNC_URXD2 (MTK_PIN_NO(15) | 2)
+
+#define MT7623_PIN_18_PCM_CLK_FUNC_GPIO18 (MTK_PIN_NO(18) | 0)
+#define MT7623_PIN_18_PCM_CLK_FUNC_PCM_CLK0 (MTK_PIN_NO(18) | 1)
+#define MT7623_PIN_18_PCM_CLK_FUNC_AP_PCM_CLKO (MTK_PIN_NO(18) | 6)
+
+#define MT7623_PIN_19_PCM_SYNC_FUNC_GPIO19 (MTK_PIN_NO(19) | 0)
+#define MT7623_PIN_19_PCM_SYNC_FUNC_PCM_SYNC (MTK_PIN_NO(19) | 1)
+#define MT7623_PIN_19_PCM_SYNC_FUNC_AP_PCM_SYNC (MTK_PIN_NO(19) | 6)
+
+#define MT7623_PIN_20_PCM_RX_FUNC_GPIO20 (MTK_PIN_NO(20) | 0)
+#define MT7623_PIN_20_PCM_RX_FUNC_PCM_RX (MTK_PIN_NO(20) | 1)
+#define MT7623_PIN_20_PCM_RX_FUNC_PCM_TX (MTK_PIN_NO(20) | 4)
+#define MT7623_PIN_20_PCM_RX_FUNC_AP_PCM_RX (MTK_PIN_NO(20) | 6)
+
+#define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
+#define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1)
+#define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4)

[PATCH V2 1/2] pinctrl: mediatek: Modify pinctrl bindings for mt7623

[John Crispin]

Signed-off-by: John Crispin 
Cc: devicet...@vger.kernel.org
---
please apply to the devel-mt2701 branch

Changes in V2
* make mt7623-pinfunc.h part of patch 1/2
* make sure the list stays sorted

 .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |1 +
 include/dt-bindings/pinctrl/mt7623-pinfunc.h   |  520 
 2 files changed, 521 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/mt7623-pinfunc.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
index 9ffb0b2..17631d0 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
@@ -6,6 +6,7 @@ Required properties:
 - compatible: value should be one of the following.
"mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
"mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
+   "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl.
"mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
"mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
"mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
diff --git a/include/dt-bindings/pinctrl/mt7623-pinfunc.h 
b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
new file mode 100644
index 000..2f00bdc
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
@@ -0,0 +1,520 @@
+#ifndef __DTS_MT7623_PINFUNC_H
+#define __DTS_MT7623_PINFUNC_H
+
+#include 
+
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_PWRAP_SPIDO (MTK_PIN_NO(0) | 1)
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_PWRAP_SPIDI (MTK_PIN_NO(0) | 2)
+
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_PWRAP_SPIDI (MTK_PIN_NO(1) | 1)
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_PWRAP_SPIDO (MTK_PIN_NO(1) | 2)
+
+#define MT7623_PIN_2_PWRAP_INT_FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT7623_PIN_2_PWRAP_INT_FUNC_PWRAP_INT (MTK_PIN_NO(2) | 1)
+
+#define MT7623_PIN_3_PWRAP_SPI0_CK_FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT7623_PIN_3_PWRAP_SPI0_CK_FUNC_PWRAP_SPICK_I (MTK_PIN_NO(3) | 1)
+
+#define MT7623_PIN_4_PWRAP_SPI0_CSN_FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT7623_PIN_4_PWRAP_SPI0_CSN_FUNC_PWRAP_SPICS_B_I (MTK_PIN_NO(4) | 1)
+
+#define MT7623_PIN_5_PWRAP_SPI0_CK2_FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT7623_PIN_5_PWRAP_SPI0_CK2_FUNC_PWRAP_SPICK2_I (MTK_PIN_NO(5) | 1)
+
+#define MT7623_PIN_6_PWRAP_SPI0_CSN2_FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT7623_PIN_6_PWRAP_SPI0_CSN2_FUNC_PWRAP_SPICS2_B_I (MTK_PIN_NO(6) | 1)
+
+#define MT7623_PIN_7_SPI1_CSN_FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT7623_PIN_7_SPI1_CSN_FUNC_SPI1_CS (MTK_PIN_NO(7) | 1)
+
+#define MT7623_PIN_8_SPI1_MI_FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT7623_PIN_8_SPI1_MI_FUNC_SPI1_MI (MTK_PIN_NO(8) | 1)
+#define MT7623_PIN_8_SPI1_MI_FUNC_SPI1_MO (MTK_PIN_NO(8) | 2)
+
+#define MT7623_PIN_9_SPI1_MO_FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define MT7623_PIN_9_SPI1_MO_FUNC_SPI1_MO (MTK_PIN_NO(9) | 1)
+#define MT7623_PIN_9_SPI1_MO_FUNC_SPI1_MI (MTK_PIN_NO(9) | 2)
+
+#define MT7623_PIN_10_RTC32K_CK_FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define MT7623_PIN_10_RTC32K_CK_FUNC_RTC32K_CK (MTK_PIN_NO(10) | 1)
+
+#define MT7623_PIN_11_WATCHDOG_FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define MT7623_PIN_11_WATCHDOG_FUNC_WATCHDOG (MTK_PIN_NO(11) | 1)
+
+#define MT7623_PIN_12_SRCLKENA_FUNC_GPIO12 (MTK_PIN_NO(12) | 0)
+#define MT7623_PIN_12_SRCLKENA_FUNC_SRCLKENA (MTK_PIN_NO(12) | 1)
+
+#define MT7623_PIN_13_SRCLKENAI_FUNC_GPIO13 (MTK_PIN_NO(13) | 0)
+#define MT7623_PIN_13_SRCLKENAI_FUNC_SRCLKENAI (MTK_PIN_NO(13) | 1)
+
+#define MT7623_PIN_14_GPIO14_FUNC_GPIO14 (MTK_PIN_NO(14) | 0)
+#define MT7623_PIN_14_GPIO14_FUNC_URXD2 (MTK_PIN_NO(14) | 1)
+#define MT7623_PIN_14_GPIO14_FUNC_UTXD2 (MTK_PIN_NO(14) | 2)
+
+#define MT7623_PIN_15_GPIO15_FUNC_GPIO15 (MTK_PIN_NO(15) | 0)
+#define MT7623_PIN_15_GPIO15_FUNC_UTXD2 (MTK_PIN_NO(15) | 1)
+#define MT7623_PIN_15_GPIO15_FUNC_URXD2 (MTK_PIN_NO(15) | 2)
+
+#define MT7623_PIN_18_PCM_CLK_FUNC_GPIO18 (MTK_PIN_NO(18) | 0)
+#define MT7623_PIN_18_PCM_CLK_FUNC_PCM_CLK0 (MTK_PIN_NO(18) | 1)
+#define MT7623_PIN_18_PCM_CLK_FUNC_AP_PCM_CLKO (MTK_PIN_NO(18) | 6)
+
+#define MT7623_PIN_19_PCM_SYNC_FUNC_GPIO19 (MTK_PIN_NO(19) | 0)
+#define MT7623_PIN_19_PCM_SYNC_FUNC_PCM_SYNC (MTK_PIN_NO(19) | 1)
+#define MT7623_PIN_19_PCM_SYNC_FUNC_AP_PCM_SYNC (MTK_PIN_NO(19) | 6)
+
+#define MT7623_PIN_20_PCM_RX_FUNC_GPIO20 (MTK_PIN_NO(20) | 0)
+#define MT7623_PIN_20_PCM_RX_FUNC_PCM_RX (MTK_PIN_NO(20) | 1)
+#define MT7623_PIN_20_PCM_RX_FUNC_PCM_TX (MTK_PIN_NO(20) | 4)
+#define MT7623_PIN_20_PCM_RX_FUNC_AP_PCM_RX (MTK_PIN_NO(20) | 6)
+
+#define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
+#define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1)
+#define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4)
+#define 

Re: [PATCHv3 00/11] Fixes and improvements to f_fs and f_midi

[Felipe Balbi]

Hi,

Michal Nazarewicz  writes:
>> Michal Nazarewicz  writes:
>>> Resending my previous two sets for f_fs and f_midi.  This time rebased
>>> on top of Felipe’s next branch.
>>>
>>> Dan Carpenter (1):
>>>   usb: gadget: f_midi: missing unlock on error path
>>>
>>> Du, Changbin (1):
>>>   usb: f_fs: avoid race condition with ffs_epfile_io_complete
>>>
>>> Felipe F. Tonello (1):
>>>   usb: gadget: f_midi: remove useless midi reference from port struct
>>>
>>> Michal Nazarewicz (8):
>>>   usb: f_fs: fix memory leak when ep changes during transfer
>>>   usb: f_fs: fix ffs_epfile_io returning success on req alloc failure
>>>   usb: f_fs: replace unnecessary goto with a return
>>>   usb: f_fs: refactor ffs_epfile_io
>>>   usb: gadget: f_midi: move some of f_midi_transmit to separate func
>>>   usb: gadget: f_midi: fix in_last_port looping logic
>>>   usb: gadget: f_midi: use flexible array member for gmidi_in_port
>>> elements
>>>   usb: gadget: f_midi: stash substream in gmidi_in_port structure
>
> On Thu, Feb 18 2016, Felipe Balbi wrote:
>> looks like I don't have these patches in my inbox, care to resend ?
>
> Patches freshly rebased on your next branch coming right up.  Also
> available at:
>
> git fetch https://github.com/mina86/linux.git for-felipe

thanks, I'll fetch your branch and apply the patches individually :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCHv3 00/11] Fixes and improvements to f_fs and f_midi

[Felipe Balbi]

Hi,

Michal Nazarewicz  writes:
>> Michal Nazarewicz  writes:
>>> Resending my previous two sets for f_fs and f_midi.  This time rebased
>>> on top of Felipe’s next branch.
>>>
>>> Dan Carpenter (1):
>>>   usb: gadget: f_midi: missing unlock on error path
>>>
>>> Du, Changbin (1):
>>>   usb: f_fs: avoid race condition with ffs_epfile_io_complete
>>>
>>> Felipe F. Tonello (1):
>>>   usb: gadget: f_midi: remove useless midi reference from port struct
>>>
>>> Michal Nazarewicz (8):
>>>   usb: f_fs: fix memory leak when ep changes during transfer
>>>   usb: f_fs: fix ffs_epfile_io returning success on req alloc failure
>>>   usb: f_fs: replace unnecessary goto with a return
>>>   usb: f_fs: refactor ffs_epfile_io
>>>   usb: gadget: f_midi: move some of f_midi_transmit to separate func
>>>   usb: gadget: f_midi: fix in_last_port looping logic
>>>   usb: gadget: f_midi: use flexible array member for gmidi_in_port
>>> elements
>>>   usb: gadget: f_midi: stash substream in gmidi_in_port structure
>
> On Thu, Feb 18 2016, Felipe Balbi wrote:
>> looks like I don't have these patches in my inbox, care to resend ?
>
> Patches freshly rebased on your next branch coming right up.  Also
> available at:
>
> git fetch https://github.com/mina86/linux.git for-felipe

thanks, I'll fetch your branch and apply the patches individually :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 05/10] usb: dbc: add bulk out and bulk in interfaces

[Lu Baolu]

On 02/18/2016 09:32 PM, Mathias Nyman wrote:
> On 26.01.2016 14:58, Lu Baolu wrote:
>> This patch adds interfaces for bulk out and bulk in ops. These
>> interfaces could be used to implement early printk bootconsole
>> or hook to various system debuggers.
>>
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/early/xhci-dbc.c | 373 
>> +++
>>   include/linux/usb/xhci-dbc.h |  30 
>>   2 files changed, 403 insertions(+)
>>
>
> ...
>
>> +
>> +/*
>> + * Check and dispatch events in event ring. It also checks status
>> + * of hardware. This function will be called from multiple threads.
>> + * An atomic lock is applied to protect the access of event ring.
>> + */
>> +static int xdbc_check_event(void)
>> +{
>> +/* event ring is under checking by other thread? */
>> +if (!test_bit(XDBC_ATOMIC_EVENT, >atomic_flags) &&
>> +!test_and_set_bit(XDBC_ATOMIC_EVENT,
>> +>atomic_flags))
>> +return 0;
>
> homemade trylock, can't the real ones be used?
>
>> +
>> +xdbc_handle_events();
>> +
>> +test_and_clear_bit(XDBC_ATOMIC_EVENT, >atomic_flags);
>> +
>> +return 0;
>>  +}
>> +
>> +#defineBULK_IN_COMPLETED(p)((xdbcp->in_pending == (p)) && \
>> + xdbcp->in_complete)
>> +#defineBULK_OUT_COMPLETED(p)((xdbcp->out_pending == (p)) && \
>> + xdbcp->out_complete)
>> +
>
> ...
>
>> +}
>> +
>> +int xdbc_bulk_read(void *data, int size, int loops)
>> +{
>> +int ret;
>> +
>> +do {
>> +if (!test_bit(XDBC_ATOMIC_BULKIN, >atomic_flags) &&
>> +!test_and_set_bit(XDBC_ATOMIC_BULKIN,
>> +>atomic_flags))
>> +break;
>> +} while (1);
>
> homemeade spin_lock, can't the real one be used?
>
> If the xdbc_bulk_write() can be accessed from interrupt context (handler, 
> soft, timer) it
> may deadlock
>
>> +
>> +ret = xdbc_bulk_transfer(data, size, loops, true);
>> +
>> +test_and_clear_bit(XDBC_ATOMIC_BULKIN, >atomic_flags);
>> +
>> +return ret;
>> +}
>> +
>> +int xdbc_bulk_write(const char *bytes, int size)
>> +{
>> +int ret;
>> +
>> +do {
>> +if (!test_bit(XDBC_ATOMIC_BULKOUT, >atomic_flags) &&
>> +!test_and_set_bit(XDBC_ATOMIC_BULKOUT,
>> +>atomic_flags))
>> +break;
>> +} while (1);
>
> Another homemeade spin_lock, can't the real one be used?
>
> same issue here, deadlock if accessible from interrupt context.

I will try to rework this spin_lock with the real one and keep avoiding 
deadlock in mind.

>
>
> Would it make sense to have only one spinlock, and start one separate thread 
> for
> reading the event ring. The thread would,  lock, handle pending events, 
> unlock,
> then call shedule, in a loop. ehci early debug code has some variant of this.

Let me try to find this part of code.

>
> So the lock would be taken while events are being handled.
>
> The same lock would be used for bulk_read and bulk_write. Yes this would 
> prevent read and
> write at the same time, and the read and writes need to be modified to not 
> block until
> the reansfer is finished, just to write the TRBs on the ring, update ring 
> pointers,
> and ring the doorbell.
>
> Or is all this impossibe due to the earlyness of the code?

It's not only due to earlyness of the code. But also, these read/write ops were 
designed to
be used by a debugger (for example kgdb) as well. Using the kernel provided 
interface
might make things simple, but what should happen when the debugger is used
to debug the kernel subsystem itself?

So, it seems that I should implement read/write ops depends on the use case. 
For this
time being, let's focus on the boot console case.

Some transfers take place when the thread/lock subsystem is not initialized yet.
But after thread/lock subsystem is able to be used, we are able to use the real 
one.

Let me wrapper them in functions. For the transfers taken place before the 
subsystem
initialization (that's single thread context, no worry about deadlock), it will 
use the
current methods (it might be possible to drop lock due the single thread 
context),
and after the subsystem being initialized, it will use those provided by the 
kernel.

>
> -Mathias
>

Very appreciated for your time.

Regards,
-Baolu

Re: [PATCH v7 05/10] usb: dbc: add bulk out and bulk in interfaces

[Lu Baolu]

On 02/18/2016 09:32 PM, Mathias Nyman wrote:
> On 26.01.2016 14:58, Lu Baolu wrote:
>> This patch adds interfaces for bulk out and bulk in ops. These
>> interfaces could be used to implement early printk bootconsole
>> or hook to various system debuggers.
>>
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/early/xhci-dbc.c | 373 
>> +++
>>   include/linux/usb/xhci-dbc.h |  30 
>>   2 files changed, 403 insertions(+)
>>
>
> ...
>
>> +
>> +/*
>> + * Check and dispatch events in event ring. It also checks status
>> + * of hardware. This function will be called from multiple threads.
>> + * An atomic lock is applied to protect the access of event ring.
>> + */
>> +static int xdbc_check_event(void)
>> +{
>> +/* event ring is under checking by other thread? */
>> +if (!test_bit(XDBC_ATOMIC_EVENT, >atomic_flags) &&
>> +!test_and_set_bit(XDBC_ATOMIC_EVENT,
>> +>atomic_flags))
>> +return 0;
>
> homemade trylock, can't the real ones be used?
>
>> +
>> +xdbc_handle_events();
>> +
>> +test_and_clear_bit(XDBC_ATOMIC_EVENT, >atomic_flags);
>> +
>> +return 0;
>>  +}
>> +
>> +#defineBULK_IN_COMPLETED(p)((xdbcp->in_pending == (p)) && \
>> + xdbcp->in_complete)
>> +#defineBULK_OUT_COMPLETED(p)((xdbcp->out_pending == (p)) && \
>> + xdbcp->out_complete)
>> +
>
> ...
>
>> +}
>> +
>> +int xdbc_bulk_read(void *data, int size, int loops)
>> +{
>> +int ret;
>> +
>> +do {
>> +if (!test_bit(XDBC_ATOMIC_BULKIN, >atomic_flags) &&
>> +!test_and_set_bit(XDBC_ATOMIC_BULKIN,
>> +>atomic_flags))
>> +break;
>> +} while (1);
>
> homemeade spin_lock, can't the real one be used?
>
> If the xdbc_bulk_write() can be accessed from interrupt context (handler, 
> soft, timer) it
> may deadlock
>
>> +
>> +ret = xdbc_bulk_transfer(data, size, loops, true);
>> +
>> +test_and_clear_bit(XDBC_ATOMIC_BULKIN, >atomic_flags);
>> +
>> +return ret;
>> +}
>> +
>> +int xdbc_bulk_write(const char *bytes, int size)
>> +{
>> +int ret;
>> +
>> +do {
>> +if (!test_bit(XDBC_ATOMIC_BULKOUT, >atomic_flags) &&
>> +!test_and_set_bit(XDBC_ATOMIC_BULKOUT,
>> +>atomic_flags))
>> +break;
>> +} while (1);
>
> Another homemeade spin_lock, can't the real one be used?
>
> same issue here, deadlock if accessible from interrupt context.

I will try to rework this spin_lock with the real one and keep avoiding 
deadlock in mind.

>
>
> Would it make sense to have only one spinlock, and start one separate thread 
> for
> reading the event ring. The thread would,  lock, handle pending events, 
> unlock,
> then call shedule, in a loop. ehci early debug code has some variant of this.

Let me try to find this part of code.

>
> So the lock would be taken while events are being handled.
>
> The same lock would be used for bulk_read and bulk_write. Yes this would 
> prevent read and
> write at the same time, and the read and writes need to be modified to not 
> block until
> the reansfer is finished, just to write the TRBs on the ring, update ring 
> pointers,
> and ring the doorbell.
>
> Or is all this impossibe due to the earlyness of the code?

It's not only due to earlyness of the code. But also, these read/write ops were 
designed to
be used by a debugger (for example kgdb) as well. Using the kernel provided 
interface
might make things simple, but what should happen when the debugger is used
to debug the kernel subsystem itself?

So, it seems that I should implement read/write ops depends on the use case. 
For this
time being, let's focus on the boot console case.

Some transfers take place when the thread/lock subsystem is not initialized yet.
But after thread/lock subsystem is able to be used, we are able to use the real 
one.

Let me wrapper them in functions. For the transfers taken place before the 
subsystem
initialization (that's single thread context, no worry about deadlock), it will 
use the
current methods (it might be possible to drop lock due the single thread 
context),
and after the subsystem being initialized, it will use those provided by the 
kernel.

>
> -Mathias
>

Very appreciated for your time.

Regards,
-Baolu

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

[Konstantin Khlebnikov]

On Fri, Feb 19, 2016 at 9:40 AM, Konstantin Khlebnikov  wrote:
> On Fri, Feb 19, 2016 at 1:57 AM, Hugh Dickins  wrote:
>> On Thu, 18 Feb 2016, Johannes Weiner wrote:
>>
>>> Even before we added MemAvailable, users knew that page cache is
>>> easily convertible to free memory on pressure, and estimated their
>>> "available" memory by looking at the sum of MemFree, Cached, Buffers.
>>> However, "Cached" is calculated using NR_FILE_PAGES, which includes
>>> shmem and random driver pages inserted into the page tables; neither
>>> of which are easily reclaimable, or reclaimable at all. Reclaiming
>>> shmem requires swapping, which is slow. And unlike page cache, which
>>> has fairly conservative dirty limits, all of shmem needs to be written
>>> out before becoming evictable. Without swap, shmem is not evictable at
>>> all. And driver pages certainly never are.
>>>
>>> Calling these pages "Cached" is misleading and has resulted in broken
>>> formulas in userspace. They misrepresent the memory situation and
>>> cause either waste or unexpected OOM kills. With 64-bit and per-cpu
>>> memory we are way past the point where the relationship between
>>> virtual and physical memory is meaningful and users can rely on
>>> overcommit protection. OOM kills can not be avoided without wasting
>>> enormous amounts of memory this way. This shifts the management burden
>>> toward userspace, toward applications monitoring their environment and
>>> adjusting their operations. And so where statistics like /proc/meminfo
>>> used to be more informational, we have more and more software relying
>>> on them to make automated decisions based on utilization.
>>>
>>> But if userspace is supposed to take over responsibility, it needs a
>>> clear and accurate kernel interface to base its judgement on. And one
>>> of the requirements is certainly that memory consumers with wildly
>>> different reclaimability are not conflated. Adding MemAvailable is a
>>> good step in that direction, but there is software like Sigar[1] in
>>> circulation that might not get updated anytime soon. And even then,
>>> new users will continue to go for the intuitive interpretation of the
>>> Cached item. We can't blame them. There are years of tradition behind
>>> it, starting with the way free(1) and vmstat(8) have always reported
>>> free, buffers, cached. And try as we might, using "Cached" for
>>> unevictable memory is never going to be obvious.
>>>
>>> The semantics of Cached including shmem and kernel pages have been
>>> this way forever, dictated by the single-LRU implementation rather
>>> than optimal semantics. So it's an uncomfortable proposal to change it
>>> now. But what other way to fix this for existing users? What other way
>>> to make the interface more intuitive for future users? And what could
>>> break by removing it now? I guess somebody who already subtracts Shmem
>>> from Cached.
>>>
>>> What are your thoughts on this?
>>
>> My thoughts are NAK.  A misleading stat is not so bad as a
>> misleading stat whose meaning we change in some random kernel.
>>
>> By all means improve Documentation/filesystems/proc.txt on Cached.
>> By all means promote Active(file)+Inactive(file)-Buffers as often a
>> better measure (though Buffers itself is obscure to me - is it intended
>> usually to approximate resident FS metadata?).  By all means work on
>> /proc/meminfo-v2 (though that may entail dispiritingly long discussions).
>>
>> We have to assume that Cached has been useful to some people, and that
>> they've learnt to subtract Shmem from it, if slow or no swap concerns them.
>>
>> Added Konstantin to Cc: he's had valuable experience of people learning
>> to adapt to the numbers that we put out.
>>
>
> I think everything will ok. Subtraction of shmem isn't widespread practice,
> more like secret knowledge. This wasn't documented and people who use
> this should be aware that this might stop working at any time. So, ACK.

Actually, NR_FILE_PAGES could try to retire after that.
Where only few places where it is used and looks like it's easy to replace it
with something else, even more accurate.

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

[Konstantin Khlebnikov]

On Fri, Feb 19, 2016 at 9:40 AM, Konstantin Khlebnikov  wrote:
> On Fri, Feb 19, 2016 at 1:57 AM, Hugh Dickins  wrote:
>> On Thu, 18 Feb 2016, Johannes Weiner wrote:
>>
>>> Even before we added MemAvailable, users knew that page cache is
>>> easily convertible to free memory on pressure, and estimated their
>>> "available" memory by looking at the sum of MemFree, Cached, Buffers.
>>> However, "Cached" is calculated using NR_FILE_PAGES, which includes
>>> shmem and random driver pages inserted into the page tables; neither
>>> of which are easily reclaimable, or reclaimable at all. Reclaiming
>>> shmem requires swapping, which is slow. And unlike page cache, which
>>> has fairly conservative dirty limits, all of shmem needs to be written
>>> out before becoming evictable. Without swap, shmem is not evictable at
>>> all. And driver pages certainly never are.
>>>
>>> Calling these pages "Cached" is misleading and has resulted in broken
>>> formulas in userspace. They misrepresent the memory situation and
>>> cause either waste or unexpected OOM kills. With 64-bit and per-cpu
>>> memory we are way past the point where the relationship between
>>> virtual and physical memory is meaningful and users can rely on
>>> overcommit protection. OOM kills can not be avoided without wasting
>>> enormous amounts of memory this way. This shifts the management burden
>>> toward userspace, toward applications monitoring their environment and
>>> adjusting their operations. And so where statistics like /proc/meminfo
>>> used to be more informational, we have more and more software relying
>>> on them to make automated decisions based on utilization.
>>>
>>> But if userspace is supposed to take over responsibility, it needs a
>>> clear and accurate kernel interface to base its judgement on. And one
>>> of the requirements is certainly that memory consumers with wildly
>>> different reclaimability are not conflated. Adding MemAvailable is a
>>> good step in that direction, but there is software like Sigar[1] in
>>> circulation that might not get updated anytime soon. And even then,
>>> new users will continue to go for the intuitive interpretation of the
>>> Cached item. We can't blame them. There are years of tradition behind
>>> it, starting with the way free(1) and vmstat(8) have always reported
>>> free, buffers, cached. And try as we might, using "Cached" for
>>> unevictable memory is never going to be obvious.
>>>
>>> The semantics of Cached including shmem and kernel pages have been
>>> this way forever, dictated by the single-LRU implementation rather
>>> than optimal semantics. So it's an uncomfortable proposal to change it
>>> now. But what other way to fix this for existing users? What other way
>>> to make the interface more intuitive for future users? And what could
>>> break by removing it now? I guess somebody who already subtracts Shmem
>>> from Cached.
>>>
>>> What are your thoughts on this?
>>
>> My thoughts are NAK.  A misleading stat is not so bad as a
>> misleading stat whose meaning we change in some random kernel.
>>
>> By all means improve Documentation/filesystems/proc.txt on Cached.
>> By all means promote Active(file)+Inactive(file)-Buffers as often a
>> better measure (though Buffers itself is obscure to me - is it intended
>> usually to approximate resident FS metadata?).  By all means work on
>> /proc/meminfo-v2 (though that may entail dispiritingly long discussions).
>>
>> We have to assume that Cached has been useful to some people, and that
>> they've learnt to subtract Shmem from it, if slow or no swap concerns them.
>>
>> Added Konstantin to Cc: he's had valuable experience of people learning
>> to adapt to the numbers that we put out.
>>
>
> I think everything will ok. Subtraction of shmem isn't widespread practice,
> more like secret knowledge. This wasn't documented and people who use
> this should be aware that this might stop working at any time. So, ACK.

Actually, NR_FILE_PAGES could try to retire after that.
Where only few places where it is used and looks like it's easy to replace it
with something else, even more accurate.

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Anand Moon]

Hi Krzysztof,

On 19 February 2016 at 11:39, Krzysztof Kozlowski
 wrote:
> 2016-02-19 4:14 GMT+09:00 Anand Moon :
>> Hi Peter,
>>
>> On 18 February 2016 at 23:18, Peter Hurley  wrote:
>>> Hi Anand,
>>>
>>> On 02/18/2016 09:40 AM, Anand Moon wrote:
 From: Anand Moon 

 changes fix the correct order of the spin_lock_irqrestore/save.

 Signed-off-by: Anand Moon 
 ---
  drivers/tty/serial/samsung.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
 index d72cd73..96fe14d 100644
 --- a/drivers/tty/serial/samsung.c
 +++ b/drivers/tty/serial/samsung.c
 @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, 
 void *id)
   }

   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
 - spin_unlock(>lock);
 + spin_unlock_irqrestore(>lock, flags);
   uart_write_wakeup(port);
 - spin_lock(>lock);
 + spin_lock_irqsave(>lock, flags);
>>>
>>> This driver shouldn't be dropping the spin lock at for write wakeup.
>>> If this is causing lock-ups in a line discipline, the line discipline
>>> needs fixed.
>>>
>>
>> Thanks for pointing out.
>> Their is no lock up, just the inconstancy of the spin_lock.
>> Then I will resend this patch dropping the spin_unlock/spin_lock
>> around uart_write_wakeup.
>> Is that ok with you.
>
> Anand, before doing that, can you check Peter's second sentence? I
> mean the "If this is causing lock-ups in a line discipline, the line
> discipline needs fixed.".
> Don't drop the spin-locks "just because". I would be happy to see more
> detailed explanation in changelog.
>
> Best regards,
> Krzysztof

Yes I understood the meaning of the sentence. Already the
s3c24xx_serial_tx_chars function.
holds the lock port->lock for safe IRQ execution.

http://lxr.free-electrons.com/source/drivers/tty/serial/samsung.c#L701

Best Regards
-Anand Moon

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Anand Moon]

Hi Krzysztof,

On 19 February 2016 at 11:39, Krzysztof Kozlowski
 wrote:
> 2016-02-19 4:14 GMT+09:00 Anand Moon :
>> Hi Peter,
>>
>> On 18 February 2016 at 23:18, Peter Hurley  wrote:
>>> Hi Anand,
>>>
>>> On 02/18/2016 09:40 AM, Anand Moon wrote:
 From: Anand Moon 

 changes fix the correct order of the spin_lock_irqrestore/save.

 Signed-off-by: Anand Moon 
 ---
  drivers/tty/serial/samsung.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
 index d72cd73..96fe14d 100644
 --- a/drivers/tty/serial/samsung.c
 +++ b/drivers/tty/serial/samsung.c
 @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, 
 void *id)
   }

   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
 - spin_unlock(>lock);
 + spin_unlock_irqrestore(>lock, flags);
   uart_write_wakeup(port);
 - spin_lock(>lock);
 + spin_lock_irqsave(>lock, flags);
>>>
>>> This driver shouldn't be dropping the spin lock at for write wakeup.
>>> If this is causing lock-ups in a line discipline, the line discipline
>>> needs fixed.
>>>
>>
>> Thanks for pointing out.
>> Their is no lock up, just the inconstancy of the spin_lock.
>> Then I will resend this patch dropping the spin_unlock/spin_lock
>> around uart_write_wakeup.
>> Is that ok with you.
>
> Anand, before doing that, can you check Peter's second sentence? I
> mean the "If this is causing lock-ups in a line discipline, the line
> discipline needs fixed.".
> Don't drop the spin-locks "just because". I would be happy to see more
> detailed explanation in changelog.
>
> Best regards,
> Krzysztof

Yes I understood the meaning of the sentence. Already the
s3c24xx_serial_tx_chars function.
holds the lock port->lock for safe IRQ execution.

http://lxr.free-electrons.com/source/drivers/tty/serial/samsung.c#L701

Best Regards
-Anand Moon

[PATCH v2 1/3] tools/liblockdep: add userspace version of READ_ONCE

[Alfredo Alvarez Fernandez]

From: Alfredo Alvarez Fernandez 

This was added to the kernel code in <1658d35ead5d> ("list: Use
READ_ONCE() when testing for empty lists")
There's nothing special we need to do about it in userspace.

Signed-off-by: Alfredo Alvarez Fernandez 
---
 tools/lib/lockdep/uinclude/linux/compiler.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/lib/lockdep/uinclude/linux/compiler.h 
b/tools/lib/lockdep/uinclude/linux/compiler.h
index 6386dc3..fd3e56a 100644
--- a/tools/lib/lockdep/uinclude/linux/compiler.h
+++ b/tools/lib/lockdep/uinclude/linux/compiler.h
@@ -3,6 +3,7 @@
 
 #define __used __attribute__((__unused__))
 #define unlikely
+#define READ_ONCE(x) (x)
 #define WRITE_ONCE(x, val) x=(val)
 #define RCU_INIT_POINTER(p, v) p=(v)
 
-- 
2.5.0

[PATCH v2 1/3] tools/liblockdep: add userspace version of READ_ONCE

[Alfredo Alvarez Fernandez]

From: Alfredo Alvarez Fernandez 

This was added to the kernel code in <1658d35ead5d> ("list: Use
READ_ONCE() when testing for empty lists")
There's nothing special we need to do about it in userspace.

Signed-off-by: Alfredo Alvarez Fernandez 
---
 tools/lib/lockdep/uinclude/linux/compiler.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/lib/lockdep/uinclude/linux/compiler.h 
b/tools/lib/lockdep/uinclude/linux/compiler.h
index 6386dc3..fd3e56a 100644
--- a/tools/lib/lockdep/uinclude/linux/compiler.h
+++ b/tools/lib/lockdep/uinclude/linux/compiler.h
@@ -3,6 +3,7 @@
 
 #define __used __attribute__((__unused__))
 #define unlikely
+#define READ_ONCE(x) (x)
 #define WRITE_ONCE(x, val) x=(val)
 #define RCU_INIT_POINTER(p, v) p=(v)
 
-- 
2.5.0

Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA

[Alexander Kochetkov]

Hello, here comments from Shawn Lin:

19 февр. 2016 г., в 9:46, Shawn Lin  написал(а):

Seriously review the patch again, commit 271e1b86e691 "dmaengine:
pl330: add quirk for broken no flushp" has not chance to break
the platforms which don't add quirk inside the dts stuff.
as well as the other works from rockchip.

But refer to Boojin Kim's patch,
dmaengine: pl330: support burst mode for dev-to-mem and mem-to-dev transmit

may some platforms can't support multi-burst? If that's the case,
the been-broken driver should limit the maxburst.

2016-02-17 14:12 GMT+03:00 Bartlomiej Zolnierkiewicz :
>
> Hi,
>
> On Thursday, February 11, 2016 02:27:51 PM Vinod Koul wrote:
>> On Wed, Feb 10, 2016 at 03:56:17PM -0600, Dinh Nguyen wrote:
>> > Hi Vinod,
>> >
>> > It appears that commit 271e1b86e691 "dmaengine: pl330: add quirk for
>> > broken no flushp" is breaking uart dma on SoCFPGA. This commit is in
>> > linux-next(next-20160210).
>> >
>> > Doing a bisect pointed to commit 271e1b86e691, but I had to also revert
>> > the following commits (86a8ce7d4103 "dmaengine: pl330: add max burst for
>> > dmaengine") and (848e9776fee4 "dmaengine: pl330: support burst mode for
>> > dev-to-mem and mem-to-dev transmit") as well because the build would
>> > fail if I only revert 271e1b86e691.
>> >
>> > The SoCFPGA platform is being tested on Olof's board farm and is failing
>> > multi_v7_defconfig build because the PL330 DMA is enabled in this 
>> > defconfig.
>> >
>> > After doing reverts of those 3 commits, the socfpga platform is able
>> > boot completely again with multi_v7_defconfig.
>>
>> Okay I am removing this topic from next. Also I can drop the series unless
>> someone sends me a fix in couple of days..
>
> I've noticed that these commits also break UART DMA on Samsung Exynos4412
> SoCs (I got similar bisection results as Dinh when I've noticed issue
> with next-20160211 kernel).
>
> Caesar, please keep me on Cc: for potential fix(es) / revised patches
> (I'll be happy to test them).
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>

Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA

[Alexander Kochetkov]

Hello, here comments from Shawn Lin:

19 февр. 2016 г., в 9:46, Shawn Lin  написал(а):

Seriously review the patch again, commit 271e1b86e691 "dmaengine:
pl330: add quirk for broken no flushp" has not chance to break
the platforms which don't add quirk inside the dts stuff.
as well as the other works from rockchip.

But refer to Boojin Kim's patch,
dmaengine: pl330: support burst mode for dev-to-mem and mem-to-dev transmit

may some platforms can't support multi-burst? If that's the case,
the been-broken driver should limit the maxburst.

2016-02-17 14:12 GMT+03:00 Bartlomiej Zolnierkiewicz :
>
> Hi,
>
> On Thursday, February 11, 2016 02:27:51 PM Vinod Koul wrote:
>> On Wed, Feb 10, 2016 at 03:56:17PM -0600, Dinh Nguyen wrote:
>> > Hi Vinod,
>> >
>> > It appears that commit 271e1b86e691 "dmaengine: pl330: add quirk for
>> > broken no flushp" is breaking uart dma on SoCFPGA. This commit is in
>> > linux-next(next-20160210).
>> >
>> > Doing a bisect pointed to commit 271e1b86e691, but I had to also revert
>> > the following commits (86a8ce7d4103 "dmaengine: pl330: add max burst for
>> > dmaengine") and (848e9776fee4 "dmaengine: pl330: support burst mode for
>> > dev-to-mem and mem-to-dev transmit") as well because the build would
>> > fail if I only revert 271e1b86e691.
>> >
>> > The SoCFPGA platform is being tested on Olof's board farm and is failing
>> > multi_v7_defconfig build because the PL330 DMA is enabled in this 
>> > defconfig.
>> >
>> > After doing reverts of those 3 commits, the socfpga platform is able
>> > boot completely again with multi_v7_defconfig.
>>
>> Okay I am removing this topic from next. Also I can drop the series unless
>> someone sends me a fix in couple of days..
>
> I've noticed that these commits also break UART DMA on Samsung Exynos4412
> SoCs (I got similar bisection results as Dinh when I've noticed issue
> with next-20160211 kernel).
>
> Caesar, please keep me on Cc: for potential fix(es) / revised patches
> (I'll be happy to test them).
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>

[PATCH v2 0/3] lockdep: liblockdep: Prevent chain_key collisions

[Alfredo Alvarez Fernandez]

This patch series prevents possible collisions in the chain_key
hashing macro iterate_chain_key(key1, key2) that can lead to lockdep
not detecting very simple deadlocks such as AA or ABBA.

The problem only affects the first allocated lock classes. That could
explain why it was not seen while running lockdep's test suite, since
by the time the test suite runs there are already registered lock
classes and the indexes allocated for the lock classes under test are
high enough to avoid collisions.

The patch series also extends the tools/liblockdep test suite with
tests covering the offending cases.

I came across the problem while testing a simple AA deadlock scenario
in userspace using a pthread_mutex and tools/liblockdep. In that
context it is fairly easy to have a clean and deterministic initial
state where the problem can be reproduced.

The proposed solution was tested with the newly introduced tests and
also with lockdep's test suite:
 [0.00] Good, all 253 testcases passed! |

v2:
  - Add detection for chain_key collisions under CONFIG_DEBUG_LOCKDEP.
When a collision is detected the problem is reported and all lock
debugging is turned off.

Tested using liblockdep and the added tests before and after
applying the fix, confirming both that the code added for the
detection correctly reports the problem and that the fix actually
fixes it.

Tested tweaking lockdep to generate false collisions and
verified that the problem is reported and that lock debugging is 
turned off.

Also tested with lockdep's test suite after applying the patch:
[0.00] Good, all 253 testcases passed! |

  - Fix code style problems in added liblockdep tests

Alfredo Alvarez Fernandez (3):
  tools/liblockdep: add userspace version of READ_ONCE
  tools/liblockdep: add tests
  lockdep: prevent and detect chain_key collisions

 kernel/locking/lockdep.c| 73 ++---
 tools/lib/lockdep/tests/AA.c|  8 ++--
 tools/lib/lockdep/tests/ABA.c   | 13 +
 tools/lib/lockdep/tests/ABBA_2threads.c | 46 ++
 tools/lib/lockdep/uinclude/linux/compiler.h |  1 +
 5 files changed, 121 insertions(+), 20 deletions(-)
 create mode 100644 tools/lib/lockdep/tests/ABA.c
 create mode 100644 tools/lib/lockdep/tests/ABBA_2threads.c

-- 
2.5.0

[PATCH v2 3/3] lockdep: prevent and detect chain_key collisions

[Alfredo Alvarez Fernandez]

From: Alfredo Alvarez Fernandez 

The chain_key hashing macro iterate_chain_key(key1, key2) does not
generate a new different value if both key1 and key2 are 0. In that
case the generated value is again 0. This can lead to collisions which
can result in lockdep not detecting deadlocks or circular
dependencies.

Avoid the problem by using class_idx (1-based) instead of class id
(0-based) as an input for the hashing macro 'key2' in
iterate_chain_key(key1, key2).

The use of class id created collisions in cases like the following:

1.- Consider an initial state in which no class has been acquired yet.
Under these circumstances an AA deadlock will not be detected by
lockdep:

  lock  [key1,key2]->new key  (key1=old chain_key, key2=id)
  --
  A [0,0]->0
  A [0,0]->0 (collision)

  The newly generated chain_key collides with the one used before and as
  a result the check for a deadlock is skipped

  A simple test using liblockdep and a pthread mutex confirms the
  problem: (omitting stack traces)

new class 0xe15038: 0x7ffc64950f20
acquire class [0xe15038] 0x7ffc64950f20
acquire class [0xe15038] 0x7ffc64950f20
hash chain already cached, key:  tail class:
[0xe15038] 0x7ffc64950f20

2.- Consider an ABBA in 2 different tasks and no class yet acquired.

  T1 [key1,key2]->new key T2[key1,key2]->new key
  --  --
  A [0,0]->0

  B [0,1]->1

  B [0,1]->1  (collision)

  A

  In this case the collision prevents lockdep from creating the new
dependency A->B. This in turn results in lockdep not detecting the
circular dependency when T2 acquires A.

Add detection for chain_key collision under CONFIG_DEBUG_LOCKDEP.
When a collision is detected the problem is reported and all lock
debugging is turned off.

Signed-off-by: Alfredo Alvarez Fernandez 
---
Changes in v2:
  - Add detection for chain_key collisions under CONFIG_DEBUG_LOCKDEP.
When a collision is detected the problem is reported and all lock
debugging is turned off.

Tested using liblockdep and the added tests before and after
applying the fix, confirming both that the code added for the
detection correctly reports the problem and that the fix actually
fixes it.

Tested tweaking lockdep to generate false collisions and
verified that the problem is reported and that lock debugging is 
turned off.

Also tested with lockdep's test suite after applying the patch:
[0.00] Good, all 253 testcases passed! |

 kernel/locking/lockdep.c | 73 +---
 1 file changed, 57 insertions(+), 16 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 60ace56..2c28298 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2007,6 +2007,53 @@ struct lock_class *lock_chain_get_class(struct 
lock_chain *chain, int i)
 }
 
 /*
+ * Returns the index of the first held_lock of the current chain
+ */
+static inline int get_first_held_lock(struct task_struct *curr,
+   struct held_lock *hlock)
+{
+   int i;
+   struct held_lock *hlock_curr;
+
+   for (i = curr->lockdep_depth - 1; i >= 0; i--) {
+   hlock_curr = curr->held_locks + i;
+   if (hlock_curr->irq_context != hlock->irq_context)
+   break;
+
+   }
+
+   return ++i;
+}
+
+/*
+ * Checks whether the chain and the current held locks are consistent
+ * in depth and also in content. If they are not it most likely means
+ * that there was a collision during the calculation of the chain_key.
+ * Returns: 0 not passed, 1 passed
+ */
+static int check_no_collision(struct task_struct *curr,
+   struct held_lock *hlock,
+   struct lock_chain *chain)
+{
+#ifdef CONFIG_DEBUG_LOCKDEP
+   int i, j, id;
+
+   i = get_first_held_lock(curr, hlock);
+
+   if (DEBUG_LOCKS_WARN_ON(chain->depth != curr->lockdep_depth - (i - 1)))
+   return 0;
+
+   for (j = 0; j < chain->depth - 1; j++, i++) {
+   id = curr->held_locks[i].class_idx - 1;
+
+   if (DEBUG_LOCKS_WARN_ON(chain_hlocks[chain->base + j] != id))
+   return 0;
+   }
+#endif
+   return 1;
+}
+
+/*
  * Look up a dependency chain. If the key is not present yet then
  * add it and return 1 - in this case the new dependency chain is
  * validated. If the key is already hashed, return 0.
@@ -2019,7 +2066,6 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
struct lock_class *class = hlock_class(hlock);
struct list_head *hash_head = chainhashentry(chain_key);
struct lock_chain *chain;
-   struct held_lock *hlock_curr;
int i, j;
 
/*
@@ -2037,6 +2083,9 @@ static inline int 

[PATCH v2 0/3] lockdep: liblockdep: Prevent chain_key collisions

[Alfredo Alvarez Fernandez]

This patch series prevents possible collisions in the chain_key
hashing macro iterate_chain_key(key1, key2) that can lead to lockdep
not detecting very simple deadlocks such as AA or ABBA.

The problem only affects the first allocated lock classes. That could
explain why it was not seen while running lockdep's test suite, since
by the time the test suite runs there are already registered lock
classes and the indexes allocated for the lock classes under test are
high enough to avoid collisions.

The patch series also extends the tools/liblockdep test suite with
tests covering the offending cases.

I came across the problem while testing a simple AA deadlock scenario
in userspace using a pthread_mutex and tools/liblockdep. In that
context it is fairly easy to have a clean and deterministic initial
state where the problem can be reproduced.

The proposed solution was tested with the newly introduced tests and
also with lockdep's test suite:
 [0.00] Good, all 253 testcases passed! |

v2:
  - Add detection for chain_key collisions under CONFIG_DEBUG_LOCKDEP.
When a collision is detected the problem is reported and all lock
debugging is turned off.

Tested using liblockdep and the added tests before and after
applying the fix, confirming both that the code added for the
detection correctly reports the problem and that the fix actually
fixes it.

Tested tweaking lockdep to generate false collisions and
verified that the problem is reported and that lock debugging is 
turned off.

Also tested with lockdep's test suite after applying the patch:
[0.00] Good, all 253 testcases passed! |

  - Fix code style problems in added liblockdep tests

Alfredo Alvarez Fernandez (3):
  tools/liblockdep: add userspace version of READ_ONCE
  tools/liblockdep: add tests
  lockdep: prevent and detect chain_key collisions

 kernel/locking/lockdep.c| 73 ++---
 tools/lib/lockdep/tests/AA.c|  8 ++--
 tools/lib/lockdep/tests/ABA.c   | 13 +
 tools/lib/lockdep/tests/ABBA_2threads.c | 46 ++
 tools/lib/lockdep/uinclude/linux/compiler.h |  1 +
 5 files changed, 121 insertions(+), 20 deletions(-)
 create mode 100644 tools/lib/lockdep/tests/ABA.c
 create mode 100644 tools/lib/lockdep/tests/ABBA_2threads.c

-- 
2.5.0

[PATCH v2 3/3] lockdep: prevent and detect chain_key collisions

[Alfredo Alvarez Fernandez]

From: Alfredo Alvarez Fernandez 

The chain_key hashing macro iterate_chain_key(key1, key2) does not
generate a new different value if both key1 and key2 are 0. In that
case the generated value is again 0. This can lead to collisions which
can result in lockdep not detecting deadlocks or circular
dependencies.

Avoid the problem by using class_idx (1-based) instead of class id
(0-based) as an input for the hashing macro 'key2' in
iterate_chain_key(key1, key2).

The use of class id created collisions in cases like the following:

1.- Consider an initial state in which no class has been acquired yet.
Under these circumstances an AA deadlock will not be detected by
lockdep:

  lock  [key1,key2]->new key  (key1=old chain_key, key2=id)
  --
  A [0,0]->0
  A [0,0]->0 (collision)

  The newly generated chain_key collides with the one used before and as
  a result the check for a deadlock is skipped

  A simple test using liblockdep and a pthread mutex confirms the
  problem: (omitting stack traces)

new class 0xe15038: 0x7ffc64950f20
acquire class [0xe15038] 0x7ffc64950f20
acquire class [0xe15038] 0x7ffc64950f20
hash chain already cached, key:  tail class:
[0xe15038] 0x7ffc64950f20

2.- Consider an ABBA in 2 different tasks and no class yet acquired.

  T1 [key1,key2]->new key T2[key1,key2]->new key
  --  --
  A [0,0]->0

  B [0,1]->1

  B [0,1]->1  (collision)

  A

  In this case the collision prevents lockdep from creating the new
dependency A->B. This in turn results in lockdep not detecting the
circular dependency when T2 acquires A.

Add detection for chain_key collision under CONFIG_DEBUG_LOCKDEP.
When a collision is detected the problem is reported and all lock
debugging is turned off.

Signed-off-by: Alfredo Alvarez Fernandez 
---
Changes in v2:
  - Add detection for chain_key collisions under CONFIG_DEBUG_LOCKDEP.
When a collision is detected the problem is reported and all lock
debugging is turned off.

Tested using liblockdep and the added tests before and after
applying the fix, confirming both that the code added for the
detection correctly reports the problem and that the fix actually
fixes it.

Tested tweaking lockdep to generate false collisions and
verified that the problem is reported and that lock debugging is 
turned off.

Also tested with lockdep's test suite after applying the patch:
[0.00] Good, all 253 testcases passed! |

 kernel/locking/lockdep.c | 73 +---
 1 file changed, 57 insertions(+), 16 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 60ace56..2c28298 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2007,6 +2007,53 @@ struct lock_class *lock_chain_get_class(struct 
lock_chain *chain, int i)
 }
 
 /*
+ * Returns the index of the first held_lock of the current chain
+ */
+static inline int get_first_held_lock(struct task_struct *curr,
+   struct held_lock *hlock)
+{
+   int i;
+   struct held_lock *hlock_curr;
+
+   for (i = curr->lockdep_depth - 1; i >= 0; i--) {
+   hlock_curr = curr->held_locks + i;
+   if (hlock_curr->irq_context != hlock->irq_context)
+   break;
+
+   }
+
+   return ++i;
+}
+
+/*
+ * Checks whether the chain and the current held locks are consistent
+ * in depth and also in content. If they are not it most likely means
+ * that there was a collision during the calculation of the chain_key.
+ * Returns: 0 not passed, 1 passed
+ */
+static int check_no_collision(struct task_struct *curr,
+   struct held_lock *hlock,
+   struct lock_chain *chain)
+{
+#ifdef CONFIG_DEBUG_LOCKDEP
+   int i, j, id;
+
+   i = get_first_held_lock(curr, hlock);
+
+   if (DEBUG_LOCKS_WARN_ON(chain->depth != curr->lockdep_depth - (i - 1)))
+   return 0;
+
+   for (j = 0; j < chain->depth - 1; j++, i++) {
+   id = curr->held_locks[i].class_idx - 1;
+
+   if (DEBUG_LOCKS_WARN_ON(chain_hlocks[chain->base + j] != id))
+   return 0;
+   }
+#endif
+   return 1;
+}
+
+/*
  * Look up a dependency chain. If the key is not present yet then
  * add it and return 1 - in this case the new dependency chain is
  * validated. If the key is already hashed, return 0.
@@ -2019,7 +2066,6 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
struct lock_class *class = hlock_class(hlock);
struct list_head *hash_head = chainhashentry(chain_key);
struct lock_chain *chain;
-   struct held_lock *hlock_curr;
int i, j;
 
/*
@@ -2037,6 +2083,9 @@ static inline int lookup_chain_cache(struct task_struct 
*curr,
if 

[PATCH v2 2/3] tools/liblockdep: add tests

[Alfredo Alvarez Fernandez]

From: Alfredo Alvarez Fernandez 

Add test for AA and 2 threaded ABBA locking.

Rename AA.c to ABA.c since it was implementing an ABA instead of a pure
AA. Now both cases are covered.

The expected output for AA.c is that the process blocks and lockdep
reports a deadlock.

ABBA_2threads.c differs from ABBA.c in that lockdep keeps separate chains
of held locks per task. This can lead to different behaviour regarding
lock detection. The expected output for this test is that the process
blocks and lockdep reports a circular locking dependency.

Signed-off-by: Alfredo Alvarez Fernandez 
---
Changes in v2:
  - Fix style problems in added tests

 tools/lib/lockdep/tests/AA.c|  8 +++---
 tools/lib/lockdep/tests/ABA.c   | 13 ++
 tools/lib/lockdep/tests/ABBA_2threads.c | 46 +
 3 files changed, 63 insertions(+), 4 deletions(-)
 create mode 100644 tools/lib/lockdep/tests/ABA.c
 create mode 100644 tools/lib/lockdep/tests/ABBA_2threads.c

diff --git a/tools/lib/lockdep/tests/AA.c b/tools/lib/lockdep/tests/AA.c
index 0f782ff..18211a5 100644
--- a/tools/lib/lockdep/tests/AA.c
+++ b/tools/lib/lockdep/tests/AA.c
@@ -1,13 +1,13 @@
 #include 
 
-void main(void)
+int main(void)
 {
-   pthread_mutex_t a, b;
+   pthread_mutex_t a;
 
pthread_mutex_init(, NULL);
-   pthread_mutex_init(, NULL);
 
pthread_mutex_lock();
-   pthread_mutex_lock();
pthread_mutex_lock();
+
+   return 0;
 }
diff --git a/tools/lib/lockdep/tests/ABA.c b/tools/lib/lockdep/tests/ABA.c
new file mode 100644
index 000..0f782ff
--- /dev/null
+++ b/tools/lib/lockdep/tests/ABA.c
@@ -0,0 +1,13 @@
+#include 
+
+void main(void)
+{
+   pthread_mutex_t a, b;
+
+   pthread_mutex_init(, NULL);
+   pthread_mutex_init(, NULL);
+
+   pthread_mutex_lock();
+   pthread_mutex_lock();
+   pthread_mutex_lock();
+}
diff --git a/tools/lib/lockdep/tests/ABBA_2threads.c 
b/tools/lib/lockdep/tests/ABBA_2threads.c
new file mode 100644
index 000..cd807d7
--- /dev/null
+++ b/tools/lib/lockdep/tests/ABBA_2threads.c
@@ -0,0 +1,46 @@
+#include 
+#include 
+
+pthread_mutex_t a = PTHREAD_MUTEX_INITIALIZER;
+pthread_mutex_t b = PTHREAD_MUTEX_INITIALIZER;
+pthread_barrier_t bar;
+
+void *ba_lock(void *arg)
+{
+   int ret, i;
+
+   pthread_mutex_lock();
+
+   if (pthread_barrier_wait() == PTHREAD_BARRIER_SERIAL_THREAD)
+   pthread_barrier_destroy();
+
+   pthread_mutex_lock();
+
+   pthread_mutex_unlock();
+   pthread_mutex_unlock();
+}
+
+int main(void)
+{
+   pthread_t t;
+
+   pthread_barrier_init(, NULL, 2);
+
+   if (pthread_create(, NULL, ba_lock, NULL)) {
+   fprintf(stderr, "pthread_create() failed\n");
+   return 1;
+   }
+   pthread_mutex_lock();
+
+   if (pthread_barrier_wait() == PTHREAD_BARRIER_SERIAL_THREAD)
+   pthread_barrier_destroy();
+
+   pthread_mutex_lock();
+
+   pthread_mutex_unlock();
+   pthread_mutex_unlock();
+
+   pthread_join(t, NULL);
+
+   return 0;
+}
-- 
2.5.0

Re: [lkp] [xfs] fbcc025613: -5.6% fsmark.files_per_sec

[Dave Chinner]

On Fri, Feb 19, 2016 at 10:52:08AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit fbcc025613590d7b1d15521555dcc6393a148a6b ("xfs: Introduce writeback 
> context for writepages")
> 
> 
> =
> compiler/cpufreq_governor/disk/filesize/fs/iterations/kconfig/md/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase:
>   
> gcc-4.9/performance/8BRD_12G/4M/xfs/1x/x86_64-rhel/RAID0/1t/debian-x86_64-2015-02-07.cgz/fsyncBeforeClose/lkp-hsx02/60G/fsmark
> 
> commit: 
>   150d5be09ce49a9bed6feb7b7dc4e5ae188778ec
>   fbcc025613590d7b1d15521555dcc6393a148a6b
> 
> 150d5be09ce49a9b fbcc025613590d7b1d15521555 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>  36122 ±  0% -57.4%  15404 ±  0%  
> fsmark.time.involuntary_context_switches
>  95.30 ±  0%  +1.8%  97.00 ±  0%  
> fsmark.time.percent_of_cpu_this_job_got
>  25339 ± 32%   +5756.0%1483901 ±  1%  
> fsmark.time.voluntary_context_switches
> 881.80 ± 45%  +14258.5% 126613 ± 10%  
> latency_stats.hits.wait_on_page_bit.__filemap_fdatawait_range.filemap_fdatawait_range.filemap_write_and_wait_range.xfs_file_fsync.vfs_fsync_range.do_fsync.SyS_fsync.entry_SYSCALL_64_fastpath
>   3548 ± 48%  +11967.4% 428200 ±  7%  
> latency_stats.sum.wait_on_page_bit.__filemap_fdatawait_range.filemap_fdatawait_range.filemap_write_and_wait_range.xfs_file_fsync.vfs_fsync_range.do_fsync.SyS_fsync.entry_SYSCALL_64_fastpath
.
> 2016-02-17 22:08:15 mount -t xfs -o nobarrier,inode64 /dev/ram0 /fs/ram0
> 2016-02-17 22:08:16 ./fs_mark -d /fs/ram0/1 -n 10240 -L 1 -S 1 -s 4194304

Ok, so 10k x 4MB files, fsync after each. Let me go look.

So the problem above appears to be that fsync is waiting on 125,000
more pages to complete IO, causing a major increase in context
switches during fsync. With only 1 files being created, that
mores than 10 pages per file that is being waited on.

That doesn't really seem right. The writeback should be done as a
single ioend, with a single completion, with a single setsize
transaction, adn then all the pages are marked clean sequentially.
The above behaviour implies we are ending up doing something like:

fsync proc  io completion
wait on page 0
end page 0 writeback
wake up page 0
wait on page 1
end page 1 writeback
wake up page 1
wait on page 2
end page 2 writeback
wake up page 2

Though in slightly larger batches than a single page (10 wakeups a
file, so batches of around 100 pages per wakeup?). i.e. the fsync
IO wait appears to be racing with IO completion marking pages as
done. I simply cannot see how the above change would cause that, as
it was simply a change in the IO submission code that doesn't affect
overall size or shape of the IOs being submitted.

This is a patch in the middle of a larger patch set - if any of the
patches in that series should affect behaviour, it's the commit a
couple further that removed the XFS page clustering code - that
changes the size and shape of the ioends and bios we build and
submit and so if anything is perturbing Io completion behaviour I'd
expect those to be the culprit

Does this same problem context switch problem still exist when the
entire set of patches in the XFs series has been applied? I can't
reproduce it here locally with the entire series applied, but I have
only tested on 16p with 48GB RAM. The context switch rate does not
go above 3,000/s, regardless of whether I use a ramdisk or high
throughput SSDs. Tracing also clearly indicates a single 4MB ioend
is being build and submitted by the new code and so that implies
that the io completions that are occuring before and after this
patchset are identical, and so therefore the way pages are moving
from dirty -> writeback -> clean is identical before and after the
patch series.

So, like I said - this makes no sense to me from the perspective of
the change that you've bisected it down to. This smells to me of a
scheduler change in the linux-next tree, espcially as I can't
reproduce the behaviour with just the XFS commits in isolation on a
4.5-rc3 tree.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[PATCH v2 2/3] tools/liblockdep: add tests

[Alfredo Alvarez Fernandez]

From: Alfredo Alvarez Fernandez 

Add test for AA and 2 threaded ABBA locking.

Rename AA.c to ABA.c since it was implementing an ABA instead of a pure
AA. Now both cases are covered.

The expected output for AA.c is that the process blocks and lockdep
reports a deadlock.

ABBA_2threads.c differs from ABBA.c in that lockdep keeps separate chains
of held locks per task. This can lead to different behaviour regarding
lock detection. The expected output for this test is that the process
blocks and lockdep reports a circular locking dependency.

Signed-off-by: Alfredo Alvarez Fernandez 
---
Changes in v2:
  - Fix style problems in added tests

 tools/lib/lockdep/tests/AA.c|  8 +++---
 tools/lib/lockdep/tests/ABA.c   | 13 ++
 tools/lib/lockdep/tests/ABBA_2threads.c | 46 +
 3 files changed, 63 insertions(+), 4 deletions(-)
 create mode 100644 tools/lib/lockdep/tests/ABA.c
 create mode 100644 tools/lib/lockdep/tests/ABBA_2threads.c

diff --git a/tools/lib/lockdep/tests/AA.c b/tools/lib/lockdep/tests/AA.c
index 0f782ff..18211a5 100644
--- a/tools/lib/lockdep/tests/AA.c
+++ b/tools/lib/lockdep/tests/AA.c
@@ -1,13 +1,13 @@
 #include 
 
-void main(void)
+int main(void)
 {
-   pthread_mutex_t a, b;
+   pthread_mutex_t a;
 
pthread_mutex_init(, NULL);
-   pthread_mutex_init(, NULL);
 
pthread_mutex_lock();
-   pthread_mutex_lock();
pthread_mutex_lock();
+
+   return 0;
 }
diff --git a/tools/lib/lockdep/tests/ABA.c b/tools/lib/lockdep/tests/ABA.c
new file mode 100644
index 000..0f782ff
--- /dev/null
+++ b/tools/lib/lockdep/tests/ABA.c
@@ -0,0 +1,13 @@
+#include 
+
+void main(void)
+{
+   pthread_mutex_t a, b;
+
+   pthread_mutex_init(, NULL);
+   pthread_mutex_init(, NULL);
+
+   pthread_mutex_lock();
+   pthread_mutex_lock();
+   pthread_mutex_lock();
+}
diff --git a/tools/lib/lockdep/tests/ABBA_2threads.c 
b/tools/lib/lockdep/tests/ABBA_2threads.c
new file mode 100644
index 000..cd807d7
--- /dev/null
+++ b/tools/lib/lockdep/tests/ABBA_2threads.c
@@ -0,0 +1,46 @@
+#include 
+#include 
+
+pthread_mutex_t a = PTHREAD_MUTEX_INITIALIZER;
+pthread_mutex_t b = PTHREAD_MUTEX_INITIALIZER;
+pthread_barrier_t bar;
+
+void *ba_lock(void *arg)
+{
+   int ret, i;
+
+   pthread_mutex_lock();
+
+   if (pthread_barrier_wait() == PTHREAD_BARRIER_SERIAL_THREAD)
+   pthread_barrier_destroy();
+
+   pthread_mutex_lock();
+
+   pthread_mutex_unlock();
+   pthread_mutex_unlock();
+}
+
+int main(void)
+{
+   pthread_t t;
+
+   pthread_barrier_init(, NULL, 2);
+
+   if (pthread_create(, NULL, ba_lock, NULL)) {
+   fprintf(stderr, "pthread_create() failed\n");
+   return 1;
+   }
+   pthread_mutex_lock();
+
+   if (pthread_barrier_wait() == PTHREAD_BARRIER_SERIAL_THREAD)
+   pthread_barrier_destroy();
+
+   pthread_mutex_lock();
+
+   pthread_mutex_unlock();
+   pthread_mutex_unlock();
+
+   pthread_join(t, NULL);
+
+   return 0;
+}
-- 
2.5.0

Re: [lkp] [xfs] fbcc025613: -5.6% fsmark.files_per_sec

[Dave Chinner]

On Fri, Feb 19, 2016 at 10:52:08AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit fbcc025613590d7b1d15521555dcc6393a148a6b ("xfs: Introduce writeback 
> context for writepages")
> 
> 
> =
> compiler/cpufreq_governor/disk/filesize/fs/iterations/kconfig/md/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase:
>   
> gcc-4.9/performance/8BRD_12G/4M/xfs/1x/x86_64-rhel/RAID0/1t/debian-x86_64-2015-02-07.cgz/fsyncBeforeClose/lkp-hsx02/60G/fsmark
> 
> commit: 
>   150d5be09ce49a9bed6feb7b7dc4e5ae188778ec
>   fbcc025613590d7b1d15521555dcc6393a148a6b
> 
> 150d5be09ce49a9b fbcc025613590d7b1d15521555 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>  36122 ±  0% -57.4%  15404 ±  0%  
> fsmark.time.involuntary_context_switches
>  95.30 ±  0%  +1.8%  97.00 ±  0%  
> fsmark.time.percent_of_cpu_this_job_got
>  25339 ± 32%   +5756.0%1483901 ±  1%  
> fsmark.time.voluntary_context_switches
> 881.80 ± 45%  +14258.5% 126613 ± 10%  
> latency_stats.hits.wait_on_page_bit.__filemap_fdatawait_range.filemap_fdatawait_range.filemap_write_and_wait_range.xfs_file_fsync.vfs_fsync_range.do_fsync.SyS_fsync.entry_SYSCALL_64_fastpath
>   3548 ± 48%  +11967.4% 428200 ±  7%  
> latency_stats.sum.wait_on_page_bit.__filemap_fdatawait_range.filemap_fdatawait_range.filemap_write_and_wait_range.xfs_file_fsync.vfs_fsync_range.do_fsync.SyS_fsync.entry_SYSCALL_64_fastpath
.
> 2016-02-17 22:08:15 mount -t xfs -o nobarrier,inode64 /dev/ram0 /fs/ram0
> 2016-02-17 22:08:16 ./fs_mark -d /fs/ram0/1 -n 10240 -L 1 -S 1 -s 4194304

Ok, so 10k x 4MB files, fsync after each. Let me go look.

So the problem above appears to be that fsync is waiting on 125,000
more pages to complete IO, causing a major increase in context
switches during fsync. With only 1 files being created, that
mores than 10 pages per file that is being waited on.

That doesn't really seem right. The writeback should be done as a
single ioend, with a single completion, with a single setsize
transaction, adn then all the pages are marked clean sequentially.
The above behaviour implies we are ending up doing something like:

fsync proc  io completion
wait on page 0
end page 0 writeback
wake up page 0
wait on page 1
end page 1 writeback
wake up page 1
wait on page 2
end page 2 writeback
wake up page 2

Though in slightly larger batches than a single page (10 wakeups a
file, so batches of around 100 pages per wakeup?). i.e. the fsync
IO wait appears to be racing with IO completion marking pages as
done. I simply cannot see how the above change would cause that, as
it was simply a change in the IO submission code that doesn't affect
overall size or shape of the IOs being submitted.

This is a patch in the middle of a larger patch set - if any of the
patches in that series should affect behaviour, it's the commit a
couple further that removed the XFS page clustering code - that
changes the size and shape of the ioends and bios we build and
submit and so if anything is perturbing Io completion behaviour I'd
expect those to be the culprit

Does this same problem context switch problem still exist when the
entire set of patches in the XFs series has been applied? I can't
reproduce it here locally with the entire series applied, but I have
only tested on 16p with 48GB RAM. The context switch rate does not
go above 3,000/s, regardless of whether I use a ramdisk or high
throughput SSDs. Tracing also clearly indicates a single 4MB ioend
is being build and submitted by the new code and so that implies
that the io completions that are occuring before and after this
patchset are identical, and so therefore the way pages are moving
from dirty -> writeback -> clean is identical before and after the
patch series.

So, like I said - this makes no sense to me from the perspective of
the change that you've bisected it down to. This smells to me of a
scheduler change in the linux-next tree, espcially as I can't
reproduce the behaviour with just the XFS commits in isolation on a
4.5-rc3 tree.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Interesting csd deadlock on ARC

[Vineet Gupta]

Hi Peter,

I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 and it
turned out to be lot more interesting than I'd hoped for. This is stock v4.4

Trouble starts with an IPI to self which doesn't get delivered as the inter-core
interrupt providing h/w is not capable of IPI to self (which I found as part of
debugging this). Subsequent IPIs from other cores to this core get elided as 
well
due to the IPI coalescing optimization in arch/arc/kernel/smp.c: 
ipi_send_msg_one()

There are ways to use a different h/w mechanism to solve the trigger issue and 
I'd
hoped to just implement arch_irq_work_raise(). But the trouble is the call stack
for this issue: IPI to self is triggered from

sys_sched_setscheduler
   __balance_callback
   pull_rt_task
 irq_work_queue_on  <-- called with @cpu == self

Looking into irq_work.c, irq_work_queue() is what is semantically needed,
specifically arch_irq_work_raise() will not be called, which means I need
arch_send_call_function_single_ipi() to be able to IPI to self cpu also. Is that
expected from arch code

Just wanted to understand before writing patches...

Test case triggering is harmless looking LTP: trace_sched -c 1
It is kind of scheduler fizzer as it triggers a whole bunch of sched activity.

Thx,
-Vineet

Interesting csd deadlock on ARC

[Vineet Gupta]

Hi Peter,

I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 and it
turned out to be lot more interesting than I'd hoped for. This is stock v4.4

Trouble starts with an IPI to self which doesn't get delivered as the inter-core
interrupt providing h/w is not capable of IPI to self (which I found as part of
debugging this). Subsequent IPIs from other cores to this core get elided as 
well
due to the IPI coalescing optimization in arch/arc/kernel/smp.c: 
ipi_send_msg_one()

There are ways to use a different h/w mechanism to solve the trigger issue and 
I'd
hoped to just implement arch_irq_work_raise(). But the trouble is the call stack
for this issue: IPI to self is triggered from

sys_sched_setscheduler
   __balance_callback
   pull_rt_task
 irq_work_queue_on  <-- called with @cpu == self

Looking into irq_work.c, irq_work_queue() is what is semantically needed,
specifically arch_irq_work_raise() will not be called, which means I need
arch_send_call_function_single_ipi() to be able to IPI to self cpu also. Is that
expected from arch code

Just wanted to understand before writing patches...

Test case triggering is harmless looking LTP: trace_sched -c 1
It is kind of scheduler fizzer as it triggers a whole bunch of sched activity.

Thx,
-Vineet

[PATCH][QUESTION] Intentional memory leak in ipmi_msghandler?

[Calvin Owens]

Hello,

I've got a few boxes that are leaking memory in handle_new_recv_msgs()
in ipmi_msghandler. AFAICS this is intentional, there's even an explicit
counter that tracks the number of times smi_msg is leaked.

I'm guessing there was a reason for doing this, but there wasn't any
discussion about it on LKML when the patch was accepted. Can you clarify
why something like the below patch won't work? I tried it on one of my
leaky boxes and nothing obviously horrible happened.

Thanks,
Calvin

8<
From: Calvin Owens 
Subject: [PATCH] ipmi_msghandler: Don't leak memory on errors

Signed-off-by: Calvin Owens 
---
 drivers/char/ipmi/ipmi_msghandler.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 94fb407..ed82ffa 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3834,10 +3834,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
break;
} else {
list_del(_msg->link);
-   if (rv == 0)
-   /* Message handled */
-   ipmi_free_smi_msg(smi_msg);
-   /* If rv < 0, fatal error, del but don't free. */
+   ipmi_free_smi_msg(smi_msg);
}
}
if (!run_to_completion)
-- 
2.4.6

[PATCH][QUESTION] Intentional memory leak in ipmi_msghandler?

[Calvin Owens]

Hello,

I've got a few boxes that are leaking memory in handle_new_recv_msgs()
in ipmi_msghandler. AFAICS this is intentional, there's even an explicit
counter that tracks the number of times smi_msg is leaked.

I'm guessing there was a reason for doing this, but there wasn't any
discussion about it on LKML when the patch was accepted. Can you clarify
why something like the below patch won't work? I tried it on one of my
leaky boxes and nothing obviously horrible happened.

Thanks,
Calvin

8<
From: Calvin Owens 
Subject: [PATCH] ipmi_msghandler: Don't leak memory on errors

Signed-off-by: Calvin Owens 
---
 drivers/char/ipmi/ipmi_msghandler.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 94fb407..ed82ffa 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3834,10 +3834,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
break;
} else {
list_del(_msg->link);
-   if (rv == 0)
-   /* Message handled */
-   ipmi_free_smi_msg(smi_msg);
-   /* If rv < 0, fatal error, del but don't free. */
+   ipmi_free_smi_msg(smi_msg);
}
}
if (!run_to_completion)
-- 
2.4.6

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

[Konstantin Khlebnikov]

On Fri, Feb 19, 2016 at 1:57 AM, Hugh Dickins  wrote:
> On Thu, 18 Feb 2016, Johannes Weiner wrote:
>
>> Even before we added MemAvailable, users knew that page cache is
>> easily convertible to free memory on pressure, and estimated their
>> "available" memory by looking at the sum of MemFree, Cached, Buffers.
>> However, "Cached" is calculated using NR_FILE_PAGES, which includes
>> shmem and random driver pages inserted into the page tables; neither
>> of which are easily reclaimable, or reclaimable at all. Reclaiming
>> shmem requires swapping, which is slow. And unlike page cache, which
>> has fairly conservative dirty limits, all of shmem needs to be written
>> out before becoming evictable. Without swap, shmem is not evictable at
>> all. And driver pages certainly never are.
>>
>> Calling these pages "Cached" is misleading and has resulted in broken
>> formulas in userspace. They misrepresent the memory situation and
>> cause either waste or unexpected OOM kills. With 64-bit and per-cpu
>> memory we are way past the point where the relationship between
>> virtual and physical memory is meaningful and users can rely on
>> overcommit protection. OOM kills can not be avoided without wasting
>> enormous amounts of memory this way. This shifts the management burden
>> toward userspace, toward applications monitoring their environment and
>> adjusting their operations. And so where statistics like /proc/meminfo
>> used to be more informational, we have more and more software relying
>> on them to make automated decisions based on utilization.
>>
>> But if userspace is supposed to take over responsibility, it needs a
>> clear and accurate kernel interface to base its judgement on. And one
>> of the requirements is certainly that memory consumers with wildly
>> different reclaimability are not conflated. Adding MemAvailable is a
>> good step in that direction, but there is software like Sigar[1] in
>> circulation that might not get updated anytime soon. And even then,
>> new users will continue to go for the intuitive interpretation of the
>> Cached item. We can't blame them. There are years of tradition behind
>> it, starting with the way free(1) and vmstat(8) have always reported
>> free, buffers, cached. And try as we might, using "Cached" for
>> unevictable memory is never going to be obvious.
>>
>> The semantics of Cached including shmem and kernel pages have been
>> this way forever, dictated by the single-LRU implementation rather
>> than optimal semantics. So it's an uncomfortable proposal to change it
>> now. But what other way to fix this for existing users? What other way
>> to make the interface more intuitive for future users? And what could
>> break by removing it now? I guess somebody who already subtracts Shmem
>> from Cached.
>>
>> What are your thoughts on this?
>
> My thoughts are NAK.  A misleading stat is not so bad as a
> misleading stat whose meaning we change in some random kernel.
>
> By all means improve Documentation/filesystems/proc.txt on Cached.
> By all means promote Active(file)+Inactive(file)-Buffers as often a
> better measure (though Buffers itself is obscure to me - is it intended
> usually to approximate resident FS metadata?).  By all means work on
> /proc/meminfo-v2 (though that may entail dispiritingly long discussions).
>
> We have to assume that Cached has been useful to some people, and that
> they've learnt to subtract Shmem from it, if slow or no swap concerns them.
>
> Added Konstantin to Cc: he's had valuable experience of people learning
> to adapt to the numbers that we put out.
>

I think everything will ok. Subtraction of shmem isn't widespread practice,
more like secret knowledge. This wasn't documented and people who use
this should be aware that this might stop working at any time. So, ACK.

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

[Konstantin Khlebnikov]

On Fri, Feb 19, 2016 at 1:57 AM, Hugh Dickins  wrote:
> On Thu, 18 Feb 2016, Johannes Weiner wrote:
>
>> Even before we added MemAvailable, users knew that page cache is
>> easily convertible to free memory on pressure, and estimated their
>> "available" memory by looking at the sum of MemFree, Cached, Buffers.
>> However, "Cached" is calculated using NR_FILE_PAGES, which includes
>> shmem and random driver pages inserted into the page tables; neither
>> of which are easily reclaimable, or reclaimable at all. Reclaiming
>> shmem requires swapping, which is slow. And unlike page cache, which
>> has fairly conservative dirty limits, all of shmem needs to be written
>> out before becoming evictable. Without swap, shmem is not evictable at
>> all. And driver pages certainly never are.
>>
>> Calling these pages "Cached" is misleading and has resulted in broken
>> formulas in userspace. They misrepresent the memory situation and
>> cause either waste or unexpected OOM kills. With 64-bit and per-cpu
>> memory we are way past the point where the relationship between
>> virtual and physical memory is meaningful and users can rely on
>> overcommit protection. OOM kills can not be avoided without wasting
>> enormous amounts of memory this way. This shifts the management burden
>> toward userspace, toward applications monitoring their environment and
>> adjusting their operations. And so where statistics like /proc/meminfo
>> used to be more informational, we have more and more software relying
>> on them to make automated decisions based on utilization.
>>
>> But if userspace is supposed to take over responsibility, it needs a
>> clear and accurate kernel interface to base its judgement on. And one
>> of the requirements is certainly that memory consumers with wildly
>> different reclaimability are not conflated. Adding MemAvailable is a
>> good step in that direction, but there is software like Sigar[1] in
>> circulation that might not get updated anytime soon. And even then,
>> new users will continue to go for the intuitive interpretation of the
>> Cached item. We can't blame them. There are years of tradition behind
>> it, starting with the way free(1) and vmstat(8) have always reported
>> free, buffers, cached. And try as we might, using "Cached" for
>> unevictable memory is never going to be obvious.
>>
>> The semantics of Cached including shmem and kernel pages have been
>> this way forever, dictated by the single-LRU implementation rather
>> than optimal semantics. So it's an uncomfortable proposal to change it
>> now. But what other way to fix this for existing users? What other way
>> to make the interface more intuitive for future users? And what could
>> break by removing it now? I guess somebody who already subtracts Shmem
>> from Cached.
>>
>> What are your thoughts on this?
>
> My thoughts are NAK.  A misleading stat is not so bad as a
> misleading stat whose meaning we change in some random kernel.
>
> By all means improve Documentation/filesystems/proc.txt on Cached.
> By all means promote Active(file)+Inactive(file)-Buffers as often a
> better measure (though Buffers itself is obscure to me - is it intended
> usually to approximate resident FS metadata?).  By all means work on
> /proc/meminfo-v2 (though that may entail dispiritingly long discussions).
>
> We have to assume that Cached has been useful to some people, and that
> they've learnt to subtract Shmem from it, if slow or no swap concerns them.
>
> Added Konstantin to Cc: he's had valuable experience of people learning
> to adapt to the numbers that we put out.
>

I think everything will ok. Subtraction of shmem isn't widespread practice,
more like secret knowledge. This wasn't documented and people who use
this should be aware that this might stop working at any time. So, ACK.

Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore

[Anand Moon]

Hi Krzysztof,

On 19 February 2016 at 11:36, Krzysztof Kozlowski
 wrote:
> 2016-02-19 2:21 GMT+09:00 Anand Moon :
>> From: Anand Moon 
>>
>> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking.
>> It's safe to initialize pl330_tasklet tasklet after release of the locking.
>
> This is tasklet init, not tasklet execution (which you are referring
> to in first sentence). I don't get how usage of spinlock during
> execution guarantees the safeness during init... Please describe why
> this is safe.
>
> Best regards,
> Krzysztof
>

http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972

pl330_tasklet function which is initiated by tasklet_init is trying to lock
using same spin_unlock_irqsave/restore pch->lock.
So better release the pch->lock and then initialize  the tasklet_init.

Best Regards,
-Anand Moon

>>
>> Signed-off-by: Anand Moon 
>> ---
>>  drivers/dma/pl330.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>> index 17ee758..df2cab1 100644
>> --- a/drivers/dma/pl330.c
>> +++ b/drivers/dma/pl330.c
>> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct 
>> dma_chan *chan)
>> return -ENOMEM;
>> }
>>
>> -   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>> -
>> spin_unlock_irqrestore(>lock, flags);
>>
>> +   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>> +
>> return 1;
>>  }
>>
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore

[Anand Moon]

Hi Krzysztof,

On 19 February 2016 at 11:36, Krzysztof Kozlowski
 wrote:
> 2016-02-19 2:21 GMT+09:00 Anand Moon :
>> From: Anand Moon 
>>
>> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking.
>> It's safe to initialize pl330_tasklet tasklet after release of the locking.
>
> This is tasklet init, not tasklet execution (which you are referring
> to in first sentence). I don't get how usage of spinlock during
> execution guarantees the safeness during init... Please describe why
> this is safe.
>
> Best regards,
> Krzysztof
>

http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972

pl330_tasklet function which is initiated by tasklet_init is trying to lock
using same spin_unlock_irqsave/restore pch->lock.
So better release the pch->lock and then initialize  the tasklet_init.

Best Regards,
-Anand Moon

>>
>> Signed-off-by: Anand Moon 
>> ---
>>  drivers/dma/pl330.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>> index 17ee758..df2cab1 100644
>> --- a/drivers/dma/pl330.c
>> +++ b/drivers/dma/pl330.c
>> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct 
>> dma_chan *chan)
>> return -ENOMEM;
>> }
>>
>> -   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>> -
>> spin_unlock_irqrestore(>lock, flags);
>>
>> +   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
>> +
>> return 1;
>>  }
>>
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 00/14] ACPI 2.0: Enable TermList interpretion and early opeartion region accesses for table loading

[Zheng, Lv]

Hi, Rafael

> From: Zheng, Lv
> Subject: [PATCH 00/14] ACPI 2.0: Enable TermList interpretion and early
> opeartion region accesses for table loading
> 



> 
> PATCH 01-02: The initrd installation testing facility.
> PATCH 03-07: Entropy reduction stuff in ACPICA.

PATCH 03-06 were just sent in ACPICA 20160212 release series.
So this patchset need to be re-arranged and sent again after the 20160212 
release cycle.

But PATCH 01-02 looks not so closely related to this patchset.
Maybe you can help to check to see if they are upstreamable.
If they are merged, then I needn't send them again in v2 series.
Thanks in advance.

Best regards
-Lv

> PATCH 08-10: Entropy reduction stuff in EC driver and ACPI subsystem's
>  initialization order.
> PATCH 12:The first step enabling.
> PATCH 13:The code to facilitate AML 2.0 table loading.
> PATCH 14:The second step enabling.
> 
> Lv Zheng (14):
>   ACPI / OSL: Cleanup initrd table override code
>   ACPI / OSL: Add support to install tables via initrd
>   ACPI 2.0 / AML: Make default region accessible during the table load
>   ACPI 2.0 / AML: Tune _REG evaluations order in the initialization
> steps
>   ACPI 2.0 / AML: Ensure \_SB._INI executed before any _REG
>   ACPI 2.0 / AML: Rename acpi_gbl_reg_methods_enabled to
> acpi_gbl_namespace_initialized
>   ACPICA: Events: Fix an issue that _REG association can happen before
> namespace is initialized
>   ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED
>   ACPI 2.0 / ECDT: Remove early namespace reference from EC
>   ACPI 2.0 / ECDT: Enable correct ECDT initialization order
>   ACPI 2.0 / AML: Improve module level execution by moving the
> If/Else/While execution to per-table basis
>   ACPI 2.0 / AML: Add TermList parsing support for table loading
>   ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order
> for new table loading mode
>   ACPI 2.0 / AML: Fix module level execution by correctly parsing table
> as TermList

RE: [PATCH 00/14] ACPI 2.0: Enable TermList interpretion and early opeartion region accesses for table loading

[Zheng, Lv]

Hi, Rafael

> From: Zheng, Lv
> Subject: [PATCH 00/14] ACPI 2.0: Enable TermList interpretion and early
> opeartion region accesses for table loading
> 



> 
> PATCH 01-02: The initrd installation testing facility.
> PATCH 03-07: Entropy reduction stuff in ACPICA.

PATCH 03-06 were just sent in ACPICA 20160212 release series.
So this patchset need to be re-arranged and sent again after the 20160212 
release cycle.

But PATCH 01-02 looks not so closely related to this patchset.
Maybe you can help to check to see if they are upstreamable.
If they are merged, then I needn't send them again in v2 series.
Thanks in advance.

Best regards
-Lv

> PATCH 08-10: Entropy reduction stuff in EC driver and ACPI subsystem's
>  initialization order.
> PATCH 12:The first step enabling.
> PATCH 13:The code to facilitate AML 2.0 table loading.
> PATCH 14:The second step enabling.
> 
> Lv Zheng (14):
>   ACPI / OSL: Cleanup initrd table override code
>   ACPI / OSL: Add support to install tables via initrd
>   ACPI 2.0 / AML: Make default region accessible during the table load
>   ACPI 2.0 / AML: Tune _REG evaluations order in the initialization
> steps
>   ACPI 2.0 / AML: Ensure \_SB._INI executed before any _REG
>   ACPI 2.0 / AML: Rename acpi_gbl_reg_methods_enabled to
> acpi_gbl_namespace_initialized
>   ACPICA: Events: Fix an issue that _REG association can happen before
> namespace is initialized
>   ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED
>   ACPI 2.0 / ECDT: Remove early namespace reference from EC
>   ACPI 2.0 / ECDT: Enable correct ECDT initialization order
>   ACPI 2.0 / AML: Improve module level execution by moving the
> If/Else/While execution to per-table basis
>   ACPI 2.0 / AML: Add TermList parsing support for table loading
>   ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order
> for new table loading mode
>   ACPI 2.0 / AML: Fix module level execution by correctly parsing table
> as TermList

Re: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi

[Jianqun Xu]

Hi Heiko

在 19/02/2016 14:31, Heiko Stuebner 写道:

Hi Jianqun,

Am Freitag, 19. Februar 2016, 09:56:15 schrieb jianqun.xu:

From: Jianqun Xu 

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Jianqun Xu 
Signed-off-by: Heiko Stuebner 


Mark already applied this patch yesterday.



Good news, so the patch will be removed in next version's patchset.

thanks


Heiko

Re: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi

[Jianqun Xu]

Hi Heiko

在 19/02/2016 14:31, Heiko Stuebner 写道:

Hi Jianqun,

Am Freitag, 19. Februar 2016, 09:56:15 schrieb jianqun.xu:

From: Jianqun Xu 

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Jianqun Xu 
Signed-off-by: Heiko Stuebner 


Mark already applied this patch yesterday.



Good news, so the patch will be removed in next version's patchset.

thanks


Heiko

Re: [PATCH v2 0/6] arm64: Add support of KVM with ACPI

[Wei Huang]

On 02/11/2016 09:33 AM, Julien Grall wrote:
> Hello,
> 
> This small series allows an ARM64 ACPI based platform to use KVM.
> 
> Currently the KVM code has to parse the firmware table to get the necessary
> information to setup the virtual timer and virtual GIC.
> 
> However the parsing of those tables are already done in the GIC and arch
> timer drivers.
> 
> This patch series introduces different helpers to retrieve the information
> from different drivers avoiding to duplicate the parsing code.
> 
> Note there is patch series ([1] and [2]) adding support of KVM on ACPI,
> although the approach chosen is completely different. The code to parse
> the firmware tables are duplicated which I think make more complex to
> support new firmware tables.

I backported these patches to my internal tree. It booted on an ARM64
machine. Even though I haven't got the chance to test it on an GICv3
machine (will update later), I think you can add my name as Tested-by if
needed.

-Wei

> 
> See the changes since v1 in the different patches.
> 
> Regards,
> 
> [1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
> [2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html
> 
> Julien Grall (6):
>   KVM: arm/arm64: arch_timer: Gather KVM specific information in a
> structure
>   KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the
> firmware tables
>   irqchip/gic-v2: Gather ACPI specific data in a single structure
>   irqchip/gic-v2: Parse and export virtual GIC information
>   irqchip/gic-v3: Parse and export virtual GIC information
>   KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware
> tables
> 
>  drivers/clocksource/arm_arch_timer.c   | 11 ++--
>  drivers/irqchip/irq-gic-common.c   | 13 +
>  drivers/irqchip/irq-gic-common.h   |  3 ++
>  drivers/irqchip/irq-gic-v3.c   | 36 ++
>  drivers/irqchip/irq-gic.c  | 91 
> --
>  include/clocksource/arm_arch_timer.h   | 13 ++---
>  include/kvm/arm_vgic.h |  7 +--
>  include/linux/irqchip/arm-gic-common.h | 34 +
>  virt/kvm/arm/arch_timer.c  | 39 ---
>  virt/kvm/arm/vgic-v2.c | 67 +
>  virt/kvm/arm/vgic-v3.c | 45 +
>  virt/kvm/arm/vgic.c| 50 ++-
>  12 files changed, 264 insertions(+), 145 deletions(-)
>  create mode 100644 include/linux/irqchip/arm-gic-common.h
> 

Re: [PATCH v2 0/6] arm64: Add support of KVM with ACPI

[Wei Huang]

On 02/11/2016 09:33 AM, Julien Grall wrote:
> Hello,
> 
> This small series allows an ARM64 ACPI based platform to use KVM.
> 
> Currently the KVM code has to parse the firmware table to get the necessary
> information to setup the virtual timer and virtual GIC.
> 
> However the parsing of those tables are already done in the GIC and arch
> timer drivers.
> 
> This patch series introduces different helpers to retrieve the information
> from different drivers avoiding to duplicate the parsing code.
> 
> Note there is patch series ([1] and [2]) adding support of KVM on ACPI,
> although the approach chosen is completely different. The code to parse
> the firmware tables are duplicated which I think make more complex to
> support new firmware tables.

I backported these patches to my internal tree. It booted on an ARM64
machine. Even though I haven't got the chance to test it on an GICv3
machine (will update later), I think you can add my name as Tested-by if
needed.

-Wei

> 
> See the changes since v1 in the different patches.
> 
> Regards,
> 
> [1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
> [2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html
> 
> Julien Grall (6):
>   KVM: arm/arm64: arch_timer: Gather KVM specific information in a
> structure
>   KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the
> firmware tables
>   irqchip/gic-v2: Gather ACPI specific data in a single structure
>   irqchip/gic-v2: Parse and export virtual GIC information
>   irqchip/gic-v3: Parse and export virtual GIC information
>   KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware
> tables
> 
>  drivers/clocksource/arm_arch_timer.c   | 11 ++--
>  drivers/irqchip/irq-gic-common.c   | 13 +
>  drivers/irqchip/irq-gic-common.h   |  3 ++
>  drivers/irqchip/irq-gic-v3.c   | 36 ++
>  drivers/irqchip/irq-gic.c  | 91 
> --
>  include/clocksource/arm_arch_timer.h   | 13 ++---
>  include/kvm/arm_vgic.h |  7 +--
>  include/linux/irqchip/arm-gic-common.h | 34 +
>  virt/kvm/arm/arch_timer.c  | 39 ---
>  virt/kvm/arm/vgic-v2.c | 67 +
>  virt/kvm/arm/vgic-v3.c | 45 +
>  virt/kvm/arm/vgic.c| 50 ++-
>  12 files changed, 264 insertions(+), 145 deletions(-)
>  create mode 100644 include/linux/irqchip/arm-gic-common.h
> 

Re: [PATCH v7 04/10] usb: dbc: add debug buffer

[Lu Baolu]

On 02/18/2016 07:43 PM, Mathias Nyman wrote:
> On 26.01.2016 14:58, Lu Baolu wrote:
>> "printk" is not suitable for dbc debugging especially when console
>> is in usage. This patch adds a debug buffer in dbc driver and puts
>> the debug messages in this local buffer. The debug buffer could be
>> dumped whenever the console is not in use. This part of code will
>> not be visible unless DBC_DEBUG is defined.
>>
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/early/xhci-dbc.c | 62 
>> ++--
>>   1 file changed, 60 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index 41ce116..6855048 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
>>   static struct xdbc_state *xdbcp = _stat;
>>
>>   #ifdef DBC_DEBUG
>> -/* place holder */
>> -#definexdbc_traceprintk
>> +#defineXDBC_DEBUG_BUF_SIZE(PAGE_SIZE * 32)
>
> Does it really need to be this huge? minimum 4096 * 32 ~ 128k
> The kernel ring  buffer is about the same size (16k - 256k)

This debug buffer is only used when DBC_DEBUG is defined.

128k is a little large. I will change it to 16k.

>
>> +#defineMSG_MAX_LINE128
>
> with 128 characters per line this would fit ~1000 lines
>
>> +static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
>> +static void xdbc_trace(const char *fmt, ...)
>> +{
>> +int i, size;
>> +va_list args;
>> +static int pos;
>> +char temp_buf[MSG_MAX_LINE];
>> +
>> +if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
>> +return;
>> +
>> +memset(temp_buf, 0, MSG_MAX_LINE);
>> +va_start(args, fmt);
>> +vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
>> +va_end(args);
>> +
>> +i = 0;
>> +size = strlen(temp_buf);
>> +while (i < size) {
>> +xdbc_debug_buf[pos] = temp_buf[i];
>> +pos++;
>> +i++;
>> +
>> +if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
>> +break;
>> +}
>
> how about something like:
>
> size = min(XDBC_DEBUG_BUF_SIZE - pos, size)
> memcpy(xdbc_debug_buf + pos, temp_buf, size)
> pos += size;
>
> (might need some "-1" and off by one checking..)

Yes. This looks better.

>
>> +}
>> +
>> +static void xdbc_dump_debug_buffer(void)
>> +{
>> +int index = 0;
>> +int count = 0;
>> +char dump_buf[MSG_MAX_LINE];
>> +
>> +xdbc_trace("The end of DbC trace buffer\n");
>> +pr_notice("DBC debug buffer:\n");
>> +memset(dump_buf, 0, MSG_MAX_LINE);
>> +
>> +while (index < XDBC_DEBUG_BUF_SIZE) {
>> +if (!xdbc_debug_buf[index])
>> +break;
>> +
>> +if (xdbc_debug_buf[index] == '\n' ||
>> +count >= MSG_MAX_LINE - 1) {
>> +pr_notice("DBC: @%08x %s\n", index, dump_buf);
>
> Is showing the he index (position in debug buffer) useful here?

It helps to check the debug log especially when it shows the hardware
registers or memory block.

>
>
>> +memset(dump_buf, 0, MSG_MAX_LINE);
>> +count = 0;
>> +} else {
>> +dump_buf[count] = xdbc_debug_buf[index];
>> +count++;
>> +}
>> +
>> +index++;
>> +}
>
> So we have one huge buffer that xdbc keeps on filling as the initialization 
> progresses.
> It is never emptied, or overwritten (circular).
> When dumped it always dumps the whole thing, copying one character
> at a time.
>
> As this is only used for debugging during xdbc development/debugging, and 
> never enabled
> even if xdbc early printk is used, I don't think optimization really matters.

Yes, it's only a helper for the persons who develop and debug this driver.

>
> Perhaps take a look if we really need PAGE_SIZE * 32 bytes, is xdbc driver 
> even nearly
> writing that much debug data.

I will reduce the debug buffer size.

>  
> -Mathias
>
>

Thanks for your time.

Regards,
-Baolu

Re: [PATCH v7 04/10] usb: dbc: add debug buffer

[Lu Baolu]

On 02/18/2016 07:43 PM, Mathias Nyman wrote:
> On 26.01.2016 14:58, Lu Baolu wrote:
>> "printk" is not suitable for dbc debugging especially when console
>> is in usage. This patch adds a debug buffer in dbc driver and puts
>> the debug messages in this local buffer. The debug buffer could be
>> dumped whenever the console is not in use. This part of code will
>> not be visible unless DBC_DEBUG is defined.
>>
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/early/xhci-dbc.c | 62 
>> ++--
>>   1 file changed, 60 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index 41ce116..6855048 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
>>   static struct xdbc_state *xdbcp = _stat;
>>
>>   #ifdef DBC_DEBUG
>> -/* place holder */
>> -#definexdbc_traceprintk
>> +#defineXDBC_DEBUG_BUF_SIZE(PAGE_SIZE * 32)
>
> Does it really need to be this huge? minimum 4096 * 32 ~ 128k
> The kernel ring  buffer is about the same size (16k - 256k)

This debug buffer is only used when DBC_DEBUG is defined.

128k is a little large. I will change it to 16k.

>
>> +#defineMSG_MAX_LINE128
>
> with 128 characters per line this would fit ~1000 lines
>
>> +static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
>> +static void xdbc_trace(const char *fmt, ...)
>> +{
>> +int i, size;
>> +va_list args;
>> +static int pos;
>> +char temp_buf[MSG_MAX_LINE];
>> +
>> +if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
>> +return;
>> +
>> +memset(temp_buf, 0, MSG_MAX_LINE);
>> +va_start(args, fmt);
>> +vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
>> +va_end(args);
>> +
>> +i = 0;
>> +size = strlen(temp_buf);
>> +while (i < size) {
>> +xdbc_debug_buf[pos] = temp_buf[i];
>> +pos++;
>> +i++;
>> +
>> +if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
>> +break;
>> +}
>
> how about something like:
>
> size = min(XDBC_DEBUG_BUF_SIZE - pos, size)
> memcpy(xdbc_debug_buf + pos, temp_buf, size)
> pos += size;
>
> (might need some "-1" and off by one checking..)

Yes. This looks better.

>
>> +}
>> +
>> +static void xdbc_dump_debug_buffer(void)
>> +{
>> +int index = 0;
>> +int count = 0;
>> +char dump_buf[MSG_MAX_LINE];
>> +
>> +xdbc_trace("The end of DbC trace buffer\n");
>> +pr_notice("DBC debug buffer:\n");
>> +memset(dump_buf, 0, MSG_MAX_LINE);
>> +
>> +while (index < XDBC_DEBUG_BUF_SIZE) {
>> +if (!xdbc_debug_buf[index])
>> +break;
>> +
>> +if (xdbc_debug_buf[index] == '\n' ||
>> +count >= MSG_MAX_LINE - 1) {
>> +pr_notice("DBC: @%08x %s\n", index, dump_buf);
>
> Is showing the he index (position in debug buffer) useful here?

It helps to check the debug log especially when it shows the hardware
registers or memory block.

>
>
>> +memset(dump_buf, 0, MSG_MAX_LINE);
>> +count = 0;
>> +} else {
>> +dump_buf[count] = xdbc_debug_buf[index];
>> +count++;
>> +}
>> +
>> +index++;
>> +}
>
> So we have one huge buffer that xdbc keeps on filling as the initialization 
> progresses.
> It is never emptied, or overwritten (circular).
> When dumped it always dumps the whole thing, copying one character
> at a time.
>
> As this is only used for debugging during xdbc development/debugging, and 
> never enabled
> even if xdbc early printk is used, I don't think optimization really matters.

Yes, it's only a helper for the persons who develop and debug this driver.

>
> Perhaps take a look if we really need PAGE_SIZE * 32 bytes, is xdbc driver 
> even nearly
> writing that much debug data.

I will reduce the debug buffer size.

>  
> -Mathias
>
>

Thanks for your time.

Regards,
-Baolu

Re: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi

[Heiko Stuebner]

Hi Jianqun,

Am Freitag, 19. Februar 2016, 09:56:15 schrieb jianqun.xu:
> From: Jianqun Xu 
> 
> Add devicetree bindings for Rockchip rk3399 spi which found on
> Rockchip rk3399 SoCs.
> 
> Signed-off-by: Jianqun Xu 
> Signed-off-by: Heiko Stuebner 

Mark already applied this patch yesterday.


Heiko

Re: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi

[Heiko Stuebner]

Hi Jianqun,

Am Freitag, 19. Februar 2016, 09:56:15 schrieb jianqun.xu:
> From: Jianqun Xu 
> 
> Add devicetree bindings for Rockchip rk3399 spi which found on
> Rockchip rk3399 SoCs.
> 
> Signed-off-by: Jianqun Xu 
> Signed-off-by: Heiko Stuebner 

Mark already applied this patch yesterday.


Heiko

[PATCH 09/15] ACPICA: ACPICA: Tune _REG evaluations order in the initialization steps

[Lv Zheng]

ACPICA commit 77e0c7a482ac30ef857cf3c33d075e5fe5b5e449

This patch tunes _REG evaluations to be later than all table loading
facilities:
1. acpi_load_tables(): _REG is currently invoked after this function.
2. acpi_ns_exec_module_code_list(): this executes module level code, the
   execution should be a part of the table loading while we currently
   support this in a deferred way.
3. acpi_ns_initialize_objects(): this parses Region/Field/Buffer/Package where
   pkg_length primitive can be seen in the grammar, the parsing should be a
   part of the table loading while we currently support this in a deferred
   way.
Control method evaluation should happen after loading the tables. So this
patch changes the order of _REG evaluation when
acpi_gbl_group_module_level_code experiment is enabled. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/77e0c7a4
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/utxfinit.c |   35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index e1ffd7a..9415830 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -262,23 +262,6 @@ acpi_status __init acpi_initialize_objects(u32 flags)
 
ACPI_FUNCTION_TRACE(acpi_initialize_objects);
 
-   /*
-* Run all _REG methods
-*
-* Note: Any objects accessed by the _REG methods will be automatically
-* initialized, even if they contain executable AML (see the call to
-* acpi_ns_initialize_objects below).
-*/
-   acpi_gbl_reg_methods_enabled = TRUE;
-   if (!(flags & ACPI_NO_ADDRESS_SPACE_INIT)) {
-   ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
- "[Init] Executing _REG OpRegion methods\n"));
-
-   status = acpi_ev_initialize_op_regions();
-   if (ACPI_FAILURE(status)) {
-   return_ACPI_STATUS(status);
-   }
-   }
 #ifdef ACPI_EXEC_APP
/*
 * This call implements the "initialization file" option for acpi_exec.
@@ -319,6 +302,24 @@ acpi_status __init acpi_initialize_objects(u32 flags)
}
 
/*
+* Run all _REG methods
+*
+* Note: Any objects accessed by the _REG methods will be automatically
+* initialized, even if they contain executable AML (see the call to
+* acpi_ns_initialize_objects below).
+*/
+   acpi_gbl_reg_methods_enabled = TRUE;
+   if (!(flags & ACPI_NO_ADDRESS_SPACE_INIT)) {
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+ "[Init] Executing _REG OpRegion methods\n"));
+
+   status = acpi_ev_initialize_op_regions();
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+   }
+
+   /*
 * Initialize all device objects in the namespace. This runs the device
 * _STA and _INI methods.
 */
-- 
1.7.10

[PATCH 09/15] ACPICA: ACPICA: Tune _REG evaluations order in the initialization steps

[Lv Zheng]

ACPICA commit 77e0c7a482ac30ef857cf3c33d075e5fe5b5e449

This patch tunes _REG evaluations to be later than all table loading
facilities:
1. acpi_load_tables(): _REG is currently invoked after this function.
2. acpi_ns_exec_module_code_list(): this executes module level code, the
   execution should be a part of the table loading while we currently
   support this in a deferred way.
3. acpi_ns_initialize_objects(): this parses Region/Field/Buffer/Package where
   pkg_length primitive can be seen in the grammar, the parsing should be a
   part of the table loading while we currently support this in a deferred
   way.
Control method evaluation should happen after loading the tables. So this
patch changes the order of _REG evaluation when
acpi_gbl_group_module_level_code experiment is enabled. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/77e0c7a4
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/utxfinit.c |   35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index e1ffd7a..9415830 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -262,23 +262,6 @@ acpi_status __init acpi_initialize_objects(u32 flags)
 
ACPI_FUNCTION_TRACE(acpi_initialize_objects);
 
-   /*
-* Run all _REG methods
-*
-* Note: Any objects accessed by the _REG methods will be automatically
-* initialized, even if they contain executable AML (see the call to
-* acpi_ns_initialize_objects below).
-*/
-   acpi_gbl_reg_methods_enabled = TRUE;
-   if (!(flags & ACPI_NO_ADDRESS_SPACE_INIT)) {
-   ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
- "[Init] Executing _REG OpRegion methods\n"));
-
-   status = acpi_ev_initialize_op_regions();
-   if (ACPI_FAILURE(status)) {
-   return_ACPI_STATUS(status);
-   }
-   }
 #ifdef ACPI_EXEC_APP
/*
 * This call implements the "initialization file" option for acpi_exec.
@@ -319,6 +302,24 @@ acpi_status __init acpi_initialize_objects(u32 flags)
}
 
/*
+* Run all _REG methods
+*
+* Note: Any objects accessed by the _REG methods will be automatically
+* initialized, even if they contain executable AML (see the call to
+* acpi_ns_initialize_objects below).
+*/
+   acpi_gbl_reg_methods_enabled = TRUE;
+   if (!(flags & ACPI_NO_ADDRESS_SPACE_INIT)) {
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+ "[Init] Executing _REG OpRegion methods\n"));
+
+   status = acpi_ev_initialize_op_regions();
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+   }
+
+   /*
 * Initialize all device objects in the namespace. This runs the device
 * _STA and _INI methods.
 */
-- 
1.7.10

[PATCH 14/15] ACPICA: Utilities: Update trace mechinism for acquire_object

[Lv Zheng]

From: Bob Moore 

ACPICA commit 0824ab90e03c2e4239e890615f447e7962b1daa2

Was not using the correct macro. Updated a comment in
acoutput.h

Link: https://github.com/acpica/acpica/commit/0824ab90
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utcache.c |2 +-
 include/acpi/acoutput.h   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/utcache.c b/drivers/acpi/acpica/utcache.c
index c9a720f..f8e9978 100644
--- a/drivers/acpi/acpica/utcache.c
+++ b/drivers/acpi/acpica/utcache.c
@@ -245,7 +245,7 @@ void *acpi_os_acquire_object(struct acpi_memory_list *cache)
acpi_status status;
void *object;
 
-   ACPI_FUNCTION_NAME(os_acquire_object);
+   ACPI_FUNCTION_TRACE(os_acquire_object);
 
if (!cache) {
return_PTR(NULL);
diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h
index 5bfc619..34f601e 100644
--- a/include/acpi/acoutput.h
+++ b/include/acpi/acoutput.h
@@ -262,7 +262,7 @@
 #define ACPI_GET_FUNCTION_NAME  _acpi_function_name
 
 /*
- * The Name parameter should be the procedure name as a quoted string.
+ * The Name parameter should be the procedure name as a non-quoted string.
  * The function name is also used by the function exit macros below.
  * Note: (const char) is used to be compatible with the debug interfaces
  * and macros such as __func__.
-- 
1.7.10

[PATCH 15/15] ACPICA: Update version to 20160212

[Lv Zheng]

From: Bob Moore 

ACPICA commit 6b06645ea778cc054f48b03dd1842260a1606532

Version 20160212

Link: https://github.com/acpica/acpica/commit/6b06645e
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 1755697..c5078aa 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -46,7 +46,7 @@
 
 /* Current ACPICA subsystem version in MMDD format */
 
-#define ACPI_CA_VERSION 0x20160108
+#define ACPI_CA_VERSION 0x20160212
 
 #include 
 #include 
-- 
1.7.10

[PATCH 13/15] ACPICA: Revert "Parser: Fix for SuperName method invocation"

[Lv Zheng]

From: Bob Moore 

ACPICA commit eade8f78f2aa21e8eabc3380a5728db47273bcf1

This reverts commit 4b86d1046d06e462dae83ebcd5a66cc132a08f8f.

Support for method invocations as part of super_name will be
removed from the ACPI specification, since no AML interpreter
supports it.

Link: https://github.com/acpica/acpica/commit/eade8f78
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/psargs.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/psargs.c b/drivers/acpi/acpica/psargs.c
index 3052185..d48cbed 100644
--- a/drivers/acpi/acpica/psargs.c
+++ b/drivers/acpi/acpica/psargs.c
@@ -269,8 +269,7 @@ acpi_ps_get_next_namepath(struct acpi_walk_state 
*walk_state,
 */
if (ACPI_SUCCESS(status) &&
possible_method_call && (node->type == ACPI_TYPE_METHOD)) {
-   if (GET_CURRENT_ARG_TYPE(walk_state->arg_types) ==
-   ARGP_SUPERNAME) {
+   if (walk_state->opcode == AML_UNLOAD_OP) {
/*
 * acpi_ps_get_next_namestring has increased the AML 
pointer,
 * so we need to restore the saved AML pointer for 
method call.
@@ -697,7 +696,7 @@ static union acpi_parse_object 
*acpi_ps_get_next_field(struct acpi_parse_state
  *
  * PARAMETERS:  walk_state  - Current state
  *  parser_state- Current parser state object
- *  arg_type- The parser argument type (ARGP_*)
+ *  arg_type- The argument type (AML_*_ARG)
  *  return_arg  - Where the next arg is returned
  *
  * RETURN:  Status, and an op object containing the next argument.
@@ -817,9 +816,9 @@ acpi_ps_get_next_arg(struct acpi_walk_state *walk_state,
return_ACPI_STATUS(AE_NO_MEMORY);
}
 
-   /* super_name allows argument to be a method call */
+   /* To support super_name arg of Unload */
 
-   if (arg_type == ARGP_SUPERNAME) {
+   if (walk_state->opcode == AML_UNLOAD_OP) {
status =
acpi_ps_get_next_namepath(walk_state,
  parser_state, arg,
-- 
1.7.10

[PATCH 14/15] ACPICA: Utilities: Update trace mechinism for acquire_object

[Lv Zheng]

From: Bob Moore 

ACPICA commit 0824ab90e03c2e4239e890615f447e7962b1daa2

Was not using the correct macro. Updated a comment in
acoutput.h

Link: https://github.com/acpica/acpica/commit/0824ab90
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utcache.c |2 +-
 include/acpi/acoutput.h   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/utcache.c b/drivers/acpi/acpica/utcache.c
index c9a720f..f8e9978 100644
--- a/drivers/acpi/acpica/utcache.c
+++ b/drivers/acpi/acpica/utcache.c
@@ -245,7 +245,7 @@ void *acpi_os_acquire_object(struct acpi_memory_list *cache)
acpi_status status;
void *object;
 
-   ACPI_FUNCTION_NAME(os_acquire_object);
+   ACPI_FUNCTION_TRACE(os_acquire_object);
 
if (!cache) {
return_PTR(NULL);
diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h
index 5bfc619..34f601e 100644
--- a/include/acpi/acoutput.h
+++ b/include/acpi/acoutput.h
@@ -262,7 +262,7 @@
 #define ACPI_GET_FUNCTION_NAME  _acpi_function_name
 
 /*
- * The Name parameter should be the procedure name as a quoted string.
+ * The Name parameter should be the procedure name as a non-quoted string.
  * The function name is also used by the function exit macros below.
  * Note: (const char) is used to be compatible with the debug interfaces
  * and macros such as __func__.
-- 
1.7.10

[PATCH 15/15] ACPICA: Update version to 20160212

[Lv Zheng]

From: Bob Moore 

ACPICA commit 6b06645ea778cc054f48b03dd1842260a1606532

Version 20160212

Link: https://github.com/acpica/acpica/commit/6b06645e
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 1755697..c5078aa 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -46,7 +46,7 @@
 
 /* Current ACPICA subsystem version in MMDD format */
 
-#define ACPI_CA_VERSION 0x20160108
+#define ACPI_CA_VERSION 0x20160212
 
 #include 
 #include 
-- 
1.7.10

[PATCH 13/15] ACPICA: Revert "Parser: Fix for SuperName method invocation"

[Lv Zheng]

From: Bob Moore 

ACPICA commit eade8f78f2aa21e8eabc3380a5728db47273bcf1

This reverts commit 4b86d1046d06e462dae83ebcd5a66cc132a08f8f.

Support for method invocations as part of super_name will be
removed from the ACPI specification, since no AML interpreter
supports it.

Link: https://github.com/acpica/acpica/commit/eade8f78
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/psargs.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/psargs.c b/drivers/acpi/acpica/psargs.c
index 3052185..d48cbed 100644
--- a/drivers/acpi/acpica/psargs.c
+++ b/drivers/acpi/acpica/psargs.c
@@ -269,8 +269,7 @@ acpi_ps_get_next_namepath(struct acpi_walk_state 
*walk_state,
 */
if (ACPI_SUCCESS(status) &&
possible_method_call && (node->type == ACPI_TYPE_METHOD)) {
-   if (GET_CURRENT_ARG_TYPE(walk_state->arg_types) ==
-   ARGP_SUPERNAME) {
+   if (walk_state->opcode == AML_UNLOAD_OP) {
/*
 * acpi_ps_get_next_namestring has increased the AML 
pointer,
 * so we need to restore the saved AML pointer for 
method call.
@@ -697,7 +696,7 @@ static union acpi_parse_object 
*acpi_ps_get_next_field(struct acpi_parse_state
  *
  * PARAMETERS:  walk_state  - Current state
  *  parser_state- Current parser state object
- *  arg_type- The parser argument type (ARGP_*)
+ *  arg_type- The argument type (AML_*_ARG)
  *  return_arg  - Where the next arg is returned
  *
  * RETURN:  Status, and an op object containing the next argument.
@@ -817,9 +816,9 @@ acpi_ps_get_next_arg(struct acpi_walk_state *walk_state,
return_ACPI_STATUS(AE_NO_MEMORY);
}
 
-   /* super_name allows argument to be a method call */
+   /* To support super_name arg of Unload */
 
-   if (arg_type == ARGP_SUPERNAME) {
+   if (walk_state->opcode == AML_UNLOAD_OP) {
status =
acpi_ps_get_next_namepath(walk_state,
  parser_state, arg,
-- 
1.7.10

[PATCH 06/15] ACPICA: Remove unnecessary arguments to ACPI_INFO

[Lv Zheng]

From: Bob Moore 

ACPICA commit 181f56605a771e0b91e24b0648d2565ca70bea20

This is used as a purely infomation message, without module name
and line number information. Therefore, these arguments are
not needed and they are unnecessary overhead.
Arguments are removed.
ACPICA BZ 872.

Link: https://github.com/acpica/acpica/commit/181f5660
Link: https://bugs.acpica.org/show_bug.cgi?id=872
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dbcmds.c|2 +-
 drivers/acpi/acpica/dsmethod.c  |3 +--
 drivers/acpi/acpica/dsobject.c  |3 +--
 drivers/acpi/acpica/evgpeblk.c  |3 +--
 drivers/acpi/acpica/evgpeinit.c |2 +-
 drivers/acpi/acpica/exconfig.c  |4 ++--
 drivers/acpi/acpica/nseval.c|3 +--
 drivers/acpi/acpica/tbinstal.c  |5 ++---
 drivers/acpi/acpica/tbprint.c   |7 +++
 drivers/acpi/acpica/tbutils.c   |4 +---
 drivers/acpi/acpica/tbxfload.c  |6 ++
 drivers/acpi/acpica/uttrack.c   |2 +-
 drivers/acpi/acpica/utxferror.c |3 +--
 include/acpi/acpixf.h   |6 ++
 14 files changed, 20 insertions(+), 33 deletions(-)

diff --git a/drivers/acpi/acpica/dbcmds.c b/drivers/acpi/acpica/dbcmds.c
index 7ec62c4..772178c 100644
--- a/drivers/acpi/acpica/dbcmds.c
+++ b/drivers/acpi/acpica/dbcmds.c
@@ -348,7 +348,7 @@ void acpi_db_display_table_info(char *table_arg)
} else {
/* If the pointer is null, the table has been unloaded 
*/
 
-   ACPI_INFO((AE_INFO, "%4.4s - Table has been unloaded",
+   ACPI_INFO(("%4.4s - Table has been unloaded",
   table_desc->signature.ascii));
}
}
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index 6a72047..1982310 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -809,8 +809,7 @@ acpi_ds_terminate_control_method(union acpi_operand_object 
*method_desc,
if (method_desc->method.
info_flags & ACPI_METHOD_SERIALIZED_PENDING) {
if (walk_state) {
-   ACPI_INFO((AE_INFO,
-  "Marking method %4.4s as Serialized "
+   ACPI_INFO(("Marking method %4.4s as Serialized "
   "because of AE_ALREADY_EXISTS error",
   walk_state->method_node->name.
   ascii));
diff --git a/drivers/acpi/acpica/dsobject.c b/drivers/acpi/acpica/dsobject.c
index c303e9d..a91de2b 100644
--- a/drivers/acpi/acpica/dsobject.c
+++ b/drivers/acpi/acpica/dsobject.c
@@ -524,8 +524,7 @@ acpi_ds_build_internal_package_obj(struct acpi_walk_state 
*walk_state,
arg = arg->common.next;
}
 
-   ACPI_INFO((AE_INFO,
-  "Actual Package length (%u) is larger than "
+   ACPI_INFO(("Actual Package length (%u) is larger than "
   "NumElements field (%u), truncated",
   i, element_count));
} else if (i < element_count) {
diff --git a/drivers/acpi/acpica/evgpeblk.c b/drivers/acpi/acpica/evgpeblk.c
index 9275e62..447fa1c 100644
--- a/drivers/acpi/acpica/evgpeblk.c
+++ b/drivers/acpi/acpica/evgpeblk.c
@@ -499,8 +499,7 @@ acpi_ev_initialize_gpe_block(struct acpi_gpe_xrupt_info 
*gpe_xrupt_info,
}
 
if (gpe_enabled_count) {
-   ACPI_INFO((AE_INFO,
-  "Enabled %u GPEs in block %02X to %02X",
+   ACPI_INFO(("Enabled %u GPEs in block %02X to %02X",
   gpe_enabled_count, (u32)gpe_block->block_base_number,
   (u32)(gpe_block->block_base_number +
 (gpe_block->gpe_count - 1;
diff --git a/drivers/acpi/acpica/evgpeinit.c b/drivers/acpi/acpica/evgpeinit.c
index 9fdd8d0..7dc7547 100644
--- a/drivers/acpi/acpica/evgpeinit.c
+++ b/drivers/acpi/acpica/evgpeinit.c
@@ -281,7 +281,7 @@ void acpi_ev_update_gpes(acpi_owner_id table_owner_id)
}
 
if (walk_info.count) {
-   ACPI_INFO((AE_INFO, "Enabled %u new GPEs", walk_info.count));
+   ACPI_INFO(("Enabled %u new GPEs", walk_info.count));
}
 
(void)acpi_ut_release_mutex(ACPI_MTX_EVENTS);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 011df21..f741613 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -252,7 +252,7 @@ acpi_ex_load_table_op(struct acpi_walk_state *walk_state,
 
status = acpi_get_table_by_index(table_index, );
if (ACPI_SUCCESS(status)) {
-   ACPI_INFO((AE_INFO, "Dynamic OEM Table Load:"));
+   ACPI_INFO(("Dynamic OEM Table Load:"));
 

[PATCH 05/15] ACPICA: debugger: dbconvert: free pld_info on error return path

[Lv Zheng]

From: Colin Ian King 

ACPICA commit 23e644670539e23818fa81e2af5e89ad6657e75c

A failed allocation of new_buffer causes a leak of pld_info
because the error return path fails to free pld_info. Ensure
it is freed on the error exit path.

Link: https://github.com/acpica/acpica/commit/23e64467
Signed-off-by: Colin Ian King 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dbconvert.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/dbconvert.c b/drivers/acpi/acpica/dbconvert.c
index 9fee88f..68f4e0f4 100644
--- a/drivers/acpi/acpica/dbconvert.c
+++ b/drivers/acpi/acpica/dbconvert.c
@@ -408,7 +408,7 @@ void acpi_db_dump_pld_buffer(union acpi_object *obj_desc)
 
new_buffer = acpi_db_encode_pld_buffer(pld_info);
if (!new_buffer) {
-   return;
+   goto exit;
}
 
/* The two bit-packed buffers should match */
@@ -479,6 +479,7 @@ void acpi_db_dump_pld_buffer(union acpi_object *obj_desc)
   pld_info->horizontal_offset);
}
 
-   ACPI_FREE(pld_info);
ACPI_FREE(new_buffer);
+exit:
+   ACPI_FREE(pld_info);
 }
-- 
1.7.10

[PATCH 06/15] ACPICA: Remove unnecessary arguments to ACPI_INFO

[Lv Zheng]

From: Bob Moore 

ACPICA commit 181f56605a771e0b91e24b0648d2565ca70bea20

This is used as a purely infomation message, without module name
and line number information. Therefore, these arguments are
not needed and they are unnecessary overhead.
Arguments are removed.
ACPICA BZ 872.

Link: https://github.com/acpica/acpica/commit/181f5660
Link: https://bugs.acpica.org/show_bug.cgi?id=872
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dbcmds.c|2 +-
 drivers/acpi/acpica/dsmethod.c  |3 +--
 drivers/acpi/acpica/dsobject.c  |3 +--
 drivers/acpi/acpica/evgpeblk.c  |3 +--
 drivers/acpi/acpica/evgpeinit.c |2 +-
 drivers/acpi/acpica/exconfig.c  |4 ++--
 drivers/acpi/acpica/nseval.c|3 +--
 drivers/acpi/acpica/tbinstal.c  |5 ++---
 drivers/acpi/acpica/tbprint.c   |7 +++
 drivers/acpi/acpica/tbutils.c   |4 +---
 drivers/acpi/acpica/tbxfload.c  |6 ++
 drivers/acpi/acpica/uttrack.c   |2 +-
 drivers/acpi/acpica/utxferror.c |3 +--
 include/acpi/acpixf.h   |6 ++
 14 files changed, 20 insertions(+), 33 deletions(-)

diff --git a/drivers/acpi/acpica/dbcmds.c b/drivers/acpi/acpica/dbcmds.c
index 7ec62c4..772178c 100644
--- a/drivers/acpi/acpica/dbcmds.c
+++ b/drivers/acpi/acpica/dbcmds.c
@@ -348,7 +348,7 @@ void acpi_db_display_table_info(char *table_arg)
} else {
/* If the pointer is null, the table has been unloaded 
*/
 
-   ACPI_INFO((AE_INFO, "%4.4s - Table has been unloaded",
+   ACPI_INFO(("%4.4s - Table has been unloaded",
   table_desc->signature.ascii));
}
}
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index 6a72047..1982310 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -809,8 +809,7 @@ acpi_ds_terminate_control_method(union acpi_operand_object 
*method_desc,
if (method_desc->method.
info_flags & ACPI_METHOD_SERIALIZED_PENDING) {
if (walk_state) {
-   ACPI_INFO((AE_INFO,
-  "Marking method %4.4s as Serialized "
+   ACPI_INFO(("Marking method %4.4s as Serialized "
   "because of AE_ALREADY_EXISTS error",
   walk_state->method_node->name.
   ascii));
diff --git a/drivers/acpi/acpica/dsobject.c b/drivers/acpi/acpica/dsobject.c
index c303e9d..a91de2b 100644
--- a/drivers/acpi/acpica/dsobject.c
+++ b/drivers/acpi/acpica/dsobject.c
@@ -524,8 +524,7 @@ acpi_ds_build_internal_package_obj(struct acpi_walk_state 
*walk_state,
arg = arg->common.next;
}
 
-   ACPI_INFO((AE_INFO,
-  "Actual Package length (%u) is larger than "
+   ACPI_INFO(("Actual Package length (%u) is larger than "
   "NumElements field (%u), truncated",
   i, element_count));
} else if (i < element_count) {
diff --git a/drivers/acpi/acpica/evgpeblk.c b/drivers/acpi/acpica/evgpeblk.c
index 9275e62..447fa1c 100644
--- a/drivers/acpi/acpica/evgpeblk.c
+++ b/drivers/acpi/acpica/evgpeblk.c
@@ -499,8 +499,7 @@ acpi_ev_initialize_gpe_block(struct acpi_gpe_xrupt_info 
*gpe_xrupt_info,
}
 
if (gpe_enabled_count) {
-   ACPI_INFO((AE_INFO,
-  "Enabled %u GPEs in block %02X to %02X",
+   ACPI_INFO(("Enabled %u GPEs in block %02X to %02X",
   gpe_enabled_count, (u32)gpe_block->block_base_number,
   (u32)(gpe_block->block_base_number +
 (gpe_block->gpe_count - 1;
diff --git a/drivers/acpi/acpica/evgpeinit.c b/drivers/acpi/acpica/evgpeinit.c
index 9fdd8d0..7dc7547 100644
--- a/drivers/acpi/acpica/evgpeinit.c
+++ b/drivers/acpi/acpica/evgpeinit.c
@@ -281,7 +281,7 @@ void acpi_ev_update_gpes(acpi_owner_id table_owner_id)
}
 
if (walk_info.count) {
-   ACPI_INFO((AE_INFO, "Enabled %u new GPEs", walk_info.count));
+   ACPI_INFO(("Enabled %u new GPEs", walk_info.count));
}
 
(void)acpi_ut_release_mutex(ACPI_MTX_EVENTS);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 011df21..f741613 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -252,7 +252,7 @@ acpi_ex_load_table_op(struct acpi_walk_state *walk_state,
 
status = acpi_get_table_by_index(table_index, );
if (ACPI_SUCCESS(status)) {
-   ACPI_INFO((AE_INFO, "Dynamic OEM Table Load:"));
+   ACPI_INFO(("Dynamic OEM Table Load:"));
acpi_tb_print_table_header(0, table);
}
 
@@ 

[PATCH 05/15] ACPICA: debugger: dbconvert: free pld_info on error return path

[Lv Zheng]

From: Colin Ian King 

ACPICA commit 23e644670539e23818fa81e2af5e89ad6657e75c

A failed allocation of new_buffer causes a leak of pld_info
because the error return path fails to free pld_info. Ensure
it is freed on the error exit path.

Link: https://github.com/acpica/acpica/commit/23e64467
Signed-off-by: Colin Ian King 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dbconvert.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/dbconvert.c b/drivers/acpi/acpica/dbconvert.c
index 9fee88f..68f4e0f4 100644
--- a/drivers/acpi/acpica/dbconvert.c
+++ b/drivers/acpi/acpica/dbconvert.c
@@ -408,7 +408,7 @@ void acpi_db_dump_pld_buffer(union acpi_object *obj_desc)
 
new_buffer = acpi_db_encode_pld_buffer(pld_info);
if (!new_buffer) {
-   return;
+   goto exit;
}
 
/* The two bit-packed buffers should match */
@@ -479,6 +479,7 @@ void acpi_db_dump_pld_buffer(union acpi_object *obj_desc)
   pld_info->horizontal_offset);
}
 
-   ACPI_FREE(pld_info);
ACPI_FREE(new_buffer);
+exit:
+   ACPI_FREE(pld_info);
 }
-- 
1.7.10

[PATCH 10/15] ACPICA: Namespace: Ensure \_SB._INI executed before any _REG

[Lv Zheng]

ACPICA commit 8ae25b8d128b6b8509010be321ff6bf2760f3807

There is BIOS code relying on the fact that \_SB._INI should get evaluated
before any other control methods. This may implies a gap in ACPICA/Linux
initialization/enumeration process.

Before revealing Windows true behavior by more validations, this patch only
ensures \_SB._INI evaluated before any _REG control methods. This can help
to make progress to other initialization order fixes. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/8ae25b8d
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acnamesp.h |2 +-
 drivers/acpi/acpica/nsinit.c   |  133 
 drivers/acpi/acpica/utxfinit.c |   27 ++--
 3 files changed, 85 insertions(+), 77 deletions(-)

diff --git a/drivers/acpi/acpica/acnamesp.h b/drivers/acpi/acpica/acnamesp.h
index 9684ed6..022d69c 100644
--- a/drivers/acpi/acpica/acnamesp.h
+++ b/drivers/acpi/acpica/acnamesp.h
@@ -88,7 +88,7 @@
  */
 acpi_status acpi_ns_initialize_objects(void);
 
-acpi_status acpi_ns_initialize_devices(void);
+acpi_status acpi_ns_initialize_devices(u32 flags);
 
 /*
  * nsload -  Namespace loading
diff --git a/drivers/acpi/acpica/nsinit.c b/drivers/acpi/acpica/nsinit.c
index bd75d46..3281dd8 100644
--- a/drivers/acpi/acpica/nsinit.c
+++ b/drivers/acpi/acpica/nsinit.c
@@ -46,6 +46,7 @@
 #include "acnamesp.h"
 #include "acdispat.h"
 #include "acinterp.h"
+#include "acevents.h"
 
 #define _COMPONENT  ACPI_NAMESPACE
 ACPI_MODULE_NAME("nsinit")
@@ -133,82 +134,108 @@ acpi_status acpi_ns_initialize_objects(void)
  *
  
**/
 
-acpi_status acpi_ns_initialize_devices(void)
+acpi_status acpi_ns_initialize_devices(u32 flags)
 {
acpi_status status;
struct acpi_device_walk_info info;
 
ACPI_FUNCTION_TRACE(ns_initialize_devices);
 
-   /* Init counters */
+   if (!(flags & ACPI_NO_DEVICE_INIT)) {
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+ "[Init] Initializing ACPI Devices\n"));
 
-   info.device_count = 0;
-   info.num_STA = 0;
-   info.num_INI = 0;
+   /* Init counters */
 
-   ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
- "Initializing Device/Processor/Thermal objects "
- "and executing _INI/_STA methods:\n"));
+   info.device_count = 0;
+   info.num_STA = 0;
+   info.num_INI = 0;
 
-   /* Tree analysis: find all subtrees that contain _INI methods */
+   ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
+ "Initializing Device/Processor/Thermal 
objects "
+ "and executing _INI/_STA methods:\n"));
 
-   status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
-   ACPI_UINT32_MAX, FALSE,
-   acpi_ns_find_ini_methods, NULL, ,
-   NULL);
-   if (ACPI_FAILURE(status)) {
-   goto error_exit;
-   }
+   /* Tree analysis: find all subtrees that contain _INI methods */
 
-   /* Allocate the evaluation information block */
+   status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX, FALSE,
+   acpi_ns_find_ini_methods, NULL,
+   , NULL);
+   if (ACPI_FAILURE(status)) {
+   goto error_exit;
+   }
+
+   /* Allocate the evaluation information block */
 
-   info.evaluate_info =
-   ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info));
-   if (!info.evaluate_info) {
-   status = AE_NO_MEMORY;
-   goto error_exit;
+   info.evaluate_info =
+   ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info));
+   if (!info.evaluate_info) {
+   status = AE_NO_MEMORY;
+   goto error_exit;
+   }
+
+   /*
+* Execute the "global" _INI method that may appear at the root.
+* This support is provided for Windows compatibility (Vista+) 
and
+* is not part of the ACPI specification.
+*/
+   info.evaluate_info->prefix_node = acpi_gbl_root_node;
+   info.evaluate_info->relative_pathname = METHOD_NAME__INI;
+   info.evaluate_info->parameters = NULL;
+   info.evaluate_info->flags = ACPI_IGNORE_RETURN_VALUE;
+
+   status = acpi_ns_evaluate(info.evaluate_info);
+   if (ACPI_SUCCESS(status)) {
+   info.num_INI++;
+   }
}
 
   

[PATCH 10/15] ACPICA: Namespace: Ensure \_SB._INI executed before any _REG

[Lv Zheng]

ACPICA commit 8ae25b8d128b6b8509010be321ff6bf2760f3807

There is BIOS code relying on the fact that \_SB._INI should get evaluated
before any other control methods. This may implies a gap in ACPICA/Linux
initialization/enumeration process.

Before revealing Windows true behavior by more validations, this patch only
ensures \_SB._INI evaluated before any _REG control methods. This can help
to make progress to other initialization order fixes. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/8ae25b8d
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acnamesp.h |2 +-
 drivers/acpi/acpica/nsinit.c   |  133 
 drivers/acpi/acpica/utxfinit.c |   27 ++--
 3 files changed, 85 insertions(+), 77 deletions(-)

diff --git a/drivers/acpi/acpica/acnamesp.h b/drivers/acpi/acpica/acnamesp.h
index 9684ed6..022d69c 100644
--- a/drivers/acpi/acpica/acnamesp.h
+++ b/drivers/acpi/acpica/acnamesp.h
@@ -88,7 +88,7 @@
  */
 acpi_status acpi_ns_initialize_objects(void);
 
-acpi_status acpi_ns_initialize_devices(void);
+acpi_status acpi_ns_initialize_devices(u32 flags);
 
 /*
  * nsload -  Namespace loading
diff --git a/drivers/acpi/acpica/nsinit.c b/drivers/acpi/acpica/nsinit.c
index bd75d46..3281dd8 100644
--- a/drivers/acpi/acpica/nsinit.c
+++ b/drivers/acpi/acpica/nsinit.c
@@ -46,6 +46,7 @@
 #include "acnamesp.h"
 #include "acdispat.h"
 #include "acinterp.h"
+#include "acevents.h"
 
 #define _COMPONENT  ACPI_NAMESPACE
 ACPI_MODULE_NAME("nsinit")
@@ -133,82 +134,108 @@ acpi_status acpi_ns_initialize_objects(void)
  *
  
**/
 
-acpi_status acpi_ns_initialize_devices(void)
+acpi_status acpi_ns_initialize_devices(u32 flags)
 {
acpi_status status;
struct acpi_device_walk_info info;
 
ACPI_FUNCTION_TRACE(ns_initialize_devices);
 
-   /* Init counters */
+   if (!(flags & ACPI_NO_DEVICE_INIT)) {
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+ "[Init] Initializing ACPI Devices\n"));
 
-   info.device_count = 0;
-   info.num_STA = 0;
-   info.num_INI = 0;
+   /* Init counters */
 
-   ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
- "Initializing Device/Processor/Thermal objects "
- "and executing _INI/_STA methods:\n"));
+   info.device_count = 0;
+   info.num_STA = 0;
+   info.num_INI = 0;
 
-   /* Tree analysis: find all subtrees that contain _INI methods */
+   ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
+ "Initializing Device/Processor/Thermal 
objects "
+ "and executing _INI/_STA methods:\n"));
 
-   status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
-   ACPI_UINT32_MAX, FALSE,
-   acpi_ns_find_ini_methods, NULL, ,
-   NULL);
-   if (ACPI_FAILURE(status)) {
-   goto error_exit;
-   }
+   /* Tree analysis: find all subtrees that contain _INI methods */
 
-   /* Allocate the evaluation information block */
+   status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX, FALSE,
+   acpi_ns_find_ini_methods, NULL,
+   , NULL);
+   if (ACPI_FAILURE(status)) {
+   goto error_exit;
+   }
+
+   /* Allocate the evaluation information block */
 
-   info.evaluate_info =
-   ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info));
-   if (!info.evaluate_info) {
-   status = AE_NO_MEMORY;
-   goto error_exit;
+   info.evaluate_info =
+   ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info));
+   if (!info.evaluate_info) {
+   status = AE_NO_MEMORY;
+   goto error_exit;
+   }
+
+   /*
+* Execute the "global" _INI method that may appear at the root.
+* This support is provided for Windows compatibility (Vista+) 
and
+* is not part of the ACPI specification.
+*/
+   info.evaluate_info->prefix_node = acpi_gbl_root_node;
+   info.evaluate_info->relative_pathname = METHOD_NAME__INI;
+   info.evaluate_info->parameters = NULL;
+   info.evaluate_info->flags = ACPI_IGNORE_RETURN_VALUE;
+
+   status = acpi_ns_evaluate(info.evaluate_info);
+   if (ACPI_SUCCESS(status)) {
+   info.num_INI++;
+   }
}
 
/*
-* Execute the "global" 

[PATCH 07/15] ACPICA: ACPI 6.0/iASL: Add support for the External AML opcode

[Lv Zheng]

From: "David E. Box" 

ACPICA commit 882892feeafe8b8e5be10463133405cd4f1309d9

Support for both the compiler and disassembler.
Also, the interpreter will ignore this opcode if it
is ever encountered (should not happen).
David Box.

Link: https://github.com/acpica/acpica/commit/882892fe
Signed-off-by: David E. Box 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/exoparg3.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/exoparg3.c b/drivers/acpi/acpica/exoparg3.c
index 28eb861..5aa21c4 100644
--- a/drivers/acpi/acpica/exoparg3.c
+++ b/drivers/acpi/acpica/exoparg3.c
@@ -123,8 +123,10 @@ acpi_status acpi_ex_opcode_3A_0T_0R(struct acpi_walk_state 
*walk_state)
 * op is intended for use by disassemblers in order to properly
 * disassemble control method invocations. The opcode or group 
of
 * opcodes should be surrounded by an "if (0)" clause to ensure 
that
-* AML interpreters never see the opcode.
+* AML interpreters never see the opcode. Thus, something is
+* wrong if an external opcode ever gets here.
 */
+   ACPI_ERROR((AE_INFO, "Executed External Op"));
status = AE_OK;
goto cleanup;
 
-- 
1.7.10

[PATCH 08/15] ACPICA: Tables: make default region accessible during the table load

[Lv Zheng]

ACPICA commit 016b2a0917cca9cf0d40c38a1541017d9cf569dd

It is proven that the default regions should be accessible during the
table loading in order to execute module level AML code.
This patch moves default region handler installation code earlier in
order to make this happen.
Note that by putting the code here, we actually allow OSPMs to override
default region handlers between acpi_initialize_subsystem() and
acpi_load_tables(), without the need to introduce region handler override
mechanism in acpi_install_address_space_handler(). OSPMs are also couraged
to check acpi_install_address_space_handler() return value to determine if
acpi_remove_address_space_handler() should be invoked before installing new
address space handler. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/016b2a09
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/tbxfload.c |   22 ++
 drivers/acpi/acpica/utxfinit.c |   12 +++-
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index c89943b..9496b84 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -47,6 +47,7 @@
 #include "accommon.h"
 #include "acnamesp.h"
 #include "actables.h"
+#include "acevents.h"
 
 #define _COMPONENT  ACPI_TABLES
 ACPI_MODULE_NAME("tbxfload")
@@ -68,6 +69,27 @@ acpi_status __init acpi_load_tables(void)
 
ACPI_FUNCTION_TRACE(acpi_load_tables);
 
+   /*
+* Install the default operation region handlers. These are the
+* handlers that are defined by the ACPI specification to be
+* "always accessible" -- namely, system_memory, system_IO, and
+* PCI_Config. This also means that no _REG methods need to be
+* run for these address spaces. We need to have these handlers
+* installed before any AML code can be executed, especially any
+* module-level code (11/2015).
+* Note that we allow OSPMs to install their own region handlers
+* between acpi_initialize_subsystem() and acpi_load_tables() to use
+* their customized default region handlers.
+*/
+   if (acpi_gbl_group_module_level_code) {
+   status = acpi_ev_install_region_handlers();
+   if (ACPI_FAILURE(status) && status != AE_ALREADY_EXISTS) {
+   ACPI_EXCEPTION((AE_INFO, status,
+   "During Region initialization"));
+   return_ACPI_STATUS(status);
+   }
+   }
+
/* Load the namespace from the tables */
 
status = acpi_tb_load_namespace();
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 721b87c..e1ffd7a 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -163,11 +163,13 @@ acpi_status __init acpi_enable_subsystem(u32 flags)
 * installed before any AML code can be executed, especially any
 * module-level code (11/2015).
 */
-   status = acpi_ev_install_region_handlers();
-   if (ACPI_FAILURE(status)) {
-   ACPI_EXCEPTION((AE_INFO, status,
-   "During Region initialization"));
-   return_ACPI_STATUS(status);
+   if (!acpi_gbl_group_module_level_code) {
+   status = acpi_ev_install_region_handlers();
+   if (ACPI_FAILURE(status)) {
+   ACPI_EXCEPTION((AE_INFO, status,
+   "During Region initialization"));
+   return_ACPI_STATUS(status);
+   }
}
 #if (!ACPI_REDUCED_HARDWARE)
 
-- 
1.7.10

[PATCH 07/15] ACPICA: ACPI 6.0/iASL: Add support for the External AML opcode

[Lv Zheng]

From: "David E. Box" 

ACPICA commit 882892feeafe8b8e5be10463133405cd4f1309d9

Support for both the compiler and disassembler.
Also, the interpreter will ignore this opcode if it
is ever encountered (should not happen).
David Box.

Link: https://github.com/acpica/acpica/commit/882892fe
Signed-off-by: David E. Box 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/exoparg3.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/exoparg3.c b/drivers/acpi/acpica/exoparg3.c
index 28eb861..5aa21c4 100644
--- a/drivers/acpi/acpica/exoparg3.c
+++ b/drivers/acpi/acpica/exoparg3.c
@@ -123,8 +123,10 @@ acpi_status acpi_ex_opcode_3A_0T_0R(struct acpi_walk_state 
*walk_state)
 * op is intended for use by disassemblers in order to properly
 * disassemble control method invocations. The opcode or group 
of
 * opcodes should be surrounded by an "if (0)" clause to ensure 
that
-* AML interpreters never see the opcode.
+* AML interpreters never see the opcode. Thus, something is
+* wrong if an external opcode ever gets here.
 */
+   ACPI_ERROR((AE_INFO, "Executed External Op"));
status = AE_OK;
goto cleanup;
 
-- 
1.7.10

[PATCH 08/15] ACPICA: Tables: make default region accessible during the table load

[Lv Zheng]

ACPICA commit 016b2a0917cca9cf0d40c38a1541017d9cf569dd

It is proven that the default regions should be accessible during the
table loading in order to execute module level AML code.
This patch moves default region handler installation code earlier in
order to make this happen.
Note that by putting the code here, we actually allow OSPMs to override
default region handlers between acpi_initialize_subsystem() and
acpi_load_tables(), without the need to introduce region handler override
mechanism in acpi_install_address_space_handler(). OSPMs are also couraged
to check acpi_install_address_space_handler() return value to determine if
acpi_remove_address_space_handler() should be invoked before installing new
address space handler. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/016b2a09
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/tbxfload.c |   22 ++
 drivers/acpi/acpica/utxfinit.c |   12 +++-
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index c89943b..9496b84 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -47,6 +47,7 @@
 #include "accommon.h"
 #include "acnamesp.h"
 #include "actables.h"
+#include "acevents.h"
 
 #define _COMPONENT  ACPI_TABLES
 ACPI_MODULE_NAME("tbxfload")
@@ -68,6 +69,27 @@ acpi_status __init acpi_load_tables(void)
 
ACPI_FUNCTION_TRACE(acpi_load_tables);
 
+   /*
+* Install the default operation region handlers. These are the
+* handlers that are defined by the ACPI specification to be
+* "always accessible" -- namely, system_memory, system_IO, and
+* PCI_Config. This also means that no _REG methods need to be
+* run for these address spaces. We need to have these handlers
+* installed before any AML code can be executed, especially any
+* module-level code (11/2015).
+* Note that we allow OSPMs to install their own region handlers
+* between acpi_initialize_subsystem() and acpi_load_tables() to use
+* their customized default region handlers.
+*/
+   if (acpi_gbl_group_module_level_code) {
+   status = acpi_ev_install_region_handlers();
+   if (ACPI_FAILURE(status) && status != AE_ALREADY_EXISTS) {
+   ACPI_EXCEPTION((AE_INFO, status,
+   "During Region initialization"));
+   return_ACPI_STATUS(status);
+   }
+   }
+
/* Load the namespace from the tables */
 
status = acpi_tb_load_namespace();
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 721b87c..e1ffd7a 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -163,11 +163,13 @@ acpi_status __init acpi_enable_subsystem(u32 flags)
 * installed before any AML code can be executed, especially any
 * module-level code (11/2015).
 */
-   status = acpi_ev_install_region_handlers();
-   if (ACPI_FAILURE(status)) {
-   ACPI_EXCEPTION((AE_INFO, status,
-   "During Region initialization"));
-   return_ACPI_STATUS(status);
+   if (!acpi_gbl_group_module_level_code) {
+   status = acpi_ev_install_region_handlers();
+   if (ACPI_FAILURE(status)) {
+   ACPI_EXCEPTION((AE_INFO, status,
+   "During Region initialization"));
+   return_ACPI_STATUS(status);
+   }
}
 #if (!ACPI_REDUCED_HARDWARE)
 
-- 
1.7.10

[PATCH 11/15] ACPICA: Namespace: Rename acpi_gbl_reg_methods_enabled to acpi_gbl_namespace_initialized

[Lv Zheng]

ACPICA commit 4be3b82cf45d324366ea8567102d5108c5ef47cb
ACPICA commit 19f84c249267fab0bfb138bd14d12510fb4faf24

The global variable actually means the availability of the namespace, and
control methods evaluations should happen after namespace readiness. Thus
this patch renames the global variable to reflect this logic. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/4be3b82c
Link: https://github.com/acpica/acpica/commit/19f84c24
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acglobal.h |2 +-
 drivers/acpi/acpica/evregion.c |2 +-
 drivers/acpi/acpica/nsinit.c   |2 +-
 drivers/acpi/acpica/utxfinit.c |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 55c8197..51b073b 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -165,7 +165,7 @@ ACPI_GLOBAL(u8, acpi_gbl_next_owner_id_offset);
 
 /* Initialization sequencing */
 
-ACPI_INIT_GLOBAL(u8, acpi_gbl_reg_methods_enabled, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_namespace_initialized, FALSE);
 
 /* Misc */
 
diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
index 47092b4..63924d1 100644
--- a/drivers/acpi/acpica/evregion.c
+++ b/drivers/acpi/acpica/evregion.c
@@ -600,7 +600,7 @@ acpi_ev_execute_reg_method(union acpi_operand_object 
*region_obj, u32 function)
 
if (region_obj2->extra.method_REG == NULL ||
region_obj->region.handler == NULL ||
-   !acpi_gbl_reg_methods_enabled) {
+   !acpi_gbl_namespace_initialized) {
return_ACPI_STATUS(AE_OK);
}
 
diff --git a/drivers/acpi/acpica/nsinit.c b/drivers/acpi/acpica/nsinit.c
index 3281dd8..f029a3d 100644
--- a/drivers/acpi/acpica/nsinit.c
+++ b/drivers/acpi/acpica/nsinit.c
@@ -136,7 +136,7 @@ acpi_status acpi_ns_initialize_objects(void)
 
 acpi_status acpi_ns_initialize_devices(u32 flags)
 {
-   acpi_status status;
+   acpi_status status = AE_OK;
struct acpi_device_walk_info info;
 
ACPI_FUNCTION_TRACE(ns_initialize_devices);
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 66d6f19..d70649d 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -301,7 +301,7 @@ acpi_status __init acpi_initialize_objects(u32 flags)
}
}
 
-   acpi_gbl_reg_methods_enabled = TRUE;
+   acpi_gbl_namespace_initialized = TRUE;
 
/*
 * Initialize all device/region objects in the namespace. This runs
-- 
1.7.10

[PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec

[Lv Zheng]

From: Bob Moore 

ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387

Small changes:
1) A couple new predefined names
2) New _HID values
3) New subtable for HEST

Link: https://github.com/acpica/acpica/commit/5f21bdda
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |9 +
 drivers/acpi/acpica/utdecode.c |   30 +-
 include/acpi/actbl.h   |2 +-
 include/acpi/actbl1.h  |   29 ++---
 include/acpi/actypes.h |3 ++-
 5 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index 5faeab4..4ca426b 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -523,6 +523,9 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
  METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (4 Int) */
PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 4, 0, 0, 0),
 
+   {{"_FIT", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_BUFFER)}},  /* ACPI 6.0 */
+
{{"_FIX", METHOD_0ARGS,
  METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints) */
PACKAGE_INFO(ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0, 0, 0, 0),
@@ -1053,6 +1056,12 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
  METHOD_RETURNS(ACPI_RTYPE_INTEGER | ACPI_RTYPE_STRING |
 ACPI_RTYPE_BUFFER)}},
 
+   {{"_WPC", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
+
+   {{"_WPP", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
+
PACKAGE_INFO(0, 0, 0, 0, 0, 0)  /* Table terminator */
 };
 #else
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 6ba65b0..efd7988 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -446,7 +446,7 @@ const char *acpi_ut_get_mutex_name(u32 mutex_id)
 
 /* Names for Notify() values, used for debug output */
 
-static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
+static const char *acpi_gbl_generic_notify[ACPI_GENERIC_NOTIFY_MAX + 1] = {
/* 00 */ "Bus Check",
/* 01 */ "Device Check",
/* 02 */ "Device Wake",
@@ -459,49 +459,53 @@ static const char 
*acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
/* 09 */ "Device PLD Check",
/* 0A */ "Reserved",
/* 0B */ "System Locality Update",
-   /* 0C */ "Shutdown Request",
+   /* 0C */ "Shutdown Request",
+   /* Reserved in ACPI 6.0 */
/* 0D */ "System Resource Affinity Update"
 };
 
-static const char *acpi_gbl_device_notify[4] = {
+static const char *acpi_gbl_device_notify[5] = {
/* 80 */ "Status Change",
/* 81 */ "Information Change",
/* 82 */ "Device-Specific Change",
-   /* 83 */ "Device-Specific Change"
+   /* 83 */ "Device-Specific Change",
+   /* 84 */ "Reserved"
 };
 
-static const char *acpi_gbl_processor_notify[4] = {
+static const char *acpi_gbl_processor_notify[5] = {
/* 80 */ "Performance Capability Change",
/* 81 */ "C-State Change",
/* 82 */ "Throttling Capability Change",
-   /* 83 */ "Device-Specific Change"
+   /* 83 */ "Guaranteed Change",
+   /* 84 */ "Minimum Excursion"
 };
 
-static const char *acpi_gbl_thermal_notify[4] = {
+static const char *acpi_gbl_thermal_notify[5] = {
/* 80 */ "Thermal Status Change",
/* 81 */ "Thermal Trip Point Change",
/* 82 */ "Thermal Device List Change",
-   /* 83 */ "Thermal Relationship Change"
+   /* 83 */ "Thermal Relationship Change",
+   /* 84 */ "Reserved"
 };
 
 const char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type)
 {
 
-   /* 00 - 0D are common to all object types */
+   /* 00 - 0D are "common to all object types" (from ACPI Spec) */
 
-   if (notify_value <= ACPI_NOTIFY_MAX) {
+   if (notify_value <= ACPI_GENERIC_NOTIFY_MAX) {
return (acpi_gbl_generic_notify[notify_value]);
}
 
-   /* 0D - 7F are reserved */
+   /* 0E - 7F are reserved */
 
if (notify_value <= ACPI_MAX_SYS_NOTIFY) {
return ("Reserved");
}
 
-   /* 80 - 83 are per-object-type */
+   /* 80 - 84 are per-object-type */
 
-   if (notify_value <= 0x83) {
+   if (notify_value <= ACPI_SPECIFIC_NOTIFY_MAX) {
switch (type) {
case ACPI_TYPE_ANY:
case ACPI_TYPE_DEVICE:
diff --git a/include/acpi/actbl.h b/include/acpi/actbl.h
index 0cb1a00..6a4e521 100644
--- a/include/acpi/actbl.h
+++ b/include/acpi/actbl.h
@@ -223,7 +223,7 @@ struct acpi_table_facs {
 

[PATCH 11/15] ACPICA: Namespace: Rename acpi_gbl_reg_methods_enabled to acpi_gbl_namespace_initialized

[Lv Zheng]

ACPICA commit 4be3b82cf45d324366ea8567102d5108c5ef47cb
ACPICA commit 19f84c249267fab0bfb138bd14d12510fb4faf24

The global variable actually means the availability of the namespace, and
control methods evaluations should happen after namespace readiness. Thus
this patch renames the global variable to reflect this logic. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/4be3b82c
Link: https://github.com/acpica/acpica/commit/19f84c24
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acglobal.h |2 +-
 drivers/acpi/acpica/evregion.c |2 +-
 drivers/acpi/acpica/nsinit.c   |2 +-
 drivers/acpi/acpica/utxfinit.c |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 55c8197..51b073b 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -165,7 +165,7 @@ ACPI_GLOBAL(u8, acpi_gbl_next_owner_id_offset);
 
 /* Initialization sequencing */
 
-ACPI_INIT_GLOBAL(u8, acpi_gbl_reg_methods_enabled, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_namespace_initialized, FALSE);
 
 /* Misc */
 
diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
index 47092b4..63924d1 100644
--- a/drivers/acpi/acpica/evregion.c
+++ b/drivers/acpi/acpica/evregion.c
@@ -600,7 +600,7 @@ acpi_ev_execute_reg_method(union acpi_operand_object 
*region_obj, u32 function)
 
if (region_obj2->extra.method_REG == NULL ||
region_obj->region.handler == NULL ||
-   !acpi_gbl_reg_methods_enabled) {
+   !acpi_gbl_namespace_initialized) {
return_ACPI_STATUS(AE_OK);
}
 
diff --git a/drivers/acpi/acpica/nsinit.c b/drivers/acpi/acpica/nsinit.c
index 3281dd8..f029a3d 100644
--- a/drivers/acpi/acpica/nsinit.c
+++ b/drivers/acpi/acpica/nsinit.c
@@ -136,7 +136,7 @@ acpi_status acpi_ns_initialize_objects(void)
 
 acpi_status acpi_ns_initialize_devices(u32 flags)
 {
-   acpi_status status;
+   acpi_status status = AE_OK;
struct acpi_device_walk_info info;
 
ACPI_FUNCTION_TRACE(ns_initialize_devices);
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 66d6f19..d70649d 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -301,7 +301,7 @@ acpi_status __init acpi_initialize_objects(u32 flags)
}
}
 
-   acpi_gbl_reg_methods_enabled = TRUE;
+   acpi_gbl_namespace_initialized = TRUE;
 
/*
 * Initialize all device/region objects in the namespace. This runs
-- 
1.7.10

[PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec

[Lv Zheng]

From: Bob Moore 

ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387

Small changes:
1) A couple new predefined names
2) New _HID values
3) New subtable for HEST

Link: https://github.com/acpica/acpica/commit/5f21bdda
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |9 +
 drivers/acpi/acpica/utdecode.c |   30 +-
 include/acpi/actbl.h   |2 +-
 include/acpi/actbl1.h  |   29 ++---
 include/acpi/actypes.h |3 ++-
 5 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index 5faeab4..4ca426b 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -523,6 +523,9 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
  METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (4 Int) */
PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 4, 0, 0, 0),
 
+   {{"_FIT", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_BUFFER)}},  /* ACPI 6.0 */
+
{{"_FIX", METHOD_0ARGS,
  METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints) */
PACKAGE_INFO(ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0, 0, 0, 0),
@@ -1053,6 +1056,12 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
  METHOD_RETURNS(ACPI_RTYPE_INTEGER | ACPI_RTYPE_STRING |
 ACPI_RTYPE_BUFFER)}},
 
+   {{"_WPC", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
+
+   {{"_WPP", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
+
PACKAGE_INFO(0, 0, 0, 0, 0, 0)  /* Table terminator */
 };
 #else
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 6ba65b0..efd7988 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -446,7 +446,7 @@ const char *acpi_ut_get_mutex_name(u32 mutex_id)
 
 /* Names for Notify() values, used for debug output */
 
-static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
+static const char *acpi_gbl_generic_notify[ACPI_GENERIC_NOTIFY_MAX + 1] = {
/* 00 */ "Bus Check",
/* 01 */ "Device Check",
/* 02 */ "Device Wake",
@@ -459,49 +459,53 @@ static const char 
*acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
/* 09 */ "Device PLD Check",
/* 0A */ "Reserved",
/* 0B */ "System Locality Update",
-   /* 0C */ "Shutdown Request",
+   /* 0C */ "Shutdown Request",
+   /* Reserved in ACPI 6.0 */
/* 0D */ "System Resource Affinity Update"
 };
 
-static const char *acpi_gbl_device_notify[4] = {
+static const char *acpi_gbl_device_notify[5] = {
/* 80 */ "Status Change",
/* 81 */ "Information Change",
/* 82 */ "Device-Specific Change",
-   /* 83 */ "Device-Specific Change"
+   /* 83 */ "Device-Specific Change",
+   /* 84 */ "Reserved"
 };
 
-static const char *acpi_gbl_processor_notify[4] = {
+static const char *acpi_gbl_processor_notify[5] = {
/* 80 */ "Performance Capability Change",
/* 81 */ "C-State Change",
/* 82 */ "Throttling Capability Change",
-   /* 83 */ "Device-Specific Change"
+   /* 83 */ "Guaranteed Change",
+   /* 84 */ "Minimum Excursion"
 };
 
-static const char *acpi_gbl_thermal_notify[4] = {
+static const char *acpi_gbl_thermal_notify[5] = {
/* 80 */ "Thermal Status Change",
/* 81 */ "Thermal Trip Point Change",
/* 82 */ "Thermal Device List Change",
-   /* 83 */ "Thermal Relationship Change"
+   /* 83 */ "Thermal Relationship Change",
+   /* 84 */ "Reserved"
 };
 
 const char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type)
 {
 
-   /* 00 - 0D are common to all object types */
+   /* 00 - 0D are "common to all object types" (from ACPI Spec) */
 
-   if (notify_value <= ACPI_NOTIFY_MAX) {
+   if (notify_value <= ACPI_GENERIC_NOTIFY_MAX) {
return (acpi_gbl_generic_notify[notify_value]);
}
 
-   /* 0D - 7F are reserved */
+   /* 0E - 7F are reserved */
 
if (notify_value <= ACPI_MAX_SYS_NOTIFY) {
return ("Reserved");
}
 
-   /* 80 - 83 are per-object-type */
+   /* 80 - 84 are per-object-type */
 
-   if (notify_value <= 0x83) {
+   if (notify_value <= ACPI_SPECIFIC_NOTIFY_MAX) {
switch (type) {
case ACPI_TYPE_ANY:
case ACPI_TYPE_DEVICE:
diff --git a/include/acpi/actbl.h b/include/acpi/actbl.h
index 0cb1a00..6a4e521 100644
--- a/include/acpi/actbl.h
+++ b/include/acpi/actbl.h
@@ -223,7 +223,7 @@ struct acpi_table_facs {
 
/***
  *
  * FADT - Fixed ACPI Description Table (Signature "FACP")
- * 

[PATCH 02/15] ACPICA: Remove incorrect "static" from a global structure

[Lv Zheng]

From: Bob Moore 

ACPICA commit 7a9956a2afd3863fa7d9fe4a64a957389d09f3c2

Reported by Colin Ian King. ACPICA BZ 1239.

Link: https://github.com/acpica/acpica/commit/7a9956a2
Link: https://bugs.acpica.org/show_bug.cgi?id=1239
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index 52f6bee..5faeab4 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -1125,7 +1125,7 @@ const union acpi_predefined_info 
acpi_gbl_resource_names[] = {
PACKAGE_INFO(0, 0, 0, 0, 0, 0)  /* Table terminator */
 };
 
-static const union acpi_predefined_info acpi_gbl_scope_names[] = {
+const union acpi_predefined_info acpi_gbl_scope_names[] = {
{{"_GPE", 0, 0}},
{{"_PR_", 0, 0}},
{{"_SB_", 0, 0}},
-- 
1.7.10

[PATCH 04/15] ACPICA: iASL: Update to use internal acpi_ut_strtoul64 function

[Lv Zheng]

From: Bob Moore 

ACPICA commit e959584d23b520c53700e90282312d17b9603ed5

Was using a local Strtoul64, update to use the common acpi_ut_strtoul64
and remove the local Strtoul64.

Link: https://github.com/acpica/acpica/commit/e959584d
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utnonansi.c |  244 +--
 1 file changed, 206 insertions(+), 38 deletions(-)

diff --git a/drivers/acpi/acpica/utnonansi.c b/drivers/acpi/acpica/utnonansi.c
index d1f4a47..d5c3adf 100644
--- a/drivers/acpi/acpica/utnonansi.c
+++ b/drivers/acpi/acpica/utnonansi.c
@@ -140,6 +140,67 @@ int acpi_ut_stricmp(char *string1, char *string2)
return (c1 - c2);
 }
 
+#if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
+/***
+ *
+ * FUNCTION:acpi_ut_safe_strcpy, acpi_ut_safe_strcat, acpi_ut_safe_strncat
+ *
+ * PARAMETERS:  Adds a "DestSize" parameter to each of the standard string
+ *  functions. This is the size of the Destination buffer.
+ *
+ * RETURN:  TRUE if the operation would overflow the destination buffer.
+ *
+ * DESCRIPTION: Safe versions of standard Clib string functions. Ensure that
+ *  the result of the operation will not overflow the output string
+ *  buffer.
+ *
+ * NOTE:These functions are typically only helpful for processing
+ *  user input and command lines. For most ACPICA code, the
+ *  required buffer length is precisely calculated before buffer
+ *  allocation, so the use of these functions is unnecessary.
+ *
+ 
**/
+
+u8 acpi_ut_safe_strcpy(char *dest, acpi_size dest_size, char *source)
+{
+
+   if (strlen(source) >= dest_size) {
+   return (TRUE);
+   }
+
+   strcpy(dest, source);
+   return (FALSE);
+}
+
+u8 acpi_ut_safe_strcat(char *dest, acpi_size dest_size, char *source)
+{
+
+   if ((strlen(dest) + strlen(source)) >= dest_size) {
+   return (TRUE);
+   }
+
+   strcat(dest, source);
+   return (FALSE);
+}
+
+u8
+acpi_ut_safe_strncat(char *dest,
+acpi_size dest_size,
+char *source, acpi_size max_transfer_length)
+{
+   acpi_size actual_transfer_length;
+
+   actual_transfer_length = ACPI_MIN(max_transfer_length, strlen(source));
+
+   if ((strlen(dest) + actual_transfer_length) >= dest_size) {
+   return (TRUE);
+   }
+
+   strncat(dest, source, max_transfer_length);
+   return (FALSE);
+}
+#endif
+
 
/***
  *
  * FUNCTION:acpi_ut_strtoul64
@@ -155,7 +216,15 @@ int acpi_ut_stricmp(char *string1, char *string2)
  *  32-bit or 64-bit conversion, depending on the current mode
  *  of the interpreter.
  *
- * NOTE:Does not support Octal strings, not needed.
+ * NOTES:   acpi_gbl_integer_byte_width should be set to the proper width.
+ *  For the core ACPICA code, this width depends on the DSDT
+ *  version. For iASL, the default byte width is always 8.
+ *
+ *  Does not support Octal strings, not needed at this time.
+ *
+ *  There is an earlier version of the function after this one,
+ *  below. It is slightly different than this one, and the two
+ *  may eventually may need to be merged. (01/2016).
  *
  
**/
 
@@ -318,63 +387,162 @@ error_exit:
}
 }
 
-#if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
+#ifdef _OBSOLETE_FUNCTIONS
+/* TBD: use version in ACPICA main code base? */
+/* DONE: 01/2016 */
+
 
/***
  *
- * FUNCTION:acpi_ut_safe_strcpy, acpi_ut_safe_strcat, acpi_ut_safe_strncat
+ * FUNCTION:strtoul64
  *
- * PARAMETERS:  Adds a "DestSize" parameter to each of the standard string
- *  functions. This is the size of the Destination buffer.
+ * PARAMETERS:  string  - Null terminated string
+ *  terminater  - Where a pointer to the terminating byte
+ *is returned
+ *  base- Radix of the string
  *
- * RETURN:  TRUE if the operation would overflow the destination buffer.
+ * RETURN:  Converted value
  *
- * DESCRIPTION: Safe versions of standard Clib string functions. Ensure that
- *  the result of the operation will not overflow the output string
- *  buffer.
- *
- * NOTE:These functions are typically only helpful for processing
- *  user input and command lines. For most ACPICA code, 

[PATCH 00/15] ACPICA: 20160212 Release

[Lv Zheng]

The 20160212 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. i386 + default + ACPI_DEBUGGER=y
2. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All "drivers/acpi" configurations
   All "drivers/platform" drivers
   All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20160108 Release):
  506 lines
After applying (20160212 Release):
  506 lines

Bob Moore (8):
  ACPICA: Remove incorrect "static" from a global structure
  ACPICA: iASL: Fix some typos with the name strtoul64
  ACPICA: iASL: Update to use internal acpi_ut_strtoul64 function
  ACPICA: Remove unnecessary arguments to ACPI_INFO
  ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
  ACPICA: Revert "Parser: Fix for SuperName method invocation"
  ACPICA: Utilities: Update trace mechinism for acquire_object
  ACPICA: Update version to 20160212

Colin Ian King (1):
  ACPICA: debugger: dbconvert: free pld_info on error return path

David E. Box (1):
  ACPICA: ACPI 6.0/iASL: Add support for the External AML opcode

Lv Zheng (4):
  ACPICA: Tables: make default region accessible during the table load
  ACPICA: ACPICA: Tune _REG evaluations order in the initialization
steps
  ACPICA: Namespace: Ensure \_SB._INI executed before any _REG
  ACPICA: Namespace: Rename acpi_gbl_reg_methods_enabled to
acpi_gbl_namespace_initialized

waddlesplash (1):
  ACPICA: aclocal: Put parens around some definitions.

 drivers/acpi/acpica/acglobal.h  |2 +-
 drivers/acpi/acpica/aclocal.h   |6 +-
 drivers/acpi/acpica/acnamesp.h  |2 +-
 drivers/acpi/acpica/acpredef.h  |   11 +-
 drivers/acpi/acpica/dbcmds.c|2 +-
 drivers/acpi/acpica/dbconvert.c |5 +-
 drivers/acpi/acpica/dsmethod.c  |3 +-
 drivers/acpi/acpica/dsobject.c  |3 +-
 drivers/acpi/acpica/evgpeblk.c  |3 +-
 drivers/acpi/acpica/evgpeinit.c |2 +-
 drivers/acpi/acpica/evregion.c  |2 +-
 drivers/acpi/acpica/exconfig.c  |4 +-
 drivers/acpi/acpica/exoparg3.c  |4 +-
 drivers/acpi/acpica/nseval.c|3 +-
 drivers/acpi/acpica/nsinit.c|  135 -
 drivers/acpi/acpica/psargs.c|9 +-
 drivers/acpi/acpica/tbinstal.c  |5 +-
 drivers/acpi/acpica/tbprint.c   |7 +-
 drivers/acpi/acpica/tbutils.c   |4 +-
 drivers/acpi/acpica/tbxfload.c  |   28 -
 drivers/acpi/acpica/utcache.c   |2 +-
 drivers/acpi/acpica/utdecode.c  |   30 ++---
 drivers/acpi/acpica/utnonansi.c |  246 ---
 drivers/acpi/acpica/uttrack.c   |2 +-
 drivers/acpi/acpica/utxferror.c |3 +-
 drivers/acpi/acpica/utxfinit.c  |   42 +++
 include/acpi/acoutput.h |2 +-
 include/acpi/acpixf.h   |8 +-
 include/acpi/actbl.h|2 +-
 include/acpi/actbl1.h   |   29 -
 include/acpi/actypes.h  |3 +-
 31 files changed, 418 insertions(+), 191 deletions(-)

-- 
1.7.10

[PATCH 02/15] ACPICA: Remove incorrect "static" from a global structure

[Lv Zheng]

From: Bob Moore 

ACPICA commit 7a9956a2afd3863fa7d9fe4a64a957389d09f3c2

Reported by Colin Ian King. ACPICA BZ 1239.

Link: https://github.com/acpica/acpica/commit/7a9956a2
Link: https://bugs.acpica.org/show_bug.cgi?id=1239
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index 52f6bee..5faeab4 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -1125,7 +1125,7 @@ const union acpi_predefined_info 
acpi_gbl_resource_names[] = {
PACKAGE_INFO(0, 0, 0, 0, 0, 0)  /* Table terminator */
 };
 
-static const union acpi_predefined_info acpi_gbl_scope_names[] = {
+const union acpi_predefined_info acpi_gbl_scope_names[] = {
{{"_GPE", 0, 0}},
{{"_PR_", 0, 0}},
{{"_SB_", 0, 0}},
-- 
1.7.10

[PATCH 04/15] ACPICA: iASL: Update to use internal acpi_ut_strtoul64 function

[Lv Zheng]

From: Bob Moore 

ACPICA commit e959584d23b520c53700e90282312d17b9603ed5

Was using a local Strtoul64, update to use the common acpi_ut_strtoul64
and remove the local Strtoul64.

Link: https://github.com/acpica/acpica/commit/e959584d
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utnonansi.c |  244 +--
 1 file changed, 206 insertions(+), 38 deletions(-)

diff --git a/drivers/acpi/acpica/utnonansi.c b/drivers/acpi/acpica/utnonansi.c
index d1f4a47..d5c3adf 100644
--- a/drivers/acpi/acpica/utnonansi.c
+++ b/drivers/acpi/acpica/utnonansi.c
@@ -140,6 +140,67 @@ int acpi_ut_stricmp(char *string1, char *string2)
return (c1 - c2);
 }
 
+#if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
+/***
+ *
+ * FUNCTION:acpi_ut_safe_strcpy, acpi_ut_safe_strcat, acpi_ut_safe_strncat
+ *
+ * PARAMETERS:  Adds a "DestSize" parameter to each of the standard string
+ *  functions. This is the size of the Destination buffer.
+ *
+ * RETURN:  TRUE if the operation would overflow the destination buffer.
+ *
+ * DESCRIPTION: Safe versions of standard Clib string functions. Ensure that
+ *  the result of the operation will not overflow the output string
+ *  buffer.
+ *
+ * NOTE:These functions are typically only helpful for processing
+ *  user input and command lines. For most ACPICA code, the
+ *  required buffer length is precisely calculated before buffer
+ *  allocation, so the use of these functions is unnecessary.
+ *
+ 
**/
+
+u8 acpi_ut_safe_strcpy(char *dest, acpi_size dest_size, char *source)
+{
+
+   if (strlen(source) >= dest_size) {
+   return (TRUE);
+   }
+
+   strcpy(dest, source);
+   return (FALSE);
+}
+
+u8 acpi_ut_safe_strcat(char *dest, acpi_size dest_size, char *source)
+{
+
+   if ((strlen(dest) + strlen(source)) >= dest_size) {
+   return (TRUE);
+   }
+
+   strcat(dest, source);
+   return (FALSE);
+}
+
+u8
+acpi_ut_safe_strncat(char *dest,
+acpi_size dest_size,
+char *source, acpi_size max_transfer_length)
+{
+   acpi_size actual_transfer_length;
+
+   actual_transfer_length = ACPI_MIN(max_transfer_length, strlen(source));
+
+   if ((strlen(dest) + actual_transfer_length) >= dest_size) {
+   return (TRUE);
+   }
+
+   strncat(dest, source, max_transfer_length);
+   return (FALSE);
+}
+#endif
+
 
/***
  *
  * FUNCTION:acpi_ut_strtoul64
@@ -155,7 +216,15 @@ int acpi_ut_stricmp(char *string1, char *string2)
  *  32-bit or 64-bit conversion, depending on the current mode
  *  of the interpreter.
  *
- * NOTE:Does not support Octal strings, not needed.
+ * NOTES:   acpi_gbl_integer_byte_width should be set to the proper width.
+ *  For the core ACPICA code, this width depends on the DSDT
+ *  version. For iASL, the default byte width is always 8.
+ *
+ *  Does not support Octal strings, not needed at this time.
+ *
+ *  There is an earlier version of the function after this one,
+ *  below. It is slightly different than this one, and the two
+ *  may eventually may need to be merged. (01/2016).
  *
  
**/
 
@@ -318,63 +387,162 @@ error_exit:
}
 }
 
-#if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
+#ifdef _OBSOLETE_FUNCTIONS
+/* TBD: use version in ACPICA main code base? */
+/* DONE: 01/2016 */
+
 
/***
  *
- * FUNCTION:acpi_ut_safe_strcpy, acpi_ut_safe_strcat, acpi_ut_safe_strncat
+ * FUNCTION:strtoul64
  *
- * PARAMETERS:  Adds a "DestSize" parameter to each of the standard string
- *  functions. This is the size of the Destination buffer.
+ * PARAMETERS:  string  - Null terminated string
+ *  terminater  - Where a pointer to the terminating byte
+ *is returned
+ *  base- Radix of the string
  *
- * RETURN:  TRUE if the operation would overflow the destination buffer.
+ * RETURN:  Converted value
  *
- * DESCRIPTION: Safe versions of standard Clib string functions. Ensure that
- *  the result of the operation will not overflow the output string
- *  buffer.
- *
- * NOTE:These functions are typically only helpful for processing
- *  user input and command lines. For most ACPICA code, the
- *  required buffer length is precisely calculated 

[PATCH 00/15] ACPICA: 20160212 Release

[Lv Zheng]

The 20160212 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. i386 + default + ACPI_DEBUGGER=y
2. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All "drivers/acpi" configurations
   All "drivers/platform" drivers
   All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20160108 Release):
  506 lines
After applying (20160212 Release):
  506 lines

Bob Moore (8):
  ACPICA: Remove incorrect "static" from a global structure
  ACPICA: iASL: Fix some typos with the name strtoul64
  ACPICA: iASL: Update to use internal acpi_ut_strtoul64 function
  ACPICA: Remove unnecessary arguments to ACPI_INFO
  ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
  ACPICA: Revert "Parser: Fix for SuperName method invocation"
  ACPICA: Utilities: Update trace mechinism for acquire_object
  ACPICA: Update version to 20160212

Colin Ian King (1):
  ACPICA: debugger: dbconvert: free pld_info on error return path

David E. Box (1):
  ACPICA: ACPI 6.0/iASL: Add support for the External AML opcode

Lv Zheng (4):
  ACPICA: Tables: make default region accessible during the table load
  ACPICA: ACPICA: Tune _REG evaluations order in the initialization
steps
  ACPICA: Namespace: Ensure \_SB._INI executed before any _REG
  ACPICA: Namespace: Rename acpi_gbl_reg_methods_enabled to
acpi_gbl_namespace_initialized

waddlesplash (1):
  ACPICA: aclocal: Put parens around some definitions.

 drivers/acpi/acpica/acglobal.h  |2 +-
 drivers/acpi/acpica/aclocal.h   |6 +-
 drivers/acpi/acpica/acnamesp.h  |2 +-
 drivers/acpi/acpica/acpredef.h  |   11 +-
 drivers/acpi/acpica/dbcmds.c|2 +-
 drivers/acpi/acpica/dbconvert.c |5 +-
 drivers/acpi/acpica/dsmethod.c  |3 +-
 drivers/acpi/acpica/dsobject.c  |3 +-
 drivers/acpi/acpica/evgpeblk.c  |3 +-
 drivers/acpi/acpica/evgpeinit.c |2 +-
 drivers/acpi/acpica/evregion.c  |2 +-
 drivers/acpi/acpica/exconfig.c  |4 +-
 drivers/acpi/acpica/exoparg3.c  |4 +-
 drivers/acpi/acpica/nseval.c|3 +-
 drivers/acpi/acpica/nsinit.c|  135 -
 drivers/acpi/acpica/psargs.c|9 +-
 drivers/acpi/acpica/tbinstal.c  |5 +-
 drivers/acpi/acpica/tbprint.c   |7 +-
 drivers/acpi/acpica/tbutils.c   |4 +-
 drivers/acpi/acpica/tbxfload.c  |   28 -
 drivers/acpi/acpica/utcache.c   |2 +-
 drivers/acpi/acpica/utdecode.c  |   30 ++---
 drivers/acpi/acpica/utnonansi.c |  246 ---
 drivers/acpi/acpica/uttrack.c   |2 +-
 drivers/acpi/acpica/utxferror.c |3 +-
 drivers/acpi/acpica/utxfinit.c  |   42 +++
 include/acpi/acoutput.h |2 +-
 include/acpi/acpixf.h   |8 +-
 include/acpi/actbl.h|2 +-
 include/acpi/actbl1.h   |   29 -
 include/acpi/actypes.h  |3 +-
 31 files changed, 418 insertions(+), 191 deletions(-)

-- 
1.7.10

[PATCH 03/15] ACPICA: iASL: Fix some typos with the name strtoul64

[Lv Zheng]

From: Bob Moore 

ACPICA commit e9622aa824e00997dc92e8638733b7553a4dba26

Was defined as stroul64 in some places.

Link: https://github.com/acpica/acpica/commit/e9622aa8
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utnonansi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/utnonansi.c b/drivers/acpi/acpica/utnonansi.c
index c427a5c..d1f4a47 100644
--- a/drivers/acpi/acpica/utnonansi.c
+++ b/drivers/acpi/acpica/utnonansi.c
@@ -171,7 +171,7 @@ acpi_status acpi_ut_strtoul64(char *string, u32 base, u64 
*ret_integer)
u8 sign_of0x = 0;
u8 term = 0;
 
-   ACPI_FUNCTION_TRACE_STR(ut_stroul64, string);
+   ACPI_FUNCTION_TRACE_STR(ut_strtoul64, string);
 
switch (base) {
case ACPI_ANY_BASE:
-- 
1.7.10

[PATCH 01/15] ACPICA: aclocal: Put parens around some definitions.

[Lv Zheng]

From: waddlesplash 

ACPICA commit 7100a109f7d6523330d29f4d088cf1ffb756025f

Looking at where these are used, this shouldn't result in any behavioral 
changes, but it's best practices to have them.

Link: https://github.com/acpica/acpica/commit/7100a109
Signed-off-by: waddlesplash 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index e4977fa..9562a10 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -85,7 +85,7 @@ union acpi_parse_object;
 #define ACPI_MTX_MEMORY 5  /* Debug memory tracking lists 
*/
 
 #define ACPI_MAX_MUTEX  5
-#define ACPI_NUM_MUTEX  ACPI_MAX_MUTEX+1
+#define ACPI_NUM_MUTEX  (ACPI_MAX_MUTEX+1)
 
 /* Lock structure for reader/writer interfaces */
 
@@ -103,11 +103,11 @@ struct acpi_rw_lock {
 #define ACPI_LOCK_HARDWARE  1
 
 #define ACPI_MAX_LOCK   1
-#define ACPI_NUM_LOCK   ACPI_MAX_LOCK+1
+#define ACPI_NUM_LOCK   (ACPI_MAX_LOCK+1)
 
 /* This Thread ID means that the mutex is not in use (unlocked) */
 
-#define ACPI_MUTEX_NOT_ACQUIRED (acpi_thread_id) 0
+#define ACPI_MUTEX_NOT_ACQUIRED ((acpi_thread_id) 0)
 
 /* This Thread ID means an invalid thread ID */
 
-- 
1.7.10

[PATCH 03/15] ACPICA: iASL: Fix some typos with the name strtoul64

[Lv Zheng]

From: Bob Moore 

ACPICA commit e9622aa824e00997dc92e8638733b7553a4dba26

Was defined as stroul64 in some places.

Link: https://github.com/acpica/acpica/commit/e9622aa8
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utnonansi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/utnonansi.c b/drivers/acpi/acpica/utnonansi.c
index c427a5c..d1f4a47 100644
--- a/drivers/acpi/acpica/utnonansi.c
+++ b/drivers/acpi/acpica/utnonansi.c
@@ -171,7 +171,7 @@ acpi_status acpi_ut_strtoul64(char *string, u32 base, u64 
*ret_integer)
u8 sign_of0x = 0;
u8 term = 0;
 
-   ACPI_FUNCTION_TRACE_STR(ut_stroul64, string);
+   ACPI_FUNCTION_TRACE_STR(ut_strtoul64, string);
 
switch (base) {
case ACPI_ANY_BASE:
-- 
1.7.10

[PATCH 01/15] ACPICA: aclocal: Put parens around some definitions.

[Lv Zheng]

From: waddlesplash 

ACPICA commit 7100a109f7d6523330d29f4d088cf1ffb756025f

Looking at where these are used, this shouldn't result in any behavioral 
changes, but it's best practices to have them.

Link: https://github.com/acpica/acpica/commit/7100a109
Signed-off-by: waddlesplash 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index e4977fa..9562a10 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -85,7 +85,7 @@ union acpi_parse_object;
 #define ACPI_MTX_MEMORY 5  /* Debug memory tracking lists 
*/
 
 #define ACPI_MAX_MUTEX  5
-#define ACPI_NUM_MUTEX  ACPI_MAX_MUTEX+1
+#define ACPI_NUM_MUTEX  (ACPI_MAX_MUTEX+1)
 
 /* Lock structure for reader/writer interfaces */
 
@@ -103,11 +103,11 @@ struct acpi_rw_lock {
 #define ACPI_LOCK_HARDWARE  1
 
 #define ACPI_MAX_LOCK   1
-#define ACPI_NUM_LOCK   ACPI_MAX_LOCK+1
+#define ACPI_NUM_LOCK   (ACPI_MAX_LOCK+1)
 
 /* This Thread ID means that the mutex is not in use (unlocked) */
 
-#define ACPI_MUTEX_NOT_ACQUIRED (acpi_thread_id) 0
+#define ACPI_MUTEX_NOT_ACQUIRED ((acpi_thread_id) 0)
 
 /* This Thread ID means an invalid thread ID */
 
-- 
1.7.10

Re: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document

[Raveendra Padasalagi]

On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring  wrote:
> On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
>> In Cygnus SOC touch screen controller registers are shared
>> with ADC and flex timer. Using readl/writel could lead to
>> race condition. So touch screen driver is enhanced to support
>>
>> 1. If touchscreen register's are not shared. Register access
>> is handled through readl/writel if "brcm,iproc-touchscreen"
>> compatible is provided in touchscreen dt node. This will help
>> for future SOC's if comes with dedicated touchscreen IP register's.
>>
>> 2. If touchscreen register's are shared with other IP's, register
>> access is handled through syscon framework API's to take care of
>> mutually exclusive access. This feature can be enabled by selecting
>> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
>> dt node.
>>
>> Hence touchscreen dt node bindings document is updated to take care
>> of above changes in the touchscreen driver.
>>
>> Signed-off-by: Raveendra Padasalagi 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 
>> +++---
>>  1 file changed, 51 insertions(+), 6 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>  
>> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> index 34e3382..f530c25 100644
>> --- 
>> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> +++ 
>> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> @@ -1,12 +1,30 @@
>>  * Broadcom's IPROC Touchscreen Controller
>>
>>  Required properties:
>> -- compatible: must be "brcm,iproc-touchscreen"
>> -- reg: physical base address of the controller and length of memory mapped
>> -  region.
>> +- compatible: should be one of
>> +"brcm,iproc-touchscreen"
>> +"brcm,iproc-touchscreen-syscon"
>
> More specific and this is not how you do syscon. Either the block is or
> isn't. You can't have it both ways.

Existing driver has support for reg, if we modify now to support only syscon
then this driver will not work if some one wishes to use previous
kernel version's
dt and vice versa. Basically this breaks dt compatibility. Is that ok ?

>> +- ts_syscon: if "brcm,iproc-touchscreen-syscon" compatible string
>> +  is selected then "ts_syscon" is mandatory or else not required.
>> +  The "ts_syscon" is handler of syscon node defining physical base
>> +  address of the controller and length of memory mapped region.
>> +  If this property is selected please make sure MFD_SYSCON config
>> +  is enabled in the defconfig file.
>> +- reg: if "brcm,iproc-touchscreen" compatible string is selected
>> +  then "reg" property is mandatory or else not required.
>> +  The "reg" should be physical base address of the controller and
>> +  length of memory mapped region.
>
> I thought every chip to date is a syscon. Add reg support when you
> actually need it.

Since the existing driver has support for reg and now if we modify it to
support syscon only then we break the dt compatibility with previous kernel
versions. So keeping support for both will help to avoid dt
compatibility issues.

I will change the driver if you still think syscon only support is fine.
Let me know your opinion.

>>  - clocks:  The clock provided by the SOC to driver the tsc
>>  - clock-name:  name for the clock
>>  - interrupts: The touchscreen controller's interrupt
>> +- address-cells: Specify the number of u32 entries needed in child nodes.
>> + Should set to 1. This property is mandatory when
>> + "brcm,iproc-touchscreen-syscon" compatible string is 
>> selected
>> + or else not required.
>> +- size-cells: Specify number of u32 entries needed to specify child nodes 
>> size
>> +  in reg property. Should set to 1.This property is mandatory 
>> when
>> +  "brcm,iproc-touchscreen-syscon" compatible string is selected 
>> or
>> +  else not required.
>>
>>  Optional properties:
>>  - scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
>> @@ -53,13 +71,40 @@ Optional properties:
>>  - touchscreen-inverted-x: X axis is inverted (boolean)
>>  - touchscreen-inverted-y: Y axis is inverted (boolean)
>>
>> -Example:
>> +Example 1: An example of touchscreen node with 
>> "brcm,iproc-touchscreen-syscon"
>> +   compatible string.
>> +
>> + ts_adc_syscon: ts_adc_syscon@0x180a6000 {
>> + compatible = "syscon";
>> + reg = <0x180a6000 0xc30>;
>> + };
>>
>>   touchscreen: tsc@0x180A6000 {
>
> Drop the '0x' and the node name should be touchscreen, not tsc.

I will address this in the next patch.

>> - compatible = 

Re: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document

[Raveendra Padasalagi]

On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring  wrote:
> On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
>> In Cygnus SOC touch screen controller registers are shared
>> with ADC and flex timer. Using readl/writel could lead to
>> race condition. So touch screen driver is enhanced to support
>>
>> 1. If touchscreen register's are not shared. Register access
>> is handled through readl/writel if "brcm,iproc-touchscreen"
>> compatible is provided in touchscreen dt node. This will help
>> for future SOC's if comes with dedicated touchscreen IP register's.
>>
>> 2. If touchscreen register's are shared with other IP's, register
>> access is handled through syscon framework API's to take care of
>> mutually exclusive access. This feature can be enabled by selecting
>> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
>> dt node.
>>
>> Hence touchscreen dt node bindings document is updated to take care
>> of above changes in the touchscreen driver.
>>
>> Signed-off-by: Raveendra Padasalagi 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 
>> +++---
>>  1 file changed, 51 insertions(+), 6 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>  
>> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> index 34e3382..f530c25 100644
>> --- 
>> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> +++ 
>> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> @@ -1,12 +1,30 @@
>>  * Broadcom's IPROC Touchscreen Controller
>>
>>  Required properties:
>> -- compatible: must be "brcm,iproc-touchscreen"
>> -- reg: physical base address of the controller and length of memory mapped
>> -  region.
>> +- compatible: should be one of
>> +"brcm,iproc-touchscreen"
>> +"brcm,iproc-touchscreen-syscon"
>
> More specific and this is not how you do syscon. Either the block is or
> isn't. You can't have it both ways.

Existing driver has support for reg, if we modify now to support only syscon
then this driver will not work if some one wishes to use previous
kernel version's
dt and vice versa. Basically this breaks dt compatibility. Is that ok ?

>> +- ts_syscon: if "brcm,iproc-touchscreen-syscon" compatible string
>> +  is selected then "ts_syscon" is mandatory or else not required.
>> +  The "ts_syscon" is handler of syscon node defining physical base
>> +  address of the controller and length of memory mapped region.
>> +  If this property is selected please make sure MFD_SYSCON config
>> +  is enabled in the defconfig file.
>> +- reg: if "brcm,iproc-touchscreen" compatible string is selected
>> +  then "reg" property is mandatory or else not required.
>> +  The "reg" should be physical base address of the controller and
>> +  length of memory mapped region.
>
> I thought every chip to date is a syscon. Add reg support when you
> actually need it.

Since the existing driver has support for reg and now if we modify it to
support syscon only then we break the dt compatibility with previous kernel
versions. So keeping support for both will help to avoid dt
compatibility issues.

I will change the driver if you still think syscon only support is fine.
Let me know your opinion.

>>  - clocks:  The clock provided by the SOC to driver the tsc
>>  - clock-name:  name for the clock
>>  - interrupts: The touchscreen controller's interrupt
>> +- address-cells: Specify the number of u32 entries needed in child nodes.
>> + Should set to 1. This property is mandatory when
>> + "brcm,iproc-touchscreen-syscon" compatible string is 
>> selected
>> + or else not required.
>> +- size-cells: Specify number of u32 entries needed to specify child nodes 
>> size
>> +  in reg property. Should set to 1.This property is mandatory 
>> when
>> +  "brcm,iproc-touchscreen-syscon" compatible string is selected 
>> or
>> +  else not required.
>>
>>  Optional properties:
>>  - scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
>> @@ -53,13 +71,40 @@ Optional properties:
>>  - touchscreen-inverted-x: X axis is inverted (boolean)
>>  - touchscreen-inverted-y: Y axis is inverted (boolean)
>>
>> -Example:
>> +Example 1: An example of touchscreen node with 
>> "brcm,iproc-touchscreen-syscon"
>> +   compatible string.
>> +
>> + ts_adc_syscon: ts_adc_syscon@0x180a6000 {
>> + compatible = "syscon";
>> + reg = <0x180a6000 0xc30>;
>> + };
>>
>>   touchscreen: tsc@0x180A6000 {
>
> Drop the '0x' and the node name should be touchscreen, not tsc.

I will address this in the next patch.

>> - compatible = "brcm,iproc-touchscreen";
>> + compatible = "brcm,iproc-touchscreen-syscon";
>>   #address-cells = 

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Krzysztof Kozlowski]

2016-02-19 4:14 GMT+09:00 Anand Moon :
> Hi Peter,
>
> On 18 February 2016 at 23:18, Peter Hurley  wrote:
>> Hi Anand,
>>
>> On 02/18/2016 09:40 AM, Anand Moon wrote:
>>> From: Anand Moon 
>>>
>>> changes fix the correct order of the spin_lock_irqrestore/save.
>>>
>>> Signed-off-by: Anand Moon 
>>> ---
>>>  drivers/tty/serial/samsung.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>>> index d72cd73..96fe14d 100644
>>> --- a/drivers/tty/serial/samsung.c
>>> +++ b/drivers/tty/serial/samsung.c
>>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, 
>>> void *id)
>>>   }
>>>
>>>   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
>>> - spin_unlock(>lock);
>>> + spin_unlock_irqrestore(>lock, flags);
>>>   uart_write_wakeup(port);
>>> - spin_lock(>lock);
>>> + spin_lock_irqsave(>lock, flags);
>>
>> This driver shouldn't be dropping the spin lock at for write wakeup.
>> If this is causing lock-ups in a line discipline, the line discipline
>> needs fixed.
>>
>
> Thanks for pointing out.
> Their is no lock up, just the inconstancy of the spin_lock.
> Then I will resend this patch dropping the spin_unlock/spin_lock
> around uart_write_wakeup.
> Is that ok with you.

Anand, before doing that, can you check Peter's second sentence? I
mean the "If this is causing lock-ups in a line discipline, the line
discipline needs fixed.".
Don't drop the spin-locks "just because". I would be happy to see more
detailed explanation in changelog.

Best regards,
Krzysztof

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Krzysztof Kozlowski]

2016-02-19 4:14 GMT+09:00 Anand Moon :
> Hi Peter,
>
> On 18 February 2016 at 23:18, Peter Hurley  wrote:
>> Hi Anand,
>>
>> On 02/18/2016 09:40 AM, Anand Moon wrote:
>>> From: Anand Moon 
>>>
>>> changes fix the correct order of the spin_lock_irqrestore/save.
>>>
>>> Signed-off-by: Anand Moon 
>>> ---
>>>  drivers/tty/serial/samsung.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>>> index d72cd73..96fe14d 100644
>>> --- a/drivers/tty/serial/samsung.c
>>> +++ b/drivers/tty/serial/samsung.c
>>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, 
>>> void *id)
>>>   }
>>>
>>>   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
>>> - spin_unlock(>lock);
>>> + spin_unlock_irqrestore(>lock, flags);
>>>   uart_write_wakeup(port);
>>> - spin_lock(>lock);
>>> + spin_lock_irqsave(>lock, flags);
>>
>> This driver shouldn't be dropping the spin lock at for write wakeup.
>> If this is causing lock-ups in a line discipline, the line discipline
>> needs fixed.
>>
>
> Thanks for pointing out.
> Their is no lock up, just the inconstancy of the spin_lock.
> Then I will resend this patch dropping the spin_unlock/spin_lock
> around uart_write_wakeup.
> Is that ok with you.

Anand, before doing that, can you check Peter's second sentence? I
mean the "If this is causing lock-ups in a line discipline, the line
discipline needs fixed.".
Don't drop the spin-locks "just because". I would be happy to see more
detailed explanation in changelog.

Best regards,
Krzysztof

[PATCH] arm64, kbuild: make "make install" not depend on vmlinux

[Masahiro Yamada]

For the same reason as commit 19514fc665ff (arm, kbuild: make "make
install" not depend on vmlinux), the install targets should never
trigger the rebuild of the kernel.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/Makefile|  2 +-
 arch/arm64/boot/Makefile   |  4 ++--
 arch/arm64/boot/install.sh | 14 ++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 307237c..b5e3f6d 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -88,7 +88,7 @@ Image: vmlinux
 Image.%: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-zinstall install: vmlinux
+zinstall install:
$(Q)$(MAKE) $(build)=$(boot) $@
 
 %.dtb: scripts
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index abcbba2..305c552 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -34,10 +34,10 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
 $(obj)/Image.lzo: $(obj)/Image FORCE
$(call if_changed,lzo)
 
-install: $(obj)/Image
+install:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image System.map "$(INSTALL_PATH)"
 
-zinstall: $(obj)/Image.gz
+zinstall:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image.gz System.map "$(INSTALL_PATH)"
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
index 12ed78a..d91e1f0 100644
--- a/arch/arm64/boot/install.sh
+++ b/arch/arm64/boot/install.sh
@@ -20,6 +20,20 @@
 #   $4 - default install path (blank if root directory)
 #
 
+verify () {
+   if [ ! -f "$1" ]; then
+   echo ""   1>&2
+   echo " *** Missing file: $1"  1>&2
+   echo ' *** You need to run "make" before "make install".' 1>&2
+   echo ""   1>&2
+   exit 1
+   fi
+}
+
+# Make sure the files actually exist
+verify "$2"
+verify "$3"
+
 # User may have a custom install script
 if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
 if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
-- 
1.9.1

[PATCH] arm64, kbuild: make "make install" not depend on vmlinux

[Masahiro Yamada]

For the same reason as commit 19514fc665ff (arm, kbuild: make "make
install" not depend on vmlinux), the install targets should never
trigger the rebuild of the kernel.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/Makefile|  2 +-
 arch/arm64/boot/Makefile   |  4 ++--
 arch/arm64/boot/install.sh | 14 ++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 307237c..b5e3f6d 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -88,7 +88,7 @@ Image: vmlinux
 Image.%: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-zinstall install: vmlinux
+zinstall install:
$(Q)$(MAKE) $(build)=$(boot) $@
 
 %.dtb: scripts
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index abcbba2..305c552 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -34,10 +34,10 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
 $(obj)/Image.lzo: $(obj)/Image FORCE
$(call if_changed,lzo)
 
-install: $(obj)/Image
+install:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image System.map "$(INSTALL_PATH)"
 
-zinstall: $(obj)/Image.gz
+zinstall:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image.gz System.map "$(INSTALL_PATH)"
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
index 12ed78a..d91e1f0 100644
--- a/arch/arm64/boot/install.sh
+++ b/arch/arm64/boot/install.sh
@@ -20,6 +20,20 @@
 #   $4 - default install path (blank if root directory)
 #
 
+verify () {
+   if [ ! -f "$1" ]; then
+   echo ""   1>&2
+   echo " *** Missing file: $1"  1>&2
+   echo ' *** You need to run "make" before "make install".' 1>&2
+   echo ""   1>&2
+   exit 1
+   fi
+}
+
+# Make sure the files actually exist
+verify "$2"
+verify "$3"
+
 # User may have a custom install script
 if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
 if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
-- 
1.9.1

Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore

[Krzysztof Kozlowski]

2016-02-19 2:21 GMT+09:00 Anand Moon :
> From: Anand Moon 
>
> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking.
> It's safe to initialize pl330_tasklet tasklet after release of the locking.

This is tasklet init, not tasklet execution (which you are referring
to in first sentence). I don't get how usage of spinlock during
execution guarantees the safeness during init... Please describe why
this is safe.

Best regards,
Krzysztof

>
> Signed-off-by: Anand Moon 
> ---
>  drivers/dma/pl330.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 17ee758..df2cab1 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct dma_chan 
> *chan)
> return -ENOMEM;
> }
>
> -   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
> -
> spin_unlock_irqrestore(>lock, flags);
>
> +   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
> +
> return 1;
>  }
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore

[Krzysztof Kozlowski]

2016-02-19 2:21 GMT+09:00 Anand Moon :
> From: Anand Moon 
>
> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking.
> It's safe to initialize pl330_tasklet tasklet after release of the locking.

This is tasklet init, not tasklet execution (which you are referring
to in first sentence). I don't get how usage of spinlock during
execution guarantees the safeness during init... Please describe why
this is safe.

Best regards,
Krzysztof

>
> Signed-off-by: Anand Moon 
> ---
>  drivers/dma/pl330.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 17ee758..df2cab1 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct dma_chan 
> *chan)
> return -ENOMEM;
> }
>
> -   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
> -
> spin_unlock_irqrestore(>lock, flags);
>
> +   tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
> +
> return 1;
>  }
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html