Re: [RFC v3 09/10] iommu/arm-smmu: Implement reserved region get/put callbacks

[Auger Eric]

Hi Robin,

On 07/12/2016 19:24, Robin Murphy wrote:
> On 07/12/16 15:02, Auger Eric wrote:
>> Hi Robin,
>> On 06/12/2016 19:55, Robin Murphy wrote:
>>> On 15/11/16 13:09, Eric Auger wrote:
 The get() populates the list with the PCI host bridge windows
 and the MSI IOVA range.

 At the moment an arbitray MSI IOVA window is set at 0x800
 of size 1MB. This will allow to report those info in iommu-group
 sysfs?
>>
>>
>> First thank you for reviewing the series. This is definitively helpful!

 Signed-off-by: Eric Auger 

 ---

 RFC v2 -> v3:
 - use existing get/put_resv_regions

 RFC v1 -> v2:
 - use defines for MSI IOVA base and length
 ---
  drivers/iommu/arm-smmu.c | 52 
 
  1 file changed, 52 insertions(+)

 diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
 index 8f72814..81f1a83 100644
 --- a/drivers/iommu/arm-smmu.c
 +++ b/drivers/iommu/arm-smmu.c
 @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
  
  #define FSYNR0_WNR(1 << 4)
  
 +#define MSI_IOVA_BASE 0x800
 +#define MSI_IOVA_LENGTH   0x10
 +
  static int force_stage;
  module_param(force_stage, int, S_IRUGO);
  MODULE_PARM_DESC(force_stage,
 @@ -1545,6 +1548,53 @@ static int arm_smmu_of_xlate(struct device *dev, 
 struct of_phandle_args *args)
return iommu_fwspec_add_ids(dev, , 1);
  }
  
 +static void arm_smmu_get_resv_regions(struct device *dev,
 +struct list_head *head)
 +{
 +  struct iommu_resv_region *region;
 +  struct pci_host_bridge *bridge;
 +  struct resource_entry *window;
 +
 +  /* MSI region */
 +  region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
 +   IOMMU_RESV_MSI);
 +  if (!region)
 +  return;
 +
 +  list_add_tail(>list, head);
 +
 +  if (!dev_is_pci(dev))
 +  return;
 +
 +  bridge = pci_find_host_bridge(to_pci_dev(dev)->bus);
 +
 +  resource_list_for_each_entry(window, >windows) {
 +  phys_addr_t start;
 +  size_t length;
 +
 +  if (resource_type(window->res) != IORESOURCE_MEM &&
 +  resource_type(window->res) != IORESOURCE_IO)
>>>
>>> As Joerg commented elsewhere, considering anything other than memory
>>> resources isn't right (I appreciate you've merely copied my own mistake
>>> here). We need some other way to handle root complexes where the CPU
>>> MMIO views of PCI windows appear in PCI memory space - using the I/O
>>> address of I/O resources only works by chance on Juno, and it still
>>> doesn't account for config space. I suggest we just leave that out for
>>> the time being to make life easier (does it even apply to anything other
>>> than Juno?) and figure it out later.
>> OK so I understand I should remove IORESOURCE_IO check.
>>>
 +  continue;
 +
 +  start = window->res->start - window->offset;
 +  length = window->res->end - window->res->start + 1;
 +  region = iommu_alloc_resv_region(start, length,
 +   IOMMU_RESV_NOMAP);
 +  if (!region)
 +  return;
 +  list_add_tail(>list, head);
 +  }
 +}
>>>
>>> Either way, there's nothing SMMU-specific about PCI windows. The fact
>>> that we'd have to copy-paste all of this into the SMMUv3 driver
>>> unchanged suggests it should go somewhere common (although I would be
>>> inclined to leave the insertion of the fake MSI region to driver-private
>>> wrappers). As I said before, the current iova_reserve_pci_windows()
>>> simply wants splitting into appropriate public callbacks for
>>> get_resv_regions and apply_resv_regions.
>> Do you mean somewhere common in the arm-smmu subsystem (new file) or in
>> another subsystem (pci?)
>>
>> More generally the current implementation does not handle the case where
>> any of those PCIe host bridge window collide with the MSI window. To me
>> this is a flaw.
>> 1) Either we take into account the PCIe windows and prevent any
>> collision when allocating the MSI window.
>> 2) or we do not care about PCIe host bridge windows at kernel level.
> 
> Even more generally, the MSI window also needs to avoid any other
> IOMMU-specific reserved regions as well - fortunately I don't think
> there's any current intersection between platforms with RMRR-type
> reservations and platforms which require MSI mapping - so I think we've
> got enough freedom for the moment, but it's certainly an argument in
> favour of ultimately expressing PCI windows through the same mechanism
> to keep everything in the same place. The other big advantage of
> reserved regions is 

Re: [RFC v3 09/10] iommu/arm-smmu: Implement reserved region get/put callbacks

[Auger Eric]

Hi Robin,

On 07/12/2016 19:24, Robin Murphy wrote:
> On 07/12/16 15:02, Auger Eric wrote:
>> Hi Robin,
>> On 06/12/2016 19:55, Robin Murphy wrote:
>>> On 15/11/16 13:09, Eric Auger wrote:
 The get() populates the list with the PCI host bridge windows
 and the MSI IOVA range.

 At the moment an arbitray MSI IOVA window is set at 0x800
 of size 1MB. This will allow to report those info in iommu-group
 sysfs?
>>
>>
>> First thank you for reviewing the series. This is definitively helpful!

 Signed-off-by: Eric Auger 

 ---

 RFC v2 -> v3:
 - use existing get/put_resv_regions

 RFC v1 -> v2:
 - use defines for MSI IOVA base and length
 ---
  drivers/iommu/arm-smmu.c | 52 
 
  1 file changed, 52 insertions(+)

 diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
 index 8f72814..81f1a83 100644
 --- a/drivers/iommu/arm-smmu.c
 +++ b/drivers/iommu/arm-smmu.c
 @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
  
  #define FSYNR0_WNR(1 << 4)
  
 +#define MSI_IOVA_BASE 0x800
 +#define MSI_IOVA_LENGTH   0x10
 +
  static int force_stage;
  module_param(force_stage, int, S_IRUGO);
  MODULE_PARM_DESC(force_stage,
 @@ -1545,6 +1548,53 @@ static int arm_smmu_of_xlate(struct device *dev, 
 struct of_phandle_args *args)
return iommu_fwspec_add_ids(dev, , 1);
  }
  
 +static void arm_smmu_get_resv_regions(struct device *dev,
 +struct list_head *head)
 +{
 +  struct iommu_resv_region *region;
 +  struct pci_host_bridge *bridge;
 +  struct resource_entry *window;
 +
 +  /* MSI region */
 +  region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
 +   IOMMU_RESV_MSI);
 +  if (!region)
 +  return;
 +
 +  list_add_tail(>list, head);
 +
 +  if (!dev_is_pci(dev))
 +  return;
 +
 +  bridge = pci_find_host_bridge(to_pci_dev(dev)->bus);
 +
 +  resource_list_for_each_entry(window, >windows) {
 +  phys_addr_t start;
 +  size_t length;
 +
 +  if (resource_type(window->res) != IORESOURCE_MEM &&
 +  resource_type(window->res) != IORESOURCE_IO)
>>>
>>> As Joerg commented elsewhere, considering anything other than memory
>>> resources isn't right (I appreciate you've merely copied my own mistake
>>> here). We need some other way to handle root complexes where the CPU
>>> MMIO views of PCI windows appear in PCI memory space - using the I/O
>>> address of I/O resources only works by chance on Juno, and it still
>>> doesn't account for config space. I suggest we just leave that out for
>>> the time being to make life easier (does it even apply to anything other
>>> than Juno?) and figure it out later.
>> OK so I understand I should remove IORESOURCE_IO check.
>>>
 +  continue;
 +
 +  start = window->res->start - window->offset;
 +  length = window->res->end - window->res->start + 1;
 +  region = iommu_alloc_resv_region(start, length,
 +   IOMMU_RESV_NOMAP);
 +  if (!region)
 +  return;
 +  list_add_tail(>list, head);
 +  }
 +}
>>>
>>> Either way, there's nothing SMMU-specific about PCI windows. The fact
>>> that we'd have to copy-paste all of this into the SMMUv3 driver
>>> unchanged suggests it should go somewhere common (although I would be
>>> inclined to leave the insertion of the fake MSI region to driver-private
>>> wrappers). As I said before, the current iova_reserve_pci_windows()
>>> simply wants splitting into appropriate public callbacks for
>>> get_resv_regions and apply_resv_regions.
>> Do you mean somewhere common in the arm-smmu subsystem (new file) or in
>> another subsystem (pci?)
>>
>> More generally the current implementation does not handle the case where
>> any of those PCIe host bridge window collide with the MSI window. To me
>> this is a flaw.
>> 1) Either we take into account the PCIe windows and prevent any
>> collision when allocating the MSI window.
>> 2) or we do not care about PCIe host bridge windows at kernel level.
> 
> Even more generally, the MSI window also needs to avoid any other
> IOMMU-specific reserved regions as well - fortunately I don't think
> there's any current intersection between platforms with RMRR-type
> reservations and platforms which require MSI mapping - so I think we've
> got enough freedom for the moment, but it's certainly an argument in
> favour of ultimately expressing PCI windows through the same mechanism
> to keep everything in the same place. The other big advantage of
> reserved regions is that they will 

[PATCH 0/2] Determine kernel text mapping size at runtime for x86_64

[Baoquan He]

Dave Anderson ever told in Crash utility he makes judgement whether it's
a kaslr kernel by size of KERNEL_IMAGE_SIZE. As long as it's 1G, it's
recognized as kaslr. Then the current upstream kernel has a wrong behaviour,
it sets KERNEL_IMAGE_SIZE as 1G as long as CONFIG_RANDOMIZE_BASE is enabled,
though people specify "nokaslr" into cmdline to disable kaslr explicitly.

So in this patchset, made changes to determine the size of kernel text mapping
area at runtime. If "nokaslr" specified, kernel mapping size is 512M though
CONFIG_RANDOMIZE_BASE is enabled.

Baoquan He (2):
  x86/64: Make kernel text mapping always take one whole page table in
early boot code
  x86/KASLR/64: Determine kernel text mapping size at runtime

 arch/x86/boot/compressed/kaslr.c| 15 ++-
 arch/x86/include/asm/kaslr.h|  1 +
 arch/x86/include/asm/page_64_types.h| 20 
 arch/x86/include/asm/pgtable_64_types.h |  2 +-
 arch/x86/kernel/head64.c| 11 ++-
 arch/x86/kernel/head_64.S   | 16 +---
 arch/x86/mm/dump_pagetables.c   |  3 ++-
 arch/x86/mm/init_64.c   |  2 +-
 arch/x86/mm/physaddr.c  |  6 +++---
 9 files changed, 45 insertions(+), 31 deletions(-)

-- 
2.5.5

