[PATCH v2 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes

[Andrzej Hajda]

Ultra HD modes requires clock ticking at increased rate.

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f120d99..4d28e93 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -764,6 +764,17 @@
clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
  "aclk_xiu_decon0x", "pclk_smmu_decon0x",
  "sclk_decon_vclk", "sclk_decon_eclk";
+   assigned-clocks =
+   <_mif CLK_MOUT_SCLK_DECON_TV_ECLK_A>,
+   <_mif CLK_DIV_SCLK_DECON_TV_ECLK>,
+   <_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>,
+   <_disp CLK_MOUT_SCLK_DECON_TV_ECLK>;
+   assigned-clock-parents =
+   <_mif CLK_MOUT_BUS_PLL_DIV2>,
+   <0>,
+   <_mif CLK_SCLK_DECON_TV_ECLK_DISP>,
+   <_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>;
+   assigned-clock-rates = <0>, <4>;
samsung,disp-sysreg = <_disp>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = ,
-- 
2.7.4

[PATCH v2 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes

[Andrzej Hajda]

Ultra HD modes requires clock ticking at increased rate.

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f120d99..4d28e93 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -764,6 +764,17 @@
clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
  "aclk_xiu_decon0x", "pclk_smmu_decon0x",
  "sclk_decon_vclk", "sclk_decon_eclk";
+   assigned-clocks =
+   <_mif CLK_MOUT_SCLK_DECON_TV_ECLK_A>,
+   <_mif CLK_DIV_SCLK_DECON_TV_ECLK>,
+   <_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>,
+   <_disp CLK_MOUT_SCLK_DECON_TV_ECLK>;
+   assigned-clock-parents =
+   <_mif CLK_MOUT_BUS_PLL_DIV2>,
+   <0>,
+   <_mif CLK_SCLK_DECON_TV_ECLK_DISP>,
+   <_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>;
+   assigned-clock-rates = <0>, <4>;
samsung,disp-sysreg = <_disp>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = ,
-- 
2.7.4

Re: [PATCH 10/21] MIPS memblock: Discard bootmem allocator initialization

[Marcin Nowakowski]

Hi Serge,

On 19.12.2016 03:07, Serge Semin wrote:

Bootmem allocator initialization needs to be discarded.
PFN limit constants are still in use by some subsystems, so they
need to be properly initialized. The initialization is moved into
a separate method and performed with help of commonly used
platform-specific constants. It might me too simplified, but most
of the kernel platforms do it the same way. Moreover it's much
easier to debug it, when it's not that complicated.

Signed-off-by: Serge Semin 
---
 arch/mips/kernel/setup.c | 193 -
 1 file changed, 21 insertions(+), 172 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index e746793..6562f55 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -626,6 +626,25 @@ static void __init request_crashkernel(struct resource 
*res) { }
 #endif /* !CONFIG_KEXEC */

 /*
+ * Calcualte PFN limits with respect to the defined memory layout
+ */
+static void __init find_pfn_limits(void)
+{
+   phys_addr_t ram_end = memblock_end_of_DRAM();
+
+   min_low_pfn = ARCH_PFN_OFFSET;
+   max_low_pfn = PFN_UP(HIGHMEM_START);


This doesn't look right - as this may set max_low_pfn to more than the 
actual physical memory size. In some cases this might be a serious 
problem and it doesn't look like any other platform does that.
Even in MIPS code you can find uses of max_low_pfn that would be 
seriously affected by this change (vpe loader with 
CONFIG_MIPS_VPE_LOADER_TOM).



+   max_pfn = PFN_UP(ram_end);
+#ifdef CONFIG_HIGHMEM
+   highstart_pfn = max_low_pfn;
+   highend_pfn = max_pfn <= highstart_pfn ? highstart_pfn : max_pfn;
+#endif
+   pr_info("PFNs: low min %lu, low max %lu, high start %lu, high end %lu,"
+   "max %lu\n",
+   min_low_pfn, max_low_pfn, highstart_pfn, highend_pfn, max_pfn);
+}
+
+/*
  * Initialize the bootmem allocator. It also setup initrd related data
  * if needed.
  */




I fully agree with you that the current initialisation code is really 
complex and difficult to debug, but the modified one seems a bit too 
simplified.


Regards,
Marcin

Re: [PATCH 10/21] MIPS memblock: Discard bootmem allocator initialization

[Marcin Nowakowski]

Hi Serge,

On 19.12.2016 03:07, Serge Semin wrote:

Bootmem allocator initialization needs to be discarded.
PFN limit constants are still in use by some subsystems, so they
need to be properly initialized. The initialization is moved into
a separate method and performed with help of commonly used
platform-specific constants. It might me too simplified, but most
of the kernel platforms do it the same way. Moreover it's much
easier to debug it, when it's not that complicated.

Signed-off-by: Serge Semin 
---
 arch/mips/kernel/setup.c | 193 -
 1 file changed, 21 insertions(+), 172 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index e746793..6562f55 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -626,6 +626,25 @@ static void __init request_crashkernel(struct resource 
*res) { }
 #endif /* !CONFIG_KEXEC */

 /*
+ * Calcualte PFN limits with respect to the defined memory layout
+ */
+static void __init find_pfn_limits(void)
+{
+   phys_addr_t ram_end = memblock_end_of_DRAM();
+
+   min_low_pfn = ARCH_PFN_OFFSET;
+   max_low_pfn = PFN_UP(HIGHMEM_START);


This doesn't look right - as this may set max_low_pfn to more than the 
actual physical memory size. In some cases this might be a serious 
problem and it doesn't look like any other platform does that.
Even in MIPS code you can find uses of max_low_pfn that would be 
seriously affected by this change (vpe loader with 
CONFIG_MIPS_VPE_LOADER_TOM).



+   max_pfn = PFN_UP(ram_end);
+#ifdef CONFIG_HIGHMEM
+   highstart_pfn = max_low_pfn;
+   highend_pfn = max_pfn <= highstart_pfn ? highstart_pfn : max_pfn;
+#endif
+   pr_info("PFNs: low min %lu, low max %lu, high start %lu, high end %lu,"
+   "max %lu\n",
+   min_low_pfn, max_low_pfn, highstart_pfn, highend_pfn, max_pfn);
+}
+
+/*
  * Initialize the bootmem allocator. It also setup initrd related data
  * if needed.
  */




I fully agree with you that the current initialisation code is really 
complex and difficult to debug, but the modified one seems a bit too 
simplified.


Regards,
Marcin

Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to NO_BOOTMEM

[Marcin Nowakowski]

Hi Serge,

Thanks for this patch series, it's really useful. I've tested it on 
Malta and Ci40 and it seems to work well (I've posted a few small 
comments separately).



On 19.12.2016 03:07, Serge Semin wrote:

Most of the modern platforms supported by linux kernel have already
been cleaned up of old bootmem allocator by moving to nobootmem
interface wrapping up the memblock. This patchset is the first
attempt to do the similar improvement for MIPS for UMA systems
only.

Even though the porting was performed as much careful as possible
there still might be problem with support of some platforms,
especially Loonson3 or SGI IP27, which perform early memory manager
initialization by their self.



The patchset is split so individual patch being consistent in
functional and buildable ways. But the MIPS early memory manager
will work correctly only either with or without the whole set being
applied. For the same reason a reviewer should not pay much attention
to methods bootmem_init(), arch_mem_init(), paging_init() and
mem_init() until they are fully refactored.


I'm not sure this can be merged that way? It would be up to Ralf to 
decide, but it is generally expected that all intermediate patches not 
only build, but also work correctly. I understand that this might be 
difficult to achieve given the scale of changes required here.



The patchset is applied on top of kernel v4.9.


Can you please work on cleaning up the issues discussed in the comments 
so far as well as rebasing (and updating) the changes onto linux-next? 
There are a few patches I made related to kexec and kernel relocation 
that will force changes in your code (although I admit that the changes 
I did for kexec/relocation were in some places unnecessarily complex 
because of the mess in the bootmem handling in MIPS that you are now 
trying to clean up).



Thanks,
Marcin


Signed-off-by: Serge Semin 

Serge Semin (21):
  MIPS memblock: Unpin dts memblock sanity check method
  MIPS memblock: Add dts mem and reserved-mem callbacks
  MIPS memblock: Alter traditional add_memory_region() method
  MIPS memblock: Alter user-defined memory parameter parser
  MIPS memblock: Alter initrd memory reservation method
  MIPS memblock: Alter kexec-crashkernel parameters parser
  MIPS memblock: Alter elfcorehdr parameters parser
  MIPS memblock: Move kernel parameters parser into individual method
  MIPS memblock: Move kernel memory reservation to individual method
  MIPS memblock: Discard bootmem allocator initialization
  MIPS memblock: Add memblock sanity check method
  MIPS memblock: Add memblock print outs in debug
  MIPS memblock: Add memblock allocator initialization
  MIPS memblock: Alter IO resources initialization method
  MIPS memblock: Alter weakened MAAR initialization method
  MIPS memblock: Alter paging initialization method
  MIPS memblock: Alter high memory freeing method
  MIPS memblock: Slightly improve buddy allocator init method
  MIPS memblock: Add print out method of kernel virtual memory layout
  MIPS memblock: Add free low memory test method call
  MIPS memblock: Deactivate old bootmem allocator

 arch/mips/Kconfig|   2 +-
 arch/mips/kernel/prom.c  |  32 +-
 arch/mips/kernel/setup.c | 958 +++--
 arch/mips/mm/init.c  | 234 ---
 drivers/of/fdt.c |  47 +-
 include/linux/of_fdt.h   |   1 +
 6 files changed, 739 insertions(+), 535 deletions(-)

Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to NO_BOOTMEM

[Marcin Nowakowski]

Hi Serge,

Thanks for this patch series, it's really useful. I've tested it on 
Malta and Ci40 and it seems to work well (I've posted a few small 
comments separately).



On 19.12.2016 03:07, Serge Semin wrote:

Most of the modern platforms supported by linux kernel have already
been cleaned up of old bootmem allocator by moving to nobootmem
interface wrapping up the memblock. This patchset is the first
attempt to do the similar improvement for MIPS for UMA systems
only.

Even though the porting was performed as much careful as possible
there still might be problem with support of some platforms,
especially Loonson3 or SGI IP27, which perform early memory manager
initialization by their self.



The patchset is split so individual patch being consistent in
functional and buildable ways. But the MIPS early memory manager
will work correctly only either with or without the whole set being
applied. For the same reason a reviewer should not pay much attention
to methods bootmem_init(), arch_mem_init(), paging_init() and
mem_init() until they are fully refactored.


I'm not sure this can be merged that way? It would be up to Ralf to 
decide, but it is generally expected that all intermediate patches not 
only build, but also work correctly. I understand that this might be 
difficult to achieve given the scale of changes required here.



The patchset is applied on top of kernel v4.9.


Can you please work on cleaning up the issues discussed in the comments 
so far as well as rebasing (and updating) the changes onto linux-next? 
There are a few patches I made related to kexec and kernel relocation 
that will force changes in your code (although I admit that the changes 
I did for kexec/relocation were in some places unnecessarily complex 
because of the mess in the bootmem handling in MIPS that you are now 
trying to clean up).



Thanks,
Marcin


Signed-off-by: Serge Semin 

Serge Semin (21):
  MIPS memblock: Unpin dts memblock sanity check method
  MIPS memblock: Add dts mem and reserved-mem callbacks
  MIPS memblock: Alter traditional add_memory_region() method
  MIPS memblock: Alter user-defined memory parameter parser
  MIPS memblock: Alter initrd memory reservation method
  MIPS memblock: Alter kexec-crashkernel parameters parser
  MIPS memblock: Alter elfcorehdr parameters parser
  MIPS memblock: Move kernel parameters parser into individual method
  MIPS memblock: Move kernel memory reservation to individual method
  MIPS memblock: Discard bootmem allocator initialization
  MIPS memblock: Add memblock sanity check method
  MIPS memblock: Add memblock print outs in debug
  MIPS memblock: Add memblock allocator initialization
  MIPS memblock: Alter IO resources initialization method
  MIPS memblock: Alter weakened MAAR initialization method
  MIPS memblock: Alter paging initialization method
  MIPS memblock: Alter high memory freeing method
  MIPS memblock: Slightly improve buddy allocator init method
  MIPS memblock: Add print out method of kernel virtual memory layout
  MIPS memblock: Add free low memory test method call
  MIPS memblock: Deactivate old bootmem allocator

 arch/mips/Kconfig|   2 +-
 arch/mips/kernel/prom.c  |  32 +-
 arch/mips/kernel/setup.c | 958 +++--
 arch/mips/mm/init.c  | 234 ---
 drivers/of/fdt.c |  47 +-
 include/linux/of_fdt.h   |   1 +
 6 files changed, 739 insertions(+), 535 deletions(-)

Re: [PATCH 04/21] MIPS memblock: Alter user-defined memory parameter parser

[Marcin Nowakowski]

Hi Serge,

On 19.12.2016 03:07, Serge Semin wrote:

Both new memblock and boot_mem_map subsystems need to be fully
cleared before a new memory region is added. So the early parser is
correspondingly modified.

Signed-off-by: Serge Semin 
---
 arch/mips/kernel/setup.c | 67 +-
 1 file changed, 37 insertions(+), 30 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 9da6f8a..789aafe 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -229,6 +229,43 @@ static void __init print_memory_map(void)
 }

 /*
+ * Parse "mem=size@start" parameter rewriting a defined memory map
+ * We look for mem=size@start, where start and size are "value[KkMm]"
+ */
+static int __init early_parse_mem(char *p)
+{
+   static int usermem;


usermem variable seems unnecessary now and could easily be removed?


+   phys_addr_t start, size;
+
+   start = PHYS_OFFSET;
+   size = memparse(p, );
+   if (*p == '@')
+   start = memparse(p + 1, );
+
+   /*
+* If a user specifies memory size, we blow away any automatically
+* generated regions.
+*/
+   if (usermem == 0) {
+   phys_addr_t ram_start = memblock_start_of_DRAM();
+   phys_addr_t ram_end = memblock_end_of_DRAM() - ram_start;
+
+   pr_notice("Discard memory layout %pa - %pa",
+ _start, _end);


missing \n in printk


+   memblock_remove(ram_start, ram_end - ram_start);
+   boot_mem_map.nr_map = 0;
+   usermem = 1;
+   }
+   pr_notice("Add userdefined memory region %08zx @ %pa",
+ (size_t)size, );


ditto


+   add_memory_region(start, size, BOOT_MEM_RAM);
+   return 0;
+}
+early_param("mem", early_parse_mem);
+
+/*
  * Manage initrd
  */
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -613,31 +650,6 @@ static void __init bootmem_init(void)
  * initialization hook for anything else was introduced.
  */

-static int usermem __initdata;
-
-static int __init early_parse_mem(char *p)
-{
-   phys_addr_t start, size;
-
-   /*
-* If a user specifies memory size, we
-* blow away any automatically generated
-* size.
-*/
-   if (usermem == 0) {
-   boot_mem_map.nr_map = 0;
-   usermem = 1;
-   }
-   start = 0;
-   size = memparse(p, );
-   if (*p == '@')
-   start = memparse(p + 1, );
-
-   add_memory_region(start, size, BOOT_MEM_RAM);
-   return 0;
-}
-early_param("mem", early_parse_mem);
-
 #ifdef CONFIG_PROC_VMCORE
 unsigned long setup_elfcorehdr, setup_elfcorehdr_size;
 static int __init early_parse_elfcorehdr(char *p)
@@ -797,11 +809,6 @@ static void __init arch_mem_init(char **cmdline_p)

parse_early_param();

-   if (usermem) {
-   pr_info("User-defined physical RAM map:\n");
-   print_memory_map();
-   }
-
bootmem_init();
 #ifdef CONFIG_PROC_VMCORE
if (setup_elfcorehdr && setup_elfcorehdr_size) {




Regards,
Marcin

Re: [PATCH 04/21] MIPS memblock: Alter user-defined memory parameter parser

[Marcin Nowakowski]

Hi Serge,

On 19.12.2016 03:07, Serge Semin wrote:

Both new memblock and boot_mem_map subsystems need to be fully
cleared before a new memory region is added. So the early parser is
correspondingly modified.

Signed-off-by: Serge Semin 
---
 arch/mips/kernel/setup.c | 67 +-
 1 file changed, 37 insertions(+), 30 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 9da6f8a..789aafe 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -229,6 +229,43 @@ static void __init print_memory_map(void)
 }

 /*
+ * Parse "mem=size@start" parameter rewriting a defined memory map
+ * We look for mem=size@start, where start and size are "value[KkMm]"
+ */
+static int __init early_parse_mem(char *p)
+{
+   static int usermem;


usermem variable seems unnecessary now and could easily be removed?


+   phys_addr_t start, size;
+
+   start = PHYS_OFFSET;
+   size = memparse(p, );
+   if (*p == '@')
+   start = memparse(p + 1, );
+
+   /*
+* If a user specifies memory size, we blow away any automatically
+* generated regions.
+*/
+   if (usermem == 0) {
+   phys_addr_t ram_start = memblock_start_of_DRAM();
+   phys_addr_t ram_end = memblock_end_of_DRAM() - ram_start;
+
+   pr_notice("Discard memory layout %pa - %pa",
+ _start, _end);


missing \n in printk


+   memblock_remove(ram_start, ram_end - ram_start);
+   boot_mem_map.nr_map = 0;
+   usermem = 1;
+   }
+   pr_notice("Add userdefined memory region %08zx @ %pa",
+ (size_t)size, );


ditto


+   add_memory_region(start, size, BOOT_MEM_RAM);
+   return 0;
+}
+early_param("mem", early_parse_mem);
+
+/*
  * Manage initrd
  */
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -613,31 +650,6 @@ static void __init bootmem_init(void)
  * initialization hook for anything else was introduced.
  */

-static int usermem __initdata;
-
-static int __init early_parse_mem(char *p)
-{
-   phys_addr_t start, size;
-
-   /*
-* If a user specifies memory size, we
-* blow away any automatically generated
-* size.
-*/
-   if (usermem == 0) {
-   boot_mem_map.nr_map = 0;
-   usermem = 1;
-   }
-   start = 0;
-   size = memparse(p, );
-   if (*p == '@')
-   start = memparse(p + 1, );
-
-   add_memory_region(start, size, BOOT_MEM_RAM);
-   return 0;
-}
-early_param("mem", early_parse_mem);
-
 #ifdef CONFIG_PROC_VMCORE
 unsigned long setup_elfcorehdr, setup_elfcorehdr_size;
 static int __init early_parse_elfcorehdr(char *p)
@@ -797,11 +809,6 @@ static void __init arch_mem_init(char **cmdline_p)

parse_early_param();

-   if (usermem) {
-   pr_info("User-defined physical RAM map:\n");
-   print_memory_map();
-   }
-
bootmem_init();
 #ifdef CONFIG_PROC_VMCORE
if (setup_elfcorehdr && setup_elfcorehdr_size) {




Regards,
Marcin

Re: [Intel-gfx] [RESEND PATCH v14 2/2] drm/i915: Put "cooked" vlank counters in frame CRC lines

[Daniel Vetter]

On Mon, Jan 16, 2017 at 10:12:36AM +0100, Tomeu Vizoso wrote:
> On 10 January 2017 at 17:31, Daniel Vetter  wrote:
> > On Tue, Jan 10, 2017 at 05:54:57PM +0200, Ville Syrjälä wrote:
> >> On Tue, Jan 10, 2017 at 02:43:05PM +0100, Tomeu Vizoso wrote:
> >> > Use drm_accurate_vblank_count so we have the full 32 bit to represent
> >> > the frame counter and userspace has a simpler way of knowing when the
> >> > counter wraps around.
> >> >
> >> > Signed-off-by: Tomeu Vizoso 
> >> > Reviewed-by: Emil Velikov 
> >> > Reviewed-by: Robert Foss 
> >> > ---
> >> >
> >> >  drivers/gpu/drm/i915/i915_irq.c | 6 +++---
> >> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> > b/drivers/gpu/drm/i915/i915_irq.c
> >> > index b9beb5955dae..75fb1f66cc0c 100644
> >> > --- a/drivers/gpu/drm/i915/i915_irq.c
> >> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> > @@ -1557,7 +1557,6 @@ static void display_pipe_crc_irq_handler(struct 
> >> > drm_i915_private *dev_priv,
> >> > struct drm_driver *driver = dev_priv->drm.driver;
> >> > uint32_t crcs[5];
> >> > int head, tail;
> >> > -   u32 frame;
> >> >
> >> > spin_lock(_crc->lock);
> >> > if (pipe_crc->source) {
> >> > @@ -1612,8 +1611,9 @@ static void display_pipe_crc_irq_handler(struct 
> >> > drm_i915_private *dev_priv,
> >> > crcs[2] = crc2;
> >> > crcs[3] = crc3;
> >> > crcs[4] = crc4;
> >> > -   frame = driver->get_vblank_counter(_priv->drm, pipe);
> >> > -   drm_crtc_add_crc_entry(>base, true, frame, crcs);
> >> > +   drm_crtc_add_crc_entry(>base, true,
> >> > +  
> >> > drm_accurate_vblank_count(>base),
> >>
> >> My assumption would be that this gets called after the vblank irq
> >> handler, so using the _accurate version seems a bit overkill.
> >
> > Since we're at like v15 of this I figured I'll pull this in, and we can
> > polish this a bit more later. Tomeu, can you pls do that follow-up patch
> > and get Ville to review+merge it.
> 
> At least on the SKL and SNB I have here, the -sequence subtests in
> kms_pipe_crc_basic fail if I replace the call to
> drm_accurate_vblank_count with drm_crtc_vblank_count.
> 
> Any ideas on why this could be?

No idea at all, on a quick check things seem ordered correctly. Can you
pls paste how the test falls over?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [RESEND PATCH v14 2/2] drm/i915: Put "cooked" vlank counters in frame CRC lines

[Daniel Vetter]

On Mon, Jan 16, 2017 at 10:12:36AM +0100, Tomeu Vizoso wrote:
> On 10 January 2017 at 17:31, Daniel Vetter  wrote:
> > On Tue, Jan 10, 2017 at 05:54:57PM +0200, Ville Syrjälä wrote:
> >> On Tue, Jan 10, 2017 at 02:43:05PM +0100, Tomeu Vizoso wrote:
> >> > Use drm_accurate_vblank_count so we have the full 32 bit to represent
> >> > the frame counter and userspace has a simpler way of knowing when the
> >> > counter wraps around.
> >> >
> >> > Signed-off-by: Tomeu Vizoso 
> >> > Reviewed-by: Emil Velikov 
> >> > Reviewed-by: Robert Foss 
> >> > ---
> >> >
> >> >  drivers/gpu/drm/i915/i915_irq.c | 6 +++---
> >> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> > b/drivers/gpu/drm/i915/i915_irq.c
> >> > index b9beb5955dae..75fb1f66cc0c 100644
> >> > --- a/drivers/gpu/drm/i915/i915_irq.c
> >> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> > @@ -1557,7 +1557,6 @@ static void display_pipe_crc_irq_handler(struct 
> >> > drm_i915_private *dev_priv,
> >> > struct drm_driver *driver = dev_priv->drm.driver;
> >> > uint32_t crcs[5];
> >> > int head, tail;
> >> > -   u32 frame;
> >> >
> >> > spin_lock(_crc->lock);
> >> > if (pipe_crc->source) {
> >> > @@ -1612,8 +1611,9 @@ static void display_pipe_crc_irq_handler(struct 
> >> > drm_i915_private *dev_priv,
> >> > crcs[2] = crc2;
> >> > crcs[3] = crc3;
> >> > crcs[4] = crc4;
> >> > -   frame = driver->get_vblank_counter(_priv->drm, pipe);
> >> > -   drm_crtc_add_crc_entry(>base, true, frame, crcs);
> >> > +   drm_crtc_add_crc_entry(>base, true,
> >> > +  
> >> > drm_accurate_vblank_count(>base),
> >>
> >> My assumption would be that this gets called after the vblank irq
> >> handler, so using the _accurate version seems a bit overkill.
> >
> > Since we're at like v15 of this I figured I'll pull this in, and we can
> > polish this a bit more later. Tomeu, can you pls do that follow-up patch
> > and get Ville to review+merge it.
> 
> At least on the SKL and SNB I have here, the -sequence subtests in
> kms_pipe_crc_basic fail if I replace the call to
> drm_accurate_vblank_count with drm_crtc_vblank_count.
> 
> Any ideas on why this could be?

No idea at all, on a quick check things seem ordered correctly. Can you
pls paste how the test falls over?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC

[Chris Packham]

On 21/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = {
>>  .num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
>>  };
>>
>> +static const struct coreclk_soc_desc mv98dx3236_coreclks = {
>> +.get_tclk_freq = mv98dx3236_get_tclk_freq,
>> +.get_cpu_freq = mv98dx3236_get_cpu_freq,
>> +.get_clk_ratio = NULL,
>> +.ratios = NULL,
>> +.num_ratios = 0,
>
> Are these intentionally initialized to 0 explicitly? Otherwise we
> could leave them out and it's all the same.
>

No reason, just didn't remove the unused members when copying the 
armada-xp example above.

>> +};
>> +
>>  /*
>>   * Clock Gating Control
>>   */
> [..]
>> @@ -243,5 +245,30 @@ static void __init of_cpu_clk_setup(struct device_node 
>> *node)
>>  iounmap(clock_complex_base);
>>  }
>>
>> +/* Use this function to call the generic setup with the correct
>> + * clock operation
>> + */
>> +static void __init of_cpu_clk_setup(struct device_node *node)
>> +{
>> +_of_cpu_clk_setup(node, _ops);
>> +}
>> +
>>  CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
>>   of_cpu_clk_setup);
>> +
>> +/* Define the clock and operations for the mv98dx3236 - it cannot perform
>> + * any operations.
>> + */
>> +static const struct clk_ops mv98dx3236_cpu_ops = {
>> +.recalc_rate = NULL,
>> +.round_rate = NULL,
>> +.set_rate = NULL,
>
> But clk_set_rate() works silently? Why not just register a clk
> provider that returns a NULL pointer? Then there isn't any
> structure to maintain?
>

Not 100% sure what you mean. Something like this?

+static void __init of_mv98dx3236_cpu_clk_setup(struct device_node *node)
+{
+   of_clk_add_provider(node, of_clk_src_simple_get, NULL);
+}

Seems to work as expected (i.e. does nothing, kernel boots/runs).

Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC

[Chris Packham]

On 21/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = {
>>  .num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
>>  };
>>
>> +static const struct coreclk_soc_desc mv98dx3236_coreclks = {
>> +.get_tclk_freq = mv98dx3236_get_tclk_freq,
>> +.get_cpu_freq = mv98dx3236_get_cpu_freq,
>> +.get_clk_ratio = NULL,
>> +.ratios = NULL,
>> +.num_ratios = 0,
>
> Are these intentionally initialized to 0 explicitly? Otherwise we
> could leave them out and it's all the same.
>

No reason, just didn't remove the unused members when copying the 
armada-xp example above.

>> +};
>> +
>>  /*
>>   * Clock Gating Control
>>   */
> [..]
>> @@ -243,5 +245,30 @@ static void __init of_cpu_clk_setup(struct device_node 
>> *node)
>>  iounmap(clock_complex_base);
>>  }
>>
>> +/* Use this function to call the generic setup with the correct
>> + * clock operation
>> + */
>> +static void __init of_cpu_clk_setup(struct device_node *node)
>> +{
>> +_of_cpu_clk_setup(node, _ops);
>> +}
>> +
>>  CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
>>   of_cpu_clk_setup);
>> +
>> +/* Define the clock and operations for the mv98dx3236 - it cannot perform
>> + * any operations.
>> + */
>> +static const struct clk_ops mv98dx3236_cpu_ops = {
>> +.recalc_rate = NULL,
>> +.round_rate = NULL,
>> +.set_rate = NULL,
>
> But clk_set_rate() works silently? Why not just register a clk
> provider that returns a NULL pointer? Then there isn't any
> structure to maintain?
>

Not 100% sure what you mean. Something like this?

+static void __init of_mv98dx3236_cpu_clk_setup(struct device_node *node)
+{
+   of_clk_add_provider(node, of_clk_src_simple_get, NULL);
+}

Seems to work as expected (i.e. does nothing, kernel boots/runs).

Nuevo Etiquetado Frontal Nutrimental

[Ojeda Mauricio]

Últimos Lugares, confirme su asistencia ahora!

Distinguido(a) Cliente, tenemos el gusto de invitarle al evento: Etiquetado 
Nutrimental de Alimentos y Bebidas que se impartirá en:
27 Enero México, D.F.

La etiqueta representa un valioso instrumento de información para el consumidor 
y su primer contacto con el producto. Su contenido se constituye como un medio 
de promoción o publicidad, además de incluir información respecto de las 
características, composición y propiedades del mismo.
En este sentido, hoy en día existe una marcada preferencia hacia los alimentos 
saludables, lo cual ha aumentado el interés de los consumidores en la 
información nutrimental contenida en la etiqueta.

Reciba un folleto electrónico con el temario completo, responda este correo con 
la palabra NUTRIMENTAL mencione:
-Nombre:
-Teléfono:
-Empresa:

O bien, comuniquese con nosotros a: 01 800 333 7726 con horario de atención de 
lunes a viernes de 9:00 a 18:30.

-Reenvíe esta invitación a compañeras que les pueda ser de utilidad.

Si no eres el usuario o si deseas ser borrado: linux-kernel@vger.kernel.org de 
nuestro listado de envíos sólo responda con la palabra (cot321) y su solicitud 
será procesada en las próximas 48 hrs.

Nuevo Etiquetado Frontal Nutrimental

[Ojeda Mauricio]

Últimos Lugares, confirme su asistencia ahora!

Distinguido(a) Cliente, tenemos el gusto de invitarle al evento: Etiquetado 
Nutrimental de Alimentos y Bebidas que se impartirá en:
27 Enero México, D.F.

La etiqueta representa un valioso instrumento de información para el consumidor 
y su primer contacto con el producto. Su contenido se constituye como un medio 
de promoción o publicidad, además de incluir información respecto de las 
características, composición y propiedades del mismo.
En este sentido, hoy en día existe una marcada preferencia hacia los alimentos 
saludables, lo cual ha aumentado el interés de los consumidores en la 
información nutrimental contenida en la etiqueta.

Reciba un folleto electrónico con el temario completo, responda este correo con 
la palabra NUTRIMENTAL mencione:
-Nombre:
-Teléfono:
-Empresa:

O bien, comuniquese con nosotros a: 01 800 333 7726 con horario de atención de 
lunes a viernes de 9:00 a 18:30.

-Reenvíe esta invitación a compañeras que les pueda ser de utilidad.

Si no eres el usuario o si deseas ser borrado: linux-kernel@vger.kernel.org de 
nuestro listado de envíos sólo responda con la palabra (cot321) y su solicitud 
será procesada en las próximas 48 hrs.

Re: [PATCH v3] zram: extend zero pages to same element pages

[Minchan Kim]

On Mon, Jan 23, 2017 at 02:17:23PM +0800, zhouxianrong wrote:
> i am not sure as well about reverse hurting cache.
> 
> On 2017/1/23 14:13, Joonsoo Kim wrote:
> >On Mon, Jan 23, 2017 at 01:47:20PM +0900, Minchan Kim wrote:
> >>Hello,
> >>
> >>When I look at first patch, I wanted to use increment loop but didn't
> >>tell to you because that small piece of code is no harmful for readbility
> >>to me so I want to keep author's code rather than pointing the trivial
> >>which is just matter of preference out.
> >>
> >>Rather than readiblity, I suspect it might hurt performance and talked
> >>with Namhyung but we cannot find anything decremental loop is bad
> >>compared to incremental. Rather than, many articles have been said
> >>decrement loop is faster like zhouxianrong's mentiond although I don't
> >>think it makes marginal difference.
> >>
> >>Joonsoo, why do you think incremental is faster?
> >>zhouxianrong, why do you think decrement loops makes cache problem?
> >>
> >>I'm okay either way. Just want to know why you guys think about it.
> >
> >Hmm... I guess that cache prefetcher works better for forward access
> >but I'm not sure.
 
If there is no one to ask changing it to incremental, I wanted to go
with decremental you wrote firstly but now there is one more people
who likes incremental loop as well as me. And he spent a time to his
precious time for review so we should take care of his credit.

So, please go with incremental approach if you are not against.
Please resend the patch by yourself. With patch I sent today, I guess
you got to know my intention about semantic change of documentation
, description change to notice zero page change risk and remoe
partial handling function. :)

Thanks.

Re: [PATCH v3] zram: extend zero pages to same element pages

[Minchan Kim]

On Mon, Jan 23, 2017 at 02:17:23PM +0800, zhouxianrong wrote:
> i am not sure as well about reverse hurting cache.
> 
> On 2017/1/23 14:13, Joonsoo Kim wrote:
> >On Mon, Jan 23, 2017 at 01:47:20PM +0900, Minchan Kim wrote:
> >>Hello,
> >>
> >>When I look at first patch, I wanted to use increment loop but didn't
> >>tell to you because that small piece of code is no harmful for readbility
> >>to me so I want to keep author's code rather than pointing the trivial
> >>which is just matter of preference out.
> >>
> >>Rather than readiblity, I suspect it might hurt performance and talked
> >>with Namhyung but we cannot find anything decremental loop is bad
> >>compared to incremental. Rather than, many articles have been said
> >>decrement loop is faster like zhouxianrong's mentiond although I don't
> >>think it makes marginal difference.
> >>
> >>Joonsoo, why do you think incremental is faster?
> >>zhouxianrong, why do you think decrement loops makes cache problem?
> >>
> >>I'm okay either way. Just want to know why you guys think about it.
> >
> >Hmm... I guess that cache prefetcher works better for forward access
> >but I'm not sure.
 
If there is no one to ask changing it to incremental, I wanted to go
with decremental you wrote firstly but now there is one more people
who likes incremental loop as well as me. And he spent a time to his
precious time for review so we should take care of his credit.

So, please go with incremental approach if you are not against.
Please resend the patch by yourself. With patch I sent today, I guess
you got to know my intention about semantic change of documentation
, description change to notice zero page change risk and remoe
partial handling function. :)

Thanks.

[PATCH] ARM: tegra: paz00: fix __initdata placement

[Dmitry Torokhov]

To have expected effect the __initdata attribute should go after variable
name and before initializer.`

Signed-off-by: Dmitry Torokhov 
---
 arch/arm/mach-tegra/board-paz00.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/board-paz00.c 
b/arch/arm/mach-tegra/board-paz00.c
index 7478f6fb3664..ea6bff404161 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -23,7 +23,7 @@
 
 #include "board.h"
 
-static struct property_entry __initdata wifi_rfkill_prop[] = {
+static struct property_entry wifi_rfkill_prop[] __initdata = {
PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
PROPERTY_ENTRY_STRING("type", "wlan"),
{ },
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

[PATCH] ARM: tegra: paz00: fix __initdata placement

[Dmitry Torokhov]

To have expected effect the __initdata attribute should go after variable
name and before initializer.`

Signed-off-by: Dmitry Torokhov 
---
 arch/arm/mach-tegra/board-paz00.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/board-paz00.c 
b/arch/arm/mach-tegra/board-paz00.c
index 7478f6fb3664..ea6bff404161 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -23,7 +23,7 @@
 
 #include "board.h"
 
-static struct property_entry __initdata wifi_rfkill_prop[] = {
+static struct property_entry wifi_rfkill_prop[] __initdata = {
PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
PROPERTY_ENTRY_STRING("type", "wlan"),
{ },
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Minchan Kim]

On Mon, Jan 23, 2017 at 04:13:39PM +0900, Sergey Senozhatsky wrote:
> On (01/23/17 15:27), Joonsoo Kim wrote:
> > Hello,
> > 
> > Think about following case in 64 bits kernel.
> > 
> > If value pattern in the page is like as following, we cannot detect
> > the same page with 'unsigned int' element.
> > 
> > ...
> > 
> > 4 bytes is 0x and next 4 bytes is 0x and so on.
> 
> yep, that's exactly the case that I though would be broken
> with a 4-bytes pattern matching. so my conlusion was that
> for 4 byte pattern we would have working detection anyway,
> for 8 bytes patterns we might have some extra matching.
> not sure if it matters that much though.

It would be better for deduplication as pattern coverage is bigger
and we cannot guess all of patterns now so it would be never ending
story(i.e., someone claims 16bytes pattern matching would be better).
So, I want to make that path fast rather than increasing dedup ratio
if memset is really fast rather than open-looping. So in future,
if we can prove bigger pattern can increase dedup ratio a lot, then,
we could consider to extend it at the cost of make that path slow.

In summary, zhouxianrong, please test pattern as Joonsoo asked.
So if there are not much benefit with 'long', let's go to the
'int' with memset. And Please resend patch if anyone dosn't oppose
strongly by the time.

Thanks.

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Minchan Kim]

On Mon, Jan 23, 2017 at 04:13:39PM +0900, Sergey Senozhatsky wrote:
> On (01/23/17 15:27), Joonsoo Kim wrote:
> > Hello,
> > 
> > Think about following case in 64 bits kernel.
> > 
> > If value pattern in the page is like as following, we cannot detect
> > the same page with 'unsigned int' element.
> > 
> > ...
> > 
> > 4 bytes is 0x and next 4 bytes is 0x and so on.
> 
> yep, that's exactly the case that I though would be broken
> with a 4-bytes pattern matching. so my conlusion was that
> for 4 byte pattern we would have working detection anyway,
> for 8 bytes patterns we might have some extra matching.
> not sure if it matters that much though.

It would be better for deduplication as pattern coverage is bigger
and we cannot guess all of patterns now so it would be never ending
story(i.e., someone claims 16bytes pattern matching would be better).
So, I want to make that path fast rather than increasing dedup ratio
if memset is really fast rather than open-looping. So in future,
if we can prove bigger pattern can increase dedup ratio a lot, then,
we could consider to extend it at the cost of make that path slow.

In summary, zhouxianrong, please test pattern as Joonsoo asked.
So if there are not much benefit with 'long', let's go to the
'int' with memset. And Please resend patch if anyone dosn't oppose
strongly by the time.

Thanks.

[PATCH 2/2] device property: allow constify properties

[Dmitry Torokhov]

There is no reason why statically defined properties should be modifiable,
so let's make device_add_properties() and the rest of pset_*() functions to
take const pointers to properties.

This will allow us to mark properties as const/__initconst at definition
sites.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/property.c  | 35 ++-
 include/linux/property.h |  2 +-
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index ee22ded63e06..4cbf99cb8ef6 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -21,7 +21,7 @@
 
 struct property_set {
struct fwnode_handle fwnode;
-   struct property_entry *properties;
+   const struct property_entry *properties;
 };
 
 static inline bool is_pset_node(struct fwnode_handle *fwnode)
@@ -35,10 +35,10 @@ static inline struct property_set *to_pset_node(struct 
fwnode_handle *fwnode)
container_of(fwnode, struct property_set, fwnode) : NULL;
 }
 
-static struct property_entry *pset_prop_get(struct property_set *pset,
-   const char *name)
+static const struct property_entry *pset_prop_get(struct property_set *pset,
+ const char *name)
 {
-   struct property_entry *prop;
+   const struct property_entry *prop;
 
if (!pset || !pset->properties)
return NULL;
@@ -50,11 +50,11 @@ static struct property_entry *pset_prop_get(struct 
property_set *pset,
return NULL;
 }
 
-static void *pset_prop_find(struct property_set *pset, const char *propname,
-   size_t length)
+static const void *pset_prop_find(struct property_set *pset,
+ const char *propname, size_t length)
 {
-   struct property_entry *prop;
-   void *pointer;
+   const struct property_entry *prop;
+   const void *pointer;
 
prop = pset_prop_get(pset, propname);
if (!prop)
@@ -74,7 +74,7 @@ static int pset_prop_read_u8_array(struct property_set *pset,
   const char *propname,
   u8 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -89,7 +89,7 @@ static int pset_prop_read_u16_array(struct property_set *pset,
const char *propname,
u16 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -104,7 +104,7 @@ static int pset_prop_read_u32_array(struct property_set 
*pset,
const char *propname,
u32 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -119,7 +119,7 @@ static int pset_prop_read_u64_array(struct property_set 
*pset,
const char *propname,
u64 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -133,7 +133,7 @@ static int pset_prop_read_u64_array(struct property_set 
*pset,
 static int pset_prop_count_elems_of_size(struct property_set *pset,
 const char *propname, size_t length)
 {
-   struct property_entry *prop;
+   const struct property_entry *prop;
 
prop = pset_prop_get(pset, propname);
if (!prop)
@@ -146,7 +146,7 @@ static int pset_prop_read_string_array(struct property_set 
*pset,
   const char *propname,
   const char **strings, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*strings);
 
pointer = pset_prop_find(pset, propname, length);
@@ -160,8 +160,8 @@ static int pset_prop_read_string_array(struct property_set 
*pset,
 static int pset_prop_read_string(struct property_set *pset,
 const char *propname, const char **strings)
 {
-   struct property_entry *prop;
-   const char **pointer;
+   const struct property_entry *prop;
+   const char * const *pointer;
 
prop = pset_prop_get(pset, propname);
if (!prop)
@@ -867,7 +867,8 @@ EXPORT_SYMBOL_GPL(device_remove_properties);
  * @dev as its secondary firmware node. The function takes a copy of
  * @properties.
  */
-int device_add_properties(struct device *dev, struct property_entry 
*properties)
+int 

[PATCH 2/2] device property: allow constify properties

[Dmitry Torokhov]

There is no reason why statically defined properties should be modifiable,
so let's make device_add_properties() and the rest of pset_*() functions to
take const pointers to properties.

This will allow us to mark properties as const/__initconst at definition
sites.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/property.c  | 35 ++-
 include/linux/property.h |  2 +-
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index ee22ded63e06..4cbf99cb8ef6 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -21,7 +21,7 @@
 
 struct property_set {
struct fwnode_handle fwnode;
-   struct property_entry *properties;
+   const struct property_entry *properties;
 };
 
 static inline bool is_pset_node(struct fwnode_handle *fwnode)
@@ -35,10 +35,10 @@ static inline struct property_set *to_pset_node(struct 
fwnode_handle *fwnode)
container_of(fwnode, struct property_set, fwnode) : NULL;
 }
 
-static struct property_entry *pset_prop_get(struct property_set *pset,
-   const char *name)
+static const struct property_entry *pset_prop_get(struct property_set *pset,
+ const char *name)
 {
-   struct property_entry *prop;
+   const struct property_entry *prop;
 
if (!pset || !pset->properties)
return NULL;
@@ -50,11 +50,11 @@ static struct property_entry *pset_prop_get(struct 
property_set *pset,
return NULL;
 }
 
-static void *pset_prop_find(struct property_set *pset, const char *propname,
-   size_t length)
+static const void *pset_prop_find(struct property_set *pset,
+ const char *propname, size_t length)
 {
-   struct property_entry *prop;
-   void *pointer;
+   const struct property_entry *prop;
+   const void *pointer;
 
prop = pset_prop_get(pset, propname);
if (!prop)
@@ -74,7 +74,7 @@ static int pset_prop_read_u8_array(struct property_set *pset,
   const char *propname,
   u8 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -89,7 +89,7 @@ static int pset_prop_read_u16_array(struct property_set *pset,
const char *propname,
u16 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -104,7 +104,7 @@ static int pset_prop_read_u32_array(struct property_set 
*pset,
const char *propname,
u32 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -119,7 +119,7 @@ static int pset_prop_read_u64_array(struct property_set 
*pset,
const char *propname,
u64 *values, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*values);
 
pointer = pset_prop_find(pset, propname, length);
@@ -133,7 +133,7 @@ static int pset_prop_read_u64_array(struct property_set 
*pset,
 static int pset_prop_count_elems_of_size(struct property_set *pset,
 const char *propname, size_t length)
 {
-   struct property_entry *prop;
+   const struct property_entry *prop;
 
prop = pset_prop_get(pset, propname);
if (!prop)
@@ -146,7 +146,7 @@ static int pset_prop_read_string_array(struct property_set 
*pset,
   const char *propname,
   const char **strings, size_t nval)
 {
-   void *pointer;
+   const void *pointer;
size_t length = nval * sizeof(*strings);
 
pointer = pset_prop_find(pset, propname, length);
@@ -160,8 +160,8 @@ static int pset_prop_read_string_array(struct property_set 
*pset,
 static int pset_prop_read_string(struct property_set *pset,
 const char *propname, const char **strings)
 {
-   struct property_entry *prop;
-   const char **pointer;
+   const struct property_entry *prop;
+   const char * const *pointer;
 
prop = pset_prop_get(pset, propname);
if (!prop)
@@ -867,7 +867,8 @@ EXPORT_SYMBOL_GPL(device_remove_properties);
  * @dev as its secondary firmware node. The function takes a copy of
  * @properties.
  */
-int device_add_properties(struct device *dev, struct property_entry 
*properties)
+int device_add_properties(struct device 

[PATCH 1/2] device property: export code duplicating array of property entries

[Dmitry Torokhov]

When augmenting ACPI-enumerated devices with additional property data based
on DMI info, a module has often several potential property sets, with only
one being active on a given box. In order to save memory it should be
possible to mark everything and __initdata or __initconst, execute DMI
match early, and duplicate relevant properties. Then kernel will discard
the rest of them.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/property.c  | 124 +++
 include/linux/property.h |   3 ++
 2 files changed, 75 insertions(+), 52 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 43a36d68c3fd..ee22ded63e06 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -682,41 +682,8 @@ int fwnode_property_match_string(struct fwnode_handle 
*fwnode,
 }
 EXPORT_SYMBOL_GPL(fwnode_property_match_string);
 
-/**
- * pset_free_set - releases memory allocated for copied property set
- * @pset: Property set to release
- *
- * Function takes previously copied property set and releases all the
- * memory allocated to it.
- */
-static void pset_free_set(struct property_set *pset)
-{
-   const struct property_entry *prop;
-   size_t i, nval;
-
-   if (!pset)
-   return;
-
-   for (prop = pset->properties; prop->name; prop++) {
-   if (prop->is_array) {
-   if (prop->is_string && prop->pointer.str) {
-   nval = prop->length / sizeof(const char *);
-   for (i = 0; i < nval; i++)
-   kfree(prop->pointer.str[i]);
-   }
-   kfree(prop->pointer.raw_data);
-   } else if (prop->is_string) {
-   kfree(prop->value.str);
-   }
-   kfree(prop->name);
-   }
-
-   kfree(pset->properties);
-   kfree(pset);
-}
-
-static int pset_copy_entry(struct property_entry *dst,
-  const struct property_entry *src)
+static int property_entry_copy(struct property_entry *dst,
+  const struct property_entry *src)
 {
const char **d, **s;
size_t i, nval;
@@ -765,6 +732,71 @@ static int pset_copy_entry(struct property_entry *dst,
 }
 
 /**
+ * property_entries_dup - duplicate array of properties
+ * @properties: array of properties to copy
+ *
+ * This function creates a deep copy of the given NULL-terminated array
+ * of property entries.
+ */
+struct property_entry *property_entries_dup(
+   const struct property_entry *properties)
+{
+   struct property_entry *p;
+   int i, n = 0;
+
+   while (properties[n].name)
+   n++;
+
+   p = kcalloc(n + 1, sizeof(*p), GFP_KERNEL);
+   if (!p)
+   return ERR_PTR(-ENOMEM);
+
+   for (i = 0; i < n; i++) {
+   int ret = property_entry_copy([i], [i]);
+   if (ret) {
+   kfree(p);
+   return ERR_PTR(ret);
+   }
+   }
+
+   return p;
+}
+EXPORT_SYMBOL_GPL(property_entries_dup);
+
+/**
+ * pset_free_set - releases memory allocated for copied property set
+ * @pset: Property set to release
+ *
+ * Function takes previously copied property set and releases all the
+ * memory allocated to it.
+ */
+static void pset_free_set(struct property_set *pset)
+{
+   const struct property_entry *prop;
+   size_t i, nval;
+
+   if (!pset)
+   return;
+
+   for (prop = pset->properties; prop->name; prop++) {
+   if (prop->is_array) {
+   if (prop->is_string && prop->pointer.str) {
+   nval = prop->length / sizeof(const char *);
+   for (i = 0; i < nval; i++)
+   kfree(prop->pointer.str[i]);
+   }
+   kfree(prop->pointer.raw_data);
+   } else if (prop->is_string) {
+   kfree(prop->value.str);
+   }
+   kfree(prop->name);
+   }
+
+   kfree(pset->properties);
+   kfree(pset);
+}
+
+/**
  * pset_copy_set - copies property set
  * @pset: Property set to copy
  *
@@ -776,32 +808,20 @@ static int pset_copy_entry(struct property_entry *dst,
  */
 static struct property_set *pset_copy_set(const struct property_set *pset)
 {
-   const struct property_entry *entry;
+   struct property_entry *properties;
struct property_set *p;
-   size_t i, n = 0;
 
p = kzalloc(sizeof(*p), GFP_KERNEL);
if (!p)
return ERR_PTR(-ENOMEM);
 
-   while (pset->properties[n].name)
-   n++;
-
-   p->properties = kcalloc(n + 1, sizeof(*entry), GFP_KERNEL);
-   if (!p->properties) {
+   properties = property_entries_dup(pset->properties);
+   if 

[PATCH 1/2] device property: export code duplicating array of property entries

[Dmitry Torokhov]

When augmenting ACPI-enumerated devices with additional property data based
on DMI info, a module has often several potential property sets, with only
one being active on a given box. In order to save memory it should be
possible to mark everything and __initdata or __initconst, execute DMI
match early, and duplicate relevant properties. Then kernel will discard
the rest of them.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/property.c  | 124 +++
 include/linux/property.h |   3 ++
 2 files changed, 75 insertions(+), 52 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 43a36d68c3fd..ee22ded63e06 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -682,41 +682,8 @@ int fwnode_property_match_string(struct fwnode_handle 
*fwnode,
 }
 EXPORT_SYMBOL_GPL(fwnode_property_match_string);
 
-/**
- * pset_free_set - releases memory allocated for copied property set
- * @pset: Property set to release
- *
- * Function takes previously copied property set and releases all the
- * memory allocated to it.
- */
-static void pset_free_set(struct property_set *pset)
-{
-   const struct property_entry *prop;
-   size_t i, nval;
-
-   if (!pset)
-   return;
-
-   for (prop = pset->properties; prop->name; prop++) {
-   if (prop->is_array) {
-   if (prop->is_string && prop->pointer.str) {
-   nval = prop->length / sizeof(const char *);
-   for (i = 0; i < nval; i++)
-   kfree(prop->pointer.str[i]);
-   }
-   kfree(prop->pointer.raw_data);
-   } else if (prop->is_string) {
-   kfree(prop->value.str);
-   }
-   kfree(prop->name);
-   }
-
-   kfree(pset->properties);
-   kfree(pset);
-}
-
-static int pset_copy_entry(struct property_entry *dst,
-  const struct property_entry *src)
+static int property_entry_copy(struct property_entry *dst,
+  const struct property_entry *src)
 {
const char **d, **s;
size_t i, nval;
@@ -765,6 +732,71 @@ static int pset_copy_entry(struct property_entry *dst,
 }
 
 /**
+ * property_entries_dup - duplicate array of properties
+ * @properties: array of properties to copy
+ *
+ * This function creates a deep copy of the given NULL-terminated array
+ * of property entries.
+ */
+struct property_entry *property_entries_dup(
+   const struct property_entry *properties)
+{
+   struct property_entry *p;
+   int i, n = 0;
+
+   while (properties[n].name)
+   n++;
+
+   p = kcalloc(n + 1, sizeof(*p), GFP_KERNEL);
+   if (!p)
+   return ERR_PTR(-ENOMEM);
+
+   for (i = 0; i < n; i++) {
+   int ret = property_entry_copy([i], [i]);
+   if (ret) {
+   kfree(p);
+   return ERR_PTR(ret);
+   }
+   }
+
+   return p;
+}
+EXPORT_SYMBOL_GPL(property_entries_dup);
+
+/**
+ * pset_free_set - releases memory allocated for copied property set
+ * @pset: Property set to release
+ *
+ * Function takes previously copied property set and releases all the
+ * memory allocated to it.
+ */
+static void pset_free_set(struct property_set *pset)
+{
+   const struct property_entry *prop;
+   size_t i, nval;
+
+   if (!pset)
+   return;
+
+   for (prop = pset->properties; prop->name; prop++) {
+   if (prop->is_array) {
+   if (prop->is_string && prop->pointer.str) {
+   nval = prop->length / sizeof(const char *);
+   for (i = 0; i < nval; i++)
+   kfree(prop->pointer.str[i]);
+   }
+   kfree(prop->pointer.raw_data);
+   } else if (prop->is_string) {
+   kfree(prop->value.str);
+   }
+   kfree(prop->name);
+   }
+
+   kfree(pset->properties);
+   kfree(pset);
+}
+
+/**
  * pset_copy_set - copies property set
  * @pset: Property set to copy
  *
@@ -776,32 +808,20 @@ static int pset_copy_entry(struct property_entry *dst,
  */
 static struct property_set *pset_copy_set(const struct property_set *pset)
 {
-   const struct property_entry *entry;
+   struct property_entry *properties;
struct property_set *p;
-   size_t i, n = 0;
 
p = kzalloc(sizeof(*p), GFP_KERNEL);
if (!p)
return ERR_PTR(-ENOMEM);
 
-   while (pset->properties[n].name)
-   n++;
-
-   p->properties = kcalloc(n + 1, sizeof(*entry), GFP_KERNEL);
-   if (!p->properties) {
+   properties = property_entries_dup(pset->properties);
+   if (IS_ERR(properties)) {
 

Re: [PATCH v1] sound: pci: ymfpci: ymfpci_main:- Handle return NULL error from ioremap_nocache

[Arvind Yadav]

I will take care your comments.

Thanks
-Arvind

On Monday 23 January 2017 12:54 PM, Julia Lawall wrote:

or general cleanup patches
like this one, you can use the following options, that will just send the
patch to the maintainers, and not to everyone who has ever touched the

Re: [PATCH v1] sound: pci: ymfpci: ymfpci_main:- Handle return NULL error from ioremap_nocache

[Arvind Yadav]

I will take care your comments.

Thanks
-Arvind

On Monday 23 January 2017 12:54 PM, Julia Lawall wrote:

or general cleanup patches
like this one, you can use the following options, that will just send the
patch to the maintainers, and not to everyone who has ever touched the

Re: [PATCH] ARM: dts: vf610-zii-dev: add EEPROM entry to Rev C

[Shawn Guo]

On Thu, Jan 12, 2017 at 06:06:20PM -0500, Vivien Didelot wrote:
> The ZII Dev Rev C board has EEPROMs hanging the 88E6390 Ethernet switch
> chips. Add an "eeprom-length" property to allow access from ethtool.
> 
> Signed-off-by: Vivien Didelot 

Applied, thanks.

Re: [PATCH] seccomp: dump core when using SECCOMP_RET_KILL

[Mike Frysinger]

On Sun, Jan 22, 2017 at 4:10 PM, James Morris wrote:
> On Fri, 20 Jan 2017, Kees Cook wrote:
> > Yup, I think this is fine. The additional kernel code executed before
> > the do_exit() is relatively limited, and is equivalent to leaving
> > kill(self, SIGSEGV) exposed in a seccomp filter. Setting an RLIMIT is
> > also sufficient to block the core generation, so really paranoid
> > environments can still do that.
> >
> > The forwarded ack stands:
> >
> > Acked-by: Kees Cook 
> >
> > James, can you add this to your tree?
>
> Mike, please resend the patch, I don't have it.

looks like patchwork grabbed it:
  https://patchwork.kernel.org/patch/9527359/

has a mbox link which should get you what you need ?
-mike

Re: [PATCH] ARM: dts: vf610-zii-dev: add EEPROM entry to Rev C

[Shawn Guo]

On Thu, Jan 12, 2017 at 06:06:20PM -0500, Vivien Didelot wrote:
> The ZII Dev Rev C board has EEPROMs hanging the 88E6390 Ethernet switch
> chips. Add an "eeprom-length" property to allow access from ethtool.
> 
> Signed-off-by: Vivien Didelot 

Applied, thanks.

Re: [PATCH] seccomp: dump core when using SECCOMP_RET_KILL

[Mike Frysinger]

On Sun, Jan 22, 2017 at 4:10 PM, James Morris wrote:
> On Fri, 20 Jan 2017, Kees Cook wrote:
> > Yup, I think this is fine. The additional kernel code executed before
> > the do_exit() is relatively limited, and is equivalent to leaving
> > kill(self, SIGSEGV) exposed in a seccomp filter. Setting an RLIMIT is
> > also sufficient to block the core generation, so really paranoid
> > environments can still do that.
> >
> > The forwarded ack stands:
> >
> > Acked-by: Kees Cook 
> >
> > James, can you add this to your tree?
>
> Mike, please resend the patch, I don't have it.

looks like patchwork grabbed it:
  https://patchwork.kernel.org/patch/9527359/

has a mbox link which should get you what you need ?
-mike

Re: [PATCH linux-next 1/1] usb: gadget: udc: atmel: Update endpoint allocation scheme

[Ludovic Desroches]

Hi Cristian,

Minor comments about syntax otherwise
Reviewed-by: Ludovic Desroches 

On Fri, Jan 20, 2017 at 05:40:59PM +0200, cristian.bir...@microchip.com wrote:
> From: Cristian Birsan 
> 
> Update atmel udc driver with a new enpoint allocation scheme. The data
> sheet requires that all endpoints are allocated in order.
> 
> Signed-off-by: Cristian Birsan 
> ---
>  drivers/usb/gadget/udc/Kconfig  |  14 ++
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 236 
> +++-
>  drivers/usb/gadget/udc/atmel_usba_udc.h |  10 +-
>  3 files changed, 227 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
> index 658b8da..4b69f28 100644
> --- a/drivers/usb/gadget/udc/Kconfig
> +++ b/drivers/usb/gadget/udc/Kconfig
> @@ -60,6 +60,20 @@ config USB_ATMEL_USBA
> USBA is the integrated high-speed USB Device controller on
> the AT32AP700x, some AT91SAM9 and AT91CAP9 processors from Atmel.
>  
> +   The fifo_mode parameter is used to select endpoint allocation mode.
> +   fifo_mode = 0 is used to let the driver autoconfigure the endpoints.
> +   In this case 2 banks are allocated for isochronous endpoints and
> +   only one bank is allocated for the rest of the endpoints.
> +
> +   fifo_mode = 1 is a generic maximum fifo size (1024 bytes) 
> configuration
> +   allowing the usage of ep1 - ep6
> +
> +   fifo_mode = 2 is a generic performance maximum fifo size (1024 bytes)
> +   configuration allowing the usage of ep1 - ep3
> +
> +   fifo_mode = 3 is a balanced performance configuration allowing the
> +   the usage of ep1 - ep8
> +
>  config USB_BCM63XX_UDC
>   tristate "Broadcom BCM63xx Peripheral Controller"
>   depends on BCM63XX
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 12c7687..3417bb9 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -318,6 +319,91 @@ static inline void usba_cleanup_debugfs(struct usba_udc 
> *udc)
>  }
>  #endif
>  
> +static ushort fifo_mode;
> +
> +/* "modprobe ... fifo_mode=1" etc */
> +module_param(fifo_mode, ushort, 0x0);
> +MODULE_PARM_DESC(fifo_mode, "Endpoint configuration mode");
> +
> +/* mode 0 - uses autoconfig */
> +
> +/* mode 1 - fits in 8KB, generic max fifo configuration */
> +static struct usba_fifo_cfg mode_1_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 1024, .nr_banks = 2, },
> +{ .hw_ep_num = 2, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 3, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 4, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 5, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 6, .fifo_size = 1024, .nr_banks = 1, },
> +};
> +
> +/* mode 2 - fits in 8KB, performance max fifo configuration */
> +static struct usba_fifo_cfg mode_2_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 1024, .nr_banks = 3, },
> +{ .hw_ep_num = 2, .fifo_size = 1024, .nr_banks = 2, },
> +{ .hw_ep_num = 3, .fifo_size = 1024, .nr_banks = 2, },
> +};
> +
> +/* mode 3 - fits in 8KB, mixed fifo configuration */
> +static struct usba_fifo_cfg mode_3_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 1024, .nr_banks = 2, },
> +{ .hw_ep_num = 2, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 3, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 4, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 5, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 6, .fifo_size = 512,  .nr_banks = 2, },
> +};
> +
> +/* mode 4 - fits in 8KB, custom fifo configuration */
> +static struct usba_fifo_cfg mode_4_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 2, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 3, .fifo_size = 8,.nr_banks = 2, },
> +{ .hw_ep_num = 4, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 5, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 6, .fifo_size = 16,   .nr_banks = 2, },
> +{ .hw_ep_num = 7, .fifo_size = 8,.nr_banks = 2, },
> +{ .hw_ep_num = 8, .fifo_size = 8,.nr_banks = 2, },
> +};
> +/* Add additional configurations here */
> +
> +int usba_config_fifo_table(struct usba_udc *udc)
> +{
> + int n;
> +
> + switch (fifo_mode) {
> + default:
> + fifo_mode = 0;
> + case 0:
> + udc->fifo_cfg = NULL;
> + n = 0;
> + break;
> + case 1:
> + udc->fifo_cfg = mode_1_cfg;
> + n = ARRAY_SIZE(mode_1_cfg);
> + 

[PATCH v2] ALSA: ymfpci: Handle return NULL error from ioremap_nocache

[Arvind Yadav]

Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.

Signed-off-by: Arvind Yadav 
---
 sound/pci/ymfpci/ymfpci_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c
index ffee284..8590c3f 100644
--- a/sound/pci/ymfpci/ymfpci_main.c
+++ b/sound/pci/ymfpci/ymfpci_main.c
@@ -2392,6 +2392,10 @@ int snd_ymfpci_create(struct snd_card *card,
chip->rev = pci->revision;
chip->reg_area_phys = pci_resource_start(pci, 0);
chip->reg_area_virt = ioremap_nocache(chip->reg_area_phys, 0x8000);
+   if (!chip->reg_area_virt) {
+   pci_disable_device(pci);
+   return -ENOMEM;
+   }
pci_set_master(pci);
chip->src441_used = -1;
 
-- 
1.9.1

Re: [PATCH linux-next 1/1] usb: gadget: udc: atmel: Update endpoint allocation scheme

[Ludovic Desroches]

Hi Cristian,

Minor comments about syntax otherwise
Reviewed-by: Ludovic Desroches 

On Fri, Jan 20, 2017 at 05:40:59PM +0200, cristian.bir...@microchip.com wrote:
> From: Cristian Birsan 
> 
> Update atmel udc driver with a new enpoint allocation scheme. The data
> sheet requires that all endpoints are allocated in order.
> 
> Signed-off-by: Cristian Birsan 
> ---
>  drivers/usb/gadget/udc/Kconfig  |  14 ++
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 236 
> +++-
>  drivers/usb/gadget/udc/atmel_usba_udc.h |  10 +-
>  3 files changed, 227 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
> index 658b8da..4b69f28 100644
> --- a/drivers/usb/gadget/udc/Kconfig
> +++ b/drivers/usb/gadget/udc/Kconfig
> @@ -60,6 +60,20 @@ config USB_ATMEL_USBA
> USBA is the integrated high-speed USB Device controller on
> the AT32AP700x, some AT91SAM9 and AT91CAP9 processors from Atmel.
>  
> +   The fifo_mode parameter is used to select endpoint allocation mode.
> +   fifo_mode = 0 is used to let the driver autoconfigure the endpoints.
> +   In this case 2 banks are allocated for isochronous endpoints and
> +   only one bank is allocated for the rest of the endpoints.
> +
> +   fifo_mode = 1 is a generic maximum fifo size (1024 bytes) 
> configuration
> +   allowing the usage of ep1 - ep6
> +
> +   fifo_mode = 2 is a generic performance maximum fifo size (1024 bytes)
> +   configuration allowing the usage of ep1 - ep3
> +
> +   fifo_mode = 3 is a balanced performance configuration allowing the
> +   the usage of ep1 - ep8
> +
>  config USB_BCM63XX_UDC
>   tristate "Broadcom BCM63xx Peripheral Controller"
>   depends on BCM63XX
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 12c7687..3417bb9 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -318,6 +319,91 @@ static inline void usba_cleanup_debugfs(struct usba_udc 
> *udc)
>  }
>  #endif
>  
> +static ushort fifo_mode;
> +
> +/* "modprobe ... fifo_mode=1" etc */
> +module_param(fifo_mode, ushort, 0x0);
> +MODULE_PARM_DESC(fifo_mode, "Endpoint configuration mode");
> +
> +/* mode 0 - uses autoconfig */
> +
> +/* mode 1 - fits in 8KB, generic max fifo configuration */
> +static struct usba_fifo_cfg mode_1_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 1024, .nr_banks = 2, },
> +{ .hw_ep_num = 2, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 3, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 4, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 5, .fifo_size = 1024, .nr_banks = 1, },
> +{ .hw_ep_num = 6, .fifo_size = 1024, .nr_banks = 1, },
> +};
> +
> +/* mode 2 - fits in 8KB, performance max fifo configuration */
> +static struct usba_fifo_cfg mode_2_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 1024, .nr_banks = 3, },
> +{ .hw_ep_num = 2, .fifo_size = 1024, .nr_banks = 2, },
> +{ .hw_ep_num = 3, .fifo_size = 1024, .nr_banks = 2, },
> +};
> +
> +/* mode 3 - fits in 8KB, mixed fifo configuration */
> +static struct usba_fifo_cfg mode_3_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 1024, .nr_banks = 2, },
> +{ .hw_ep_num = 2, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 3, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 4, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 5, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 6, .fifo_size = 512,  .nr_banks = 2, },
> +};
> +
> +/* mode 4 - fits in 8KB, custom fifo configuration */
> +static struct usba_fifo_cfg mode_4_cfg[] = {
> +{ .hw_ep_num = 0, .fifo_size = 64,   .nr_banks = 1, },
> +{ .hw_ep_num = 1, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 2, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 3, .fifo_size = 8,.nr_banks = 2, },
> +{ .hw_ep_num = 4, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 5, .fifo_size = 512,  .nr_banks = 2, },
> +{ .hw_ep_num = 6, .fifo_size = 16,   .nr_banks = 2, },
> +{ .hw_ep_num = 7, .fifo_size = 8,.nr_banks = 2, },
> +{ .hw_ep_num = 8, .fifo_size = 8,.nr_banks = 2, },
> +};
> +/* Add additional configurations here */
> +
> +int usba_config_fifo_table(struct usba_udc *udc)
> +{
> + int n;
> +
> + switch (fifo_mode) {
> + default:
> + fifo_mode = 0;
> + case 0:
> + udc->fifo_cfg = NULL;
> + n = 0;
> + break;
> + case 1:
> + udc->fifo_cfg = mode_1_cfg;
> + n = ARRAY_SIZE(mode_1_cfg);
> + break;
> + case 2:
> + udc->fifo_cfg = mode_2_cfg;
> + 

[PATCH v2] ALSA: ymfpci: Handle return NULL error from ioremap_nocache

[Arvind Yadav]

Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.

Signed-off-by: Arvind Yadav 
---
 sound/pci/ymfpci/ymfpci_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c
index ffee284..8590c3f 100644
--- a/sound/pci/ymfpci/ymfpci_main.c
+++ b/sound/pci/ymfpci/ymfpci_main.c
@@ -2392,6 +2392,10 @@ int snd_ymfpci_create(struct snd_card *card,
chip->rev = pci->revision;
chip->reg_area_phys = pci_resource_start(pci, 0);
chip->reg_area_virt = ioremap_nocache(chip->reg_area_phys, 0x8000);
+   if (!chip->reg_area_virt) {
+   pci_disable_device(pci);
+   return -ENOMEM;
+   }
pci_set_master(pci);
chip->src441_used = -1;
 
-- 
1.9.1

[PATCH v9 2/2] tpm: add securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

Unlike the device driver support for TPM 1.2, the TPM 2.0 does
not support the securityfs pseudo files for displaying the
firmware event log.

This patch enables support for providing the TPM 2.0 event log in
binary form. TPM 2.0 event log supports a crypto agile format that
records multiple digests, which is different from TPM 1.2. This
patch enables the tpm_bios_log_setup for TPM 2.0  and adds the
event log parser which understand the TPM 2.0 crypto agile format.

Signed-off-by: Nayna Jain 
---
 drivers/char/tpm/Makefile  |   2 +-
 .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c}   |  35 ++--
 drivers/char/tpm/tpm2_eventlog.c   | 203 +
 drivers/char/tpm/tpm_acpi.c|   3 +
 drivers/char/tpm/tpm_eventlog.h|  59 ++
 5 files changed, 287 insertions(+), 15 deletions(-)
 rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
 create mode 100644 drivers/char/tpm/tpm2_eventlog.c

diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a05b1eb..3d386a8 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -3,7 +3,7 @@
 #
 obj-$(CONFIG_TCG_TPM) += tpm.o
 tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o tpm-chip.o tpm2-cmd.o \
-   tpm_eventlog.o
+   tpm1_eventlog.o tpm2_eventlog.o
 tpm-$(CONFIG_ACPI) += tpm_ppi.o tpm_acpi.o
 tpm-$(CONFIG_OF) += tpm_of.o
 obj-$(CONFIG_TCG_TIS_CORE) += tpm_tis_core.o
diff --git a/drivers/char/tpm/tpm_eventlog.c b/drivers/char/tpm/tpm1_eventlog.c
similarity index 95%
rename from drivers/char/tpm/tpm_eventlog.c
rename to drivers/char/tpm/tpm1_eventlog.c
index 11bb113..9a8605e 100644
--- a/drivers/char/tpm/tpm_eventlog.c
+++ b/drivers/char/tpm/tpm1_eventlog.c
@@ -390,9 +390,6 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
unsigned int cnt;
int rc = 0;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   return 0;
-
rc = tpm_read_log(chip);
if (rc)
return rc;
@@ -407,7 +404,13 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
cnt++;
 
chip->bin_log_seqops.chip = chip;
-   chip->bin_log_seqops.seqops = _binary_b_measurements_seqops;
+   if (chip->flags & TPM_CHIP_FLAG_TPM2)
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+   else
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+
 
chip->bios_dir[cnt] =
securityfs_create_file("binary_bios_measurements",
@@ -418,17 +421,21 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
goto err;
cnt++;
 
-   chip->ascii_log_seqops.chip = chip;
-   chip->ascii_log_seqops.seqops = _ascii_b_measurements_seqops;
+   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
 
-   chip->bios_dir[cnt] =
-   securityfs_create_file("ascii_bios_measurements",
-  0440, chip->bios_dir[0],
-  (void *)>ascii_log_seqops,
-  _bios_measurements_ops);
-   if (IS_ERR(chip->bios_dir[cnt]))
-   goto err;
-   cnt++;
+   chip->ascii_log_seqops.chip = chip;
+   chip->ascii_log_seqops.seqops =
+   _ascii_b_measurements_seqops;
+
+   chip->bios_dir[cnt] =
+   securityfs_create_file("ascii_bios_measurements",
+  0440, chip->bios_dir[0],
+  (void *)>ascii_log_seqops,
+  _bios_measurements_ops);
+   if (IS_ERR(chip->bios_dir[cnt]))
+   goto err;
+   cnt++;
+   }
 
return 0;
 
diff --git a/drivers/char/tpm/tpm2_eventlog.c b/drivers/char/tpm/tpm2_eventlog.c
new file mode 100644
index 000..513897c
--- /dev/null
+++ b/drivers/char/tpm/tpm2_eventlog.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2016 IBM Corporation
+ *
+ * Authors:
+ *  Nayna Jain 
+ *
+ * Access to TPM 2.0 event log as written by Firmware.
+ * It assumes that writer of event log has followed TCG Specification
+ * for Family "2.0" and written the event data in little endian.
+ * With that, it doesn't need any endian conversion for structure
+ * content.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tpm.h"
+#include "tpm_eventlog.h"
+
+/*
+ * calc_tpm2_event_size() - calculate the event size, where event
+ * is an entry in the TPM 2.0 event log. The event is of type Crypto
+ * Agile Log Entry 

[PATCH v9 2/2] tpm: add securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

Unlike the device driver support for TPM 1.2, the TPM 2.0 does
not support the securityfs pseudo files for displaying the
firmware event log.

This patch enables support for providing the TPM 2.0 event log in
binary form. TPM 2.0 event log supports a crypto agile format that
records multiple digests, which is different from TPM 1.2. This
patch enables the tpm_bios_log_setup for TPM 2.0  and adds the
event log parser which understand the TPM 2.0 crypto agile format.

Signed-off-by: Nayna Jain 
---
 drivers/char/tpm/Makefile  |   2 +-
 .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c}   |  35 ++--
 drivers/char/tpm/tpm2_eventlog.c   | 203 +
 drivers/char/tpm/tpm_acpi.c|   3 +
 drivers/char/tpm/tpm_eventlog.h|  59 ++
 5 files changed, 287 insertions(+), 15 deletions(-)
 rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
 create mode 100644 drivers/char/tpm/tpm2_eventlog.c

diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a05b1eb..3d386a8 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -3,7 +3,7 @@
 #
 obj-$(CONFIG_TCG_TPM) += tpm.o
 tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o tpm-chip.o tpm2-cmd.o \
-   tpm_eventlog.o
+   tpm1_eventlog.o tpm2_eventlog.o
 tpm-$(CONFIG_ACPI) += tpm_ppi.o tpm_acpi.o
 tpm-$(CONFIG_OF) += tpm_of.o
 obj-$(CONFIG_TCG_TIS_CORE) += tpm_tis_core.o
diff --git a/drivers/char/tpm/tpm_eventlog.c b/drivers/char/tpm/tpm1_eventlog.c
similarity index 95%
rename from drivers/char/tpm/tpm_eventlog.c
rename to drivers/char/tpm/tpm1_eventlog.c
index 11bb113..9a8605e 100644
--- a/drivers/char/tpm/tpm_eventlog.c
+++ b/drivers/char/tpm/tpm1_eventlog.c
@@ -390,9 +390,6 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
unsigned int cnt;
int rc = 0;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   return 0;
-
rc = tpm_read_log(chip);
if (rc)
return rc;
@@ -407,7 +404,13 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
cnt++;
 
chip->bin_log_seqops.chip = chip;
-   chip->bin_log_seqops.seqops = _binary_b_measurements_seqops;
+   if (chip->flags & TPM_CHIP_FLAG_TPM2)
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+   else
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+
 
chip->bios_dir[cnt] =
securityfs_create_file("binary_bios_measurements",
@@ -418,17 +421,21 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
goto err;
cnt++;
 
-   chip->ascii_log_seqops.chip = chip;
-   chip->ascii_log_seqops.seqops = _ascii_b_measurements_seqops;
+   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
 
-   chip->bios_dir[cnt] =
-   securityfs_create_file("ascii_bios_measurements",
-  0440, chip->bios_dir[0],
-  (void *)>ascii_log_seqops,
-  _bios_measurements_ops);
-   if (IS_ERR(chip->bios_dir[cnt]))
-   goto err;
-   cnt++;
+   chip->ascii_log_seqops.chip = chip;
+   chip->ascii_log_seqops.seqops =
+   _ascii_b_measurements_seqops;
+
+   chip->bios_dir[cnt] =
+   securityfs_create_file("ascii_bios_measurements",
+  0440, chip->bios_dir[0],
+  (void *)>ascii_log_seqops,
+  _bios_measurements_ops);
+   if (IS_ERR(chip->bios_dir[cnt]))
+   goto err;
+   cnt++;
+   }
 
return 0;
 
diff --git a/drivers/char/tpm/tpm2_eventlog.c b/drivers/char/tpm/tpm2_eventlog.c
new file mode 100644
index 000..513897c
--- /dev/null
+++ b/drivers/char/tpm/tpm2_eventlog.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2016 IBM Corporation
+ *
+ * Authors:
+ *  Nayna Jain 
+ *
+ * Access to TPM 2.0 event log as written by Firmware.
+ * It assumes that writer of event log has followed TCG Specification
+ * for Family "2.0" and written the event data in little endian.
+ * With that, it doesn't need any endian conversion for structure
+ * content.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tpm.h"
+#include "tpm_eventlog.h"
+
+/*
+ * calc_tpm2_event_size() - calculate the event size, where event
+ * is an entry in the TPM 2.0 event log. The event is of type Crypto
+ * Agile Log Entry Format as defined in TCG EFI Protocol Specification
+ 

[PATCH v9 0/2] securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

The TPM device driver defines ascii and binary methods for
displaying the TPM 1.2 event log via securityfs files, which are
needed for validating a TPM quote. The device driver for TPM 2.0
does not have similar support for displaying the TPM 2.0
event log. This patch set adds the support for displaying
TPM 2.0 event log in binary format.

The parsing mechanism to display the TPM 2.0 event log in binary
format is implemented as defined in the TPM 2.0 TCG specification[1].
If the firmware event log support exists and is successfully read,
the securityfs file is created to provide the event log in binary
format for both the OF device tree and ACPI.

   - Patch 1 adds the device tree bindings support for Physical TPM.
   - Patch 2 adds the support for creating securityfs files and for
 displaying the TPM 2.0 crypto agile event log in binary format.

[1] TCG EFI Protocol Specification, Family "2.0" - Section 5 "Event
Log Structure"

Changelog History

v9:
- Rebased to the Jarkko's latest master branch (9b7f425 tpm: Check size of 
  response before accessing data)
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log" 
  - Renamed struct tpmt_ha to struct tpm2_hash.
  - Removed struct tpml_digest_values.

v8:
- Rebased to the Jarkko's latest master branch (8e25809 tpm:
  Do not print an error message when doing TPM auto startup)
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log" 
  - Added feedbacks from Jarkko
- tpm_read_log_acpi() returns -ENODEV for TPM 2.0.
- Fixed code formatting and comments.

v7:
- Rebased to the Jarkko's latest master branch (b2505f6 tpm/vtpm:
  fix kdoc warnings)
- Included Jarkko's feedbacks on version v6.
- Cleaned up #defines in tpm2_eventlog.c
  - renamed HASH_COUNT to TPM2_ACTIVE_PCR_BANKS
  - deleted MAX_DIGEST_SIZE, used SHA384_DIGEST_SIZE directly from 
  
  - deleted MAX_TPM_LOG_MSG. Redefined event[MAX_TPM_LOG_MSG]
  as event[0].

v6:

- Rebased to the Jarkko's latest master branch (e717b5c:tpm: vtpm_proxy: 
  conditionally call tpm_chip_unregister)
- Retained securityfs setup functions in tpm_eventlog.c
- Renamed tpm_eventlog.c to tpm1_eventlog.c
- Fixed tpm_read_log_of() for NULL check and memcpy function.

v5:

- Upstreamed cleanup and fixes as different patchset
- Rebased to the Jarkko's latest master branch (e5be084 tpm: vtpm_proxy:
  Do not access host's event log)
- Patch "tpm: enhance read_log_of() to support Physical TPM event log
  - New Patch.
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log"
  - Moved the changes in read_log_of() to a different patch
  - TPM 2.0 event log data types are declared in tpm_eventlog.h, tpm2.h
  is removed.
  - Included other feedbacks also from Jarkko on aligment and extra
line

v4:

- Includes feedbacks from Jarkko and Jason.
- Patch "tpm: define a generic open() method for ascii & bios
measurements".
  - Fix indentation issue.
- Patch "tpm: replace the dynamically allocated bios_dir as
  struct dentry array".
  - Continue to use bios_dir_count variable to use is_bad() checks and
to maintain correct order for securityfs_remove() during teardown.
  - Reset chip->bios_dir_count in teardown() function.
- Patch "tpm: validate the eventlog access before tpm_bios_log_setup".
  - Retain TPM2 check which was removed in previous patch.
  - Add tpm_bios_log_setup failure handling.
  - Remove use of private data from v3 version of patch. Add a
  new member to struct tpm_chip to achieve the same purpose.
- Patch "tpm: redefine the read_log method to check for ACPI/OF 
properties sequentially".
  - Move replacement of CONFIG_TCG_IBMVTPM with CONFIG_OF to this
patch from patch 3.
  - Replace -1 error code with -ENODEV.
- Patch "tpm: replace the of_find_node_by_name() with dev of_node
property".
  - Uses chip->dev.parent->of_node.
  - Created separate patch for cleanup of pr_err messages.
- Patch "tpm: remove printk error messages".
  - New Patch.
- Patch "tpm: add the securityfs file support for TPM 2.0 eventlog".
  - Parses event digests using event alg_id rather than event log header
alg_id.
  - Uses of_property_match_string to differentiate tpm/vtpm compatible

v3:

- Includes the review feedbacks as suggested by Jason.
- Split of patches into one patch per idea.
- Generic open() method for ascii/bios measurements.
- Replacement of of **bios_dir with *bios_dir[3].
- Verifying readlog() is successful before creating securityfs entries.
- Generic readlog() to check for ACPI/OF in sequence.
- read_log_of() method now uses of_node propertry rather than
calling find_device_by_name.
- read_log differentiates vtpm/tpm using its compatible property.
- Cleans pr_err with dev_dbg.
- Commit msgs subject line prefixed with tpm.

v2:

- Fixes issues as given in feedback by Jason.
- Adds documentation for device tree.

Nayna Jain (2):
  tpm: enhance read_log_of() to support Physical TPM event log
  tpm: add securityfs support for TPM 2.0 firmware event log

 

[PATCH v9 1/2] tpm: enhance read_log_of() to support Physical TPM event log

[Nayna Jain]

Physical TPMs use Open Firmware Device Tree bindings that are similar
to the IBM Power virtual TPM to support event log. However, these
properties store the values in different endianness for Physical
and Virtual TPM.

This patch fixes the endianness issue by doing appropriate conversion
based on Physical or Virtual TPM.

Signed-off-by: Nayna Jain 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_of.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 7dee42d7..de57d4a 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -27,6 +27,8 @@ int tpm_read_log_of(struct tpm_chip *chip)
const u32 *sizep;
const u64 *basep;
struct tpm_bios_log *log;
+   u32 size;
+   u64 base;
 
log = >log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -41,18 +43,35 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (sizep == NULL || basep == NULL)
return -EIO;
 
-   if (*sizep == 0) {
+   /*
+* For both vtpm/tpm, firmware has log addr and log size in big
+* endian format. But in case of vtpm, there is a method called
+* sml-handover which is run during kernel init even before
+* device tree is setup. This sml-handover function takes care
+* of endianness and writes to sml-base and sml-size in little
+* endian format. For this reason, vtpm doesn't need conversion
+* but physical tpm needs the conversion.
+*/
+   if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0) {
+   size = be32_to_cpup(sizep);
+   base = be64_to_cpup(basep);
+   } else {
+   size = *sizep;
+   base = *basep;
+   }
+
+   if (size == 0) {
dev_warn(>dev, "%s: Event log area empty\n", __func__);
return -EIO;
}
 
-   log->bios_event_log = kmalloc(*sizep, GFP_KERNEL);
+   log->bios_event_log = kmalloc(size, GFP_KERNEL);
if (!log->bios_event_log)
return -ENOMEM;
 
-   log->bios_event_log_end = log->bios_event_log + *sizep;
+   log->bios_event_log_end = log->bios_event_log + size;
 
-   memcpy(log->bios_event_log, __va(*basep), *sizep);
+   memcpy(log->bios_event_log, __va(base), size);
 
return 0;
 }
-- 
2.5.0

[PATCH v9 0/2] securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

The TPM device driver defines ascii and binary methods for
displaying the TPM 1.2 event log via securityfs files, which are
needed for validating a TPM quote. The device driver for TPM 2.0
does not have similar support for displaying the TPM 2.0
event log. This patch set adds the support for displaying
TPM 2.0 event log in binary format.

The parsing mechanism to display the TPM 2.0 event log in binary
format is implemented as defined in the TPM 2.0 TCG specification[1].
If the firmware event log support exists and is successfully read,
the securityfs file is created to provide the event log in binary
format for both the OF device tree and ACPI.

   - Patch 1 adds the device tree bindings support for Physical TPM.
   - Patch 2 adds the support for creating securityfs files and for
 displaying the TPM 2.0 crypto agile event log in binary format.

[1] TCG EFI Protocol Specification, Family "2.0" - Section 5 "Event
Log Structure"

Changelog History

v9:
- Rebased to the Jarkko's latest master branch (9b7f425 tpm: Check size of 
  response before accessing data)
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log" 
  - Renamed struct tpmt_ha to struct tpm2_hash.
  - Removed struct tpml_digest_values.

v8:
- Rebased to the Jarkko's latest master branch (8e25809 tpm:
  Do not print an error message when doing TPM auto startup)
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log" 
  - Added feedbacks from Jarkko
- tpm_read_log_acpi() returns -ENODEV for TPM 2.0.
- Fixed code formatting and comments.

v7:
- Rebased to the Jarkko's latest master branch (b2505f6 tpm/vtpm:
  fix kdoc warnings)
- Included Jarkko's feedbacks on version v6.
- Cleaned up #defines in tpm2_eventlog.c
  - renamed HASH_COUNT to TPM2_ACTIVE_PCR_BANKS
  - deleted MAX_DIGEST_SIZE, used SHA384_DIGEST_SIZE directly from 
  
  - deleted MAX_TPM_LOG_MSG. Redefined event[MAX_TPM_LOG_MSG]
  as event[0].

v6:

- Rebased to the Jarkko's latest master branch (e717b5c:tpm: vtpm_proxy: 
  conditionally call tpm_chip_unregister)
- Retained securityfs setup functions in tpm_eventlog.c
- Renamed tpm_eventlog.c to tpm1_eventlog.c
- Fixed tpm_read_log_of() for NULL check and memcpy function.

v5:

- Upstreamed cleanup and fixes as different patchset
- Rebased to the Jarkko's latest master branch (e5be084 tpm: vtpm_proxy:
  Do not access host's event log)
- Patch "tpm: enhance read_log_of() to support Physical TPM event log
  - New Patch.
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log"
  - Moved the changes in read_log_of() to a different patch
  - TPM 2.0 event log data types are declared in tpm_eventlog.h, tpm2.h
  is removed.
  - Included other feedbacks also from Jarkko on aligment and extra
line

v4:

- Includes feedbacks from Jarkko and Jason.
- Patch "tpm: define a generic open() method for ascii & bios
measurements".
  - Fix indentation issue.
- Patch "tpm: replace the dynamically allocated bios_dir as
  struct dentry array".
  - Continue to use bios_dir_count variable to use is_bad() checks and
to maintain correct order for securityfs_remove() during teardown.
  - Reset chip->bios_dir_count in teardown() function.
- Patch "tpm: validate the eventlog access before tpm_bios_log_setup".
  - Retain TPM2 check which was removed in previous patch.
  - Add tpm_bios_log_setup failure handling.
  - Remove use of private data from v3 version of patch. Add a
  new member to struct tpm_chip to achieve the same purpose.
- Patch "tpm: redefine the read_log method to check for ACPI/OF 
properties sequentially".
  - Move replacement of CONFIG_TCG_IBMVTPM with CONFIG_OF to this
patch from patch 3.
  - Replace -1 error code with -ENODEV.
- Patch "tpm: replace the of_find_node_by_name() with dev of_node
property".
  - Uses chip->dev.parent->of_node.
  - Created separate patch for cleanup of pr_err messages.
- Patch "tpm: remove printk error messages".
  - New Patch.
- Patch "tpm: add the securityfs file support for TPM 2.0 eventlog".
  - Parses event digests using event alg_id rather than event log header
alg_id.
  - Uses of_property_match_string to differentiate tpm/vtpm compatible

v3:

- Includes the review feedbacks as suggested by Jason.
- Split of patches into one patch per idea.
- Generic open() method for ascii/bios measurements.
- Replacement of of **bios_dir with *bios_dir[3].
- Verifying readlog() is successful before creating securityfs entries.
- Generic readlog() to check for ACPI/OF in sequence.
- read_log_of() method now uses of_node propertry rather than
calling find_device_by_name.
- read_log differentiates vtpm/tpm using its compatible property.
- Cleans pr_err with dev_dbg.
- Commit msgs subject line prefixed with tpm.

v2:

- Fixes issues as given in feedback by Jason.
- Adds documentation for device tree.

Nayna Jain (2):
  tpm: enhance read_log_of() to support Physical TPM event log
  tpm: add securityfs support for TPM 2.0 firmware event log

 

[PATCH v9 1/2] tpm: enhance read_log_of() to support Physical TPM event log

[Nayna Jain]

Physical TPMs use Open Firmware Device Tree bindings that are similar
to the IBM Power virtual TPM to support event log. However, these
properties store the values in different endianness for Physical
and Virtual TPM.

This patch fixes the endianness issue by doing appropriate conversion
based on Physical or Virtual TPM.

Signed-off-by: Nayna Jain 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_of.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 7dee42d7..de57d4a 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -27,6 +27,8 @@ int tpm_read_log_of(struct tpm_chip *chip)
const u32 *sizep;
const u64 *basep;
struct tpm_bios_log *log;
+   u32 size;
+   u64 base;
 
log = >log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -41,18 +43,35 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (sizep == NULL || basep == NULL)
return -EIO;
 
-   if (*sizep == 0) {
+   /*
+* For both vtpm/tpm, firmware has log addr and log size in big
+* endian format. But in case of vtpm, there is a method called
+* sml-handover which is run during kernel init even before
+* device tree is setup. This sml-handover function takes care
+* of endianness and writes to sml-base and sml-size in little
+* endian format. For this reason, vtpm doesn't need conversion
+* but physical tpm needs the conversion.
+*/
+   if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0) {
+   size = be32_to_cpup(sizep);
+   base = be64_to_cpup(basep);
+   } else {
+   size = *sizep;
+   base = *basep;
+   }
+
+   if (size == 0) {
dev_warn(>dev, "%s: Event log area empty\n", __func__);
return -EIO;
}
 
-   log->bios_event_log = kmalloc(*sizep, GFP_KERNEL);
+   log->bios_event_log = kmalloc(size, GFP_KERNEL);
if (!log->bios_event_log)
return -ENOMEM;
 
-   log->bios_event_log_end = log->bios_event_log + *sizep;
+   log->bios_event_log_end = log->bios_event_log + size;
 
-   memcpy(log->bios_event_log, __va(*basep), *sizep);
+   memcpy(log->bios_event_log, __va(base), size);
 
return 0;
 }
-- 
2.5.0

Re: [PATCH v1] sound: pci: ymfpci: ymfpci_main:- Handle return NULL error from ioremap_nocache

[Julia Lawall]

Some comments on the patch header:

* No need to put v1 on a patch.  If you are asked to revise it, then you
can start with v2.

* sound: pci: ymfpci: ymfpci_main is not the proper subject line for this
file.  Do git log --oneline and see what others have done.

* There should not be a - after the final colon in the subject line.

* I'm not sure why I was included in this patch.  get_maintainers by
default gives the names of a lot of people.  For general cleanup patches
like this one, you can use the following options, that will just send the
patch to the maintainers, and not to everyone who has ever touched the
file:

scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback --norolestats

julia

On Mon, 23 Jan 2017, Arvind Yadav wrote:

> Here, If ioremap_nocache will fail. It will return NULL.
> Kernel can run into a NULL-pointer dereference.
> This error check will avoid NULL pointer dereference.
>
> Signed-off-by: Arvind Yadav 
> ---
>  sound/pci/ymfpci/ymfpci_main.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c
> index ffee284..8590c3f 100644
> --- a/sound/pci/ymfpci/ymfpci_main.c
> +++ b/sound/pci/ymfpci/ymfpci_main.c
> @@ -2392,6 +2392,10 @@ int snd_ymfpci_create(struct snd_card *card,
>   chip->rev = pci->revision;
>   chip->reg_area_phys = pci_resource_start(pci, 0);
>   chip->reg_area_virt = ioremap_nocache(chip->reg_area_phys, 0x8000);
> + if (!chip->reg_area_virt) {
> + pci_disable_device(pci);
> + return -ENOMEM;
> + }
>   pci_set_master(pci);
>   chip->src441_used = -1;
>
> --
> 1.9.1
>
>

Re: [PATCH v1] sound: pci: ymfpci: ymfpci_main:- Handle return NULL error from ioremap_nocache

[Julia Lawall]

Some comments on the patch header:

* No need to put v1 on a patch.  If you are asked to revise it, then you
can start with v2.

* sound: pci: ymfpci: ymfpci_main is not the proper subject line for this
file.  Do git log --oneline and see what others have done.

* There should not be a - after the final colon in the subject line.

* I'm not sure why I was included in this patch.  get_maintainers by
default gives the names of a lot of people.  For general cleanup patches
like this one, you can use the following options, that will just send the
patch to the maintainers, and not to everyone who has ever touched the
file:

scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback --norolestats

julia

On Mon, 23 Jan 2017, Arvind Yadav wrote:

> Here, If ioremap_nocache will fail. It will return NULL.
> Kernel can run into a NULL-pointer dereference.
> This error check will avoid NULL pointer dereference.
>
> Signed-off-by: Arvind Yadav 
> ---
>  sound/pci/ymfpci/ymfpci_main.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c
> index ffee284..8590c3f 100644
> --- a/sound/pci/ymfpci/ymfpci_main.c
> +++ b/sound/pci/ymfpci/ymfpci_main.c
> @@ -2392,6 +2392,10 @@ int snd_ymfpci_create(struct snd_card *card,
>   chip->rev = pci->revision;
>   chip->reg_area_phys = pci_resource_start(pci, 0);
>   chip->reg_area_virt = ioremap_nocache(chip->reg_area_phys, 0x8000);
> + if (!chip->reg_area_virt) {
> + pci_disable_device(pci);
> + return -ENOMEM;
> + }
>   pci_set_master(pci);
>   chip->src441_used = -1;
>
> --
> 1.9.1
>
>

[PATCH] pinctrl: berlin-bg4ct: fix the value for "sd1a" of pin SCRD0_CRD_PRES

[Jisheng Zhang]

This should be a typo.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/berlin-bg4ct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/berlin/berlin-bg4ct.c 
b/drivers/pinctrl/berlin/berlin-bg4ct.c
index 09172043d589..c617ec49e9ed 100644
--- a/drivers/pinctrl/berlin/berlin-bg4ct.c
+++ b/drivers/pinctrl/berlin/berlin-bg4ct.c
@@ -217,7 +217,7 @@ static const struct berlin_desc_group 
berlin4ct_soc_pinctrl_groups[] = {
BERLIN_PINCTRL_GROUP("SCRD0_CRD_PRES", 0xc, 0x3, 0x15,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO20 */
BERLIN_PINCTRL_FUNCTION(0x1, "scrd0"), /* crd pres */
-   BERLIN_PINCTRL_FUNCTION(0x1, "sd1a")), /* DAT3 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a")), /* DAT3 */
BERLIN_PINCTRL_GROUP("SPI1_SS0n", 0xc, 0x3, 0x18,
BERLIN_PINCTRL_FUNCTION(0x0, "spi1"), /* SS0n */
BERLIN_PINCTRL_FUNCTION(0x1, "gpio"), /* GPIO37 */
-- 
2.11.0

[PATCH] pinctrl: berlin-bg4ct: fix the value for "sd1a" of pin SCRD0_CRD_PRES

[Jisheng Zhang]

This should be a typo.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/berlin-bg4ct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/berlin/berlin-bg4ct.c 
b/drivers/pinctrl/berlin/berlin-bg4ct.c
index 09172043d589..c617ec49e9ed 100644
--- a/drivers/pinctrl/berlin/berlin-bg4ct.c
+++ b/drivers/pinctrl/berlin/berlin-bg4ct.c
@@ -217,7 +217,7 @@ static const struct berlin_desc_group 
berlin4ct_soc_pinctrl_groups[] = {
BERLIN_PINCTRL_GROUP("SCRD0_CRD_PRES", 0xc, 0x3, 0x15,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO20 */
BERLIN_PINCTRL_FUNCTION(0x1, "scrd0"), /* crd pres */
-   BERLIN_PINCTRL_FUNCTION(0x1, "sd1a")), /* DAT3 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a")), /* DAT3 */
BERLIN_PINCTRL_GROUP("SPI1_SS0n", 0xc, 0x3, 0x18,
BERLIN_PINCTRL_FUNCTION(0x0, "spi1"), /* SS0n */
BERLIN_PINCTRL_FUNCTION(0x1, "gpio"), /* GPIO37 */
-- 
2.11.0

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Julia Lawall]

On Sun, 22 Jan 2017, Guenter Roeck wrote:

> On 01/22/2017 10:43 PM, Joe Perches wrote:
> > On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
> > > We have a device reference, utilize it instead of pr_warn().
> >
> > There is at least one more hwmon to convert in applesmc.c
> >
> > Perhaps a coccinelle script?
> >
> > Two questions for Julia Lawall:
> >
> > o is there a better way to do this than repeat the blocks
> >   one for each replacement
> > o can struct device * dev be made an arbitrary identifier
>
> Definitely yes here; otherwise you only catch the ones named 'dev'.
> Did you try "identifier dev;" ?

Definitely do that.

>
> The type of fn is irrelevant; you don't need to specify it.

Agreed.

> There is also the case where 'struct device *dev' is a local variable
>
> fn(...) {
> ...
> struct device *dev = e;
> <...
> ...>
> }

Here, you don't need the fn(...) { ... } part.  It would also be good to
say:

expression e != NULL;

dev could also be initialized:

@@
struct device *dev;
expression e != NULL;
expression e1;
@@

dev = e;
<...
-
+
...>
? dev = e1; // stop when dev is reinitialized, to avoid a double match

The rules can all be merged together with a disjunction:

(
- pr_emerg
+ dev_emerg
|
- pr_crit
+ dev_crit  // fill in all cases
)
  (
+ dev,
  ...)

julia


> or when it isn't but is still available
>
> fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
> }
>
> >
> > $ cat dev_printk.cocci
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_emerg(
> > +   dev_emerg(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_crit(
> > +   dev_crit(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_alert(
> > +   dev_alert(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_err(
> > +   dev_err(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_notice(
> > +   dev_notice(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_warn(
> > +   dev_warn(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_info(
> > +   dev_info(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_debug(
> > +   dev_dbg(dev,
> > ...);
> > ...>
> > }
> >
> >
>
>

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Julia Lawall]

On Sun, 22 Jan 2017, Guenter Roeck wrote:

> On 01/22/2017 10:43 PM, Joe Perches wrote:
> > On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
> > > We have a device reference, utilize it instead of pr_warn().
> >
> > There is at least one more hwmon to convert in applesmc.c
> >
> > Perhaps a coccinelle script?
> >
> > Two questions for Julia Lawall:
> >
> > o is there a better way to do this than repeat the blocks
> >   one for each replacement
> > o can struct device * dev be made an arbitrary identifier
>
> Definitely yes here; otherwise you only catch the ones named 'dev'.
> Did you try "identifier dev;" ?

Definitely do that.

>
> The type of fn is irrelevant; you don't need to specify it.

Agreed.

> There is also the case where 'struct device *dev' is a local variable
>
> fn(...) {
> ...
> struct device *dev = e;
> <...
> ...>
> }

Here, you don't need the fn(...) { ... } part.  It would also be good to
say:

expression e != NULL;

dev could also be initialized:

@@
struct device *dev;
expression e != NULL;
expression e1;
@@

dev = e;
<...
-
+
...>
? dev = e1; // stop when dev is reinitialized, to avoid a double match

The rules can all be merged together with a disjunction:

(
- pr_emerg
+ dev_emerg
|
- pr_crit
+ dev_crit  // fill in all cases
)
  (
+ dev,
  ...)

julia


> or when it isn't but is still available
>
> fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
> }
>
> >
> > $ cat dev_printk.cocci
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_emerg(
> > +   dev_emerg(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_crit(
> > +   dev_crit(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_alert(
> > +   dev_alert(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_err(
> > +   dev_err(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_notice(
> > +   dev_notice(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_warn(
> > +   dev_warn(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_info(
> > +   dev_info(dev,
> > ...);
> > ...>
> > }
> >
> > @@
> > identifier fn;
> > type T;
> > @@
> >
> > T fn ( ..., struct device * dev, ... ) {
> > <...
> > -   pr_debug(
> > +   dev_dbg(dev,
> > ...);
> > ...>
> > }
> >
> >
>
>

[RESEND PATCH] usb: chipidea: usb2: delete the redundant setting default DMA mask code

[Jisheng Zhang]

Similar as commit 2b2fe36def08 ("usb: chipidea: imx: delete the
redundant setting default DMA mask code"), the ci_hdrc_usb2 platform
device is also created by device tree, the default DMA mask should be
already set by of_dma_configure when the device are created. So delete
the redundant code at driver.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/chipidea/ci_hdrc_usb2.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
b/drivers/usb/chipidea/ci_hdrc_usb2.c
index 4456d2cf80ff..d162cc0bb8ce 100644
--- a/drivers/usb/chipidea/ci_hdrc_usb2.c
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -74,10 +74,6 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev)
}
}
 
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto clk_err;
-
ci_pdata->name = dev_name(dev);
 
priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
-- 
2.11.0

[RESEND PATCH] usb: chipidea: usb2: delete the redundant setting default DMA mask code

[Jisheng Zhang]

Similar as commit 2b2fe36def08 ("usb: chipidea: imx: delete the
redundant setting default DMA mask code"), the ci_hdrc_usb2 platform
device is also created by device tree, the default DMA mask should be
already set by of_dma_configure when the device are created. So delete
the redundant code at driver.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/chipidea/ci_hdrc_usb2.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
b/drivers/usb/chipidea/ci_hdrc_usb2.c
index 4456d2cf80ff..d162cc0bb8ce 100644
--- a/drivers/usb/chipidea/ci_hdrc_usb2.c
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -74,10 +74,6 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev)
}
}
 
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto clk_err;
-
ci_pdata->name = dev_name(dev);
 
priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
-- 
2.11.0

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Sergey Senozhatsky]

On (01/23/17 15:27), Joonsoo Kim wrote:
> Hello,
> 
> Think about following case in 64 bits kernel.
> 
> If value pattern in the page is like as following, we cannot detect
> the same page with 'unsigned int' element.
> 
> ...
> 
> 4 bytes is 0x and next 4 bytes is 0x and so on.

yep, that's exactly the case that I though would be broken
with a 4-bytes pattern matching. so my conlusion was that
for 4 byte pattern we would have working detection anyway,
for 8 bytes patterns we might have some extra matching.
not sure if it matters that much though.

-ss

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Sergey Senozhatsky]

On (01/23/17 15:27), Joonsoo Kim wrote:
> Hello,
> 
> Think about following case in 64 bits kernel.
> 
> If value pattern in the page is like as following, we cannot detect
> the same page with 'unsigned int' element.
> 
> ...
> 
> 4 bytes is 0x and next 4 bytes is 0x and so on.

yep, that's exactly the case that I though would be broken
with a 4-bytes pattern matching. so my conlusion was that
for 4 byte pattern we would have working detection anyway,
for 8 bytes patterns we might have some extra matching.
not sure if it matters that much though.

-ss

Re: [PATCH v2 22/26] drm/rockchip: vop: test for P{H,V}SYNC

[Mark yao]

On 2017年01月22日 00:31, John Keeping wrote:

When connected to the MIPI DSI output, we need to use N{H,V}SYNC for the
internal connection but these flags are meaningless for DSI panels.
Switch the test so that we do not set the P{H,V}SYNC bits unless the
mode requires it.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..67aefc6d4e9a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -933,8 +933,8 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
}
  
  	pin_pol = 0x8;

-   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
-   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
+   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC) ? 1 : 0;
+   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC) ? (1 << 1) : 0;


I'm confuse that why SYNC flags have N and P on drm, they are same meaning.

If no one configure display mode's flags, I don't know which one is 
correct, N or P? it's a problem.

Does anyone can answer it?

For this patch, it may effect non-sync flags mode on other connector's 
behavior,
but seems mostly display mode has sync flags except mipi dsi connector, 
I think feed mipi's requirement would be better.


So it's no problem  on my side.

Reviewed-by: Mark Yao 


VOP_CTRL_SET(vop, pin_pol, pin_pol);
  
  	switch (s->output_type) {



--
Ｍark Yao

Re: [PATCH v2 22/26] drm/rockchip: vop: test for P{H,V}SYNC

[Mark yao]

On 2017年01月22日 00:31, John Keeping wrote:

When connected to the MIPI DSI output, we need to use N{H,V}SYNC for the
internal connection but these flags are meaningless for DSI panels.
Switch the test so that we do not set the P{H,V}SYNC bits unless the
mode requires it.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..67aefc6d4e9a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -933,8 +933,8 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
}
  
  	pin_pol = 0x8;

-   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
-   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
+   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC) ? 1 : 0;
+   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC) ? (1 << 1) : 0;


I'm confuse that why SYNC flags have N and P on drm, they are same meaning.

If no one configure display mode's flags, I don't know which one is 
correct, N or P? it's a problem.

Does anyone can answer it?

For this patch, it may effect non-sync flags mode on other connector's 
behavior,
but seems mostly display mode has sync flags except mipi dsi connector, 
I think feed mipi's requirement would be better.


So it's no problem  on my side.

Reviewed-by: Mark Yao 


VOP_CTRL_SET(vop, pin_pol, pin_pol);
  
  	switch (s->output_type) {



--
Ｍark Yao

[RESEND PATCH] usb: chipidea: delete an useless header include

[Jisheng Zhang]

 is for net phy drivers, we don't need it.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/chipidea/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3dbb4a21ab44..77078083e9fb 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,7 +62,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.11.0

[RESEND PATCH] usb: chipidea: delete an useless header include

[Jisheng Zhang]

 is for net phy drivers, we don't need it.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/chipidea/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3dbb4a21ab44..77078083e9fb 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,7 +62,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.11.0

[PATCH v1] sound: pci: ymfpci: ymfpci_main:- Handle return NULL error from ioremap_nocache

[Arvind Yadav]

Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.

Signed-off-by: Arvind Yadav 
---
 sound/pci/ymfpci/ymfpci_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c
index ffee284..8590c3f 100644
--- a/sound/pci/ymfpci/ymfpci_main.c
+++ b/sound/pci/ymfpci/ymfpci_main.c
@@ -2392,6 +2392,10 @@ int snd_ymfpci_create(struct snd_card *card,
chip->rev = pci->revision;
chip->reg_area_phys = pci_resource_start(pci, 0);
chip->reg_area_virt = ioremap_nocache(chip->reg_area_phys, 0x8000);
+   if (!chip->reg_area_virt) {
+   pci_disable_device(pci);
+   return -ENOMEM;
+   }
pci_set_master(pci);
chip->src441_used = -1;
 
-- 
1.9.1

[PATCH v1] sound: pci: ymfpci: ymfpci_main:- Handle return NULL error from ioremap_nocache

[Arvind Yadav]

Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.

Signed-off-by: Arvind Yadav 
---
 sound/pci/ymfpci/ymfpci_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c
index ffee284..8590c3f 100644
--- a/sound/pci/ymfpci/ymfpci_main.c
+++ b/sound/pci/ymfpci/ymfpci_main.c
@@ -2392,6 +2392,10 @@ int snd_ymfpci_create(struct snd_card *card,
chip->rev = pci->revision;
chip->reg_area_phys = pci_resource_start(pci, 0);
chip->reg_area_virt = ioremap_nocache(chip->reg_area_phys, 0x8000);
+   if (!chip->reg_area_virt) {
+   pci_disable_device(pci);
+   return -ENOMEM;
+   }
pci_set_master(pci);
chip->src441_used = -1;
 
-- 
1.9.1

Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Dan Williams]

On Sun, Jan 22, 2017 at 10:37 PM, Matthew Wilcox  wrote:
> From: Christoph Hellwig [mailto:h...@lst.de]
>> On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote:
>> > Two guests on the same physical machine (or a guest and a host) have access
>> > to the same set of physical addresses.  This might be an NV-DIMM, or it 
>> > might
>> > just be DRAM (for the purposes of reducing guest overhead).  The network
>> > filesystem has been enhanced with a call to allow the client to ask the 
>> > server
>> > "What is the physical address for this range of bytes in this file?"
>> >
>> > We don't want to use the guest pagecache here.  That's antithetical to the
>> > second usage, and it's inefficient for the first usage.
>>
>> And the answer is that you need a dax device for whatever memoery exposed
>> in this way, as it needs to show up in the memory map for example.
>
> Wow, DAX devices look painful and awful.  I certainly don't want to be 
> exposing the memory fronted by my network filesystem to userspace to access.  
> That just seems like a world of pain and bad experiences.  Absolutely the 
> filesystem (or perhaps better, the ACPI tables) need to mark that chunk of 
> memory as reserved, but it's definitely not available for anyone to access 
> without the filesystem being aware.
>
> Even if we let the filesystem create a DAX device that doesn't show up in 
> /dev (for example), Dan's patches don't give us a way to go from a file on 
> the filesystem to a set of dax_ops.  And it does need to be a per-file 
> operation, eg to support a file on an XFS volume which might be on a RT 
> device or a normal device.  That was why I leaned towards an address_space 
> operation, but I'd be happy to see an inode_operation instead.

How about we solve the copy_from_user() abuse first before we hijack
this thread for some future feature that afaics has no patches posted
yet.

An incremental step towards disentangling filesystem-dax from
block_devices is a lookup mechanism to go from a block_device to a dax
object that holds dax_ops. When this brave new filesystem enabling
appears it can grow a mechanism to lookup, or mount on, the dax object
directly.

One idea is to just hang a pointer to this dax object off of
bdev_inode, set at bdev open() time.

Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Dan Williams]

On Sun, Jan 22, 2017 at 10:37 PM, Matthew Wilcox  wrote:
> From: Christoph Hellwig [mailto:h...@lst.de]
>> On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote:
>> > Two guests on the same physical machine (or a guest and a host) have access
>> > to the same set of physical addresses.  This might be an NV-DIMM, or it 
>> > might
>> > just be DRAM (for the purposes of reducing guest overhead).  The network
>> > filesystem has been enhanced with a call to allow the client to ask the 
>> > server
>> > "What is the physical address for this range of bytes in this file?"
>> >
>> > We don't want to use the guest pagecache here.  That's antithetical to the
>> > second usage, and it's inefficient for the first usage.
>>
>> And the answer is that you need a dax device for whatever memoery exposed
>> in this way, as it needs to show up in the memory map for example.
>
> Wow, DAX devices look painful and awful.  I certainly don't want to be 
> exposing the memory fronted by my network filesystem to userspace to access.  
> That just seems like a world of pain and bad experiences.  Absolutely the 
> filesystem (or perhaps better, the ACPI tables) need to mark that chunk of 
> memory as reserved, but it's definitely not available for anyone to access 
> without the filesystem being aware.
>
> Even if we let the filesystem create a DAX device that doesn't show up in 
> /dev (for example), Dan's patches don't give us a way to go from a file on 
> the filesystem to a set of dax_ops.  And it does need to be a per-file 
> operation, eg to support a file on an XFS volume which might be on a RT 
> device or a normal device.  That was why I leaned towards an address_space 
> operation, but I'd be happy to see an inode_operation instead.

How about we solve the copy_from_user() abuse first before we hijack
this thread for some future feature that afaics has no patches posted
yet.

An incremental step towards disentangling filesystem-dax from
block_devices is a lookup mechanism to go from a block_device to a dax
object that holds dax_ops. When this brave new filesystem enabling
appears it can grow a mechanism to lookup, or mount on, the dax object
directly.

One idea is to just hang a pointer to this dax object off of
bdev_inode, set at bdev open() time.

Re: [PATCH v2 1/1] ARM: dts: add Armadeus Systems OPOS6UL and OPOS6ULDEV support

[Shawn Guo]

On Tue, Jan 10, 2017 at 02:32:53PM +0100, Sébastien Szymanski wrote:
> OPOS6UL is an i.MX6UL based SoM.
> OPOS6ULDev is a carrier board for the OPOS6UL SoM.
> 
> For more details see:
> http://www.opossom.com/english/products-processor_boards-opos6ul.html
> http://www.opossom.com/english/products-development_boards-opos6ul_dev.html
> 
> Signed-off-by: Sébastien Szymanski 

Applied, thanks.

Re: [PATCH v2 1/1] ARM: dts: add Armadeus Systems OPOS6UL and OPOS6ULDEV support

[Shawn Guo]

On Tue, Jan 10, 2017 at 02:32:53PM +0100, Sébastien Szymanski wrote:
> OPOS6UL is an i.MX6UL based SoM.
> OPOS6ULDev is a carrier board for the OPOS6UL SoM.
> 
> For more details see:
> http://www.opossom.com/english/products-processor_boards-opos6ul.html
> http://www.opossom.com/english/products-development_boards-opos6ul_dev.html
> 
> Signed-off-by: Sébastien Szymanski 

Applied, thanks.

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Guenter Roeck]

On 01/22/2017 10:43 PM, Joe Perches wrote:

On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:

We have a device reference, utilize it instead of pr_warn().


There is at least one more hwmon to convert in applesmc.c

Perhaps a coccinelle script?

Two questions for Julia Lawall:

o is there a better way to do this than repeat the blocks
  one for each replacement
o can struct device * dev be made an arbitrary identifier


Definitely yes here; otherwise you only catch the ones named 'dev'.
Did you try "identifier dev;" ?

The type of fn is irrelevant; you don't need to specify it.

There is also the case where 'struct device *dev' is a local variable

fn(...) {
...
struct device *dev = e;
<...
...>
}

or when it isn't but is still available

fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
}



$ cat dev_printk.cocci
@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_crit(
+   dev_crit(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_alert(
+   dev_alert(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_err(
+   dev_err(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_notice(
+   dev_notice(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_warn(
+   dev_warn(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_info(
+   dev_info(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_debug(
+   dev_dbg(dev,
...);
...>
}

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Guenter Roeck]

On 01/22/2017 10:43 PM, Joe Perches wrote:

On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:

We have a device reference, utilize it instead of pr_warn().


There is at least one more hwmon to convert in applesmc.c

Perhaps a coccinelle script?

Two questions for Julia Lawall:

o is there a better way to do this than repeat the blocks
  one for each replacement
o can struct device * dev be made an arbitrary identifier


Definitely yes here; otherwise you only catch the ones named 'dev'.
Did you try "identifier dev;" ?

The type of fn is irrelevant; you don't need to specify it.

There is also the case where 'struct device *dev' is a local variable

fn(...) {
...
struct device *dev = e;
<...
...>
}

or when it isn't but is still available

fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
}



$ cat dev_printk.cocci
@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_crit(
+   dev_crit(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_alert(
+   dev_alert(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_err(
+   dev_err(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_notice(
+   dev_notice(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_warn(
+   dev_warn(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_info(
+   dev_info(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_debug(
+   dev_dbg(dev,
...);
...>
}

Re: [PATCH 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrew-Jeffery/gpio-aspeed-Implement-banks-Y-Z-AA-AB-and-AC/20170123-134930
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from arch/sparc/include/asm/bitops_64.h:53:0,
from arch/sparc/include/asm/bitops.h:4,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   drivers/gpio/gpio-aspeed.c: In function 'set_irq_valid_mask':
>> include/asm-generic/bitops/find.h:58:60: error: passing argument 1 of 
>> 'find_next_zero_bit' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 
0)
   ^
   include/linux/bitops.h:50:15: note: in expansion of macro 
'find_first_zero_bit'
 for ((bit) = find_first_zero_bit((addr), (size)); \
  ^~~
   drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   include/asm-generic/bitops/find.h:28:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
 ^~
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/linux/bitops.h:52:34: error: passing argument 1 of 
'find_next_zero_bit' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
 ^
   drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   In file included from arch/sparc/include/asm/bitops_64.h:53:0,
from arch/sparc/include/asm/bitops.h:4,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/asm-generic/bitops/find.h:28:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
 ^~
   cc1: some warnings being treated as errors

vim +/find_next_zero_bit +58 include/asm-generic/bitops/find.h

708ff2a0 Akinobu Mita   2010-09-29  42  extern unsigned long 
find_first_bit(const unsigned long *addr,
708ff2a0 Akinobu Mita   2010-09-29  43  
unsigned long size);
708ff2a0 Akinobu Mita   2010-09-29  44  
708ff2a0 Akinobu Mita   2010-09-29  45  /**
708ff2a0 Akinobu Mita   2010-09-29  46   * find_first_zero_bit - find the first 
cleared bit in a memory region
708ff2a0 Akinobu Mita   2010-09-29  47   * @addr: The address to start the 
search at
ec778edf Cody P Schafer 2013-11-12  48   * @size: The maximum number of bits to 
search
708ff2a0 Akinobu Mita   2010-09-29  49   *
708ff2a0 Akinobu Mita   2010-09-29  50   * Returns the bit number of the first 
cleared bit.
ec778edf Cody P Schafer 2013-11-12  51   * If no bits are zero, returns @size.
708ff2a0 Akinobu Mita   2010-09-29  52   */
708ff2a0 Akinobu Mita   2010-09-29  53  extern unsigned long 
find_first_zero_bit(const unsigned long *addr,
708ff2a0 Akinobu Mita   2010-09-29  54  
 unsigned long size);
708ff2a0 Akinobu Mita   2010-09-29  55  #else /* CONFIG_GENERIC_FIND_FIRST_BIT 
*/
708ff2a0 Akinobu Mita   2010-09-29  56  
c7f612cd Akinobu Mita   2006-03-26  57  #define find_first_bit(addr, size) 
find_next_bit((addr), (size), 0)
c7f612cd Akinobu Mita   2006-03-26 @58  #define find_first_zero_bit(addr, size) 
find_next_zero_bit((addr), 

Re: [PATCH 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrew-Jeffery/gpio-aspeed-Implement-banks-Y-Z-AA-AB-and-AC/20170123-134930
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from arch/sparc/include/asm/bitops_64.h:53:0,
from arch/sparc/include/asm/bitops.h:4,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   drivers/gpio/gpio-aspeed.c: In function 'set_irq_valid_mask':
>> include/asm-generic/bitops/find.h:58:60: error: passing argument 1 of 
>> 'find_next_zero_bit' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 
0)
   ^
   include/linux/bitops.h:50:15: note: in expansion of macro 
'find_first_zero_bit'
 for ((bit) = find_first_zero_bit((addr), (size)); \
  ^~~
   drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   include/asm-generic/bitops/find.h:28:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
 ^~
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/linux/bitops.h:52:34: error: passing argument 1 of 
'find_next_zero_bit' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
 ^
   drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   In file included from arch/sparc/include/asm/bitops_64.h:53:0,
from arch/sparc/include/asm/bitops.h:4,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/asm-generic/bitops/find.h:28:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
 ^~
   cc1: some warnings being treated as errors

vim +/find_next_zero_bit +58 include/asm-generic/bitops/find.h

708ff2a0 Akinobu Mita   2010-09-29  42  extern unsigned long 
find_first_bit(const unsigned long *addr,
708ff2a0 Akinobu Mita   2010-09-29  43  
unsigned long size);
708ff2a0 Akinobu Mita   2010-09-29  44  
708ff2a0 Akinobu Mita   2010-09-29  45  /**
708ff2a0 Akinobu Mita   2010-09-29  46   * find_first_zero_bit - find the first 
cleared bit in a memory region
708ff2a0 Akinobu Mita   2010-09-29  47   * @addr: The address to start the 
search at
ec778edf Cody P Schafer 2013-11-12  48   * @size: The maximum number of bits to 
search
708ff2a0 Akinobu Mita   2010-09-29  49   *
708ff2a0 Akinobu Mita   2010-09-29  50   * Returns the bit number of the first 
cleared bit.
ec778edf Cody P Schafer 2013-11-12  51   * If no bits are zero, returns @size.
708ff2a0 Akinobu Mita   2010-09-29  52   */
708ff2a0 Akinobu Mita   2010-09-29  53  extern unsigned long 
find_first_zero_bit(const unsigned long *addr,
708ff2a0 Akinobu Mita   2010-09-29  54  
 unsigned long size);
708ff2a0 Akinobu Mita   2010-09-29  55  #else /* CONFIG_GENERIC_FIND_FIRST_BIT 
*/
708ff2a0 Akinobu Mita   2010-09-29  56  
c7f612cd Akinobu Mita   2006-03-26  57  #define find_first_bit(addr, size) 
find_next_bit((addr), (size), 0)
c7f612cd Akinobu Mita   2006-03-26 @58  #define find_first_zero_bit(addr, size) 
find_next_zero_bit((addr), 

[PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

From: Jingju Hou 

From: Jingju Hou 

The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY

Signed-off-by: Jingju Hou 
Signed-off-by: Jisheng Zhang 
---
since v3:
 - really fix the build error

since v2,v1:
 - using phy_dev member in struct net_device
 - add commit msg

 drivers/net/ethernet/marvell/mvneta.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 6dcc951af0ff..02611fa1c3b8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device 
*dev, u32 *indir, u8 *key,
return 0;
 }
 
+static void mvneta_ethtool_get_wol(struct net_device *dev,
+  struct ethtool_wolinfo *wol)
+{
+   wol->supported = 0;
+   wol->wolopts = 0;
+
+   if (dev->phydev)
+   return phy_ethtool_get_wol(dev->phydev, wol);
+}
+
+static int mvneta_ethtool_set_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wol)
+{
+   if (!dev->phydev)
+   return -EOPNOTSUPP;
+
+   return phy_ethtool_set_wol(dev->phydev, wol);
+}
+
 static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open= mvneta_open,
.ndo_stop= mvneta_stop,
@@ -3958,6 +3977,8 @@ const struct ethtool_ops mvneta_eth_tool_ops = {
.set_rxfh   = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+   .get_wol= mvneta_ethtool_get_wol,
+   .set_wol= mvneta_ethtool_set_wol,
 };
 
 /* Initialize hw */
-- 
2.11.0

[PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

From: Jingju Hou 

From: Jingju Hou 

The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY

Signed-off-by: Jingju Hou 
Signed-off-by: Jisheng Zhang 
---
since v3:
 - really fix the build error

since v2,v1:
 - using phy_dev member in struct net_device
 - add commit msg

 drivers/net/ethernet/marvell/mvneta.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 6dcc951af0ff..02611fa1c3b8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device 
*dev, u32 *indir, u8 *key,
return 0;
 }
 
+static void mvneta_ethtool_get_wol(struct net_device *dev,
+  struct ethtool_wolinfo *wol)
+{
+   wol->supported = 0;
+   wol->wolopts = 0;
+
+   if (dev->phydev)
+   return phy_ethtool_get_wol(dev->phydev, wol);
+}
+
+static int mvneta_ethtool_set_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wol)
+{
+   if (!dev->phydev)
+   return -EOPNOTSUPP;
+
+   return phy_ethtool_set_wol(dev->phydev, wol);
+}
+
 static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open= mvneta_open,
.ndo_stop= mvneta_stop,
@@ -3958,6 +3977,8 @@ const struct ethtool_ops mvneta_eth_tool_ops = {
.set_rxfh   = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+   .get_wol= mvneta_ethtool_get_wol,
+   .set_wol= mvneta_ethtool_set_wol,
 };
 
 /* Initialize hw */
-- 
2.11.0

Re: [PATCH] ARM: imx: hide unused variable in #ifdef

[Shawn Guo]

On Tue, Jan 10, 2017 at 01:19:05PM +0100, Arnd Bergmann wrote:
> A bugfix added a new local variable that is only used inside of an #ifdef
> section, and unused if CONFIG_PERF_EVENTS is disabled:
> 
> arch/arm/mach-imx/mmdc.c:63:25: warning: 'cpuhp_mmdc_state' defined but not 
> used [-Wunused-variable]
> 
> This moves the variable down inside that same ifdef.
> 
> Fixes: a051f220d6b9 ("ARM/imx/mmcd: Fix broken cpu hotplug handling")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

Re: [PATCH] ARM: imx: hide unused variable in #ifdef

[Shawn Guo]

On Tue, Jan 10, 2017 at 01:19:05PM +0100, Arnd Bergmann wrote:
> A bugfix added a new local variable that is only used inside of an #ifdef
> section, and unused if CONFIG_PERF_EVENTS is disabled:
> 
> arch/arm/mach-imx/mmdc.c:63:25: warning: 'cpuhp_mmdc_state' defined but not 
> used [-Wunused-variable]
> 
> This moves the variable down inside that same ifdef.
> 
> Fixes: a051f220d6b9 ("ARM/imx/mmcd: Fix broken cpu hotplug handling")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Joe Perches]

On Sun, 2017-01-22 at 22:43 -0800, Joe Perches wrote:
> Two questions for Julia Lawall:
> 
> o is there a better way to do this than repeat the blocks
>   one for each replacement
> o can struct device * dev be made an arbitrary identifier
> 
> $ cat dev_printk.cocci
> @@
> identifier fn;
> type T;
> @@
> 
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_emerg(
> + dev_emerg(dev,
>   ...);
> ...>
> }

Well, the second question is simple if I would just
think a little before asking...

@@
identifier fn;
identifier dev;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

etc...

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Joe Perches]

On Sun, 2017-01-22 at 22:43 -0800, Joe Perches wrote:
> Two questions for Julia Lawall:
> 
> o is there a better way to do this than repeat the blocks
>   one for each replacement
> o can struct device * dev be made an arbitrary identifier
> 
> $ cat dev_printk.cocci
> @@
> identifier fn;
> type T;
> @@
> 
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_emerg(
> + dev_emerg(dev,
>   ...);
> ...>
> }

Well, the second question is simple if I would just
think a little before asking...

@@
identifier fn;
identifier dev;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

etc...

Re: [PATCH 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrew-Jeffery/gpio-aspeed-Implement-banks-Y-Z-AA-AB-and-AC/20170123-134930
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   drivers/gpio/gpio-aspeed.c: In function 'set_irq_valid_mask':
>> include/linux/bitops.h:50:35: error: passing argument 1 of 
>> 'find_first_zero_bit' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 for ((bit) = find_first_zero_bit((addr), (size)); \
  ^
>> drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
>> 'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   In file included from arch/x86/include/asm/bitops.h:509:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/asm-generic/bitops/find.h:53:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_first_zero_bit(const unsigned long *addr,
 ^~~
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
>> include/linux/bitops.h:52:34: error: passing argument 1 of 
>> 'find_next_zero_bit' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
  (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
 ^
>> drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
>> 'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   In file included from arch/x86/include/asm/bitops.h:509:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/asm-generic/bitops/find.h:28:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
 ^~
   cc1: some warnings being treated as errors

vim +/for_each_clear_bit +457 drivers/gpio/gpio-aspeed.c

   441  static struct irq_chip aspeed_gpio_irqchip = {
   442  .name   = "aspeed-gpio",
   443  .irq_ack= aspeed_gpio_irq_ack,
   444  .irq_mask   = aspeed_gpio_irq_mask,
   445  .irq_unmask = aspeed_gpio_irq_unmask,
   446  .irq_set_type   = aspeed_gpio_set_type,
   447  };
   448  
   449  static void set_irq_valid_mask(struct aspeed_gpio *gpio)
   450  {
   451  const struct aspeed_bank_props *props = gpio->config->props;
   452  
   453  while (!is_bank_props_sentinel(props)) {
   454  unsigned int offset;
   455  
   456  /* Pretty crummy approach, but similar to GPIO core */
 > 457  for_each_clear_bit(offset, >input, 32) {
   458  unsigned int i = props->bank * 32 + offset;
   459  
   460  if (i >= gpio->config->nr_gpios)
   461  break;
   462  
   463  clear_bit(i, gpio->chip.irq_valid_mask);
   464  }
   465  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] gpio: aspeed: Add banks Y, Z, AA, AB and AC

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.10-rc5 next-20170123]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrew-Jeffery/gpio-aspeed-Implement-banks-Y-Z-AA-AB-and-AC/20170123-134930
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   drivers/gpio/gpio-aspeed.c: In function 'set_irq_valid_mask':
>> include/linux/bitops.h:50:35: error: passing argument 1 of 
>> 'find_first_zero_bit' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 for ((bit) = find_first_zero_bit((addr), (size)); \
  ^
>> drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
>> 'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   In file included from arch/x86/include/asm/bitops.h:509:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/asm-generic/bitops/find.h:53:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_first_zero_bit(const unsigned long *addr,
 ^~~
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
>> include/linux/bitops.h:52:34: error: passing argument 1 of 
>> 'find_next_zero_bit' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
  (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
 ^
>> drivers/gpio/gpio-aspeed.c:457:3: note: in expansion of macro 
>> 'for_each_clear_bit'
  for_each_clear_bit(offset, >input, 32) {
  ^~
   In file included from arch/x86/include/asm/bitops.h:509:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/gpio/gpio-aspeed.c:12:
   include/asm-generic/bitops/find.h:28:22: note: expected 'const long unsigned 
int *' but argument is of type 'const u32 * {aka const unsigned int *}'
extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
 ^~
   cc1: some warnings being treated as errors

vim +/for_each_clear_bit +457 drivers/gpio/gpio-aspeed.c

   441  static struct irq_chip aspeed_gpio_irqchip = {
   442  .name   = "aspeed-gpio",
   443  .irq_ack= aspeed_gpio_irq_ack,
   444  .irq_mask   = aspeed_gpio_irq_mask,
   445  .irq_unmask = aspeed_gpio_irq_unmask,
   446  .irq_set_type   = aspeed_gpio_set_type,
   447  };
   448  
   449  static void set_irq_valid_mask(struct aspeed_gpio *gpio)
   450  {
   451  const struct aspeed_bank_props *props = gpio->config->props;
   452  
   453  while (!is_bank_props_sentinel(props)) {
   454  unsigned int offset;
   455  
   456  /* Pretty crummy approach, but similar to GPIO core */
 > 457  for_each_clear_bit(offset, >input, 32) {
   458  unsigned int i = props->bank * 32 + offset;
   459  
   460  if (i >= gpio->config->nr_gpios)
   461  break;
   462  
   463  clear_bit(i, gpio->chip.irq_valid_mask);
   464  }
   465  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v2] x86/crash: Update the stale comment in reserve_crashkernel()

[Xunlei Pang]

CRASH_KERNEL_ADDR_MAX has been missing for a long time,
update it with more detailed explanation.

Cc: Robert LeBlanc 
Cc: Baoquan He 
Signed-off-by: Xunlei Pang 
---
 arch/x86/kernel/setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..c32a167 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -575,7 +575,9 @@ static void __init reserve_crashkernel(void)
/* 0 means: find the address automatically */
if (crash_base <= 0) {
/*
-*  kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
+* Set CRASH_ADDR_LOW_MAX upper bound for crash memory
+* as old kexec-tools loads bzImage below that, unless
+* "crashkernel=size[KMG],high" is specified.
 */
crash_base = memblock_find_in_range(CRASH_ALIGN,
high ? CRASH_ADDR_HIGH_MAX
-- 
1.8.3.1

[PATCH v2] x86/crash: Update the stale comment in reserve_crashkernel()

[Xunlei Pang]

CRASH_KERNEL_ADDR_MAX has been missing for a long time,
update it with more detailed explanation.

Cc: Robert LeBlanc 
Cc: Baoquan He 
Signed-off-by: Xunlei Pang 
---
 arch/x86/kernel/setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..c32a167 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -575,7 +575,9 @@ static void __init reserve_crashkernel(void)
/* 0 means: find the address automatically */
if (crash_base <= 0) {
/*
-*  kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
+* Set CRASH_ADDR_LOW_MAX upper bound for crash memory
+* as old kexec-tools loads bzImage below that, unless
+* "crashkernel=size[KMG],high" is specified.
 */
crash_base = memblock_find_in_range(CRASH_ALIGN,
high ? CRASH_ADDR_HIGH_MAX
-- 
1.8.3.1

答复: [PATCH] mm: extend zero pages to same element pages for zram

[zhouxianrong]

Yes, memset's prototype is int but
the implement of arch is unsigned char; for example, in arm64

.weak memset
ENTRY(__memset)
ENTRY(memset)
mov dst, dstin  /* Preserve return value.  */
and A_lw, val, #255
orr A_lw, A_lw, A_lw, lsl #8
orr A_lw, A_lw, A_lw, lsl #16
orr A_l, A_l, A_l, lsl #32

-邮件原件-
发件人: Matthew Wilcox [mailto:wi...@infradead.org] 
发送时间: 2017年1月23日 14:26
收件人: zhouxianrong
抄送: Sergey Senozhatsky; linux...@kvack.org; linux-kernel@vger.kernel.org; 
a...@linux-foundation.org; sergey.senozhat...@gmail.com; minc...@kernel.org; 
ngu...@vflare.org; Mi Sophia Wang; Zhouxiyu; Duwei (Device OS); Zhangshiming 
(Simon, Device OS); Won Ho Park
主题: Re: [PATCH] mm: extend zero pages to same element pages for zram

On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> 1. memset is just set a int value but i want to set a long value.

memset doesn't set an int value.

DESCRIPTION
   The  memset()  function  fills  the  first  n  bytes of the memory area
   pointed to by s with the constant byte c.

It sets a byte value.  K just happened to choose 'int' as the type to store 
that "unsigned char" in.  Probably for very good reasons which make absolutely 
no sense today.

答复: [PATCH] mm: extend zero pages to same element pages for zram

[zhouxianrong]

Yes, memset's prototype is int but
the implement of arch is unsigned char; for example, in arm64

.weak memset
ENTRY(__memset)
ENTRY(memset)
mov dst, dstin  /* Preserve return value.  */
and A_lw, val, #255
orr A_lw, A_lw, A_lw, lsl #8
orr A_lw, A_lw, A_lw, lsl #16
orr A_l, A_l, A_l, lsl #32

-邮件原件-
发件人: Matthew Wilcox [mailto:wi...@infradead.org] 
发送时间: 2017年1月23日 14:26
收件人: zhouxianrong
抄送: Sergey Senozhatsky; linux...@kvack.org; linux-kernel@vger.kernel.org; 
a...@linux-foundation.org; sergey.senozhat...@gmail.com; minc...@kernel.org; 
ngu...@vflare.org; Mi Sophia Wang; Zhouxiyu; Duwei (Device OS); Zhangshiming 
(Simon, Device OS); Won Ho Park
主题: Re: [PATCH] mm: extend zero pages to same element pages for zram

On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> 1. memset is just set a int value but i want to set a long value.

memset doesn't set an int value.

DESCRIPTION
   The  memset()  function  fills  the  first  n  bytes of the memory area
   pointed to by s with the constant byte c.

It sets a byte value.  K just happened to choose 'int' as the type to store 
that "unsigned char" in.  Probably for very good reasons which make absolutely 
no sense today.

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Joe Perches]

On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
> We have a device reference, utilize it instead of pr_warn().

There is at least one more hwmon to convert in applesmc.c

Perhaps a coccinelle script?

Two questions for Julia Lawall:

o is there a better way to do this than repeat the blocks
  one for each replacement
o can struct device * dev be made an arbitrary identifier

$ cat dev_printk.cocci
@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_crit(
+   dev_crit(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_alert(
+   dev_alert(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_err(
+   dev_err(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_notice(
+   dev_notice(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_warn(
+   dev_warn(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_info(
+   dev_info(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_debug(
+   dev_dbg(dev,
...);
...>
}

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Joe Perches]

On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
> We have a device reference, utilize it instead of pr_warn().

There is at least one more hwmon to convert in applesmc.c

Perhaps a coccinelle script?

Two questions for Julia Lawall:

o is there a better way to do this than repeat the blocks
  one for each replacement
o can struct device * dev be made an arbitrary identifier

$ cat dev_printk.cocci
@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_crit(
+   dev_crit(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_alert(
+   dev_alert(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_err(
+   dev_err(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_notice(
+   dev_notice(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_warn(
+   dev_warn(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_info(
+   dev_info(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_debug(
+   dev_dbg(dev,
...);
...>
}

RE: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Matthew Wilcox]

From: Christoph Hellwig [mailto:h...@lst.de]
> On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote:
> > Two guests on the same physical machine (or a guest and a host) have access
> > to the same set of physical addresses.  This might be an NV-DIMM, or it 
> > might
> > just be DRAM (for the purposes of reducing guest overhead).  The network
> > filesystem has been enhanced with a call to allow the client to ask the 
> > server
> > "What is the physical address for this range of bytes in this file?"
> >
> > We don't want to use the guest pagecache here.  That's antithetical to the
> > second usage, and it's inefficient for the first usage.
> 
> And the answer is that you need a dax device for whatever memoery exposed
> in this way, as it needs to show up in the memory map for example.

Wow, DAX devices look painful and awful.  I certainly don't want to be exposing 
the memory fronted by my network filesystem to userspace to access.  That just 
seems like a world of pain and bad experiences.  Absolutely the filesystem (or 
perhaps better, the ACPI tables) need to mark that chunk of memory as reserved, 
but it's definitely not available for anyone to access without the filesystem 
being aware.

Even if we let the filesystem create a DAX device that doesn't show up in /dev 
(for example), Dan's patches don't give us a way to go from a file on the 
filesystem to a set of dax_ops.  And it does need to be a per-file operation, 
eg to support a file on an XFS volume which might be on a RT device or a normal 
device.  That was why I leaned towards an address_space operation, but I'd be 
happy to see an inode_operation instead. 

RE: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

[Matthew Wilcox]

From: Christoph Hellwig [mailto:h...@lst.de]
> On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote:
> > Two guests on the same physical machine (or a guest and a host) have access
> > to the same set of physical addresses.  This might be an NV-DIMM, or it 
> > might
> > just be DRAM (for the purposes of reducing guest overhead).  The network
> > filesystem has been enhanced with a call to allow the client to ask the 
> > server
> > "What is the physical address for this range of bytes in this file?"
> >
> > We don't want to use the guest pagecache here.  That's antithetical to the
> > second usage, and it's inefficient for the first usage.
> 
> And the answer is that you need a dax device for whatever memoery exposed
> in this way, as it needs to show up in the memory map for example.

Wow, DAX devices look painful and awful.  I certainly don't want to be exposing 
the memory fronted by my network filesystem to userspace to access.  That just 
seems like a world of pain and bad experiences.  Absolutely the filesystem (or 
perhaps better, the ACPI tables) need to mark that chunk of memory as reserved, 
but it's definitely not available for anyone to access without the filesystem 
being aware.

Even if we let the filesystem create a DAX device that doesn't show up in /dev 
(for example), Dan's patches don't give us a way to go from a file on the 
filesystem to a set of dax_ops.  And it does need to be a per-file operation, 
eg to support a file on an XFS volume which might be on a RT device or a normal 
device.  That was why I leaned towards an address_space operation, but I'd be 
happy to see an inode_operation instead. 

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Matthew Wilcox]

On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> 1. memset is just set a int value but i want to set a long value.

memset doesn't set an int value.

DESCRIPTION
   The  memset()  function  fills  the  first  n  bytes of the memory area
   pointed to by s with the constant byte c.

It sets a byte value.  K just happened to choose 'int' as the type
to store that "unsigned char" in.  Probably for very good reasons which
make absolutely no sense today.

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Matthew Wilcox]

On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> 1. memset is just set a int value but i want to set a long value.

memset doesn't set an int value.

DESCRIPTION
   The  memset()  function  fills  the  first  n  bytes of the memory area
   pointed to by s with the constant byte c.

It sets a byte value.  K just happened to choose 'int' as the type
to store that "unsigned char" in.  Probably for very good reasons which
make absolutely no sense today.

Re: [PATCH v2] tags: honor COMPILED_SOURCE with apart output directory

[Robert Jarzmik]

Robert Jarzmik  writes:

> When the kernel is compiled with an "O=" argument, the object files are
> not necessarily in the source tree, and more probably in another tree.
>
> In this situation, the current used check doesn't work, and
> COMPILED_SOURCE tags is broken with O= builds.
>
> This patch fixes it by looking for object files both in source tree and
> potential destination tree.
>
> It was verified that in the case of O= usage, the current directory is
> the build tree, ie. the tree referenced by O=xxx, and j is the source
> tree path concatenated with relative path of the object to the source
> tree root, hence the simple expression to compute "k" as the built
> object.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: amended k expression, Marek's comments
Hi Marek,

Is this version good for you ?

> ---
>  scripts/tags.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index a2ff3388e5ea..35cb64d5211c 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -106,7 +106,8 @@ all_compiled_sources()
>   case "$i" in
>   *.[cS])
>   j=${i/\.[cS]/\.o}
> - if [ -e $j ]; then
> + k="${j#$tree}"
> + if [ -e $j -o -e "$k" ]; then
>   echo $i
>   fi
>   ;;

Cheers.

-- 
Robert

Re: [PATCH v2] tags: honor COMPILED_SOURCE with apart output directory

[Robert Jarzmik]

Robert Jarzmik  writes:

> When the kernel is compiled with an "O=" argument, the object files are
> not necessarily in the source tree, and more probably in another tree.
>
> In this situation, the current used check doesn't work, and
> COMPILED_SOURCE tags is broken with O= builds.
>
> This patch fixes it by looking for object files both in source tree and
> potential destination tree.
>
> It was verified that in the case of O= usage, the current directory is
> the build tree, ie. the tree referenced by O=xxx, and j is the source
> tree path concatenated with relative path of the object to the source
> tree root, hence the simple expression to compute "k" as the built
> object.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: amended k expression, Marek's comments
Hi Marek,

Is this version good for you ?

> ---
>  scripts/tags.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index a2ff3388e5ea..35cb64d5211c 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -106,7 +106,8 @@ all_compiled_sources()
>   case "$i" in
>   *.[cS])
>   j=${i/\.[cS]/\.o}
> - if [ -e $j ]; then
> + k="${j#$tree}"
> + if [ -e $j -o -e "$k" ]; then
>   echo $i
>   fi
>   ;;

Cheers.

-- 
Robert

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Joonsoo Kim]

On Mon, Jan 23, 2017 at 01:03:47PM +0900, Sergey Senozhatsky wrote:
> On (01/23/17 11:58), Joonsoo Kim wrote:
> > Hello,
> > 
> > On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> > > 1. memset is just set a int value but i want to set a long value.
> > 
> > Sorry for late review.
> > 
> > Do we really need to set a long value? I cannot believe that
> > long value is repeated in the page. Value repeatition is
> > usually done by value 0 or 1 and it's enough to use int. And, I heard
> > that value 0 or 1 is repeated in Android. Could you check the distribution
> > of the value in the same page?
> 
> Hello Joonsoo,
> 
> thanks for taking a look and for bringing this question up.
> so I kinda wanted to propose union of `ulong handle' with `uint element'
> and switching to memset(), but I couldn't figure out if that change would
> break detection of some patterns.
> 
>  /* Allocated for each disk page */
>  struct zram_table_entry {
> -   unsigned long handle;
> +   union {
> +   unsigned long handle;
> +   unsigned int element;
> +   };
> unsigned long value;
>  };

Hello,

Think about following case in 64 bits kernel.

If value pattern in the page is like as following, we cannot detect
the same page with 'unsigned int' element.

...

4 bytes is 0x and next 4 bytes is 0x and so on.

However, as I said before, I think that it is uncommon case.

Thanks.

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Joonsoo Kim]

On Mon, Jan 23, 2017 at 01:03:47PM +0900, Sergey Senozhatsky wrote:
> On (01/23/17 11:58), Joonsoo Kim wrote:
> > Hello,
> > 
> > On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> > > 1. memset is just set a int value but i want to set a long value.
> > 
> > Sorry for late review.
> > 
> > Do we really need to set a long value? I cannot believe that
> > long value is repeated in the page. Value repeatition is
> > usually done by value 0 or 1 and it's enough to use int. And, I heard
> > that value 0 or 1 is repeated in Android. Could you check the distribution
> > of the value in the same page?
> 
> Hello Joonsoo,
> 
> thanks for taking a look and for bringing this question up.
> so I kinda wanted to propose union of `ulong handle' with `uint element'
> and switching to memset(), but I couldn't figure out if that change would
> break detection of some patterns.
> 
>  /* Allocated for each disk page */
>  struct zram_table_entry {
> -   unsigned long handle;
> +   union {
> +   unsigned long handle;
> +   unsigned int element;
> +   };
> unsigned long value;
>  };

Hello,

Think about following case in 64 bits kernel.

If value pattern in the page is like as following, we cannot detect
the same page with 'unsigned int' element.

...

4 bytes is 0x and next 4 bytes is 0x and so on.

However, as I said before, I think that it is uncommon case.

Thanks.

Re: [PATCH] zram: remove obsolete sysfs attrs

[Sergey Senozhatsky]

On (01/23/17 15:04), Minchan Kim wrote:
> On Wed, Jan 18, 2017 at 12:58:38PM +0900, Sergey Senozhatsky wrote:
> > We had a deprecated_attr_warn() warning for 2 years and now the
> > time has come and we finally can do the cleanup.
> > 
> > The plan was as follows:
> > 
> > : per-stat sysfs attributes are considered to be deprecated.
> > : The basic strategy is:
> > : -- the existing RW nodes will be downgraded to WO nodes (in linux 4.11)
> > : -- deprecated RO sysfs nodes will eventually be removed (in linux 4.11)
> > :
> > : The list of deprecated attributes can be found here:
> > : Documentation/ABI/obsolete/sysfs-block-zram
> > :
> > : Basically, every attribute that has its own read accessible sysfs
> > : node (e.g. num_reads) *AND* is accessible via one of the stat files
> > : (zram/stat or zram/io_stat or zram/mm_stat) is considered
> > : to be deprecated.
> > 
> > The patch also removes `obsolete/sysfs-block-zram', clean ups
> > `testing/sysfs-block-zram' and tweaks zram.txt files.
> > 
> > Signed-off-by: Sergey Senozhatsky 
> Acked-by: Minchan Kim 

thanks.


I didn't touch some of the attrs. we can start a new deprecation cycle
a bit later. for instance, our sysfs zram_hot add/remove must leave; and
max_comp_streams is still RW - we left if intact just in case if we would
revert per-cpu compression stream and return idle list back.

-ss

Re: [PATCH] zram: remove obsolete sysfs attrs

[Sergey Senozhatsky]

On (01/23/17 15:04), Minchan Kim wrote:
> On Wed, Jan 18, 2017 at 12:58:38PM +0900, Sergey Senozhatsky wrote:
> > We had a deprecated_attr_warn() warning for 2 years and now the
> > time has come and we finally can do the cleanup.
> > 
> > The plan was as follows:
> > 
> > : per-stat sysfs attributes are considered to be deprecated.
> > : The basic strategy is:
> > : -- the existing RW nodes will be downgraded to WO nodes (in linux 4.11)
> > : -- deprecated RO sysfs nodes will eventually be removed (in linux 4.11)
> > :
> > : The list of deprecated attributes can be found here:
> > : Documentation/ABI/obsolete/sysfs-block-zram
> > :
> > : Basically, every attribute that has its own read accessible sysfs
> > : node (e.g. num_reads) *AND* is accessible via one of the stat files
> > : (zram/stat or zram/io_stat or zram/mm_stat) is considered
> > : to be deprecated.
> > 
> > The patch also removes `obsolete/sysfs-block-zram', clean ups
> > `testing/sysfs-block-zram' and tweaks zram.txt files.
> > 
> > Signed-off-by: Sergey Senozhatsky 
> Acked-by: Minchan Kim 

thanks.


I didn't touch some of the attrs. we can start a new deprecation cycle
a bit later. for instance, our sysfs zram_hot add/remove must leave; and
max_comp_streams is still RW - we left if intact just in case if we would
revert per-cpu compression stream and return idle list back.

-ss

[PATCH net] r8152: don't execute runtime suspend if the tx is not empty

[Hayes Wang]

Runtime suspend shouldn't be executed if the tx queue is not empty,
because the device is not idle.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0e99af0..e1466b4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"6"
+#define NET_VERSION"7"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -3574,6 +3574,8 @@ static bool delay_autosuspend(struct r8152 *tp)
 */
if (!sw_linking && tp->rtl_ops.in_nway(tp))
return true;
+   else if (!skb_queue_empty(>tx_queue))
+   return true;
else
return false;
 }
-- 
2.7.4

[PATCH net] r8152: don't execute runtime suspend if the tx is not empty

[Hayes Wang]

Runtime suspend shouldn't be executed if the tx queue is not empty,
because the device is not idle.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0e99af0..e1466b4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"6"
+#define NET_VERSION"7"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -3574,6 +3574,8 @@ static bool delay_autosuspend(struct r8152 *tp)
 */
if (!sw_linking && tp->rtl_ops.in_nway(tp))
return true;
+   else if (!skb_queue_empty(>tx_queue))
+   return true;
else
return false;
 }
-- 
2.7.4

Re: [PATCH v3] zram: extend zero pages to same element pages

[zhouxianrong]

i am not sure as well about reverse hurting cache.

On 2017/1/23 14:13, Joonsoo Kim wrote:

On Mon, Jan 23, 2017 at 01:47:20PM +0900, Minchan Kim wrote:

Hello,

When I look at first patch, I wanted to use increment loop but didn't
tell to you because that small piece of code is no harmful for readbility
to me so I want to keep author's code rather than pointing the trivial
which is just matter of preference out.

Rather than readiblity, I suspect it might hurt performance and talked
with Namhyung but we cannot find anything decremental loop is bad
compared to incremental. Rather than, many articles have been said
decrement loop is faster like zhouxianrong's mentiond although I don't
think it makes marginal difference.

Joonsoo, why do you think incremental is faster?
zhouxianrong, why do you think decrement loops makes cache problem?

I'm okay either way. Just want to know why you guys think about it.


Hmm... I guess that cache prefetcher works better for forward access
but I'm not sure.

Thanks.


.

Re: [PATCH v3] zram: extend zero pages to same element pages

[zhouxianrong]

i am not sure as well about reverse hurting cache.

On 2017/1/23 14:13, Joonsoo Kim wrote:

On Mon, Jan 23, 2017 at 01:47:20PM +0900, Minchan Kim wrote:

Hello,

When I look at first patch, I wanted to use increment loop but didn't
tell to you because that small piece of code is no harmful for readbility
to me so I want to keep author's code rather than pointing the trivial
which is just matter of preference out.

Rather than readiblity, I suspect it might hurt performance and talked
with Namhyung but we cannot find anything decremental loop is bad
compared to incremental. Rather than, many articles have been said
decrement loop is faster like zhouxianrong's mentiond although I don't
think it makes marginal difference.

Joonsoo, why do you think incremental is faster?
zhouxianrong, why do you think decrement loops makes cache problem?

I'm okay either way. Just want to know why you guys think about it.


Hmm... I guess that cache prefetcher works better for forward access
but I'm not sure.

Thanks.


.

Re: [PATCH -next] staging: greybus: audio_gb.c: Change uint32_t to u32

[Vaibhav Agarwal]

On Sun, Jan 22, 2017 at 11:19 PM, Marcos Paulo de Souza
 wrote:
> Change uint32_t to u32, solved the issue reported by checkpatch.pl:
>
> CHECK: Prefer kernel type 'u32' over 'uint32_t'
> +   uint32_t *format, uint32_t *rate, u8 *channels,
>
> CHECK: Prefer kernel type 'u32' over 'uint32_t'
> +   uint32_t format, uint32_t rate, u8 channels,
>
> Signed-off-by: Marcos Paulo de Souza 
> ---

Acked-by: Vaibhav Agarwal 

Re: [PATCH -next] staging: greybus: audio_gb.c: Change uint32_t to u32

[Vaibhav Agarwal]

On Sun, Jan 22, 2017 at 11:19 PM, Marcos Paulo de Souza
 wrote:
> Change uint32_t to u32, solved the issue reported by checkpatch.pl:
>
> CHECK: Prefer kernel type 'u32' over 'uint32_t'
> +   uint32_t *format, uint32_t *rate, u8 *channels,
>
> CHECK: Prefer kernel type 'u32' over 'uint32_t'
> +   uint32_t format, uint32_t rate, u8 channels,
>
> Signed-off-by: Marcos Paulo de Souza 
> ---

Acked-by: Vaibhav Agarwal 

Re: [PATCH v2 25/26] drm/rockchip: dw-mipi-dsi: add reset control

[Chris Zhong]

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

In order to fully reset the state of the MIPI controller we must assert
this reset.

This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 881bb0c62ca5..f780401e8b5e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1121,6 +1122,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
of_match_device(dw_mipi_dsi_dt_ids, dev);
const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
struct platform_device *pdev = to_platform_device(dev);
+   struct reset_control *apb_rst;
struct drm_device *drm = data;
struct dw_mipi_dsi *dsi;
struct resource *res;
@@ -1159,6 +1161,34 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
return ret;
}
  
+	/*

+* Note that the reset was not defined in the initial device tree, so
+* we have to be prepared for it not being found.
+*/
+   apb_rst = devm_reset_control_get(dev, "apb");
+   if (IS_ERR(apb_rst)) {
+   if (PTR_ERR(apb_rst) == -ENODEV) {
+   apb_rst = NULL;
+   } else {
+   dev_err(dev, "Unable to get reset control: %d\n", ret);
+   return PTR_ERR(apb_rst);
+   }
+   }
+
+   if (apb_rst) {
+   ret = clk_prepare_enable(dsi->pclk);
+   if (ret) {
+   dev_err(dev, "%s: Failed to enable pclk\n", __func__);
+   return ret;
+   }
+
+   reset_control_assert(apb_rst);
+   usleep_range(10, 20);
+   reset_control_deassert(apb_rst);
+
+   clk_disable_unprepare(dsi->pclk);
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);

Re: [PATCH v2 25/26] drm/rockchip: dw-mipi-dsi: add reset control

[Chris Zhong]

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

In order to fully reset the state of the MIPI controller we must assert
this reset.

This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 881bb0c62ca5..f780401e8b5e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1121,6 +1122,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
of_match_device(dw_mipi_dsi_dt_ids, dev);
const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
struct platform_device *pdev = to_platform_device(dev);
+   struct reset_control *apb_rst;
struct drm_device *drm = data;
struct dw_mipi_dsi *dsi;
struct resource *res;
@@ -1159,6 +1161,34 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
return ret;
}
  
+	/*

+* Note that the reset was not defined in the initial device tree, so
+* we have to be prepared for it not being found.
+*/
+   apb_rst = devm_reset_control_get(dev, "apb");
+   if (IS_ERR(apb_rst)) {
+   if (PTR_ERR(apb_rst) == -ENODEV) {
+   apb_rst = NULL;
+   } else {
+   dev_err(dev, "Unable to get reset control: %d\n", ret);
+   return PTR_ERR(apb_rst);
+   }
+   }
+
+   if (apb_rst) {
+   ret = clk_prepare_enable(dsi->pclk);
+   if (ret) {
+   dev_err(dev, "%s: Failed to enable pclk\n", __func__);
+   return ret;
+   }
+
+   reset_control_assert(apb_rst);
+   usleep_range(10, 20);
+   reset_control_deassert(apb_rst);
+
+   clk_disable_unprepare(dsi->pclk);
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);

Re: [PATCH v2 24/26] drm/rockchip: dw-mipi-dsi: support non-burst modes

[Chris Zhong]

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +---
  1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 2dafb17e31d2..881bb0c62ca5 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -82,6 +82,7 @@
  #define FRAME_BTA_ACK BIT(14)
  #define ENABLE_LOW_POWER  (0x3f << 8)
  #define ENABLE_LOW_POWER_MASK (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
  #define VID_MODE_TYPE_BURST_SYNC_PULSES   0x2
  #define VID_MODE_TYPE_MASK0x3
  
@@ -286,6 +287,7 @@ struct dw_mipi_dsi {

u32 format;
u16 input_div;
u16 feedback_div;
+   unsigned long mode_flags;
  
  	const struct dw_mipi_dsi_plat_data *pdata;

  };
@@ -548,15 +550,10 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
return -EINVAL;
}
  
-	if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ||

-   !(device->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)) {
-   dev_err(dsi->dev, "device mode is unsupported\n");
-   return -EINVAL;
-   }
-
dsi->lanes = device->lanes;
dsi->channel = device->channel;
dsi->format = device->format;
+   dsi->mode_flags = device->mode_flags;
dsi->panel = of_drm_find_panel(device->dev.of_node);
if (dsi->panel)
return drm_panel_attach(dsi->panel, >connector);
@@ -713,7 +710,12 @@ static void dw_mipi_dsi_video_mode_config(struct 
dw_mipi_dsi *dsi)
  {
u32 val;
  
-	val = VID_MODE_TYPE_BURST_SYNC_PULSES | ENABLE_LOW_POWER;

+   val = ENABLE_LOW_POWER;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+   val |= VID_MODE_TYPE_BURST_SYNC_PULSES;
+   else if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
+   val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
  
  	dsi_write(dsi, DSI_VID_MODE_CFG, val);

  }

Re: [PATCH v2 24/26] drm/rockchip: dw-mipi-dsi: support non-burst modes

[Chris Zhong]

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +---
  1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 2dafb17e31d2..881bb0c62ca5 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -82,6 +82,7 @@
  #define FRAME_BTA_ACK BIT(14)
  #define ENABLE_LOW_POWER  (0x3f << 8)
  #define ENABLE_LOW_POWER_MASK (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
  #define VID_MODE_TYPE_BURST_SYNC_PULSES   0x2
  #define VID_MODE_TYPE_MASK0x3
  
@@ -286,6 +287,7 @@ struct dw_mipi_dsi {

u32 format;
u16 input_div;
u16 feedback_div;
+   unsigned long mode_flags;
  
  	const struct dw_mipi_dsi_plat_data *pdata;

  };
@@ -548,15 +550,10 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
return -EINVAL;
}
  
-	if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ||

-   !(device->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)) {
-   dev_err(dsi->dev, "device mode is unsupported\n");
-   return -EINVAL;
-   }
-
dsi->lanes = device->lanes;
dsi->channel = device->channel;
dsi->format = device->format;
+   dsi->mode_flags = device->mode_flags;
dsi->panel = of_drm_find_panel(device->dev.of_node);
if (dsi->panel)
return drm_panel_attach(dsi->panel, >connector);
@@ -713,7 +710,12 @@ static void dw_mipi_dsi_video_mode_config(struct 
dw_mipi_dsi *dsi)
  {
u32 val;
  
-	val = VID_MODE_TYPE_BURST_SYNC_PULSES | ENABLE_LOW_POWER;

+   val = ENABLE_LOW_POWER;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+   val |= VID_MODE_TYPE_BURST_SYNC_PULSES;
+   else if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
+   val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
  
  	dsi_write(dsi, DSI_VID_MODE_CFG, val);

  }

Re: [PATCH v3] zram: extend zero pages to same element pages

[Joonsoo Kim]

On Mon, Jan 23, 2017 at 01:47:20PM +0900, Minchan Kim wrote:
> Hello,
> 
> When I look at first patch, I wanted to use increment loop but didn't
> tell to you because that small piece of code is no harmful for readbility
> to me so I want to keep author's code rather than pointing the trivial
> which is just matter of preference out.
> 
> Rather than readiblity, I suspect it might hurt performance and talked
> with Namhyung but we cannot find anything decremental loop is bad
> compared to incremental. Rather than, many articles have been said
> decrement loop is faster like zhouxianrong's mentiond although I don't
> think it makes marginal difference.
> 
> Joonsoo, why do you think incremental is faster?
> zhouxianrong, why do you think decrement loops makes cache problem?
> 
> I'm okay either way. Just want to know why you guys think about it.

Hmm... I guess that cache prefetcher works better for forward access
but I'm not sure.

Thanks.

Re: [PATCH v3] zram: extend zero pages to same element pages

[Joonsoo Kim]

On Mon, Jan 23, 2017 at 01:47:20PM +0900, Minchan Kim wrote:
> Hello,
> 
> When I look at first patch, I wanted to use increment loop but didn't
> tell to you because that small piece of code is no harmful for readbility
> to me so I want to keep author's code rather than pointing the trivial
> which is just matter of preference out.
> 
> Rather than readiblity, I suspect it might hurt performance and talked
> with Namhyung but we cannot find anything decremental loop is bad
> compared to incremental. Rather than, many articles have been said
> decrement loop is faster like zhouxianrong's mentiond although I don't
> think it makes marginal difference.
> 
> Joonsoo, why do you think incremental is faster?
> zhouxianrong, why do you think decrement loops makes cache problem?
> 
> I'm okay either way. Just want to know why you guys think about it.

Hmm... I guess that cache prefetcher works better for forward access
but I'm not sure.

Thanks.