Re: [PATCH] staging: dgnc: Fix a NULL pointer dereference

[Greg KH]

On Tue, May 03, 2016 at 10:56:09PM -0700, Greg KH wrote:
> On Wed, May 04, 2016 at 02:41:22PM +0900, Daeseok Youn wrote:
> > The error handling for print_drive after calling tty_alloc_driver()
> > was needed. But there was error handling but too late for this.
> > Error handling code moved after tty_alloc_driver() call.
> > 
> > Fixes: 60b3109e5e2d ("staging: dgnc: use tty_alloc_driver instead of 
> > kcalloc")
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Daeseok Youn 
> > ---
> >  drivers/staging/dgnc/dgnc_tty.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> Patch doesn't apply at all, does it need something else to be merged
> first?

Oh nevermind, I tried applying it to the wrong git tree, my fault...

I need some sleep...

greg k-h

Re: [PATCH] staging: dgnc: Fix a NULL pointer dereference

[Greg KH]

On Tue, May 03, 2016 at 10:56:09PM -0700, Greg KH wrote:
> On Wed, May 04, 2016 at 02:41:22PM +0900, Daeseok Youn wrote:
> > The error handling for print_drive after calling tty_alloc_driver()
> > was needed. But there was error handling but too late for this.
> > Error handling code moved after tty_alloc_driver() call.
> > 
> > Fixes: 60b3109e5e2d ("staging: dgnc: use tty_alloc_driver instead of 
> > kcalloc")
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Daeseok Youn 
> > ---
> >  drivers/staging/dgnc/dgnc_tty.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> Patch doesn't apply at all, does it need something else to be merged
> first?

Oh nevermind, I tried applying it to the wrong git tree, my fault...

I need some sleep...

greg k-h

Re: [PATCH] staging: dgnc: Fix a NULL pointer dereference

[Greg KH]

On Wed, May 04, 2016 at 02:41:22PM +0900, Daeseok Youn wrote:
> The error handling for print_drive after calling tty_alloc_driver()
> was needed. But there was error handling but too late for this.
> Error handling code moved after tty_alloc_driver() call.
> 
> Fixes: 60b3109e5e2d ("staging: dgnc: use tty_alloc_driver instead of kcalloc")
> Reported-by: Dan Carpenter 
> Signed-off-by: Daeseok Youn 
> ---
>  drivers/staging/dgnc/dgnc_tty.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Patch doesn't apply at all, does it need something else to be merged
first?

confused,

greg k-h

Re: [PATCH] staging: dgnc: Fix a NULL pointer dereference

[Greg KH]

On Wed, May 04, 2016 at 02:41:22PM +0900, Daeseok Youn wrote:
> The error handling for print_drive after calling tty_alloc_driver()
> was needed. But there was error handling but too late for this.
> Error handling code moved after tty_alloc_driver() call.
> 
> Fixes: 60b3109e5e2d ("staging: dgnc: use tty_alloc_driver instead of kcalloc")
> Reported-by: Dan Carpenter 
> Signed-off-by: Daeseok Youn 
> ---
>  drivers/staging/dgnc/dgnc_tty.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Patch doesn't apply at all, does it need something else to be merged
first?

confused,

greg k-h

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

[Yinghai Lu]

On Tue, May 3, 2016 at 10:08 PM, Yinghai Lu  wrote:
> On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas  wrote:
>> I did not propose changing any user-visible ABI.  To recap what I did
>> propose:
>
> I want to avoid introduce one strange pci_user_to_resource.
>
>>
>>   - The sysfs path uses offsets between 0 and BAR size on all arches.
>> It uses pci_resource_to_user() today, but I think it should not.
>>
>>   - The procfs path uses offsets of resource values (CPU physical
>> addresses) on most architectures, but uses something else, e.g.,
>> BAR values, on others.  pci_resource_to_user() does this
>> translation.  The procfs path does not use pci_resource_to_user()
>> today, but I think it should.
>
> current powerpc pci_resource_to_user is strange:
> it will return resource start for io mem.
> but will return BAR (?) start for io port.
>
> sparc pci_resource_to_user does return BAR value for iomem.
>
>>
>>   - This implies that pci_mmap_page_range() should deal with resource
>> values (CPU physical addresses), and proc_bus_pci_mmap() should do
>> any necessary arch-specific translation from BAR values to
>> resource values.
>
> so will need one different version pci_user_to_resource.
> and can not use pcibios_bus_to_resource directly, and will be another mess.

looks like we can avoid that pci_user_to_resource() via trying out.

Please check it:


Subject: [RFC PATCH] PCI: Let pci_mmap_page_range() take resource addr

Some arch where cpu address (resource value) is not same as pci bus address
(BAR value in pci BAR registers), include sparc, powerpc, microblaze.

In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
to check exposed value with resource start/end in proc mmap path.
|start = vma->vm_pgoff;
|size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
|pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
|pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
|if (start >= pci_start && start < pci_start + size &&
|start + nr <= pci_start + size)
That would break sparc that exposed value is still BAR value.

According to Bjorn, we could just pass resource addr instead of BAR.

In the patch:
1. in proc path: proc_bus_pci_mmap, try convert back to resource
   before calling pci_mmap_page_range
2. in sysfs path: pci_mmap_resource will just offset with resource start.
3. all pci_mmap_page_range will all have vma->vm_pgoff with in resource range
   instead of BAR value.

Signed-off-by: Yinghai Lu 

---
 arch/microblaze/pci/pci-common.c |   14 --
 arch/powerpc/kernel/pci-common.c |   14 --
 arch/sparc/kernel/pci.c  |   27 +--
 arch/xtensa/kernel/pci.c |   11 ---
 drivers/pci/pci-sysfs.c  |8 +---
 drivers/pci/proc.c   |   13 +
 6 files changed, 35 insertions(+), 52 deletions(-)

Index: linux-2.6/arch/microblaze/pci/pci-common.c
===
--- linux-2.6.orig/arch/microblaze/pci/pci-common.c
+++ linux-2.6/arch/microblaze/pci/pci-common.c
@@ -169,23 +169,16 @@ static struct resource *__pci_mmap_make_
enum pci_mmap_state mmap_state)
 {
 struct pci_controller *hose = pci_bus_to_host(dev->bus);
-unsigned long io_offset = 0;
 int i, res_bit;

 if (!hose)
 return NULL;/* should never happen */

 /* If memory, add on the PCI bridge address offset */
-if (mmap_state == pci_mmap_mem) {
-#if 0 /* See comment in pci_resource_to_user() for why this is disabled */
-*offset += hose->pci_mem_offset;
-#endif
+if (mmap_state == pci_mmap_mem)
 res_bit = IORESOURCE_MEM;
-} else {
-io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
-*offset += io_offset;
+else
 res_bit = IORESOURCE_IO;
-}

 /*
  * Check that the offset requested corresponds to one of the
@@ -209,7 +202,8 @@ static struct resource *__pci_mmap_make_

 /* found it! construct the final physical address */
 if (mmap_state == pci_mmap_io)
-*offset += hose->io_base_phys - io_offset;
+*offset += hose->io_base_phys -
+ ((unsigned long)hose->io_base_virt - _IO_BASE);
 return rp;
 }

Index: linux-2.6/arch/powerpc/kernel/pci-common.c
===
--- linux-2.6.orig/arch/powerpc/kernel/pci-common.c
+++ linux-2.6/arch/powerpc/kernel/pci-common.c
@@ -308,23 +308,16 @@ static struct resource *__pci_mmap_make_
enum pci_mmap_state mmap_state)
 {
 struct pci_controller *hose = pci_bus_to_host(dev->bus);
-unsigned long io_offset = 0;
 int i, res_bit;

 if (hose == NULL)
 return NULL;/* should never happen */

 /* If 

[PATCH 06/15] ACPICA: ACPI 6.0, tools/iasl: Add support for new resource descriptors

[Lv Zheng]

From: Bob Moore 

ACPICA commit 5a0555ece4ba9917e5842b21d88469ae06b4e815

Adds full support for:
i2c_serial_bus_v2
spi_serial_bus_v2
uart_serial_bus_v2

Compiler, Disassembler, Resource Manager, acpi_help.

Link: https://github.com/acpica/acpica/commit/5a0555ec
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/rsdumpinfo.c |9 +
 drivers/acpi/acpica/rsserial.c   |   21 ++---
 include/acpi/acrestyp.h  |1 +
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/acpica/rsdumpinfo.c b/drivers/acpi/acpica/rsdumpinfo.c
index 5c34913..61e8f16 100644
--- a/drivers/acpi/acpica/rsdumpinfo.c
+++ b/drivers/acpi/acpica/rsdumpinfo.c
@@ -330,19 +330,20 @@ struct acpi_rsdump_info acpi_rs_dump_fixed_dma[4] = {
{ACPI_RSD_UINT8,ACPI_RSD_OFFSET (common_serial_bus.type),   
"Type", acpi_gbl_sbt_decode}, \
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET 
(common_serial_bus.producer_consumer), "ProducerConsumer",  
acpi_gbl_consume_decode}, \
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (common_serial_bus.slave_mode), 
"SlaveMode",acpi_gbl_sm_decode}, \
+   {ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET 
(common_serial_bus.connection_sharing),"ConnectionSharing", 
acpi_gbl_shr_decode}, \
{ACPI_RSD_UINT8,ACPI_RSD_OFFSET 
(common_serial_bus.type_revision_id), "TypeRevisionId", NULL}, \
{ACPI_RSD_UINT16,   ACPI_RSD_OFFSET 
(common_serial_bus.type_data_length), "TypeDataLength", NULL}, \
{ACPI_RSD_SOURCE,   ACPI_RSD_OFFSET 
(common_serial_bus.resource_source), "ResourceSource",  NULL}, \
{ACPI_RSD_UINT16,   ACPI_RSD_OFFSET (common_serial_bus.vendor_length),  
"VendorLength", NULL}, \
{ACPI_RSD_SHORTLISTX,ACPI_RSD_OFFSET (common_serial_bus.vendor_data),   
"VendorData",   NULL},
 
-struct acpi_rsdump_info acpi_rs_dump_common_serial_bus[10] = {
+struct acpi_rsdump_info acpi_rs_dump_common_serial_bus[11] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_common_serial_bus),
 "Common Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS
 };
 
-struct acpi_rsdump_info acpi_rs_dump_i2c_serial_bus[13] = {
+struct acpi_rsdump_info acpi_rs_dump_i2c_serial_bus[14] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_i2c_serial_bus),
 "I2C Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS {ACPI_RSD_1BITFLAG,
@@ -355,7 +356,7 @@ struct acpi_rsdump_info acpi_rs_dump_i2c_serial_bus[13] = {
 "SlaveAddress", NULL},
 };
 
-struct acpi_rsdump_info acpi_rs_dump_spi_serial_bus[17] = {
+struct acpi_rsdump_info acpi_rs_dump_spi_serial_bus[18] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_spi_serial_bus),
 "Spi Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS {ACPI_RSD_1BITFLAG,
@@ -376,7 +377,7 @@ struct acpi_rsdump_info acpi_rs_dump_spi_serial_bus[17] = {
 "ConnectionSpeed", NULL},
 };
 
-struct acpi_rsdump_info acpi_rs_dump_uart_serial_bus[19] = {
+struct acpi_rsdump_info acpi_rs_dump_uart_serial_bus[20] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_uart_serial_bus),
 "Uart Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS {ACPI_RSD_2BITFLAG,
diff --git a/drivers/acpi/acpica/rsserial.c b/drivers/acpi/acpica/rsserial.c
index 8a01296..b82c061 100644
--- a/drivers/acpi/acpica/rsserial.c
+++ b/drivers/acpi/acpica/rsserial.c
@@ -151,7 +151,7 @@ struct acpi_rsconvert_info acpi_rs_convert_gpio[18] = {
  *
  
**/
 
-struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[16] = {
+struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[17] = {
{ACPI_RSC_INITGET, ACPI_RESOURCE_TYPE_SERIAL_BUS,
 ACPI_RS_SIZE(struct acpi_resource_i2c_serialbus),
 ACPI_RSC_TABLE_SIZE(acpi_rs_convert_i2c_serial_bus)},
@@ -177,6 +177,11 @@ struct acpi_rsconvert_info 
acpi_rs_convert_i2c_serial_bus[16] = {
 AML_OFFSET(common_serial_bus.flags),
 1},
 
+   {ACPI_RSC_1BITFLAG,
+ACPI_RS_OFFSET(data.common_serial_bus.connection_sharing),
+AML_OFFSET(common_serial_bus.flags),
+2},
+
{ACPI_RSC_MOVE8,
 ACPI_RS_OFFSET(data.common_serial_bus.type_revision_id),
 AML_OFFSET(common_serial_bus.type_revision_id),
@@ -237,7 +242,7 @@ struct acpi_rsconvert_info 
acpi_rs_convert_i2c_serial_bus[16] = {
  *
  
**/
 
-struct acpi_rsconvert_info acpi_rs_convert_spi_serial_bus[20] = {
+struct acpi_rsconvert_info acpi_rs_convert_spi_serial_bus[21] = {
{ACPI_RSC_INITGET, ACPI_RESOURCE_TYPE_SERIAL_BUS,
 ACPI_RS_SIZE(struct acpi_resource_spi_serialbus),
 ACPI_RSC_TABLE_SIZE(acpi_rs_convert_spi_serial_bus)},
@@ 

linux-next: build warning after merge of the lightnvm tree

[Stephen Rothwell]

Hi Matias,

After merging the lightnvm tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

In file included from include/linux/swab.h:4:0,
 from include/uapi/linux/byteorder/big_endia
n.h:12,
 from include/linux/byteorder/big_endian.h:4
,
 from arch/powerpc/include/uapi/asm/byteorde
r.h:13,
 from include/asm-generic/bitops/le.h:5,
 from arch/powerpc/include/asm/bitops.h:279,
 from include/linux/bitops.h:36,
 from include/linux/kernel.h:10,
 from include/linux/list.h:8,
 from include/linux/pci.h:25,
 from drivers/nvme/host/nvme.h:18,
 from drivers/nvme/host/lightnvm.c:23:
drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_rqtocmd'
:
include/uapi/linux/byteorder/big_endian.h:30:52: warning: passing argument 1 of 
'__fswab64' makes integer from pointer without a cast [-Wint-conversion]
 #define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^
include/uapi/linux/swab.h:126:12: note: in definition of macro '__swab64'
  __fswab64(x))
^
include/linux/byteorder/generic.h:85:21: note: in expansion of macro 
'__cpu_to_le64'
 #define cpu_to_le64 __cpu_to_le64
 ^
drivers/nvme/host/lightnvm.c:472:22: note: in expansion of macro 'cpu_to_le64'
  c->ph_rw.metadata = cpu_to_le64(rqd->meta_list);
  ^
include/uapi/linux/swab.h:68:41: note: expected '__u64 {aka long long unsigned 
int}' but argument is of type 'void *'
 static inline __attribute_const__ __u64 __fswab64(__u64 val)
 ^

Introduced by commit

  a34b1eb78e21 ("lightnvm: enable metadata to be sent to device")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

[Yinghai Lu]

On Tue, May 3, 2016 at 10:08 PM, Yinghai Lu  wrote:
> On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas  wrote:
>> I did not propose changing any user-visible ABI.  To recap what I did
>> propose:
>
> I want to avoid introduce one strange pci_user_to_resource.
>
>>
>>   - The sysfs path uses offsets between 0 and BAR size on all arches.
>> It uses pci_resource_to_user() today, but I think it should not.
>>
>>   - The procfs path uses offsets of resource values (CPU physical
>> addresses) on most architectures, but uses something else, e.g.,
>> BAR values, on others.  pci_resource_to_user() does this
>> translation.  The procfs path does not use pci_resource_to_user()
>> today, but I think it should.
>
> current powerpc pci_resource_to_user is strange:
> it will return resource start for io mem.
> but will return BAR (?) start for io port.
>
> sparc pci_resource_to_user does return BAR value for iomem.
>
>>
>>   - This implies that pci_mmap_page_range() should deal with resource
>> values (CPU physical addresses), and proc_bus_pci_mmap() should do
>> any necessary arch-specific translation from BAR values to
>> resource values.
>
> so will need one different version pci_user_to_resource.
> and can not use pcibios_bus_to_resource directly, and will be another mess.

looks like we can avoid that pci_user_to_resource() via trying out.

Please check it:


Subject: [RFC PATCH] PCI: Let pci_mmap_page_range() take resource addr

Some arch where cpu address (resource value) is not same as pci bus address
(BAR value in pci BAR registers), include sparc, powerpc, microblaze.

In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
to check exposed value with resource start/end in proc mmap path.
|start = vma->vm_pgoff;
|size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
|pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
|pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
|if (start >= pci_start && start < pci_start + size &&
|start + nr <= pci_start + size)
That would break sparc that exposed value is still BAR value.

According to Bjorn, we could just pass resource addr instead of BAR.

In the patch:
1. in proc path: proc_bus_pci_mmap, try convert back to resource
   before calling pci_mmap_page_range
2. in sysfs path: pci_mmap_resource will just offset with resource start.
3. all pci_mmap_page_range will all have vma->vm_pgoff with in resource range
   instead of BAR value.

Signed-off-by: Yinghai Lu 

---
 arch/microblaze/pci/pci-common.c |   14 --
 arch/powerpc/kernel/pci-common.c |   14 --
 arch/sparc/kernel/pci.c  |   27 +--
 arch/xtensa/kernel/pci.c |   11 ---
 drivers/pci/pci-sysfs.c  |8 +---
 drivers/pci/proc.c   |   13 +
 6 files changed, 35 insertions(+), 52 deletions(-)

Index: linux-2.6/arch/microblaze/pci/pci-common.c
===
--- linux-2.6.orig/arch/microblaze/pci/pci-common.c
+++ linux-2.6/arch/microblaze/pci/pci-common.c
@@ -169,23 +169,16 @@ static struct resource *__pci_mmap_make_
enum pci_mmap_state mmap_state)
 {
 struct pci_controller *hose = pci_bus_to_host(dev->bus);
-unsigned long io_offset = 0;
 int i, res_bit;

 if (!hose)
 return NULL;/* should never happen */

 /* If memory, add on the PCI bridge address offset */
-if (mmap_state == pci_mmap_mem) {
-#if 0 /* See comment in pci_resource_to_user() for why this is disabled */
-*offset += hose->pci_mem_offset;
-#endif
+if (mmap_state == pci_mmap_mem)
 res_bit = IORESOURCE_MEM;
-} else {
-io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
-*offset += io_offset;
+else
 res_bit = IORESOURCE_IO;
-}

 /*
  * Check that the offset requested corresponds to one of the
@@ -209,7 +202,8 @@ static struct resource *__pci_mmap_make_

 /* found it! construct the final physical address */
 if (mmap_state == pci_mmap_io)
-*offset += hose->io_base_phys - io_offset;
+*offset += hose->io_base_phys -
+ ((unsigned long)hose->io_base_virt - _IO_BASE);
 return rp;
 }

Index: linux-2.6/arch/powerpc/kernel/pci-common.c
===
--- linux-2.6.orig/arch/powerpc/kernel/pci-common.c
+++ linux-2.6/arch/powerpc/kernel/pci-common.c
@@ -308,23 +308,16 @@ static struct resource *__pci_mmap_make_
enum pci_mmap_state mmap_state)
 {
 struct pci_controller *hose = pci_bus_to_host(dev->bus);
-unsigned long io_offset = 0;
 int i, res_bit;

 if (hose == NULL)
 return NULL;/* should never happen */

 /* If memory, add on the PCI bridge address offset */
-if 

[PATCH 06/15] ACPICA: ACPI 6.0, tools/iasl: Add support for new resource descriptors

[Lv Zheng]

From: Bob Moore 

ACPICA commit 5a0555ece4ba9917e5842b21d88469ae06b4e815

Adds full support for:
i2c_serial_bus_v2
spi_serial_bus_v2
uart_serial_bus_v2

Compiler, Disassembler, Resource Manager, acpi_help.

Link: https://github.com/acpica/acpica/commit/5a0555ec
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/rsdumpinfo.c |9 +
 drivers/acpi/acpica/rsserial.c   |   21 ++---
 include/acpi/acrestyp.h  |1 +
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/acpica/rsdumpinfo.c b/drivers/acpi/acpica/rsdumpinfo.c
index 5c34913..61e8f16 100644
--- a/drivers/acpi/acpica/rsdumpinfo.c
+++ b/drivers/acpi/acpica/rsdumpinfo.c
@@ -330,19 +330,20 @@ struct acpi_rsdump_info acpi_rs_dump_fixed_dma[4] = {
{ACPI_RSD_UINT8,ACPI_RSD_OFFSET (common_serial_bus.type),   
"Type", acpi_gbl_sbt_decode}, \
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET 
(common_serial_bus.producer_consumer), "ProducerConsumer",  
acpi_gbl_consume_decode}, \
{ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET (common_serial_bus.slave_mode), 
"SlaveMode",acpi_gbl_sm_decode}, \
+   {ACPI_RSD_1BITFLAG, ACPI_RSD_OFFSET 
(common_serial_bus.connection_sharing),"ConnectionSharing", 
acpi_gbl_shr_decode}, \
{ACPI_RSD_UINT8,ACPI_RSD_OFFSET 
(common_serial_bus.type_revision_id), "TypeRevisionId", NULL}, \
{ACPI_RSD_UINT16,   ACPI_RSD_OFFSET 
(common_serial_bus.type_data_length), "TypeDataLength", NULL}, \
{ACPI_RSD_SOURCE,   ACPI_RSD_OFFSET 
(common_serial_bus.resource_source), "ResourceSource",  NULL}, \
{ACPI_RSD_UINT16,   ACPI_RSD_OFFSET (common_serial_bus.vendor_length),  
"VendorLength", NULL}, \
{ACPI_RSD_SHORTLISTX,ACPI_RSD_OFFSET (common_serial_bus.vendor_data),   
"VendorData",   NULL},
 
-struct acpi_rsdump_info acpi_rs_dump_common_serial_bus[10] = {
+struct acpi_rsdump_info acpi_rs_dump_common_serial_bus[11] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_common_serial_bus),
 "Common Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS
 };
 
-struct acpi_rsdump_info acpi_rs_dump_i2c_serial_bus[13] = {
+struct acpi_rsdump_info acpi_rs_dump_i2c_serial_bus[14] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_i2c_serial_bus),
 "I2C Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS {ACPI_RSD_1BITFLAG,
@@ -355,7 +356,7 @@ struct acpi_rsdump_info acpi_rs_dump_i2c_serial_bus[13] = {
 "SlaveAddress", NULL},
 };
 
-struct acpi_rsdump_info acpi_rs_dump_spi_serial_bus[17] = {
+struct acpi_rsdump_info acpi_rs_dump_spi_serial_bus[18] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_spi_serial_bus),
 "Spi Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS {ACPI_RSD_1BITFLAG,
@@ -376,7 +377,7 @@ struct acpi_rsdump_info acpi_rs_dump_spi_serial_bus[17] = {
 "ConnectionSpeed", NULL},
 };
 
-struct acpi_rsdump_info acpi_rs_dump_uart_serial_bus[19] = {
+struct acpi_rsdump_info acpi_rs_dump_uart_serial_bus[20] = {
{ACPI_RSD_TITLE, ACPI_RSD_TABLE_SIZE(acpi_rs_dump_uart_serial_bus),
 "Uart Serial Bus", NULL},
ACPI_RS_DUMP_COMMON_SERIAL_BUS {ACPI_RSD_2BITFLAG,
diff --git a/drivers/acpi/acpica/rsserial.c b/drivers/acpi/acpica/rsserial.c
index 8a01296..b82c061 100644
--- a/drivers/acpi/acpica/rsserial.c
+++ b/drivers/acpi/acpica/rsserial.c
@@ -151,7 +151,7 @@ struct acpi_rsconvert_info acpi_rs_convert_gpio[18] = {
  *
  
**/
 
-struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[16] = {
+struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[17] = {
{ACPI_RSC_INITGET, ACPI_RESOURCE_TYPE_SERIAL_BUS,
 ACPI_RS_SIZE(struct acpi_resource_i2c_serialbus),
 ACPI_RSC_TABLE_SIZE(acpi_rs_convert_i2c_serial_bus)},
@@ -177,6 +177,11 @@ struct acpi_rsconvert_info 
acpi_rs_convert_i2c_serial_bus[16] = {
 AML_OFFSET(common_serial_bus.flags),
 1},
 
+   {ACPI_RSC_1BITFLAG,
+ACPI_RS_OFFSET(data.common_serial_bus.connection_sharing),
+AML_OFFSET(common_serial_bus.flags),
+2},
+
{ACPI_RSC_MOVE8,
 ACPI_RS_OFFSET(data.common_serial_bus.type_revision_id),
 AML_OFFSET(common_serial_bus.type_revision_id),
@@ -237,7 +242,7 @@ struct acpi_rsconvert_info 
acpi_rs_convert_i2c_serial_bus[16] = {
  *
  
**/
 
-struct acpi_rsconvert_info acpi_rs_convert_spi_serial_bus[20] = {
+struct acpi_rsconvert_info acpi_rs_convert_spi_serial_bus[21] = {
{ACPI_RSC_INITGET, ACPI_RESOURCE_TYPE_SERIAL_BUS,
 ACPI_RS_SIZE(struct acpi_resource_spi_serialbus),
 ACPI_RSC_TABLE_SIZE(acpi_rs_convert_spi_serial_bus)},
@@ -263,6 +268,11 @@ struct acpi_rsconvert_info 

linux-next: build warning after merge of the lightnvm tree

[Stephen Rothwell]

Hi Matias,

After merging the lightnvm tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

In file included from include/linux/swab.h:4:0,
 from include/uapi/linux/byteorder/big_endia
n.h:12,
 from include/linux/byteorder/big_endian.h:4
,
 from arch/powerpc/include/uapi/asm/byteorde
r.h:13,
 from include/asm-generic/bitops/le.h:5,
 from arch/powerpc/include/asm/bitops.h:279,
 from include/linux/bitops.h:36,
 from include/linux/kernel.h:10,
 from include/linux/list.h:8,
 from include/linux/pci.h:25,
 from drivers/nvme/host/nvme.h:18,
 from drivers/nvme/host/lightnvm.c:23:
drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_rqtocmd'
:
include/uapi/linux/byteorder/big_endian.h:30:52: warning: passing argument 1 of 
'__fswab64' makes integer from pointer without a cast [-Wint-conversion]
 #define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^
include/uapi/linux/swab.h:126:12: note: in definition of macro '__swab64'
  __fswab64(x))
^
include/linux/byteorder/generic.h:85:21: note: in expansion of macro 
'__cpu_to_le64'
 #define cpu_to_le64 __cpu_to_le64
 ^
drivers/nvme/host/lightnvm.c:472:22: note: in expansion of macro 'cpu_to_le64'
  c->ph_rw.metadata = cpu_to_le64(rqd->meta_list);
  ^
include/uapi/linux/swab.h:68:41: note: expected '__u64 {aka long long unsigned 
int}' but argument is of type 'void *'
 static inline __attribute_const__ __u64 __fswab64(__u64 val)
 ^

Introduced by commit

  a34b1eb78e21 ("lightnvm: enable metadata to be sent to device")

-- 
Cheers,
Stephen Rothwell

[PATCH 12/15] ACPICA: Hardware: Add access_width/bit_offset support in acpi_hw_read()

[Lv Zheng]

ACPICA commit 96ece052d4d073aae4f935f0ff0746646aea1174
ACPICA commit 3d8583a054e410f2ea4d73b48986facad9cfc0d4

This patch adds access_width/bit_offset support in acpi_hw_read().
This also enables GAS definition where bit_width is not a power of
two. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/96ece052
Link: https://github.com/acpica/acpica/commit/3d8583a0
Link: https://bugs.acpica.org/show_bug.cgi?id=1240
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/hwregs.c |   75 ++
 1 file changed, 62 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 892e677..6eee012 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -195,17 +195,19 @@ acpi_hw_validate_register(struct acpi_generic_address 
*reg,
  *  64-bit values is not needed.
  *
  * LIMITATIONS: 
- *  bit_width must be exactly 8, 16, or 32.
  *  space_ID must be system_memory or system_IO.
- *  bit_offset and access_width are currently ignored, as there has
- *  not been a need to implement these.
  *
  
**/
 
 acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address *reg)
 {
u64 address;
+   u8 access_width;
+   u32 bit_width;
+   u8 bit_offset;
u64 value64;
+   u32 value32;
+   u8 index;
acpi_status status;
 
ACPI_FUNCTION_NAME(hw_read);
@@ -217,28 +219,75 @@ acpi_status acpi_hw_read(u32 *value, struct 
acpi_generic_address *reg)
return (status);
}
 
-   /* Initialize entire 32-bit return value to zero */
-
+   /*
+* Initialize entire 32-bit return value to zero, convert access_width
+* into number of bits based
+*/
*value = 0;
+   access_width = acpi_hw_get_access_bit_width(reg, 32);
+   bit_width = reg->bit_offset + reg->bit_width;
+   bit_offset = reg->bit_offset;
 
/*
 * Two address spaces supported: Memory or IO. PCI_Config is
 * not supported here because the GAS structure is insufficient
 */
-   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
-   status = acpi_os_read_memory((acpi_physical_address)
-address, , reg->bit_width);
+   index = 0;
+   while (bit_width) {
+   if (bit_offset >= access_width) {
+   value32 = 0;
+   bit_offset -= access_width;
+   } else {
+   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+   status =
+   acpi_os_read_memory((acpi_physical_address)
+   address +
+   index *
+   ACPI_DIV_8
+   (access_width),
+   , access_width);
+   value32 = (u32)value64;
+   } else {/* ACPI_ADR_SPACE_SYSTEM_IO, validated 
earlier */
+
+   status = acpi_hw_read_port((acpi_io_address)
+  address +
+  index *
+  ACPI_DIV_8
+  (access_width),
+  ,
+  access_width);
+   }
 
-   *value = (u32)value64;
-   } else {/* ACPI_ADR_SPACE_SYSTEM_IO, validated earlier 
*/
+   /*
+* Use offset style bit masks because:
+* bit_offset < access_width/bit_width < access_width, 
and
+* access_width is ensured to be less than 32-bits by
+* acpi_hw_validate_register().
+*/
+   if (bit_offset) {
+   value32 &= ACPI_MASK_BITS_BELOW(bit_offset);
+   bit_offset = 0;
+   }
+   if (bit_width < access_width) {
+   value32 &= ACPI_MASK_BITS_ABOVE(bit_width);
+   }
+   }
+
+   /*
+* Use offset style bit writes because "Index * AccessWidth" is
+* ensured to be less than 32-bits by 
acpi_hw_validate_register().
+*/
+   ACPI_SET_BITS(value, index * access_width,
+  

[PATCH 12/15] ACPICA: Hardware: Add access_width/bit_offset support in acpi_hw_read()

[Lv Zheng]

ACPICA commit 96ece052d4d073aae4f935f0ff0746646aea1174
ACPICA commit 3d8583a054e410f2ea4d73b48986facad9cfc0d4

This patch adds access_width/bit_offset support in acpi_hw_read().
This also enables GAS definition where bit_width is not a power of
two. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/96ece052
Link: https://github.com/acpica/acpica/commit/3d8583a0
Link: https://bugs.acpica.org/show_bug.cgi?id=1240
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/hwregs.c |   75 ++
 1 file changed, 62 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 892e677..6eee012 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -195,17 +195,19 @@ acpi_hw_validate_register(struct acpi_generic_address 
*reg,
  *  64-bit values is not needed.
  *
  * LIMITATIONS: 
- *  bit_width must be exactly 8, 16, or 32.
  *  space_ID must be system_memory or system_IO.
- *  bit_offset and access_width are currently ignored, as there has
- *  not been a need to implement these.
  *
  
**/
 
 acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address *reg)
 {
u64 address;
+   u8 access_width;
+   u32 bit_width;
+   u8 bit_offset;
u64 value64;
+   u32 value32;
+   u8 index;
acpi_status status;
 
ACPI_FUNCTION_NAME(hw_read);
@@ -217,28 +219,75 @@ acpi_status acpi_hw_read(u32 *value, struct 
acpi_generic_address *reg)
return (status);
}
 
-   /* Initialize entire 32-bit return value to zero */
-
+   /*
+* Initialize entire 32-bit return value to zero, convert access_width
+* into number of bits based
+*/
*value = 0;
+   access_width = acpi_hw_get_access_bit_width(reg, 32);
+   bit_width = reg->bit_offset + reg->bit_width;
+   bit_offset = reg->bit_offset;
 
/*
 * Two address spaces supported: Memory or IO. PCI_Config is
 * not supported here because the GAS structure is insufficient
 */
-   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
-   status = acpi_os_read_memory((acpi_physical_address)
-address, , reg->bit_width);
+   index = 0;
+   while (bit_width) {
+   if (bit_offset >= access_width) {
+   value32 = 0;
+   bit_offset -= access_width;
+   } else {
+   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+   status =
+   acpi_os_read_memory((acpi_physical_address)
+   address +
+   index *
+   ACPI_DIV_8
+   (access_width),
+   , access_width);
+   value32 = (u32)value64;
+   } else {/* ACPI_ADR_SPACE_SYSTEM_IO, validated 
earlier */
+
+   status = acpi_hw_read_port((acpi_io_address)
+  address +
+  index *
+  ACPI_DIV_8
+  (access_width),
+  ,
+  access_width);
+   }
 
-   *value = (u32)value64;
-   } else {/* ACPI_ADR_SPACE_SYSTEM_IO, validated earlier 
*/
+   /*
+* Use offset style bit masks because:
+* bit_offset < access_width/bit_width < access_width, 
and
+* access_width is ensured to be less than 32-bits by
+* acpi_hw_validate_register().
+*/
+   if (bit_offset) {
+   value32 &= ACPI_MASK_BITS_BELOW(bit_offset);
+   bit_offset = 0;
+   }
+   if (bit_width < access_width) {
+   value32 &= ACPI_MASK_BITS_ABOVE(bit_width);
+   }
+   }
+
+   /*
+* Use offset style bit writes because "Index * AccessWidth" is
+* ensured to be less than 32-bits by 
acpi_hw_validate_register().
+*/
+   ACPI_SET_BITS(value, index * access_width,
+ 

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

[Lv Zheng]

From: Bob Moore 

ACPICA commit a2327ba410e19c2aabaf34b711dbadf7d1dcf346

Version 20160422.

Link: https://github.com/acpica/acpica/commit/a2327ba4
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 366b364..4e4c214 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 0x20160318
+#define ACPI_CA_VERSION 0x20160422
 
 #include 
 #include 
-- 
1.7.10

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

[Lv Zheng]

From: Bob Moore 

ACPICA commit a2327ba410e19c2aabaf34b711dbadf7d1dcf346

Version 20160422.

Link: https://github.com/acpica/acpica/commit/a2327ba4
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 366b364..4e4c214 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 0x20160318
+#define ACPI_CA_VERSION 0x20160422
 
 #include 
 #include 
-- 
1.7.10

[PATCH 05/15] ACPICA: ACPI 6.0: Update _BIX support for new package element

[Lv Zheng]

From: Bob Moore 

ACPICA commit 3451e6d49d37919c13ec2c0019a31534b0dfc0c0

One integer was added at the end of the _BIX method, and the
version number was incremented.

Link: https://github.com/acpica/acpica/commit/3451e6d4
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |5 ++-
 drivers/acpi/acpica/nsprepkg.c |   86 
 2 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index 4ca426b..888440b 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -129,7 +129,8 @@ enum acpi_return_package_types {
ACPI_PTYPE2_REV_FIXED = 9,
ACPI_PTYPE2_FIX_VAR = 10,
ACPI_PTYPE2_VAR_VAR = 11,
-   ACPI_PTYPE2_UUID_PAIR = 12
+   ACPI_PTYPE2_UUID_PAIR = 12,
+   ACPI_PTYPE_CUSTOM = 13
 };
 
 /* Support macros for users of the predefined info table */
@@ -340,7 +341,7 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
 
{{"_BIX", METHOD_0ARGS,
  METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (16 Int),(4 
Str) */
-   PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 16,
+   PACKAGE_INFO(ACPI_PTYPE_CUSTOM, ACPI_RTYPE_INTEGER, 16,
 ACPI_RTYPE_STRING, 4, 0),
 
{{"_BLT",
diff --git a/drivers/acpi/acpica/nsprepkg.c b/drivers/acpi/acpica/nsprepkg.c
index fde5a09..fbedc6e 100644
--- a/drivers/acpi/acpica/nsprepkg.c
+++ b/drivers/acpi/acpica/nsprepkg.c
@@ -62,6 +62,10 @@ acpi_ns_check_package_elements(struct acpi_evaluate_info 
*info,
   u32 count1,
   u8 type2, u32 count2, u32 start_index);
 
+static acpi_status
+acpi_ns_custom_package(struct acpi_evaluate_info *info,
+  union acpi_operand_object **elements, u32 count);
+
 
/***
  *
  * FUNCTION:acpi_ns_check_package
@@ -135,6 +139,11 @@ acpi_ns_check_package(struct acpi_evaluate_info *info,
 * PTYPE2 packages contain subpackages
 */
switch (package->ret_info.type) {
+   case ACPI_PTYPE_CUSTOM:
+
+   status = acpi_ns_custom_package(info, elements, count);
+   break;
+
case ACPI_PTYPE1_FIXED:
/*
 * The package count is fixed and there are no subpackages
@@ -626,6 +635,83 @@ package_too_small:
 
 
/***
  *
+ * FUNCTION:acpi_ns_custom_package
+ *
+ * PARAMETERS:  info- Method execution information block
+ *  elements- Pointer to the package elements array
+ *  count   - Element count for the package
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Check a returned package object for the correct count and
+ *  correct type of all sub-objects.
+ *
+ * NOTE: Currently used for the _BIX method only. When needed for two or more
+ * methods, probably a detect/dispatch mechanism will be required.
+ *
+ 
**/
+
+static acpi_status
+acpi_ns_custom_package(struct acpi_evaluate_info *info,
+  union acpi_operand_object **elements, u32 count)
+{
+   u32 expected_count;
+   u32 version;
+   acpi_status status = AE_OK;
+
+   ACPI_FUNCTION_NAME(ns_custom_package);
+
+   /* Get version number, must be Integer */
+
+   if ((*elements)->common.type != ACPI_TYPE_INTEGER) {
+   ACPI_WARN_PREDEFINED((AE_INFO, info->full_pathname,
+ info->node_flags,
+ "Return Package has invalid object type 
for version number"));
+   return_ACPI_STATUS(AE_AML_OPERAND_TYPE);
+   }
+
+   version = (u32)(*elements)->integer.value;
+   expected_count = 21;/* Version 1 */
+
+   if (version == 0) {
+   expected_count = 20;/* Version 0 */
+   }
+
+   if (count < expected_count) {
+   ACPI_WARN_PREDEFINED((AE_INFO, info->full_pathname,
+ info->node_flags,
+ "Return Package is too small - found %u 
elements, expected %u",
+ count, expected_count));
+   return_ACPI_STATUS(AE_AML_OPERAND_VALUE);
+   } else if (count > expected_count) {
+   ACPI_DEBUG_PRINT((ACPI_DB_REPAIR,
+ "%s: Return Package is larger than needed - "
+ "found %u, expected %u\n",
+ info->full_pathname, count, expected_count));
+   }
+
+   /* Validate all elements of the returned package */
+
+   status = 

[PATCH 13/15] ACPICA: Hardware: Add access_width/bit_offset support for acpi_hw_write()

[Lv Zheng]

ACPICA commit 48eea5e7993ccb7189bd63cd726e02adafee6057

This patch adds access_width/bit_offset support in acpi_hw_write().
Lv Zheng.

Link: https://github.com/acpica/acpica/commit/48eea5e7
Link: https://bugs.acpica.org/show_bug.cgi?id=1240
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/hwregs.c |  146 +++---
 1 file changed, 137 insertions(+), 9 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 6eee012..0f18dbc 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -311,6 +311,12 @@ acpi_status acpi_hw_read(u32 *value, struct 
acpi_generic_address *reg)
 acpi_status acpi_hw_write(u32 value, struct acpi_generic_address *reg)
 {
u64 address;
+   u8 access_width;
+   u32 bit_width;
+   u8 bit_offset;
+   u64 value64;
+   u32 new_value32, old_value32;
+   u8 index;
acpi_status status;
 
ACPI_FUNCTION_NAME(hw_write);
@@ -322,23 +328,145 @@ acpi_status acpi_hw_write(u32 value, struct 
acpi_generic_address *reg)
return (status);
}
 
+   /* Convert access_width into number of bits based */
+
+   access_width = acpi_hw_get_access_bit_width(reg, 32);
+   bit_width = reg->bit_offset + reg->bit_width;
+   bit_offset = reg->bit_offset;
+
/*
 * Two address spaces supported: Memory or IO. PCI_Config is
 * not supported here because the GAS structure is insufficient
 */
-   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
-   status = acpi_os_write_memory((acpi_physical_address)
- address, (u64)value,
- reg->bit_width);
-   } else {/* ACPI_ADR_SPACE_SYSTEM_IO, validated earlier 
*/
-
-   status = acpi_hw_write_port((acpi_io_address)
-   address, value, reg->bit_width);
+   index = 0;
+   while (bit_width) {
+   /*
+* Use offset style bit reads because "Index * AccessWidth" is
+* ensured to be less than 32-bits by 
acpi_hw_validate_register().
+*/
+   new_value32 = ACPI_GET_BITS(, index * access_width,
+   ACPI_MASK_BITS_ABOVE_32
+   (access_width));
+
+   if (bit_offset >= access_width) {
+   bit_offset -= access_width;
+   } else {
+   /*
+* Use offset style bit masks because access_width is 
ensured
+* to be less than 32-bits by 
acpi_hw_validate_register() and
+* bit_offset/bit_width is less than access_width here.
+*/
+   if (bit_offset) {
+   new_value32 &= ACPI_MASK_BITS_BELOW(bit_offset);
+   }
+   if (bit_width < access_width) {
+   new_value32 &= ACPI_MASK_BITS_ABOVE(bit_width);
+   }
+
+   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+   if (bit_offset || bit_width < access_width) {
+   /*
+* Read old values in order not to 
modify the bits that
+* are beyond the register 
bit_width/bit_offset setting.
+*/
+   status =
+   
acpi_os_read_memory((acpi_physical_address)
+   address +
+   index *
+   ACPI_DIV_8
+   (access_width),
+   ,
+   access_width);
+   old_value32 = (u32)value64;
+
+   /*
+* Use offset style bit masks because 
access_width is
+* ensured to be less than 32-bits by
+* acpi_hw_validate_register() and 
bit_offset/bit_width is
+* less than access_width here.
+*/
+   if (bit_offset) {
+   old_value32 &=
+   ACPI_MASK_BITS_ABOVE
+  

[PATCH 08/15] ACPICA: Dispatcher: Update thread ID for recursive method calls

[Lv Zheng]

From: Prarit Bhargava 

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava 

Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dsmethod.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index ddfec05..47c7b52 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -428,6 +428,9 @@ acpi_ds_begin_method_execution(struct acpi_namespace_node 
*method_node,
obj_desc->method.mutex->mutex.
original_sync_level =
obj_desc->method.mutex->mutex.sync_level;
+
+   obj_desc->method.mutex->mutex.thread_id =
+   acpi_os_get_thread_id();
}
}
 
-- 
1.7.10

[PATCH 10/15] ACPICA: Hardware: Add optimized access bit width support

[Lv Zheng]

ACPICA commit c49a751b4dae7baec1790748a2b4b6e8ab599f51

For Access Size = 0, it actually can use user expected access bit width.
This patch implements this.

Besides of the ACPICA upstream commit, this patch also includes a fix fixing
the issue reported by the FreeBSD community.
The old register descriptors are translated in acpi_tb_init_generic_address()
with access_width being filled with 0. This breaks code in
acpi_hw_get_access_bit_width() when the registers are 16-bit IO ports and their
bit_width fields are filled with 16. The rapid fix is meant to make code
written for acpi_hw_get_access_bit_width() regression safer before the issue is
correctly fixed from acpi_tb_init_generic_address(). Reported by
John Baldwin , fixed by Lv Zheng , tested
by Jung-uk Kim .

Link: https://github.com/acpica/acpica/commit/c49a751b
Reported-by: John Baldwin 
Tested-by Jung-uk Kim .
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/hwregs.c |   49 --
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 035fb52..892e677 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -51,6 +51,10 @@ ACPI_MODULE_NAME("hwregs")
 
 #if (!ACPI_REDUCED_HARDWARE)
 /* Local Prototypes */
+static u8
+acpi_hw_get_access_bit_width(struct acpi_generic_address *reg,
+u8 max_bit_width);
+
 static acpi_status
 acpi_hw_read_multiple(u32 *value,
  struct acpi_generic_address *register_a,
@@ -65,6 +69,48 @@ acpi_hw_write_multiple(u32 value,
 
 /**
  *
+ * FUNCTION:acpi_hw_get_access_bit_width
+ *
+ * PARAMETERS:  reg - GAS register structure
+ *  max_bit_width   - Max bit_width supported (32 or 64)
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Obtain optimal access bit width
+ *
+ 
**/
+
+static u8
+acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 
max_bit_width)
+{
+   u64 address;
+
+   if (!reg->access_width) {
+   /*
+* Detect old register descriptors where only the bit_width 
field
+* makes senses. The target address is copied to handle possible
+* alignment issues.
+*/
+   ACPI_MOVE_64_TO_64(, >address);
+   if (!reg->bit_offset && reg->bit_width &&
+   ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
+   ACPI_IS_ALIGNED(reg->bit_width, 8) &&
+   ACPI_IS_ALIGNED(address, reg->bit_width)) {
+   return (reg->bit_width);
+   } else {
+   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
+   return (32);
+   } else {
+   return (max_bit_width);
+   }
+   }
+   } else {
+   return (1 << (reg->access_width + 2));
+   }
+}
+
+/**
+ *
  * FUNCTION:acpi_hw_validate_register
  *
  * PARAMETERS:  reg - GAS register structure
@@ -122,8 +168,7 @@ acpi_hw_validate_register(struct acpi_generic_address *reg,
 
/* Validate the bit_width, convert access_width into number of bits */
 
-   access_width = reg->access_width ? reg->access_width : 1;
-   access_width = 1 << (access_width + 2);
+   access_width = acpi_hw_get_access_bit_width(reg, max_bit_width);
bit_width =
ACPI_ROUND_UP(reg->bit_offset + reg->bit_width, access_width);
if (max_bit_width < bit_width) {
-- 
1.7.10

[PATCH 07/15] ACPICA: Renamed some #defined flag constants for clarity

[Lv Zheng]

From: Bob Moore 

ACPICA commit 438905b205e64e742f9670a0970419c426264831

Expanded a couple of cryptic names.

Link: https://github.com/acpica/acpica/commit/438905b2
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h |   30 +++---
 drivers/acpi/acpica/psutils.c |2 +-
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 166a67f..13331d7 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -856,24 +856,24 @@ struct acpi_parse_state {
 
 /* Parse object flags */
 
-#define ACPI_PARSEOP_GENERIC0x01
-#define ACPI_PARSEOP_NAMED  0x02
-#define ACPI_PARSEOP_DEFERRED   0x04
-#define ACPI_PARSEOP_BYTELIST   0x08
-#define ACPI_PARSEOP_IN_STACK   0x10
-#define ACPI_PARSEOP_TARGET 0x20
-#define ACPI_PARSEOP_IN_CACHE   0x80
+#define ACPI_PARSEOP_GENERIC0x01
+#define ACPI_PARSEOP_NAMED_OBJECT   0x02
+#define ACPI_PARSEOP_DEFERRED   0x04
+#define ACPI_PARSEOP_BYTELIST   0x08
+#define ACPI_PARSEOP_IN_STACK   0x10
+#define ACPI_PARSEOP_TARGET 0x20
+#define ACPI_PARSEOP_IN_CACHE   0x80
 
 /* Parse object disasm_flags */
 
-#define ACPI_PARSEOP_IGNORE 0x01
-#define ACPI_PARSEOP_PARAMLIST  0x02
-#define ACPI_PARSEOP_EMPTY_TERMLIST 0x04
-#define ACPI_PARSEOP_PREDEF_CHECKED 0x08
-#define ACPI_PARSEOP_CLOSING_PAREN  0x10
-#define ACPI_PARSEOP_COMPOUND   0x20
-#define ACPI_PARSEOP_ASSIGNMENT 0x40
-#define ACPI_PARSEOP_ELSEIF 0x80
+#define ACPI_PARSEOP_IGNORE 0x01
+#define ACPI_PARSEOP_PARAMETER_LIST 0x02
+#define ACPI_PARSEOP_EMPTY_TERMLIST 0x04
+#define ACPI_PARSEOP_PREDEFINED_CHECKED 0x08
+#define ACPI_PARSEOP_CLOSING_PAREN  0x10
+#define ACPI_PARSEOP_COMPOUND_ASSIGNMENT0x20
+#define ACPI_PARSEOP_ASSIGNMENT 0x40
+#define ACPI_PARSEOP_ELSEIF 0x80
 
 /*
  *
diff --git a/drivers/acpi/acpica/psutils.c b/drivers/acpi/acpica/psutils.c
index b28b0da..89cb4bf 100644
--- a/drivers/acpi/acpica/psutils.c
+++ b/drivers/acpi/acpica/psutils.c
@@ -128,7 +128,7 @@ union acpi_parse_object *acpi_ps_alloc_op(u16 opcode, u8 
*aml)
if (op_info->flags & AML_DEFER) {
flags = ACPI_PARSEOP_DEFERRED;
} else if (op_info->flags & AML_NAMED) {
-   flags = ACPI_PARSEOP_NAMED;
+   flags = ACPI_PARSEOP_NAMED_OBJECT;
} else if (opcode == AML_INT_BYTELIST_OP) {
flags = ACPI_PARSEOP_BYTELIST;
}
-- 
1.7.10

[PATCH 14/15] ACPICA: Move all ASCII utilities to a common file

[Lv Zheng]

From: Bob Moore 

ACPICA commit ba60e4500053010bf775d58f6f61febbdb94d817

New file is utascii.c

Link: https://github.com/acpica/acpica/commit/ba60e450
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/Makefile |1 +
 drivers/acpi/acpica/actables.h   |2 -
 drivers/acpi/acpica/acutils.h|   13 ++-
 drivers/acpi/acpica/dbnames.c|2 +-
 drivers/acpi/acpica/exnames.c|2 +-
 drivers/acpi/acpica/tbdata.c |6 +-
 drivers/acpi/acpica/tbfind.c |2 +-
 drivers/acpi/acpica/tbinstal.c   |6 +-
 drivers/acpi/acpica/tbutils.c|   27 --
 drivers/acpi/acpica/utascii.c|  140 ++
 drivers/acpi/acpica/utstring.c   |   69 +--
 tools/power/acpi/tools/acpidump/Makefile |1 +
 tools/power/acpi/tools/acpidump/apdump.c |8 +-
 13 files changed, 168 insertions(+), 111 deletions(-)
 create mode 100644 drivers/acpi/acpica/utascii.c

diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index 188597f..227bb7b 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -150,6 +150,7 @@ acpi-y +=   \
 acpi-y +=  \
utaddress.o \
utalloc.o   \
+   utascii.o   \
utbuffer.o  \
utcopy.o\
utexcep.o   \
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 848ad3a..cd5a135 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -161,8 +161,6 @@ acpi_tb_install_fixed_table(acpi_physical_address address,
 
 acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
 
-u8 acpi_is_valid_signature(char *signature);
-
 /*
  * tbxfload
  */
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 107f9e0..a7dbb2b 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -167,6 +167,15 @@ struct acpi_pkg_info {
 #define DB_QWORD_DISPLAY8
 
 /*
+ * utascii - ASCII utilities
+ */
+u8 acpi_ut_valid_nameseg(char *signature);
+
+u8 acpi_ut_valid_name_char(char character, u32 position);
+
+void acpi_ut_check_and_repair_ascii(u8 *name, char *repaired_name, u32 count);
+
+/*
  * utnonansi - Non-ANSI C library functions
  */
 void acpi_ut_strupr(char *src_string);
@@ -579,10 +588,6 @@ void acpi_ut_print_string(char *string, u16 max_length);
 void ut_convert_backslashes(char *pathname);
 #endif
 
-u8 acpi_ut_valid_acpi_name(char *name);
-
-u8 acpi_ut_valid_acpi_char(char character, u32 position);
-
 void acpi_ut_repair_name(char *name);
 
 #if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
diff --git a/drivers/acpi/acpica/dbnames.c b/drivers/acpi/acpica/dbnames.c
index 4c9e59a..8667f14 100644
--- a/drivers/acpi/acpica/dbnames.c
+++ b/drivers/acpi/acpica/dbnames.c
@@ -709,7 +709,7 @@ acpi_db_integrity_walk(acpi_handle obj_handle,
return (AE_OK);
}
 
-   if (!acpi_ut_valid_acpi_name(node->name.ascii)) {
+   if (!acpi_ut_valid_nameseg(node->name.ascii)) {
acpi_os_printf("Invalid AcpiName for Node %p\n", node);
return (AE_OK);
}
diff --git a/drivers/acpi/acpica/exnames.c b/drivers/acpi/acpica/exnames.c
index 27c11ab..3d6af93 100644
--- a/drivers/acpi/acpica/exnames.c
+++ b/drivers/acpi/acpica/exnames.c
@@ -178,7 +178,7 @@ static acpi_status acpi_ex_name_segment(u8 ** 
in_aml_address, char *name_string)
 
for (index = 0;
 (index < ACPI_NAME_SIZE)
-&& (acpi_ut_valid_acpi_char(*aml_address, 0)); index++) {
+&& (acpi_ut_valid_name_char(*aml_address, 0)); index++) {
char_buf[index] = *aml_address++;
ACPI_DEBUG_PRINT((ACPI_DB_LOAD, "%c\n", char_buf[index]));
}
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index d471df3..1388a19 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -401,9 +401,9 @@ acpi_tb_verify_temp_table(struct acpi_table_desc 
*table_desc, char *signature)
ACPI_EXCEPTION((AE_INFO, AE_NO_MEMORY,
"%4.4s 0x%8.8X%8.8X"
" Attempted table install failed",
-   acpi_ut_valid_acpi_name(table_desc->
-   signature.
-   ascii) ?
+   acpi_ut_valid_nameseg(table_desc->
+ signature.
+ ascii) ?
table_desc->signature.ascii : "",

[PATCH 05/15] ACPICA: ACPI 6.0: Update _BIX support for new package element

[Lv Zheng]

From: Bob Moore 

ACPICA commit 3451e6d49d37919c13ec2c0019a31534b0dfc0c0

One integer was added at the end of the _BIX method, and the
version number was incremented.

Link: https://github.com/acpica/acpica/commit/3451e6d4
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |5 ++-
 drivers/acpi/acpica/nsprepkg.c |   86 
 2 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index 4ca426b..888440b 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -129,7 +129,8 @@ enum acpi_return_package_types {
ACPI_PTYPE2_REV_FIXED = 9,
ACPI_PTYPE2_FIX_VAR = 10,
ACPI_PTYPE2_VAR_VAR = 11,
-   ACPI_PTYPE2_UUID_PAIR = 12
+   ACPI_PTYPE2_UUID_PAIR = 12,
+   ACPI_PTYPE_CUSTOM = 13
 };
 
 /* Support macros for users of the predefined info table */
@@ -340,7 +341,7 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
 
{{"_BIX", METHOD_0ARGS,
  METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (16 Int),(4 
Str) */
-   PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 16,
+   PACKAGE_INFO(ACPI_PTYPE_CUSTOM, ACPI_RTYPE_INTEGER, 16,
 ACPI_RTYPE_STRING, 4, 0),
 
{{"_BLT",
diff --git a/drivers/acpi/acpica/nsprepkg.c b/drivers/acpi/acpica/nsprepkg.c
index fde5a09..fbedc6e 100644
--- a/drivers/acpi/acpica/nsprepkg.c
+++ b/drivers/acpi/acpica/nsprepkg.c
@@ -62,6 +62,10 @@ acpi_ns_check_package_elements(struct acpi_evaluate_info 
*info,
   u32 count1,
   u8 type2, u32 count2, u32 start_index);
 
+static acpi_status
+acpi_ns_custom_package(struct acpi_evaluate_info *info,
+  union acpi_operand_object **elements, u32 count);
+
 
/***
  *
  * FUNCTION:acpi_ns_check_package
@@ -135,6 +139,11 @@ acpi_ns_check_package(struct acpi_evaluate_info *info,
 * PTYPE2 packages contain subpackages
 */
switch (package->ret_info.type) {
+   case ACPI_PTYPE_CUSTOM:
+
+   status = acpi_ns_custom_package(info, elements, count);
+   break;
+
case ACPI_PTYPE1_FIXED:
/*
 * The package count is fixed and there are no subpackages
@@ -626,6 +635,83 @@ package_too_small:
 
 
/***
  *
+ * FUNCTION:acpi_ns_custom_package
+ *
+ * PARAMETERS:  info- Method execution information block
+ *  elements- Pointer to the package elements array
+ *  count   - Element count for the package
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Check a returned package object for the correct count and
+ *  correct type of all sub-objects.
+ *
+ * NOTE: Currently used for the _BIX method only. When needed for two or more
+ * methods, probably a detect/dispatch mechanism will be required.
+ *
+ 
**/
+
+static acpi_status
+acpi_ns_custom_package(struct acpi_evaluate_info *info,
+  union acpi_operand_object **elements, u32 count)
+{
+   u32 expected_count;
+   u32 version;
+   acpi_status status = AE_OK;
+
+   ACPI_FUNCTION_NAME(ns_custom_package);
+
+   /* Get version number, must be Integer */
+
+   if ((*elements)->common.type != ACPI_TYPE_INTEGER) {
+   ACPI_WARN_PREDEFINED((AE_INFO, info->full_pathname,
+ info->node_flags,
+ "Return Package has invalid object type 
for version number"));
+   return_ACPI_STATUS(AE_AML_OPERAND_TYPE);
+   }
+
+   version = (u32)(*elements)->integer.value;
+   expected_count = 21;/* Version 1 */
+
+   if (version == 0) {
+   expected_count = 20;/* Version 0 */
+   }
+
+   if (count < expected_count) {
+   ACPI_WARN_PREDEFINED((AE_INFO, info->full_pathname,
+ info->node_flags,
+ "Return Package is too small - found %u 
elements, expected %u",
+ count, expected_count));
+   return_ACPI_STATUS(AE_AML_OPERAND_VALUE);
+   } else if (count > expected_count) {
+   ACPI_DEBUG_PRINT((ACPI_DB_REPAIR,
+ "%s: Return Package is larger than needed - "
+ "found %u, expected %u\n",
+ info->full_pathname, count, expected_count));
+   }
+
+   /* Validate all elements of the returned package */
+
+   status = acpi_ns_check_package_elements(info, elements,
+ 

[PATCH 13/15] ACPICA: Hardware: Add access_width/bit_offset support for acpi_hw_write()

[Lv Zheng]

ACPICA commit 48eea5e7993ccb7189bd63cd726e02adafee6057

This patch adds access_width/bit_offset support in acpi_hw_write().
Lv Zheng.

Link: https://github.com/acpica/acpica/commit/48eea5e7
Link: https://bugs.acpica.org/show_bug.cgi?id=1240
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/hwregs.c |  146 +++---
 1 file changed, 137 insertions(+), 9 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 6eee012..0f18dbc 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -311,6 +311,12 @@ acpi_status acpi_hw_read(u32 *value, struct 
acpi_generic_address *reg)
 acpi_status acpi_hw_write(u32 value, struct acpi_generic_address *reg)
 {
u64 address;
+   u8 access_width;
+   u32 bit_width;
+   u8 bit_offset;
+   u64 value64;
+   u32 new_value32, old_value32;
+   u8 index;
acpi_status status;
 
ACPI_FUNCTION_NAME(hw_write);
@@ -322,23 +328,145 @@ acpi_status acpi_hw_write(u32 value, struct 
acpi_generic_address *reg)
return (status);
}
 
+   /* Convert access_width into number of bits based */
+
+   access_width = acpi_hw_get_access_bit_width(reg, 32);
+   bit_width = reg->bit_offset + reg->bit_width;
+   bit_offset = reg->bit_offset;
+
/*
 * Two address spaces supported: Memory or IO. PCI_Config is
 * not supported here because the GAS structure is insufficient
 */
-   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
-   status = acpi_os_write_memory((acpi_physical_address)
- address, (u64)value,
- reg->bit_width);
-   } else {/* ACPI_ADR_SPACE_SYSTEM_IO, validated earlier 
*/
-
-   status = acpi_hw_write_port((acpi_io_address)
-   address, value, reg->bit_width);
+   index = 0;
+   while (bit_width) {
+   /*
+* Use offset style bit reads because "Index * AccessWidth" is
+* ensured to be less than 32-bits by 
acpi_hw_validate_register().
+*/
+   new_value32 = ACPI_GET_BITS(, index * access_width,
+   ACPI_MASK_BITS_ABOVE_32
+   (access_width));
+
+   if (bit_offset >= access_width) {
+   bit_offset -= access_width;
+   } else {
+   /*
+* Use offset style bit masks because access_width is 
ensured
+* to be less than 32-bits by 
acpi_hw_validate_register() and
+* bit_offset/bit_width is less than access_width here.
+*/
+   if (bit_offset) {
+   new_value32 &= ACPI_MASK_BITS_BELOW(bit_offset);
+   }
+   if (bit_width < access_width) {
+   new_value32 &= ACPI_MASK_BITS_ABOVE(bit_width);
+   }
+
+   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+   if (bit_offset || bit_width < access_width) {
+   /*
+* Read old values in order not to 
modify the bits that
+* are beyond the register 
bit_width/bit_offset setting.
+*/
+   status =
+   
acpi_os_read_memory((acpi_physical_address)
+   address +
+   index *
+   ACPI_DIV_8
+   (access_width),
+   ,
+   access_width);
+   old_value32 = (u32)value64;
+
+   /*
+* Use offset style bit masks because 
access_width is
+* ensured to be less than 32-bits by
+* acpi_hw_validate_register() and 
bit_offset/bit_width is
+* less than access_width here.
+*/
+   if (bit_offset) {
+   old_value32 &=
+   ACPI_MASK_BITS_ABOVE
+   (bit_offset);
+

[PATCH 08/15] ACPICA: Dispatcher: Update thread ID for recursive method calls

[Lv Zheng]

From: Prarit Bhargava 

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava 

Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dsmethod.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index ddfec05..47c7b52 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -428,6 +428,9 @@ acpi_ds_begin_method_execution(struct acpi_namespace_node 
*method_node,
obj_desc->method.mutex->mutex.
original_sync_level =
obj_desc->method.mutex->mutex.sync_level;
+
+   obj_desc->method.mutex->mutex.thread_id =
+   acpi_os_get_thread_id();
}
}
 
-- 
1.7.10

[PATCH 10/15] ACPICA: Hardware: Add optimized access bit width support

[Lv Zheng]

ACPICA commit c49a751b4dae7baec1790748a2b4b6e8ab599f51

For Access Size = 0, it actually can use user expected access bit width.
This patch implements this.

Besides of the ACPICA upstream commit, this patch also includes a fix fixing
the issue reported by the FreeBSD community.
The old register descriptors are translated in acpi_tb_init_generic_address()
with access_width being filled with 0. This breaks code in
acpi_hw_get_access_bit_width() when the registers are 16-bit IO ports and their
bit_width fields are filled with 16. The rapid fix is meant to make code
written for acpi_hw_get_access_bit_width() regression safer before the issue is
correctly fixed from acpi_tb_init_generic_address(). Reported by
John Baldwin , fixed by Lv Zheng , tested
by Jung-uk Kim .

Link: https://github.com/acpica/acpica/commit/c49a751b
Reported-by: John Baldwin 
Tested-by Jung-uk Kim .
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/hwregs.c |   49 --
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 035fb52..892e677 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -51,6 +51,10 @@ ACPI_MODULE_NAME("hwregs")
 
 #if (!ACPI_REDUCED_HARDWARE)
 /* Local Prototypes */
+static u8
+acpi_hw_get_access_bit_width(struct acpi_generic_address *reg,
+u8 max_bit_width);
+
 static acpi_status
 acpi_hw_read_multiple(u32 *value,
  struct acpi_generic_address *register_a,
@@ -65,6 +69,48 @@ acpi_hw_write_multiple(u32 value,
 
 /**
  *
+ * FUNCTION:acpi_hw_get_access_bit_width
+ *
+ * PARAMETERS:  reg - GAS register structure
+ *  max_bit_width   - Max bit_width supported (32 or 64)
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Obtain optimal access bit width
+ *
+ 
**/
+
+static u8
+acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 
max_bit_width)
+{
+   u64 address;
+
+   if (!reg->access_width) {
+   /*
+* Detect old register descriptors where only the bit_width 
field
+* makes senses. The target address is copied to handle possible
+* alignment issues.
+*/
+   ACPI_MOVE_64_TO_64(, >address);
+   if (!reg->bit_offset && reg->bit_width &&
+   ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
+   ACPI_IS_ALIGNED(reg->bit_width, 8) &&
+   ACPI_IS_ALIGNED(address, reg->bit_width)) {
+   return (reg->bit_width);
+   } else {
+   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
+   return (32);
+   } else {
+   return (max_bit_width);
+   }
+   }
+   } else {
+   return (1 << (reg->access_width + 2));
+   }
+}
+
+/**
+ *
  * FUNCTION:acpi_hw_validate_register
  *
  * PARAMETERS:  reg - GAS register structure
@@ -122,8 +168,7 @@ acpi_hw_validate_register(struct acpi_generic_address *reg,
 
/* Validate the bit_width, convert access_width into number of bits */
 
-   access_width = reg->access_width ? reg->access_width : 1;
-   access_width = 1 << (access_width + 2);
+   access_width = acpi_hw_get_access_bit_width(reg, max_bit_width);
bit_width =
ACPI_ROUND_UP(reg->bit_offset + reg->bit_width, access_width);
if (max_bit_width < bit_width) {
-- 
1.7.10

[PATCH 07/15] ACPICA: Renamed some #defined flag constants for clarity

[Lv Zheng]

From: Bob Moore 

ACPICA commit 438905b205e64e742f9670a0970419c426264831

Expanded a couple of cryptic names.

Link: https://github.com/acpica/acpica/commit/438905b2
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h |   30 +++---
 drivers/acpi/acpica/psutils.c |2 +-
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 166a67f..13331d7 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -856,24 +856,24 @@ struct acpi_parse_state {
 
 /* Parse object flags */
 
-#define ACPI_PARSEOP_GENERIC0x01
-#define ACPI_PARSEOP_NAMED  0x02
-#define ACPI_PARSEOP_DEFERRED   0x04
-#define ACPI_PARSEOP_BYTELIST   0x08
-#define ACPI_PARSEOP_IN_STACK   0x10
-#define ACPI_PARSEOP_TARGET 0x20
-#define ACPI_PARSEOP_IN_CACHE   0x80
+#define ACPI_PARSEOP_GENERIC0x01
+#define ACPI_PARSEOP_NAMED_OBJECT   0x02
+#define ACPI_PARSEOP_DEFERRED   0x04
+#define ACPI_PARSEOP_BYTELIST   0x08
+#define ACPI_PARSEOP_IN_STACK   0x10
+#define ACPI_PARSEOP_TARGET 0x20
+#define ACPI_PARSEOP_IN_CACHE   0x80
 
 /* Parse object disasm_flags */
 
-#define ACPI_PARSEOP_IGNORE 0x01
-#define ACPI_PARSEOP_PARAMLIST  0x02
-#define ACPI_PARSEOP_EMPTY_TERMLIST 0x04
-#define ACPI_PARSEOP_PREDEF_CHECKED 0x08
-#define ACPI_PARSEOP_CLOSING_PAREN  0x10
-#define ACPI_PARSEOP_COMPOUND   0x20
-#define ACPI_PARSEOP_ASSIGNMENT 0x40
-#define ACPI_PARSEOP_ELSEIF 0x80
+#define ACPI_PARSEOP_IGNORE 0x01
+#define ACPI_PARSEOP_PARAMETER_LIST 0x02
+#define ACPI_PARSEOP_EMPTY_TERMLIST 0x04
+#define ACPI_PARSEOP_PREDEFINED_CHECKED 0x08
+#define ACPI_PARSEOP_CLOSING_PAREN  0x10
+#define ACPI_PARSEOP_COMPOUND_ASSIGNMENT0x20
+#define ACPI_PARSEOP_ASSIGNMENT 0x40
+#define ACPI_PARSEOP_ELSEIF 0x80
 
 /*
  *
diff --git a/drivers/acpi/acpica/psutils.c b/drivers/acpi/acpica/psutils.c
index b28b0da..89cb4bf 100644
--- a/drivers/acpi/acpica/psutils.c
+++ b/drivers/acpi/acpica/psutils.c
@@ -128,7 +128,7 @@ union acpi_parse_object *acpi_ps_alloc_op(u16 opcode, u8 
*aml)
if (op_info->flags & AML_DEFER) {
flags = ACPI_PARSEOP_DEFERRED;
} else if (op_info->flags & AML_NAMED) {
-   flags = ACPI_PARSEOP_NAMED;
+   flags = ACPI_PARSEOP_NAMED_OBJECT;
} else if (opcode == AML_INT_BYTELIST_OP) {
flags = ACPI_PARSEOP_BYTELIST;
}
-- 
1.7.10

[PATCH 14/15] ACPICA: Move all ASCII utilities to a common file

[Lv Zheng]

From: Bob Moore 

ACPICA commit ba60e4500053010bf775d58f6f61febbdb94d817

New file is utascii.c

Link: https://github.com/acpica/acpica/commit/ba60e450
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/Makefile |1 +
 drivers/acpi/acpica/actables.h   |2 -
 drivers/acpi/acpica/acutils.h|   13 ++-
 drivers/acpi/acpica/dbnames.c|2 +-
 drivers/acpi/acpica/exnames.c|2 +-
 drivers/acpi/acpica/tbdata.c |6 +-
 drivers/acpi/acpica/tbfind.c |2 +-
 drivers/acpi/acpica/tbinstal.c   |6 +-
 drivers/acpi/acpica/tbutils.c|   27 --
 drivers/acpi/acpica/utascii.c|  140 ++
 drivers/acpi/acpica/utstring.c   |   69 +--
 tools/power/acpi/tools/acpidump/Makefile |1 +
 tools/power/acpi/tools/acpidump/apdump.c |8 +-
 13 files changed, 168 insertions(+), 111 deletions(-)
 create mode 100644 drivers/acpi/acpica/utascii.c

diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index 188597f..227bb7b 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -150,6 +150,7 @@ acpi-y +=   \
 acpi-y +=  \
utaddress.o \
utalloc.o   \
+   utascii.o   \
utbuffer.o  \
utcopy.o\
utexcep.o   \
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 848ad3a..cd5a135 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -161,8 +161,6 @@ acpi_tb_install_fixed_table(acpi_physical_address address,
 
 acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
 
-u8 acpi_is_valid_signature(char *signature);
-
 /*
  * tbxfload
  */
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 107f9e0..a7dbb2b 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -167,6 +167,15 @@ struct acpi_pkg_info {
 #define DB_QWORD_DISPLAY8
 
 /*
+ * utascii - ASCII utilities
+ */
+u8 acpi_ut_valid_nameseg(char *signature);
+
+u8 acpi_ut_valid_name_char(char character, u32 position);
+
+void acpi_ut_check_and_repair_ascii(u8 *name, char *repaired_name, u32 count);
+
+/*
  * utnonansi - Non-ANSI C library functions
  */
 void acpi_ut_strupr(char *src_string);
@@ -579,10 +588,6 @@ void acpi_ut_print_string(char *string, u16 max_length);
 void ut_convert_backslashes(char *pathname);
 #endif
 
-u8 acpi_ut_valid_acpi_name(char *name);
-
-u8 acpi_ut_valid_acpi_char(char character, u32 position);
-
 void acpi_ut_repair_name(char *name);
 
 #if defined (ACPI_DEBUGGER) || defined (ACPI_APPLICATION)
diff --git a/drivers/acpi/acpica/dbnames.c b/drivers/acpi/acpica/dbnames.c
index 4c9e59a..8667f14 100644
--- a/drivers/acpi/acpica/dbnames.c
+++ b/drivers/acpi/acpica/dbnames.c
@@ -709,7 +709,7 @@ acpi_db_integrity_walk(acpi_handle obj_handle,
return (AE_OK);
}
 
-   if (!acpi_ut_valid_acpi_name(node->name.ascii)) {
+   if (!acpi_ut_valid_nameseg(node->name.ascii)) {
acpi_os_printf("Invalid AcpiName for Node %p\n", node);
return (AE_OK);
}
diff --git a/drivers/acpi/acpica/exnames.c b/drivers/acpi/acpica/exnames.c
index 27c11ab..3d6af93 100644
--- a/drivers/acpi/acpica/exnames.c
+++ b/drivers/acpi/acpica/exnames.c
@@ -178,7 +178,7 @@ static acpi_status acpi_ex_name_segment(u8 ** 
in_aml_address, char *name_string)
 
for (index = 0;
 (index < ACPI_NAME_SIZE)
-&& (acpi_ut_valid_acpi_char(*aml_address, 0)); index++) {
+&& (acpi_ut_valid_name_char(*aml_address, 0)); index++) {
char_buf[index] = *aml_address++;
ACPI_DEBUG_PRINT((ACPI_DB_LOAD, "%c\n", char_buf[index]));
}
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index d471df3..1388a19 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -401,9 +401,9 @@ acpi_tb_verify_temp_table(struct acpi_table_desc 
*table_desc, char *signature)
ACPI_EXCEPTION((AE_INFO, AE_NO_MEMORY,
"%4.4s 0x%8.8X%8.8X"
" Attempted table install failed",
-   acpi_ut_valid_acpi_name(table_desc->
-   signature.
-   ascii) ?
+   acpi_ut_valid_nameseg(table_desc->
+ signature.
+ ascii) ?
table_desc->signature.ascii : "",
ACPI_FORMAT_UINT64(table_desc->
 

[PATCH 04/15] ACPICA: ACPI 6.1: Support for new PCCT subtable

[Lv Zheng]

From: Bob Moore 

ACPICA commit de3ea7c322b9b6bdb09aa90c2e1d420cd4dce47c

Additional subspace structure was added.

Link: https://github.com/acpica/acpica/commit/de3ea7c3
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actbl3.h |   23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
index f12f4bb..ebc1f4f 100644
--- a/include/acpi/actbl3.h
+++ b/include/acpi/actbl3.h
@@ -481,7 +481,8 @@ struct acpi_table_pcct {
 enum acpi_pcct_type {
ACPI_PCCT_TYPE_GENERIC_SUBSPACE = 0,
ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE = 1,
-   ACPI_PCCT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
+   ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2 = 2,   /* ACPI 6.1 */
+   ACPI_PCCT_TYPE_RESERVED = 3 /* 3 and greater are reserved */
 };
 
 /*
@@ -520,6 +521,26 @@ struct acpi_pcct_hw_reduced {
u16 min_turnaround_time;
 };
 
+/* 2: HW-reduced Communications Subspace Type 2 (ACPI 6.1) */
+
+struct acpi_pcct_hw_reduced_type2 {
+   struct acpi_subtable_header header;
+   u32 doorbell_interrupt;
+   u8 flags;
+   u8 reserved;
+   u64 base_address;
+   u64 length;
+   struct acpi_generic_address doorbell_register;
+   u64 preserve_mask;
+   u64 write_mask;
+   u32 latency;
+   u32 max_access_rate;
+   u16 min_turnaround_time;
+   struct acpi_generic_address doorbell_ack_register;
+   u64 ack_preserve_mask;
+   u64 ack_write_mask;
+};
+
 /* Values for doorbell flags above */
 
 #define ACPI_PCCT_INTERRUPT_POLARITY(1)
-- 
1.7.10

[PATCH 09/15] ACPICA: Utilities: Add ACPI_IS_ALIGNED() macro

[Lv Zheng]

This patch introduces ACPI_IS_ALIGNED() macro. Lv Zheng.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acmacros.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h
index 73f6653..ecbaaba 100644
--- a/drivers/acpi/acpica/acmacros.h
+++ b/drivers/acpi/acpica/acmacros.h
@@ -262,7 +262,8 @@
 
 /* Generic (power-of-two) rounding */
 
-#define ACPI_IS_POWER_OF_TWO(a) (((a) & ((a) - 1)) == 0)
+#define ACPI_IS_ALIGNED(a, s)   (((a) & ((s) - 1)) == 0)
+#define ACPI_IS_POWER_OF_TWO(a) ACPI_IS_ALIGNED(a, a)
 
 /*
  * Bitmask creation
-- 
1.7.10

[PATCH 11/15] ACPICA: Executer: Introduce a set of macros to handle bit width mask generation

[Lv Zheng]

ACPICA commit c23034a3a09d5ed79f1827d51f43cfbccf68ab64

A regression was reported to the shift offset >= width of type.
This patch fixes this issue. BZ 1270.
This is a part of the fix because the order of the patches are modified for
Linux upstream, containing the cleanups for the old code. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/c23034a3
Link: https://bugs.acpica.org/show_bug.cgi?id=1270
Reported-by: Sascha Wildner 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acmacros.h |   12 
 drivers/acpi/acpica/exfldio.c  |   12 ++--
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h
index ecbaaba..a3b9543 100644
--- a/drivers/acpi/acpica/acmacros.h
+++ b/drivers/acpi/acpica/acmacros.h
@@ -270,9 +270,21 @@
  * Bit positions start at zero.
  * MASK_BITS_ABOVE creates a mask starting AT the position and above
  * MASK_BITS_BELOW creates a mask starting one bit BELOW the position
+ * MASK_BITS_ABOVE/BELOW accpets a bit offset to create a mask
+ * MASK_BITS_ABOVE/BELOW_32/64 accpets a bit width to create a mask
+ * Note: The ACPI_INTEGER_BIT_SIZE check is used to bypass compiler
+ * differences with the shift operator
  */
 #define ACPI_MASK_BITS_ABOVE(position)  (~((ACPI_UINT64_MAX) << ((u32) 
(position
 #define ACPI_MASK_BITS_BELOW(position)  ((ACPI_UINT64_MAX) << ((u32) 
(position)))
+#define ACPI_MASK_BITS_ABOVE_32(width)  ((u32) ACPI_MASK_BITS_ABOVE(width))
+#define ACPI_MASK_BITS_BELOW_32(width)  ((u32) ACPI_MASK_BITS_BELOW(width))
+#define ACPI_MASK_BITS_ABOVE_64(width)  ((width) == ACPI_INTEGER_BIT_SIZE 
? \
+   
ACPI_UINT64_MAX : \
+   
ACPI_MASK_BITS_ABOVE(width))
+#define ACPI_MASK_BITS_BELOW_64(width)  ((width) == ACPI_INTEGER_BIT_SIZE 
? \
+   
(u64) 0 : \
+   
ACPI_MASK_BITS_BELOW(width))
 
 /* Bitfields within ACPI registers */
 
diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index 72f9176..ee76d29 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -897,17 +897,9 @@ acpi_ex_insert_into_field(union acpi_operand_object 
*obj_desc,
 
access_bit_width = ACPI_MUL_8(obj_desc->common_field.access_byte_width);
 
-   /*
-* Create the bitmasks used for bit insertion.
-* Note: This if/else is used to bypass compiler differences with the
-* shift operator
-*/
-   if (access_bit_width == ACPI_INTEGER_BIT_SIZE) {
-   width_mask = ACPI_UINT64_MAX;
-   } else {
-   width_mask = ACPI_MASK_BITS_ABOVE(access_bit_width);
-   }
+   /* Create the bitmasks used for bit insertion */
 
+   width_mask = ACPI_MASK_BITS_ABOVE_64(access_bit_width);
mask = width_mask &
ACPI_MASK_BITS_BELOW(obj_desc->common_field.start_field_bit_offset);
 
-- 
1.7.10

[PATCH 04/15] ACPICA: ACPI 6.1: Support for new PCCT subtable

[Lv Zheng]

From: Bob Moore 

ACPICA commit de3ea7c322b9b6bdb09aa90c2e1d420cd4dce47c

Additional subspace structure was added.

Link: https://github.com/acpica/acpica/commit/de3ea7c3
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actbl3.h |   23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
index f12f4bb..ebc1f4f 100644
--- a/include/acpi/actbl3.h
+++ b/include/acpi/actbl3.h
@@ -481,7 +481,8 @@ struct acpi_table_pcct {
 enum acpi_pcct_type {
ACPI_PCCT_TYPE_GENERIC_SUBSPACE = 0,
ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE = 1,
-   ACPI_PCCT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
+   ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2 = 2,   /* ACPI 6.1 */
+   ACPI_PCCT_TYPE_RESERVED = 3 /* 3 and greater are reserved */
 };
 
 /*
@@ -520,6 +521,26 @@ struct acpi_pcct_hw_reduced {
u16 min_turnaround_time;
 };
 
+/* 2: HW-reduced Communications Subspace Type 2 (ACPI 6.1) */
+
+struct acpi_pcct_hw_reduced_type2 {
+   struct acpi_subtable_header header;
+   u32 doorbell_interrupt;
+   u8 flags;
+   u8 reserved;
+   u64 base_address;
+   u64 length;
+   struct acpi_generic_address doorbell_register;
+   u64 preserve_mask;
+   u64 write_mask;
+   u32 latency;
+   u32 max_access_rate;
+   u16 min_turnaround_time;
+   struct acpi_generic_address doorbell_ack_register;
+   u64 ack_preserve_mask;
+   u64 ack_write_mask;
+};
+
 /* Values for doorbell flags above */
 
 #define ACPI_PCCT_INTERRUPT_POLARITY(1)
-- 
1.7.10

[PATCH 09/15] ACPICA: Utilities: Add ACPI_IS_ALIGNED() macro

[Lv Zheng]

This patch introduces ACPI_IS_ALIGNED() macro. Lv Zheng.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acmacros.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h
index 73f6653..ecbaaba 100644
--- a/drivers/acpi/acpica/acmacros.h
+++ b/drivers/acpi/acpica/acmacros.h
@@ -262,7 +262,8 @@
 
 /* Generic (power-of-two) rounding */
 
-#define ACPI_IS_POWER_OF_TWO(a) (((a) & ((a) - 1)) == 0)
+#define ACPI_IS_ALIGNED(a, s)   (((a) & ((s) - 1)) == 0)
+#define ACPI_IS_POWER_OF_TWO(a) ACPI_IS_ALIGNED(a, a)
 
 /*
  * Bitmask creation
-- 
1.7.10

[PATCH 11/15] ACPICA: Executer: Introduce a set of macros to handle bit width mask generation

[Lv Zheng]

ACPICA commit c23034a3a09d5ed79f1827d51f43cfbccf68ab64

A regression was reported to the shift offset >= width of type.
This patch fixes this issue. BZ 1270.
This is a part of the fix because the order of the patches are modified for
Linux upstream, containing the cleanups for the old code. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/c23034a3
Link: https://bugs.acpica.org/show_bug.cgi?id=1270
Reported-by: Sascha Wildner 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acmacros.h |   12 
 drivers/acpi/acpica/exfldio.c  |   12 ++--
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h
index ecbaaba..a3b9543 100644
--- a/drivers/acpi/acpica/acmacros.h
+++ b/drivers/acpi/acpica/acmacros.h
@@ -270,9 +270,21 @@
  * Bit positions start at zero.
  * MASK_BITS_ABOVE creates a mask starting AT the position and above
  * MASK_BITS_BELOW creates a mask starting one bit BELOW the position
+ * MASK_BITS_ABOVE/BELOW accpets a bit offset to create a mask
+ * MASK_BITS_ABOVE/BELOW_32/64 accpets a bit width to create a mask
+ * Note: The ACPI_INTEGER_BIT_SIZE check is used to bypass compiler
+ * differences with the shift operator
  */
 #define ACPI_MASK_BITS_ABOVE(position)  (~((ACPI_UINT64_MAX) << ((u32) 
(position
 #define ACPI_MASK_BITS_BELOW(position)  ((ACPI_UINT64_MAX) << ((u32) 
(position)))
+#define ACPI_MASK_BITS_ABOVE_32(width)  ((u32) ACPI_MASK_BITS_ABOVE(width))
+#define ACPI_MASK_BITS_BELOW_32(width)  ((u32) ACPI_MASK_BITS_BELOW(width))
+#define ACPI_MASK_BITS_ABOVE_64(width)  ((width) == ACPI_INTEGER_BIT_SIZE 
? \
+   
ACPI_UINT64_MAX : \
+   
ACPI_MASK_BITS_ABOVE(width))
+#define ACPI_MASK_BITS_BELOW_64(width)  ((width) == ACPI_INTEGER_BIT_SIZE 
? \
+   
(u64) 0 : \
+   
ACPI_MASK_BITS_BELOW(width))
 
 /* Bitfields within ACPI registers */
 
diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index 72f9176..ee76d29 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -897,17 +897,9 @@ acpi_ex_insert_into_field(union acpi_operand_object 
*obj_desc,
 
access_bit_width = ACPI_MUL_8(obj_desc->common_field.access_byte_width);
 
-   /*
-* Create the bitmasks used for bit insertion.
-* Note: This if/else is used to bypass compiler differences with the
-* shift operator
-*/
-   if (access_bit_width == ACPI_INTEGER_BIT_SIZE) {
-   width_mask = ACPI_UINT64_MAX;
-   } else {
-   width_mask = ACPI_MASK_BITS_ABOVE(access_bit_width);
-   }
+   /* Create the bitmasks used for bit insertion */
 
+   width_mask = ACPI_MASK_BITS_ABOVE_64(access_bit_width);
mask = width_mask &
ACPI_MASK_BITS_BELOW(obj_desc->common_field.start_field_bit_offset);
 
-- 
1.7.10

[PATCH 03/15] ACPICA: Refactor evaluate_object to reduce nesting

[Lv Zheng]

From: Bob Moore 

ACPICA commit 599e9159f53565e4a3f3e67f6a03f81fcb10a4cf

Original patch from hanjun@linaro.org
ACPICA BZ 1072.

Link: https://github.com/acpica/acpica/commit/599e9159
Link: https://bugs.acpica.org/show_bug.cgi?id=1072
Original-by: Hanjun Guo 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/nsxfeval.c |  111 
 1 file changed, 55 insertions(+), 56 deletions(-)

diff --git a/drivers/acpi/acpica/nsxfeval.c b/drivers/acpi/acpica/nsxfeval.c
index 614e4ba..d2a9b4f 100644
--- a/drivers/acpi/acpica/nsxfeval.c
+++ b/drivers/acpi/acpica/nsxfeval.c
@@ -280,13 +280,12 @@ acpi_evaluate_object(acpi_handle handle,
info->parameters[info->param_count] = NULL;
}
 
-#if 0
+#ifdef _FUTURE_FEATURE
 
/*
 * Begin incoming argument count analysis. Check for too few args
 * and too many args.
 */
-
switch (acpi_ns_get_type(info->node)) {
case ACPI_TYPE_METHOD:
 
@@ -370,68 +369,68 @@ acpi_evaluate_object(acpi_handle handle,
 * If we are expecting a return value, and all went well above,
 * copy the return value to an external object.
 */
-   if (return_buffer) {
-   if (!info->return_object) {
-   return_buffer->length = 0;
-   } else {
-   if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
-   ACPI_DESC_TYPE_NAMED) {
-   /*
-* If we received a NS Node as a return object, 
this means that
-* the object we are evaluating has nothing 
interesting to
-* return (such as a mutex, etc.)  We return an 
error because
-* these types are essentially unsupported by 
this interface.
-* We don't check up front because this makes 
it easier to add
-* support for various types at a later date if 
necessary.
-*/
-   status = AE_TYPE;
-   info->return_object = NULL; /* No need to 
delete a NS Node */
-   return_buffer->length = 0;
-   }
+   if (!return_buffer) {
+   goto cleanup_return_object;
+   }
 
-   if (ACPI_SUCCESS(status)) {
+   if (!info->return_object) {
+   return_buffer->length = 0;
+   goto cleanup;
+   }
 
-   /* Dereference Index and ref_of references */
+   if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
+   ACPI_DESC_TYPE_NAMED) {
+   /*
+* If we received a NS Node as a return object, this means that
+* the object we are evaluating has nothing interesting to
+* return (such as a mutex, etc.)  We return an error because
+* these types are essentially unsupported by this interface.
+* We don't check up front because this makes it easier to add
+* support for various types at a later date if necessary.
+*/
+   status = AE_TYPE;
+   info->return_object = NULL; /* No need to delete a NS Node 
*/
+   return_buffer->length = 0;
+   }
 
-   acpi_ns_resolve_references(info);
+   if (ACPI_FAILURE(status)) {
+   goto cleanup_return_object;
+   }
 
-   /* Get the size of the returned object */
+   /* Dereference Index and ref_of references */
 
-   status =
-   acpi_ut_get_object_size(info->return_object,
-   
_space_needed);
-   if (ACPI_SUCCESS(status)) {
-
-   /* Validate/Allocate/Clear caller 
buffer */
-
-   status =
-   acpi_ut_initialize_buffer
-   (return_buffer,
-buffer_space_needed);
-   if (ACPI_FAILURE(status)) {
-   /*
-* Caller's buffer is too small 
or a new one can't
-* be allocated
-*/
-   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Needed 
buffer size %X, %s\n",
-   

[PATCH 00/15] ACPICA: 20160422 Release

[Lv Zheng]

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

NOTE:
1. Indentation improvement
The [PATCH 02] is a result of an ACPICA release process fix. It requires
much of human intervention, and many linuxized patches in my hand that are
not upstreamed to the ACPICA are burnt by this commit, which takes weeks or
months to recover. So hope we can do it only once. The [PATCH 01] can
reduce the painful manual work when we have to re-do it.
2. AcessWidth/BitOffset support
The old way of hardware access code has been working for many years. The
commits in this release cycle enables AccessWidth/BitOffset support. Though
the commits of AccessWidth/BitOffset support are written in the regression
safer way, it may still break users because of unknown cases. But we need
to have it in the upstream so that it can be used by as many as possible
users in order to obtain the feedback to reveal the unknown cases.

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 (20160318 Release):
  494 lines
After applying (20160422 Release):
  485 lines
The reduction is caused by recently merged module level improvement.

Bob Moore (7):
  ACPICA: Refactor evaluate_object to reduce nesting
  ACPICA: ACPI 6.1: Support for new PCCT subtable
  ACPICA: ACPI 6.0: Update _BIX support for new package element
  ACPICA: ACPI 6.0, tools/iasl: Add support for new resource
descriptors
  ACPICA: Renamed some #defined flag constants for clarity
  ACPICA: Move all ASCII utilities to a common file
  ACPICA: Update version to 20160422

Lv Zheng (7):
  ACPICA: Linuxize: reduce divergences for 20160422 release
  ACPICA: Divergence: remove unwanted spaces for typedef
  ACPICA: Utilities: Add ACPI_IS_ALIGNED() macro
  ACPICA: Hardware: Add optimized access bit width support
  ACPICA: Executer: Introduce a set of macros to handle bit width mask
generation
  ACPICA: Hardware: Add access_width/bit_offset support in
acpi_hw_read()
  ACPICA: Hardware: Add access_width/bit_offset support for
acpi_hw_write()

Prarit Bhargava (1):
  ACPICA: Dispatcher: Update thread ID for recursive method calls

 drivers/acpi/acpica/Makefile   |1 +
 drivers/acpi/acpica/acdebug.h  |6 +-
 drivers/acpi/acpica/acevents.h |1 +
 drivers/acpi/acpica/acinterp.h |2 +-
 drivers/acpi/acpica/aclocal.h  |   61 ++---
 drivers/acpi/acpica/acmacros.h |   15 +-
 drivers/acpi/acpica/acpredef.h |5 +-
 drivers/acpi/acpica/acresrc.h  |8 +-
 drivers/acpi/acpica/actables.h |2 -
 drivers/acpi/acpica/acutils.h  |   35 +--
 drivers/acpi/acpica/dbcmds.c   |4 +-
 drivers/acpi/acpica/dbconvert.c|4 +-
 drivers/acpi/acpica/dbexec.c   |2 +-
 drivers/acpi/acpica/dbinput.c  |6 +-
 drivers/acpi/acpica/dbnames.c  |4 +-
 drivers/acpi/acpica/dbxface.c  |4 +-
 drivers/acpi/acpica/dscontrol.c|4 +-
 drivers/acpi/acpica/dsinit.c   |2 +-
 drivers/acpi/acpica/dsmethod.c |5 +-
 drivers/acpi/acpica/dsutils.c  |2 +-
 drivers/acpi/acpica/dswload.c  |4 +-
 drivers/acpi/acpica/dswload2.c |4 +-
 drivers/acpi/acpica/dswstate.c |   10 +-
 drivers/acpi/acpica/evgpe.c|4 +-
 drivers/acpi/acpica/evgpeblk.c |4 +-
 drivers/acpi/acpica/evgpeutil.c|4 +-
 drivers/acpi/acpica/evhandler.c|2 +-
 drivers/acpi/acpica/evmisc.c   |3 +-
 drivers/acpi/acpica/evrgnini.c |2 +-
 drivers/acpi/acpica/evxfgpe.c  |2 +-
 

[PATCH 02/15] ACPICA: Divergence: remove unwanted spaces for typedef

[Lv Zheng]

ACPICA commit b2294cae776f5a66a7697414b21949d307e6856f

This patch removes unwanted spaces for typedef. This solution doesn't cover
function types.

Note that the linuxize result of this commit is very giant and should have
many conflicts against the current Linux upstream. Thus it is required to
modify the linuxize result of this commit and the commits around it
manually in order to have them merged to the Linux upstream. Since this is
very costy, we should do this only once, and if we can't ensure to do this
only once, we need to revert the Linux code to the wrong indentation result
before merging the linuxize result of this commit. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/b2294cae
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acdebug.h  |6 +-
 drivers/acpi/acpica/acevents.h |1 +
 drivers/acpi/acpica/acinterp.h |2 +-
 drivers/acpi/acpica/aclocal.h  |   31 +++
 drivers/acpi/acpica/acresrc.h  |6 +-
 drivers/acpi/acpica/actables.h |2 +-
 drivers/acpi/acpica/acutils.h  |   22 ++---
 drivers/acpi/acpica/dbcmds.c   |4 +-
 drivers/acpi/acpica/dbconvert.c|4 +-
 drivers/acpi/acpica/dbexec.c   |2 +-
 drivers/acpi/acpica/dbinput.c  |6 +-
 drivers/acpi/acpica/dbnames.c  |2 +-
 drivers/acpi/acpica/dbxface.c  |4 +-
 drivers/acpi/acpica/dscontrol.c|4 +-
 drivers/acpi/acpica/dsfield.c  |4 +-
 drivers/acpi/acpica/dsinit.c   |2 +-
 drivers/acpi/acpica/dsmethod.c |2 +-
 drivers/acpi/acpica/dsutils.c  |2 +-
 drivers/acpi/acpica/dswload.c  |4 +-
 drivers/acpi/acpica/dswload2.c |4 +-
 drivers/acpi/acpica/dswstate.c |8 +-
 drivers/acpi/acpica/evgpe.c|4 +-
 drivers/acpi/acpica/evgpeblk.c |4 +-
 drivers/acpi/acpica/evgpeutil.c|4 +-
 drivers/acpi/acpica/evhandler.c|2 +-
 drivers/acpi/acpica/evmisc.c   |3 +-
 drivers/acpi/acpica/evrgnini.c |2 +-
 drivers/acpi/acpica/evxfgpe.c  |2 +-
 drivers/acpi/acpica/exconcat.c |4 +-
 drivers/acpi/acpica/exconfig.c |2 +-
 drivers/acpi/acpica/exconvrt.c |4 +-
 drivers/acpi/acpica/excreate.c |2 +-
 drivers/acpi/acpica/exfield.c  |4 +-
 drivers/acpi/acpica/exfldio.c  |2 +-
 drivers/acpi/acpica/exoparg3.c |8 +-
 drivers/acpi/acpica/exoparg6.c |2 +-
 drivers/acpi/acpica/exregion.c |4 +-
 drivers/acpi/acpica/exresnte.c |4 +-
 drivers/acpi/acpica/exresolv.c |2 +-
 drivers/acpi/acpica/exresop.c  |2 +-
 drivers/acpi/acpica/exstorob.c |4 +-
 drivers/acpi/acpica/hwgpe.c|   16 ++--
 drivers/acpi/acpica/hwregs.c   |4 +-
 drivers/acpi/acpica/hwxface.c  |9 +-
 drivers/acpi/acpica/nsconvert.c|6 +-
 drivers/acpi/acpica/nsnames.c  |2 +-
 drivers/acpi/acpica/nsobject.c |4 +-
 drivers/acpi/acpica/nspredef.c |2 +-
 drivers/acpi/acpica/nsrepair.c |2 +-
 drivers/acpi/acpica/nsrepair2.c|6 +-
 drivers/acpi/acpica/nsutils.c  |8 +-
 drivers/acpi/acpica/nsxfeval.c |2 +-
 drivers/acpi/acpica/nsxfname.c |8 +-
 drivers/acpi/acpica/nsxfobj.c  |6 +-
 drivers/acpi/acpica/psargs.c   |2 +-
 drivers/acpi/acpica/psparse.c  |4 +-
 drivers/acpi/acpica/psxface.c  |2 +-
 drivers/acpi/acpica/rscalc.c   |   88 ++--
 drivers/acpi/acpica/rscreate.c |2 +-
 drivers/acpi/acpica/rsmisc.c   |2 +-
 drivers/acpi/acpica/rsutils.c  |   12 +--
 drivers/acpi/acpica/rsxface.c  |6 +-
 drivers/acpi/acpica/tbdata.c   |9 +-
 drivers/acpi/acpica/tbfadt.c   |2 +-
 drivers/acpi/acpica/tbutils.c  |6 +-
 drivers/acpi/acpica/tbxface.c  |8 +-
 drivers/acpi/acpica/tbxfroot.c |8 +-
 

[PATCH 01/15] ACPICA: Linuxize: reduce divergences for 20160422 release

[Lv Zheng]

The patch reduces source code differences between the Linux kernel and the
ACPICA upstream so that the linuxized ACPICA 20160422 release can be
applied with reduced human intervention.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h  |2 +-
 drivers/acpi/acpica/acresrc.h  |2 +-
 drivers/acpi/acpica/actables.h |2 +-
 drivers/acpi/acpica/dsfield.c  |4 ++--
 drivers/acpi/acpica/dswstate.c |2 +-
 drivers/acpi/acpica/exconfig.c |2 +-
 drivers/acpi/acpica/exregion.c |2 +-
 drivers/acpi/acpica/exresop.c  |2 +-
 drivers/acpi/acpica/hwgpe.c|   10 +-
 drivers/acpi/acpica/hwregs.c   |4 ++--
 drivers/acpi/acpica/hwxface.c  |2 +-
 drivers/acpi/acpica/nspredef.c |2 +-
 drivers/acpi/acpica/nsxfname.c |2 +-
 drivers/acpi/acpica/rscalc.c   |2 +-
 drivers/acpi/acpica/tbxface.c  |2 +-
 drivers/acpi/acpica/utcopy.c   |8 
 drivers/acpi/acpica/utlock.c   |4 ++--
 drivers/acpi/acpica/utmath.c   |4 ++--
 include/acpi/acpiosxf.h|2 +-
 19 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 083b16a..379797e 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -541,7 +541,7 @@ struct acpi_gpe_device_info {
 
 typedef acpi_status(*acpi_gpe_callback) (struct acpi_gpe_xrupt_info *
 gpe_xrupt_info,
-struct acpi_gpe_block_info *gpe_block,
+struct acpi_gpe_block_info * gpe_block,
 void *context);
 
 /* Information about each particular fixed event */
diff --git a/drivers/acpi/acpica/acresrc.h b/drivers/acpi/acpica/acresrc.h
index 83e9a29..baacde8 100644
--- a/drivers/acpi/acpica/acresrc.h
+++ b/drivers/acpi/acpica/acresrc.h
@@ -223,7 +223,7 @@ acpi_rs_get_aei_method_data(struct acpi_namespace_node 
*node,
  * rscalc
  */
 acpi_status
-acpi_rs_get_list_length(u8 * aml_buffer,
+acpi_rs_get_list_length(u8 *aml_buffer,
u32 aml_buffer_length, acpi_size * size_needed);
 
 acpi_status
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 848ad3a..fa81099 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -131,7 +131,7 @@ acpi_status acpi_tb_allocate_owner_id(u32 table_index);
 
 acpi_status acpi_tb_release_owner_id(u32 table_index);
 
-acpi_status acpi_tb_get_owner_id(u32 table_index, acpi_owner_id *owner_id);
+acpi_status acpi_tb_get_owner_id(u32 table_index, acpi_owner_id * owner_id);
 
 /*
  * tbutils - table manager utilities
diff --git a/drivers/acpi/acpica/dsfield.c b/drivers/acpi/acpica/dsfield.c
index 6a4b603..0cd777f 100644
--- a/drivers/acpi/acpica/dsfield.c
+++ b/drivers/acpi/acpica/dsfield.c
@@ -147,8 +147,8 @@ acpi_ds_create_external_region(acpi_status lookup_status,
  
**/
 
 acpi_status
-acpi_ds_create_buffer_field(union acpi_parse_object *op,
-   struct acpi_walk_state *walk_state)
+acpi_ds_create_buffer_field(union acpi_parse_object * op,
+   struct acpi_walk_state * walk_state)
 {
union acpi_parse_object *arg;
struct acpi_namespace_node *node;
diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index 3a26ddb..6ec8dca 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -143,7 +143,7 @@ acpi_ds_result_pop(union acpi_operand_object **object,
  
**/
 
 acpi_status
-acpi_ds_result_push(union acpi_operand_object * object,
+acpi_ds_result_push(union acpi_operand_object *object,
struct acpi_walk_state * walk_state)
 {
union acpi_generic_state *state;
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index a1d177d..03d2eb0 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -334,7 +334,7 @@ acpi_ex_region_read(union acpi_operand_object *obj_desc, 
u32 length, u8 *buffer)
 acpi_status
 acpi_ex_load_op(union acpi_operand_object *obj_desc,
union acpi_operand_object *target,
-   struct acpi_walk_state *walk_state)
+   struct acpi_walk_state * walk_state)
 {
union acpi_operand_object *ddb_handle;
struct acpi_table_header *table_header;
diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c
index 076074d..3bcea59 100644
--- a/drivers/acpi/acpica/exregion.c
+++ b/drivers/acpi/acpica/exregion.c
@@ -333,7 +333,7 @@ acpi_ex_system_io_space_handler(u32 function,
case ACPI_WRITE:
 
status = acpi_hw_write_port((acpi_io_address) address,
-   (u32) * value, bit_width);
+ 

[PATCH 03/15] ACPICA: Refactor evaluate_object to reduce nesting

[Lv Zheng]

From: Bob Moore 

ACPICA commit 599e9159f53565e4a3f3e67f6a03f81fcb10a4cf

Original patch from hanjun@linaro.org
ACPICA BZ 1072.

Link: https://github.com/acpica/acpica/commit/599e9159
Link: https://bugs.acpica.org/show_bug.cgi?id=1072
Original-by: Hanjun Guo 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/nsxfeval.c |  111 
 1 file changed, 55 insertions(+), 56 deletions(-)

diff --git a/drivers/acpi/acpica/nsxfeval.c b/drivers/acpi/acpica/nsxfeval.c
index 614e4ba..d2a9b4f 100644
--- a/drivers/acpi/acpica/nsxfeval.c
+++ b/drivers/acpi/acpica/nsxfeval.c
@@ -280,13 +280,12 @@ acpi_evaluate_object(acpi_handle handle,
info->parameters[info->param_count] = NULL;
}
 
-#if 0
+#ifdef _FUTURE_FEATURE
 
/*
 * Begin incoming argument count analysis. Check for too few args
 * and too many args.
 */
-
switch (acpi_ns_get_type(info->node)) {
case ACPI_TYPE_METHOD:
 
@@ -370,68 +369,68 @@ acpi_evaluate_object(acpi_handle handle,
 * If we are expecting a return value, and all went well above,
 * copy the return value to an external object.
 */
-   if (return_buffer) {
-   if (!info->return_object) {
-   return_buffer->length = 0;
-   } else {
-   if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
-   ACPI_DESC_TYPE_NAMED) {
-   /*
-* If we received a NS Node as a return object, 
this means that
-* the object we are evaluating has nothing 
interesting to
-* return (such as a mutex, etc.)  We return an 
error because
-* these types are essentially unsupported by 
this interface.
-* We don't check up front because this makes 
it easier to add
-* support for various types at a later date if 
necessary.
-*/
-   status = AE_TYPE;
-   info->return_object = NULL; /* No need to 
delete a NS Node */
-   return_buffer->length = 0;
-   }
+   if (!return_buffer) {
+   goto cleanup_return_object;
+   }
 
-   if (ACPI_SUCCESS(status)) {
+   if (!info->return_object) {
+   return_buffer->length = 0;
+   goto cleanup;
+   }
 
-   /* Dereference Index and ref_of references */
+   if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
+   ACPI_DESC_TYPE_NAMED) {
+   /*
+* If we received a NS Node as a return object, this means that
+* the object we are evaluating has nothing interesting to
+* return (such as a mutex, etc.)  We return an error because
+* these types are essentially unsupported by this interface.
+* We don't check up front because this makes it easier to add
+* support for various types at a later date if necessary.
+*/
+   status = AE_TYPE;
+   info->return_object = NULL; /* No need to delete a NS Node 
*/
+   return_buffer->length = 0;
+   }
 
-   acpi_ns_resolve_references(info);
+   if (ACPI_FAILURE(status)) {
+   goto cleanup_return_object;
+   }
 
-   /* Get the size of the returned object */
+   /* Dereference Index and ref_of references */
 
-   status =
-   acpi_ut_get_object_size(info->return_object,
-   
_space_needed);
-   if (ACPI_SUCCESS(status)) {
-
-   /* Validate/Allocate/Clear caller 
buffer */
-
-   status =
-   acpi_ut_initialize_buffer
-   (return_buffer,
-buffer_space_needed);
-   if (ACPI_FAILURE(status)) {
-   /*
-* Caller's buffer is too small 
or a new one can't
-* be allocated
-*/
-   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Needed 
buffer size %X, %s\n",
- (u32)
-  

[PATCH 00/15] ACPICA: 20160422 Release

[Lv Zheng]

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

NOTE:
1. Indentation improvement
The [PATCH 02] is a result of an ACPICA release process fix. It requires
much of human intervention, and many linuxized patches in my hand that are
not upstreamed to the ACPICA are burnt by this commit, which takes weeks or
months to recover. So hope we can do it only once. The [PATCH 01] can
reduce the painful manual work when we have to re-do it.
2. AcessWidth/BitOffset support
The old way of hardware access code has been working for many years. The
commits in this release cycle enables AccessWidth/BitOffset support. Though
the commits of AccessWidth/BitOffset support are written in the regression
safer way, it may still break users because of unknown cases. But we need
to have it in the upstream so that it can be used by as many as possible
users in order to obtain the feedback to reveal the unknown cases.

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 (20160318 Release):
  494 lines
After applying (20160422 Release):
  485 lines
The reduction is caused by recently merged module level improvement.

Bob Moore (7):
  ACPICA: Refactor evaluate_object to reduce nesting
  ACPICA: ACPI 6.1: Support for new PCCT subtable
  ACPICA: ACPI 6.0: Update _BIX support for new package element
  ACPICA: ACPI 6.0, tools/iasl: Add support for new resource
descriptors
  ACPICA: Renamed some #defined flag constants for clarity
  ACPICA: Move all ASCII utilities to a common file
  ACPICA: Update version to 20160422

Lv Zheng (7):
  ACPICA: Linuxize: reduce divergences for 20160422 release
  ACPICA: Divergence: remove unwanted spaces for typedef
  ACPICA: Utilities: Add ACPI_IS_ALIGNED() macro
  ACPICA: Hardware: Add optimized access bit width support
  ACPICA: Executer: Introduce a set of macros to handle bit width mask
generation
  ACPICA: Hardware: Add access_width/bit_offset support in
acpi_hw_read()
  ACPICA: Hardware: Add access_width/bit_offset support for
acpi_hw_write()

Prarit Bhargava (1):
  ACPICA: Dispatcher: Update thread ID for recursive method calls

 drivers/acpi/acpica/Makefile   |1 +
 drivers/acpi/acpica/acdebug.h  |6 +-
 drivers/acpi/acpica/acevents.h |1 +
 drivers/acpi/acpica/acinterp.h |2 +-
 drivers/acpi/acpica/aclocal.h  |   61 ++---
 drivers/acpi/acpica/acmacros.h |   15 +-
 drivers/acpi/acpica/acpredef.h |5 +-
 drivers/acpi/acpica/acresrc.h  |8 +-
 drivers/acpi/acpica/actables.h |2 -
 drivers/acpi/acpica/acutils.h  |   35 +--
 drivers/acpi/acpica/dbcmds.c   |4 +-
 drivers/acpi/acpica/dbconvert.c|4 +-
 drivers/acpi/acpica/dbexec.c   |2 +-
 drivers/acpi/acpica/dbinput.c  |6 +-
 drivers/acpi/acpica/dbnames.c  |4 +-
 drivers/acpi/acpica/dbxface.c  |4 +-
 drivers/acpi/acpica/dscontrol.c|4 +-
 drivers/acpi/acpica/dsinit.c   |2 +-
 drivers/acpi/acpica/dsmethod.c |5 +-
 drivers/acpi/acpica/dsutils.c  |2 +-
 drivers/acpi/acpica/dswload.c  |4 +-
 drivers/acpi/acpica/dswload2.c |4 +-
 drivers/acpi/acpica/dswstate.c |   10 +-
 drivers/acpi/acpica/evgpe.c|4 +-
 drivers/acpi/acpica/evgpeblk.c |4 +-
 drivers/acpi/acpica/evgpeutil.c|4 +-
 drivers/acpi/acpica/evhandler.c|2 +-
 drivers/acpi/acpica/evmisc.c   |3 +-
 drivers/acpi/acpica/evrgnini.c |2 +-
 drivers/acpi/acpica/evxfgpe.c  |2 +-
 

[PATCH 02/15] ACPICA: Divergence: remove unwanted spaces for typedef

[Lv Zheng]

ACPICA commit b2294cae776f5a66a7697414b21949d307e6856f

This patch removes unwanted spaces for typedef. This solution doesn't cover
function types.

Note that the linuxize result of this commit is very giant and should have
many conflicts against the current Linux upstream. Thus it is required to
modify the linuxize result of this commit and the commits around it
manually in order to have them merged to the Linux upstream. Since this is
very costy, we should do this only once, and if we can't ensure to do this
only once, we need to revert the Linux code to the wrong indentation result
before merging the linuxize result of this commit. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/b2294cae
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acdebug.h  |6 +-
 drivers/acpi/acpica/acevents.h |1 +
 drivers/acpi/acpica/acinterp.h |2 +-
 drivers/acpi/acpica/aclocal.h  |   31 +++
 drivers/acpi/acpica/acresrc.h  |6 +-
 drivers/acpi/acpica/actables.h |2 +-
 drivers/acpi/acpica/acutils.h  |   22 ++---
 drivers/acpi/acpica/dbcmds.c   |4 +-
 drivers/acpi/acpica/dbconvert.c|4 +-
 drivers/acpi/acpica/dbexec.c   |2 +-
 drivers/acpi/acpica/dbinput.c  |6 +-
 drivers/acpi/acpica/dbnames.c  |2 +-
 drivers/acpi/acpica/dbxface.c  |4 +-
 drivers/acpi/acpica/dscontrol.c|4 +-
 drivers/acpi/acpica/dsfield.c  |4 +-
 drivers/acpi/acpica/dsinit.c   |2 +-
 drivers/acpi/acpica/dsmethod.c |2 +-
 drivers/acpi/acpica/dsutils.c  |2 +-
 drivers/acpi/acpica/dswload.c  |4 +-
 drivers/acpi/acpica/dswload2.c |4 +-
 drivers/acpi/acpica/dswstate.c |8 +-
 drivers/acpi/acpica/evgpe.c|4 +-
 drivers/acpi/acpica/evgpeblk.c |4 +-
 drivers/acpi/acpica/evgpeutil.c|4 +-
 drivers/acpi/acpica/evhandler.c|2 +-
 drivers/acpi/acpica/evmisc.c   |3 +-
 drivers/acpi/acpica/evrgnini.c |2 +-
 drivers/acpi/acpica/evxfgpe.c  |2 +-
 drivers/acpi/acpica/exconcat.c |4 +-
 drivers/acpi/acpica/exconfig.c |2 +-
 drivers/acpi/acpica/exconvrt.c |4 +-
 drivers/acpi/acpica/excreate.c |2 +-
 drivers/acpi/acpica/exfield.c  |4 +-
 drivers/acpi/acpica/exfldio.c  |2 +-
 drivers/acpi/acpica/exoparg3.c |8 +-
 drivers/acpi/acpica/exoparg6.c |2 +-
 drivers/acpi/acpica/exregion.c |4 +-
 drivers/acpi/acpica/exresnte.c |4 +-
 drivers/acpi/acpica/exresolv.c |2 +-
 drivers/acpi/acpica/exresop.c  |2 +-
 drivers/acpi/acpica/exstorob.c |4 +-
 drivers/acpi/acpica/hwgpe.c|   16 ++--
 drivers/acpi/acpica/hwregs.c   |4 +-
 drivers/acpi/acpica/hwxface.c  |9 +-
 drivers/acpi/acpica/nsconvert.c|6 +-
 drivers/acpi/acpica/nsnames.c  |2 +-
 drivers/acpi/acpica/nsobject.c |4 +-
 drivers/acpi/acpica/nspredef.c |2 +-
 drivers/acpi/acpica/nsrepair.c |2 +-
 drivers/acpi/acpica/nsrepair2.c|6 +-
 drivers/acpi/acpica/nsutils.c  |8 +-
 drivers/acpi/acpica/nsxfeval.c |2 +-
 drivers/acpi/acpica/nsxfname.c |8 +-
 drivers/acpi/acpica/nsxfobj.c  |6 +-
 drivers/acpi/acpica/psargs.c   |2 +-
 drivers/acpi/acpica/psparse.c  |4 +-
 drivers/acpi/acpica/psxface.c  |2 +-
 drivers/acpi/acpica/rscalc.c   |   88 ++--
 drivers/acpi/acpica/rscreate.c |2 +-
 drivers/acpi/acpica/rsmisc.c   |2 +-
 drivers/acpi/acpica/rsutils.c  |   12 +--
 drivers/acpi/acpica/rsxface.c  |6 +-
 drivers/acpi/acpica/tbdata.c   |9 +-
 drivers/acpi/acpica/tbfadt.c   |2 +-
 drivers/acpi/acpica/tbutils.c  |6 +-
 drivers/acpi/acpica/tbxface.c  |8 +-
 drivers/acpi/acpica/tbxfroot.c |8 +-
 drivers/acpi/acpica/utalloc.c  

[PATCH 01/15] ACPICA: Linuxize: reduce divergences for 20160422 release

[Lv Zheng]

The patch reduces source code differences between the Linux kernel and the
ACPICA upstream so that the linuxized ACPICA 20160422 release can be
applied with reduced human intervention.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h  |2 +-
 drivers/acpi/acpica/acresrc.h  |2 +-
 drivers/acpi/acpica/actables.h |2 +-
 drivers/acpi/acpica/dsfield.c  |4 ++--
 drivers/acpi/acpica/dswstate.c |2 +-
 drivers/acpi/acpica/exconfig.c |2 +-
 drivers/acpi/acpica/exregion.c |2 +-
 drivers/acpi/acpica/exresop.c  |2 +-
 drivers/acpi/acpica/hwgpe.c|   10 +-
 drivers/acpi/acpica/hwregs.c   |4 ++--
 drivers/acpi/acpica/hwxface.c  |2 +-
 drivers/acpi/acpica/nspredef.c |2 +-
 drivers/acpi/acpica/nsxfname.c |2 +-
 drivers/acpi/acpica/rscalc.c   |2 +-
 drivers/acpi/acpica/tbxface.c  |2 +-
 drivers/acpi/acpica/utcopy.c   |8 
 drivers/acpi/acpica/utlock.c   |4 ++--
 drivers/acpi/acpica/utmath.c   |4 ++--
 include/acpi/acpiosxf.h|2 +-
 19 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 083b16a..379797e 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -541,7 +541,7 @@ struct acpi_gpe_device_info {
 
 typedef acpi_status(*acpi_gpe_callback) (struct acpi_gpe_xrupt_info *
 gpe_xrupt_info,
-struct acpi_gpe_block_info *gpe_block,
+struct acpi_gpe_block_info * gpe_block,
 void *context);
 
 /* Information about each particular fixed event */
diff --git a/drivers/acpi/acpica/acresrc.h b/drivers/acpi/acpica/acresrc.h
index 83e9a29..baacde8 100644
--- a/drivers/acpi/acpica/acresrc.h
+++ b/drivers/acpi/acpica/acresrc.h
@@ -223,7 +223,7 @@ acpi_rs_get_aei_method_data(struct acpi_namespace_node 
*node,
  * rscalc
  */
 acpi_status
-acpi_rs_get_list_length(u8 * aml_buffer,
+acpi_rs_get_list_length(u8 *aml_buffer,
u32 aml_buffer_length, acpi_size * size_needed);
 
 acpi_status
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 848ad3a..fa81099 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -131,7 +131,7 @@ acpi_status acpi_tb_allocate_owner_id(u32 table_index);
 
 acpi_status acpi_tb_release_owner_id(u32 table_index);
 
-acpi_status acpi_tb_get_owner_id(u32 table_index, acpi_owner_id *owner_id);
+acpi_status acpi_tb_get_owner_id(u32 table_index, acpi_owner_id * owner_id);
 
 /*
  * tbutils - table manager utilities
diff --git a/drivers/acpi/acpica/dsfield.c b/drivers/acpi/acpica/dsfield.c
index 6a4b603..0cd777f 100644
--- a/drivers/acpi/acpica/dsfield.c
+++ b/drivers/acpi/acpica/dsfield.c
@@ -147,8 +147,8 @@ acpi_ds_create_external_region(acpi_status lookup_status,
  
**/
 
 acpi_status
-acpi_ds_create_buffer_field(union acpi_parse_object *op,
-   struct acpi_walk_state *walk_state)
+acpi_ds_create_buffer_field(union acpi_parse_object * op,
+   struct acpi_walk_state * walk_state)
 {
union acpi_parse_object *arg;
struct acpi_namespace_node *node;
diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index 3a26ddb..6ec8dca 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -143,7 +143,7 @@ acpi_ds_result_pop(union acpi_operand_object **object,
  
**/
 
 acpi_status
-acpi_ds_result_push(union acpi_operand_object * object,
+acpi_ds_result_push(union acpi_operand_object *object,
struct acpi_walk_state * walk_state)
 {
union acpi_generic_state *state;
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index a1d177d..03d2eb0 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -334,7 +334,7 @@ acpi_ex_region_read(union acpi_operand_object *obj_desc, 
u32 length, u8 *buffer)
 acpi_status
 acpi_ex_load_op(union acpi_operand_object *obj_desc,
union acpi_operand_object *target,
-   struct acpi_walk_state *walk_state)
+   struct acpi_walk_state * walk_state)
 {
union acpi_operand_object *ddb_handle;
struct acpi_table_header *table_header;
diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c
index 076074d..3bcea59 100644
--- a/drivers/acpi/acpica/exregion.c
+++ b/drivers/acpi/acpica/exregion.c
@@ -333,7 +333,7 @@ acpi_ex_system_io_space_handler(u32 function,
case ACPI_WRITE:
 
status = acpi_hw_write_port((acpi_io_address) address,
-   (u32) * value, bit_width);
+ 

Re: [PATCH 0.14] oom detection rework v6

[Joonsoo Kim]

On Wed, Apr 20, 2016 at 03:47:13PM -0400, Michal Hocko wrote:
> Hi,
> 
> This is v6 of the series. The previous version was posted [1]. The
> code hasn't changed much since then. I have found one old standing
> bug (patch 1) which just got much more severe and visible with this
> series. Other than that I have reorganized the series and put the
> compaction feedback abstraction to the front just in case we find out
> that parts of the series would have to be reverted later on for some
> reason. The premature oom killer invocation reported by Hugh [2] seems
> to be addressed.
> 
> We have discussed this series at LSF/MM summit in Raleigh and there
> didn't seem to be any concerns/objections to go on with the patch set
> and target it for the next merge window. 

I still don't agree with some part of this patchset that deal with
!costly order. As you know, there was two regression reports from Hugh
and Aaron and you fixed them by ensuring to trigger compaction. I
think that these show the problem of this patchset. Previous kernel
doesn't need to ensure to trigger compaction and just works fine in
any case. Your series make compaction necessary for all. OOM handling
is essential part in MM but compaction isn't. OOM handling should not
depend on compaction. I tested my own benchmark without
CONFIG_COMPACTION and found that premature OOM happens.

I hope that you try to test something without CONFIG_COMPACTION.

Thanks.

> 
> Motivation:
> As pointed by Linus [3][4] relying on zone_reclaimable as a way to
> communicate the reclaim progress is rater dubious. I tend to agree,
> not only it is really obscure, it is not hard to imagine cases where a
> single page freed in the loop keeps all the reclaimers looping without
> getting any progress because their gfp_mask wouldn't allow to get that
> page anyway (e.g. single GFP_ATOMIC alloc and free loop). This is rather
> rare so it doesn't happen in the practice but the current logic which we
> have is rather obscure and hard to follow a also non-deterministic.
> 
> This is an attempt to make the OOM detection more deterministic and
> easier to follow because each reclaimer basically tracks its own
> progress which is implemented at the page allocator layer rather spread
> out between the allocator and the reclaim. The more on the implementation
> is described in the first patch.
> 
> I have tested several different scenarios but it should be clear that
> testing OOM killer is quite hard to be representative. There is usually
> a tiny gap between almost OOM and full blown OOM which is often time
> sensitive. Anyway, I have tested the following 2 scenarios and I would
> appreciate if there are more to test.
> 
> Testing environment: a virtual machine with 2G of RAM and 2CPUs without
> any swap to make the OOM more deterministic.
> 
> 1) 2 writers (each doing dd with 4M blocks to an xfs partition with 1G
>file size, removes the files and starts over again) running in
>parallel for 10s to build up a lot of dirty pages when 100 parallel
>mem_eaters (anon private populated mmap which waits until it gets
>signal) with 80M each.
> 
>This causes an OOM flood of course and I have compared both patched
>and unpatched kernels. The test is considered finished after there
>are no OOM conditions detected. This should tell us whether there are
>any excessive kills or some of them premature (e.g. due to dirty pages):
> 
> I have performed two runs this time each after a fresh boot.
> 
> * base kernel
> $ grep "Out of memory:" base-oom-run1.log | wc -l
> 78
> $ grep "Out of memory:" base-oom-run2.log | wc -l
> 78
> 
> $ grep "Kill process" base-oom-run1.log | tail -n1
> [   91.391203] Out of memory: Kill process 3061 (mem_eater) score 39 or 
> sacrifice child
> $ grep "Kill process" base-oom-run2.log | tail -n1
> [   82.141919] Out of memory: Kill process 3086 (mem_eater) score 39 or 
> sacrifice child
> 
> $ grep "DMA32 free:" base-oom-run1.log | sed 's@.*free:\([0-9]*\)kB.*@\1@' | 
> calc_min_max.awk 
> min: 5376.00 max: 6776.00 avg: 5530.75 std: 166.50 nr: 61
> $ grep "DMA32 free:" base-oom-run2.log | sed 's@.*free:\([0-9]*\)kB.*@\1@' | 
> calc_min_max.awk 
> min: 5416.00 max: 5608.00 avg: 5514.15 std: 42.94 nr: 52
> 
> $ grep "DMA32.*all_unreclaimable? no" base-oom-run1.log | wc -l
> 1
> $ grep "DMA32.*all_unreclaimable? no" base-oom-run2.log | wc -l
> 3
> 
> * patched kernel
> $ grep "Out of memory:" patched-oom-run1.log | wc -l
> 78
> miso@tiehlicka /mnt/share/devel/miso/kvm $ grep "Out of memory:" 
> patched-oom-run2.log | wc -l
> 77
> 
> e grep "Kill process" patched-oom-run1.log | tail -n1
> [  497.317732] Out of memory: Kill process 3108 (mem_eater) score 39 or 
> sacrifice child
> $ grep "Kill process" patched-oom-run2.log | tail -n1
> [  316.169920] Out of memory: Kill process 3093 (mem_eater) score 39 or 
> sacrifice child
> 
> $ grep "DMA32 free:" patched-oom-run1.log | sed 's@.*free:\([0-9]*\)kB.*@\1@' 
> | calc_min_max.awk 
> min: 

Re: [PATCH 0.14] oom detection rework v6

[Joonsoo Kim]

On Wed, Apr 20, 2016 at 03:47:13PM -0400, Michal Hocko wrote:
> Hi,
> 
> This is v6 of the series. The previous version was posted [1]. The
> code hasn't changed much since then. I have found one old standing
> bug (patch 1) which just got much more severe and visible with this
> series. Other than that I have reorganized the series and put the
> compaction feedback abstraction to the front just in case we find out
> that parts of the series would have to be reverted later on for some
> reason. The premature oom killer invocation reported by Hugh [2] seems
> to be addressed.
> 
> We have discussed this series at LSF/MM summit in Raleigh and there
> didn't seem to be any concerns/objections to go on with the patch set
> and target it for the next merge window. 

I still don't agree with some part of this patchset that deal with
!costly order. As you know, there was two regression reports from Hugh
and Aaron and you fixed them by ensuring to trigger compaction. I
think that these show the problem of this patchset. Previous kernel
doesn't need to ensure to trigger compaction and just works fine in
any case. Your series make compaction necessary for all. OOM handling
is essential part in MM but compaction isn't. OOM handling should not
depend on compaction. I tested my own benchmark without
CONFIG_COMPACTION and found that premature OOM happens.

I hope that you try to test something without CONFIG_COMPACTION.

Thanks.

> 
> Motivation:
> As pointed by Linus [3][4] relying on zone_reclaimable as a way to
> communicate the reclaim progress is rater dubious. I tend to agree,
> not only it is really obscure, it is not hard to imagine cases where a
> single page freed in the loop keeps all the reclaimers looping without
> getting any progress because their gfp_mask wouldn't allow to get that
> page anyway (e.g. single GFP_ATOMIC alloc and free loop). This is rather
> rare so it doesn't happen in the practice but the current logic which we
> have is rather obscure and hard to follow a also non-deterministic.
> 
> This is an attempt to make the OOM detection more deterministic and
> easier to follow because each reclaimer basically tracks its own
> progress which is implemented at the page allocator layer rather spread
> out between the allocator and the reclaim. The more on the implementation
> is described in the first patch.
> 
> I have tested several different scenarios but it should be clear that
> testing OOM killer is quite hard to be representative. There is usually
> a tiny gap between almost OOM and full blown OOM which is often time
> sensitive. Anyway, I have tested the following 2 scenarios and I would
> appreciate if there are more to test.
> 
> Testing environment: a virtual machine with 2G of RAM and 2CPUs without
> any swap to make the OOM more deterministic.
> 
> 1) 2 writers (each doing dd with 4M blocks to an xfs partition with 1G
>file size, removes the files and starts over again) running in
>parallel for 10s to build up a lot of dirty pages when 100 parallel
>mem_eaters (anon private populated mmap which waits until it gets
>signal) with 80M each.
> 
>This causes an OOM flood of course and I have compared both patched
>and unpatched kernels. The test is considered finished after there
>are no OOM conditions detected. This should tell us whether there are
>any excessive kills or some of them premature (e.g. due to dirty pages):
> 
> I have performed two runs this time each after a fresh boot.
> 
> * base kernel
> $ grep "Out of memory:" base-oom-run1.log | wc -l
> 78
> $ grep "Out of memory:" base-oom-run2.log | wc -l
> 78
> 
> $ grep "Kill process" base-oom-run1.log | tail -n1
> [   91.391203] Out of memory: Kill process 3061 (mem_eater) score 39 or 
> sacrifice child
> $ grep "Kill process" base-oom-run2.log | tail -n1
> [   82.141919] Out of memory: Kill process 3086 (mem_eater) score 39 or 
> sacrifice child
> 
> $ grep "DMA32 free:" base-oom-run1.log | sed 's@.*free:\([0-9]*\)kB.*@\1@' | 
> calc_min_max.awk 
> min: 5376.00 max: 6776.00 avg: 5530.75 std: 166.50 nr: 61
> $ grep "DMA32 free:" base-oom-run2.log | sed 's@.*free:\([0-9]*\)kB.*@\1@' | 
> calc_min_max.awk 
> min: 5416.00 max: 5608.00 avg: 5514.15 std: 42.94 nr: 52
> 
> $ grep "DMA32.*all_unreclaimable? no" base-oom-run1.log | wc -l
> 1
> $ grep "DMA32.*all_unreclaimable? no" base-oom-run2.log | wc -l
> 3
> 
> * patched kernel
> $ grep "Out of memory:" patched-oom-run1.log | wc -l
> 78
> miso@tiehlicka /mnt/share/devel/miso/kvm $ grep "Out of memory:" 
> patched-oom-run2.log | wc -l
> 77
> 
> e grep "Kill process" patched-oom-run1.log | tail -n1
> [  497.317732] Out of memory: Kill process 3108 (mem_eater) score 39 or 
> sacrifice child
> $ grep "Kill process" patched-oom-run2.log | tail -n1
> [  316.169920] Out of memory: Kill process 3093 (mem_eater) score 39 or 
> sacrifice child
> 
> $ grep "DMA32 free:" patched-oom-run1.log | sed 's@.*free:\([0-9]*\)kB.*@\1@' 
> | calc_min_max.awk 
> min: 

[PATCH] staging: dgnc: Fix a NULL pointer dereference

[Daeseok Youn]

The error handling for print_drive after calling tty_alloc_driver()
was needed. But there was error handling but too late for this.
Error handling code moved after tty_alloc_driver() call.

Fixes: 60b3109e5e2d ("staging: dgnc: use tty_alloc_driver instead of kcalloc")
Reported-by: Dan Carpenter 
Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 2cecdb0..392d532 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -224,6 +224,11 @@ int dgnc_tty_register(struct dgnc_board *brd)
 TTY_DRIVER_DYNAMIC_DEV |
 TTY_DRIVER_HARDWARE_BREAK);
 
+   if (IS_ERR(brd->print_driver)) {
+   rc = PTR_ERR(brd->print_driver);
+   goto unregister_serial_driver;
+   }
+
snprintf(brd->print_name, MAXTTYNAMELEN, "pr_dgnc_%d_", brd->boardnum);
 
brd->print_driver->name = brd->print_name;
@@ -235,11 +240,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
brd->print_driver->init_termios = DgncDefaultTermios;
brd->print_driver->driver_name = DRVSTR;
 
-   if (IS_ERR(brd->print_driver)) {
-   rc = PTR_ERR(brd->print_driver);
-   goto unregister_serial_driver;
-   }
-
/*
 * Entry points for driver.  Called by the kernel from
 * tty_io.c and n_tty.c.
-- 
2.8.2

[PATCH] staging: dgnc: Fix a NULL pointer dereference

[Daeseok Youn]

The error handling for print_drive after calling tty_alloc_driver()
was needed. But there was error handling but too late for this.
Error handling code moved after tty_alloc_driver() call.

Fixes: 60b3109e5e2d ("staging: dgnc: use tty_alloc_driver instead of kcalloc")
Reported-by: Dan Carpenter 
Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 2cecdb0..392d532 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -224,6 +224,11 @@ int dgnc_tty_register(struct dgnc_board *brd)
 TTY_DRIVER_DYNAMIC_DEV |
 TTY_DRIVER_HARDWARE_BREAK);
 
+   if (IS_ERR(brd->print_driver)) {
+   rc = PTR_ERR(brd->print_driver);
+   goto unregister_serial_driver;
+   }
+
snprintf(brd->print_name, MAXTTYNAMELEN, "pr_dgnc_%d_", brd->boardnum);
 
brd->print_driver->name = brd->print_name;
@@ -235,11 +240,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
brd->print_driver->init_termios = DgncDefaultTermios;
brd->print_driver->driver_name = DRVSTR;
 
-   if (IS_ERR(brd->print_driver)) {
-   rc = PTR_ERR(brd->print_driver);
-   goto unregister_serial_driver;
-   }
-
/*
 * Entry points for driver.  Called by the kernel from
 * tty_io.c and n_tty.c.
-- 
2.8.2

Re: [PATCH 2/2] Fix issue with dmesg.py and python 3.X

[Jan Kiszka]

On 2016-05-04 05:12, buzdelab...@gmail.com wrote:
> From: Dom Cote 
> 
> Replace the addition (+) of 2 python 'memoryview' objects
> with the addition of 2 'bytes' objects, convert the result
> back to memoryview.
> 
> Tested with python 3.4 and 2.7
> Tested with gdb 7.7

A word here on what setup was found broken would have been good. If you
have a sentence at hand, we can fold it in during merge.

> 
> Signed-off-by: Dom Cote 
> ---
>  scripts/gdb/linux/dmesg.py | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
> index 927d0d2a3145..04d6719067f2 100644
> --- a/scripts/gdb/linux/dmesg.py
> +++ b/scripts/gdb/linux/dmesg.py
> @@ -33,11 +33,12 @@ class LxDmesg(gdb.Command):
>  if log_first_idx < log_next_idx:
>  log_buf_2nd_half = -1
>  length = log_next_idx - log_first_idx
> -log_buf = inf.read_memory(start, length)
> +log_buf = utils.read_memoryview(inf, start, length).tobytes()
>  else:
>  log_buf_2nd_half = log_buf_len - log_first_idx
> -log_buf = inf.read_memory(start, log_buf_2nd_half) + \
> -inf.read_memory(log_buf_addr, log_next_idx)
> +a = utils.read_memoryview(inf, start, log_buf_2nd_half)
> +b = utils.read_memoryview(inf, log_buf_addr, log_next_idx)
> +log_buf = a.tobytes() + b.tobytes()
>  
>  pos = 0
>  while pos < log_buf.__len__():
> 

Patches look good to me on first glance. Need to try out as well.

Kieran?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 2/2] Fix issue with dmesg.py and python 3.X

[Jan Kiszka]

On 2016-05-04 05:12, buzdelab...@gmail.com wrote:
> From: Dom Cote 
> 
> Replace the addition (+) of 2 python 'memoryview' objects
> with the addition of 2 'bytes' objects, convert the result
> back to memoryview.
> 
> Tested with python 3.4 and 2.7
> Tested with gdb 7.7

A word here on what setup was found broken would have been good. If you
have a sentence at hand, we can fold it in during merge.

> 
> Signed-off-by: Dom Cote 
> ---
>  scripts/gdb/linux/dmesg.py | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
> index 927d0d2a3145..04d6719067f2 100644
> --- a/scripts/gdb/linux/dmesg.py
> +++ b/scripts/gdb/linux/dmesg.py
> @@ -33,11 +33,12 @@ class LxDmesg(gdb.Command):
>  if log_first_idx < log_next_idx:
>  log_buf_2nd_half = -1
>  length = log_next_idx - log_first_idx
> -log_buf = inf.read_memory(start, length)
> +log_buf = utils.read_memoryview(inf, start, length).tobytes()
>  else:
>  log_buf_2nd_half = log_buf_len - log_first_idx
> -log_buf = inf.read_memory(start, log_buf_2nd_half) + \
> -inf.read_memory(log_buf_addr, log_next_idx)
> +a = utils.read_memoryview(inf, start, log_buf_2nd_half)
> +b = utils.read_memoryview(inf, log_buf_addr, log_next_idx)
> +log_buf = a.tobytes() + b.tobytes()
>  
>  pos = 0
>  while pos < log_buf.__len__():
> 

Patches look good to me on first glance. Need to try out as well.

Kieran?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[PATCH 3/3] staging: dgnc: clean up the dgnc_get_modem_info()

[Daeseok Youn]

the "ch" in dgnc_get_modem_info() was already checked before calling
this function and also if "ch" is not NULL, dgnc_get_mstat() returns
valid value so it doesn't need to check an error.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 46ca01d..f67d7d4 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -2013,17 +2013,7 @@ static inline int dgnc_get_mstat(struct channel_t *ch)
 static int dgnc_get_modem_info(struct channel_t *ch,
   unsigned int  __user *value)
 {
-   int result;
-
-   if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
-   return -ENXIO;
-
-   result = dgnc_get_mstat(ch);
-
-   if (result < 0)
-   return -ENXIO;
-
-   return put_user(result, value);
+   return put_user(dgnc_get_mstat(ch), value);
 }
 
 /*
-- 
2.8.2

[PATCH 3/3] staging: dgnc: clean up the dgnc_get_modem_info()

[Daeseok Youn]

the "ch" in dgnc_get_modem_info() was already checked before calling
this function and also if "ch" is not NULL, dgnc_get_mstat() returns
valid value so it doesn't need to check an error.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 46ca01d..f67d7d4 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -2013,17 +2013,7 @@ static inline int dgnc_get_mstat(struct channel_t *ch)
 static int dgnc_get_modem_info(struct channel_t *ch,
   unsigned int  __user *value)
 {
-   int result;
-
-   if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
-   return -ENXIO;
-
-   result = dgnc_get_mstat(ch);
-
-   if (result < 0)
-   return -ENXIO;
-
-   return put_user(result, value);
+   return put_user(dgnc_get_mstat(ch), value);
 }
 
 /*
-- 
2.8.2

Re: [PATCH] PCI: dra7xx: program outbound atu with correct address

[Kishon Vijay Abraham I]

On Tuesday 03 May 2016 10:20 PM, Bjorn Helgaas wrote:
> On Mon, May 02, 2016 at 04:09:33PM -0500, Bjorn Helgaas wrote:
>> On Mon, May 02, 2016 at 04:54:40PM +0200, Niklas Cassel wrote:
>>> From: Niklas Cassel 
>>>
>>> commit 1488aefa37a4 ("PCI: designware: Move Root Complex
>>> setup code to dw_pcie_setup_rc()") broke dra7xx
>>> by moving code from dw_pcie_host_init to dw_pcie_setup_rc.
>>>
>>> Fix this by doing the cpu to bus calculation before calling
>>> dw_pcie_setup_rc.
>>>
>>> Fixes: 1488aefa37a4 ("PCI: designware: Move Root Complex setup code to 
>>> dw_pcie_setup_rc()")
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/host/pci-dra7xx.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
>>> index 2ca3a1f..f441130 100644
>>> --- a/drivers/pci/host/pci-dra7xx.c
>>> +++ b/drivers/pci/host/pci-dra7xx.c
>>> @@ -142,13 +142,13 @@ static void dra7xx_pcie_enable_interrupts(struct 
>>> pcie_port *pp)
>>>  
>>>  static void dra7xx_pcie_host_init(struct pcie_port *pp)
>>>  {
>>> -   dw_pcie_setup_rc(pp);
>>> -
>>> pp->io_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>> pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>> pp->cfg0_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>> pp->cfg1_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>>  
>>> +   dw_pcie_setup_rc(pp);
>>
>> This looks correct to me.  Prior to 1488aefa37a4, we had this path,
>> which applied the dra7xx mem_base adjustment before programming the
>> outbound ATU:
>>
>>   dra7xx_add_pcie_port
>> dw_pcie_host_init
>>   pp->mem_base = pp->mem->start # <-- set pp->mem_base
>>   ops->host_init
>>   dra7xx_pcie_host_init # .host_init
>> dw_pcie_setup_rc
>> pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR  # <-- update pp->mem_base
>>   dw_pcie_prog_outbound_atu(pp->mem_base)   # <-- use pp->mem_base
>>
>> After 1488aefa37a4, we have this:
>>
>>   dra7xx_add_pcie_port
>> dw_pcie_host_init
>>   pp->mem_base = pp->mem->start # <-- set pp->mem_base
>>   ops->host_init
>>   dra7xx_pcie_host_init # .host_init
>> dw_pcie_setup_rc
>>   dw_pcie_prog_outbound_atu(pp->mem_base)   # <-- use pp->mem_base
>> pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR  # <-- update pp->mem_base
>>
>> So the dra7xx update is applied after we've already used it.
>>
>> If you agree, Kishon, I'll fold Niklas's fix into Jisheng's patch so
>> there's no bisection hole for dra7xx.
> 
> I merged this (folded into Jisheng's patch on the pci/host-designware
> branch, and included in my "next" branch).
> 
> Please let me know if it works for you, Niklas, or if you see any
> problems.

I did a basic ping test with a broadcom ethernet card and it worked fine.

Tested-by: Kishon Vijay Abraham I 

> 
>>> dra7xx_pcie_establish_link(pp);
>>> if (IS_ENABLED(CONFIG_PCI_MSI))
>>> dw_pcie_msi_init(pp);
>>> -- 
>>> 2.1.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] staging: dgnc: remove useless assigned error value in

[Daeseok Youn]

the result in dgnc_get_mstat() was initialized with -EIO but
there are no use of EIO as a result in this function.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index d85d005..46ca01d 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -1979,7 +1979,7 @@ static void dgnc_tty_send_xchar(struct tty_struct *tty, 
char c)
 static inline int dgnc_get_mstat(struct channel_t *ch)
 {
unsigned char mstat;
-   int result = -EIO;
+   int result = 0;
unsigned long flags;
 
if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
@@ -1991,8 +1991,6 @@ static inline int dgnc_get_mstat(struct channel_t *ch)
 
spin_unlock_irqrestore(>ch_lock, flags);
 
-   result = 0;
-
if (mstat & UART_MCR_DTR)
result |= TIOCM_DTR;
if (mstat & UART_MCR_RTS)
-- 
2.8.2

Re: [PATCH] PCI: dra7xx: program outbound atu with correct address

[Kishon Vijay Abraham I]

On Tuesday 03 May 2016 10:20 PM, Bjorn Helgaas wrote:
> On Mon, May 02, 2016 at 04:09:33PM -0500, Bjorn Helgaas wrote:
>> On Mon, May 02, 2016 at 04:54:40PM +0200, Niklas Cassel wrote:
>>> From: Niklas Cassel 
>>>
>>> commit 1488aefa37a4 ("PCI: designware: Move Root Complex
>>> setup code to dw_pcie_setup_rc()") broke dra7xx
>>> by moving code from dw_pcie_host_init to dw_pcie_setup_rc.
>>>
>>> Fix this by doing the cpu to bus calculation before calling
>>> dw_pcie_setup_rc.
>>>
>>> Fixes: 1488aefa37a4 ("PCI: designware: Move Root Complex setup code to 
>>> dw_pcie_setup_rc()")
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/host/pci-dra7xx.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
>>> index 2ca3a1f..f441130 100644
>>> --- a/drivers/pci/host/pci-dra7xx.c
>>> +++ b/drivers/pci/host/pci-dra7xx.c
>>> @@ -142,13 +142,13 @@ static void dra7xx_pcie_enable_interrupts(struct 
>>> pcie_port *pp)
>>>  
>>>  static void dra7xx_pcie_host_init(struct pcie_port *pp)
>>>  {
>>> -   dw_pcie_setup_rc(pp);
>>> -
>>> pp->io_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>> pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>> pp->cfg0_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>> pp->cfg1_base &= DRA7XX_CPU_TO_BUS_ADDR;
>>>  
>>> +   dw_pcie_setup_rc(pp);
>>
>> This looks correct to me.  Prior to 1488aefa37a4, we had this path,
>> which applied the dra7xx mem_base adjustment before programming the
>> outbound ATU:
>>
>>   dra7xx_add_pcie_port
>> dw_pcie_host_init
>>   pp->mem_base = pp->mem->start # <-- set pp->mem_base
>>   ops->host_init
>>   dra7xx_pcie_host_init # .host_init
>> dw_pcie_setup_rc
>> pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR  # <-- update pp->mem_base
>>   dw_pcie_prog_outbound_atu(pp->mem_base)   # <-- use pp->mem_base
>>
>> After 1488aefa37a4, we have this:
>>
>>   dra7xx_add_pcie_port
>> dw_pcie_host_init
>>   pp->mem_base = pp->mem->start # <-- set pp->mem_base
>>   ops->host_init
>>   dra7xx_pcie_host_init # .host_init
>> dw_pcie_setup_rc
>>   dw_pcie_prog_outbound_atu(pp->mem_base)   # <-- use pp->mem_base
>> pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR  # <-- update pp->mem_base
>>
>> So the dra7xx update is applied after we've already used it.
>>
>> If you agree, Kishon, I'll fold Niklas's fix into Jisheng's patch so
>> there's no bisection hole for dra7xx.
> 
> I merged this (folded into Jisheng's patch on the pci/host-designware
> branch, and included in my "next" branch).
> 
> Please let me know if it works for you, Niklas, or if you see any
> problems.

I did a basic ping test with a broadcom ethernet card and it worked fine.

Tested-by: Kishon Vijay Abraham I 

> 
>>> dra7xx_pcie_establish_link(pp);
>>> if (IS_ENABLED(CONFIG_PCI_MSI))
>>> dw_pcie_msi_init(pp);
>>> -- 
>>> 2.1.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] staging: dgnc: remove useless assigned error value in

[Daeseok Youn]

the result in dgnc_get_mstat() was initialized with -EIO but
there are no use of EIO as a result in this function.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index d85d005..46ca01d 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -1979,7 +1979,7 @@ static void dgnc_tty_send_xchar(struct tty_struct *tty, 
char c)
 static inline int dgnc_get_mstat(struct channel_t *ch)
 {
unsigned char mstat;
-   int result = -EIO;
+   int result = 0;
unsigned long flags;
 
if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
@@ -1991,8 +1991,6 @@ static inline int dgnc_get_mstat(struct channel_t *ch)
 
spin_unlock_irqrestore(>ch_lock, flags);
 
-   result = 0;
-
if (mstat & UART_MCR_DTR)
result |= TIOCM_DTR;
if (mstat & UART_MCR_RTS)
-- 
2.8.2

[PATCH 1/3] staging: dgnc: remove redundant NULL check in

[Daeseok Youn]

tty and ch are already checked for NULL
before calling dgnc_block_til_ready().

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 2cecdb0..d85d005 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -1172,17 +1172,12 @@ static int dgnc_block_til_ready(struct tty_struct *tty,
struct channel_t *ch)
 {
int retval = 0;
-   struct un_t *un = NULL;
+   struct un_t *un = tty->driver_data;
unsigned long flags;
uintold_flags = 0;
int sleep_on_un_flags = 0;
 
-   if (!tty || tty->magic != TTY_MAGIC || !file || !ch ||
-   ch->magic != DGNC_CHANNEL_MAGIC)
-   return -ENXIO;
-
-   un = tty->driver_data;
-   if (!un || un->magic != DGNC_UNIT_MAGIC)
+   if (!file)
return -ENXIO;
 
spin_lock_irqsave(>ch_lock, flags);
-- 
2.8.2

[PATCH 1/3] staging: dgnc: remove redundant NULL check in

[Daeseok Youn]

tty and ch are already checked for NULL
before calling dgnc_block_til_ready().

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 2cecdb0..d85d005 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -1172,17 +1172,12 @@ static int dgnc_block_til_ready(struct tty_struct *tty,
struct channel_t *ch)
 {
int retval = 0;
-   struct un_t *un = NULL;
+   struct un_t *un = tty->driver_data;
unsigned long flags;
uintold_flags = 0;
int sleep_on_un_flags = 0;
 
-   if (!tty || tty->magic != TTY_MAGIC || !file || !ch ||
-   ch->magic != DGNC_CHANNEL_MAGIC)
-   return -ENXIO;
-
-   un = tty->driver_data;
-   if (!un || un->magic != DGNC_UNIT_MAGIC)
+   if (!file)
return -ENXIO;
 
spin_lock_irqsave(>ch_lock, flags);
-- 
2.8.2

Re: [linux-sunxi] Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Priit Laes]

On Tue, 2016-05-03 at 17:52 +0200, Olliver Schinagl wrote:
> Hey all,
> 
> On 03-05-16 17:02, christo.ra...@gmail.com wrote:
> > On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote:
> > > > Hi to All,
> > > > 
> > > > I have already solved and tested this issue on Armbian build. 
> > > >  Find
> > > > patches for both legacy (3.4.111) and mainline (4.5.2) kernels
> > > > on:
> > > > http://forum.armbian.com/index.php/topic/853-armbian-customizat
> > > > ion/page-2#entry7494
> > > > There it is also described how to do eMMC bootable and much
> > > > more.
> > > > 
> > > > About the board - Olimex already sold all 3 kinds after
> > > > migration to
> > > > their HW rev. E. One have to specify Lime2-eMMC as
> > > > A20-Olinuxino-Lime2-eMMC instead of their old 2 options
> > > > A20-Olinuxino-Lime2(-4GB).
> > > Interesting, you have a link to that device?

I guess, it is this one:

https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/
open-source-hardware

> > > 
> > > Thanks,
> > > Maxime
> > > 
> > > -- 
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux, Kernel and Android engineering
> > > http://free-electrons.com
> > I have really 2 boards delivered by their local distributor.
> > 
> > Unfortunately, they do not update their site. Use the link for NAND
> > option:
> > https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2-4
> > GB/open-source-hardware
> > There you can find Users Manual where it is described that eMMC
> > option is available from HW rev. D. The schematic for HW rev. E is
> > also available on their repository:
> > https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A20-OLinuX
> > ino-LIME2
> > 
> > On the board both 4GB NAND and eMMC Flash chips can be placed
> > alternatively on the same place. There is difference in some other
> > components as well.
> > 
> > If one want to order it from the site probably has to order A20
> > -Olinuxino-Lime2-4GB with note that eMMC option is required. The
> > price is the same.
> Sorry for the late reply, but yeah the board exists, we asked Olimex
> to 
> develop the eMMC variant for us. I currently have a dozen or so on my
> desk :)
> 
> I don't know when Olimex will update their webshop with the new
> designs, 
> but they simply might not have enough eMMC chips available yet?
> 

Re: [linux-sunxi] Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Priit Laes]

On Tue, 2016-05-03 at 17:52 +0200, Olliver Schinagl wrote:
> Hey all,
> 
> On 03-05-16 17:02, christo.ra...@gmail.com wrote:
> > On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote:
> > > > Hi to All,
> > > > 
> > > > I have already solved and tested this issue on Armbian build. 
> > > >  Find
> > > > patches for both legacy (3.4.111) and mainline (4.5.2) kernels
> > > > on:
> > > > http://forum.armbian.com/index.php/topic/853-armbian-customizat
> > > > ion/page-2#entry7494
> > > > There it is also described how to do eMMC bootable and much
> > > > more.
> > > > 
> > > > About the board - Olimex already sold all 3 kinds after
> > > > migration to
> > > > their HW rev. E. One have to specify Lime2-eMMC as
> > > > A20-Olinuxino-Lime2-eMMC instead of their old 2 options
> > > > A20-Olinuxino-Lime2(-4GB).
> > > Interesting, you have a link to that device?

I guess, it is this one:

https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/
open-source-hardware

> > > 
> > > Thanks,
> > > Maxime
> > > 
> > > -- 
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux, Kernel and Android engineering
> > > http://free-electrons.com
> > I have really 2 boards delivered by their local distributor.
> > 
> > Unfortunately, they do not update their site. Use the link for NAND
> > option:
> > https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2-4
> > GB/open-source-hardware
> > There you can find Users Manual where it is described that eMMC
> > option is available from HW rev. D. The schematic for HW rev. E is
> > also available on their repository:
> > https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A20-OLinuX
> > ino-LIME2
> > 
> > On the board both 4GB NAND and eMMC Flash chips can be placed
> > alternatively on the same place. There is difference in some other
> > components as well.
> > 
> > If one want to order it from the site probably has to order A20
> > -Olinuxino-Lime2-4GB with note that eMMC option is required. The
> > price is the same.
> Sorry for the late reply, but yeah the board exists, we asked Olimex
> to 
> develop the eMMC variant for us. I currently have a dozen or so on my
> desk :)
> 
> I don't know when Olimex will update their webshop with the new
> designs, 
> but they simply might not have enough eMMC chips available yet?
> 

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

[Yinghai Lu]

On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas  wrote:
> On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote:
>>
>> The problem tends to be old Xserver expectations...
>>
>> That stuff has been a can of worms over the years and we did things in
>> the kernel to work around X limitations. I'm not that keen on touching
>> /proc at all in that regard. Leave it there do what it does today, it's
>> a user visible ABI, don't change it.
>
> I did not propose changing any user-visible ABI.  To recap what I did
> propose:

I want to avoid introduce one strange pci_user_to_resource.

>
>   - The sysfs path uses offsets between 0 and BAR size on all arches.
> It uses pci_resource_to_user() today, but I think it should not.
>
>   - The procfs path uses offsets of resource values (CPU physical
> addresses) on most architectures, but uses something else, e.g.,
> BAR values, on others.  pci_resource_to_user() does this
> translation.  The procfs path does not use pci_resource_to_user()
> today, but I think it should.

current powerpc pci_resource_to_user is strange:
it will return resource start for io mem.
but will return BAR (?) start for io port.

sparc pci_resource_to_user does return BAR value for iomem.

>
>   - This implies that pci_mmap_page_range() should deal with resource
> values (CPU physical addresses), and proc_bus_pci_mmap() should do
> any necessary arch-specific translation from BAR values to
> resource values.

so will need one different version pci_user_to_resource.
and can not use pcibios_bus_to_resource directly, and will be another mess.

Can you reconsider to keep the pci_mmap_page_range still use BAR value
and only touch pci_mmap_fits() ?

like i suggested before, and it does not conflict with the patchset.

Subject: [PATCH] PCI: Fix pci_mmap_fits() with proc interface

Passed value is user address, so need to compare it with
user addr that is converted from dev resource.

Signed-off-by: Yinghai Lu 

---
 drivers/pci/pci-sysfs.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/pci-sysfs.c
===
--- linux-2.6.orig/drivers/pci/pci-sysfs.c
+++ linux-2.6/drivers/pci/pci-sysfs.c
@@ -969,15 +969,19 @@ void pci_remove_legacy_files(struct pci_
 int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma,
   enum pci_mmap_api mmap_api)
 {
-unsigned long nr, start, size, pci_start;
+unsigned long nr, start, size;
+resource_size_t pci_start = 0, pci_end;

 if (pci_resource_len(pdev, resno) == 0)
 return 0;
 nr = vma_pages(vma);
 start = vma->vm_pgoff;
 size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
-pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
-pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
+if (mmap_api == PCI_MMAP_PROCFS) {
+pci_resource_to_user(pdev, resno, >resource[resno],
+ _start, _end);
+pci_start >>= PAGE_SHIFT;
+}
 if (start >= pci_start && start < pci_start + size &&
 start + nr <= pci_start + size)
 return 1;

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

[Yinghai Lu]

On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas  wrote:
> On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote:
>>
>> The problem tends to be old Xserver expectations...
>>
>> That stuff has been a can of worms over the years and we did things in
>> the kernel to work around X limitations. I'm not that keen on touching
>> /proc at all in that regard. Leave it there do what it does today, it's
>> a user visible ABI, don't change it.
>
> I did not propose changing any user-visible ABI.  To recap what I did
> propose:

I want to avoid introduce one strange pci_user_to_resource.

>
>   - The sysfs path uses offsets between 0 and BAR size on all arches.
> It uses pci_resource_to_user() today, but I think it should not.
>
>   - The procfs path uses offsets of resource values (CPU physical
> addresses) on most architectures, but uses something else, e.g.,
> BAR values, on others.  pci_resource_to_user() does this
> translation.  The procfs path does not use pci_resource_to_user()
> today, but I think it should.

current powerpc pci_resource_to_user is strange:
it will return resource start for io mem.
but will return BAR (?) start for io port.

sparc pci_resource_to_user does return BAR value for iomem.

>
>   - This implies that pci_mmap_page_range() should deal with resource
> values (CPU physical addresses), and proc_bus_pci_mmap() should do
> any necessary arch-specific translation from BAR values to
> resource values.

so will need one different version pci_user_to_resource.
and can not use pcibios_bus_to_resource directly, and will be another mess.

Can you reconsider to keep the pci_mmap_page_range still use BAR value
and only touch pci_mmap_fits() ?

like i suggested before, and it does not conflict with the patchset.

Subject: [PATCH] PCI: Fix pci_mmap_fits() with proc interface

Passed value is user address, so need to compare it with
user addr that is converted from dev resource.

Signed-off-by: Yinghai Lu 

---
 drivers/pci/pci-sysfs.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/pci-sysfs.c
===
--- linux-2.6.orig/drivers/pci/pci-sysfs.c
+++ linux-2.6/drivers/pci/pci-sysfs.c
@@ -969,15 +969,19 @@ void pci_remove_legacy_files(struct pci_
 int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma,
   enum pci_mmap_api mmap_api)
 {
-unsigned long nr, start, size, pci_start;
+unsigned long nr, start, size;
+resource_size_t pci_start = 0, pci_end;

 if (pci_resource_len(pdev, resno) == 0)
 return 0;
 nr = vma_pages(vma);
 start = vma->vm_pgoff;
 size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
-pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
-pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
+if (mmap_api == PCI_MMAP_PROCFS) {
+pci_resource_to_user(pdev, resno, >resource[resno],
+ _start, _end);
+pci_start >>= PAGE_SHIFT;
+}
 if (start >= pci_start && start < pci_start + size &&
 start + nr <= pci_start + size)
 return 1;

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[Dan Williams]

On Tue, May 3, 2016 at 8:18 PM, Dave Chinner  wrote:
> On Tue, May 03, 2016 at 10:28:15AM -0700, Dan Williams wrote:
>> On Mon, May 2, 2016 at 6:51 PM, Dave Chinner  wrote:
>> > On Mon, May 02, 2016 at 04:25:51PM -0700, Dan Williams wrote:
>> [..]
>> > Yes, I know, and it doesn't answer any of the questions I just
>> > asked. What you just told me is that there is something that is kept
>> > three levels of abstraction away from a filesystem. So:
>>
>> Ok, let's answer them.
>>
>> A lot of your questions seem to assume the filesystem has a leading
>> role to play with error recovery, that isn't the case with traditional
>> disk errors and we're not looking to change that situation.
>
> *cough* BTRFS
>
> New filesystems are mostly being designed with redundancy and
> recovery mechanisms built into them. Hence the high level
> /assumption/ that filesystems aren't going to play a significant
> role in error recovery for pmem storage is, well, somewhat
> disturbing

It is unfortunate is that you cite the lack of pmem enabling in btrfs
as a reason to block patches that hookup the kernel's existing error
mechanisms for the DAX case.  I expect btrfs multi-device
redundancy-management for pmem to be a more a coherent solution than
what we can achieve with single-device-filesystems + RAID.  I'm trying
not to boil the ocean in this discussion, but Iet's go ahead and rope
in btrfs-devel into this thread so we can make progress on hooking up
SIGBUS notifications for DAX errors and bypassing dax_do_io() to clear
errors.

>> The
>> filesystem can help with forensics after an error escapes the kernel
>> and is communicated to userspace, but the ability to reverse map a
>> sector to a file is just a convenience to identify potential data
>> loss.
>
> So working out what file got corrupted in your terabytes of pmem
> storage is "just a convenience"? I suspect that a rather large
> percentage of admins will disagree with you on this.

Yes, I will point them to their file system maintainer to ask about
reverse mapping support.

>> For redundancy in the DAX case I can envision DAX-aware RAID that
>> makes the potential exposure to bad blocks smaller, but it will always
>> be the case that the array can be out-of-sync / degraded and has no
>> choice but to communicate the error to userspace.  So, the answers
>> below address what we do when we are in that state, and include some
>> thoughts about follow-on enabling we can do at the DM/MD layer.
>>
>> > - What mechanism is to be used for the underlying block
>> >   device to inform the filesytem that a new bad block was
>> >   added to this list?
>>
>> The filesystem doesn't need this notification and doesn't get it today
>> from RAID.
>
> Why doesn't the filesystem need this notification? Just because we
> don't get it today from a RAID device does not mean we can't use it.

If xfs and ext4 had a use for error notification today we would hook into it.

> Indeed, think about the btrfs scrub operation - it validates
> everything on it's individual block devices, and when it finds a
> problem (e.g. a data CRC error) it notifies a different layer in the
> btrfs code that goes and works out if it can repair the problem from
> redundant copies/parity/mirrors/etc.

Yes, just like RAID, sounds like we should definitely keep that in
mind for the patch set that adds pmem support to btrfs, this isn't
that patch set.

>> It's handy for the bad block list to be available to
>> fs/dax.c and the block layer, but I don't see ext4/xfs having a role
>> to play with the list and certainly not care about "new error detected
>> events".
>
> That's very short-sighted. Just because ext4/xfs don't *currently*
> do this, it doesn't mean other filesystems (existing or new) can't
> make use of notifications, nor that ext4/XFS can't ever make use of
> it, either.

Did I say "can't ever make use of it", no, if you have a need for a
notification for xfs let's work on a notification mechanism.

>
>> For a DM/MD driver it also does not need to know about new
>> errors because it will follow the traditional disk model where errors
>> are handled on access, or discovered and scrubbed during a periodic
>> array scan.
>>
>> That said, new errors may get added to the list by having the pmem
>> driver trigger a rescan of the device whenever a latent error is
>> discovered (i.e. memcpy_from_pmem() returns -EIO).  The update of the
>> bad block list is asynchronous.  We also have a task on the todo list
>> to allow the pmem rescan action to be triggered via sysfs.
>
> IOWs, the pmem driver won't report errors to anyone who can correct
> them until an access to that bad block is made? Even if it means the
> error might go unreported and hence uncorrected for weeks or months
> because no access is made to that bad data?

RAID periodically polls for and fixes bad blocks.  The currently
implementation only polls for errors at driver load.  When we

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[Dan Williams]

On Tue, May 3, 2016 at 8:18 PM, Dave Chinner  wrote:
> On Tue, May 03, 2016 at 10:28:15AM -0700, Dan Williams wrote:
>> On Mon, May 2, 2016 at 6:51 PM, Dave Chinner  wrote:
>> > On Mon, May 02, 2016 at 04:25:51PM -0700, Dan Williams wrote:
>> [..]
>> > Yes, I know, and it doesn't answer any of the questions I just
>> > asked. What you just told me is that there is something that is kept
>> > three levels of abstraction away from a filesystem. So:
>>
>> Ok, let's answer them.
>>
>> A lot of your questions seem to assume the filesystem has a leading
>> role to play with error recovery, that isn't the case with traditional
>> disk errors and we're not looking to change that situation.
>
> *cough* BTRFS
>
> New filesystems are mostly being designed with redundancy and
> recovery mechanisms built into them. Hence the high level
> /assumption/ that filesystems aren't going to play a significant
> role in error recovery for pmem storage is, well, somewhat
> disturbing

It is unfortunate is that you cite the lack of pmem enabling in btrfs
as a reason to block patches that hookup the kernel's existing error
mechanisms for the DAX case.  I expect btrfs multi-device
redundancy-management for pmem to be a more a coherent solution than
what we can achieve with single-device-filesystems + RAID.  I'm trying
not to boil the ocean in this discussion, but Iet's go ahead and rope
in btrfs-devel into this thread so we can make progress on hooking up
SIGBUS notifications for DAX errors and bypassing dax_do_io() to clear
errors.

>> The
>> filesystem can help with forensics after an error escapes the kernel
>> and is communicated to userspace, but the ability to reverse map a
>> sector to a file is just a convenience to identify potential data
>> loss.
>
> So working out what file got corrupted in your terabytes of pmem
> storage is "just a convenience"? I suspect that a rather large
> percentage of admins will disagree with you on this.

Yes, I will point them to their file system maintainer to ask about
reverse mapping support.

>> For redundancy in the DAX case I can envision DAX-aware RAID that
>> makes the potential exposure to bad blocks smaller, but it will always
>> be the case that the array can be out-of-sync / degraded and has no
>> choice but to communicate the error to userspace.  So, the answers
>> below address what we do when we are in that state, and include some
>> thoughts about follow-on enabling we can do at the DM/MD layer.
>>
>> > - What mechanism is to be used for the underlying block
>> >   device to inform the filesytem that a new bad block was
>> >   added to this list?
>>
>> The filesystem doesn't need this notification and doesn't get it today
>> from RAID.
>
> Why doesn't the filesystem need this notification? Just because we
> don't get it today from a RAID device does not mean we can't use it.

If xfs and ext4 had a use for error notification today we would hook into it.

> Indeed, think about the btrfs scrub operation - it validates
> everything on it's individual block devices, and when it finds a
> problem (e.g. a data CRC error) it notifies a different layer in the
> btrfs code that goes and works out if it can repair the problem from
> redundant copies/parity/mirrors/etc.

Yes, just like RAID, sounds like we should definitely keep that in
mind for the patch set that adds pmem support to btrfs, this isn't
that patch set.

>> It's handy for the bad block list to be available to
>> fs/dax.c and the block layer, but I don't see ext4/xfs having a role
>> to play with the list and certainly not care about "new error detected
>> events".
>
> That's very short-sighted. Just because ext4/xfs don't *currently*
> do this, it doesn't mean other filesystems (existing or new) can't
> make use of notifications, nor that ext4/XFS can't ever make use of
> it, either.

Did I say "can't ever make use of it", no, if you have a need for a
notification for xfs let's work on a notification mechanism.

>
>> For a DM/MD driver it also does not need to know about new
>> errors because it will follow the traditional disk model where errors
>> are handled on access, or discovered and scrubbed during a periodic
>> array scan.
>>
>> That said, new errors may get added to the list by having the pmem
>> driver trigger a rescan of the device whenever a latent error is
>> discovered (i.e. memcpy_from_pmem() returns -EIO).  The update of the
>> bad block list is asynchronous.  We also have a task on the todo list
>> to allow the pmem rescan action to be triggered via sysfs.
>
> IOWs, the pmem driver won't report errors to anyone who can correct
> them until an access to that bad block is made? Even if it means the
> error might go unreported and hence uncorrected for weeks or months
> because no access is made to that bad data?

RAID periodically polls for and fixes bad blocks.  The currently
implementation only polls for errors at driver load.  When we
implement userspace triggered bad blocks 

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

[Jamie Heilman]

Tadeusz Struk wrote:
> On 05/03/2016 07:26 PM, Jamie Heilman wrote:
> >>> Alrighty, presumably relevant bits:
> >>> > >
> >>> > > X.509: Cert Issuer: Build time autogenerated kernel key
> >>> > > X.509: Cert Subject: Build time autogenerated kernel key
> >>> > > X.509: Cert Key Algo: rsa
> >>> > > X.509: Cert Valid period: 1461826791-4615426791
> >>> > > X.509: Cert Signature: rsa + sha512
> >>> > > X.509: ==>x509_check_signature()
> >>> > > X.509: ==>x509_get_sig_params()
> >>> > > X.509: <==x509_get_sig_params() = 0
> >>> > > PKEY: ==>public_key_verify_signature()
> >>> > > X.509: Cert Verification: -2
> >> > 
> >> > Hmmm...  Okay, the only ways out of public_key_verify_signature() without
> >> > printing a leaving message are for snprintf() to overrun (which would 
> >> > return
> >> > error -22) or for crypto_alloc_akcipher() to have failed; everything 
> >> > else must
> >> > go through the kleave() at the pr_devel() at the bottom of the function.
> >> > 
> >> > Can you stick:
> >> > 
> >> >  pr_devel("ALGO: %s\n", alg_name);
> >> > 
> >> > immediately before this line:
> >> > 
> >> >  tfm = crypto_alloc_akcipher(alg_name, 0, 0);
> >> > 
> >> > and try it again?
> > PKEY: ALGO: pkcs1pad(rsa,sha512)
> 
> I think the problem is that pkcs1pad template needs CRYPTO_MANAGER, but
> your configuration doesn't enable CRYPTO_MANAGER. Could you try this
> please:
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 93a1fdc..1d33beb 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -96,6 +96,7 @@ config CRYPTO_AKCIPHER
>  config CRYPTO_RSA
>   tristate "RSA algorithm"
>   select CRYPTO_AKCIPHER
> + select CRYPTO_MANAGER
>   select MPILIB
>   select ASN1
>   help

Yep, that does indeed make everything work again.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

[Jamie Heilman]

Tadeusz Struk wrote:
> On 05/03/2016 07:26 PM, Jamie Heilman wrote:
> >>> Alrighty, presumably relevant bits:
> >>> > >
> >>> > > X.509: Cert Issuer: Build time autogenerated kernel key
> >>> > > X.509: Cert Subject: Build time autogenerated kernel key
> >>> > > X.509: Cert Key Algo: rsa
> >>> > > X.509: Cert Valid period: 1461826791-4615426791
> >>> > > X.509: Cert Signature: rsa + sha512
> >>> > > X.509: ==>x509_check_signature()
> >>> > > X.509: ==>x509_get_sig_params()
> >>> > > X.509: <==x509_get_sig_params() = 0
> >>> > > PKEY: ==>public_key_verify_signature()
> >>> > > X.509: Cert Verification: -2
> >> > 
> >> > Hmmm...  Okay, the only ways out of public_key_verify_signature() without
> >> > printing a leaving message are for snprintf() to overrun (which would 
> >> > return
> >> > error -22) or for crypto_alloc_akcipher() to have failed; everything 
> >> > else must
> >> > go through the kleave() at the pr_devel() at the bottom of the function.
> >> > 
> >> > Can you stick:
> >> > 
> >> >  pr_devel("ALGO: %s\n", alg_name);
> >> > 
> >> > immediately before this line:
> >> > 
> >> >  tfm = crypto_alloc_akcipher(alg_name, 0, 0);
> >> > 
> >> > and try it again?
> > PKEY: ALGO: pkcs1pad(rsa,sha512)
> 
> I think the problem is that pkcs1pad template needs CRYPTO_MANAGER, but
> your configuration doesn't enable CRYPTO_MANAGER. Could you try this
> please:
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 93a1fdc..1d33beb 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -96,6 +96,7 @@ config CRYPTO_AKCIPHER
>  config CRYPTO_RSA
>   tristate "RSA algorithm"
>   select CRYPTO_AKCIPHER
> + select CRYPTO_MANAGER
>   select MPILIB
>   select ASN1
>   help

Yep, that does indeed make everything work again.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Re: [RFC v6 1/3] gpio: dt-bindings: add wd,mbl-gpio bindings

[Christian Lamparter]

On Tuesday, May 03, 2016 09:22:10 PM Rob Herring wrote:
> On Sun, May 01, 2016 at 02:18:37PM +0200, Christian Lamparter wrote:
> > This patch adds the device tree bindings for the Western Digital's
> > MyBook Live memory-mapped GPIO controllers.
> > 
> > The gpios will be supported by gpio-mmio code of the
> > GPIO generic library.
> > 
> > +++ b/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
> > @@ -0,0 +1,38 @@
> > +Bindings for the Western Digital's MyBook Live memory-mapped GPIO 
> > controllers.
> 
> Are these really product level GPIOs rather than some SOC's GPIOs 
> (APM?)?
> 
Ah, that's a good point. 

In a nutshell: The APM82181 SoC has two proper/normal GPIO controllers
which have a dt-binding and a kernel driver ready to go.
However Western Digital went with their own GPIO controller for
the MyBook Live [7].

Long version:
I know this SoC does have proper GPIO controllers [0].
For reference: I've helped making a OpenWRT port for the Cisco Meraki MR24
which uses it/them [1], [2]. Here's the GPIO extract from the MR24 DTS [3]:

--- MR24 DTS ---
GPIO0: gpio@ef600b00 {
compatible = "ibm,ppc4xx-gpio";
   reg = <0xef600b00 0x0048>; 
   #gpio-cells = <2>;
   gpio-controller;
};
--- snap ---

The driver for the "ibm,ppc4xx-gpio" is located under: 
arch/powerpc/sysdev/ppc4xx_gpio.c [4].
I can't find a dt binding text for it, if you want I can write one >later<.
The "ppc4xx" moniker is a strong indication that these GPIO controllers 
were carried over from the ppc46x/44x/40x series. 
The address (but not the range): 0x0004 ef600b00 does match with the
System Memory Map of the PPC460EX (See GPIO0 Controller on page 8 [5]).

Now for the MyBook Live: The GPIO situation is completely different.
Unlike the MR24, there are two GPIOs. The first one is on address
0x4e000. It drives the 3-color LED, Ethernet PHY Reset, USB-Core Power,
SATA Port0 and Port1 Power, NOR Flash Switch and the reset button driver.

The second GPIO only has one input connected. It BIT2 represents the state
of the reset button. It is located at 0x4e010. (The 0x4e0x address
puts the GPIO devices on the EBC (aka External Peripheral Bus Controller).
The EBC is normally used for "direct attachment of memory devices such as
ROM, SRAM, ...")

Western Digital did release their version of the GPIO driver: apollo3g-gpio.c
as part of their GPL sources [6]. (I found a mostly untouched version of the
apollo3g-gpio.c driver on github [7] (AFAICT he added the "porting to kernel 
3.2.64 by night_ghost@..."  string, other than that it should be pretty much
identical to what's inside the GPL.tar.gz).

So, I think the MyBook Live's GPIO controller is definitively something WD
cooked up by themselves in their labs. But I have no idea why they didn't
use the SoC's GPIO like Cisco... But sadly they really didn't...

Note:
If someone wants to look and play with this curiosity. I have a small
stack of DIY "MyBook Live kits", so I can sent one or two away easily.
For assembling a kit: one need a working 3.5" SATA HDD and a 12v 1.25A
PSU with a standard 5.5mm x 2.1mm power jack. I made a Debian image for 
development (download). So, if someone is interested: PM me.

Regards,
Christian

[0] 
[1] 
[2] 
[3] 

[4] 

[5] 
[6] 
[7] 


> +The Western Digital MyBook Live has two memory-mapped GPIO controllers.
> +Both GPIO controller only have a single 8-bit data register, where GPIO
> +state can be read and/or written.
> +
> +Required properties:
> + - compatible: should be "wd,mbl-gpio"
> + - reg-names: must contain
> + "dat" - data register
> + - reg: address + size pairs describing the GPIO register sets;
> + order must correspond with the order of entries in reg-names
> + - #gpio-cells: must be set to 2. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = active high
> + 1 = active low
> + - gpio-controller: Marks the device node as a gpio controller.
> +
> +Optional properties:
> + - no-output: GPIOs are read-only.
> +
> +Examples:
> + gpio0: gpio0@e000 {
> + compatible = "wd,mbl-gpio";
> + reg-names = "dat";
> + reg = <0xe000 0x1>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> +
> +   

Re: [RFC v6 1/3] gpio: dt-bindings: add wd,mbl-gpio bindings

[Christian Lamparter]

On Tuesday, May 03, 2016 09:22:10 PM Rob Herring wrote:
> On Sun, May 01, 2016 at 02:18:37PM +0200, Christian Lamparter wrote:
> > This patch adds the device tree bindings for the Western Digital's
> > MyBook Live memory-mapped GPIO controllers.
> > 
> > The gpios will be supported by gpio-mmio code of the
> > GPIO generic library.
> > 
> > +++ b/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
> > @@ -0,0 +1,38 @@
> > +Bindings for the Western Digital's MyBook Live memory-mapped GPIO 
> > controllers.
> 
> Are these really product level GPIOs rather than some SOC's GPIOs 
> (APM?)?
> 
Ah, that's a good point. 

In a nutshell: The APM82181 SoC has two proper/normal GPIO controllers
which have a dt-binding and a kernel driver ready to go.
However Western Digital went with their own GPIO controller for
the MyBook Live [7].

Long version:
I know this SoC does have proper GPIO controllers [0].
For reference: I've helped making a OpenWRT port for the Cisco Meraki MR24
which uses it/them [1], [2]. Here's the GPIO extract from the MR24 DTS [3]:

--- MR24 DTS ---
GPIO0: gpio@ef600b00 {
compatible = "ibm,ppc4xx-gpio";
   reg = <0xef600b00 0x0048>; 
   #gpio-cells = <2>;
   gpio-controller;
};
--- snap ---

The driver for the "ibm,ppc4xx-gpio" is located under: 
arch/powerpc/sysdev/ppc4xx_gpio.c [4].
I can't find a dt binding text for it, if you want I can write one >later<.
The "ppc4xx" moniker is a strong indication that these GPIO controllers 
were carried over from the ppc46x/44x/40x series. 
The address (but not the range): 0x0004 ef600b00 does match with the
System Memory Map of the PPC460EX (See GPIO0 Controller on page 8 [5]).

Now for the MyBook Live: The GPIO situation is completely different.
Unlike the MR24, there are two GPIOs. The first one is on address
0x4e000. It drives the 3-color LED, Ethernet PHY Reset, USB-Core Power,
SATA Port0 and Port1 Power, NOR Flash Switch and the reset button driver.

The second GPIO only has one input connected. It BIT2 represents the state
of the reset button. It is located at 0x4e010. (The 0x4e0x address
puts the GPIO devices on the EBC (aka External Peripheral Bus Controller).
The EBC is normally used for "direct attachment of memory devices such as
ROM, SRAM, ...")

Western Digital did release their version of the GPIO driver: apollo3g-gpio.c
as part of their GPL sources [6]. (I found a mostly untouched version of the
apollo3g-gpio.c driver on github [7] (AFAICT he added the "porting to kernel 
3.2.64 by night_ghost@..."  string, other than that it should be pretty much
identical to what's inside the GPL.tar.gz).

So, I think the MyBook Live's GPIO controller is definitively something WD
cooked up by themselves in their labs. But I have no idea why they didn't
use the SoC's GPIO like Cisco... But sadly they really didn't...

Note:
If someone wants to look and play with this curiosity. I have a small
stack of DIY "MyBook Live kits", so I can sent one or two away easily.
For assembling a kit: one need a working 3.5" SATA HDD and a 12v 1.25A
PSU with a standard 5.5mm x 2.1mm power jack. I made a Debian image for 
development (download). So, if someone is interested: PM me.

Regards,
Christian

[0] 
[1] 
[2] 
[3] 

[4] 

[5] 
[6] 
[7] 


> +The Western Digital MyBook Live has two memory-mapped GPIO controllers.
> +Both GPIO controller only have a single 8-bit data register, where GPIO
> +state can be read and/or written.
> +
> +Required properties:
> + - compatible: should be "wd,mbl-gpio"
> + - reg-names: must contain
> + "dat" - data register
> + - reg: address + size pairs describing the GPIO register sets;
> + order must correspond with the order of entries in reg-names
> + - #gpio-cells: must be set to 2. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = active high
> + 1 = active low
> + - gpio-controller: Marks the device node as a gpio controller.
> +
> +Optional properties:
> + - no-output: GPIOs are read-only.
> +
> +Examples:
> + gpio0: gpio0@e000 {
> + compatible = "wd,mbl-gpio";
> + reg-names = "dat";
> + reg = <0xe000 0x1>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> +
> +   

Re: [GIT PULL for v4.6-rc1] media updates

[Stefan Lippers-Hollmann]

Hi

On 2016-05-03, Linus Torvalds wrote:
> On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann  wrote:
> > Hi
> > [...]  
> >> Mauro Carvalho Chehab (95):  
> > [...]  
> >>   [media] use v4l2_mc_usb_media_device_init() on most USB devices  
> > [...]
> >
> > This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each
> > equipped with a TeVii s480 (dvb_usb_dw2102) DVB-S2 card, for me (kernel
> > v4.5.3-rc1 is fine):  
> 
> From the oops it looks like the "->prev" pointer in one of the list
> heads in 'mdev' is NULL.
> 
> > [5.041915] BUG: unable to handle kernel NULL pointer dereference at 
> >   (null)
> > [5.041921] IP: [] media_gobj_create+0xb8/0x100 
> > [media]  
> 
> I can't tell *which* list head it is, but it looks like there's a
> missing call to media_device_init() which is what should have
> initialized those list heads.
> 
> Of course, maybe that list pointer got initialized but then
> overwritten by NULL for some other reason.

Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
aren't needed/ loaded on my system) crude revert avoids the problem for 
me on v4.6-rc6-113-g83858a7.

--- a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
@@ -107,7 +107,15 @@ static int dvb_usb_media_device_init(str
if (!mdev)
return -ENOMEM;
 
-   media_device_usb_init(mdev, udev, d->desc->name);
+   mdev->dev = >dev;
+   strlcpy(mdev->model, d->desc->name, sizeof(mdev->model));
+   if (udev->serial)
+   strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial));
+   strcpy(mdev->bus_info, udev->devpath);
+   mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
+   mdev->driver_version = LINUX_VERSION_CODE;
+
+   media_device_init(mdev);
 
dvb_register_media_controller(>dvb_adap, mdev);
 
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -412,7 +412,15 @@ static int dvb_usbv2_media_device_init(s
if (!mdev)
return -ENOMEM;
 
-   media_device_usb_init(mdev, udev, d->name);
+   mdev->dev = >dev;
+   strlcpy(mdev->model, d->name, sizeof(mdev->model));
+   if (udev->serial)
+   strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial));
+   strcpy(mdev->bus_info, udev->devpath);
+   mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
+   mdev->driver_version = LINUX_VERSION_CODE;
+
+   media_device_init(mdev);
 
dvb_register_media_controller(>dvb_adap, mdev);
 
While testing this, I also noticed that not just the dvb_usb based
dvb_usb_dw2102 is affected, but that also the dvb_usb_v2 based rtl2832
triggers this Oops on its own (given that just reverting 
drivers/media/usb/dvb-usb/dvb-usb-dvb.c wasn't enough).

Regards
Stefan Lippers-Hollmann

Re: [GIT PULL for v4.6-rc1] media updates

[Stefan Lippers-Hollmann]

Hi

On 2016-05-03, Linus Torvalds wrote:
> On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann  wrote:
> > Hi
> > [...]  
> >> Mauro Carvalho Chehab (95):  
> > [...]  
> >>   [media] use v4l2_mc_usb_media_device_init() on most USB devices  
> > [...]
> >
> > This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each
> > equipped with a TeVii s480 (dvb_usb_dw2102) DVB-S2 card, for me (kernel
> > v4.5.3-rc1 is fine):  
> 
> From the oops it looks like the "->prev" pointer in one of the list
> heads in 'mdev' is NULL.
> 
> > [5.041915] BUG: unable to handle kernel NULL pointer dereference at 
> >   (null)
> > [5.041921] IP: [] media_gobj_create+0xb8/0x100 
> > [media]  
> 
> I can't tell *which* list head it is, but it looks like there's a
> missing call to media_device_init() which is what should have
> initialized those list heads.
> 
> Of course, maybe that list pointer got initialized but then
> overwritten by NULL for some other reason.

Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
aren't needed/ loaded on my system) crude revert avoids the problem for 
me on v4.6-rc6-113-g83858a7.

--- a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
@@ -107,7 +107,15 @@ static int dvb_usb_media_device_init(str
if (!mdev)
return -ENOMEM;
 
-   media_device_usb_init(mdev, udev, d->desc->name);
+   mdev->dev = >dev;
+   strlcpy(mdev->model, d->desc->name, sizeof(mdev->model));
+   if (udev->serial)
+   strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial));
+   strcpy(mdev->bus_info, udev->devpath);
+   mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
+   mdev->driver_version = LINUX_VERSION_CODE;
+
+   media_device_init(mdev);
 
dvb_register_media_controller(>dvb_adap, mdev);
 
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -412,7 +412,15 @@ static int dvb_usbv2_media_device_init(s
if (!mdev)
return -ENOMEM;
 
-   media_device_usb_init(mdev, udev, d->name);
+   mdev->dev = >dev;
+   strlcpy(mdev->model, d->name, sizeof(mdev->model));
+   if (udev->serial)
+   strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial));
+   strcpy(mdev->bus_info, udev->devpath);
+   mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
+   mdev->driver_version = LINUX_VERSION_CODE;
+
+   media_device_init(mdev);
 
dvb_register_media_controller(>dvb_adap, mdev);
 
While testing this, I also noticed that not just the dvb_usb based
dvb_usb_dw2102 is affected, but that also the dvb_usb_v2 based rtl2832
triggers this Oops on its own (given that just reverting 
drivers/media/usb/dvb-usb/dvb-usb-dvb.c wasn't enough).

Regards
Stefan Lippers-Hollmann

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

[Tadeusz Struk]

On 05/03/2016 07:26 PM, Jamie Heilman wrote:
>>> Alrighty, presumably relevant bits:
>>> > >
>>> > > X.509: Cert Issuer: Build time autogenerated kernel key
>>> > > X.509: Cert Subject: Build time autogenerated kernel key
>>> > > X.509: Cert Key Algo: rsa
>>> > > X.509: Cert Valid period: 1461826791-4615426791
>>> > > X.509: Cert Signature: rsa + sha512
>>> > > X.509: ==>x509_check_signature()
>>> > > X.509: ==>x509_get_sig_params()
>>> > > X.509: <==x509_get_sig_params() = 0
>>> > > PKEY: ==>public_key_verify_signature()
>>> > > X.509: Cert Verification: -2
>> > 
>> > Hmmm...  Okay, the only ways out of public_key_verify_signature() without
>> > printing a leaving message are for snprintf() to overrun (which would 
>> > return
>> > error -22) or for crypto_alloc_akcipher() to have failed; everything else 
>> > must
>> > go through the kleave() at the pr_devel() at the bottom of the function.
>> > 
>> > Can you stick:
>> > 
>> >pr_devel("ALGO: %s\n", alg_name);
>> > 
>> > immediately before this line:
>> > 
>> >tfm = crypto_alloc_akcipher(alg_name, 0, 0);
>> > 
>> > and try it again?
> PKEY: ALGO: pkcs1pad(rsa,sha512)

I think the problem is that pkcs1pad template needs CRYPTO_MANAGER, but
your configuration doesn't enable CRYPTO_MANAGER. Could you try this
please:

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 93a1fdc..1d33beb 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -96,6 +96,7 @@ config CRYPTO_AKCIPHER
 config CRYPTO_RSA
tristate "RSA algorithm"
select CRYPTO_AKCIPHER
+   select CRYPTO_MANAGER
select MPILIB
select ASN1
help

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

[Tadeusz Struk]

On 05/03/2016 07:26 PM, Jamie Heilman wrote:
>>> Alrighty, presumably relevant bits:
>>> > >
>>> > > X.509: Cert Issuer: Build time autogenerated kernel key
>>> > > X.509: Cert Subject: Build time autogenerated kernel key
>>> > > X.509: Cert Key Algo: rsa
>>> > > X.509: Cert Valid period: 1461826791-4615426791
>>> > > X.509: Cert Signature: rsa + sha512
>>> > > X.509: ==>x509_check_signature()
>>> > > X.509: ==>x509_get_sig_params()
>>> > > X.509: <==x509_get_sig_params() = 0
>>> > > PKEY: ==>public_key_verify_signature()
>>> > > X.509: Cert Verification: -2
>> > 
>> > Hmmm...  Okay, the only ways out of public_key_verify_signature() without
>> > printing a leaving message are for snprintf() to overrun (which would 
>> > return
>> > error -22) or for crypto_alloc_akcipher() to have failed; everything else 
>> > must
>> > go through the kleave() at the pr_devel() at the bottom of the function.
>> > 
>> > Can you stick:
>> > 
>> >pr_devel("ALGO: %s\n", alg_name);
>> > 
>> > immediately before this line:
>> > 
>> >tfm = crypto_alloc_akcipher(alg_name, 0, 0);
>> > 
>> > and try it again?
> PKEY: ALGO: pkcs1pad(rsa,sha512)

I think the problem is that pkcs1pad template needs CRYPTO_MANAGER, but
your configuration doesn't enable CRYPTO_MANAGER. Could you try this
please:

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 93a1fdc..1d33beb 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -96,6 +96,7 @@ config CRYPTO_AKCIPHER
 config CRYPTO_RSA
tristate "RSA algorithm"
select CRYPTO_AKCIPHER
+   select CRYPTO_MANAGER
select MPILIB
select ASN1
help

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

[David Miller]

From: Benjamin Herrenschmidt 
Date: Wed, 04 May 2016 10:37:40 +1000

> On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
>> BenH and DavidM,
>> Are you ok to let /proc/bus/pci/devices to expose resource value
>> instead of
>> BAR value?
>> powerpc already expose MMIO as resource value, but still keep IO as
>> BAR value?
>> 
>> Or can we just dump /proc/bus/pci support from now?
> 
> The problem tends to be old Xserver expectations...
> 
> That stuff has been a can of worms over the years and we did things in
> the kernel to work around X limitations. I'm not that keen on touching
> /proc at all in that regard. Leave it there do what it does today, it's
> a user visible ABI, don't change it.

I agree with Ben, whatever procfs is exporting in the past is what
the Xserver and other things expect on sparc64 and therefore is a
user facing ABI that can't be changed.

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

[David Miller]

From: Benjamin Herrenschmidt 
Date: Wed, 04 May 2016 10:37:40 +1000

> On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
>> BenH and DavidM,
>> Are you ok to let /proc/bus/pci/devices to expose resource value
>> instead of
>> BAR value?
>> powerpc already expose MMIO as resource value, but still keep IO as
>> BAR value?
>> 
>> Or can we just dump /proc/bus/pci support from now?
> 
> The problem tends to be old Xserver expectations...
> 
> That stuff has been a can of worms over the years and we did things in
> the kernel to work around X limitations. I'm not that keen on touching
> /proc at all in that regard. Leave it there do what it does today, it's
> a user visible ABI, don't change it.

I agree with Ben, whatever procfs is exporting in the past is what
the Xserver and other things expect on sparc64 and therefore is a
user facing ABI that can't be changed.

Re: [PATCH] crypto: algif_skcipher: replace sg++ with sg_next()

[Herbert Xu]

Muhammad Falak R Wani  wrote:
> Never use sg++, always use sg = sg_next(sg). Scatterlist entries can
> be combined if the memory is contiguous but sg++ won't know about
> that. It sure would run on the slower side.
> But regardless, sg++ should never be used, only sg_next is safe.
> 
> Signed-off-by: Muhammad Falak R Wani 

No please the only difference between sg_next and sg++ is chaining,
which is irrelevant here.

Patch rejected.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: algif_skcipher: replace sg++ with sg_next()

[Herbert Xu]

Muhammad Falak R Wani  wrote:
> Never use sg++, always use sg = sg_next(sg). Scatterlist entries can
> be combined if the memory is contiguous but sg++ won't know about
> that. It sure would run on the slower side.
> But regardless, sg++ should never be used, only sg_next is safe.
> 
> Signed-off-by: Muhammad Falak R Wani 

No please the only difference between sg_next and sg++ is chaining,
which is irrelevant here.

Patch rejected.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v7 1/6] Shared library support

[Masahiro Yamada]

Hi Emese,


2016-05-04 6:29 GMT+09:00 Emese Revfy :
> On Tue, 3 May 2016 11:00:56 +0900
> Masahiro Yamada  wrote:
>
> Hi,
>
>> # Compile .c file, create position independent .o file
>> # host-cxxshobjs -> .o
>> quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@
>>   cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
>>$(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
>>$(call if_changed_dep,host-cxxshobjs)
>>
>>
>>
>>
>> We generally use HOSTCC to compile *.c files,
>> and HOSTCXX to compile *.cc files.
>>
>>
>> But, here, you mention to use HOSTCXX to compile .c files
>> such as cyc_complexity_plugin.c, sancov_plugin.c, etc.
>>
>> This is not straight-forward.  It is worthwhile to comment the reason.
>
> I wrote a comment about it here:
> https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/74f6343a7f13c071e00c417332051e25f15009ea
>



+# Note that plugin capable gcc versions can be either C or C++ based
+# therefore plugin source files have to be compilable in both C and C++ mode.
+# This is why a C++ compiler is invoked on a .c file.

Thanks.

Please let me confirm if I understood correctly.


We generally have to do something with the name-space conflict
(with 'extern "C"') in the mixture of C/C++.

Depending on the GCC version,
GCC-plugin-related libraries could be built for C or C++.

So, we need to check the GCC version and choose correct one
from C or C++.


Am I right?


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v7 1/6] Shared library support

[Masahiro Yamada]

Hi Emese,


2016-05-04 6:29 GMT+09:00 Emese Revfy :
> On Tue, 3 May 2016 11:00:56 +0900
> Masahiro Yamada  wrote:
>
> Hi,
>
>> # Compile .c file, create position independent .o file
>> # host-cxxshobjs -> .o
>> quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@
>>   cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
>>$(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
>>$(call if_changed_dep,host-cxxshobjs)
>>
>>
>>
>>
>> We generally use HOSTCC to compile *.c files,
>> and HOSTCXX to compile *.cc files.
>>
>>
>> But, here, you mention to use HOSTCXX to compile .c files
>> such as cyc_complexity_plugin.c, sancov_plugin.c, etc.
>>
>> This is not straight-forward.  It is worthwhile to comment the reason.
>
> I wrote a comment about it here:
> https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/74f6343a7f13c071e00c417332051e25f15009ea
>



+# Note that plugin capable gcc versions can be either C or C++ based
+# therefore plugin source files have to be compilable in both C and C++ mode.
+# This is why a C++ compiler is invoked on a .c file.

Thanks.

Please let me confirm if I understood correctly.


We generally have to do something with the name-space conflict
(with 'extern "C"') in the mixture of C/C++.

Depending on the GCC version,
GCC-plugin-related libraries could be built for C or C++.

So, we need to check the GCC version and choose correct one
from C or C++.


Am I right?


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] mmc: omap: Use dma_request_chan() for requesting DMA channel

[Peter Ujfalusi]

On 05/03/2016 11:00 PM, Peter Ujfalusi wrote:
>>> @@ -1382,29 +1379,31 @@ static int mmc_omap_probe(struct platform_device 
>>> *pdev)
>>> goto err_free_iclk;
>>> }
>>>
>>> -   dma_cap_zero(mask);
>>> -   dma_cap_set(DMA_SLAVE, mask);
>>> -
>>> host->dma_tx_burst = -1;
>>> host->dma_rx_burst = -1;
>>>
>>> -   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
>>> -   if (res)
>>> -   sig = res->start;
>>> -   host->dma_tx = dma_request_slave_channel_compat(mask,
>>> -   omap_dma_filter_fn, , >dev, "tx");
>>> -   if (!host->dma_tx)
>>> -   dev_warn(host->dev, "unable to obtain TX DMA engine channel 
>>> %u\n",
>>> -   sig);
>>> -
>>> -   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
>>> -   if (res)
>>> -   sig = res->start;
>>> -   host->dma_rx = dma_request_slave_channel_compat(mask,
>>> -   omap_dma_filter_fn, , >dev, "rx");
>>> -   if (!host->dma_rx)
>>> -   dev_warn(host->dev, "unable to obtain RX DMA engine channel 
>>> %u\n",
>>> -   sig);
>>> +   host->dma_tx = dma_request_chan(>dev, "tx");
>>> +   if (IS_ERR(host->dma_tx)) {
>>> +   ret = PTR_ERR(host->dma_tx);
>>> +   if (ret == -EPROBE_DEFER)
>>> +   goto err_free_iclk;
> 
> and one clk_put(host->fclk) is missing from here.
> 
>>> +
>>> +   host->dma_tx = NULL;
>>
>> Instead of setting this to NULL, let's keep its value and later check
>> it with IS_ERR() when needed.
> 
> I thought about it, but decided against without need to have changes in other
> places in the driver.

This sentence does not make too much sense ;) Let's try it again:
So, I have considered to use PTR_ERR in the driver for the DMA channel, but I
wanted to avoid too broad changes in the driver. Keeping the ERR_PTR would
bring no runtime benefit since we only care if we have channel or not.

-- 
Péter

Re: [PATCH] mmc: omap: Use dma_request_chan() for requesting DMA channel

[Peter Ujfalusi]

On 05/03/2016 11:00 PM, Peter Ujfalusi wrote:
>>> @@ -1382,29 +1379,31 @@ static int mmc_omap_probe(struct platform_device 
>>> *pdev)
>>> goto err_free_iclk;
>>> }
>>>
>>> -   dma_cap_zero(mask);
>>> -   dma_cap_set(DMA_SLAVE, mask);
>>> -
>>> host->dma_tx_burst = -1;
>>> host->dma_rx_burst = -1;
>>>
>>> -   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
>>> -   if (res)
>>> -   sig = res->start;
>>> -   host->dma_tx = dma_request_slave_channel_compat(mask,
>>> -   omap_dma_filter_fn, , >dev, "tx");
>>> -   if (!host->dma_tx)
>>> -   dev_warn(host->dev, "unable to obtain TX DMA engine channel 
>>> %u\n",
>>> -   sig);
>>> -
>>> -   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
>>> -   if (res)
>>> -   sig = res->start;
>>> -   host->dma_rx = dma_request_slave_channel_compat(mask,
>>> -   omap_dma_filter_fn, , >dev, "rx");
>>> -   if (!host->dma_rx)
>>> -   dev_warn(host->dev, "unable to obtain RX DMA engine channel 
>>> %u\n",
>>> -   sig);
>>> +   host->dma_tx = dma_request_chan(>dev, "tx");
>>> +   if (IS_ERR(host->dma_tx)) {
>>> +   ret = PTR_ERR(host->dma_tx);
>>> +   if (ret == -EPROBE_DEFER)
>>> +   goto err_free_iclk;
> 
> and one clk_put(host->fclk) is missing from here.
> 
>>> +
>>> +   host->dma_tx = NULL;
>>
>> Instead of setting this to NULL, let's keep its value and later check
>> it with IS_ERR() when needed.
> 
> I thought about it, but decided against without need to have changes in other
> places in the driver.

This sentence does not make too much sense ;) Let's try it again:
So, I have considered to use PTR_ERR in the driver for the DMA channel, but I
wanted to avoid too broad changes in the driver. Keeping the ERR_PTR would
bring no runtime benefit since we only care if we have channel or not.

-- 
Péter

[PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

[Rajesh Bhagat]

On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
to be able to do DMA allocations, so use the of_dma_configure() helper
to populate the dma properties and assign an appropriate dma_ops.

Signed-off-by: Rajesh Bhagat 
Reviewed-by: Yang-Leo Li 
---
 drivers/usb/dwc3/host.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..4d5b783 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 #include "core.h"
 
@@ -32,6 +33,9 @@ int dwc3_host_init(struct dwc3 *dwc)
return -ENOMEM;
}
 
+   if (IS_ENABLED(CONFIG_OF) && dwc->dev->of_node)
+   of_dma_configure(>dev, dwc->dev->of_node);
+
dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
 
xhci->dev.parent= dwc->dev;
-- 
2.6.2.198.g614a2ac

[PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

[Rajesh Bhagat]

On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
to be able to do DMA allocations, so use the of_dma_configure() helper
to populate the dma properties and assign an appropriate dma_ops.

Signed-off-by: Rajesh Bhagat 
Reviewed-by: Yang-Leo Li 
---
 drivers/usb/dwc3/host.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..4d5b783 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 #include "core.h"
 
@@ -32,6 +33,9 @@ int dwc3_host_init(struct dwc3 *dwc)
return -ENOMEM;
}
 
+   if (IS_ENABLED(CONFIG_OF) && dwc->dev->of_node)
+   of_dma_configure(>dev, dwc->dev->of_node);
+
dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
 
xhci->dev.parent= dwc->dev;
-- 
2.6.2.198.g614a2ac

[v9, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Yangbo Lu]

Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.

Signed-off-by: Yangbo Lu 
Acked-by: Wolfram Sang 
Acked-by: Stephen Boyd 
Acked-by: Scott Wood 
Acked-by: Joerg Roedel 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
 drivers/clk/clk-qoriq.c   | 3 +--
 drivers/i2c/busses/i2c-mpc.c  | 2 +-
 drivers/iommu/fsl_pamu.c  | 3 +--
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
 6 files changed, 7 insertions(+), 9 deletions(-)
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 _GLOBAL(__e500_icache_setup)
mfspr   r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1148,8 +1149,6 @@ bad_args:
 }
 
 #ifdef CONFIG_PPC
-#include 
-
 static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
 #include "fsl_pamu.h"
 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 /* define indexes for each operation mapping scenario */
 #define OMI_QMAN0x00
 #define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #ifdef CONFIG_PPC
 #include 
-#include 
 #endif
 #include 
 #include 
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
  * (at your option) any later version.
  */
 
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
 
 #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
 #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
-- 
2.1.0.27.g96db324

[v9, 0/7] Fix eSDHC host version register bug

[Yangbo Lu]

This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.

So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.

Yangbo Lu (7):
  Documentation: DT: update Freescale DCFG compatible
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc directory
  powerpc/fsl: move mpc85xx.h to include/linux/fsl
  MAINTAINERS: add entry for Freescale SoC driver
  mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

 Documentation/devicetree/bindings/arm/fsl.txt  |   6 +-
 .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
 MAINTAINERS|  11 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
 arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
 drivers/clk/clk-qoriq.c|   3 +-
 drivers/i2c/busses/i2c-mpc.c   |   2 +-
 drivers/iommu/fsl_pamu.c   |   3 +-
 drivers/mmc/host/Kconfig   |   1 +
 drivers/mmc/host/sdhci-of-esdhc.c  |  23 
 drivers/net/ethernet/freescale/gianfar.c   |   2 +-
 drivers/soc/Kconfig|   2 +-
 drivers/soc/fsl/Kconfig|   8 ++
 drivers/soc/fsl/Makefile   |   1 +
 drivers/soc/fsl/guts.c | 119 +++
 include/linux/fsl/guts.h   | 126 +
 .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
 17 files changed, 262 insertions(+), 60 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

-- 
2.1.0.27.g96db324

[v9, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Yangbo Lu]

Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.

Signed-off-by: Yangbo Lu 
Acked-by: Wolfram Sang 
Acked-by: Stephen Boyd 
Acked-by: Scott Wood 
Acked-by: Joerg Roedel 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
 drivers/clk/clk-qoriq.c   | 3 +--
 drivers/i2c/busses/i2c-mpc.c  | 2 +-
 drivers/iommu/fsl_pamu.c  | 3 +--
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
 6 files changed, 7 insertions(+), 9 deletions(-)
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 _GLOBAL(__e500_icache_setup)
mfspr   r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1148,8 +1149,6 @@ bad_args:
 }
 
 #ifdef CONFIG_PPC
-#include 
-
 static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
 #include "fsl_pamu.h"
 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 /* define indexes for each operation mapping scenario */
 #define OMI_QMAN0x00
 #define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #ifdef CONFIG_PPC
 #include 
-#include 
 #endif
 #include 
 #include 
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
  * (at your option) any later version.
  */
 
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
 
 #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
 #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
-- 
2.1.0.27.g96db324

[v9, 0/7] Fix eSDHC host version register bug

[Yangbo Lu]

This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.

So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.

Yangbo Lu (7):
  Documentation: DT: update Freescale DCFG compatible
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc directory
  powerpc/fsl: move mpc85xx.h to include/linux/fsl
  MAINTAINERS: add entry for Freescale SoC driver
  mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

 Documentation/devicetree/bindings/arm/fsl.txt  |   6 +-
 .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
 MAINTAINERS|  11 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
 arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
 drivers/clk/clk-qoriq.c|   3 +-
 drivers/i2c/busses/i2c-mpc.c   |   2 +-
 drivers/iommu/fsl_pamu.c   |   3 +-
 drivers/mmc/host/Kconfig   |   1 +
 drivers/mmc/host/sdhci-of-esdhc.c  |  23 
 drivers/net/ethernet/freescale/gianfar.c   |   2 +-
 drivers/soc/Kconfig|   2 +-
 drivers/soc/fsl/Kconfig|   8 ++
 drivers/soc/fsl/Makefile   |   1 +
 drivers/soc/fsl/guts.c | 119 +++
 include/linux/fsl/guts.h   | 126 +
 .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
 17 files changed, 262 insertions(+), 60 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

-- 
2.1.0.27.g96db324

[v9, 6/7] MAINTAINERS: add entry for Freescale SoC driver

[Yangbo Lu]

Add maintainer entry for Freescale SoC driver including
the QE library and the GUTS driver now. Also add maintainer
for QE library.

Signed-off-by: Yangbo Lu 
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
---
 MAINTAINERS | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d1..ce91db7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4622,9 +4622,18 @@ F:   drivers/net/ethernet/freescale/fec_ptp.c
 F: drivers/net/ethernet/freescale/fec.h
 F: Documentation/devicetree/bindings/net/fsl-fec.txt
 
+FREESCALE SOC DRIVER
+M: Scott Wood 
+L: linuxppc-...@lists.ozlabs.org
+L: linux-arm-ker...@lists.infradead.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
 FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao 
 L: linuxppc-...@lists.ozlabs.org
-S: Orphan
+S: Maintained
 F: drivers/soc/fsl/qe/
 F: include/soc/fsl/*qe*.h
 F: include/soc/fsl/*ucc*.h
-- 
2.1.0.27.g96db324

[v9, 2/7] ARM64: dts: ls2080a: add device configuration node

[Yangbo Lu]

Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.

Signed-off-by: Yangbo Lu 
Acked-by: Scott Wood 
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <>;
};
 
+   dcfg: dcfg@1e0 {
+   compatible = "fsl,ls2080a-dcfg", "syscon";
+   reg = <0x0 0x1e0 0x0 0x1>;
+   little-endian;
+   };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
-- 
2.1.0.27.g96db324

[v9, 6/7] MAINTAINERS: add entry for Freescale SoC driver

[Yangbo Lu]

Add maintainer entry for Freescale SoC driver including
the QE library and the GUTS driver now. Also add maintainer
for QE library.

Signed-off-by: Yangbo Lu 
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
---
 MAINTAINERS | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d1..ce91db7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4622,9 +4622,18 @@ F:   drivers/net/ethernet/freescale/fec_ptp.c
 F: drivers/net/ethernet/freescale/fec.h
 F: Documentation/devicetree/bindings/net/fsl-fec.txt
 
+FREESCALE SOC DRIVER
+M: Scott Wood 
+L: linuxppc-...@lists.ozlabs.org
+L: linux-arm-ker...@lists.infradead.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
 FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao 
 L: linuxppc-...@lists.ozlabs.org
-S: Orphan
+S: Maintained
 F: drivers/soc/fsl/qe/
 F: include/soc/fsl/*qe*.h
 F: include/soc/fsl/*ucc*.h
-- 
2.1.0.27.g96db324

[v9, 2/7] ARM64: dts: ls2080a: add device configuration node

[Yangbo Lu]

Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.

Signed-off-by: Yangbo Lu 
Acked-by: Scott Wood 
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <>;
};
 
+   dcfg: dcfg@1e0 {
+   compatible = "fsl,ls2080a-dcfg", "syscon";
+   reg = <0x0 0x1e0 0x0 0x1>;
+   little-endian;
+   };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
-- 
2.1.0.27.g96db324

[v9, 1/7] Documentation: DT: update Freescale DCFG compatible

[Yangbo Lu]

Update Freescale DCFG compatible with 'fsl,-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.

Signed-off-by: Yangbo Lu 
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
---
 Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt 
b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
 configuration and status for the device. Such as setting the secondary
 core start address and release the secondary core from holdoff and startup.
   Required properties:
-  - compatible: should be "fsl,ls1021a-dcfg"
+  - compatible: should be "fsl,-dcfg"
+Possible compatibles:
+   "fsl,ls1021a-dcfg"
+   "fsl,ls1043a-dcfg"
+   "fsl,ls2080a-dcfg"
   - reg : should contain base address and length of DCFG memory-mapped 
registers
 
 Example:
-- 
2.1.0.27.g96db324

[v9, 1/7] Documentation: DT: update Freescale DCFG compatible

[Yangbo Lu]

Update Freescale DCFG compatible with 'fsl,-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.

Signed-off-by: Yangbo Lu 
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
---
 Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt 
b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
 configuration and status for the device. Such as setting the secondary
 core start address and release the secondary core from holdoff and startup.
   Required properties:
-  - compatible: should be "fsl,ls1021a-dcfg"
+  - compatible: should be "fsl,-dcfg"
+Possible compatibles:
+   "fsl,ls1021a-dcfg"
+   "fsl,ls1043a-dcfg"
+   "fsl,ls2080a-dcfg"
   - reg : should contain base address and length of DCFG memory-mapped 
registers
 
 Example:
-- 
2.1.0.27.g96db324

[PATCH v3 06/12] documentation: Add scheduler/sched-avg.txt

[Yuyang Du]

This doc file has the program to generate the constants to compute
sched averages.

Signed-off-by: Yuyang Du 
---
 Documentation/scheduler/sched-avg.txt |   94 +
 1 file changed, 94 insertions(+)
 create mode 100644 Documentation/scheduler/sched-avg.txt

diff --git a/Documentation/scheduler/sched-avg.txt 
b/Documentation/scheduler/sched-avg.txt
new file mode 100644
index 000..45be4bd
--- /dev/null
+++ b/Documentation/scheduler/sched-avg.txt
@@ -0,0 +1,94 @@
+The following program is used to generate the constants for
+computing sched averages.
+
+==
+   C program (compile with -lm)
+==
+
+#include 
+#include 
+
+#define HALFLIFE 32
+#define SHIFT 32
+
+double y;
+
+void calc_decay_inv_multiply() {
+   int i;
+   unsigned int x;
+
+   printf("static const u32 __decay_inv_multiply_N[] = {");
+   for(i = 0; i < HALFLIFE; i++) {
+   x = ((1UL<<32)-1)*pow(y, i);
+
+   if (i % 6 == 0) printf("\n\t");
+   printf("0x%8x, ", x);
+   }
+   printf("\n};\n\n");
+}
+
+int sum = 1024;
+void calc_accumulated_sum() {
+   int i;
+
+   printf("static const u32 __accumulated_sum_N[] = {\n\t0,");
+   for(i = 1; i <= HALFLIFE; i++) {
+   if (i == 1)
+   sum *= y;
+   else
+   sum = sum*y + 1024*y;
+
+   if (i % 11 == 0) printf("\n\t");
+   printf("%5d,", sum);
+   }
+   printf("\n};\n\n");
+}
+
+int n = 1;
+/* first period */
+long max = 1024;
+
+void calc_converged_max() {
+   long last = 0, y_inv = ((1UL<<32)-1)*y;
+
+   for (; ; n++) {
+   if (n > 1)
+   max = ((max*y_inv)>>SHIFT) + 1024;
+   /*
+* This is the same as:
+* max = max*y + 1024;
+*/
+
+   if (last == max)
+   break;
+
+   last = max;
+   }
+   n--;
+   printf("#define SCHED_AVG_HALFLIFE %d\n", HALFLIFE);
+   printf("#define SCHED_AVG_MAX %ld\n", max);
+   printf("#define SCHED_AVG_MAX_N %d\n\n", n);
+}
+
+void calc_accumulated_sum_32() {
+   int i, x = sum;
+
+   printf("static const u32 __accumulated_sum_N32[] = {\n\t 0,");
+   for(i = 1; i <= n/HALFLIFE+1; i++) {
+   if (i > 1)
+   x = x/2 + sum;
+
+   if (i % 6 == 0) printf("\n\t");
+   printf("%6d,", x);
+   }
+   printf("\n};\n\n");
+}
+
+void main() {
+   y = pow(0.5, 1/(double)HALFLIFE);
+
+   calc_decay_inv_multiply();
+   calc_accumulated_sum();
+   calc_converged_max();
+   calc_accumulated_sum_32();
+}
-- 
1.7.9.5

[PATCH v3 07/12] sched/fair: Generalize the load/util averages resolution definition

[Yuyang Du]

Integer metric needs fixed point arithmetic. In sched/fair, a few
metrics, including weight, load, load_avg, util_avg, freq, and capacity,
may have different fixed point ranges.

In order to avoid errors relating to the fixed point range of these
metrics, we define a basic fixed point range, and then formalize all
metrics to base on the basic range.

The basic range is 1024. Further, one can recursively apply this basic
range to have larger range.

Pointed out by Ben Segall, weight (visible to user, e.g., NICE-0 has
1024) and load (e.g., NICE_0_LOAD) have independent ranges, but they
must be well calibrated.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h |   16 +---
 kernel/sched/fair.c   |4 
 kernel/sched/sched.h  |   15 ++-
 3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index ad9454d..33e7929 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -937,9 +937,19 @@ enum cpu_idle_type {
 };
 
 /*
+ * Integer metrics need fixed point arithmetic, e.g., sched/fair
+ * has a few: load, load_avg, util_avg, freq, and capacity.
+ *
+ * We define a basic fixed point arithmetic range, and then formalize
+ * all these metrics based on that basic range.
+ */
+# define SCHED_FIXEDPOINT_SHIFT10
+# define SCHED_FIXEDPOINT_SCALE(1L << SCHED_FIXEDPOINT_SHIFT)
+
+/*
  * Increase resolution of cpu_capacity calculations
  */
-#define SCHED_CAPACITY_SHIFT   10
+#define SCHED_CAPACITY_SHIFT   SCHED_FIXEDPOINT_SHIFT
 #define SCHED_CAPACITY_SCALE   (1L << SCHED_CAPACITY_SHIFT)
 
 /*
@@ -1205,8 +1215,8 @@ struct load_weight {
  * 1) load_avg factors frequency scaling into the amount of time that a
  * sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
  * aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency and cpu scaling into the amount of time
- * that a sched_entity is running on a CPU, in the range [0..SCHED_LOAD_SCALE].
+ * 2) util_avg factors frequency and cpu capacity scaling into the amount of 
time
+ * that a sched_entity is running on a CPU, in the range 
[0..SCHED_CAPACITY_SCALE].
  * For cfs_rq, it is the aggregated such times of all runnable and
  * blocked sched_entities.
  * The 64 bit load_sum can:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 495e5f0..1a61137 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2678,10 +2678,6 @@ __accumulate_sum(u32 periods, u32 period_contrib, u32 
remainder)
return contrib + remainder;
 }
 
-#if (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) != 10 || SCHED_CAPACITY_SHIFT 
!= 10
-#error "load tracking assumes 2^10 as unit"
-#endif
-
 #define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
 
 static __always_inline u32 accumulate_sum(u64 delta, struct sched_avg *sa,
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 69da6fc..996a137 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -54,18 +54,23 @@ static inline void cpu_load_update_active(struct rq 
*this_rq) { }
  * increased costs.
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
-# define SCHED_LOAD_RESOLUTION 10
-# define scale_load(w) ((w) << SCHED_LOAD_RESOLUTION)
-# define scale_load_down(w)((w) >> SCHED_LOAD_RESOLUTION)
+# define SCHED_LOAD_SHIFT  (SCHED_FIXEDPOINT_SHIFT + 
SCHED_FIXEDPOINT_SHIFT)
+# define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
+# define scale_load_down(w)((w) >> SCHED_FIXEDPOINT_SHIFT)
 #else
-# define SCHED_LOAD_RESOLUTION 0
+# define SCHED_LOAD_SHIFT  (SCHED_FIXEDPOINT_SHIFT)
 # define scale_load(w) (w)
 # define scale_load_down(w)(w)
 #endif
 
-#define SCHED_LOAD_SHIFT   (10 + SCHED_LOAD_RESOLUTION)
 #define SCHED_LOAD_SCALE   (1L << SCHED_LOAD_SHIFT)
 
+/*
+ * NICE_0's weight (visible to user) and its load (invisible to user) have
+ * independent ranges, but they should be well calibrated. We use scale_load()
+ * and scale_load_down(w) to convert between them, the following must be true:
+ * scale_load(sched_prio_to_weight[20]) == NICE_0_LOAD
+ */
 #define NICE_0_LOADSCHED_LOAD_SCALE
 #define NICE_0_SHIFT   SCHED_LOAD_SHIFT
 
-- 
1.7.9.5

[PATCH v3 05/12] sched/fair: Optimize __update_sched_avg()

[Yuyang Du]

__update_sched_avg() has these steps:

  1. add the remainder of the last incomplete period
  2. decay old sum
  3. accumulate new sum in full periods since last_update_time
  4. add the current incomplete period
  5. update averages

Previously, we separately computed steps 1, 3, and 4, leading to
each one of them ugly in codes and costly in overhead.

For example:

 c1  c3   c4
 ^   ^^
 |   ||
   |<->|<->|<--->|
   ... |---x---|--| ... |--|-x (now)

c1, c3, and c4 are the accumulated (meanwhile decayed) contributions
in timing aspect of steps 1, 3, and 4 respectively.

Then the accumulated contribution to load_sum, for example, is:

contrib = c1 * weight * freq_scaled;
contrib += c3 * weight * freq_scaled;
contrib += c4 * weight * freq_scaled;

Obviously, we can optimize the above as:

contrib = c1 + c3 + c4;
contrib *= weight * freq_scaled;

After we combine them together, we will have much cleaner codes
and less CPU cycles.

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |  189 ++-
 1 file changed, 95 insertions(+), 94 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a060ef2..495e5f0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -668,7 +668,7 @@ static unsigned long task_h_load(struct task_struct *p);
  */
 #define SCHED_AVG_HALFLIFE 32  /* number of periods as a half-life */
 #define SCHED_AVG_MAX 47742/* maximum possible sched avg */
-#define SCHED_AVG_MAX_N 345/* number of full periods to produce 
SCHED_AVG_MAX */
+#define SCHED_AVG_MAX_N 347/* number of full periods to produce 
SCHED_AVG_MAX */
 
 /* Give new sched_entity start runnable values to heavy its load in infant 
time */
 void init_entity_runnable_average(struct sched_entity *se)
@@ -2606,7 +2606,7 @@ static const u32 __accumulated_sum_N[] = {
 
 /*
  * Precomputed \Sum y^k { 1<=k<=n, where n%32=0). Values are rolled down to
- * lower integers.
+ * lower integers. Since n < SCHED_AVG_MAX_N, n/SCHED_AVG_HALFLIFE < 11
  */
 static const u32 __accumulated_sum_N32[] = {
0, 23371, 35056, 40899, 43820, 45281,
@@ -2616,8 +2616,11 @@ static const u32 __accumulated_sum_N32[] = {
 /*
  * val * y^n, where y^m ~= 0.5
  *
- * n is the number of periods past; a period is ~1ms
+ * n is the number of periods past. A period is ~1ms, so a 32bit
+ * integer can hold approximately a maximum of 49 (=2^32/1000/3600/24) days.
+ *
  * m is called half-life in exponential decay; here it is 
SCHED_AVG_HALFLIFE=32.
+ *
  */
 static __always_inline u64 __decay_sum(u64 val, u32 n)
 {
@@ -2649,20 +2652,30 @@ static __always_inline u64 __decay_sum(u64 val, u32 n)
  * We can compute this efficiently by combining:
  * y^32 = 1/2 with precomputed \Sum 1024*y^n   (where n < 32)
  */
-static __always_inline u32 __accumulate_sum(u32 n)
+static __always_inline u32
+__accumulate_sum(u32 periods, u32 period_contrib, u32 remainder)
 {
-   u32 contrib = 0;
+   u32 contrib;
+
+   if (!periods)
+   return remainder - period_contrib;
 
-   if (likely(n <= SCHED_AVG_HALFLIFE))
-   return __accumulated_sum_N[n];
-   else if (unlikely(n >= SCHED_AVG_MAX_N))
+   if (unlikely(periods >= SCHED_AVG_MAX_N))
return SCHED_AVG_MAX;
 
-   /* Since n < SCHED_AVG_MAX_N, n/SCHED_AVG_HALFLIFE < 11 */
-   contrib = __accumulated_sum_N32[n/SCHED_AVG_HALFLIFE];
-   n %= SCHED_AVG_HALFLIFE;
-   contrib = __decay_sum(contrib, n);
-   return contrib + __accumulated_sum_N[n];
+   remainder += __decay_sum((u64)(1024 - period_contrib), periods);
+
+   periods -= 1;
+   if (likely(periods <= SCHED_AVG_HALFLIFE))
+   contrib = __accumulated_sum_N[periods];
+   else {
+   contrib = __accumulated_sum_N32[periods/SCHED_AVG_HALFLIFE];
+   periods %= SCHED_AVG_HALFLIFE;
+   contrib = __decay_sum(contrib, periods);
+   contrib += __accumulated_sum_N[periods];
+   }
+
+   return contrib + remainder;
 }
 
 #if (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) != 10 || SCHED_CAPACITY_SHIFT 
!= 10
@@ -2671,6 +2684,55 @@ static __always_inline u32 __accumulate_sum(u32 n)
 
 #define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
 
+static __always_inline u32 accumulate_sum(u64 delta, struct sched_avg *sa,
+   struct cfs_rq *cfs_rq, int cpu, unsigned long weight, int running)
+{
+   u32 contrib, periods;
+   unsigned long scale_freq, scale_cpu;
+
+   scale_freq = arch_scale_freq_capacity(NULL, cpu);
+   scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
+
+   delta += sa->period_contrib;
+   periods = delta >> 10; /* A period is 1024us (~1ms) */
+
+   /*
+* Accumulating *_sum has two steps.
+*
+* Step 1: decay old *_sum if we crossed period 

[PATCH v3 03/12] sched/fair: Change the variable to hold the number of periods to 32bit

[Yuyang Du]

In sched average update, a period is about 1ms, so a 32-bit unsigned
integer can approximately hold a maximum of 49 (=2^32/1000/3600/24)
days.

For usual cases, 32bit is big enough and 64bit is needless. But if
a task sleeps longer than it, there can be two outcomes:

Consider a task sleeps whatever m milliseconds, then n = (u32)m.

1. If n >= 32*64, then the task's sched avgs will be surely decayed
   to 0. In this case, it really doesn't matter that the 32bit is not
   big enough to hold m. In other words, a task sleeps 2 secs or sleeps
   50 days are the same from sched average point of view.

2. If m < 32*64, the chance to be here is very very low, but if so,
   the task's sched avgs MAY NOT be decayed to 0, depending on how
   big its sums are, and the chance to 0 is still good as load_sum
   is way less than ~0ULL and util_sum way less than ~0U.

Nevertheless, what really maters is what happens in the worst-case
scenario, which is when (u32)m = 0? So in that case, it would be like
after so long a sleep, we treat the task as it never slept, and has the
same sched averages as before it slept. That is actually not bad or
nothing to worry about, and think of it as the same as how we treat
a new born task.

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |   27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2b83b4c..34ccaa3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2619,18 +2619,13 @@ static const u32 __accumulated_sum_N32[] = {
  * n is the number of periods past; a period is ~1ms
  * m is called half-life in exponential decay; here it is 
SCHED_AVG_HALFLIFE=32.
  */
-static __always_inline u64 __decay_sum(u64 val, u64 n)
+static __always_inline u64 __decay_sum(u64 val, u32 n)
 {
-   unsigned int local_n;
-
if (!n)
return val;
else if (unlikely(n > SCHED_AVG_HALFLIFE * 63))
return 0;
 
-   /* after bounds checking we can collapse to 32-bit */
-   local_n = n;
-
/*
 * As y^PERIOD = 1/2, we can combine
 *y^n = 1/2^(n/PERIOD) * y^(n%PERIOD)
@@ -2638,12 +2633,12 @@ static __always_inline u64 __decay_sum(u64 val, u64 n)
 *
 * To achieve constant time decay_load.
 */
-   if (unlikely(local_n >= SCHED_AVG_HALFLIFE)) {
-   val >>= local_n / SCHED_AVG_HALFLIFE;
-   local_n %= SCHED_AVG_HALFLIFE;
+   if (unlikely(n >= SCHED_AVG_HALFLIFE)) {
+   val >>= n / SCHED_AVG_HALFLIFE;
+   n %= SCHED_AVG_HALFLIFE;
}
 
-   val = mul_u64_u32_shr(val, __decay_inv_multiply_N[local_n], 32);
+   val = mul_u64_u32_shr(val, __decay_inv_multiply_N[n], 32);
return val;
 }
 
@@ -2654,7 +2649,7 @@ static __always_inline u64 __decay_sum(u64 val, u64 n)
  * We can compute this efficiently by combining:
  * y^32 = 1/2 with precomputed \Sum 1024*y^n   (where n < 32)
  */
-static u32 __accumulate_sum(u64 n)
+static u32 __accumulate_sum(u32 n)
 {
u32 contrib = 0;
 
@@ -2708,8 +2703,8 @@ static __always_inline int
 __update_sched_avg(u64 now, int cpu, struct sched_avg *sa,
  unsigned long weight, int running, struct cfs_rq *cfs_rq)
 {
-   u64 delta, scaled_delta, periods;
-   u32 contrib;
+   u64 delta, scaled_delta;
+   u32 contrib, periods;
unsigned int delta_w, scaled_delta_w, decayed = 0;
unsigned long scale_freq, scale_cpu;
 
@@ -2762,7 +2757,11 @@ __update_sched_avg(u64 now, int cpu, struct sched_avg 
*sa,
 
delta -= delta_w;
 
-   /* Figure out how many additional periods this update spans */
+   /*
+* Figure out how many additional periods this update spans.
+* A period is 1024*1024ns or ~1ms, so a 32bit integer can hold
+* approximately a maximum of 49 (=2^32/1000/3600/24) days.
+*/
periods = delta / 1024;
delta %= 1024;
 
-- 
1.7.9.5

[PATCH v3 06/12] documentation: Add scheduler/sched-avg.txt

[Yuyang Du]

This doc file has the program to generate the constants to compute
sched averages.

Signed-off-by: Yuyang Du 
---
 Documentation/scheduler/sched-avg.txt |   94 +
 1 file changed, 94 insertions(+)
 create mode 100644 Documentation/scheduler/sched-avg.txt

diff --git a/Documentation/scheduler/sched-avg.txt 
b/Documentation/scheduler/sched-avg.txt
new file mode 100644
index 000..45be4bd
--- /dev/null
+++ b/Documentation/scheduler/sched-avg.txt
@@ -0,0 +1,94 @@
+The following program is used to generate the constants for
+computing sched averages.
+
+==
+   C program (compile with -lm)
+==
+
+#include 
+#include 
+
+#define HALFLIFE 32
+#define SHIFT 32
+
+double y;
+
+void calc_decay_inv_multiply() {
+   int i;
+   unsigned int x;
+
+   printf("static const u32 __decay_inv_multiply_N[] = {");
+   for(i = 0; i < HALFLIFE; i++) {
+   x = ((1UL<<32)-1)*pow(y, i);
+
+   if (i % 6 == 0) printf("\n\t");
+   printf("0x%8x, ", x);
+   }
+   printf("\n};\n\n");
+}
+
+int sum = 1024;
+void calc_accumulated_sum() {
+   int i;
+
+   printf("static const u32 __accumulated_sum_N[] = {\n\t0,");
+   for(i = 1; i <= HALFLIFE; i++) {
+   if (i == 1)
+   sum *= y;
+   else
+   sum = sum*y + 1024*y;
+
+   if (i % 11 == 0) printf("\n\t");
+   printf("%5d,", sum);
+   }
+   printf("\n};\n\n");
+}
+
+int n = 1;
+/* first period */
+long max = 1024;
+
+void calc_converged_max() {
+   long last = 0, y_inv = ((1UL<<32)-1)*y;
+
+   for (; ; n++) {
+   if (n > 1)
+   max = ((max*y_inv)>>SHIFT) + 1024;
+   /*
+* This is the same as:
+* max = max*y + 1024;
+*/
+
+   if (last == max)
+   break;
+
+   last = max;
+   }
+   n--;
+   printf("#define SCHED_AVG_HALFLIFE %d\n", HALFLIFE);
+   printf("#define SCHED_AVG_MAX %ld\n", max);
+   printf("#define SCHED_AVG_MAX_N %d\n\n", n);
+}
+
+void calc_accumulated_sum_32() {
+   int i, x = sum;
+
+   printf("static const u32 __accumulated_sum_N32[] = {\n\t 0,");
+   for(i = 1; i <= n/HALFLIFE+1; i++) {
+   if (i > 1)
+   x = x/2 + sum;
+
+   if (i % 6 == 0) printf("\n\t");
+   printf("%6d,", x);
+   }
+   printf("\n};\n\n");
+}
+
+void main() {
+   y = pow(0.5, 1/(double)HALFLIFE);
+
+   calc_decay_inv_multiply();
+   calc_accumulated_sum();
+   calc_converged_max();
+   calc_accumulated_sum_32();
+}
-- 
1.7.9.5

[PATCH v3 07/12] sched/fair: Generalize the load/util averages resolution definition

[Yuyang Du]

Integer metric needs fixed point arithmetic. In sched/fair, a few
metrics, including weight, load, load_avg, util_avg, freq, and capacity,
may have different fixed point ranges.

In order to avoid errors relating to the fixed point range of these
metrics, we define a basic fixed point range, and then formalize all
metrics to base on the basic range.

The basic range is 1024. Further, one can recursively apply this basic
range to have larger range.

Pointed out by Ben Segall, weight (visible to user, e.g., NICE-0 has
1024) and load (e.g., NICE_0_LOAD) have independent ranges, but they
must be well calibrated.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h |   16 +---
 kernel/sched/fair.c   |4 
 kernel/sched/sched.h  |   15 ++-
 3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index ad9454d..33e7929 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -937,9 +937,19 @@ enum cpu_idle_type {
 };
 
 /*
+ * Integer metrics need fixed point arithmetic, e.g., sched/fair
+ * has a few: load, load_avg, util_avg, freq, and capacity.
+ *
+ * We define a basic fixed point arithmetic range, and then formalize
+ * all these metrics based on that basic range.
+ */
+# define SCHED_FIXEDPOINT_SHIFT10
+# define SCHED_FIXEDPOINT_SCALE(1L << SCHED_FIXEDPOINT_SHIFT)
+
+/*
  * Increase resolution of cpu_capacity calculations
  */
-#define SCHED_CAPACITY_SHIFT   10
+#define SCHED_CAPACITY_SHIFT   SCHED_FIXEDPOINT_SHIFT
 #define SCHED_CAPACITY_SCALE   (1L << SCHED_CAPACITY_SHIFT)
 
 /*
@@ -1205,8 +1215,8 @@ struct load_weight {
  * 1) load_avg factors frequency scaling into the amount of time that a
  * sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
  * aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency and cpu scaling into the amount of time
- * that a sched_entity is running on a CPU, in the range [0..SCHED_LOAD_SCALE].
+ * 2) util_avg factors frequency and cpu capacity scaling into the amount of 
time
+ * that a sched_entity is running on a CPU, in the range 
[0..SCHED_CAPACITY_SCALE].
  * For cfs_rq, it is the aggregated such times of all runnable and
  * blocked sched_entities.
  * The 64 bit load_sum can:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 495e5f0..1a61137 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2678,10 +2678,6 @@ __accumulate_sum(u32 periods, u32 period_contrib, u32 
remainder)
return contrib + remainder;
 }
 
-#if (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) != 10 || SCHED_CAPACITY_SHIFT 
!= 10
-#error "load tracking assumes 2^10 as unit"
-#endif
-
 #define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
 
 static __always_inline u32 accumulate_sum(u64 delta, struct sched_avg *sa,
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 69da6fc..996a137 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -54,18 +54,23 @@ static inline void cpu_load_update_active(struct rq 
*this_rq) { }
  * increased costs.
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
-# define SCHED_LOAD_RESOLUTION 10
-# define scale_load(w) ((w) << SCHED_LOAD_RESOLUTION)
-# define scale_load_down(w)((w) >> SCHED_LOAD_RESOLUTION)
+# define SCHED_LOAD_SHIFT  (SCHED_FIXEDPOINT_SHIFT + 
SCHED_FIXEDPOINT_SHIFT)
+# define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
+# define scale_load_down(w)((w) >> SCHED_FIXEDPOINT_SHIFT)
 #else
-# define SCHED_LOAD_RESOLUTION 0
+# define SCHED_LOAD_SHIFT  (SCHED_FIXEDPOINT_SHIFT)
 # define scale_load(w) (w)
 # define scale_load_down(w)(w)
 #endif
 
-#define SCHED_LOAD_SHIFT   (10 + SCHED_LOAD_RESOLUTION)
 #define SCHED_LOAD_SCALE   (1L << SCHED_LOAD_SHIFT)
 
+/*
+ * NICE_0's weight (visible to user) and its load (invisible to user) have
+ * independent ranges, but they should be well calibrated. We use scale_load()
+ * and scale_load_down(w) to convert between them, the following must be true:
+ * scale_load(sched_prio_to_weight[20]) == NICE_0_LOAD
+ */
 #define NICE_0_LOADSCHED_LOAD_SCALE
 #define NICE_0_SHIFT   SCHED_LOAD_SHIFT
 
-- 
1.7.9.5

[PATCH v3 05/12] sched/fair: Optimize __update_sched_avg()

[Yuyang Du]

__update_sched_avg() has these steps:

  1. add the remainder of the last incomplete period
  2. decay old sum
  3. accumulate new sum in full periods since last_update_time
  4. add the current incomplete period
  5. update averages

Previously, we separately computed steps 1, 3, and 4, leading to
each one of them ugly in codes and costly in overhead.

For example:

 c1  c3   c4
 ^   ^^
 |   ||
   |<->|<->|<--->|
   ... |---x---|--| ... |--|-x (now)

c1, c3, and c4 are the accumulated (meanwhile decayed) contributions
in timing aspect of steps 1, 3, and 4 respectively.

Then the accumulated contribution to load_sum, for example, is:

contrib = c1 * weight * freq_scaled;
contrib += c3 * weight * freq_scaled;
contrib += c4 * weight * freq_scaled;

Obviously, we can optimize the above as:

contrib = c1 + c3 + c4;
contrib *= weight * freq_scaled;

After we combine them together, we will have much cleaner codes
and less CPU cycles.

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |  189 ++-
 1 file changed, 95 insertions(+), 94 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a060ef2..495e5f0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -668,7 +668,7 @@ static unsigned long task_h_load(struct task_struct *p);
  */
 #define SCHED_AVG_HALFLIFE 32  /* number of periods as a half-life */
 #define SCHED_AVG_MAX 47742/* maximum possible sched avg */
-#define SCHED_AVG_MAX_N 345/* number of full periods to produce 
SCHED_AVG_MAX */
+#define SCHED_AVG_MAX_N 347/* number of full periods to produce 
SCHED_AVG_MAX */
 
 /* Give new sched_entity start runnable values to heavy its load in infant 
time */
 void init_entity_runnable_average(struct sched_entity *se)
@@ -2606,7 +2606,7 @@ static const u32 __accumulated_sum_N[] = {
 
 /*
  * Precomputed \Sum y^k { 1<=k<=n, where n%32=0). Values are rolled down to
- * lower integers.
+ * lower integers. Since n < SCHED_AVG_MAX_N, n/SCHED_AVG_HALFLIFE < 11
  */
 static const u32 __accumulated_sum_N32[] = {
0, 23371, 35056, 40899, 43820, 45281,
@@ -2616,8 +2616,11 @@ static const u32 __accumulated_sum_N32[] = {
 /*
  * val * y^n, where y^m ~= 0.5
  *
- * n is the number of periods past; a period is ~1ms
+ * n is the number of periods past. A period is ~1ms, so a 32bit
+ * integer can hold approximately a maximum of 49 (=2^32/1000/3600/24) days.
+ *
  * m is called half-life in exponential decay; here it is 
SCHED_AVG_HALFLIFE=32.
+ *
  */
 static __always_inline u64 __decay_sum(u64 val, u32 n)
 {
@@ -2649,20 +2652,30 @@ static __always_inline u64 __decay_sum(u64 val, u32 n)
  * We can compute this efficiently by combining:
  * y^32 = 1/2 with precomputed \Sum 1024*y^n   (where n < 32)
  */
-static __always_inline u32 __accumulate_sum(u32 n)
+static __always_inline u32
+__accumulate_sum(u32 periods, u32 period_contrib, u32 remainder)
 {
-   u32 contrib = 0;
+   u32 contrib;
+
+   if (!periods)
+   return remainder - period_contrib;
 
-   if (likely(n <= SCHED_AVG_HALFLIFE))
-   return __accumulated_sum_N[n];
-   else if (unlikely(n >= SCHED_AVG_MAX_N))
+   if (unlikely(periods >= SCHED_AVG_MAX_N))
return SCHED_AVG_MAX;
 
-   /* Since n < SCHED_AVG_MAX_N, n/SCHED_AVG_HALFLIFE < 11 */
-   contrib = __accumulated_sum_N32[n/SCHED_AVG_HALFLIFE];
-   n %= SCHED_AVG_HALFLIFE;
-   contrib = __decay_sum(contrib, n);
-   return contrib + __accumulated_sum_N[n];
+   remainder += __decay_sum((u64)(1024 - period_contrib), periods);
+
+   periods -= 1;
+   if (likely(periods <= SCHED_AVG_HALFLIFE))
+   contrib = __accumulated_sum_N[periods];
+   else {
+   contrib = __accumulated_sum_N32[periods/SCHED_AVG_HALFLIFE];
+   periods %= SCHED_AVG_HALFLIFE;
+   contrib = __decay_sum(contrib, periods);
+   contrib += __accumulated_sum_N[periods];
+   }
+
+   return contrib + remainder;
 }
 
 #if (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) != 10 || SCHED_CAPACITY_SHIFT 
!= 10
@@ -2671,6 +2684,55 @@ static __always_inline u32 __accumulate_sum(u32 n)
 
 #define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
 
+static __always_inline u32 accumulate_sum(u64 delta, struct sched_avg *sa,
+   struct cfs_rq *cfs_rq, int cpu, unsigned long weight, int running)
+{
+   u32 contrib, periods;
+   unsigned long scale_freq, scale_cpu;
+
+   scale_freq = arch_scale_freq_capacity(NULL, cpu);
+   scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
+
+   delta += sa->period_contrib;
+   periods = delta >> 10; /* A period is 1024us (~1ms) */
+
+   /*
+* Accumulating *_sum has two steps.
+*
+* Step 1: decay old *_sum if we crossed period boundaries.
+*/
+   

[PATCH v3 03/12] sched/fair: Change the variable to hold the number of periods to 32bit

[Yuyang Du]

In sched average update, a period is about 1ms, so a 32-bit unsigned
integer can approximately hold a maximum of 49 (=2^32/1000/3600/24)
days.

For usual cases, 32bit is big enough and 64bit is needless. But if
a task sleeps longer than it, there can be two outcomes:

Consider a task sleeps whatever m milliseconds, then n = (u32)m.

1. If n >= 32*64, then the task's sched avgs will be surely decayed
   to 0. In this case, it really doesn't matter that the 32bit is not
   big enough to hold m. In other words, a task sleeps 2 secs or sleeps
   50 days are the same from sched average point of view.

2. If m < 32*64, the chance to be here is very very low, but if so,
   the task's sched avgs MAY NOT be decayed to 0, depending on how
   big its sums are, and the chance to 0 is still good as load_sum
   is way less than ~0ULL and util_sum way less than ~0U.

Nevertheless, what really maters is what happens in the worst-case
scenario, which is when (u32)m = 0? So in that case, it would be like
after so long a sleep, we treat the task as it never slept, and has the
same sched averages as before it slept. That is actually not bad or
nothing to worry about, and think of it as the same as how we treat
a new born task.

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |   27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2b83b4c..34ccaa3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2619,18 +2619,13 @@ static const u32 __accumulated_sum_N32[] = {
  * n is the number of periods past; a period is ~1ms
  * m is called half-life in exponential decay; here it is 
SCHED_AVG_HALFLIFE=32.
  */
-static __always_inline u64 __decay_sum(u64 val, u64 n)
+static __always_inline u64 __decay_sum(u64 val, u32 n)
 {
-   unsigned int local_n;
-
if (!n)
return val;
else if (unlikely(n > SCHED_AVG_HALFLIFE * 63))
return 0;
 
-   /* after bounds checking we can collapse to 32-bit */
-   local_n = n;
-
/*
 * As y^PERIOD = 1/2, we can combine
 *y^n = 1/2^(n/PERIOD) * y^(n%PERIOD)
@@ -2638,12 +2633,12 @@ static __always_inline u64 __decay_sum(u64 val, u64 n)
 *
 * To achieve constant time decay_load.
 */
-   if (unlikely(local_n >= SCHED_AVG_HALFLIFE)) {
-   val >>= local_n / SCHED_AVG_HALFLIFE;
-   local_n %= SCHED_AVG_HALFLIFE;
+   if (unlikely(n >= SCHED_AVG_HALFLIFE)) {
+   val >>= n / SCHED_AVG_HALFLIFE;
+   n %= SCHED_AVG_HALFLIFE;
}
 
-   val = mul_u64_u32_shr(val, __decay_inv_multiply_N[local_n], 32);
+   val = mul_u64_u32_shr(val, __decay_inv_multiply_N[n], 32);
return val;
 }
 
@@ -2654,7 +2649,7 @@ static __always_inline u64 __decay_sum(u64 val, u64 n)
  * We can compute this efficiently by combining:
  * y^32 = 1/2 with precomputed \Sum 1024*y^n   (where n < 32)
  */
-static u32 __accumulate_sum(u64 n)
+static u32 __accumulate_sum(u32 n)
 {
u32 contrib = 0;
 
@@ -2708,8 +2703,8 @@ static __always_inline int
 __update_sched_avg(u64 now, int cpu, struct sched_avg *sa,
  unsigned long weight, int running, struct cfs_rq *cfs_rq)
 {
-   u64 delta, scaled_delta, periods;
-   u32 contrib;
+   u64 delta, scaled_delta;
+   u32 contrib, periods;
unsigned int delta_w, scaled_delta_w, decayed = 0;
unsigned long scale_freq, scale_cpu;
 
@@ -2762,7 +2757,11 @@ __update_sched_avg(u64 now, int cpu, struct sched_avg 
*sa,
 
delta -= delta_w;
 
-   /* Figure out how many additional periods this update spans */
+   /*
+* Figure out how many additional periods this update spans.
+* A period is 1024*1024ns or ~1ms, so a 32bit integer can hold
+* approximately a maximum of 49 (=2^32/1000/3600/24) days.
+*/
periods = delta / 1024;
delta %= 1024;
 
-- 
1.7.9.5

[PATCH v3 11/12] sched/fair: Rename scale_load() and scale_load_down()

[Yuyang Du]

Rename scale_load() and scale_load_down() to user_to_kernel_load()
and kernel_to_user_load() respectively. This helps us tag them
clearly and avoid confusion.

[update calculate_imbalance]
Signed-off-by: Vincent Guittot 
Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |8 
 kernel/sched/fair.c  |   18 --
 kernel/sched/sched.h |   16 
 3 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c82ca6e..349d776 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -698,12 +698,12 @@ static void set_load_weight(struct task_struct *p)
 * SCHED_IDLE tasks get minimal weight:
 */
if (idle_policy(p->policy)) {
-   load->weight = scale_load(WEIGHT_IDLEPRIO);
+   load->weight = user_to_kernel_load(WEIGHT_IDLEPRIO);
load->inv_weight = WMULT_IDLEPRIO;
return;
}
 
-   load->weight = scale_load(sched_prio_to_weight[prio]);
+   load->weight = user_to_kernel_load(sched_prio_to_weight[prio]);
load->inv_weight = sched_prio_to_wmult[prio];
 }
 
@@ -8184,7 +8184,7 @@ static void cpu_cgroup_attach(struct cgroup_taskset *tset)
 static int cpu_shares_write_u64(struct cgroup_subsys_state *css,
struct cftype *cftype, u64 shareval)
 {
-   return sched_group_set_shares(css_tg(css), scale_load(shareval));
+   return sched_group_set_shares(css_tg(css), 
user_to_kernel_load(shareval));
 }
 
 static u64 cpu_shares_read_u64(struct cgroup_subsys_state *css,
@@ -8192,7 +8192,7 @@ static u64 cpu_shares_read_u64(struct cgroup_subsys_state 
*css,
 {
struct task_group *tg = css_tg(css);
 
-   return (u64) scale_load_down(tg->shares);
+   return (u64) kernel_to_user_load(tg->shares);
 }
 
 #ifdef CONFIG_CFS_BANDWIDTH
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4487c2a..200f752 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -189,7 +189,7 @@ static void __update_inv_weight(struct load_weight *lw)
if (likely(lw->inv_weight))
return;
 
-   w = scale_load_down(lw->weight);
+   w = kernel_to_user_load(lw->weight);
 
if (BITS_PER_LONG > 32 && unlikely(w >= WMULT_CONST))
lw->inv_weight = 1;
@@ -210,10 +210,14 @@ static void __update_inv_weight(struct load_weight *lw)
  *
  * Or, weight =< lw.weight (because lw.weight is the runqueue weight), thus
  * weight/lw.weight <= 1, and therefore our shift will also be positive.
+ *
+ * Note load.weight falls back to user load scale (i.e., NICE_0's load is
+ * 1024), instead of possibly increased kernel load scale (i.e., NICE_0's
+ * load is NICE_0_LOAD) due to multiplication and division efficiency.
  */
 static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct 
load_weight *lw)
 {
-   u64 fact = scale_load_down(weight);
+   u64 fact = kernel_to_user_load(weight);
int shift = WMULT_SHIFT;
 
__update_inv_weight(lw);
@@ -7017,10 +7021,11 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
 */
if (busiest->group_type == group_overloaded &&
local->group_type   == group_overloaded) {
+   unsigned long min_cpu_load =
+   busiest->group_capacity * NICE_0_LOAD / 
SCHED_CAPACITY_SCALE;
load_above_capacity = busiest->sum_nr_running * NICE_0_LOAD;
-   if (load_above_capacity > scale_load(busiest->group_capacity))
-   load_above_capacity -=
-   scale_load(busiest->group_capacity);
+   if (load_above_capacity > min_cpu_load)
+   load_above_capacity -= min_cpu_load;
else
load_above_capacity = ~0UL;
}
@@ -8574,7 +8579,8 @@ int sched_group_set_shares(struct task_group *tg, 
unsigned long shares)
if (!tg->se[0])
return -EINVAL;
 
-   shares = clamp(shares, scale_load(MIN_SHARES), scale_load(MAX_SHARES));
+   shares = clamp(shares, user_to_kernel_load(MIN_SHARES),
+  user_to_kernel_load(MAX_SHARES));
 
mutex_lock(_mutex);
if (tg->shares == shares)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 1a3be6f..871da67 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -55,22 +55,22 @@ static inline void cpu_load_update_active(struct rq 
*this_rq) { }
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
 # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + 
SCHED_FIXEDPOINT_SHIFT)
-# define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
-# define scale_load_down(w)((w) >> SCHED_FIXEDPOINT_SHIFT)
+# define user_to_kernel_load(w)((w) << SCHED_FIXEDPOINT_SHIFT)
+# define kernel_to_user_load(w)   

[PATCH v3 11/12] sched/fair: Rename scale_load() and scale_load_down()

[Yuyang Du]

Rename scale_load() and scale_load_down() to user_to_kernel_load()
and kernel_to_user_load() respectively. This helps us tag them
clearly and avoid confusion.

[update calculate_imbalance]
Signed-off-by: Vincent Guittot 
Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |8 
 kernel/sched/fair.c  |   18 --
 kernel/sched/sched.h |   16 
 3 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c82ca6e..349d776 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -698,12 +698,12 @@ static void set_load_weight(struct task_struct *p)
 * SCHED_IDLE tasks get minimal weight:
 */
if (idle_policy(p->policy)) {
-   load->weight = scale_load(WEIGHT_IDLEPRIO);
+   load->weight = user_to_kernel_load(WEIGHT_IDLEPRIO);
load->inv_weight = WMULT_IDLEPRIO;
return;
}
 
-   load->weight = scale_load(sched_prio_to_weight[prio]);
+   load->weight = user_to_kernel_load(sched_prio_to_weight[prio]);
load->inv_weight = sched_prio_to_wmult[prio];
 }
 
@@ -8184,7 +8184,7 @@ static void cpu_cgroup_attach(struct cgroup_taskset *tset)
 static int cpu_shares_write_u64(struct cgroup_subsys_state *css,
struct cftype *cftype, u64 shareval)
 {
-   return sched_group_set_shares(css_tg(css), scale_load(shareval));
+   return sched_group_set_shares(css_tg(css), 
user_to_kernel_load(shareval));
 }
 
 static u64 cpu_shares_read_u64(struct cgroup_subsys_state *css,
@@ -8192,7 +8192,7 @@ static u64 cpu_shares_read_u64(struct cgroup_subsys_state 
*css,
 {
struct task_group *tg = css_tg(css);
 
-   return (u64) scale_load_down(tg->shares);
+   return (u64) kernel_to_user_load(tg->shares);
 }
 
 #ifdef CONFIG_CFS_BANDWIDTH
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4487c2a..200f752 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -189,7 +189,7 @@ static void __update_inv_weight(struct load_weight *lw)
if (likely(lw->inv_weight))
return;
 
-   w = scale_load_down(lw->weight);
+   w = kernel_to_user_load(lw->weight);
 
if (BITS_PER_LONG > 32 && unlikely(w >= WMULT_CONST))
lw->inv_weight = 1;
@@ -210,10 +210,14 @@ static void __update_inv_weight(struct load_weight *lw)
  *
  * Or, weight =< lw.weight (because lw.weight is the runqueue weight), thus
  * weight/lw.weight <= 1, and therefore our shift will also be positive.
+ *
+ * Note load.weight falls back to user load scale (i.e., NICE_0's load is
+ * 1024), instead of possibly increased kernel load scale (i.e., NICE_0's
+ * load is NICE_0_LOAD) due to multiplication and division efficiency.
  */
 static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct 
load_weight *lw)
 {
-   u64 fact = scale_load_down(weight);
+   u64 fact = kernel_to_user_load(weight);
int shift = WMULT_SHIFT;
 
__update_inv_weight(lw);
@@ -7017,10 +7021,11 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
 */
if (busiest->group_type == group_overloaded &&
local->group_type   == group_overloaded) {
+   unsigned long min_cpu_load =
+   busiest->group_capacity * NICE_0_LOAD / 
SCHED_CAPACITY_SCALE;
load_above_capacity = busiest->sum_nr_running * NICE_0_LOAD;
-   if (load_above_capacity > scale_load(busiest->group_capacity))
-   load_above_capacity -=
-   scale_load(busiest->group_capacity);
+   if (load_above_capacity > min_cpu_load)
+   load_above_capacity -= min_cpu_load;
else
load_above_capacity = ~0UL;
}
@@ -8574,7 +8579,8 @@ int sched_group_set_shares(struct task_group *tg, 
unsigned long shares)
if (!tg->se[0])
return -EINVAL;
 
-   shares = clamp(shares, scale_load(MIN_SHARES), scale_load(MAX_SHARES));
+   shares = clamp(shares, user_to_kernel_load(MIN_SHARES),
+  user_to_kernel_load(MAX_SHARES));
 
mutex_lock(_mutex);
if (tg->shares == shares)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 1a3be6f..871da67 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -55,22 +55,22 @@ static inline void cpu_load_update_active(struct rq 
*this_rq) { }
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
 # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + 
SCHED_FIXEDPOINT_SHIFT)
-# define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
-# define scale_load_down(w)((w) >> SCHED_FIXEDPOINT_SHIFT)
+# define user_to_kernel_load(w)((w) << SCHED_FIXEDPOINT_SHIFT)
+# define kernel_to_user_load(w)((w) >> SCHED_FIXEDPOINT_SHIFT)
 #else
 # 

[PATCH v3 08/12] sched/fair: Remove SCHED_LOAD_SHIFT and SCHED_LOAD_SCALE

[Yuyang Du]

After cleaning up the sched metrics, these two definitions that cause
ambiguity are not needed any more. Use NICE_0_LOAD_SHIFT and NICE_0_LOAD
instead (the names suggest clearly who they are).

Suggested-by: Ben Segall 
Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c  |4 ++--
 kernel/sched/sched.h |   22 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1a61137..017a26a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -721,7 +721,7 @@ void post_init_entity_util_avg(struct sched_entity *se)
 {
struct cfs_rq *cfs_rq = cfs_rq_of(se);
struct sched_avg *sa = >avg;
-   long cap = (long)(scale_load_down(SCHED_LOAD_SCALE) - 
cfs_rq->avg.util_avg) / 2;
+   long cap = (long)(SCHED_CAPACITY_SCALE - cfs_rq->avg.util_avg) / 2;
 
if (cap > 0) {
if (cfs_rq->avg.util_avg != 0) {
@@ -7019,7 +7019,7 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
if (busiest->group_type == group_overloaded &&
local->group_type   == group_overloaded) {
load_above_capacity = busiest->sum_nr_running *
-   SCHED_LOAD_SCALE;
+ scale_load_down(NICE_0_LOAD);
if (load_above_capacity > busiest->group_capacity)
load_above_capacity -= busiest->group_capacity;
else
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 996a137..1a3be6f 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -54,25 +54,25 @@ static inline void cpu_load_update_active(struct rq 
*this_rq) { }
  * increased costs.
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
-# define SCHED_LOAD_SHIFT  (SCHED_FIXEDPOINT_SHIFT + 
SCHED_FIXEDPOINT_SHIFT)
+# define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + 
SCHED_FIXEDPOINT_SHIFT)
 # define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
 # define scale_load_down(w)((w) >> SCHED_FIXEDPOINT_SHIFT)
 #else
-# define SCHED_LOAD_SHIFT  (SCHED_FIXEDPOINT_SHIFT)
+# define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT)
 # define scale_load(w) (w)
 # define scale_load_down(w)(w)
 #endif
 
-#define SCHED_LOAD_SCALE   (1L << SCHED_LOAD_SHIFT)
-
 /*
- * NICE_0's weight (visible to user) and its load (invisible to user) have
- * independent ranges, but they should be well calibrated. We use scale_load()
- * and scale_load_down(w) to convert between them, the following must be true:
- * scale_load(sched_prio_to_weight[20]) == NICE_0_LOAD
+ * Task weight (visible to user) and its load (invisible to user) have
+ * independent resolution, but they should be well calibrated. We use
+ * scale_load() and scale_load_down(w) to convert between them. The
+ * following must be true:
+ *
+ *  scale_load(sched_prio_to_weight[USER_PRIO(NICE_TO_PRIO(0))]) == NICE_0_LOAD
+ *
  */
-#define NICE_0_LOADSCHED_LOAD_SCALE
-#define NICE_0_SHIFT   SCHED_LOAD_SHIFT
+#define NICE_0_LOAD(1L << NICE_0_LOAD_SHIFT)
 
 /*
  * Single value that decides SCHED_DEADLINE internal math precision.
@@ -861,7 +861,7 @@ DECLARE_PER_CPU(struct sched_domain *, sd_asym);
 struct sched_group_capacity {
atomic_t ref;
/*
-* CPU capacity of this group, SCHED_LOAD_SCALE being max capacity
+* CPU capacity of this group, SCHED_CAPACITY_SCALE being max capacity
 * for a single CPU.
 */
unsigned int capacity;
-- 
1.7.9.5

[PATCH v3 09/12] sched/fair: Add introduction to the sched average metrics

[Yuyang Du]

These sched metrics have become complex enough. We introduce them
at their definitions.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h |   60 -
 1 file changed, 49 insertions(+), 11 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 33e7929..a7cddd6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1211,18 +1211,56 @@ struct load_weight {
 };
 
 /*
- * The load_avg/util_avg accumulates an infinite geometric series.
- * 1) load_avg factors frequency scaling into the amount of time that a
- * sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
- * aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency and cpu capacity scaling into the amount of 
time
- * that a sched_entity is running on a CPU, in the range 
[0..SCHED_CAPACITY_SCALE].
- * For cfs_rq, it is the aggregated such times of all runnable and
+ * The load_avg/util_avg accumulates an infinite geometric series
+ * (see __update_sched_avg() in kernel/sched/fair.c).
+ *
+ * [load_avg definition]
+ *
+ * load_avg = runnable% * scale_load_down(load)
+ *
+ * where runnable% is the time ratio that a sched_entity is runnable.
+ * For cfs_rq, it is the aggregated such load_avg of all runnable and
  * blocked sched_entities.
- * The 64 bit load_sum can:
- * 1) for cfs_rq, afford 4353082796 (=2^64/47742/88761) entities with
- * the highest weight (=88761) always runnable, we should not overflow
- * 2) for entity, support any load.weight always runnable
+ *
+ * load_avg may also take frequency scaling into account:
+ *
+ * load_avg = runnable% * scale_load_down(load) * freq%
+ *
+ * where freq% is the CPU frequency normalize to the highest frequency
+ *
+ * [util_avg definition]
+ *
+ * util_avg = running% * SCHED_CAPACITY_SCALE
+ *
+ * where running% is the time ratio that a sched_entity is running on
+ * a CPU. For cfs_rq, it is the aggregated such util_avg of all runnable
+ * and blocked sched_entities.
+ *
+ * util_avg may also factor frequency scaling and CPU capacity scaling:
+ *
+ * util_avg = running% * SCHED_CAPACITY_SCALE * freq% * capacity%
+ *
+ * where freq% is the same as above, and capacity% is the CPU capacity
+ * normalized to the greatest capacity (due to uarch differences, etc).
+ *
+ * N.B., the above ratios (runnable%, running%, freq%, and capacity%)
+ * themselves are in the range of [0, 1]. To do fixed point arithmetic,
+ * we therefore scale them to as large range as necessary. This is for
+ * example reflected by util_avg's SCHED_CAPACITY_SCALE.
+ *
+ * [Overflow issue]
+ *
+ * The 64bit load_sum can have 4353082796 (=2^64/47742/88761) entities
+ * with the highest load (=88761) always runnable on a single cfs_rq, we
+ * should not overflow as the number already hits PID_MAX_LIMIT.
+ *
+ * For all other cases (including 32bit kernel), struct load_weight's
+ * weight will overflow first before we do, because:
+ *
+ *Max(load_avg) <= Max(load.weight)
+ *
+ * Then, it is the load_weight's responsibility to consider overflow
+ * issues.
  */
 struct sched_avg {
u64 last_update_time, load_sum;
-- 
1.7.9.5