[PATCH 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime

[Baoquan He]

X86 64 kernel takes KERNEL_IMAGE_SIZE as the kernel text mapping size,
and it's fixed as compiling time, changing from 512M to 1G as long as
CONFIG_RANDOMIZE_BASE is enabled, though people specify kernel option
"nokaslr" explicitly.

This could be a wrong behaviour. CONFIG_RANDOMIZE_BASE should only decide
if the KASLR code need be compiled in. If user specify "nokaslr", the
kernel should behave as no KASLR code compiled in at all.

So in this patch, define a new MACRO KERNEL_MAPPING_SIZE to represent the
size of kernel text mapping area, and let KERNEL_IMAGE_SIZE limit the size
of kernel runtime space. And change to determine the size of kernel text
mapping area at runtime. Though KASLR code compiled in, if "nokaslr" specified,
still set kernel mapping size to be 512M.

Signed-off-by: Baoquan He 
---
 arch/x86/boot/compressed/kaslr.c| 15 ++-
 arch/x86/include/asm/kaslr.h|  1 +
 arch/x86/include/asm/page_64_types.h| 19 +++
 arch/x86/include/asm/pgtable_64_types.h |  2 +-
 arch/x86/kernel/head64.c| 11 ++-
 arch/x86/kernel/head_64.S   |  3 ++-
 arch/x86/mm/dump_pagetables.c   |  3 ++-
 arch/x86/mm/physaddr.c  |  6 +++---
 8 files changed, 36 insertions(+), 24 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index a66854d..3b73c76 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -22,6 +22,8 @@
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
 
+unsigned long kernel_mapping_size = KERNEL_IMAGE_SIZE;
+
 static unsigned long rotate_xor(unsigned long hash, const void *area,
size_t size)
 {
@@ -311,7 +313,7 @@ static void process_e820_entry(struct e820entry *entry,
return;
 
/* On 32-bit, ignore entries entirely above our maximum. */
-   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
+   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= kernel_mapping_size)
return;
 
/* Ignore entries entirely below our minimum. */
@@ -341,8 +343,8 @@ static void process_e820_entry(struct e820entry *entry,
 
/* On 32-bit, reduce region size to fit within max size. */
if (IS_ENABLED(CONFIG_X86_32) &&
-   region.start + region.size > KERNEL_IMAGE_SIZE)
-   region.size = KERNEL_IMAGE_SIZE - region.start;
+   region.start + region.size > kernel_mapping_size)
+   region.size = kernel_mapping_size - region.start;
 
/* Return if region can't contain decompressed kernel */
if (region.size < image_size)
@@ -408,9 +410,9 @@ static unsigned long find_random_virt_addr(unsigned long 
minimum,
/*
 * There are how many CONFIG_PHYSICAL_ALIGN-sized slots
 * that can hold image_size within the range of minimum to
-* KERNEL_IMAGE_SIZE?
+* kernel_mapping_size?
 */
-   slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
+   slots = (kernel_mapping_size - minimum - image_size) /
 CONFIG_PHYSICAL_ALIGN + 1;
 
random_addr = kaslr_get_random_long("Virtual") % slots;
@@ -438,6 +440,9 @@ void choose_random_location(unsigned long input,
return;
}
 
+   if (IS_ENABLED(CONFIG_X86_64))
+   kernel_mapping_size = KERNEL_MAPPING_SIZE_EXT;
+
boot_params->hdr.loadflags |= KASLR_FLAG;
 
/* Prepare to add new identity pagetables on demand. */
diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
index 1052a79..c4f5728 100644
--- a/arch/x86/include/asm/kaslr.h
+++ b/arch/x86/include/asm/kaslr.h
@@ -7,6 +7,7 @@ unsigned long kaslr_get_random_long(const char *purpose);
 extern unsigned long page_offset_base;
 extern unsigned long vmalloc_base;
 extern unsigned long vmemmap_base;
+extern unsigned long kernel_mapping_size;
 
 void kernel_randomize_memory(void);
 #else
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 62a20ea..b8e79d7 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -49,18 +49,21 @@
 #define __PHYSICAL_MASK_SHIFT  46
 #define __VIRTUAL_MASK_SHIFT   47
 
+
+/*
+ * Kernel image size is limited to 512 MB. The kernel code+data+bss
+ * must not be bigger than that.
+ */
+#define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
+
 /*
- * Kernel image size is limited to 1GiB due to the fixmap living in the
- * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
- * 512MiB by default, leaving 1.5GiB for modules once the page tables
+ * Kernel mapping size is limited to 1GiB due to the fixmap living in
+ * the next 1GiB (see level2_kernel_pgt in 

[PATCH 1/2] x86/64: Make kernel text mapping always take one whole page table in early boot code

[Baoquan He]

In early boot code level2_kernel_pgt is used to map kernel text. And its
size varies according to KERNEL_IMAGE_SIZE and fixed at compiling time.
In fact we can make it always takes 512 entries of one whople page table,
because later function cleanup_highmap will clean up the unused entries.
With the help of this change kernel text mapping size can be decided at
runtime later, 512M if kaslr is disabled, 1G if kaslr is enabled.

Signed-off-by: Baoquan He 
---
 arch/x86/include/asm/page_64_types.h |  3 ++-
 arch/x86/kernel/head_64.S| 15 ---
 arch/x86/mm/init_64.c|  2 +-
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 9215e05..62a20ea 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -56,8 +56,9 @@
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
  */
+#define KERNEL_MAPPING_SIZE_EXT(1024 * 1024 * 1024)
 #if defined(CONFIG_RANDOMIZE_BASE)
-#define KERNEL_IMAGE_SIZE  (1024 * 1024 * 1024)
+#define KERNEL_IMAGE_SIZE  KERNEL_MAPPING_SIZE_EXT
 #else
 #define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
 #endif
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index b4421cc..c4b40e7c9 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -453,17 +453,18 @@ NEXT_PAGE(level3_kernel_pgt)
 
 NEXT_PAGE(level2_kernel_pgt)
/*
-* 512 MB kernel mapping. We spend a full page on this pagetable
-* anyway.
+* Kernel image size is limited to 512 MB. The kernel code+data+bss
+* must not be bigger than that.
 *
-* The kernel code+data+bss must not be bigger than that.
+* We spend a full page on this pagetable anyway, so take the whole
+* page here so that the kernel mapping size can be decided at runtime,
+* 512M if no kaslr, 1G if kaslr enabled. Later cleanup_highmap will
+* clean up those unused entries.
 *
-* (NOTE: at +512MB starts the module area, see MODULES_VADDR.
-*  If you want to increase this then increase MODULES_VADDR
-*  too.)
+* The module area starts after kernel mapping area.
 */
PMDS(0, __PAGE_KERNEL_LARGE_EXEC,
-   KERNEL_IMAGE_SIZE/PMD_SIZE)
+   PTRS_PER_PMD)
 
 NEXT_PAGE(level2_fixmap_pgt)
.fill   506,8,0
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 14b9dd7..e95b977 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -307,7 +307,7 @@ void __init init_extra_mapping_uc(unsigned long phys, 
unsigned long size)
 void __init cleanup_highmap(void)
 {
unsigned long vaddr = __START_KERNEL_map;
-   unsigned long vaddr_end = __START_KERNEL_map + KERNEL_IMAGE_SIZE;
+   unsigned long vaddr_end = __START_KERNEL_map + KERNEL_MAPPING_SIZE_EXT;
unsigned long end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
pmd_t *pmd = level2_kernel_pgt;
 
-- 
2.5.5

[PATCH 0/2] Determine kernel text mapping size at runtime for x86_64

[Baoquan He]

Dave Anderson ever told in Crash utility he makes judgement whether it's
a kaslr kernel by size of KERNEL_IMAGE_SIZE. As long as it's 1G, it's
recognized as kaslr. Then the current upstream kernel has a wrong behaviour,
it sets KERNEL_IMAGE_SIZE as 1G as long as CONFIG_RANDOMIZE_BASE is enabled,
though people specify "nokaslr" into cmdline to disable kaslr explicitly.

So in this patchset, made changes to determine the size of kernel text mapping
area at runtime. If "nokaslr" specified, kernel mapping size is 512M though
CONFIG_RANDOMIZE_BASE is enabled.

Baoquan He (2):
  x86/64: Make kernel text mapping always take one whole page table in
early boot code
  x86/KASLR/64: Determine kernel text mapping size at runtime

 arch/x86/boot/compressed/kaslr.c| 15 ++-
 arch/x86/include/asm/kaslr.h|  1 +
 arch/x86/include/asm/page_64_types.h| 20 
 arch/x86/include/asm/pgtable_64_types.h |  2 +-
 arch/x86/kernel/head64.c| 11 ++-
 arch/x86/kernel/head_64.S   | 16 +---
 arch/x86/mm/dump_pagetables.c   |  3 ++-
 arch/x86/mm/init_64.c   |  2 +-
 arch/x86/mm/physaddr.c  |  6 +++---
 9 files changed, 45 insertions(+), 31 deletions(-)

-- 
2.5.5

[PATCH 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime

[Baoquan He]

X86 64 kernel takes KERNEL_IMAGE_SIZE as the kernel text mapping size,
and it's fixed as compiling time, changing from 512M to 1G as long as
CONFIG_RANDOMIZE_BASE is enabled, though people specify kernel option
"nokaslr" explicitly.

This could be a wrong behaviour. CONFIG_RANDOMIZE_BASE should only decide
if the KASLR code need be compiled in. If user specify "nokaslr", the
kernel should behave as no KASLR code compiled in at all.

So in this patch, define a new MACRO KERNEL_MAPPING_SIZE to represent the
size of kernel text mapping area, and let KERNEL_IMAGE_SIZE limit the size
of kernel runtime space. And change to determine the size of kernel text
mapping area at runtime. Though KASLR code compiled in, if "nokaslr" specified,
still set kernel mapping size to be 512M.

Signed-off-by: Baoquan He 
---
 arch/x86/boot/compressed/kaslr.c| 15 ++-
 arch/x86/include/asm/kaslr.h|  1 +
 arch/x86/include/asm/page_64_types.h| 19 +++
 arch/x86/include/asm/pgtable_64_types.h |  2 +-
 arch/x86/kernel/head64.c| 11 ++-
 arch/x86/kernel/head_64.S   |  3 ++-
 arch/x86/mm/dump_pagetables.c   |  3 ++-
 arch/x86/mm/physaddr.c  |  6 +++---
 8 files changed, 36 insertions(+), 24 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index a66854d..3b73c76 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -22,6 +22,8 @@
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
 
+unsigned long kernel_mapping_size = KERNEL_IMAGE_SIZE;
+
 static unsigned long rotate_xor(unsigned long hash, const void *area,
size_t size)
 {
@@ -311,7 +313,7 @@ static void process_e820_entry(struct e820entry *entry,
return;
 
/* On 32-bit, ignore entries entirely above our maximum. */
-   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
+   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= kernel_mapping_size)
return;
 
/* Ignore entries entirely below our minimum. */
@@ -341,8 +343,8 @@ static void process_e820_entry(struct e820entry *entry,
 
/* On 32-bit, reduce region size to fit within max size. */
if (IS_ENABLED(CONFIG_X86_32) &&
-   region.start + region.size > KERNEL_IMAGE_SIZE)
-   region.size = KERNEL_IMAGE_SIZE - region.start;
+   region.start + region.size > kernel_mapping_size)
+   region.size = kernel_mapping_size - region.start;
 
/* Return if region can't contain decompressed kernel */
if (region.size < image_size)
@@ -408,9 +410,9 @@ static unsigned long find_random_virt_addr(unsigned long 
minimum,
/*
 * There are how many CONFIG_PHYSICAL_ALIGN-sized slots
 * that can hold image_size within the range of minimum to
-* KERNEL_IMAGE_SIZE?
+* kernel_mapping_size?
 */
-   slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
+   slots = (kernel_mapping_size - minimum - image_size) /
 CONFIG_PHYSICAL_ALIGN + 1;
 
random_addr = kaslr_get_random_long("Virtual") % slots;
@@ -438,6 +440,9 @@ void choose_random_location(unsigned long input,
return;
}
 
+   if (IS_ENABLED(CONFIG_X86_64))
+   kernel_mapping_size = KERNEL_MAPPING_SIZE_EXT;
+
boot_params->hdr.loadflags |= KASLR_FLAG;
 
/* Prepare to add new identity pagetables on demand. */
diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
index 1052a79..c4f5728 100644
--- a/arch/x86/include/asm/kaslr.h
+++ b/arch/x86/include/asm/kaslr.h
@@ -7,6 +7,7 @@ unsigned long kaslr_get_random_long(const char *purpose);
 extern unsigned long page_offset_base;
 extern unsigned long vmalloc_base;
 extern unsigned long vmemmap_base;
+extern unsigned long kernel_mapping_size;
 
 void kernel_randomize_memory(void);
 #else
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 62a20ea..b8e79d7 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -49,18 +49,21 @@
 #define __PHYSICAL_MASK_SHIFT  46
 #define __VIRTUAL_MASK_SHIFT   47
 
+
+/*
+ * Kernel image size is limited to 512 MB. The kernel code+data+bss
+ * must not be bigger than that.
+ */
+#define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
+
 /*
- * Kernel image size is limited to 1GiB due to the fixmap living in the
- * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
- * 512MiB by default, leaving 1.5GiB for modules once the page tables
+ * Kernel mapping size is limited to 1GiB due to the fixmap living in
+ * the next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S).
+ * Use 

[PATCH 1/2] x86/64: Make kernel text mapping always take one whole page table in early boot code

[Baoquan He]

In early boot code level2_kernel_pgt is used to map kernel text. And its
size varies according to KERNEL_IMAGE_SIZE and fixed at compiling time.
In fact we can make it always takes 512 entries of one whople page table,
because later function cleanup_highmap will clean up the unused entries.
With the help of this change kernel text mapping size can be decided at
runtime later, 512M if kaslr is disabled, 1G if kaslr is enabled.

Signed-off-by: Baoquan He 
---
 arch/x86/include/asm/page_64_types.h |  3 ++-
 arch/x86/kernel/head_64.S| 15 ---
 arch/x86/mm/init_64.c|  2 +-
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 9215e05..62a20ea 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -56,8 +56,9 @@
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
  */
+#define KERNEL_MAPPING_SIZE_EXT(1024 * 1024 * 1024)
 #if defined(CONFIG_RANDOMIZE_BASE)
-#define KERNEL_IMAGE_SIZE  (1024 * 1024 * 1024)
+#define KERNEL_IMAGE_SIZE  KERNEL_MAPPING_SIZE_EXT
 #else
 #define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
 #endif
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index b4421cc..c4b40e7c9 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -453,17 +453,18 @@ NEXT_PAGE(level3_kernel_pgt)
 
 NEXT_PAGE(level2_kernel_pgt)
/*
-* 512 MB kernel mapping. We spend a full page on this pagetable
-* anyway.
+* Kernel image size is limited to 512 MB. The kernel code+data+bss
+* must not be bigger than that.
 *
-* The kernel code+data+bss must not be bigger than that.
+* We spend a full page on this pagetable anyway, so take the whole
+* page here so that the kernel mapping size can be decided at runtime,
+* 512M if no kaslr, 1G if kaslr enabled. Later cleanup_highmap will
+* clean up those unused entries.
 *
-* (NOTE: at +512MB starts the module area, see MODULES_VADDR.
-*  If you want to increase this then increase MODULES_VADDR
-*  too.)
+* The module area starts after kernel mapping area.
 */
PMDS(0, __PAGE_KERNEL_LARGE_EXEC,
-   KERNEL_IMAGE_SIZE/PMD_SIZE)
+   PTRS_PER_PMD)
 
 NEXT_PAGE(level2_fixmap_pgt)
.fill   506,8,0
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 14b9dd7..e95b977 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -307,7 +307,7 @@ void __init init_extra_mapping_uc(unsigned long phys, 
unsigned long size)
 void __init cleanup_highmap(void)
 {
unsigned long vaddr = __START_KERNEL_map;
-   unsigned long vaddr_end = __START_KERNEL_map + KERNEL_IMAGE_SIZE;
+   unsigned long vaddr_end = __START_KERNEL_map + KERNEL_MAPPING_SIZE_EXT;
unsigned long end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
pmd_t *pmd = level2_kernel_pgt;
 
-- 
2.5.5

[PATCH] memremap: Remove unused align_* variables

[Kirtika Ruchandani]

Commit eb7d78c9e7f6 introduced align_start, align_size and align_end
variables in pgmap_radix_release() but did not use them.
Compiling with W=1 gives the following harmless warning, fix it to
reduce the noise with W=1 in the kernel.

kernel/memremap.c: In function ‘pgmap_radix_release’:
kernel/memremap.c:199:48: warning: variable ‘align_end’ set but not used 
[-Wunused-but-set-variable]

The call to resource_size has no side-effects and is safe to remove.

Fixes: eb7d78c9e7f6 ("devm_memremap_pages: fix vmem_altmap lifetime + alignment 
handling")
Cc: Dan Williams 
Signed-off-by: Kirtika Ruchandani 
---
 kernel/memremap.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/kernel/memremap.c b/kernel/memremap.c
index b501e39..8dde681 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -196,11 +196,7 @@ EXPORT_SYMBOL(put_zone_device_page);

 static void pgmap_radix_release(struct resource *res)
 {
-   resource_size_t key, align_start, align_size, align_end;
-
-   align_start = res->start & ~(SECTION_SIZE - 1);
-   align_size = ALIGN(resource_size(res), SECTION_SIZE);
-   align_end = align_start + align_size - 1;
+   resource_size_t key;

mutex_lock(_lock);
for (key = res->start; key <= res->end; key += SECTION_SIZE)
--
2.8.0.rc3.226.g39d4020

[PATCH] memremap: Remove unused align_* variables

[Kirtika Ruchandani]

Commit eb7d78c9e7f6 introduced align_start, align_size and align_end
variables in pgmap_radix_release() but did not use them.
Compiling with W=1 gives the following harmless warning, fix it to
reduce the noise with W=1 in the kernel.

kernel/memremap.c: In function ‘pgmap_radix_release’:
kernel/memremap.c:199:48: warning: variable ‘align_end’ set but not used 
[-Wunused-but-set-variable]

The call to resource_size has no side-effects and is safe to remove.

Fixes: eb7d78c9e7f6 ("devm_memremap_pages: fix vmem_altmap lifetime + alignment 
handling")
Cc: Dan Williams 
Signed-off-by: Kirtika Ruchandani 
---
 kernel/memremap.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/kernel/memremap.c b/kernel/memremap.c
index b501e39..8dde681 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -196,11 +196,7 @@ EXPORT_SYMBOL(put_zone_device_page);

 static void pgmap_radix_release(struct resource *res)
 {
-   resource_size_t key, align_start, align_size, align_end;
-
-   align_start = res->start & ~(SECTION_SIZE - 1);
-   align_size = ALIGN(resource_size(res), SECTION_SIZE);
-   align_end = align_start + align_size - 1;
+   resource_size_t key;

mutex_lock(_lock);
for (key = res->start; key <= res->end; key += SECTION_SIZE)
--
2.8.0.rc3.226.g39d4020

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

[Auger Eric]

Hi Shanker,

On 07/12/2016 19:52, Shanker Donthineni wrote:
> Hi Eric,
> 
> Is there any reason why you are not supporting SMMUv3 driver? Qualcomm
> hardware doesn't not support SMMUv2 hardware, please add support for
> SMMUv3 in next patch set. I've ported ' RFC,v3,09/10] iommu/arm-smmu:
> Implement reserved region get/put callbacks' to SMMUv3 driver and tested
> device-pass-through feature on Qualcomm server platform without any issue.
> 
> Tested-by: Shanker Donthineni 
Thanks!

No reason behind not supporting smmuv3 except I don't have any HW to test.

I will add this support in next version.

Thanks

Eric

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

[Auger Eric]

Hi Shanker,

On 07/12/2016 19:52, Shanker Donthineni wrote:
> Hi Eric,
> 
> Is there any reason why you are not supporting SMMUv3 driver? Qualcomm
> hardware doesn't not support SMMUv2 hardware, please add support for
> SMMUv3 in next patch set. I've ported ' RFC,v3,09/10] iommu/arm-smmu:
> Implement reserved region get/put callbacks' to SMMUv3 driver and tested
> device-pass-through feature on Qualcomm server platform without any issue.
> 
> Tested-by: Shanker Donthineni 
Thanks!

No reason behind not supporting smmuv3 except I don't have any HW to test.

I will add this support in next version.

Thanks

Eric

Re: [PATCHv13,1/3] lib/string: add sysfs_match_string helper

[Heikki Krogerus]

On Wed, Dec 07, 2016 at 03:54:45PM -0800, Guenter Roeck wrote:
> > +int __sysfs_match_string(const char * const *array, size_t n, const char 
> > *str)
> > +{
> > +   const char *item;
> > +   int index;
> > +
> > +   for (index = 0; index < n; index++) {
> > +   item = array[index];
> > +   if (!item)
> > +   break;
> > +   if (!sysfs_streq(item, str))
> 
> No idea how this slipped in: sysfs_streq() returns true on a match,
> meaning the "!" here is wrong.

Good catch. Thanks Guenter.

-- 
heikki

Re: [PATCHv13,1/3] lib/string: add sysfs_match_string helper

[Heikki Krogerus]

On Wed, Dec 07, 2016 at 03:54:45PM -0800, Guenter Roeck wrote:
> > +int __sysfs_match_string(const char * const *array, size_t n, const char 
> > *str)
> > +{
> > +   const char *item;
> > +   int index;
> > +
> > +   for (index = 0; index < n; index++) {
> > +   item = array[index];
> > +   if (!item)
> > +   break;
> > +   if (!sysfs_streq(item, str))
> 
> No idea how this slipped in: sysfs_streq() returns true on a match,
> meaning the "!" here is wrong.

Good catch. Thanks Guenter.

-- 
heikki

[PATCH v2 2/2] net: rfkill: Add rfkill-any LED trigger

[Michał Kępień]

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
which may be useful on laptops with a single "radio LED" and multiple
radio transmitters.  The trigger is meant to turn a LED on whenever
there is at least one radio transmitter active and turn it off
otherwise.

Signed-off-by: Michał Kępień 
---
Changes from v1:

  - take rfkill_global_mutex before calling rfkill_set_block() in
rfkill_resume(); the need for doing this was previously obviated by
908209c ("rfkill: don't impose global states on resume"), but given
that __rfkill_any_led_trigger_event() is called from
rfkill_set_block() unconditionally, each caller of the latter needs
to take care of locking rfkill_global_mutex,

  - declare __rfkill_any_led_trigger_event() even when
CONFIG_RFKILL_LEDS=n to prevent implicit declaration errors,

  - remove the #ifdef surrounding rfkill_any_led_trigger_{,un}register()
calls to prevent compilation warnings about functions and a label
being defined but not used,

  - move the rfkill_any_led_trigger_register() call in rfkill_init()
before the rfkill_handler_init() call to avoid the need to call
rfkill_handler_exit() from rfkill_init() and thus prevent a section
mismatch.

 net/rfkill/core.c | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f28e441..cd50b11 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,47 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
 {
led_trigger_unregister(>led_trigger);
 }
+
+static struct led_trigger rfkill_any_led_trigger;
+
+static void __rfkill_any_led_trigger_event(void)
+{
+   enum led_brightness brightness = LED_OFF;
+   struct rfkill *rfkill;
+
+   list_for_each_entry(rfkill, _list, node) {
+   if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+   brightness = LED_FULL;
+   break;
+   }
+   }
+
+   led_trigger_event(_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+   mutex_lock(_global_mutex);
+   __rfkill_any_led_trigger_event();
+   mutex_unlock(_global_mutex);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+   rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   rfkill_any_led_trigger.name = "rfkill-any";
+   rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+   return led_trigger_register(_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+   led_trigger_unregister(_any_led_trigger);
+}
 #else
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
@@ -189,6 +230,23 @@ static inline int rfkill_led_trigger_register(struct 
rfkill *rfkill)
 static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
 {
 }
+
+static void __rfkill_any_led_trigger_event(void)
+{
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
 #endif /* CONFIG_RFKILL_LEDS */
 
 static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
@@ -297,6 +355,7 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
spin_unlock_irqrestore(>lock, flags);
 
rfkill_led_trigger_event(rfkill);
+   __rfkill_any_led_trigger_event();
 
if (prev != curr)
rfkill_event(rfkill);
@@ -477,6 +536,7 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool 
blocked)
spin_unlock_irqrestore(>lock, flags);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
 
if (!rfkill->registered)
return ret;
@@ -523,6 +583,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool 
blocked)
schedule_work(>uevent_work);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
 
return blocked;
 }
@@ -572,6 +633,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool 
hw)
schedule_work(>uevent_work);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
}
 }
 EXPORT_SYMBOL(rfkill_set_states);
@@ -815,8 +877,10 @@ static int rfkill_resume(struct device *dev)
rfkill->suspended = false;
 
if (!rfkill->persistent) {
+   mutex_lock(_global_mutex);
cur = !!(rfkill->state & RFKILL_BLOCK_SW);
rfkill_set_block(rfkill, cur);
+   mutex_unlock(_global_mutex);
}
 
if (rfkill->ops->poll && !rfkill->polling_paused)
@@ -988,6 +1052,7 @@ int __must_check rfkill_register(struct rfkill *rfkill)
 #endif
}
 
+   __rfkill_any_led_trigger_event();

[PATCH v2 1/2] net: rfkill: Cleanup error handling in rfkill_init()

[Michał Kępień]

Use a separate label per error condition in rfkill_init() to make it a
bit cleaner and easier to extend.

Signed-off-by: Michał Kępień 
---
No changes from v1.

 net/rfkill/core.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 884027f..f28e441 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1266,24 +1266,25 @@ static int __init rfkill_init(void)
 
error = class_register(_class);
if (error)
-   goto out;
+   goto error_class;
 
error = misc_register(_miscdev);
-   if (error) {
-   class_unregister(_class);
-   goto out;
-   }
+   if (error)
+   goto error_misc;
 
 #ifdef CONFIG_RFKILL_INPUT
error = rfkill_handler_init();
-   if (error) {
-   misc_deregister(_miscdev);
-   class_unregister(_class);
-   goto out;
-   }
+   if (error)
+   goto error_input;
 #endif
 
- out:
+   return 0;
+
+error_input:
+   misc_deregister(_miscdev);
+error_misc:
+   class_unregister(_class);
+error_class:
return error;
 }
 subsys_initcall(rfkill_init);
-- 
2.10.2

[PATCH v2 2/2] net: rfkill: Add rfkill-any LED trigger

[Michał Kępień]

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
which may be useful on laptops with a single "radio LED" and multiple
radio transmitters.  The trigger is meant to turn a LED on whenever
there is at least one radio transmitter active and turn it off
otherwise.

Signed-off-by: Michał Kępień 
---
Changes from v1:

  - take rfkill_global_mutex before calling rfkill_set_block() in
rfkill_resume(); the need for doing this was previously obviated by
908209c ("rfkill: don't impose global states on resume"), but given
that __rfkill_any_led_trigger_event() is called from
rfkill_set_block() unconditionally, each caller of the latter needs
to take care of locking rfkill_global_mutex,

  - declare __rfkill_any_led_trigger_event() even when
CONFIG_RFKILL_LEDS=n to prevent implicit declaration errors,

  - remove the #ifdef surrounding rfkill_any_led_trigger_{,un}register()
calls to prevent compilation warnings about functions and a label
being defined but not used,

  - move the rfkill_any_led_trigger_register() call in rfkill_init()
before the rfkill_handler_init() call to avoid the need to call
rfkill_handler_exit() from rfkill_init() and thus prevent a section
mismatch.

 net/rfkill/core.c | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f28e441..cd50b11 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,47 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
 {
led_trigger_unregister(>led_trigger);
 }
+
+static struct led_trigger rfkill_any_led_trigger;
+
+static void __rfkill_any_led_trigger_event(void)
+{
+   enum led_brightness brightness = LED_OFF;
+   struct rfkill *rfkill;
+
+   list_for_each_entry(rfkill, _list, node) {
+   if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+   brightness = LED_FULL;
+   break;
+   }
+   }
+
+   led_trigger_event(_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+   mutex_lock(_global_mutex);
+   __rfkill_any_led_trigger_event();
+   mutex_unlock(_global_mutex);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+   rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   rfkill_any_led_trigger.name = "rfkill-any";
+   rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+   return led_trigger_register(_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+   led_trigger_unregister(_any_led_trigger);
+}
 #else
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
@@ -189,6 +230,23 @@ static inline int rfkill_led_trigger_register(struct 
rfkill *rfkill)
 static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
 {
 }
+
+static void __rfkill_any_led_trigger_event(void)
+{
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
 #endif /* CONFIG_RFKILL_LEDS */
 
 static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
@@ -297,6 +355,7 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
spin_unlock_irqrestore(>lock, flags);
 
rfkill_led_trigger_event(rfkill);
+   __rfkill_any_led_trigger_event();
 
if (prev != curr)
rfkill_event(rfkill);
@@ -477,6 +536,7 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool 
blocked)
spin_unlock_irqrestore(>lock, flags);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
 
if (!rfkill->registered)
return ret;
@@ -523,6 +583,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool 
blocked)
schedule_work(>uevent_work);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
 
return blocked;
 }
@@ -572,6 +633,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool 
hw)
schedule_work(>uevent_work);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
}
 }
 EXPORT_SYMBOL(rfkill_set_states);
@@ -815,8 +877,10 @@ static int rfkill_resume(struct device *dev)
rfkill->suspended = false;
 
if (!rfkill->persistent) {
+   mutex_lock(_global_mutex);
cur = !!(rfkill->state & RFKILL_BLOCK_SW);
rfkill_set_block(rfkill, cur);
+   mutex_unlock(_global_mutex);
}
 
if (rfkill->ops->poll && !rfkill->polling_paused)
@@ -988,6 +1052,7 @@ int __must_check rfkill_register(struct rfkill *rfkill)
 #endif
}
 
+   __rfkill_any_led_trigger_event();

[PATCH v2 1/2] net: rfkill: Cleanup error handling in rfkill_init()

[Michał Kępień]

Use a separate label per error condition in rfkill_init() to make it a
bit cleaner and easier to extend.

Signed-off-by: Michał Kępień 
---
No changes from v1.

 net/rfkill/core.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 884027f..f28e441 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1266,24 +1266,25 @@ static int __init rfkill_init(void)
 
error = class_register(_class);
if (error)
-   goto out;
+   goto error_class;
 
error = misc_register(_miscdev);
-   if (error) {
-   class_unregister(_class);
-   goto out;
-   }
+   if (error)
+   goto error_misc;
 
 #ifdef CONFIG_RFKILL_INPUT
error = rfkill_handler_init();
-   if (error) {
-   misc_deregister(_miscdev);
-   class_unregister(_class);
-   goto out;
-   }
+   if (error)
+   goto error_input;
 #endif
 
- out:
+   return 0;
+
+error_input:
+   misc_deregister(_miscdev);
+error_misc:
+   class_unregister(_class);
+error_class:
return error;
 }
 subsys_initcall(rfkill_init);
-- 
2.10.2

Re: [PATCH v2] PCI: designware: add host_init error handling

[Jisheng Zhang]

Hi Srinivas,

On Wed,  7 Dec 2016 10:32:49 + Srinivas Kandagatla wrote:

> This patch add support to return value from host_init() callback from drivers,
> so that the designware libary can handle or pass it to proper place. Issue 
> with
> void return type is that errors or error handling within host_init() callback
> are never know to designware code, which could go ahead and access registers
> even in error cases.
> 
> Typical case in qcom controller driver is to turn off clks in case of errors,

I have similar idea last year

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

But finally I dropped the patch. The reason is PCIe supports hotplug. I
noticed that most *errors* are due to the link can't be established, for
example, the exynos, dra7xx in your below patch. I think FAIL_TO_ESTABLISH_LINK
is a normal case if we didn't plug in the PCIe DP, then in this case I think
it can't be considered as *error* and we still need to continue. What about
your opinion?

Thanks,
Jisheng

> if designware code continues to read/write register when clocks are turned off
> the board would reboot/lockup.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> Currently designware code does not have a way return errors generated
> as part of host_init() callback in controller drivers. This is an issue
> with controller drivers like qcom which turns off the clocks in error
> handling path. As the dw core is un aware of this would continue to
> access registers which faults resulting in board reboots/hangs.
> 
> There are two ways to solve this issue,
> one is remove error handling in the qcom controller host_init() function
> other is to handle error and pass back to dw core code which would then
> pass back to controller driver as part of dw_pcie_host_init() return value.
> 
> Second option seems more sensible and correct way to fix the issue,
> this patch does the same.
> 
> As part of this change to host_init() return type I had to patch other
> ihost controller drivers which use dw core. Most of the changes to other 
> drivers
> are to return proper error codes to upper layer.
> Only compile tested drivers.
> 
> Changes since RFC:
>   - Add error handling to other drivers as suggested by Joao Pinto
> 
>  drivers/pci/host/pci-dra7xx.c   | 10 --
>  drivers/pci/host/pci-exynos.c   | 10 --
>  drivers/pci/host/pci-imx6.c | 10 --
>  drivers/pci/host/pci-keystone.c | 10 --
>  drivers/pci/host/pci-layerscape.c   | 22 +-
>  drivers/pci/host/pcie-armada8k.c|  4 +++-
>  drivers/pci/host/pcie-designware-plat.c | 10 --
>  drivers/pci/host/pcie-designware.c  |  4 +++-
>  drivers/pci/host/pcie-designware.h  |  2 +-
>  drivers/pci/host/pcie-qcom.c|  5 +++--
>  drivers/pci/host/pcie-spear13xx.c   | 10 --
>  11 files changed, 71 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 9595fad..811f0f9 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -127,9 +127,10 @@ static void dra7xx_pcie_enable_interrupts(struct 
> dra7xx_pcie *dra7xx)
>  LEG_EP_INTERRUPTS);
>  }
>  
> -static void dra7xx_pcie_host_init(struct pcie_port *pp)
> +static int dra7xx_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
> + int ret;
>  
>   pp->io_base &= DRA7XX_CPU_TO_BUS_ADDR;
>   pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR;
> @@ -138,10 +139,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
>  
>   dw_pcie_setup_rc(pp);
>  
> - dra7xx_pcie_establish_link(dra7xx);
> + ret = dra7xx_pcie_establish_link(dra7xx);
> + if (ret < 0)
> + return ret;
> +
>   if (IS_ENABLED(CONFIG_PCI_MSI))
>   dw_pcie_msi_init(pp);
>   dra7xx_pcie_enable_interrupts(dra7xx);
> +
> + return 0;
>  }
>  
>  static struct pcie_host_ops dra7xx_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index f1c544b..c116fd9 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -458,12 +458,18 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
>   return 0;
>  }
>  
> -static void exynos_pcie_host_init(struct pcie_port *pp)
> +static int exynos_pcie_host_init(struct pcie_port *pp)
>  {
>   struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
> + int ret;
> +
> + ret = exynos_pcie_establish_link(exynos_pcie);
> + if (ret < 0)
> + return ret;
>  
> - exynos_pcie_establish_link(exynos_pcie);
>   exynos_pcie_enable_interrupts(exynos_pcie);
> +
> + return 0;
>  }
>  
>  static struct pcie_host_ops exynos_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index c8cefb0..1251e92 100644
> --- 

RE: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

[Bharat Bhushan]

Hi Eric,

I have tested this series on NXP platform.

Thanks
-Bharat

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Eric Auger
> Sent: Tuesday, November 15, 2016 6:39 PM
> To: eric.au...@redhat.com; eric.auger@gmail.com;
> christoffer.d...@linaro.org; marc.zyng...@arm.com;
> robin.mur...@arm.com; alex.william...@redhat.com;
> will.dea...@arm.com; j...@8bytes.org; t...@linutronix.de;
> ja...@lakedaemon.net; linux-arm-ker...@lists.infradead.org
> Cc: drjo...@redhat.com; k...@vger.kernel.org; punit.agra...@arm.com;
> linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org;
> pranav.sawargaon...@gmail.com
> Subject: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and
> IOVA reserved regions
> 
> Following LPC discussions, we now report reserved regions through iommu-
> group sysfs reserved_regions attribute file.
> 
> Reserved regions are populated through the IOMMU get_resv_region
> callback (former get_dm_regions), now implemented by amd-iommu, intel-
> iommu and arm-smmu.
> 
> The intel-iommu reports the [FEE0_h - FEF0_000h] MSI window as an
> IOMMU_RESV_NOMAP reserved region.
> 
> arm-smmu reports the MSI window (arbitrarily located at 0x800 and 1MB
> large) and the PCI host bridge windows.
> 
> The series integrates a not officially posted patch from Robin:
> "iommu/dma: Allow MSI-only cookies".
> 
> This series currently does not address IRQ safety assessment.
> 
> Best Regards
> 
> Eric
> 
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
> 
> History:
> RFC v2 -> v3:
> - switch to an iommu-group sysfs API
> - use new dummy allocator provided by Robin
> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>   the reserved regions
> - at the moment ARM MSI base address/size is left unchanged compared
>   to v2
> - we currently report reserved regions and not usable IOVA regions as
>   requested by Alex
> 
> RFC v1 -> v2:
> - fix intel_add_reserved_regions
> - add mutex lock/unlock in vfio_iommu_type1
> 
> 
> Eric Auger (10):
>   iommu/dma: Allow MSI-only cookies
>   iommu: Rename iommu_dm_regions into iommu_resv_regions
>   iommu: Add new reserved IOMMU attributes
>   iommu: iommu_alloc_resv_region
>   iommu: Do not map reserved regions
>   iommu: iommu_get_group_resv_regions
>   iommu: Implement reserved_regions iommu-group sysfs file
>   iommu/vt-d: Implement reserved region get/put callbacks
>   iommu/arm-smmu: Implement reserved region get/put callbacks
>   vfio/type1: Get MSI cookie
> 
>  drivers/iommu/amd_iommu.c   |  20 +++---
>  drivers/iommu/arm-smmu.c|  52 +++
>  drivers/iommu/dma-iommu.c   | 116 ++
> ---
>  drivers/iommu/intel-iommu.c |  50 ++
>  drivers/iommu/iommu.c   | 141
> 
>  drivers/vfio/vfio_iommu_type1.c |  26 
>  include/linux/dma-iommu.h   |   7 ++
>  include/linux/iommu.h   |  49 ++
>  8 files changed, 391 insertions(+), 70 deletions(-)
> 
> --
> 1.9.1
> 
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2] PCI: designware: add host_init error handling

[Jisheng Zhang]

Hi Srinivas,

On Wed,  7 Dec 2016 10:32:49 + Srinivas Kandagatla wrote:

> This patch add support to return value from host_init() callback from drivers,
> so that the designware libary can handle or pass it to proper place. Issue 
> with
> void return type is that errors or error handling within host_init() callback
> are never know to designware code, which could go ahead and access registers
> even in error cases.
> 
> Typical case in qcom controller driver is to turn off clks in case of errors,

I have similar idea last year

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

But finally I dropped the patch. The reason is PCIe supports hotplug. I
noticed that most *errors* are due to the link can't be established, for
example, the exynos, dra7xx in your below patch. I think FAIL_TO_ESTABLISH_LINK
is a normal case if we didn't plug in the PCIe DP, then in this case I think
it can't be considered as *error* and we still need to continue. What about
your opinion?

Thanks,
Jisheng

> if designware code continues to read/write register when clocks are turned off
> the board would reboot/lockup.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> Currently designware code does not have a way return errors generated
> as part of host_init() callback in controller drivers. This is an issue
> with controller drivers like qcom which turns off the clocks in error
> handling path. As the dw core is un aware of this would continue to
> access registers which faults resulting in board reboots/hangs.
> 
> There are two ways to solve this issue,
> one is remove error handling in the qcom controller host_init() function
> other is to handle error and pass back to dw core code which would then
> pass back to controller driver as part of dw_pcie_host_init() return value.
> 
> Second option seems more sensible and correct way to fix the issue,
> this patch does the same.
> 
> As part of this change to host_init() return type I had to patch other
> ihost controller drivers which use dw core. Most of the changes to other 
> drivers
> are to return proper error codes to upper layer.
> Only compile tested drivers.
> 
> Changes since RFC:
>   - Add error handling to other drivers as suggested by Joao Pinto
> 
>  drivers/pci/host/pci-dra7xx.c   | 10 --
>  drivers/pci/host/pci-exynos.c   | 10 --
>  drivers/pci/host/pci-imx6.c | 10 --
>  drivers/pci/host/pci-keystone.c | 10 --
>  drivers/pci/host/pci-layerscape.c   | 22 +-
>  drivers/pci/host/pcie-armada8k.c|  4 +++-
>  drivers/pci/host/pcie-designware-plat.c | 10 --
>  drivers/pci/host/pcie-designware.c  |  4 +++-
>  drivers/pci/host/pcie-designware.h  |  2 +-
>  drivers/pci/host/pcie-qcom.c|  5 +++--
>  drivers/pci/host/pcie-spear13xx.c   | 10 --
>  11 files changed, 71 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 9595fad..811f0f9 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -127,9 +127,10 @@ static void dra7xx_pcie_enable_interrupts(struct 
> dra7xx_pcie *dra7xx)
>  LEG_EP_INTERRUPTS);
>  }
>  
> -static void dra7xx_pcie_host_init(struct pcie_port *pp)
> +static int dra7xx_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
> + int ret;
>  
>   pp->io_base &= DRA7XX_CPU_TO_BUS_ADDR;
>   pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR;
> @@ -138,10 +139,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
>  
>   dw_pcie_setup_rc(pp);
>  
> - dra7xx_pcie_establish_link(dra7xx);
> + ret = dra7xx_pcie_establish_link(dra7xx);
> + if (ret < 0)
> + return ret;
> +
>   if (IS_ENABLED(CONFIG_PCI_MSI))
>   dw_pcie_msi_init(pp);
>   dra7xx_pcie_enable_interrupts(dra7xx);
> +
> + return 0;
>  }
>  
>  static struct pcie_host_ops dra7xx_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index f1c544b..c116fd9 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -458,12 +458,18 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
>   return 0;
>  }
>  
> -static void exynos_pcie_host_init(struct pcie_port *pp)
> +static int exynos_pcie_host_init(struct pcie_port *pp)
>  {
>   struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
> + int ret;
> +
> + ret = exynos_pcie_establish_link(exynos_pcie);
> + if (ret < 0)
> + return ret;
>  
> - exynos_pcie_establish_link(exynos_pcie);
>   exynos_pcie_enable_interrupts(exynos_pcie);
> +
> + return 0;
>  }
>  
>  static struct pcie_host_ops exynos_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index c8cefb0..1251e92 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ 

RE: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

[Bharat Bhushan]

Hi Eric,

I have tested this series on NXP platform.

Thanks
-Bharat

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Eric Auger
> Sent: Tuesday, November 15, 2016 6:39 PM
> To: eric.au...@redhat.com; eric.auger@gmail.com;
> christoffer.d...@linaro.org; marc.zyng...@arm.com;
> robin.mur...@arm.com; alex.william...@redhat.com;
> will.dea...@arm.com; j...@8bytes.org; t...@linutronix.de;
> ja...@lakedaemon.net; linux-arm-ker...@lists.infradead.org
> Cc: drjo...@redhat.com; k...@vger.kernel.org; punit.agra...@arm.com;
> linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org;
> pranav.sawargaon...@gmail.com
> Subject: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and
> IOVA reserved regions
> 
> Following LPC discussions, we now report reserved regions through iommu-
> group sysfs reserved_regions attribute file.
> 
> Reserved regions are populated through the IOMMU get_resv_region
> callback (former get_dm_regions), now implemented by amd-iommu, intel-
> iommu and arm-smmu.
> 
> The intel-iommu reports the [FEE0_h - FEF0_000h] MSI window as an
> IOMMU_RESV_NOMAP reserved region.
> 
> arm-smmu reports the MSI window (arbitrarily located at 0x800 and 1MB
> large) and the PCI host bridge windows.
> 
> The series integrates a not officially posted patch from Robin:
> "iommu/dma: Allow MSI-only cookies".
> 
> This series currently does not address IRQ safety assessment.
> 
> Best Regards
> 
> Eric
> 
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
> 
> History:
> RFC v2 -> v3:
> - switch to an iommu-group sysfs API
> - use new dummy allocator provided by Robin
> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>   the reserved regions
> - at the moment ARM MSI base address/size is left unchanged compared
>   to v2
> - we currently report reserved regions and not usable IOVA regions as
>   requested by Alex
> 
> RFC v1 -> v2:
> - fix intel_add_reserved_regions
> - add mutex lock/unlock in vfio_iommu_type1
> 
> 
> Eric Auger (10):
>   iommu/dma: Allow MSI-only cookies
>   iommu: Rename iommu_dm_regions into iommu_resv_regions
>   iommu: Add new reserved IOMMU attributes
>   iommu: iommu_alloc_resv_region
>   iommu: Do not map reserved regions
>   iommu: iommu_get_group_resv_regions
>   iommu: Implement reserved_regions iommu-group sysfs file
>   iommu/vt-d: Implement reserved region get/put callbacks
>   iommu/arm-smmu: Implement reserved region get/put callbacks
>   vfio/type1: Get MSI cookie
> 
>  drivers/iommu/amd_iommu.c   |  20 +++---
>  drivers/iommu/arm-smmu.c|  52 +++
>  drivers/iommu/dma-iommu.c   | 116 ++
> ---
>  drivers/iommu/intel-iommu.c |  50 ++
>  drivers/iommu/iommu.c   | 141
> 
>  drivers/vfio/vfio_iommu_type1.c |  26 
>  include/linux/dma-iommu.h   |   7 ++
>  include/linux/iommu.h   |  49 ++
>  8 files changed, 391 insertions(+), 70 deletions(-)
> 
> --
> 1.9.1
> 
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

[Caesar Wang]

The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt  | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt 
b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
new file mode 100644
index 000..b258d6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
@@ -0,0 +1,7 @@
+BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,nv101wxmn51"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.7.4

[PATCH v2 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

[Caesar Wang]

The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt  | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt 
b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
new file mode 100644
index 000..b258d6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
@@ -0,0 +1,7 @@
+BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,nv101wxmn51"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.7.4

[PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Read the panel edid information;

EDID MODE DETAILS
name = 
pixel_clock = 71900
lvds_dual_channel = 0
refresh = 0
ha = 1280
hbl = 160
hso = 48
hspw = 32
hborder = 0
va = 800
vbl = 32
vso = 3
vspw = 5
vborder = 0
phsync = +
pvsync = -
x_mm = 0
y_mm = 0
drm_display_mode
.hdisplay = 1280
.hsync_start = 1328
.hsync_end = 1360
.htotal = 1440
.vdisplay = 800
.vsync_start = 803
.vsync_end = 808
.vtotal = 832

Signed-off-by: Caesar Wang 
---

Changes in v2:
- fix the vsync_start and vsync_end from the edid.
- change the commit.

 drivers/gpu/drm/panel/panel-simple.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..7c90f16 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 5,
+   .vtotal = 800 + 3 + 5 + 24,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4

[PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Read the panel edid information;

EDID MODE DETAILS
name = 
pixel_clock = 71900
lvds_dual_channel = 0
refresh = 0
ha = 1280
hbl = 160
hso = 48
hspw = 32
hborder = 0
va = 800
vbl = 32
vso = 3
vspw = 5
vborder = 0
phsync = +
pvsync = -
x_mm = 0
y_mm = 0
drm_display_mode
.hdisplay = 1280
.hsync_start = 1328
.hsync_end = 1360
.htotal = 1440
.vdisplay = 800
.vsync_start = 803
.vsync_end = 808
.vtotal = 832

Signed-off-by: Caesar Wang 
---

Changes in v2:
- fix the vsync_start and vsync_end from the edid.
- change the commit.

 drivers/gpu/drm/panel/panel-simple.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..7c90f16 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 5,
+   .vtotal = 800 + 3 + 5 + 24,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4

Re: [PATCH v4 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

[Baolin Wang]

Hi Felipe,

On 28 November 2016 at 14:43, Baolin Wang  wrote:
> For some mobile devices with strict power management, we also want to suspend
> the host when the slave is detached for power saving. Thus we add the host
> suspend/resume functions to support this requirement.
>
> Signed-off-by: Baolin Wang 
> ---
> Changes since v3:
>  - No updates.
>
> Changes since v2:
>  - Remove pm_children_suspended() and other unused macros.
>
>  Changes since v1:
>- Add pm_runtime.h head file to avoid kbuild error.
> ---
>  drivers/usb/dwc3/Kconfig |7 +++
>  drivers/usb/dwc3/core.c  |   26 +-
>  drivers/usb/dwc3/core.h  |   15 +++
>  drivers/usb/dwc3/host.c  |   37 +
>  4 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index a45b4f1..47bb2f3 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -47,6 +47,13 @@ config USB_DWC3_DUAL_ROLE
>
>  endchoice
>
> +config USB_DWC3_HOST_SUSPEND
> +   bool "Choose if the DWC3 host (xhci) can be suspend/resume"
> +   depends on USB_DWC3_HOST=y || USB_DWC3_DUAL_ROLE=y
> +   help
> + We can suspend the host when the slave is detached for power saving,
> + and resume the host when one slave is attached.
> +
>  comment "Platform Glue Driver Support"
>
>  config USB_DWC3_OMAP
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 9a4a5e4..7ad4bc3 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(dev);
> pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
> pm_runtime_enable(dev);
> +   pm_suspend_ignore_children(dev, true);
> ret = pm_runtime_get_sync(dev);
> if (ret < 0)
> goto err1;
> @@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
>  static int dwc3_suspend_common(struct dwc3 *dwc)
>  {
> unsigned long   flags;
> +   int ret;
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   spin_lock_irqsave(>lock, flags);
> +   dwc3_gadget_suspend(dwc);
> +   spin_unlock_irqrestore(>lock, flags);
> +   break;
> case USB_DR_MODE_OTG:
> +   ret = dwc3_host_suspend(dwc);
> +   if (ret)
> +   return ret;
> +
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_suspend(dwc);
> spin_unlock_irqrestore(>lock, flags);
> break;
> case USB_DR_MODE_HOST:
> +   ret = dwc3_host_suspend(dwc);
> +   if (ret)
> +   return ret;
> default:
> /* do nothing */
> break;
> @@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   spin_lock_irqsave(>lock, flags);
> +   dwc3_gadget_resume(dwc);
> +   spin_unlock_irqrestore(>lock, flags);
> +   break;
> case USB_DR_MODE_OTG:
> +   ret = dwc3_host_resume(dwc);
> +   if (ret)
> +   return ret;
> +
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_resume(dwc);
> spin_unlock_irqrestore(>lock, flags);
> -   /* FALLTHROUGH */
> +   break;
> case USB_DR_MODE_HOST:
> +   ret = dwc3_host_resume(dwc);
> +   if (ret)
> +   return ret;
> default:
> /* do nothing */
> break;
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index b585a30..db41908 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -1226,4 +1226,19 @@ static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
>  { }
>  #endif
>
> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST_SUSPEND)
> +int dwc3_host_suspend(struct dwc3 *dwc);
> +int dwc3_host_resume(struct dwc3 *dwc);
> +#else
> +static inline int dwc3_host_suspend(struct dwc3 *dwc)
> +{
> +   return 0;
> +}
> +
> +static inline int dwc3_host_resume(struct dwc3 *dwc)
> +{
> +   return 0;
> +}
> +#endif
> +
>  #endif /* __DRIVERS_USB_DWC3_CORE_H */
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index ed82464..8e5309d6 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -16,6 +16,7 @@
>   */
>
>  #include 
> +#include 
>
>  #include "core.h"
>
> @@ -130,3 +131,39 @@ void dwc3_host_exit(struct dwc3 *dwc)
>   dev_name(>xhci->dev));
> platform_device_unregister(dwc->xhci);
>  }
> +
> +#ifdef 

Re: [PATCH v4 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

[Baolin Wang]

Hi Felipe,

On 28 November 2016 at 14:43, Baolin Wang  wrote:
> For some mobile devices with strict power management, we also want to suspend
> the host when the slave is detached for power saving. Thus we add the host
> suspend/resume functions to support this requirement.
>
> Signed-off-by: Baolin Wang 
> ---
> Changes since v3:
>  - No updates.
>
> Changes since v2:
>  - Remove pm_children_suspended() and other unused macros.
>
>  Changes since v1:
>- Add pm_runtime.h head file to avoid kbuild error.
> ---
>  drivers/usb/dwc3/Kconfig |7 +++
>  drivers/usb/dwc3/core.c  |   26 +-
>  drivers/usb/dwc3/core.h  |   15 +++
>  drivers/usb/dwc3/host.c  |   37 +
>  4 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index a45b4f1..47bb2f3 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -47,6 +47,13 @@ config USB_DWC3_DUAL_ROLE
>
>  endchoice
>
> +config USB_DWC3_HOST_SUSPEND
> +   bool "Choose if the DWC3 host (xhci) can be suspend/resume"
> +   depends on USB_DWC3_HOST=y || USB_DWC3_DUAL_ROLE=y
> +   help
> + We can suspend the host when the slave is detached for power saving,
> + and resume the host when one slave is attached.
> +
>  comment "Platform Glue Driver Support"
>
>  config USB_DWC3_OMAP
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 9a4a5e4..7ad4bc3 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(dev);
> pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
> pm_runtime_enable(dev);
> +   pm_suspend_ignore_children(dev, true);
> ret = pm_runtime_get_sync(dev);
> if (ret < 0)
> goto err1;
> @@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
>  static int dwc3_suspend_common(struct dwc3 *dwc)
>  {
> unsigned long   flags;
> +   int ret;
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   spin_lock_irqsave(>lock, flags);
> +   dwc3_gadget_suspend(dwc);
> +   spin_unlock_irqrestore(>lock, flags);
> +   break;
> case USB_DR_MODE_OTG:
> +   ret = dwc3_host_suspend(dwc);
> +   if (ret)
> +   return ret;
> +
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_suspend(dwc);
> spin_unlock_irqrestore(>lock, flags);
> break;
> case USB_DR_MODE_HOST:
> +   ret = dwc3_host_suspend(dwc);
> +   if (ret)
> +   return ret;
> default:
> /* do nothing */
> break;
> @@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   spin_lock_irqsave(>lock, flags);
> +   dwc3_gadget_resume(dwc);
> +   spin_unlock_irqrestore(>lock, flags);
> +   break;
> case USB_DR_MODE_OTG:
> +   ret = dwc3_host_resume(dwc);
> +   if (ret)
> +   return ret;
> +
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_resume(dwc);
> spin_unlock_irqrestore(>lock, flags);
> -   /* FALLTHROUGH */
> +   break;
> case USB_DR_MODE_HOST:
> +   ret = dwc3_host_resume(dwc);
> +   if (ret)
> +   return ret;
> default:
> /* do nothing */
> break;
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index b585a30..db41908 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -1226,4 +1226,19 @@ static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
>  { }
>  #endif
>
> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST_SUSPEND)
> +int dwc3_host_suspend(struct dwc3 *dwc);
> +int dwc3_host_resume(struct dwc3 *dwc);
> +#else
> +static inline int dwc3_host_suspend(struct dwc3 *dwc)
> +{
> +   return 0;
> +}
> +
> +static inline int dwc3_host_resume(struct dwc3 *dwc)
> +{
> +   return 0;
> +}
> +#endif
> +
>  #endif /* __DRIVERS_USB_DWC3_CORE_H */
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index ed82464..8e5309d6 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -16,6 +16,7 @@
>   */
>
>  #include 
> +#include 
>
>  #include "core.h"
>
> @@ -130,3 +131,39 @@ void dwc3_host_exit(struct dwc3 *dwc)
>   dev_name(>xhci->dev));
> platform_device_unregister(dwc->xhci);
>  }
> +
> +#ifdef CONFIG_USB_DWC3_HOST_SUSPEND
> +int dwc3_host_suspend(struct dwc3 *dwc)
> 

Re: [PATCH] Bluetooth: btmrvl: drop duplicate header slab.h

[Marcel Holtmann]

Hi Geliang,

> Drop duplicate header slab.h from btmrvl_drv.h.
> 
> Signed-off-by: Geliang Tang 
> ---
> drivers/bluetooth/btmrvl_drv.h | 1 -
> 1 file changed, 1 deletion(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH] Bluetooth: btmrvl: drop duplicate header slab.h

[Marcel Holtmann]

Hi Geliang,

> Drop duplicate header slab.h from btmrvl_drv.h.
> 
> Signed-off-by: Geliang Tang 
> ---
> drivers/bluetooth/btmrvl_drv.h | 1 -
> 1 file changed, 1 deletion(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH v4 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi Mathias and Felipe,

On 28 November 2016 at 14:43, Baolin Wang  wrote:
> Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
> Also call pm_runtime_get_noresume() in probe() function in case the parent
> device doesn't call suspend/resume callback by runtime PM now.
>
> Signed-off-by: Baolin Wang 
> ---
> Changes since v3:
>  - Fix kbuild error.
>
> Changes since v2:
>  - Add pm_runtime_get_noresume() in probe() function.
>  - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() 
> function.
>
> Changes since v1:
>  - No updates.
> ---
>  drivers/usb/host/xhci-plat.c |   41 -
>  1 file changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..5805c6a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (ret)
> goto dealloc_usb2_hcd;
>
> +   pm_runtime_get_noresume(>dev);
> +   pm_runtime_set_active(>dev);
> +   pm_runtime_enable(>dev);
> +
> return 0;
>
>
> @@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> struct clk *clk = xhci->clk;
>
> +   pm_runtime_set_suspended(>dev);
> +   pm_runtime_put_noidle(>dev);
> +   pm_runtime_disable(>dev);
> +
> usb_remove_hcd(xhci->shared_hcd);
> usb_phy_shutdown(hcd->usb_phy);
>
> @@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
>
> return xhci_resume(xhci, 0);
>  }
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#ifdef CONFIG_PM
> +static int xhci_plat_runtime_suspend(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_suspend(xhci, device_may_wakeup(dev));
> +}
> +
> +static int xhci_plat_runtime_resume(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_resume(xhci, 0);
> +}
> +
> +static int xhci_plat_runtime_idle(struct device *dev)
> +{
> +   return 0;
> +}
> +#endif /* CONFIG_PM */
>
>  static const struct dev_pm_ops xhci_plat_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
> +
> +   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, 
> xhci_plat_runtime_resume,
> +  xhci_plat_runtime_idle)
>  };
> -#define DEV_PM_OPS (_plat_pm_ops)
> -#else
> -#define DEV_PM_OPS NULL
> -#endif /* CONFIG_PM */
>
>  static const struct acpi_device_id usb_xhci_acpi_match[] = {
> /* XHCI-compliant USB Controller */
> @@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
> .remove = xhci_plat_remove,
> .driver = {
> .name = "xhci-hcd",
> -   .pm = DEV_PM_OPS,
> +   .pm = _plat_pm_ops,
> .of_match_table = of_match_ptr(usb_xhci_of_match),
> .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> },
> --
> 1.7.9.5
>

Do you have any comments about this patch? Thanks.

-- 
Baolin.wang
Best Regards

Re: [PATCH v4 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi Mathias and Felipe,

On 28 November 2016 at 14:43, Baolin Wang  wrote:
> Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
> Also call pm_runtime_get_noresume() in probe() function in case the parent
> device doesn't call suspend/resume callback by runtime PM now.
>
> Signed-off-by: Baolin Wang 
> ---
> Changes since v3:
>  - Fix kbuild error.
>
> Changes since v2:
>  - Add pm_runtime_get_noresume() in probe() function.
>  - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() 
> function.
>
> Changes since v1:
>  - No updates.
> ---
>  drivers/usb/host/xhci-plat.c |   41 -
>  1 file changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..5805c6a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (ret)
> goto dealloc_usb2_hcd;
>
> +   pm_runtime_get_noresume(>dev);
> +   pm_runtime_set_active(>dev);
> +   pm_runtime_enable(>dev);
> +
> return 0;
>
>
> @@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> struct clk *clk = xhci->clk;
>
> +   pm_runtime_set_suspended(>dev);
> +   pm_runtime_put_noidle(>dev);
> +   pm_runtime_disable(>dev);
> +
> usb_remove_hcd(xhci->shared_hcd);
> usb_phy_shutdown(hcd->usb_phy);
>
> @@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
>
> return xhci_resume(xhci, 0);
>  }
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#ifdef CONFIG_PM
> +static int xhci_plat_runtime_suspend(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_suspend(xhci, device_may_wakeup(dev));
> +}
> +
> +static int xhci_plat_runtime_resume(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_resume(xhci, 0);
> +}
> +
> +static int xhci_plat_runtime_idle(struct device *dev)
> +{
> +   return 0;
> +}
> +#endif /* CONFIG_PM */
>
>  static const struct dev_pm_ops xhci_plat_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
> +
> +   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, 
> xhci_plat_runtime_resume,
> +  xhci_plat_runtime_idle)
>  };
> -#define DEV_PM_OPS (_plat_pm_ops)
> -#else
> -#define DEV_PM_OPS NULL
> -#endif /* CONFIG_PM */
>
>  static const struct acpi_device_id usb_xhci_acpi_match[] = {
> /* XHCI-compliant USB Controller */
> @@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
> .remove = xhci_plat_remove,
> .driver = {
> .name = "xhci-hcd",
> -   .pm = DEV_PM_OPS,
> +   .pm = _plat_pm_ops,
> .of_match_table = of_match_ptr(usb_xhci_of_match),
> .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> },
> --
> 1.7.9.5
>

Do you have any comments about this patch? Thanks.

-- 
Baolin.wang
Best Regards

Re: [PATCH] xen/pci: Bubble up error and fix description.

[Juergen Gross]

On 06/12/16 15:28, Konrad Rzeszutek Wilk wrote:
> The function is never called under PV guests, and only shows up
> when MSI (or MSI-X) cannot be allocated. Convert the message
> to include the error value.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Commited to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH] xen/pci: Bubble up error and fix description.

[Juergen Gross]

On 06/12/16 15:28, Konrad Rzeszutek Wilk wrote:
> The function is never called under PV guests, and only shows up
> when MSI (or MSI-X) cannot be allocated. Convert the message
> to include the error value.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Commited to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH v2] inotify: Convert to using per-namespace limits

[Nikolay Borisov]

On  8.12.2016 03:40, Eric W. Biederman wrote:
> Nikolay Borisov  writes:
> 
>> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully
>> resolved.
> 
> After getting slowed down by some fixes I am now taking a hard look at
> your patch in the hopes of merging it.
> 
> Did you happen to see the kbuild test roboot boot failures and did you
> happen to look into what caused them?  I have just skimmed them and it
> appears to be related to your patch.

I saw them in the beginning but they did look like a generic memory
corruption and I believe at the time those patches were submitted there
was a lingering memory corruption hitting various patches. Thus I didn't
think it was related to my patches. I've since left my work so been
taking a bit of time off and haven't looked really hard, so those
patches have been kind of lingering.


But now that you mention it I will try and take a second look to see
what might cause the memory corruption? Is there a way to force 0day to
re-run them to see whether the failure was indeed caused by my patches
or were intermittent?

Regards,
Nikolay


> 
> Eric
> 
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
> 

Re: [PATCH v2] inotify: Convert to using per-namespace limits

[Nikolay Borisov]

On  8.12.2016 03:40, Eric W. Biederman wrote:
> Nikolay Borisov  writes:
> 
>> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully
>> resolved.
> 
> After getting slowed down by some fixes I am now taking a hard look at
> your patch in the hopes of merging it.
> 
> Did you happen to see the kbuild test roboot boot failures and did you
> happen to look into what caused them?  I have just skimmed them and it
> appears to be related to your patch.

I saw them in the beginning but they did look like a generic memory
corruption and I believe at the time those patches were submitted there
was a lingering memory corruption hitting various patches. Thus I didn't
think it was related to my patches. I've since left my work so been
taking a bit of time off and haven't looked really hard, so those
patches have been kind of lingering.


But now that you mention it I will try and take a second look to see
what might cause the memory corruption? Is there a way to force 0day to
re-run them to see whether the failure was indeed caused by my patches
or were intermittent?

Regards,
Nikolay


> 
> Eric
> 
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
> 

Re: [PATCH 1/1 v2] xen: xenbus: set error code on failure

[Juergen Gross]

On 05/12/16 09:22, Pan Bian wrote:
> Variable err is initialized with 0. As a result, the return value may 
> be 0 even if get_zeroed_page() fails to allocate memory. This patch fixes
> the bug, initializing err with "-ENOMEM".
> 
> v1 is reviewed by: Juergen Gross 
> 
> Signed-off-by: Pan Bian 

Commited to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH 1/1 v2] xen: xenbus: set error code on failure

[Juergen Gross]

On 05/12/16 09:22, Pan Bian wrote:
> Variable err is initialized with 0. As a result, the return value may 
> be 0 even if get_zeroed_page() fails to allocate memory. This patch fixes
> the bug, initializing err with "-ENOMEM".
> 
> v1 is reviewed by: Juergen Gross 
> 
> Signed-off-by: Pan Bian 

Commited to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH 1/1 v2] xen: set error code on failures

[Juergen Gross]

On 05/12/16 09:23, Pan Bian wrote:
> Variable rc is reset in the loop, and its value will be non-negative
> during the second and after repeat of the loop. If it fails to allocate
> memory then, it may return a non-negative integer, which indicates no
> error. This patch fixes the bug, assigning "-ENOMEM" to rc when
> kzalloc() or alloc_page() returns NULL, and removing the initialization
> of rc outside of the loop.
> 
> v1 is reviewed by: Juergen Gross 
> 
> Signed-off-by: Pan Bian 

Commited to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH 1/1 v2] xen: set error code on failures

[Juergen Gross]

On 05/12/16 09:23, Pan Bian wrote:
> Variable rc is reset in the loop, and its value will be non-negative
> during the second and after repeat of the loop. If it fails to allocate
> memory then, it may return a non-negative integer, which indicates no
> error. This patch fixes the bug, assigning "-ENOMEM" to rc when
> kzalloc() or alloc_page() returns NULL, and removing the initialization
> of rc outside of the loop.
> 
> v1 is reviewed by: Juergen Gross 
> 
> Signed-off-by: Pan Bian 

Commited to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH 5/8] efi: Get the secure boot status [ver #5]

[Lukas Wunner]

On Wed, Dec 07, 2016 at 01:18:39PM +, David Howells wrote:
> @@ -226,7 +180,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
> *sys_table,
>   efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
>   unsigned long reserve_addr = 0;
>   unsigned long reserve_size = 0;
> - int secure_boot = 0;
> + enum efi_secureboot_mode secure_boot = efi_secureboot_mode_unknown;

You're setting this variable unconditionally further down, so no need
to initialize it.


> +/*
> + * Determine whether we're in secure boot mode.  We return:
> + */

We return?  Looks like something's missing here.


> +enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t 
> *sys_table_arg)
> +{
> + u8 secboot, setupmode;
> + unsigned long size;
> + efi_status_t status;
> +
> + size = sizeof(secboot);
> + status = get_efi_var(efi_SecureBoot_name, _variable_guid,
> +  NULL, , );
> + if (status != EFI_SUCCESS)
> + goto out_efi_err;
> +
> + size = sizeof(setupmode);
> + status = get_efi_var(efi_SetupMode_name, _variable_guid,
> +  NULL, , );
> + if (status != EFI_SUCCESS)
> + goto out_efi_err;
> +
> + if (secboot == 0 || setupmode == 1)
> + goto secure_boot_disabled;

Well, you could just return efi_secureboot_mode_disabled directly here
instead of doing a jump.


> +
> + pr_efi(sys_table_arg, "UEFI Secure Boot is enabled.\n");
> + return efi_secureboot_mode_enabled;
> +
> +secure_boot_disabled:
> + return efi_secureboot_mode_disabled;
> +
> +out_efi_err:
> + pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot 
> status.\n");
> + if (status == EFI_NOT_FOUND)
> + goto secure_boot_disabled;
> + return efi_secureboot_mode_unknown;
> +}

Thanks,

Lukas

Re: [PATCH 5/8] efi: Get the secure boot status [ver #5]

[Lukas Wunner]

On Wed, Dec 07, 2016 at 01:18:39PM +, David Howells wrote:
> @@ -226,7 +180,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
> *sys_table,
>   efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
>   unsigned long reserve_addr = 0;
>   unsigned long reserve_size = 0;
> - int secure_boot = 0;
> + enum efi_secureboot_mode secure_boot = efi_secureboot_mode_unknown;

You're setting this variable unconditionally further down, so no need
to initialize it.


> +/*
> + * Determine whether we're in secure boot mode.  We return:
> + */

We return?  Looks like something's missing here.


> +enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t 
> *sys_table_arg)
> +{
> + u8 secboot, setupmode;
> + unsigned long size;
> + efi_status_t status;
> +
> + size = sizeof(secboot);
> + status = get_efi_var(efi_SecureBoot_name, _variable_guid,
> +  NULL, , );
> + if (status != EFI_SUCCESS)
> + goto out_efi_err;
> +
> + size = sizeof(setupmode);
> + status = get_efi_var(efi_SetupMode_name, _variable_guid,
> +  NULL, , );
> + if (status != EFI_SUCCESS)
> + goto out_efi_err;
> +
> + if (secboot == 0 || setupmode == 1)
> + goto secure_boot_disabled;

Well, you could just return efi_secureboot_mode_disabled directly here
instead of doing a jump.


> +
> + pr_efi(sys_table_arg, "UEFI Secure Boot is enabled.\n");
> + return efi_secureboot_mode_enabled;
> +
> +secure_boot_disabled:
> + return efi_secureboot_mode_disabled;
> +
> +out_efi_err:
> + pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot 
> status.\n");
> + if (status == EFI_NOT_FOUND)
> + goto secure_boot_disabled;
> + return efi_secureboot_mode_unknown;
> +}

Thanks,

Lukas

[PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

[kys]

From: Haiyang Zhang 

We currently use MAC address to match VF and synthetic NICs. Hyper-V
provides a serial number to both devices for this purpose. This patch
implements the matching based on VF serial numbers. This is the way
specified by the protocol and more reliable.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/netvsc_drv.c |   55 ---
 1 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 9522763..c5778cf 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1165,9 +1165,10 @@ static void netvsc_free_netdev(struct net_device *netdev)
free_netdev(netdev);
 }
 
-static struct net_device *get_netvsc_bymac(const u8 *mac)
+static struct net_device *get_netvsc_byvfser(u32 vfser)
 {
struct net_device *dev;
+   struct net_device_context *ndev_ctx;
 
ASSERT_RTNL();
 
@@ -1175,7 +1176,8 @@ static void netvsc_free_netdev(struct net_device *netdev)
if (dev->netdev_ops != _ops)
continue;   /* not a netvsc device */
 
-   if (ether_addr_equal(mac, dev->perm_addr))
+   ndev_ctx = netdev_priv(dev);
+   if (ndev_ctx->vf_serial == vfser)
return dev;
}
 
@@ -1205,21 +1207,66 @@ static void netvsc_free_netdev(struct net_device 
*netdev)
return NULL;
 }
 
+static u32 netvsc_get_vfser(struct net_device *vf_netdev)
+{
+   struct device *dev;
+   struct hv_device *hdev;
+   struct hv_pcibus_device *hbus = NULL;
+   struct list_head *iter;
+   struct hv_pci_dev *hpdev;
+   unsigned long flags;
+   u32 vfser = 0;
+   u32 count = 0;
+
+   for (dev = _netdev->dev; dev; dev = dev->parent) {
+   if (!dev_is_vmbus(dev))
+   continue;
+
+   hdev = device_to_hv_device(dev);
+   if (hdev->device_id != HV_PCIE)
+   continue;
+
+   hbus = hv_get_drvdata(hdev);
+   break;
+   }
+
+   if (!hbus)
+   return 0;
+
+   spin_lock_irqsave(>device_list_lock, flags);
+   list_for_each(iter, >children) {
+   hpdev = container_of(iter, struct hv_pci_dev, list_entry);
+   vfser = hpdev->desc.ser;
+   count++;
+   }
+   spin_unlock_irqrestore(>device_list_lock, flags);
+
+   if (count == 1)
+   return vfser;
+
+   return 0;
+}
+
 static int netvsc_register_vf(struct net_device *vf_netdev)
 {
struct net_device *ndev;
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
+   u32 vfser;
 
if (vf_netdev->addr_len != ETH_ALEN)
return NOTIFY_DONE;
 
+   vfser = netvsc_get_vfser(vf_netdev);
+   if (!vfser)
+   return NOTIFY_DONE;
+
/*
-* We will use the MAC address to locate the synthetic interface to
+* We will use the VF serial to locate the synthetic interface to
 * associate with the VF interface. If we don't find a matching
 * synthetic interface, move on.
 */
-   ndev = get_netvsc_bymac(vf_netdev->perm_addr);
+   ndev = get_netvsc_byvfser(vfser);
if (!ndev)
return NOTIFY_DONE;
 
-- 
1.7.4.1

[PATCH] fsl/usb: Add USB node in FSL's ls1012a DTS

[Changming Huang]

Add USB node in ls1012a device tree

Signed-off-by: Changming Huang 
---
Dependence on patch "[v3] arm64: Add DTS support for FSL's LS1012A SoC".
https://patchwork.kernel.org/patch/9462399/

 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 92e64f3..3e4bda6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -235,6 +235,23 @@
 < 4 3>;
};
 
+   usb0: usb3@2f0 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x2f0 0x0 0x1>;
+   interrupts = <0 60 0x4>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   };
+
+   usb1: usb2@860 {
+   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+   };
+
sata: sata@320 {
compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
reg = <0x0 0x320 0x0 0x1>;
-- 
1.7.9.5

[PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

[kys]

From: Haiyang Zhang 

We currently use MAC address to match VF and synthetic NICs. Hyper-V
provides a serial number to both devices for this purpose. This patch
implements the matching based on VF serial numbers. This is the way
specified by the protocol and more reliable.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/netvsc_drv.c |   55 ---
 1 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 9522763..c5778cf 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1165,9 +1165,10 @@ static void netvsc_free_netdev(struct net_device *netdev)
free_netdev(netdev);
 }
 
-static struct net_device *get_netvsc_bymac(const u8 *mac)
+static struct net_device *get_netvsc_byvfser(u32 vfser)
 {
struct net_device *dev;
+   struct net_device_context *ndev_ctx;
 
ASSERT_RTNL();
 
@@ -1175,7 +1176,8 @@ static void netvsc_free_netdev(struct net_device *netdev)
if (dev->netdev_ops != _ops)
continue;   /* not a netvsc device */
 
-   if (ether_addr_equal(mac, dev->perm_addr))
+   ndev_ctx = netdev_priv(dev);
+   if (ndev_ctx->vf_serial == vfser)
return dev;
}
 
@@ -1205,21 +1207,66 @@ static void netvsc_free_netdev(struct net_device 
*netdev)
return NULL;
 }
 
+static u32 netvsc_get_vfser(struct net_device *vf_netdev)
+{
+   struct device *dev;
+   struct hv_device *hdev;
+   struct hv_pcibus_device *hbus = NULL;
+   struct list_head *iter;
+   struct hv_pci_dev *hpdev;
+   unsigned long flags;
+   u32 vfser = 0;
+   u32 count = 0;
+
+   for (dev = _netdev->dev; dev; dev = dev->parent) {
+   if (!dev_is_vmbus(dev))
+   continue;
+
+   hdev = device_to_hv_device(dev);
+   if (hdev->device_id != HV_PCIE)
+   continue;
+
+   hbus = hv_get_drvdata(hdev);
+   break;
+   }
+
+   if (!hbus)
+   return 0;
+
+   spin_lock_irqsave(>device_list_lock, flags);
+   list_for_each(iter, >children) {
+   hpdev = container_of(iter, struct hv_pci_dev, list_entry);
+   vfser = hpdev->desc.ser;
+   count++;
+   }
+   spin_unlock_irqrestore(>device_list_lock, flags);
+
+   if (count == 1)
+   return vfser;
+
+   return 0;
+}
+
 static int netvsc_register_vf(struct net_device *vf_netdev)
 {
struct net_device *ndev;
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
+   u32 vfser;
 
if (vf_netdev->addr_len != ETH_ALEN)
return NOTIFY_DONE;
 
+   vfser = netvsc_get_vfser(vf_netdev);
+   if (!vfser)
+   return NOTIFY_DONE;
+
/*
-* We will use the MAC address to locate the synthetic interface to
+* We will use the VF serial to locate the synthetic interface to
 * associate with the VF interface. If we don't find a matching
 * synthetic interface, move on.
 */
-   ndev = get_netvsc_bymac(vf_netdev->perm_addr);
+   ndev = get_netvsc_byvfser(vfser);
if (!ndev)
return NOTIFY_DONE;
 
-- 
1.7.4.1

[PATCH] fsl/usb: Add USB node in FSL's ls1012a DTS

[Changming Huang]

Add USB node in ls1012a device tree

Signed-off-by: Changming Huang 
---
Dependence on patch "[v3] arm64: Add DTS support for FSL's LS1012A SoC".
https://patchwork.kernel.org/patch/9462399/

 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 92e64f3..3e4bda6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -235,6 +235,23 @@
 < 4 3>;
};
 
+   usb0: usb3@2f0 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x2f0 0x0 0x1>;
+   interrupts = <0 60 0x4>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   };
+
+   usb1: usb2@860 {
+   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+   };
+
sata: sata@320 {
compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
reg = <0x0 0x320 0x0 0x1>;
-- 
1.7.9.5

[PATCH 2/3] hyperv: Add a function to detect if the device is a vmbus dev

[kys]

From: Haiyang Zhang 

On Hyper-V, every VF interface has a corresponding synthetic
interface managed by netvsc that share the same MAC
address. netvsc registers for netdev events to manage this
association. Currently we use the MAC address to manage this
association but going forward, we want to use a serial number that
the host publishes. To do this we need functionality similar
to dev_is_pci() for the vmbus devices. Implement such a function.

This function will be used in subsequent patches to netvsc and in the
interest of eliminating cross tree dependencies, this patch is being
submitted first.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/vmbus_drv.c |6 ++
 include/linux/hyperv.h |2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 230c62e..64c40f3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -845,6 +845,12 @@ struct onmessage_work_context {
struct hv_message msg;
 };
 
+bool dev_is_vmbus(struct device *dev)
+{
+   return dev->bus == _bus;
+}
+EXPORT_SYMBOL_GPL(dev_is_vmbus);
+
 static void vmbus_onmessage_work(struct work_struct *work)
 {
struct onmessage_work_context *ctx;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index ff6cd3e..2abb1bf 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -947,6 +947,8 @@ static inline void clear_low_latency_mode(struct 
vmbus_channel *c)
c->low_latency = false;
 }
 
+bool dev_is_vmbus(struct device *dev);
+
 void vmbus_onmessage(void *context);
 
 int vmbus_request_offers(void);
-- 
1.7.4.1

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Bart Van Assche]

On 12/07/16 21:54, Michael S. Tsirkin wrote:
> On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
>> Additionally, there are notable exceptions to the rule that most drivers
>> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
>> would remain possible to check such drivers with sparse without enabling
>> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
>> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
>
> The right thing is probably just to fix these, isn't it?
> Until then, why not just ignore the warnings?

Neither option is realistic. With endian-checking enabled the qla2xxx 
driver triggers so many warnings that it becomes a real challenge to 
filter the non-endian warnings out manually:

$ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
 $f |  -c ': warning:'; done
4
752

If you think it would be easy to fix the endian warnings triggered by 
the qla2xxx driver, you are welcome to try to fix these.

Bart.

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Bart Van Assche]

On 12/07/16 21:54, Michael S. Tsirkin wrote:
> On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
>> Additionally, there are notable exceptions to the rule that most drivers
>> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
>> would remain possible to check such drivers with sparse without enabling
>> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
>> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
>
> The right thing is probably just to fix these, isn't it?
> Until then, why not just ignore the warnings?

Neither option is realistic. With endian-checking enabled the qla2xxx 
driver triggers so many warnings that it becomes a real challenge to 
filter the non-endian warnings out manually:

$ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
 $f |  -c ': warning:'; done
4
752

If you think it would be easy to fix the endian warnings triggered by 
the qla2xxx driver, you are welcome to try to fix these.

Bart.

[PATCH 2/3] hyperv: Add a function to detect if the device is a vmbus dev

[kys]

From: Haiyang Zhang 

On Hyper-V, every VF interface has a corresponding synthetic
interface managed by netvsc that share the same MAC
address. netvsc registers for netdev events to manage this
association. Currently we use the MAC address to manage this
association but going forward, we want to use a serial number that
the host publishes. To do this we need functionality similar
to dev_is_pci() for the vmbus devices. Implement such a function.

This function will be used in subsequent patches to netvsc and in the
interest of eliminating cross tree dependencies, this patch is being
submitted first.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/vmbus_drv.c |6 ++
 include/linux/hyperv.h |2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 230c62e..64c40f3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -845,6 +845,12 @@ struct onmessage_work_context {
struct hv_message msg;
 };
 
+bool dev_is_vmbus(struct device *dev)
+{
+   return dev->bus == _bus;
+}
+EXPORT_SYMBOL_GPL(dev_is_vmbus);
+
 static void vmbus_onmessage_work(struct work_struct *work)
 {
struct onmessage_work_context *ctx;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index ff6cd3e..2abb1bf 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -947,6 +947,8 @@ static inline void clear_low_latency_mode(struct 
vmbus_channel *c)
c->low_latency = false;
 }
 
+bool dev_is_vmbus(struct device *dev);
+
 void vmbus_onmessage(void *context);
 
 int vmbus_request_offers(void);
-- 
1.7.4.1

[PATCH 1/3] hyperv: Move hv_pci_dev and related structs to hyperv.h

[kys]

From: Haiyang Zhang 

Move some vPCI data structures to hyperv.h,
because we share them with other module.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/pci/host/pci-hyperv.c |   91 --
 include/linux/hyperv.h|   98 -
 2 files changed, 97 insertions(+), 92 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index a63c3a4..7a97b4f 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -49,12 +49,10 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -122,35 +120,6 @@ enum pci_message_type {
u32 version;
 } __packed;
 
-/*
- * Function numbers are 8-bits wide on Express, as interpreted through ARI,
- * which is all this driver does.  This representation is the one used in
- * Windows, which is what is expected when sending this back and forth with
- * the Hyper-V parent partition.
- */
-union win_slot_encoding {
-   struct {
-   u32 func:8;
-   u32 reserved:24;
-   } bits;
-   u32 slot;
-} __packed;
-
-/*
- * Pretty much as defined in the PCI Specifications.
- */
-struct pci_function_description {
-   u16 v_id;   /* vendor ID */
-   u16 d_id;   /* device ID */
-   u8  rev;
-   u8  prog_intf;
-   u8  subclass;
-   u8  base_class;
-   u32 subsystem_id;
-   union win_slot_encoding win_slot;
-   u32 ser;/* serial number */
-} __packed;
-
 /**
  * struct hv_msi_desc
  * @vector:IDT entry
@@ -345,41 +314,6 @@ struct retarget_msi_interrupt {
  * Driver specific state.
  */
 
-enum hv_pcibus_state {
-   hv_pcibus_init = 0,
-   hv_pcibus_probed,
-   hv_pcibus_installed,
-   hv_pcibus_maximum
-};
-
-struct hv_pcibus_device {
-   struct pci_sysdata sysdata;
-   enum hv_pcibus_state state;
-   atomic_t remove_lock;
-   struct hv_device *hdev;
-   resource_size_t low_mmio_space;
-   resource_size_t high_mmio_space;
-   struct resource *mem_config;
-   struct resource *low_mmio_res;
-   struct resource *high_mmio_res;
-   struct completion *survey_event;
-   struct completion remove_event;
-   struct pci_bus *pci_bus;
-   spinlock_t config_lock; /* Avoid two threads writing index page */
-   spinlock_t device_list_lock;/* Protect lists below */
-   void __iomem *cfg_addr;
-
-   struct semaphore enum_sem;
-   struct list_head resources_for_children;
-
-   struct list_head children;
-   struct list_head dr_list;
-
-   struct msi_domain_info msi_info;
-   struct msi_controller msi_chip;
-   struct irq_domain *irq_domain;
-};
-
 /*
  * Tracks "Device Relations" messages from the host, which must be both
  * processed in order and deferred so that they don't run in the context
@@ -396,14 +330,6 @@ struct hv_dr_state {
struct pci_function_description func[0];
 };
 
-enum hv_pcichild_state {
-   hv_pcichild_init = 0,
-   hv_pcichild_requirements,
-   hv_pcichild_resourced,
-   hv_pcichild_ejecting,
-   hv_pcichild_maximum
-};
-
 enum hv_pcidev_ref_reason {
hv_pcidev_ref_invalid = 0,
hv_pcidev_ref_initial,
@@ -415,23 +341,6 @@ enum hv_pcidev_ref_reason {
hv_pcidev_ref_max
 };
 
-struct hv_pci_dev {
-   /* List protected by pci_rescan_remove_lock */
-   struct list_head list_entry;
-   atomic_t refs;
-   enum hv_pcichild_state state;
-   struct pci_function_description desc;
-   bool reported_missing;
-   struct hv_pcibus_device *hbus;
-   struct work_struct wrk;
-
-   /*
-* What would be observed if one wrote 0x to a BAR and then
-* read it back, for each of the BAR offsets within config space.
-*/
-   u32 probed_bar[6];
-};
-
 struct hv_pci_compl {
struct completion host_event;
s32 completion_status;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 42fe43f..ff6cd3e 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -36,7 +36,8 @@
 #include 
 #include 
 #include 
-
+#include 
+#include 
 
 #define MAX_PAGE_BUFFER_COUNT  32
 #define MAX_MULTIPAGE_BUFFER_COUNT 32 /* 128K */
@@ -1590,5 +1591,100 @@ static inline void commit_rd_index(struct vmbus_channel 
*channel)
hv_signal_on_read(channel);
 }
 
+/* vPCI structures */
+
+/*
+ * Function numbers are 8-bits wide on Express, as interpreted through ARI,
+ * which is all this driver does.  This representation is the one used in
+ * Windows, which is what is expected when sending this back and forth with
+ * the Hyper-V parent partition.
+ */
+union win_slot_encoding {
+   struct {
+   u32 func:8;

[PATCH 1/3] hyperv: Move hv_pci_dev and related structs to hyperv.h

[kys]

From: Haiyang Zhang 

Move some vPCI data structures to hyperv.h,
because we share them with other module.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/pci/host/pci-hyperv.c |   91 --
 include/linux/hyperv.h|   98 -
 2 files changed, 97 insertions(+), 92 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index a63c3a4..7a97b4f 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -49,12 +49,10 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -122,35 +120,6 @@ enum pci_message_type {
u32 version;
 } __packed;
 
-/*
- * Function numbers are 8-bits wide on Express, as interpreted through ARI,
- * which is all this driver does.  This representation is the one used in
- * Windows, which is what is expected when sending this back and forth with
- * the Hyper-V parent partition.
- */
-union win_slot_encoding {
-   struct {
-   u32 func:8;
-   u32 reserved:24;
-   } bits;
-   u32 slot;
-} __packed;
-
-/*
- * Pretty much as defined in the PCI Specifications.
- */
-struct pci_function_description {
-   u16 v_id;   /* vendor ID */
-   u16 d_id;   /* device ID */
-   u8  rev;
-   u8  prog_intf;
-   u8  subclass;
-   u8  base_class;
-   u32 subsystem_id;
-   union win_slot_encoding win_slot;
-   u32 ser;/* serial number */
-} __packed;
-
 /**
  * struct hv_msi_desc
  * @vector:IDT entry
@@ -345,41 +314,6 @@ struct retarget_msi_interrupt {
  * Driver specific state.
  */
 
-enum hv_pcibus_state {
-   hv_pcibus_init = 0,
-   hv_pcibus_probed,
-   hv_pcibus_installed,
-   hv_pcibus_maximum
-};
-
-struct hv_pcibus_device {
-   struct pci_sysdata sysdata;
-   enum hv_pcibus_state state;
-   atomic_t remove_lock;
-   struct hv_device *hdev;
-   resource_size_t low_mmio_space;
-   resource_size_t high_mmio_space;
-   struct resource *mem_config;
-   struct resource *low_mmio_res;
-   struct resource *high_mmio_res;
-   struct completion *survey_event;
-   struct completion remove_event;
-   struct pci_bus *pci_bus;
-   spinlock_t config_lock; /* Avoid two threads writing index page */
-   spinlock_t device_list_lock;/* Protect lists below */
-   void __iomem *cfg_addr;
-
-   struct semaphore enum_sem;
-   struct list_head resources_for_children;
-
-   struct list_head children;
-   struct list_head dr_list;
-
-   struct msi_domain_info msi_info;
-   struct msi_controller msi_chip;
-   struct irq_domain *irq_domain;
-};
-
 /*
  * Tracks "Device Relations" messages from the host, which must be both
  * processed in order and deferred so that they don't run in the context
@@ -396,14 +330,6 @@ struct hv_dr_state {
struct pci_function_description func[0];
 };
 
-enum hv_pcichild_state {
-   hv_pcichild_init = 0,
-   hv_pcichild_requirements,
-   hv_pcichild_resourced,
-   hv_pcichild_ejecting,
-   hv_pcichild_maximum
-};
-
 enum hv_pcidev_ref_reason {
hv_pcidev_ref_invalid = 0,
hv_pcidev_ref_initial,
@@ -415,23 +341,6 @@ enum hv_pcidev_ref_reason {
hv_pcidev_ref_max
 };
 
-struct hv_pci_dev {
-   /* List protected by pci_rescan_remove_lock */
-   struct list_head list_entry;
-   atomic_t refs;
-   enum hv_pcichild_state state;
-   struct pci_function_description desc;
-   bool reported_missing;
-   struct hv_pcibus_device *hbus;
-   struct work_struct wrk;
-
-   /*
-* What would be observed if one wrote 0x to a BAR and then
-* read it back, for each of the BAR offsets within config space.
-*/
-   u32 probed_bar[6];
-};
-
 struct hv_pci_compl {
struct completion host_event;
s32 completion_status;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 42fe43f..ff6cd3e 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -36,7 +36,8 @@
 #include 
 #include 
 #include 
-
+#include 
+#include 
 
 #define MAX_PAGE_BUFFER_COUNT  32
 #define MAX_MULTIPAGE_BUFFER_COUNT 32 /* 128K */
@@ -1590,5 +1591,100 @@ static inline void commit_rd_index(struct vmbus_channel 
*channel)
hv_signal_on_read(channel);
 }
 
+/* vPCI structures */
+
+/*
+ * Function numbers are 8-bits wide on Express, as interpreted through ARI,
+ * which is all this driver does.  This representation is the one used in
+ * Windows, which is what is expected when sending this back and forth with
+ * the Hyper-V parent partition.
+ */
+union win_slot_encoding {
+   struct {
+   u32 func:8;
+   u32 reserved:24;
+   } bits;
+   u32 

[PATCH 0/3] Drivers: hv: Implement VF association based on serial number

[kys]

From: K. Y. Srinivasan 

Implement VF association based on serial number published by
the host.

Greg, as promised here is the patchset that would use the API for
detecting if the device is a vmbus device.
If you can take the first two patches, we can submit the netvsc
patch to the net-next tree.

Haiyang Zhang (3):
  hyperv: Move hv_pci_dev and related structs to hyperv.h
  hyperv: Add a function to detect if the device is a vmbus dev
  hv_netvsc: Implement VF matching based on serial numbers

 drivers/hv/vmbus_drv.c  |6 ++
 drivers/net/hyperv/netvsc_drv.c |   55 --
 drivers/pci/host/pci-hyperv.c   |   91 ---
 include/linux/hyperv.h  |  100 ++-
 4 files changed, 156 insertions(+), 96 deletions(-)

-- 
1.7.4.1

[PATCH 0/3] Drivers: hv: Implement VF association based on serial number

[kys]

From: K. Y. Srinivasan 

Implement VF association based on serial number published by
the host.

Greg, as promised here is the patchset that would use the API for
detecting if the device is a vmbus device.
If you can take the first two patches, we can submit the netvsc
patch to the net-next tree.

Haiyang Zhang (3):
  hyperv: Move hv_pci_dev and related structs to hyperv.h
  hyperv: Add a function to detect if the device is a vmbus dev
  hv_netvsc: Implement VF matching based on serial numbers

 drivers/hv/vmbus_drv.c  |6 ++
 drivers/net/hyperv/netvsc_drv.c |   55 --
 drivers/pci/host/pci-hyperv.c   |   91 ---
 include/linux/hyperv.h  |  100 ++-
 4 files changed, 156 insertions(+), 96 deletions(-)

-- 
1.7.4.1

答复: [PATCH] fuse: freezing abort when use wait_event_killable{,_exclusive}().

[崔立飞]

Hi Rafael,

The fuse we used is without the commit "fuse: don't mess with blocking signals" 
committed by Al Viro.
So we find the issue SIGBUS. In the page fault, trying to read page in fuse is 
interrupted,
which will lead to SIGBUS issue.

All Android platforms, include Android N, have the SIGUBS issue. All the SIGBUS 
issues are produced
in the freezing process.

In our Android platform, the root-cause of SIGBUS is :
suspend procedure will set the signal pending flag(TIF_SIGPENDING) and then 
wake up the task
which is TASK_INTERRUPTIBLE status . The request_wait_answer, which calls 
wait_event_interruptible,
is interrupted and the fuse request is still in pending status, which leads to 
SIGBUS sent to caller.

This issue can be reproduced by adding delays in funciton handle_read,
which is in the Android sdcard daemon process.

So we merge the commit "fuse: don't mess with blocking signals", which just use 
wait_event_killable{,_exclusive}().
It fix the SIGBUS issue. But the freezing will fail, because the freezing 
procedure cannot wake up the task which
is in TASK_KILLABLE(TASK_WAKEKILL | TASK_UNINTERRUPTIBLE) status. And the 
suspend procedure will abort
until the time is out.

In this patch, we try to fix the issue mentioned above.
> ---
>   fs/fuse/dev.c   | 30 ++
>   include/linux/freezer.h | 26 ++
>   2 files changed, 52 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 70ea57c..e33a081 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -19,6 +19,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   MODULE_ALIAS_MISCDEV(FUSE_MINOR);
>   MODULE_ALIAS("devname:fuse");
> @@ -99,6 +100,19 @@ void fuse_request_free(struct fuse_req *req)
> kmem_cache_free(fuse_req_cachep, req);
>   }
>   
> +static void block_sigs(sigset_t *oldset)
> +{
> + sigset_t mask;
> +
> + siginitsetinv(, sigmask(SIGKILL));
> + sigprocmask(SIG_BLOCK, , oldset);
> +}
> +
> +static void restore_sigs(sigset_t *oldset)
> +{
> + sigprocmask(SIG_SETMASK, oldset, NULL);
> +}
> +
>   void __fuse_get_request(struct fuse_req *req)
>   {
> atomic_inc(>count);
> @@ -134,13 +148,18 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn 
> *fc, unsigned npages,
>    bool for_background)
>   {
> struct fuse_req *req;
> + sigset_t oldset;
> + int intr;
> int err;
> atomic_inc(>num_waiting);
>   
> if (fuse_block_alloc(fc, for_background)) {
> err = -EINTR;
> - if (wait_event_killable_exclusive(fc->blocked_waitq,
> - !fuse_block_alloc(fc, for_background)))
> + block_sigs();
> + intr = wait_fatal_freezable(fc->blocked_waitq,
> + !fuse_block_alloc(fc, for_background), true);
> + restore_sigs();
> + if (intr)
> goto out;
> }
> /* Matches smp_wmb() in fuse_set_initialized() */
> @@ -427,9 +446,12 @@ static void request_wait_answer(struct fuse_conn *fc, 
> struct fuse_req *req)
> }
>   
> if (!test_bit(FR_FORCE, >flags)) {
> + sigset_t oldset;
> /* Only fatal signals may interrupt this */
> - err = wait_event_killable(req->waitq,
> - test_bit(FR_FINISHED, >flags));
> + block_sigs();
> + err = wait_fatal_freezable(req->waitq,
> + test_bit(FR_FINISHED, >flags), false);
> + restore_sigs();
> if (!err)
> return;
>   
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index dd03e83..2504cd0 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -256,6 +256,22 @@ static inline int 
> freezable_schedule_hrtimeout_range(ktime_t *expires,
> __retval;   \
>   })
>   
> +#define wait_fatal_freezable(wq, condition, exclusive)   
> \
> +({   \
> + int __ret = 0;  \
> + do {    \
> + if (exclusive)  \
> + __ret = wait_event_interruptible_exclusive(wq,  \
> //set the TASK_INTERRUPTIBLE
> + condition); \   
> //can be waked up by suspend procedure
> + else    \
> + __ret = wait_event_interruptible(wq,    \
> + condition); \
> + if (!__ret || fatal_signal_pending(current))    \ 

答复: [PATCH] fuse: freezing abort when use wait_event_killable{,_exclusive}().

[崔立飞]

Hi Rafael,

The fuse we used is without the commit "fuse: don't mess with blocking signals" 
committed by Al Viro.
So we find the issue SIGBUS. In the page fault, trying to read page in fuse is 
interrupted,
which will lead to SIGBUS issue.

All Android platforms, include Android N, have the SIGUBS issue. All the SIGBUS 
issues are produced
in the freezing process.

In our Android platform, the root-cause of SIGBUS is :
suspend procedure will set the signal pending flag(TIF_SIGPENDING) and then 
wake up the task
which is TASK_INTERRUPTIBLE status . The request_wait_answer, which calls 
wait_event_interruptible,
is interrupted and the fuse request is still in pending status, which leads to 
SIGBUS sent to caller.

This issue can be reproduced by adding delays in funciton handle_read,
which is in the Android sdcard daemon process.

So we merge the commit "fuse: don't mess with blocking signals", which just use 
wait_event_killable{,_exclusive}().
It fix the SIGBUS issue. But the freezing will fail, because the freezing 
procedure cannot wake up the task which
is in TASK_KILLABLE(TASK_WAKEKILL | TASK_UNINTERRUPTIBLE) status. And the 
suspend procedure will abort
until the time is out.

In this patch, we try to fix the issue mentioned above.
> ---
>   fs/fuse/dev.c   | 30 ++
>   include/linux/freezer.h | 26 ++
>   2 files changed, 52 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 70ea57c..e33a081 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -19,6 +19,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   MODULE_ALIAS_MISCDEV(FUSE_MINOR);
>   MODULE_ALIAS("devname:fuse");
> @@ -99,6 +100,19 @@ void fuse_request_free(struct fuse_req *req)
> kmem_cache_free(fuse_req_cachep, req);
>   }
>   
> +static void block_sigs(sigset_t *oldset)
> +{
> + sigset_t mask;
> +
> + siginitsetinv(, sigmask(SIGKILL));
> + sigprocmask(SIG_BLOCK, , oldset);
> +}
> +
> +static void restore_sigs(sigset_t *oldset)
> +{
> + sigprocmask(SIG_SETMASK, oldset, NULL);
> +}
> +
>   void __fuse_get_request(struct fuse_req *req)
>   {
> atomic_inc(>count);
> @@ -134,13 +148,18 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn 
> *fc, unsigned npages,
>    bool for_background)
>   {
> struct fuse_req *req;
> + sigset_t oldset;
> + int intr;
> int err;
> atomic_inc(>num_waiting);
>   
> if (fuse_block_alloc(fc, for_background)) {
> err = -EINTR;
> - if (wait_event_killable_exclusive(fc->blocked_waitq,
> - !fuse_block_alloc(fc, for_background)))
> + block_sigs();
> + intr = wait_fatal_freezable(fc->blocked_waitq,
> + !fuse_block_alloc(fc, for_background), true);
> + restore_sigs();
> + if (intr)
> goto out;
> }
> /* Matches smp_wmb() in fuse_set_initialized() */
> @@ -427,9 +446,12 @@ static void request_wait_answer(struct fuse_conn *fc, 
> struct fuse_req *req)
> }
>   
> if (!test_bit(FR_FORCE, >flags)) {
> + sigset_t oldset;
> /* Only fatal signals may interrupt this */
> - err = wait_event_killable(req->waitq,
> - test_bit(FR_FINISHED, >flags));
> + block_sigs();
> + err = wait_fatal_freezable(req->waitq,
> + test_bit(FR_FINISHED, >flags), false);
> + restore_sigs();
> if (!err)
> return;
>   
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index dd03e83..2504cd0 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -256,6 +256,22 @@ static inline int 
> freezable_schedule_hrtimeout_range(ktime_t *expires,
> __retval;   \
>   })
>   
> +#define wait_fatal_freezable(wq, condition, exclusive)   
> \
> +({   \
> + int __ret = 0;  \
> + do {    \
> + if (exclusive)  \
> + __ret = wait_event_interruptible_exclusive(wq,  \
> //set the TASK_INTERRUPTIBLE
> + condition); \   
> //can be waked up by suspend procedure
> + else    \
> + __ret = wait_event_interruptible(wq,    \
> + condition); \
> + if (!__ret || fatal_signal_pending(current))    \ 

[PATCH] ASoC: Intel: Skylake: remove unused 'runtime' variable

[Kirtika Ruchandani]

skl_platform_open() defines and sets 'struct snd_pcm_runtime* runtime'
but does not use it. Compiling with W=1 gives the following warning,
fix it.

sound/soc/intel/skylake/skl-pcm.c: In function ‘skl_platform_open’:
sound/soc/intel/skylake/skl-pcm.c:941:26: warning: variable ‘runtime’ set but 
not used [-Wunused-but-set-variable]

This was introduced with the initial driver commit a40e693c7f5e
("ASoC: Intel: Add Skylake HDA platform driver").
This is a harmless warning and is only being fixed to reduce the noise
with W=1 in the kernel.

Fixes: a40e693c7f5e ("ASoC: Intel: Add Skylake HDA platform driver")
Cc: Jeeja KP 
Cc: Subhransu S. Prusty 
Cc: Vinod Koul 
Cc: Mark Brown 
Signed-off-by: Kirtika Ruchandani 
---
 sound/soc/intel/skylake/skl-pcm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-pcm.c 
b/sound/soc/intel/skylake/skl-pcm.c
index 84b5101..3254507 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -938,14 +938,12 @@ static struct snd_soc_dai_driver skl_platform_dai[] = {

 static int skl_platform_open(struct snd_pcm_substream *substream)
 {
-   struct snd_pcm_runtime *runtime;
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_dai_link *dai_link = rtd->dai_link;

dev_dbg(rtd->cpu_dai->dev, "In %s:%s\n", __func__,
dai_link->cpu_dai_name);

-   runtime = substream->runtime;
snd_soc_set_runtime_hwparams(substream, _pcm_hw);

return 0;
--
2.8.0.rc3.226.g39d4020

[PATCH] ASoC: Intel: Skylake: remove unused 'runtime' variable

[Kirtika Ruchandani]

skl_platform_open() defines and sets 'struct snd_pcm_runtime* runtime'
but does not use it. Compiling with W=1 gives the following warning,
fix it.

sound/soc/intel/skylake/skl-pcm.c: In function ‘skl_platform_open’:
sound/soc/intel/skylake/skl-pcm.c:941:26: warning: variable ‘runtime’ set but 
not used [-Wunused-but-set-variable]

This was introduced with the initial driver commit a40e693c7f5e
("ASoC: Intel: Add Skylake HDA platform driver").
This is a harmless warning and is only being fixed to reduce the noise
with W=1 in the kernel.

Fixes: a40e693c7f5e ("ASoC: Intel: Add Skylake HDA platform driver")
Cc: Jeeja KP 
Cc: Subhransu S. Prusty 
Cc: Vinod Koul 
Cc: Mark Brown 
Signed-off-by: Kirtika Ruchandani 
---
 sound/soc/intel/skylake/skl-pcm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-pcm.c 
b/sound/soc/intel/skylake/skl-pcm.c
index 84b5101..3254507 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -938,14 +938,12 @@ static struct snd_soc_dai_driver skl_platform_dai[] = {

 static int skl_platform_open(struct snd_pcm_substream *substream)
 {
-   struct snd_pcm_runtime *runtime;
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_dai_link *dai_link = rtd->dai_link;

dev_dbg(rtd->cpu_dai->dev, "In %s:%s\n", __func__,
dai_link->cpu_dai_name);

-   runtime = substream->runtime;
snd_soc_set_runtime_hwparams(substream, _pcm_hw);

return 0;
--
2.8.0.rc3.226.g39d4020

Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu()

[Ian Kent]

On Thu, 2016-12-08 at 17:28 +1300, Eric W. Biederman wrote:
> Ian Kent  writes:
> 
> > On Thu, 2016-12-08 at 10:30 +1300, Eric W. Biederman wrote:
> > > Ian Kent  writes:
> > > 
> > > > On Sat, 2016-12-03 at 05:13 +, Al Viro wrote:
> > > > >   FWIW, I've folded that pile into vfs.git#work.autofs.
> > > > > 
> > > > > Problems:
> > > > 
> > > > snip ...
> > > > 
> > > > >   * the last one (propagation-related) is too ugly to live - at
> > > > > the
> > > > > very least, its pieces should live in fs/pnode.c; exposing
> > > > > propagate_next()
> > > > > is simply wrong.  I hadn't picked that one at all, and I would suggest
> > > > > coordinating anything in that area with ebiederman - he has some work
> > > > > around fs/pnode.c and you risk stepping on his toes.
> > > > 
> > > > The earlier patches seem to be ok now so how about we talk a little
> > > > about
> > > > this
> > > > last one.
> > > > 
> > > > Eric, Al mentioned that you are working with fs/pnode.c and recommended
> > > > I
> > > > co-
> > > > ordinate with you.
> > > > 
> > > > So is my working on this this (which is most likely going to live in
> > > > pnode.c
> > > > if
> > > > I can can get something acceptable) going to cause complications for
> > > > you?
> > > > Is what your doing at a point were it would be worth doing as Al
> > > > suggests?
> > > > 
> > > > Anyway, the problem that this patch is supposed to solve is to check if
> > > > any
> > > > of
> > > > the list of mnt_mounts or any of the mounts propagated from each are in
> > > > use.
> > > > 
> > > > One obvious problem with it is the propagation could be very large.
> > > > 
> > > > But now I look at it again there's no reason to have to every tree
> > > > because
> > > > if
> > > > one tree is busy then the the set of trees is busy. But every tree would
> > > > be
> > > > visited if the not busy so it's perhaps still a problem.
> > > > 
> > > > The difficult thing is working out if a tree is busy, more so because
> > > > there
> > > > could be a struct path holding references within any the trees so I
> > > > don't
> > > > know
> > > > of a simpler, more efficient way to check for this.
> > > 
> > > So coordination seems to be in order.  Not so much because of your
> > > current implementation (which won't tell you what you want to know)
> > 
> > Umm ... ok I've missed something then because the patch I posted does appear
> > to
> > get the calculation right. Perhaps I've missed a case where it gets it wrong
> > 
> > 
> > But now I'm looking deeper into it I'm beginning to wonder why it worked for
> > one
> > of the cases. Maybe I need to do some more tests with even more
> > printks.
> 
> So the case that I am concerned about is that if someone happens to do
> mount --bind the mount propagation trees would not just be mirror images
> in single filesystems but have leaves in odd places.
> 
> Consider .../base/one/two (where one and two are automounts) and base
> is the shared mountpoint that is propagated between namespaces.
> 
> If someone does mount --bind .../base/one ../somepath/one in any
> namespace then there will be places where an unmount of "two" will
> propagate to, but that an unmount of "one" won't as their respective
> propagation trees are different.
> 
> Not accounting for different mount points having different propagation
> trees is what I meant when I said your code was wrong.

Yeah, it's all too easy for me to miss important cases like this because such
things are not allowed (or rather not supported, since it can be done) within
automount managed directories. Even without propagation it can be problematic.

But you're right, that's no excuse for a VFS function to not cater for, or at
least handle sensibly, cases like this.

> 
> > > but because an implementation that tells you what you are looking for
> > > has really bad > O(N^2) complexity walking the propagation tree in
> > > the worst case.
> > 
> > Yes it is bad indeed.
> > 
> > > 
> > > To be correct you code would need to use next_mnt and walk the tree and
> > > on each mount use propagate_mnt_busy to see if that entry can be
> > > unmounted.  Possibly with small variations to match your case.  Mounts
> > > in one part of the tree may propagate to places that mounts in other
> > > parts of the tree will not.
> > 
> > Right, the point there being use propagate_mnt_busy() for the check.
> 
> Or a variant of propagate_mnt_busy.
> 
> > I tried to use that when I started this but had trouble, I'll have another
> > look
> > at using it.
> > 
> > I thought the reason I couldn't use propagate_mnt_busy() is because it will
> > see
> > any mount with submounts as busy and that's not what's need. It's mounts
> > below
> > each of mounts having submounts that make them busy in my case.
> 
> If you have the count of submounts passed into propagate_mnt_busy() it
> will come very close to what you need.  It is still possible to have
> false positives in the 

Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu()

[Ian Kent]

On Thu, 2016-12-08 at 17:28 +1300, Eric W. Biederman wrote:
> Ian Kent  writes:
> 
> > On Thu, 2016-12-08 at 10:30 +1300, Eric W. Biederman wrote:
> > > Ian Kent  writes:
> > > 
> > > > On Sat, 2016-12-03 at 05:13 +, Al Viro wrote:
> > > > >   FWIW, I've folded that pile into vfs.git#work.autofs.
> > > > > 
> > > > > Problems:
> > > > 
> > > > snip ...
> > > > 
> > > > >   * the last one (propagation-related) is too ugly to live - at
> > > > > the
> > > > > very least, its pieces should live in fs/pnode.c; exposing
> > > > > propagate_next()
> > > > > is simply wrong.  I hadn't picked that one at all, and I would suggest
> > > > > coordinating anything in that area with ebiederman - he has some work
> > > > > around fs/pnode.c and you risk stepping on his toes.
> > > > 
> > > > The earlier patches seem to be ok now so how about we talk a little
> > > > about
> > > > this
> > > > last one.
> > > > 
> > > > Eric, Al mentioned that you are working with fs/pnode.c and recommended
> > > > I
> > > > co-
> > > > ordinate with you.
> > > > 
> > > > So is my working on this this (which is most likely going to live in
> > > > pnode.c
> > > > if
> > > > I can can get something acceptable) going to cause complications for
> > > > you?
> > > > Is what your doing at a point were it would be worth doing as Al
> > > > suggests?
> > > > 
> > > > Anyway, the problem that this patch is supposed to solve is to check if
> > > > any
> > > > of
> > > > the list of mnt_mounts or any of the mounts propagated from each are in
> > > > use.
> > > > 
> > > > One obvious problem with it is the propagation could be very large.
> > > > 
> > > > But now I look at it again there's no reason to have to every tree
> > > > because
> > > > if
> > > > one tree is busy then the the set of trees is busy. But every tree would
> > > > be
> > > > visited if the not busy so it's perhaps still a problem.
> > > > 
> > > > The difficult thing is working out if a tree is busy, more so because
> > > > there
> > > > could be a struct path holding references within any the trees so I
> > > > don't
> > > > know
> > > > of a simpler, more efficient way to check for this.
> > > 
> > > So coordination seems to be in order.  Not so much because of your
> > > current implementation (which won't tell you what you want to know)
> > 
> > Umm ... ok I've missed something then because the patch I posted does appear
> > to
> > get the calculation right. Perhaps I've missed a case where it gets it wrong
> > 
> > 
> > But now I'm looking deeper into it I'm beginning to wonder why it worked for
> > one
> > of the cases. Maybe I need to do some more tests with even more
> > printks.
> 
> So the case that I am concerned about is that if someone happens to do
> mount --bind the mount propagation trees would not just be mirror images
> in single filesystems but have leaves in odd places.
> 
> Consider .../base/one/two (where one and two are automounts) and base
> is the shared mountpoint that is propagated between namespaces.
> 
> If someone does mount --bind .../base/one ../somepath/one in any
> namespace then there will be places where an unmount of "two" will
> propagate to, but that an unmount of "one" won't as their respective
> propagation trees are different.
> 
> Not accounting for different mount points having different propagation
> trees is what I meant when I said your code was wrong.

Yeah, it's all too easy for me to miss important cases like this because such
things are not allowed (or rather not supported, since it can be done) within
automount managed directories. Even without propagation it can be problematic.

But you're right, that's no excuse for a VFS function to not cater for, or at
least handle sensibly, cases like this.

> 
> > > but because an implementation that tells you what you are looking for
> > > has really bad > O(N^2) complexity walking the propagation tree in
> > > the worst case.
> > 
> > Yes it is bad indeed.
> > 
> > > 
> > > To be correct you code would need to use next_mnt and walk the tree and
> > > on each mount use propagate_mnt_busy to see if that entry can be
> > > unmounted.  Possibly with small variations to match your case.  Mounts
> > > in one part of the tree may propagate to places that mounts in other
> > > parts of the tree will not.
> > 
> > Right, the point there being use propagate_mnt_busy() for the check.
> 
> Or a variant of propagate_mnt_busy.
> 
> > I tried to use that when I started this but had trouble, I'll have another
> > look
> > at using it.
> > 
> > I thought the reason I couldn't use propagate_mnt_busy() is because it will
> > see
> > any mount with submounts as busy and that's not what's need. It's mounts
> > below
> > each of mounts having submounts that make them busy in my case.
> 
> If you have the count of submounts passed into propagate_mnt_busy() it
> will come very close to what you need.  It is still possible to have
> false positives in the face of propagation slaves that have 

[RESEND PATCH 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Signed-off-by: Caesar Wang 
---

 drivers/gpu/drm/panel/panel-simple.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 20,
+   .vtotal = 800 + 3 + 20 + 9,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4

[RESEND PATCH 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Signed-off-by: Caesar Wang 
---

 drivers/gpu/drm/panel/panel-simple.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 20,
+   .vtotal = 800 + 3 + 20 + 9,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4

[PATCH] ASoC: Intel: Skylake: remove unused 'out_fmt' variable

[Kirtika Ruchandani]

Commit 4cd9899f0d16 introduced struct skl_module_fmt* out_fmt without
using it. Compiling with W=1 gives the below warning, fix it.

sound/soc/intel/skylake/skl-topology.c: In function 
‘skl_tplg_update_buffer_size’:
sound/soc/intel/skylake/skl-topology.c:301:34: warning: variable ‘out_fmt’ set 
but not used [-Wunused-but-set-variable]

This is a harmless warning and is only being fixed to reduce the noise
with W=1 in the kernel.

Fixes: 4cd9899f0d16 ("ASoC: Intel: Skylake: Add multiple pin formats")
Cc: Hardik T Shah 
Cc: Omair M Abdullah 
Cc: Jeeja KP 
Cc: Subhransu S. Prusty 
Cc: Vinod Koul 
Cc: Mark Brown 
Signed-off-by: Kirtika Ruchandani 
---
 sound/soc/intel/skylake/skl-topology.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-topology.c 
b/sound/soc/intel/skylake/skl-topology.c
index bd313c9..4352236a 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -298,7 +298,7 @@ static void skl_tplg_update_buffer_size(struct skl_sst *ctx,
struct skl_module_cfg *mcfg)
 {
int multiplier = 1;
-   struct skl_module_fmt *in_fmt, *out_fmt;
+   struct skl_module_fmt *in_fmt;
int in_rate, out_rate;


@@ -306,7 +306,6 @@ static void skl_tplg_update_buffer_size(struct skl_sst *ctx,
 * change for pin 0 only
 */
in_fmt = >in_fmt[0];
-   out_fmt = >out_fmt[0];

if (mcfg->m_type == SKL_MODULE_TYPE_SRCINT)
multiplier = 5;
--
2.8.0.rc3.226.g39d4020

[PATCH] ASoC: Intel: Skylake: remove unused 'out_fmt' variable

[Kirtika Ruchandani]

Commit 4cd9899f0d16 introduced struct skl_module_fmt* out_fmt without
using it. Compiling with W=1 gives the below warning, fix it.

sound/soc/intel/skylake/skl-topology.c: In function 
‘skl_tplg_update_buffer_size’:
sound/soc/intel/skylake/skl-topology.c:301:34: warning: variable ‘out_fmt’ set 
but not used [-Wunused-but-set-variable]

This is a harmless warning and is only being fixed to reduce the noise
with W=1 in the kernel.

Fixes: 4cd9899f0d16 ("ASoC: Intel: Skylake: Add multiple pin formats")
Cc: Hardik T Shah 
Cc: Omair M Abdullah 
Cc: Jeeja KP 
Cc: Subhransu S. Prusty 
Cc: Vinod Koul 
Cc: Mark Brown 
Signed-off-by: Kirtika Ruchandani 
---
 sound/soc/intel/skylake/skl-topology.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-topology.c 
b/sound/soc/intel/skylake/skl-topology.c
index bd313c9..4352236a 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -298,7 +298,7 @@ static void skl_tplg_update_buffer_size(struct skl_sst *ctx,
struct skl_module_cfg *mcfg)
 {
int multiplier = 1;
-   struct skl_module_fmt *in_fmt, *out_fmt;
+   struct skl_module_fmt *in_fmt;
int in_rate, out_rate;


@@ -306,7 +306,6 @@ static void skl_tplg_update_buffer_size(struct skl_sst *ctx,
 * change for pin 0 only
 */
in_fmt = >in_fmt[0];
-   out_fmt = >out_fmt[0];

if (mcfg->m_type == SKL_MODULE_TYPE_SRCINT)
multiplier = 5;
--
2.8.0.rc3.226.g39d4020

[RESEND PATCH 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

[Caesar Wang]

The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.

Signed-off-by: Caesar Wang 
---

 .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt  | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt 
b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
new file mode 100644
index 000..b258d6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
@@ -0,0 +1,7 @@
+BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,nv101wxmn51"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.7.4

[RESEND PATCH 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

[Caesar Wang]

The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.

Signed-off-by: Caesar Wang 
---

 .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt  | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt 
b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
new file mode 100644
index 000..b258d6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
@@ -0,0 +1,7 @@
+BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,nv101wxmn51"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.7.4

Re: [PATCH] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

Resend the missing document.

Sorry for the noise.

在 2016年12月08日 13:26, Caesar Wang 写道:

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Signed-off-by: Caesar Wang 
---

  drivers/gpu/drm/panel/panel-simple.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
  };
  
+static const struct drm_display_mode boe_nv101wxmn51_mode = {

+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 20,
+   .vtotal = 800 + 3 + 20 + 9,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
  static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {

Re: [PATCH] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

Resend the missing document.

Sorry for the noise.

在 2016年12月08日 13:26, Caesar Wang 写道:

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Signed-off-by: Caesar Wang 
---

  drivers/gpu/drm/panel/panel-simple.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
  };
  
+static const struct drm_display_mode boe_nv101wxmn51_mode = {

+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 20,
+   .vtotal = 800 + 3 + 20 + 9,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
  static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Michael S. Tsirkin]

On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> On 12/07/16 18:29, Michael S. Tsirkin wrote:
> > By now, linux is mostly endian-clean. Enabling endian-ness
> > checks for everyone produces about 200 new sparse warnings for me -
> > less than 10% over the 2000 sparse warnings already there.
> >
> > Not a big deal, OTOH enabling this helps people notice
> > they are introducing new bugs.
> >
> > So let's just drop __CHECK_ENDIAN__. Follow-up patches
> > can drop distinction between __bitwise and __bitwise__.
> 
> Hello Michael,
> 
> This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__ 
> statements obsolete. Have you considered to remove these statements?

Absolutely. Just waiting for feedback on the idea.

> Additionally, there are notable exceptions to the rule that most drivers 
> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it 
> would remain possible to check such drivers with sparse without enabling 
> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ 
> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> 
> Thanks,
> 
> Bart.

The right thing is probably just to fix these, isn't it?
Until then, why not just ignore the warnings?

-- 
MST

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Michael S. Tsirkin]

On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> On 12/07/16 18:29, Michael S. Tsirkin wrote:
> > By now, linux is mostly endian-clean. Enabling endian-ness
> > checks for everyone produces about 200 new sparse warnings for me -
> > less than 10% over the 2000 sparse warnings already there.
> >
> > Not a big deal, OTOH enabling this helps people notice
> > they are introducing new bugs.
> >
> > So let's just drop __CHECK_ENDIAN__. Follow-up patches
> > can drop distinction between __bitwise and __bitwise__.
> 
> Hello Michael,
> 
> This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__ 
> statements obsolete. Have you considered to remove these statements?

Absolutely. Just waiting for feedback on the idea.

> Additionally, there are notable exceptions to the rule that most drivers 
> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it 
> would remain possible to check such drivers with sparse without enabling 
> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ 
> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> 
> Thanks,
> 
> Bart.

The right thing is probably just to fix these, isn't it?
Until then, why not just ignore the warnings?

-- 
MST

Re: [RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

[Juergen Gross]

On 05/12/16 18:49, Alex Thorlton wrote:
> This is the third pass at my patchset to fix up our problems with
> XENMEM_machine_memory_map on large systems.  The only changes on this
> pass were to flesh out the comment above the E820_X_MAX definition, and
> to add Juergen's Reviewed-by to the second patch.
> 
> Let me know if anyone has any questions/comments!
> 
> Alex Thorlton (2):
>   x86: Make E820_X_MAX unconditionally larger than E820MAX
>   xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
> 
>  arch/x86/include/asm/e820.h | 12 
>  arch/x86/xen/setup.c|  6 +++---
>  2 files changed, 11 insertions(+), 7 deletions(-)
> 

Ingo, do you have any preferences through which tree those patches
should go? I'd like to have at least patch 2 in 4.10, so I could take
it through the Xen tree.


Juergen

Re: [RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

[Juergen Gross]

On 05/12/16 18:49, Alex Thorlton wrote:
> This is the third pass at my patchset to fix up our problems with
> XENMEM_machine_memory_map on large systems.  The only changes on this
> pass were to flesh out the comment above the E820_X_MAX definition, and
> to add Juergen's Reviewed-by to the second patch.
> 
> Let me know if anyone has any questions/comments!
> 
> Alex Thorlton (2):
>   x86: Make E820_X_MAX unconditionally larger than E820MAX
>   xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
> 
>  arch/x86/include/asm/e820.h | 12 
>  arch/x86/xen/setup.c|  6 +++---
>  2 files changed, 11 insertions(+), 7 deletions(-)
> 

Ingo, do you have any preferences through which tree those patches
should go? I'd like to have at least patch 2 in 4.10, so I could take
it through the Xen tree.


Juergen

[PATCH] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Signed-off-by: Caesar Wang 
---

 drivers/gpu/drm/panel/panel-simple.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 20,
+   .vtotal = 800 + 3 + 20 + 9,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4

[PATCH] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Signed-off-by: Caesar Wang 
---

 drivers/gpu/drm/panel/panel-simple.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 20,
+   .vtotal = 800 + 3 + 20 + 9,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = _nv101wxmn51_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4

Re: [PATCH] timekeeping: Remove unused timekeeping_{get,set}_tai_offset()

[John Stultz]

On Wed, Dec 7, 2016 at 2:33 PM, Stephen Boyd  wrote:
> The last caller to timekeeping_set_tai_offset() was in commit
> 0b5154fb9040 (timekeeping: Simplify tai updating from
> do_adjtimex, 2013-03-22) and the last caller to
> timekeeping_get_tai_offset() was in commit 76f4108892d9 (hrtimer:
> Cleanup hrtimer accessors to the timekepeing state, 2014-07-16).
> Remove these unused functions now that we handle TAI offsets
> differently.
>
> Cc: John Stultz 
> Signed-off-by: Stephen Boyd 

Looks good! Thanks for sending this in. Its a little late, and doesn't
seem urgent, so I'll queue it for 4.11.

thanks
-john

Re: [PATCH] timekeeping: Remove unused timekeeping_{get,set}_tai_offset()

[John Stultz]

On Wed, Dec 7, 2016 at 2:33 PM, Stephen Boyd  wrote:
> The last caller to timekeeping_set_tai_offset() was in commit
> 0b5154fb9040 (timekeeping: Simplify tai updating from
> do_adjtimex, 2013-03-22) and the last caller to
> timekeeping_get_tai_offset() was in commit 76f4108892d9 (hrtimer:
> Cleanup hrtimer accessors to the timekepeing state, 2014-07-16).
> Remove these unused functions now that we handle TAI offsets
> differently.
>
> Cc: John Stultz 
> Signed-off-by: Stephen Boyd 

Looks good! Thanks for sending this in. Its a little late, and doesn't
seem urgent, so I'll queue it for 4.11.

thanks
-john

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Bart Van Assche]

On 12/07/16 18:29, Michael S. Tsirkin wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
>
> Not a big deal, OTOH enabling this helps people notice
> they are introducing new bugs.
>
> So let's just drop __CHECK_ENDIAN__. Follow-up patches
> can drop distinction between __bitwise and __bitwise__.

Hello Michael,

This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__ 
statements obsolete. Have you considered to remove these statements?

Additionally, there are notable exceptions to the rule that most drivers 
are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it 
would remain possible to check such drivers with sparse without enabling 
endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ 
into e.g. #ifndef __DONT_CHECK_ENDIAN__?

Thanks,

Bart.

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Bart Van Assche]

On 12/07/16 18:29, Michael S. Tsirkin wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
>
> Not a big deal, OTOH enabling this helps people notice
> they are introducing new bugs.
>
> So let's just drop __CHECK_ENDIAN__. Follow-up patches
> can drop distinction between __bitwise and __bitwise__.

Hello Michael,

This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__ 
statements obsolete. Have you considered to remove these statements?

Additionally, there are notable exceptions to the rule that most drivers 
are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it 
would remain possible to check such drivers with sparse without enabling 
endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ 
into e.g. #ifndef __DONT_CHECK_ENDIAN__?

Thanks,

Bart.

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

[Eric W. Biederman]

"Serge E. Hallyn"  writes:

> On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
>> "Serge E. Hallyn"  writes:
>> 
>> > Root in a user ns cannot be trusted to write a traditional
>> > security.capability xattr.  If it were allowed to do so, then any
>> > unprivileged user on the host could map his own uid to root in a
>> > namespace, write the xattr, and execute the file with privilege on the
>> > host.
>> >
>> > This patch introduces v3 of the security.capability xattr.  It builds a
>> > vfs_ns_cap_data struct by appending a uid_t rootid to struct
>> > vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
>> > init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
>> > the file capabilities may take effect.
>> >
>> > When a task in a user ns (which is privileged with CAP_SETFCAP toward
>> > that user_ns) asks to write v2 security.capability, the kernel will
>> > transparently rewrite the xattr as a v3 with the appropriate rootid.
>> > Subsequently, any task executing the file which has the noted kuid as
>> > its root uid, or which is in a descendent user_ns of such a user_ns,
>> > will run the file with capabilities.
>> >
>> > If a task writes a v3 security.capability, then it can provide a
>> > uid (valid within its own user namespace, over which it has CAP_SETFCAP)
>> > for the xattr.  The kernel will translate that to the absolute uid, and
>> > write that to disk.  After this, a task in the writer's namespace will
>> > not be able to use those capabilities, but a task in a namespace where
>> > the given uid is root will.
>> >
>> > Only a single security.capability xattr may be written.  A task may
>> > overwrite the existing one so long as it was written by a user mapped
>> > into his own user_ns over which he has CAP_SETFCAP.
>> >
>> > This allows a simple setxattr to work, allows tar/untar to work, and
>> > allows us to tar in one namespace and untar in another while preserving
>> > the capability, without risking leaking privilege into a parent
>> > namespace.
>> 
>> Any chance of a singed-off-by?
>
> Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
> -s.  Do you want me to resend the whole shebang, or does
>
> Signed-off-by: Serge Hallyn 
>
> suffice?  (My previous iterations did have it fwiw so I don't think I could
> legally disavow it now :)

That should be good enough.  I just wanted to make certain it existed
somewhere.

The whole inode->i_op->getxattr reference was also a bit of a problem
as that method was removed in 4.9-rc1 but otherwise things are looking
reasonable.

Thank you,
Eric

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

[Eric W. Biederman]

"Serge E. Hallyn"  writes:

> On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
>> "Serge E. Hallyn"  writes:
>> 
>> > Root in a user ns cannot be trusted to write a traditional
>> > security.capability xattr.  If it were allowed to do so, then any
>> > unprivileged user on the host could map his own uid to root in a
>> > namespace, write the xattr, and execute the file with privilege on the
>> > host.
>> >
>> > This patch introduces v3 of the security.capability xattr.  It builds a
>> > vfs_ns_cap_data struct by appending a uid_t rootid to struct
>> > vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
>> > init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
>> > the file capabilities may take effect.
>> >
>> > When a task in a user ns (which is privileged with CAP_SETFCAP toward
>> > that user_ns) asks to write v2 security.capability, the kernel will
>> > transparently rewrite the xattr as a v3 with the appropriate rootid.
>> > Subsequently, any task executing the file which has the noted kuid as
>> > its root uid, or which is in a descendent user_ns of such a user_ns,
>> > will run the file with capabilities.
>> >
>> > If a task writes a v3 security.capability, then it can provide a
>> > uid (valid within its own user namespace, over which it has CAP_SETFCAP)
>> > for the xattr.  The kernel will translate that to the absolute uid, and
>> > write that to disk.  After this, a task in the writer's namespace will
>> > not be able to use those capabilities, but a task in a namespace where
>> > the given uid is root will.
>> >
>> > Only a single security.capability xattr may be written.  A task may
>> > overwrite the existing one so long as it was written by a user mapped
>> > into his own user_ns over which he has CAP_SETFCAP.
>> >
>> > This allows a simple setxattr to work, allows tar/untar to work, and
>> > allows us to tar in one namespace and untar in another while preserving
>> > the capability, without risking leaking privilege into a parent
>> > namespace.
>> 
>> Any chance of a singed-off-by?
>
> Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
> -s.  Do you want me to resend the whole shebang, or does
>
> Signed-off-by: Serge Hallyn 
>
> suffice?  (My previous iterations did have it fwiw so I don't think I could
> legally disavow it now :)

That should be good enough.  I just wanted to make certain it existed
somewhere.

The whole inode->i_op->getxattr reference was also a bit of a problem
as that method was removed in 4.9-rc1 but otherwise things are looking
reasonable.

Thank you,
Eric

Re: linux-next: Tree for Dec 7 (kallsyms failure)

[Nicholas Piggin]

On Thu, 8 Dec 2016 15:29:35 +1100
Stephen Rothwell  wrote:

> Hi all,
> 
> On Wed, 7 Dec 2016 18:30:57 -0800 Randy Dunlap  wrote:
> >
> > On 12/07/16 15:56, Stephen Rothwell wrote:  
> > > 
> > > On Wed, 7 Dec 2016 15:42:32 -0800 Randy Dunlap  
> > > wrote:
> > >>
> > >> I started seeing this yesterday (2016-1206).
> > >> This is on x86_64.
> > >>
> > >> Anybody know about it?
> > >>
> > >> kallsyms failure: relative symbol value 0x8100 out of range 
> > >> in relative mode
> > > 
> > > I got a similar failure starting a few days ago on my powerpc
> > > allyesconfig build.  I was assuming that it was PowerPC specific, but
> > > noone has found a cause yet.
> > > 
> > 
> > It may just be an invalid randconfig.  I modified scripts/kallsyms.c and
> > I see this message:
> > kallsyms failure: relative symbol value 0x8100 [symbol: 
> > Tstartup_64] out of range in relative mode
> > 
> > and it makes sense that startup_64 would (or could) be at 
> > 0x8100...
> > especially since CONFIG_PHYSICAL_START=0x100 and
> > (from Documentation/x86/x86_64/mm.txt)
> > 8000 - 9fff (=512 MB)  kernel text mapping, from 
> > phys 0
> > 
> > 
> > Ard, what do you think about this?  
> 
> The similar failure I saw in the powerpc allyesconfig build
> 
> kallsyms failure: relative symbol value 0xc000 out of range in 
> relative mode
> 
> was caused by commit
> 
>   8ab2ae655bfe ("default exported asm symbols to zero")
> 
> which has been reverted in Linus' tree today.
> 

Huh, so it seems like the explicit 0 symbols were being picked up as the
kallsyms relative base, putting the 0xc... symbols beyond reach.

Re: linux-next: Tree for Dec 7 (kallsyms failure)

[Nicholas Piggin]

On Thu, 8 Dec 2016 15:29:35 +1100
Stephen Rothwell  wrote:

> Hi all,
> 
> On Wed, 7 Dec 2016 18:30:57 -0800 Randy Dunlap  wrote:
> >
> > On 12/07/16 15:56, Stephen Rothwell wrote:  
> > > 
> > > On Wed, 7 Dec 2016 15:42:32 -0800 Randy Dunlap  
> > > wrote:
> > >>
> > >> I started seeing this yesterday (2016-1206).
> > >> This is on x86_64.
> > >>
> > >> Anybody know about it?
> > >>
> > >> kallsyms failure: relative symbol value 0x8100 out of range 
> > >> in relative mode
> > > 
> > > I got a similar failure starting a few days ago on my powerpc
> > > allyesconfig build.  I was assuming that it was PowerPC specific, but
> > > noone has found a cause yet.
> > > 
> > 
> > It may just be an invalid randconfig.  I modified scripts/kallsyms.c and
> > I see this message:
> > kallsyms failure: relative symbol value 0x8100 [symbol: 
> > Tstartup_64] out of range in relative mode
> > 
> > and it makes sense that startup_64 would (or could) be at 
> > 0x8100...
> > especially since CONFIG_PHYSICAL_START=0x100 and
> > (from Documentation/x86/x86_64/mm.txt)
> > 8000 - 9fff (=512 MB)  kernel text mapping, from 
> > phys 0
> > 
> > 
> > Ard, what do you think about this?  
> 
> The similar failure I saw in the powerpc allyesconfig build
> 
> kallsyms failure: relative symbol value 0xc000 out of range in 
> relative mode
> 
> was caused by commit
> 
>   8ab2ae655bfe ("default exported asm symbols to zero")
> 
> which has been reverted in Linus' tree today.
> 

Huh, so it seems like the explicit 0 symbols were being picked up as the
kallsyms relative base, putting the 0xc... symbols beyond reach.

Re: Misalignment, MIPS, and ip_hdr(skb)->version

[Daniel Kahn Gillmor]

On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> Your custom protocol should be designed in a way you get an aligned ip
> header. Most protocols of the IETF follow this mantra and it is always
> possible to e.g. pad options so you end up on aligned boundaries for the
> next header.

fwiw, i'm not convinced that "most protocols of the IETF follow this
mantra".  we've had multiple discussions in different protocol groups
about shaving or bloating by a few bytes here or there in different
protocols, and i don't think anyone has brought up memory alignment as
an argument in any of the discussions i've followed.

that said, it sure does sound like it would make things simpler to
construct the protocol that way :)

  --dkg

Re: Misalignment, MIPS, and ip_hdr(skb)->version

[Daniel Kahn Gillmor]

On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> Your custom protocol should be designed in a way you get an aligned ip
> header. Most protocols of the IETF follow this mantra and it is always
> possible to e.g. pad options so you end up on aligned boundaries for the
> next header.

fwiw, i'm not convinced that "most protocols of the IETF follow this
mantra".  we've had multiple discussions in different protocol groups
about shaving or bloating by a few bytes here or there in different
protocols, and i don't think anyone has brought up memory alignment as
an argument in any of the discussions i've followed.

that said, it sure does sound like it would make things simpler to
construct the protocol that way :)

  --dkg

[PATCH v2 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical

[Chanwoo Choi]

The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are
disabled, the system halt happen. Following clock must be always enabled.
- CLK_ACLK_BUS0_400 : NoC's bus clock for PERIC/PERIS/FSYS/MSCL
- CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
- CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Also, this patch adds the CLK_SET_RATE_PARENT flag to the CLK_SCLK_JPEG_MSCL
because this clock should be used for bus frequency scaling. This clock need to
be changed on the fly with CLK_SET_RATE_PARENT flag.

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Cc: Chanwoo Choi 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc:linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/clk/samsung/clk-exynos5433.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index f096bd7df40c..0db5204c307c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -549,10 +549,10 @@
29, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_BUS0_400, "aclk_bus0_400", "div_aclk_bus0_400",
ENABLE_ACLK_TOP, 26,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_BUS1_400, "aclk_bus1_400", "div_aclk_bus1_400",
ENABLE_ACLK_TOP, 25,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_IMEM_200, "aclk_imem_200", "div_aclk_imem_266",
ENABLE_ACLK_TOP, 24,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
@@ -616,7 +616,7 @@
 
/* ENABLE_SCLK_TOP_MSCL */
GATE(CLK_SCLK_JPEG_MSCL, "sclk_jpeg_mscl", "div_sclk_jpeg",
-   ENABLE_SCLK_TOP_MSCL, 0, 0, 0),
+   ENABLE_SCLK_TOP_MSCL, 0, CLK_SET_RATE_PARENT, 0),
 
/* ENABLE_SCLK_TOP_CAM1 */
GATE(CLK_SCLK_ISP_SENSOR2, "sclk_isp_sensor2", "div_sclk_isp_sensor2_b",
@@ -1382,7 +1382,7 @@ static void __init exynos5433_cmu_cpif_init(struct 
device_node *np)
/* ENABLE_ACLK_MIF3 */
GATE(CLK_ACLK_BUS2_400, "aclk_bus2_400", "div_aclk_bus2_400",
ENABLE_ACLK_MIF3, 4,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_DISP_333, "aclk_disp_333", "div_aclk_disp_333",
ENABLE_ACLK_MIF3, 1,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
-- 
1.9.1

[PATCH v2 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical

[Chanwoo Choi]

The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are
disabled, the system halt happen. Following clock must be always enabled.
- CLK_ACLK_BUS0_400 : NoC's bus clock for PERIC/PERIS/FSYS/MSCL
- CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
- CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Also, this patch adds the CLK_SET_RATE_PARENT flag to the CLK_SCLK_JPEG_MSCL
because this clock should be used for bus frequency scaling. This clock need to
be changed on the fly with CLK_SET_RATE_PARENT flag.

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Cc: Chanwoo Choi 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc:linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/clk/samsung/clk-exynos5433.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index f096bd7df40c..0db5204c307c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -549,10 +549,10 @@
29, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_BUS0_400, "aclk_bus0_400", "div_aclk_bus0_400",
ENABLE_ACLK_TOP, 26,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_BUS1_400, "aclk_bus1_400", "div_aclk_bus1_400",
ENABLE_ACLK_TOP, 25,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_IMEM_200, "aclk_imem_200", "div_aclk_imem_266",
ENABLE_ACLK_TOP, 24,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
@@ -616,7 +616,7 @@
 
/* ENABLE_SCLK_TOP_MSCL */
GATE(CLK_SCLK_JPEG_MSCL, "sclk_jpeg_mscl", "div_sclk_jpeg",
-   ENABLE_SCLK_TOP_MSCL, 0, 0, 0),
+   ENABLE_SCLK_TOP_MSCL, 0, CLK_SET_RATE_PARENT, 0),
 
/* ENABLE_SCLK_TOP_CAM1 */
GATE(CLK_SCLK_ISP_SENSOR2, "sclk_isp_sensor2", "div_sclk_isp_sensor2_b",
@@ -1382,7 +1382,7 @@ static void __init exynos5433_cmu_cpif_init(struct 
device_node *np)
/* ENABLE_ACLK_MIF3 */
GATE(CLK_ACLK_BUS2_400, "aclk_bus2_400", "div_aclk_bus2_400",
ENABLE_ACLK_MIF3, 4,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_DISP_333, "aclk_disp_333", "div_aclk_disp_333",
ENABLE_ACLK_MIF3, 1,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
-- 
1.9.1

[PATCH v2 0/5] arm64: dts: Enable bus frequency scaling on Exynos5433-based TM2 board

[Chanwoo Choi]

This patches add the AMBA bus Device-tree node unsing VDD_INT
to enable the bus frequency scaling on Exynos5433-based TM2 board.

There are two kind of bus device with devfreq framework.
- Parent bus device  : Change the frequency/voltage according to bus's 
utilization.
- Passive bus device : Change only frequency according to the new level
   of parent bus device.

The VDD_INT regulator provides the power source to INT (Internal) block as
following. The sub-blocks in the INT block share the one power source.
VDD_INT |--- G2D_400 (parent device)
|--- G2D_266
|--- GSCL
|--- JPEG
|--- HEVC
|--- MFC
|--- MSCL
|--- NoC0
|--- NoC1
|--- NoC2
|--- PERIS (Fixed clock rate)
|--- PERIC (Fixed clock rate)
|--- FSYS  (Fixed clock rate)

Each sub-block has the bus clock as following:
 - CLK_ACLK_G2D_{400|266} : Bus clock for G2D (2D graphic engine)
 - CLK_ACLK_MSCL_400  : Bus clock for MSCL (Memory to memory Scaler)
 - CLK_ACLK_GSCL_333  : Bus clock for GSCL (General Scaler)
 - CLK_SCLK_JPEG_MSCL : Bus clock for JPEG
 - CLK_ACLK_MFC_400   : Bus clock for MFC (Multi Format Codec)
 - CLK_ACLK_HEVC_400  : Bus clock for HEVC (High Effective Video Codec)
 - CLK_ACLK_BUS0_400  : NoC(Network On Chip)'s bus clock for 
PERIC/PERIS/FSYS/MSCL
 - CLK_ACLK_BUS1_400  : NoC's bus clock for MFC/HEVC/G3D
 - CLK_ACLK_BUS2_400  : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Changes from v1:
- Remove duplicate description of exynos5433-bus.dtsi
- Move the bus device-tree node under the 'soc'
- Modify the node name of bus from 'bus_xxx_xxx' to 'bus[number]'
- Reorder the bus device-tree node alpabetically
- Change the node name from 'bus_busX' to 'bus_nocX'
- Fix minor issue
- Add reviewed-by tag of Krzysztof Kozlowski for patch3/5

Chanwoo Choi (5):
  clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
  PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433
  arm64: dts: exynos5433: Add PPMU dt node
  arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
  arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2

 .../devicetree/bindings/devfreq/exynos-bus.txt |  15 ++
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  70 
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  25 +++
 drivers/clk/samsung/clk-exynos5433.c   |   8 +-
 5 files changed, 311 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi

-- 
1.9.1

[PATCH v2 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
Exynos5433 has the following AMBA AXI buses to translate data
between DRAM and sub-blocks.

Following list specify the detailed correlation between sub-block and clock:
- CLK_ACLK_G2D_{400|266}  : Bus clock for G2D (2D graphic engine)
- CLK_ACLK_MSCL_400   : Bus clock for MSCL (Memory to memory Scaler)
- CLK_ACLK_GSCL_333   : Bus clock for GSCL (General Scaler)
- CLK_SCLK_JPEG_MSCL  : Bus clock for JPEG
- CLK_ACLK_MFC_400: Bus clock for MFC (Multi Format Codec)
- CLK_ACLK_HEVC_400   : Bus clock for HEVC (High Efficient Video Codec)
- CLK_ACLK_BUS0_400   : NoC(Network On Chip)'s bus clock for 
PERIC/PERIS/FSYS/MSCL
- CLK_ACLK_BUS1_400   : NoC's bus clock for MFC/HEVC/G3D
- CLK_ACLK_BUS2_400   : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |   1 +
 2 files changed, 198 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
new file mode 100644
index ..09dac0124f73
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -0,0 +1,197 @@
+/*
+ * Samsung's Exynos5433 SoC Memory interface and AMBA bus device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Chanwoo Choi 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+ {
+   bus_g2d_400: bus0 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_G2D_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_g2d_266: bus1 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_G2D_266>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_266_opp_table>;
+   status ="disabled";
+   };
+
+   bus_gscl: bus2 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_GSCL_333>;
+   clock-names = "bus";
+   operating-points-v2 = <_gscl_opp_table>;
+   status ="disabled";
+   };
+
+   bus_hevc: bus3 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_HEVC_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_hevc_opp_table>;
+   status ="disabled";
+   };
+
+   bus_jpeg: bus4 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_SCLK_JPEG_MSCL>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_mfc: bus5 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_MFC_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_mscl: bus6 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_MSCL_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_noc0: bus7 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_BUS0_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_hevc_opp_table>;
+   status ="disabled";
+   };
+
+   bus_noc1: bus8 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_BUS1_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_hevc_opp_table>;
+   status ="disabled";
+   };
+
+   bus_noc2: bus9 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_mif CLK_ACLK_BUS2_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_noc2_opp_table>;
+   status ="disabled";
+   };
+
+   bus_g2d_400_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <1075000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <100>;
+   };
+   opp@2 {
+   

[PATCH v2 3/5] arm64: dts: exynos5433: Add PPMU dt node

[Chanwoo Choi]

This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
to measure the utilization of each IP in Exynos SoC.

- PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
  block with VDD_MIF power source.
- PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
  block with VDD_INT power source.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 64226d5ae471..8c4ee84d5232 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -599,6 +599,30 @@
clock-names = "fin_pll", "mct";
};
 
+   ppmu_d0_cpu: ppmu@1048 {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x1048 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d0_general: ppmu@1049 {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x1049 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d1_cpu: ppmu@104b {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x104b 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d1_general: ppmu@104c {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x104c 0x2000>;
+   status = "disabled";
+   };
+
pinctrl_alive: pinctrl@1058 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x1058 0x1a20>, <0x1109 0x100>;
-- 
1.9.1

[PATCH v2 0/5] arm64: dts: Enable bus frequency scaling on Exynos5433-based TM2 board

[Chanwoo Choi]

This patches add the AMBA bus Device-tree node unsing VDD_INT
to enable the bus frequency scaling on Exynos5433-based TM2 board.

There are two kind of bus device with devfreq framework.
- Parent bus device  : Change the frequency/voltage according to bus's 
utilization.
- Passive bus device : Change only frequency according to the new level
   of parent bus device.

The VDD_INT regulator provides the power source to INT (Internal) block as
following. The sub-blocks in the INT block share the one power source.
VDD_INT |--- G2D_400 (parent device)
|--- G2D_266
|--- GSCL
|--- JPEG
|--- HEVC
|--- MFC
|--- MSCL
|--- NoC0
|--- NoC1
|--- NoC2
|--- PERIS (Fixed clock rate)
|--- PERIC (Fixed clock rate)
|--- FSYS  (Fixed clock rate)

Each sub-block has the bus clock as following:
 - CLK_ACLK_G2D_{400|266} : Bus clock for G2D (2D graphic engine)
 - CLK_ACLK_MSCL_400  : Bus clock for MSCL (Memory to memory Scaler)
 - CLK_ACLK_GSCL_333  : Bus clock for GSCL (General Scaler)
 - CLK_SCLK_JPEG_MSCL : Bus clock for JPEG
 - CLK_ACLK_MFC_400   : Bus clock for MFC (Multi Format Codec)
 - CLK_ACLK_HEVC_400  : Bus clock for HEVC (High Effective Video Codec)
 - CLK_ACLK_BUS0_400  : NoC(Network On Chip)'s bus clock for 
PERIC/PERIS/FSYS/MSCL
 - CLK_ACLK_BUS1_400  : NoC's bus clock for MFC/HEVC/G3D
 - CLK_ACLK_BUS2_400  : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Changes from v1:
- Remove duplicate description of exynos5433-bus.dtsi
- Move the bus device-tree node under the 'soc'
- Modify the node name of bus from 'bus_xxx_xxx' to 'bus[number]'
- Reorder the bus device-tree node alpabetically
- Change the node name from 'bus_busX' to 'bus_nocX'
- Fix minor issue
- Add reviewed-by tag of Krzysztof Kozlowski for patch3/5

Chanwoo Choi (5):
  clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
  PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433
  arm64: dts: exynos5433: Add PPMU dt node
  arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
  arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2

 .../devicetree/bindings/devfreq/exynos-bus.txt |  15 ++
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  70 
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  25 +++
 drivers/clk/samsung/clk-exynos5433.c   |   8 +-
 5 files changed, 311 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi

-- 
1.9.1

[PATCH v2 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
Exynos5433 has the following AMBA AXI buses to translate data
between DRAM and sub-blocks.

Following list specify the detailed correlation between sub-block and clock:
- CLK_ACLK_G2D_{400|266}  : Bus clock for G2D (2D graphic engine)
- CLK_ACLK_MSCL_400   : Bus clock for MSCL (Memory to memory Scaler)
- CLK_ACLK_GSCL_333   : Bus clock for GSCL (General Scaler)
- CLK_SCLK_JPEG_MSCL  : Bus clock for JPEG
- CLK_ACLK_MFC_400: Bus clock for MFC (Multi Format Codec)
- CLK_ACLK_HEVC_400   : Bus clock for HEVC (High Efficient Video Codec)
- CLK_ACLK_BUS0_400   : NoC(Network On Chip)'s bus clock for 
PERIC/PERIS/FSYS/MSCL
- CLK_ACLK_BUS1_400   : NoC's bus clock for MFC/HEVC/G3D
- CLK_ACLK_BUS2_400   : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |   1 +
 2 files changed, 198 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
new file mode 100644
index ..09dac0124f73
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -0,0 +1,197 @@
+/*
+ * Samsung's Exynos5433 SoC Memory interface and AMBA bus device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Chanwoo Choi 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+ {
+   bus_g2d_400: bus0 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_G2D_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_g2d_266: bus1 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_G2D_266>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_266_opp_table>;
+   status ="disabled";
+   };
+
+   bus_gscl: bus2 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_GSCL_333>;
+   clock-names = "bus";
+   operating-points-v2 = <_gscl_opp_table>;
+   status ="disabled";
+   };
+
+   bus_hevc: bus3 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_HEVC_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_hevc_opp_table>;
+   status ="disabled";
+   };
+
+   bus_jpeg: bus4 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_SCLK_JPEG_MSCL>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_mfc: bus5 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_MFC_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_mscl: bus6 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_MSCL_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_g2d_400_opp_table>;
+   status ="disabled";
+   };
+
+   bus_noc0: bus7 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_BUS0_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_hevc_opp_table>;
+   status ="disabled";
+   };
+
+   bus_noc1: bus8 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_top CLK_ACLK_BUS1_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_hevc_opp_table>;
+   status ="disabled";
+   };
+
+   bus_noc2: bus9 {
+   compatible = "samsung,exynos-bus";
+   clocks = <_mif CLK_ACLK_BUS2_400>;
+   clock-names = "bus";
+   operating-points-v2 = <_noc2_opp_table>;
+   status ="disabled";
+   };
+
+   bus_g2d_400_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <1075000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <100>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+  

[PATCH v2 3/5] arm64: dts: exynos5433: Add PPMU dt node

[Chanwoo Choi]

This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
to measure the utilization of each IP in Exynos SoC.

- PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
  block with VDD_MIF power source.
- PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
  block with VDD_INT power source.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 64226d5ae471..8c4ee84d5232 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -599,6 +599,30 @@
clock-names = "fin_pll", "mct";
};
 
+   ppmu_d0_cpu: ppmu@1048 {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x1048 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d0_general: ppmu@1049 {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x1049 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d1_cpu: ppmu@104b {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x104b 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d1_general: ppmu@104c {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x104c 0x2000>;
+   status = "disabled";
+   };
+
pinctrl_alive: pinctrl@1058 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x1058 0x1a20>, <0x1109 0x100>;
-- 
1.9.1

[PATCH v2 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2

[Chanwoo Choi]

This patch adds the bus Device-tree nodes for INT (Internal) block
to enable the bus frequency scaling.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index c08589970134..451788642b21 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -170,6 +170,58 @@
};
 };
 
+_g2d_400 {
+   devfreq-events = <_event0_d0_general>, <_event0_d1_general>;
+   vdd-supply = <_reg>;
+   exynos,saturation-ratio = <10>;
+   status = "okay";
+};
+
+_g2d_266 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_gscl {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_hevc {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_jpeg {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_mscl {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_noc0 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_noc1 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_noc2 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
 _aud {
assigned-clocks = <_aud CLK_MOUT_AUD_PLL_USER>;
assigned-clock-parents = <_top CLK_FOUT_AUD_PLL>;
@@ -794,6 +846,24 @@
bus-width = <4>;
 };
 
+_d0_general {
+   status = "okay";
+   events {
+   ppmu_event0_d0_general: ppmu-event0-d0-general {
+   event-name = "ppmu-event0-d0-general";
+   };
+   };
+};
+
+_d1_general {
+   status = "okay";
+   events {
+   ppmu_event0_d1_general: ppmu-event0-d1-general {
+  event-name = "ppmu-event0-d1-general";
+  };
+   };
+};
+
 _alive {
pinctrl-names = "default";
pinctrl-0 = <_alive>;
-- 
1.9.1

[PATCH v2 2/5] PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433

[Chanwoo Choi]

This patch adds the detailed corrleation between sub-blocks and VDD_INT power
line for Exynos5433. VDD_INT provided the power source to INT (Internal) block.

Cc: MyungJoo Ham 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d3ec8e676b6b..d6107770face 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -123,6 +123,21 @@ Detailed correlation between sub-blocks and power line 
according to Exynos SoC:
|--- FSYS
|--- FSYS2
 
+- In case of Exynos5433, there is VDD_INT power line as following:
+   VDD_INT |--- G2D_400 (parent device)
+   |--- G2D_266
+   |--- GSCL
+   |--- JPEG
+   |--- HEVC
+   |--- MFC
+   |--- MSCL
+   |--- NoC0
+   |--- NoC1
+   |--- NoC2
+   |--- PERIS (Fixed clock rate)
+   |--- PERIC (Fixed clock rate)
+   |--- FSYS  (Fixed clock rate)
+
 Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
-- 
1.9.1

[PATCH v2 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2

[Chanwoo Choi]

This patch adds the bus Device-tree nodes for INT (Internal) block
to enable the bus frequency scaling.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index c08589970134..451788642b21 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -170,6 +170,58 @@
};
 };
 
+_g2d_400 {
+   devfreq-events = <_event0_d0_general>, <_event0_d1_general>;
+   vdd-supply = <_reg>;
+   exynos,saturation-ratio = <10>;
+   status = "okay";
+};
+
+_g2d_266 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_gscl {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_hevc {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_jpeg {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_mscl {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_noc0 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_noc1 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
+_noc2 {
+   devfreq = <_g2d_400>;
+   status = "okay";
+};
+
 _aud {
assigned-clocks = <_aud CLK_MOUT_AUD_PLL_USER>;
assigned-clock-parents = <_top CLK_FOUT_AUD_PLL>;
@@ -794,6 +846,24 @@
bus-width = <4>;
 };
 
+_d0_general {
+   status = "okay";
+   events {
+   ppmu_event0_d0_general: ppmu-event0-d0-general {
+   event-name = "ppmu-event0-d0-general";
+   };
+   };
+};
+
+_d1_general {
+   status = "okay";
+   events {
+   ppmu_event0_d1_general: ppmu-event0-d1-general {
+  event-name = "ppmu-event0-d1-general";
+  };
+   };
+};
+
 _alive {
pinctrl-names = "default";
pinctrl-0 = <_alive>;
-- 
1.9.1

[PATCH v2 2/5] PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433

[Chanwoo Choi]

This patch adds the detailed corrleation between sub-blocks and VDD_INT power
line for Exynos5433. VDD_INT provided the power source to INT (Internal) block.

Cc: MyungJoo Ham 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d3ec8e676b6b..d6107770face 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -123,6 +123,21 @@ Detailed correlation between sub-blocks and power line 
according to Exynos SoC:
|--- FSYS
|--- FSYS2
 
+- In case of Exynos5433, there is VDD_INT power line as following:
+   VDD_INT |--- G2D_400 (parent device)
+   |--- G2D_266
+   |--- GSCL
+   |--- JPEG
+   |--- HEVC
+   |--- MFC
+   |--- MSCL
+   |--- NoC0
+   |--- NoC1
+   |--- NoC2
+   |--- PERIS (Fixed clock rate)
+   |--- PERIC (Fixed clock rate)
+   |--- FSYS  (Fixed clock rate)
+
 Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
-- 
1.9.1

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

[Serge E. Hallyn]

On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
> "Serge E. Hallyn"  writes:
> 
> > Root in a user ns cannot be trusted to write a traditional
> > security.capability xattr.  If it were allowed to do so, then any
> > unprivileged user on the host could map his own uid to root in a
> > namespace, write the xattr, and execute the file with privilege on the
> > host.
> >
> > This patch introduces v3 of the security.capability xattr.  It builds a
> > vfs_ns_cap_data struct by appending a uid_t rootid to struct
> > vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
> > init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
> > the file capabilities may take effect.
> >
> > When a task in a user ns (which is privileged with CAP_SETFCAP toward
> > that user_ns) asks to write v2 security.capability, the kernel will
> > transparently rewrite the xattr as a v3 with the appropriate rootid.
> > Subsequently, any task executing the file which has the noted kuid as
> > its root uid, or which is in a descendent user_ns of such a user_ns,
> > will run the file with capabilities.
> >
> > If a task writes a v3 security.capability, then it can provide a
> > uid (valid within its own user namespace, over which it has CAP_SETFCAP)
> > for the xattr.  The kernel will translate that to the absolute uid, and
> > write that to disk.  After this, a task in the writer's namespace will
> > not be able to use those capabilities, but a task in a namespace where
> > the given uid is root will.
> >
> > Only a single security.capability xattr may be written.  A task may
> > overwrite the existing one so long as it was written by a user mapped
> > into his own user_ns over which he has CAP_SETFCAP.
> >
> > This allows a simple setxattr to work, allows tar/untar to work, and
> > allows us to tar in one namespace and untar in another while preserving
> > the capability, without risking leaking privilege into a parent
> > namespace.
> 
> Any chance of a singed-off-by?

Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
-s.  Do you want me to resend the whole shebang, or does

Signed-off-by: Serge Hallyn 

suffice?  (My previous iterations did have it fwiw so I don't think I could
legally disavow it now :)

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

[Serge E. Hallyn]

On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
> "Serge E. Hallyn"  writes:
> 
> > Root in a user ns cannot be trusted to write a traditional
> > security.capability xattr.  If it were allowed to do so, then any
> > unprivileged user on the host could map his own uid to root in a
> > namespace, write the xattr, and execute the file with privilege on the
> > host.
> >
> > This patch introduces v3 of the security.capability xattr.  It builds a
> > vfs_ns_cap_data struct by appending a uid_t rootid to struct
> > vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
> > init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
> > the file capabilities may take effect.
> >
> > When a task in a user ns (which is privileged with CAP_SETFCAP toward
> > that user_ns) asks to write v2 security.capability, the kernel will
> > transparently rewrite the xattr as a v3 with the appropriate rootid.
> > Subsequently, any task executing the file which has the noted kuid as
> > its root uid, or which is in a descendent user_ns of such a user_ns,
> > will run the file with capabilities.
> >
> > If a task writes a v3 security.capability, then it can provide a
> > uid (valid within its own user namespace, over which it has CAP_SETFCAP)
> > for the xattr.  The kernel will translate that to the absolute uid, and
> > write that to disk.  After this, a task in the writer's namespace will
> > not be able to use those capabilities, but a task in a namespace where
> > the given uid is root will.
> >
> > Only a single security.capability xattr may be written.  A task may
> > overwrite the existing one so long as it was written by a user mapped
> > into his own user_ns over which he has CAP_SETFCAP.
> >
> > This allows a simple setxattr to work, allows tar/untar to work, and
> > allows us to tar in one namespace and untar in another while preserving
> > the capability, without risking leaking privilege into a parent
> > namespace.
> 
> Any chance of a singed-off-by?

Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
-s.  Do you want me to resend the whole shebang, or does

Signed-off-by: Serge Hallyn 

suffice?  (My previous iterations did have it fwiw so I don't think I could
legally disavow it now :)

[PATCH 1/2] arm64:dt:ls1046a: Add TMU device tree support for LS1046A

[Jia Hongtao]

Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..40604e9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -45,6 +45,8 @@
  */
 
 #include 
+#include 
+
 
 / {
compatible = "fsl,ls1046a";
@@ -67,6 +69,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -279,6 +282,82 @@
clocks = <>;
};
 
+   tmu: tmu@1f0 {
+   compatible = "fsl,qoriq-tmu";
+   reg = <0x0 0x1f0 0x0 0x1>;
+   interrupts = <0 33 0x4>;
+   fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
+   fsl,tmu-calibration = <0x 0x0026
+  0x0001 0x002d
+  0x0002 0x0032
+  0x0003 0x0039
+  0x0004 0x003f
+  0x0005 0x0046
+  0x0006 0x004d
+  0x0007 0x0054
+  0x0008 0x005a
+  0x0009 0x0061
+  0x000a 0x006a
+  0x000b 0x0071
+
+  0x0001 0x0025
+  0x00010001 0x002c
+  0x00010002 0x0035
+  0x00010003 0x003d
+  0x00010004 0x0045
+  0x00010005 0x004e
+  0x00010006 0x0057
+  0x00010007 0x0061
+  0x00010008 0x006b
+  0x00010009 0x0076
+
+  0x0002 0x0029
+  0x00020001 0x0033
+  0x00020002 0x003d
+  0x00020003 0x0049
+  0x00020004 0x0056
+  0x00020005 0x0061
+  0x00020006 0x006d
+
+  0x0003 0x0021
+  0x00030001 0x002a
+  0x00030002 0x003c
+  0x00030003 0x004e>;
+   big-endian;
+   #thermal-sensor-cells = <1>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+
+   thermal-sensors = < 3>;
+
+   trips {
+   cpu_alert: cpu-alert {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+   cpu_crit: cpu-crit {
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert>;
+   cooling-device =
+   < THERMAL_NO_LIMIT
+   THERMAL_NO_LIMIT>;
+   };
+   };
+  

[PATCH 1/2] arm64:dt:ls1046a: Add TMU device tree support for LS1046A

[Jia Hongtao]

Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..40604e9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -45,6 +45,8 @@
  */
 
 #include 
+#include 
+
 
 / {
compatible = "fsl,ls1046a";
@@ -67,6 +69,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -279,6 +282,82 @@
clocks = <>;
};
 
+   tmu: tmu@1f0 {
+   compatible = "fsl,qoriq-tmu";
+   reg = <0x0 0x1f0 0x0 0x1>;
+   interrupts = <0 33 0x4>;
+   fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
+   fsl,tmu-calibration = <0x 0x0026
+  0x0001 0x002d
+  0x0002 0x0032
+  0x0003 0x0039
+  0x0004 0x003f
+  0x0005 0x0046
+  0x0006 0x004d
+  0x0007 0x0054
+  0x0008 0x005a
+  0x0009 0x0061
+  0x000a 0x006a
+  0x000b 0x0071
+
+  0x0001 0x0025
+  0x00010001 0x002c
+  0x00010002 0x0035
+  0x00010003 0x003d
+  0x00010004 0x0045
+  0x00010005 0x004e
+  0x00010006 0x0057
+  0x00010007 0x0061
+  0x00010008 0x006b
+  0x00010009 0x0076
+
+  0x0002 0x0029
+  0x00020001 0x0033
+  0x00020002 0x003d
+  0x00020003 0x0049
+  0x00020004 0x0056
+  0x00020005 0x0061
+  0x00020006 0x006d
+
+  0x0003 0x0021
+  0x00030001 0x002a
+  0x00030002 0x003c
+  0x00030003 0x004e>;
+   big-endian;
+   #thermal-sensor-cells = <1>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+
+   thermal-sensors = < 3>;
+
+   trips {
+   cpu_alert: cpu-alert {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+   cpu_crit: cpu-crit {
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert>;
+   cooling-device =
+   < THERMAL_NO_LIMIT
+   THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+