[PATCHv5 0/9] x86: 5-level paging enabling for v4.12, Part 4

[Kirill A. Shutemov]

Here's updated version the fourth and the last bunch of of patches that brings
initial 5-level paging enabling.

Please review and consider applying.

v5:
 - Fix KASLR bug due to rewriting rewriting startup_64() in C.

Kirill A. Shutemov (9):
  x86/asm: Fix comment in return_from_SYSCALL_64
  x86/boot/64: Rewrite startup_64 in C
  x86/boot/64: Rename init_level4_pgt and early_level4_pgt
  x86/boot/64: Add support of additional page table level during early
boot
  x86/mm: Add sync_global_pgds() for configuration with 5-level paging
  x86/mm: Make kernel_physical_mapping_init() support 5-level paging
  x86/mm: Add support for 5-level paging for KASLR
  x86: Enable 5-level paging support
  x86/mm: Allow to have userspace mappings above 47-bits

 arch/x86/Kconfig|   5 +
 arch/x86/boot/compressed/head_64.S  |  23 -
 arch/x86/entry/entry_64.S   |   3 +-
 arch/x86/include/asm/elf.h  |   4 +-
 arch/x86/include/asm/mpx.h  |   9 ++
 arch/x86/include/asm/pgtable.h  |   2 +-
 arch/x86/include/asm/pgtable_64.h   |   6 +-
 arch/x86/include/asm/processor.h|  11 ++-
 arch/x86/include/uapi/asm/processor-flags.h |   2 +
 arch/x86/kernel/espfix_64.c |   2 +-
 arch/x86/kernel/head64.c| 143 +---
 arch/x86/kernel/head_64.S   | 134 ++
 arch/x86/kernel/machine_kexec_64.c  |   2 +-
 arch/x86/kernel/sys_x86_64.c|  30 +-
 arch/x86/mm/dump_pagetables.c   |   2 +-
 arch/x86/mm/hugetlbpage.c   |  27 +-
 arch/x86/mm/init_64.c   | 104 ++--
 arch/x86/mm/kasan_init_64.c |  12 +--
 arch/x86/mm/kaslr.c |  81 
 arch/x86/mm/mmap.c  |   6 +-
 arch/x86/mm/mpx.c   |  33 ++-
 arch/x86/realmode/init.c|   2 +-
 arch/x86/xen/Kconfig|   1 +
 arch/x86/xen/mmu.c  |  18 ++--
 arch/x86/xen/xen-pvh.S  |   2 +-
 25 files changed, 476 insertions(+), 188 deletions(-)

-- 
2.11.0

[PATCHv5 5/9] x86/mm: Add sync_global_pgds() for configuration with 5-level paging

[Kirill A. Shutemov]

This basically restores slightly modified version of original
sync_global_pgds() which we had before folded p4d was introduced.

The only modification is protection against 'address' overflow.

Signed-off-by: Kirill A. Shutemov 
---
 arch/x86/mm/init_64.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index a242139df8fe..0b62b13e8655 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -92,6 +92,40 @@ __setup("noexec32=", nonx32_setup);
  * When memory was added make sure all the processes MM have
  * suitable PGD entries in the local PGD level page.
  */
+#ifdef CONFIG_X86_5LEVEL
+void sync_global_pgds(unsigned long start, unsigned long end)
+{
+   unsigned long address;
+
+   for (address = start; address <= end && address >= start; address += 
PGDIR_SIZE) {
+   const pgd_t *pgd_ref = pgd_offset_k(address);
+   struct page *page;
+
+   if (pgd_none(*pgd_ref))
+   continue;
+
+   spin_lock(_lock);
+   list_for_each_entry(page, _list, lru) {
+   pgd_t *pgd;
+   spinlock_t *pgt_lock;
+
+   pgd = (pgd_t *)page_address(page) + pgd_index(address);
+   /* the pgt_lock only for Xen */
+   pgt_lock = _page_get_mm(page)->page_table_lock;
+   spin_lock(pgt_lock);
+
+   if (!pgd_none(*pgd_ref) && !pgd_none(*pgd))
+   BUG_ON(pgd_page_vaddr(*pgd) != 
pgd_page_vaddr(*pgd_ref));
+
+   if (pgd_none(*pgd))
+   set_pgd(pgd, *pgd_ref);
+
+   spin_unlock(pgt_lock);
+   }
+   spin_unlock(_lock);
+   }
+}
+#else
 void sync_global_pgds(unsigned long start, unsigned long end)
 {
unsigned long address;
@@ -135,6 +169,7 @@ void sync_global_pgds(unsigned long start, unsigned long 
end)
spin_unlock(_lock);
}
 }
+#endif
 
 /*
  * NOTE: This function is marked __ref because it calls __init function
-- 
2.11.0

[PATCH v2 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC

[sean.wang]

From: Sean Wang 

This patchset introduces support for Mediatek hardware random generator (RNG)
Currently, the driver is already tested successfully with rng-tools on MT7623
SoC. And it should also be workable on other similar Mediatek SoCs.

Changes since v1:
- remove unnecessary warning message
- remove mistakenly changed line
- refine macro definition with keeping one space between name and define
- remove redundant platform_get_resource() call

Sean Wang (2):
  dt-bindings: hwrng: Add Mediatek hardware random generator bindings
  hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

 Documentation/devicetree/bindings/rng/mtk-rng.txt |  18 +++
 drivers/char/hw_random/Kconfig|  14 ++
 drivers/char/hw_random/Makefile   |   1 +
 drivers/char/hw_random/mtk-rng.c  | 168 ++
 4 files changed, 201 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
 create mode 100644 drivers/char/hw_random/mtk-rng.c

-- 
1.9.1

[PATCH v2 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings

[sean.wang]

From: Sean Wang 

Document the devicetree bindings for Mediatek random number
generator which could be found on MT7623 SoC or other similar
Mediatek SoCs.

Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt 
b/Documentation/devicetree/bindings/rng/mtk-rng.txt
new file mode 100644
index 000..a6d62a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for Mediatek random number generator
+found in Mediatek SoC family
+
+Required properties:
+- compatible   : Should be "mediatek,mt7623-rng"
+- clocks   : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names  : Should contain "rng" entries;
+- reg  : Specifies base physical address and size of the registers
+
+Example:
+
+rng: rng@1020f000 {
+   compatible = "mediatek,mt7623-rng";
+   reg = <0 0x1020f000 0 0x1000>;
+   clocks = < CLK_INFRA_TRNG>;
+   clock-names = "rng";
+};
-- 
1.9.1

[PATCHv5 2/9] x86/boot/64: Rewrite startup_64 in C

[Kirill A. Shutemov]

The patch write most of startup_64 logic in C.

This is preparation for 5-level paging enabling.

Signed-off-by: Kirill A. Shutemov 
---
 arch/x86/kernel/head64.c  | 85 +-
 arch/x86/kernel/head_64.S | 95 ++-
 2 files changed, 87 insertions(+), 93 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 43b7002f44fb..b59c550b1d3a 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -35,9 +35,92 @@
  */
 extern pgd_t early_level4_pgt[PTRS_PER_PGD];
 extern pmd_t early_dynamic_pgts[EARLY_DYNAMIC_PAGE_TABLES][PTRS_PER_PMD];
-static unsigned int __initdata next_early_pgt = 2;
+static unsigned int __initdata next_early_pgt;
 pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL | _PAGE_NX);
 
+static void __init *fixup_pointer(void *ptr, unsigned long physaddr)
+{
+   return ptr - (void *)_text + (void *)physaddr;
+}
+
+void __init __startup_64(unsigned long physaddr)
+{
+   unsigned long load_delta, *p;
+   pgdval_t *pgd;
+   pudval_t *pud;
+   pmdval_t *pmd, pmd_entry;
+   int i;
+
+   /* Is the address too large? */
+   if (physaddr >> MAX_PHYSMEM_BITS)
+   for (;;);
+
+   /*
+* Compute the delta between the address I am compiled to run at
+* and the address I am actually running at.
+*/
+   load_delta = physaddr - (unsigned long)(_text - __START_KERNEL_map);
+
+   /* Is the address not 2M aligned? */
+   if (load_delta & ~PMD_PAGE_MASK)
+   for (;;);
+
+   /* Fixup the physical addresses in the page table */
+
+   pgd = fixup_pointer(_level4_pgt, physaddr);
+   pgd[pgd_index(__START_KERNEL_map)] += load_delta;
+
+   pud = fixup_pointer(_kernel_pgt, physaddr);
+   pud[510] += load_delta;
+   pud[511] += load_delta;
+
+   pmd = fixup_pointer(level2_fixmap_pgt, physaddr);
+   pmd[506] += load_delta;
+
+   /*
+* Set up the identity mapping for the switchover.  These
+* entries should *NOT* have the global bit set!  This also
+* creates a bunch of nonsense entries but that is fine --
+* it avoids problems around wraparound.
+*/
+
+   pud = fixup_pointer(early_dynamic_pgts[next_early_pgt++], physaddr);
+   pmd = fixup_pointer(early_dynamic_pgts[next_early_pgt++], physaddr);
+
+   i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
+   pgd[i + 0] = (pgdval_t)pud + _KERNPG_TABLE;
+   pgd[i + 1] = (pgdval_t)pud + _KERNPG_TABLE;
+
+   i = (physaddr >> PUD_SHIFT) % PTRS_PER_PUD;
+   pud[i + 0] = (pudval_t)pmd + _KERNPG_TABLE;
+   pud[i + 1] = (pudval_t)pmd + _KERNPG_TABLE;
+
+   pmd_entry = __PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL;
+   pmd_entry +=  physaddr;
+
+   for (i = 0; i < DIV_ROUND_UP(_end - _text, PMD_SIZE); i++) {
+   int idx = i + (physaddr >> PMD_SHIFT) % PTRS_PER_PMD;
+   pmd[idx] = pmd_entry + i * PMD_SIZE;
+   }
+
+   /*
+* Fixup the kernel text+data virtual addresses. Note that
+* we might write invalid pmds, when the kernel is relocated
+* cleanup_highmap() fixes this up along with the mappings
+* beyond _end.
+*/
+
+   pmd = fixup_pointer(level2_kernel_pgt, physaddr);
+   for (i = 0; i < PTRS_PER_PMD; i++) {
+   if (pmd[i] & _PAGE_PRESENT)
+   pmd[i] += load_delta;
+   }
+
+   /* Fixup phys_base */
+   p = fixup_pointer(_base, physaddr);
+   *p += load_delta;
+}
+
 /* Wipe all early page tables except for the kernel symbol map */
 static void __init reset_early_page_tables(void)
 {
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index ac9d327d2e42..1432d530fa35 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -72,100 +72,11 @@ startup_64:
/* Sanitize CPU configuration */
call verify_cpu
 
-   /*
-* Compute the delta between the address I am compiled to run at and the
-* address I am actually running at.
-*/
-   leaq_text(%rip), %rbp
-   subq$_text - __START_KERNEL_map, %rbp
-
-   /* Is the address not 2M aligned? */
-   testl   $~PMD_PAGE_MASK, %ebp
-   jnz bad_address
-
-   /*
-* Is the address too large?
-*/
-   leaq_text(%rip), %rax
-   shrq$MAX_PHYSMEM_BITS, %rax
-   jnz bad_address
-
-   /*
-* Fixup the physical addresses in the page table
-*/
-   addq%rbp, early_level4_pgt + (L4_START_KERNEL*8)(%rip)
-
-   addq%rbp, level3_kernel_pgt + (510*8)(%rip)
-   addq%rbp, level3_kernel_pgt + (511*8)(%rip)
-
-   addq%rbp, level2_fixmap_pgt + (506*8)(%rip)
-
-   /*
-* Set up the identity mapping for the switchover.  These
-* entries should *NOT* have the global bit set!  

Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support

[Dan Williams]

On Mon, Apr 17, 2017 at 12:09 PM, Dan Williams  wrote:
> Allocate a dax_device to represent the capacity of a device-mapper
> instance. Provide a ->direct_access() method via the new dax_operations
> indirection that mirrors the functionality of the current direct_access
> support via block_device_operations.  Once fs/dax.c has been converted
> to use dax_operations the old dm_blk_direct_access() will be removed.
>
> A new helper dm_dax_get_live_target() is introduced to separate some of
> the dm-specifics from the direct_access implementation.
>
> This enabling is only for the top-level dm representation to upper
> layers. Converting target direct_access implementations is deferred to a
> separate patch.
>
> Cc: Toshi Kani 
> Cc: Mike Snitzer 

Hi Mike,

Any concerns with these dax_device and dax_operations changes to
device-mapper for the upcoming merge window?


> Signed-off-by: Dan Williams 
> ---
>  drivers/md/Kconfig|1
>  drivers/md/dm-core.h  |1
>  drivers/md/dm.c   |   84 
> ++---
>  include/linux/device-mapper.h |1
>  4 files changed, 73 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index b7767da50c26..1de8372d9459 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -200,6 +200,7 @@ config BLK_DEV_DM_BUILTIN
>  config BLK_DEV_DM
> tristate "Device mapper support"
> select BLK_DEV_DM_BUILTIN
> +   select DAX
> ---help---
>   Device-mapper is a low level volume manager.  It works by allowing
>   people to specify mappings for ranges of logical sectors.  Various
> diff --git a/drivers/md/dm-core.h b/drivers/md/dm-core.h
> index 136fda3ff9e5..538630190f66 100644
> --- a/drivers/md/dm-core.h
> +++ b/drivers/md/dm-core.h
> @@ -58,6 +58,7 @@ struct mapped_device {
> struct target_type *immutable_target_type;
>
> struct gendisk *disk;
> +   struct dax_device *dax_dev;
> char name[16];
>
> void *interface_ptr;
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index dfb75979e455..bd56dfe43a99 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -908,31 +909,68 @@ int dm_set_target_max_io_len(struct dm_target *ti, 
> sector_t len)
>  }
>  EXPORT_SYMBOL_GPL(dm_set_target_max_io_len);
>
> -static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
> -void **kaddr, pfn_t *pfn, long size)
> +static struct dm_target *dm_dax_get_live_target(struct mapped_device *md,
> +   sector_t sector, int *srcu_idx)
>  {
> -   struct mapped_device *md = bdev->bd_disk->private_data;
> struct dm_table *map;
> struct dm_target *ti;
> -   int srcu_idx;
> -   long len, ret = -EIO;
>
> -   map = dm_get_live_table(md, _idx);
> +   map = dm_get_live_table(md, srcu_idx);
> if (!map)
> -   goto out;
> +   return NULL;
>
> ti = dm_table_find_target(map, sector);
> if (!dm_target_is_valid(ti))
> -   goto out;
> +   return NULL;
>
> -   len = max_io_len(sector, ti) << SECTOR_SHIFT;
> -   size = min(len, size);
> +   return ti;
> +}
>
> -   if (ti->type->direct_access)
> -   ret = ti->type->direct_access(ti, sector, kaddr, pfn, size);
> -out:
> +static long dm_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
> +   long nr_pages, void **kaddr, pfn_t *pfn)
> +{
> +   struct mapped_device *md = dax_get_private(dax_dev);
> +   sector_t sector = pgoff * PAGE_SECTORS;
> +   struct dm_target *ti;
> +   long len, ret = -EIO;
> +   int srcu_idx;
> +
> +   ti = dm_dax_get_live_target(md, sector, _idx);
> +
> +   if (!ti)
> +   goto out;
> +   if (!ti->type->direct_access)
> +   goto out;
> +   len = max_io_len(sector, ti) / PAGE_SECTORS;
> +   if (len < 1)
> +   goto out;
> +   nr_pages = min(len, nr_pages);
> +   if (ti->type->direct_access) {
> +   ret = ti->type->direct_access(ti, sector, kaddr, pfn,
> +   nr_pages * PAGE_SIZE);
> +   /*
> +* FIXME: convert ti->type->direct_access to return
> +* nr_pages directly.
> +*/
> +   if (ret >= 0)
> +   ret /= PAGE_SIZE;
> +   }
> + out:
> dm_put_live_table(md, srcu_idx);
> -   return min(ret, size);
> +
> +   return ret;
> +}
> +
> +static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
> +   void **kaddr, pfn_t *pfn, long size)
> +{
> +   struct mapped_device *md = bdev->bd_disk->private_data;
> 

[PATCH v4 4/6] mtd: dataflash: Get rid of loop counter in jedec_probe()

[Andrey Smirnov]

"For" loop in jedec_probe can be simplified to not need counter
'i'. Convert the code and get rid of the variable.

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

Changes since [v3]

- Collected Reviewed-by from Marek

Not present in v2, v1

[v3] http://lkml.kernel.org/r/20170419152305.17226-4-andrew.smir...@gmail.com

 drivers/mtd/devices/mtd_dataflash.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index ccd1e02..2d3e403 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -736,7 +736,7 @@ static struct flash_info dataflash_data[] = {
 
 static struct flash_info *jedec_probe(struct spi_device *spi)
 {
-   int ret, i;
+   int ret;
u8 code = OP_READ_ID;
u8 id[3];
u32 jedec;
@@ -767,9 +767,9 @@ static struct flash_info *jedec_probe(struct spi_device 
*spi)
jedec = jedec << 8;
jedec |= id[2];
 
-   for (i = 0, info = dataflash_data;
-   i < ARRAY_SIZE(dataflash_data);
-   i++, info++) {
+   for (info = dataflash_data;
+info < dataflash_data + ARRAY_SIZE(dataflash_data);
+info++) {
if (info->jedec_id == jedec) {
dev_dbg(>dev, "OTP, sector protect%s\n",
(info->flags & SUP_POW2PS) ?
-- 
2.9.3

Re: [PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Arnd Bergmann]

On Wed, Apr 19, 2017 at 11:06 PM, Hans Verkuil  wrote:
> On 19/04/17 18:59, Arnd Bergmann wrote:
>> When the media subsystem is built as a loadable module, a built-in

>> This adds a Kconfig dependency to enforce the HDMI driver to also
>> be a loadable module in this case.
>
> I've marked this patch and the exynos_hdmi patch as 'Obsoleted' in patchwork:
> today several CEC Kconfig cleanup patches were merged that invalidate these
> two patches. I expect they'll turn up soon in -next.

I can confirm that the previous problems are fixed with today's linux-next,
but I have now run into another problem, with CONFIG_INPUT=m forcing
CONFIG_RC_CORE=m:

drivers/media/cec/cec-core.o: In function `cec_unregister_adapter':
cec-core.c:(.text.cec_unregister_adapter+0x18): undefined reference to
`rc_unregister_device'
drivers/media/cec/cec-core.o: In function `cec_delete_adapter':
cec-core.c:(.text.cec_delete_adapter+0x54): undefined reference to
`rc_free_device'
drivers/media/cec/cec-core.o: In function `cec_register_adapter':
cec-core.c:(.text.cec_register_adapter+0x94): undefined reference to
`rc_register_device'
cec-core.c:(.text.cec_register_adapter+0xa4): undefined reference to
`rc_free_device'
cec-core.c:(.text.cec_register_adapter+0x110): undefined reference to
`rc_unregister_device'
drivers/media/cec/cec-core.o: In function `cec_allocate_adapter':
cec-core.c:(.text.cec_allocate_adapter+0x234): undefined reference to
`rc_allocate_device'
drivers/media/cec/cec-adap.o: In function `cec_received_msg':
cec-adap.c:(.text.cec_received_msg+0x734): undefined reference to `rc_keydown'
cec-adap.c:(.text.cec_received_msg+0x768): undefined reference to `rc_keyup'
/git/arm-soc/Makefile:1033: recipe for target 'vmlinux' failed

I don't see an obvious fix for  this, and as you seem to have a good grip on the
problem already, I'll let you figure out how to best address it.

   Arnd

Re: [PATCH] MAINTAINERS: Add bugzilla and documentation entites for kselftest, usbip

[Greg KH]

On Thu, Apr 20, 2017 at 09:50:10AM -0600, Shuah Khan wrote:
> @@ -13033,6 +13035,8 @@ M:Valentina Manea 
>  M:   Shuah Khan 
>  M:   Shuah Khan 
>  L:   linux-...@vger.kernel.org
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> +B:   https://bugzilla.kernel.org
>  S:   Maintained
>  F:   Documentation/usb/usbip_protocol.txt
>  F:   drivers/usb/usbip/

I don't like USB bugs in bugzilla at all, how are you going to separate
the usbip bugs out from the rest of the usb bugs there?

thanks,

greg k-h

Re: [PATCH 1/2] clk: ti: divider: try to fix ti_clk_register_divider

[Tero Kristo]

On 19/04/17 20:44, Arnd Bergmann wrote:

The newly introduced function is entirely bogus as I found when looking
at this warning:

drivers/clk/ti/divider.c: In function 'ti_clk_register_divider':
drivers/clk/ti/divider.c:460:8: error: 'reg' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

Treating a 'u32' variable as a structure leads to a stack overflow here,
and the register address we pass down is never initialized.

As the code in its original form makes no sense, I can only guess what
the intention was, and change it to take the address from div->reg.ptr
instead.


Actually, I believe the code you are fixing works before this commit:

commit 6c0afb503937a12a8d20a805fcf263e31afa9871
Author: Tero Kristo 
Date:   Thu Feb 9 11:24:37 2017 +0200

clk: ti: convert to use proper register definition for all accesses


... it attempted to convert all the register accesses to the new format 
and change the size of the clk_omap_reg in bulk but I missed converting 
this one. Previously the size of the clk_omap_reg definition was u32, 
but this was confusing and bug prone so I changed it.


The failing piece of code is only executed for legacy boot mode OMAP3 
right now, which could be potentially stripped out of the kernel already 
(I think Tony removed the support for non-DT boot OMAP3 boards 
already...?) This explains why I didn't notice the issue in my local 
testing either.




Fixes: d96f774b2538 ("clk: ti: divider: add support for legacy divider init")
Signed-off-by: Arnd Bergmann 


So, this patch itself is fine, but the desc should be updated to reflect 
the above somehow.


And the "Fixes:" line should be updated to point to the commit mentioned 
above also.


-Tero


---
 drivers/clk/ti/divider.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index d6dcb283b72b..a6d3bbfbbd31 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -428,22 +428,17 @@ struct clk_hw *ti_clk_build_component_div(struct 
ti_clk_divider *setup)

 struct clk *ti_clk_register_divider(struct ti_clk *setup)
 {
-   struct ti_clk_divider *div;
-   struct clk_omap_reg *reg_setup;
-   u32 reg;
+   struct ti_clk_divider *div = setup->data;
+   struct clk_omap_reg reg_setup = {
+   .index = div->module,
+   .offset = div->reg,
+   };


reg_setup here could be just named as 'reg' as I've done elsewhere.

-Tero


u8 width;
u32 flags = 0;
u8 div_flags = 0;
const struct clk_div_table *table;
struct clk *clk;

-   div = setup->data;
-
-   reg_setup = (struct clk_omap_reg *)
-
-   reg_setup->index = div->module;
-   reg_setup->offset = div->reg;
-
if (div->flags & CLKF_INDEX_STARTS_AT_ONE)
div_flags |= CLK_DIVIDER_ONE_BASED;

@@ -458,7 +453,7 @@ struct clk *ti_clk_register_divider(struct ti_clk *setup)
return (struct clk *)table;

clk = _register_divider(NULL, setup->name, div->parent,
-   flags, (void __iomem *)reg, div->bit_shift,
+   flags, _setup, div->bit_shift,
width, div_flags, table);

if (IS_ERR(clk))

[PATCH] MAINTAINERS: Add bugzilla and documentation entites for kselftest, usbip

[Shuah Khan]

Update Kselftest and USB IP sections to add Bugzilla and documentation
section entries. Also add git entry to USB IP.

Signed-off-by: Shuah Khan 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdd5350..a367f31 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7127,8 +7127,10 @@ M:   Shuah Khan 
 M: Shuah Khan 
 L: linux-kselft...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/shuah/linux-kselftest
+B: https://bugzilla.kernel.org
 S: Maintained
 F: tools/testing/selftests
+F: Documentation/kselftest.txt
 
 KERNEL VIRTUAL MACHINE (KVM)
 M: Paolo Bonzini 
@@ -13033,6 +13035,8 @@ M:  Valentina Manea 
 M: Shuah Khan 
 M: Shuah Khan 
 L: linux-...@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
+B: https://bugzilla.kernel.org
 S: Maintained
 F: Documentation/usb/usbip_protocol.txt
 F: drivers/usb/usbip/
-- 
2.9.3

Re: [PATCH v4 1/1] pwm: pca9685: fix gpio-only operation.

[Sven Van Asbroeck]

> Thus, I would suggest: int sleep -> bool enable (or alike).
>
> Would we agree on that?

I would. Perhaps also:
set_sleep_mode(int sleep) -> enable_sleep_mode(bool enable) ?

Let's see what Mika and Thierry think.

Re: [PATCH v3 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board

[Krzysztof Kozlowski]

On Tue, Apr 18, 2017 at 05:40:36PM +0900, Hoegeun Kwon wrote:
> This patch add the panel device tree node for s6e3hf2 display
> controller to TM2e dts.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 +++
>  1 file changed, 11 insertions(+)

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH 2/6] locking: Introduce range reader/writer lock

[Davidlohr Bueso]

On Tue, 18 Apr 2017, Laurent Dufour wrote:


On 06/04/2017 10:46, Davidlohr Bueso wrote:

+__range_read_lock_common(struct range_rwlock_tree *tree,
+struct range_rwlock *lock, long state)
+{
+   struct interval_tree_node *node;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   range_lock_set_reader(lock);
+
+   if (!__range_intersects_intree(tree, lock))
+   goto insert;
+
+   range_interval_tree_foreach(node, >root,
+   lock->node.start, lock->node.last) {
+   struct range_rwlock *blocked_lock;
+   blocked_lock = range_entry(node, struct range_rwlock, node);
+
+   if (!range_lock_is_reader(blocked_lock))
+   lock->blocking_ranges++;
+   }
+insert:
+   __range_tree_insert(tree, lock);
+
+   lock->waiter = current;


Hi Davidlohr,

Setting lock->waiter after calling range_lock_set_reader() is resetting
the reader flag. Moving the call to range_lock_set_reader() here fixes that.


Yeah, I moved the set_reader() call to after setting lock->waiter.




+   spin_unlock_irqrestore(>lock, flags);
+
+   return wait_for_ranges(tree, lock, state);
+}


[...]


+int range_read_trylock(struct range_rwlock_tree *tree, struct range_rwlock 
*lock)
+{
+   int ret = true;
+   unsigned long flags;
+   struct interval_tree_node *node;
+
+   spin_lock_irqsave(>lock, flags);
+
+   if (!__range_intersects_intree(tree, lock))
+   goto insert;
+
+   /*
+* We have overlapping ranges in the tree, ensure that we can
+* in fact share the lock.
+*/
+   range_interval_tree_foreach(node, >root,
+   lock->node.start, lock->node.last) {
+   struct range_rwlock *blocked_lock;
+   blocked_lock = range_entry(node, struct range_rwlock, node);
+
+   if (!range_lock_is_reader(blocked_lock)) {
+   ret = false;
+   goto unlock;
+   }
+   }
+insert:
+   range_lock_set_reader(lock);


Here, the lock->waiter field should have been set to current before
calling range_lock_set_reader()


But this is a trylock attempt, there is no waiting going on.

Thanks,
Davidlohr

Re: [PATCH] coresight: tmc: minor fix for output log

[Mathieu Poirier]

On 7 April 2017 at 09:22, Leo Yan  wrote:
> In current code the output logs are not well symmetric for sink and link
> enabling and disabling. This patch is to fix that so can output paired
> logs.
>
> Cc: Mathieu Poirier 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/coresight-tmc-etf.c | 25 
> +
>  1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 1549436..3a1c181 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -166,9 +166,6 @@ static int tmc_enable_etf_sink_sysfs(struct 
> coresight_device *csdev)
> if (!used)
> kfree(buf);
>
> -   if (!ret)
> -   dev_info(drvdata->dev, "TMC-ETB/ETF enabled\n");
> -
> return ret;
>  }
>
> @@ -204,15 +201,27 @@ static int tmc_enable_etf_sink_perf(struct 
> coresight_device *csdev)
>
>  static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
>  {
> +   int ret;
> +   struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +
> switch (mode) {
> case CS_MODE_SYSFS:
> -   return tmc_enable_etf_sink_sysfs(csdev);
> +   ret = tmc_enable_etf_sink_sysfs(csdev);
> +   break;
> case CS_MODE_PERF:
> -   return tmc_enable_etf_sink_perf(csdev);
> +   ret = tmc_enable_etf_sink_perf(csdev);
> +   break;
> +   /* We shouldn't be here */
> +   default:
> +   ret = -EINVAL;
> +   break;
> }
>
> -   /* We shouldn't be here */
> -   return -EINVAL;
> +   if (ret)
> +   return ret;
> +
> +   dev_info(drvdata->dev, "TMC-ETB/ETF enabled\n");
> +   return 0;
>  }
>
>  static void tmc_disable_etf_sink(struct coresight_device *csdev)
> @@ -273,7 +282,7 @@ static void tmc_disable_etf_link(struct coresight_device 
> *csdev,
> drvdata->mode = CS_MODE_DISABLED;
> spin_unlock_irqrestore(>spinlock, flags);
>
> -   dev_info(drvdata->dev, "TMC disabled\n");
> +   dev_info(drvdata->dev, "TMC-ETF disabled\n");
>  }
>

Applied - thanks.
Mathieu

>  static void *tmc_alloc_etf_buffer(struct coresight_device *csdev, int cpu,
> --
> 2.7.4
>

[PATCH v4 2/8] [media] stm32-dcmi: STM32 DCMI camera interface driver

[Hugues Fruchet]

This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI)
of STMicroelectronics STM32 SoC series.

Reviewed-by: Hans Verkuil 
Signed-off-by: Yannick Fertre 
Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig|   12 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/stm32/Makefile |1 +
 drivers/media/platform/stm32/stm32-dcmi.c | 1419 +
 4 files changed, 1434 insertions(+)
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..de6e18b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -114,6 +114,18 @@ config VIDEO_S3C_CAMIF
  To compile this driver as a module, choose M here: the module
  will be called s3c-camif.
 
+config VIDEO_STM32_DCMI
+   tristate "Digital Camera Memory Interface (DCMI) support"
+   depends on VIDEO_V4L2 && OF && HAS_DMA
+   depends on ARCH_STM32 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This module makes the STM32 Digital Camera Memory Interface (DCMI)
+ available as a v4l2 device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called stm32-dcmi.
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..231f3c2 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,6 +68,8 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)  += rcar-vin/
 obj-$(CONFIG_VIDEO_ATMEL_ISC)  += atmel/
 obj-$(CONFIG_VIDEO_ATMEL_ISI)  += atmel/
 
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/stm32/Makefile 
b/drivers/media/platform/stm32/Makefile
new file mode 100644
index 000..9b606a7
--- /dev/null
+++ b/drivers/media/platform/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32-dcmi.o
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c 
b/drivers/media/platform/stm32/stm32-dcmi.c
new file mode 100644
index 000..0ed3bd9
--- /dev/null
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -0,0 +1,1419 @@
+/*
+ * Driver for STM32 Digital Camera Memory Interface
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Authors: Yannick Fertre 
+ *  Hugues Fruchet 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * This driver is based on atmel_isi.c
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "stm32-dcmi"
+
+/* Registers offset for DCMI */
+#define DCMI_CR0x00 /* Control Register */
+#define DCMI_SR0x04 /* Status Register */
+#define DCMI_RIS   0x08 /* Raw Interrupt Status register */
+#define DCMI_IER   0x0C /* Interrupt Enable Register */
+#define DCMI_MIS   0x10 /* Masked Interrupt Status register */
+#define DCMI_ICR   0x14 /* Interrupt Clear Register */
+#define DCMI_ESCR  0x18 /* Embedded Synchronization Code Register */
+#define DCMI_ESUR  0x1C /* Embedded Synchronization Unmask Register */
+#define DCMI_CWSTRT0x20 /* Crop Window STaRT */
+#define DCMI_CWSIZE0x24 /* Crop Window SIZE */
+#define DCMI_DR0x28 /* Data Register */
+#define DCMI_IDR   0x2C /* IDentifier Register */
+
+/* Bits definition for control register (DCMI_CR) */
+#define CR_CAPTURE BIT(0)
+#define CR_CM  BIT(1)
+#define CR_CROPBIT(2)
+#define CR_JPEGBIT(3)
+#define CR_ESS BIT(4)
+#define CR_PCKPOL  BIT(5)
+#define CR_HSPOL   BIT(6)
+#define CR_VSPOL   BIT(7)
+#define CR_FCRC_0  BIT(8)
+#define CR_FCRC_1  BIT(9)
+#define CR_EDM_0   BIT(10)
+#define CR_EDM_1   BIT(11)
+#define CR_ENABLE  BIT(14)
+
+/* Bits definition for status register (DCMI_SR) */
+#define SR_HSYNC   BIT(0)
+#define SR_VSYNC   BIT(1)
+#define SR_FNE BIT(2)
+
+/*
+ * Bits definition for interrupt registers
+ * (DCMI_RIS, DCMI_IER, DCMI_MIS, DCMI_ICR)
+ */
+#define IT_FRAME   BIT(0)
+#define IT_OVR BIT(1)
+#define IT_ERR BIT(2)
+#define IT_VSYNC   BIT(3)
+#define IT_LINEBIT(4)
+
+enum state {
+   STOPPED = 0,
+   RUNNING,
+   STOPPING,
+};
+
+#define 

Re: [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries

[Krzysztof Kozlowski]

On Thu, Apr 20, 2017 at 04:25:07PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
> 
> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> unit name, but no reg property
> 
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
> 
> Reported-by: Krzysztof Kozlowski 
> Reported-by: Masahiro Yamada 
> Suggested-by: Mark Rutland 
> Signed-off-by: Viresh Kumar 
> Reviewed-by: Chanwoo Choi 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
>  arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
>  arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
>  arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
>  arch/arm/boot/dts/exynos4412.dtsi  | 66 
> +++---
>  arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
>  arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
>  arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
>  9 files changed, 194 insertions(+), 194 deletions(-)


Thanks, split ARM64 from ARM and applied (for v4.12). arm-soc keeps DTS
separated between ARM architectures. Technically this should require a
resend but we had way too many resends for this simple patch.

Best regards,
Krzysztof

[PATCH v4 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

[Hugues Fruchet]

This patchset introduces a basic support for Digital Camera Memory Interface
(DCMI) of STMicroelectronics STM32 SoC series.

This first basic support implements RGB565 & YUV frame grabbing.
Cropping and JPEG support will be added later on.

This has been tested on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.

This driver depends on:
  - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers 
http://www.spinics.net/lists/linux-media/msg113480.html

===
= history =
===
version 4:
  - "v4l2-compliance -s -f" report
  - fix behaviour in case of start_streaming failure (DMA memory shortage for 
ex.)
  - dt-bindings: Fix remarks from Rob Herring:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg111340.html
Add "Acked-by: Rob Herring "

version 3:
  - stm32-dcmi: Add "Reviewed-by: Hans Verkuil "
  - dt-bindings: Fix remarks from Rob Herring:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html

version 2:
  - Fix a Kbuild warning in probe:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html
  - Fix a warning in dcmi_queue_setup()
  - dt-bindings: warn on sensor signals level inversion in board example
  - Typos fixing

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report for this current version of the DCMI camera 
interface.
v4l2-compliance has been built from v4l-utils-1.12.3.

~ # v4l2-compliance -s -f -d /dev/video0
v4l2-compliance SHA   : f5f45e17ee98a0ebad7836ade2b34ceec909d751

Driver Info:
Driver name   : stm32-dcmi
Card type : STM32 Digital Camera Memory Int
Bus info  : platform:dcmi
Driver version: 4.11.0
Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 3 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:

Streaming ioctls:
test read/write: OK
test MMAP: OK 
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device

[PATCH v4 3/8] ARM: dts: stm32: Enable DCMI support on STM32F429 MCU

[Hugues Fruchet]

Enable DCMI camera interface on STM32F429 MCU.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32f429.dtsi | 37 +
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index ee0da97..e1ff978 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -736,6 +736,29 @@
slew-rate = <3>;
};
};
+
+   dcmi_pins: dcmi_pins@0 {
+   pins {
+   pinmux = 
,
+
,
+
,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <3>;
+   };
+   };
};
 
rcc: rcc@40023810 {
@@ -805,6 +828,20 @@
status = "disabled";
};
 
+   dcmi: dcmi@5005 {
+   compatible = "st,stm32-dcmi";
+   reg = <0x5005 0x400>;
+   interrupts = <78>;
+   resets = < STM32F4_AHB2_RESET(DCMI)>;
+   clocks = < 0 STM32F4_AHB2_CLOCK(DCMI)>;
+   clock-names = "mclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dmas = < 1 1 0x414 0x3>;
+   dma-names = "tx";
+   status = "disabled";
+   };
+
rng: rng@50060800 {
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
-- 
1.9.1

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

[Sagi Grimberg]

Hi Jens-

These are just the quirk updates, split out.  The patches are
unchanged.

I think that, even if we want to apply a broader quirk for 4.11, we
should still apply these so that we can cleanly revert the broader
quirk later.  IOW, let's get the known regressions fixed before we
get too excited about the unknown regressions.


This looks good to me, and 4.11 appropriate. I'll expedite this
through the block tree, if Keith/Sagi/Christoph agrees on this
being the right approach for 4.11.


I'm perfectly fine with this going to 4.11

[PATCH v4 5/8] ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL board

[Hugues Fruchet]

Enable STMPE1600 gpio expander of STM32F429-EVAL board.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 617f2f7..2bb8a0f 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -154,6 +154,23 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
status = "okay";
+
+   stmpe1600: stmpe1600@42 {
+   compatible = "st,stmpe1600";
+   reg = <0x42>;
+   irq-gpio = < 8 0>;
+   irq-trigger = <3>;
+   interrupts = <8 3>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   wakeup-source;
+
+   stmpegpio: stmpe_gpio {
+   compatible = "st,stmpe-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
 };
 
  {
-- 
1.9.1

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Peter Zijlstra]

On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote:
> > This is getting ludicrous. Xen is plain broken, and instead of fixing
> > it, you propose to somehow deal with its obviously crack induced
> > behaviour :-(
> 
> Totally agree and I don't like the solution I propose (and that's why
> this is RFC)... The problem is that there are such Xen setups in the
> wild and with the recent changes some guests will BUG() :-(
> 
> Alternatively, we can just remove the BUG() and do something with CPUs
> which have their pkg >= __max_logical_packages, e.g. assign them to the
> last package. Far from ideal but will help to avoid the regression.

So currently none of the stuff that uses this should appear in Xen. Its
all drivers for hardware that isn't virtualized (afaik). So assigning to
the last package 'works'.

But the moment this ends up getting used that explodes, because we'll
need different object instances for each piece of hardware.

There just isn't a good solution; on the one hand the BIOS is prone to
providing crap numbers, on the other hand virt (esp. Xen as it turns
out) provides absolutely bonkers/inconsistent topology information.

Very frustrating :-/

[PATCH v2 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[sean.wang]

From: Sean Wang 

This patch adds support for hardware random generator on MT7623 SoC
and should also work on other similar Mediatek SoCs. Currently,
the driver is already tested successfully with rng-tools.

Signed-off-by: Sean Wang 
Reviewed-by: PrasannaKumar Muralidharan 
---
 drivers/char/hw_random/Kconfig   |  14 
 drivers/char/hw_random/Makefile  |   1 +
 drivers/char/hw_random/mtk-rng.c | 168 +++
 3 files changed, 183 insertions(+)
 create mode 100644 drivers/char/hw_random/mtk-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 0cafe08..df5e7c2 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -423,6 +423,20 @@ config HW_RANDOM_CAVIUM
 
  If unsure, say Y.
 
+config HW_RANDOM_MTK
+   tristate "Mediatek Random Number Generator support"
+   depends on HW_RANDOM
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   default y
+   ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here. the
+ module will be called mtk-rng.
+
+ If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..59eacb7 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
 obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
 obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
 obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
+obj-$(CONFIG_HW_RANDOM_MTK)+= mtk-rng.o
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
new file mode 100644
index 000..df8eb54
--- /dev/null
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -0,0 +1,168 @@
+/*
+ * Driver for Mediatek Hardware Random Number Generator
+ *
+ * Copyright (C) 2017 Sean Wang 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define MTK_RNG_DEV KBUILD_MODNAME
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USEC_POLL  2
+#define TIMEOUT_POLL   20
+
+#define RNG_CTRL   0x00
+#define RNG_EN BIT(0)
+#define RNG_READY  BIT(31)
+
+#define RNG_DATA   0x08
+
+#define to_mtk_rng(p)  container_of(p, struct mtk_rng, rng)
+
+struct mtk_rng {
+   void __iomem *base;
+   struct clk *clk;
+   struct hwrng rng;
+};
+
+static int mtk_rng_init(struct hwrng *rng)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   u32 val;
+   int err;
+
+   err = clk_prepare_enable(priv->clk);
+   if (err)
+   return err;
+
+   val = readl(priv->base + RNG_CTRL);
+   val |= RNG_EN;
+   writel(val, priv->base + RNG_CTRL);
+
+   return 0;
+}
+
+static void mtk_rng_cleanup(struct hwrng *rng)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   u32 val;
+
+   val = readl(priv->base + RNG_CTRL);
+   val &= ~RNG_EN;
+   writel(val, priv->base + RNG_CTRL);
+
+   clk_disable_unprepare(priv->clk);
+}
+
+static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   int ready;
+
+   ready = readl(priv->base + RNG_CTRL) & RNG_READY;
+   if (!ready && wait)
+   readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
+ ready & RNG_READY, USEC_POLL,
+ TIMEOUT_POLL);
+   return !!ready;
+}
+
+static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   int retval = 0;
+
+   while (max >= sizeof(u32)) {
+   if (!mtk_rng_wait_ready(rng, wait))
+   break;
+
+   *(u32 *)buf = readl(priv->base + RNG_DATA);
+   retval += sizeof(u32);
+   buf += sizeof(u32);
+   max -= sizeof(u32);
+   }
+
+   return retval || !wait ? retval : -EIO;
+}
+
+static int mtk_rng_probe(struct platform_device *pdev)
+{
+   struct resource *res;
+   int ret;
+   struct mtk_rng *priv;
+
+   

Re: [PATCH v2 1/3] mmc: dt-bindings: update Mediatek MMC bindings

[Rob Herring]

On Tue, Apr 18, 2017 at 06:13:09PM +0800, Yong Mao wrote:
> From: yong mao 
> 
> Add description for mediatek,clk-pad-delay
> 
> Signed-off-by: Yong Mao 
> Signed-off-by: Chaotian Jing 
> ---
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt |2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

[Jens Axboe]

On 04/20/2017 10:29 AM, Keith Busch wrote:
> On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg wrote:
>>
 Hi Jens-

 These are just the quirk updates, split out.  The patches are
 unchanged.

 I think that, even if we want to apply a broader quirk for 4.11, we
 should still apply these so that we can cleanly revert the broader
 quirk later.  IOW, let's get the known regressions fixed before we
 get too excited about the unknown regressions.
>>>
>>> This looks good to me, and 4.11 appropriate. I'll expedite this
>>> through the block tree, if Keith/Sagi/Christoph agrees on this
>>> being the right approach for 4.11.
>>
>> I'm perfectly fine with this going to 4.11
> 
> All good with me as well.
> 
> Reviewed-by: Keith Busch 

Great, I have queued it up.

-- 
Jens Axboe

[PATCH v4 6/6] mtd: dataflash: Add flash_info for AT45DB641E

[Andrey Smirnov]

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---

Changes since [v3]:

- Update the patch ot use SUP_EXTID

No changes between v3 to v1.

[v3] http://lkml.kernel.org/r/20170419152305.17226-6-andrew.smir...@gmail.com


 drivers/mtd/devices/mtd_dataflash.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 9342cc47..7e6cdfe 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -736,6 +736,9 @@ static struct flash_info dataflash_data[] = {
 
{ "AT45DB642x",  0x1f2800, 8192, 1056, 11, SUP_POW2PS},
{ "at45db642d",  0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
+
+   { "AT45DB641E",  0x1f28000100, 32768, 264, 9, SUP_EXTID | SUP_POW2PS},
+   { "at45db641e",  0x1f28000100, 32768, 256, 8, SUP_EXTID | SUP_POW2PS | 
IS_POW2PS},
 };
 
 static struct flash_info *jedec_lookup(struct spi_device *spi,
-- 
2.9.3

[PATCH v4 5/6] mtd: dataflash: Make use of "extened device information"

[Andrey Smirnov]

In anticipation of supporting chips that need it, extend the size of
struct flash_info's 'jedec_id' field to make room 2 byte of extended
device information as well as add code to fetch this data during
jedec_probe().

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---

Changes since [v3]:

- Convert patch to use SUP_EXTID flag and avoid patching
  dataflash_data table

Changes since [v2]:

- Make 'id' have same size as 'jedec'

- Get rid of eid_mask variable in favour of using GENMASK
  in-place

Changes since [v1]:

- Formatting

[v1] http://lkml.kernel.org/r/20170411161722.11164-1-andrew.smir...@gmail.com
[v2] http://lkml.kernel.org/r/20170418142127.23301-3-andrew.smir...@gmail.com
[v3] http://lkml.kernel.org/r/20170419152305.17226-5-andrew.smir...@gmail.com

 drivers/mtd/devices/mtd_dataflash.c | 88 -
 1 file changed, 57 insertions(+), 31 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 2d3e403..9342cc47 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -84,6 +84,9 @@
 
 #define CFI_MFR_ATMEL  0x1F
 
+#define DATAFLASH_SHIFT_EXTID  24
+#define DATAFLASH_SHIFT_ID 40
+
 struct dataflash {
u8  command[4];
charname[24];
@@ -687,7 +690,7 @@ struct flash_info {
/* JEDEC id has a high byte of zero plus three data bytes:
 * the manufacturer id, then a two byte device id.
 */
-   u32 jedec_id;
+   u64 jedec_id;
 
/* The size listed here is what works with OP_ERASE_PAGE. */
unsignednr_pages;
@@ -695,6 +698,7 @@ struct flash_info {
u16 pageoffset;
 
u16 flags;
+#define SUP_EXTID  BIT(3)
 #define SUP_POW2PS 0x0002  /* supports 2^N byte pages */
 #define IS_POW2PS  0x0001  /* uses 2^N byte pages */
 };
@@ -734,42 +738,18 @@ static struct flash_info dataflash_data[] = {
{ "at45db642d",  0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
 };
 
-static struct flash_info *jedec_probe(struct spi_device *spi)
+static struct flash_info *jedec_lookup(struct spi_device *spi,
+  u64 jedec, bool use_extid)
 {
-   int ret;
-   u8 code = OP_READ_ID;
-   u8 id[3];
-   u32 jedec;
struct flash_info *info;
int status;
 
-   /*
-* JEDEC also defines an optional "extended device information"
-* string for after vendor-specific data, after the three bytes
-* we use here.  Supporting some chips might require using it.
-*
-* If the vendor ID isn't Atmel's (0x1f), assume this call failed.
-* That's not an error; only rev C and newer chips handle it, and
-* only Atmel sells these chips.
-*/
-   ret = spi_write_then_read(spi, , 1, id, 3);
-   if (ret < 0) {
-   dev_dbg(>dev, "error %d reading JEDEC ID\n", ret);
-   return ERR_PTR(ret);
-   }
-
-   if (id[0] != CFI_MFR_ATMEL)
-   return NULL;
-
-   jedec = id[0];
-   jedec = jedec << 8;
-   jedec |= id[1];
-   jedec = jedec << 8;
-   jedec |= id[2];
-
for (info = dataflash_data;
 info < dataflash_data + ARRAY_SIZE(dataflash_data);
 info++) {
+   if (use_extid && !(info->flags & SUP_EXTID))
+   continue;
+
if (info->jedec_id == jedec) {
dev_dbg(>dev, "OTP, sector protect%s\n",
(info->flags & SUP_POW2PS) ?
@@ -793,12 +773,58 @@ static struct flash_info *jedec_probe(struct spi_device 
*spi)
}
}
 
+   return ERR_PTR(-ENODEV);
+}
+
+static struct flash_info *jedec_probe(struct spi_device *spi)
+{
+   int ret;
+   u8 code = OP_READ_ID;
+   u64 jedec;
+   u8 id[sizeof(jedec)] = {0};
+   const unsigned int id_size = 5;
+   struct flash_info *info;
+
+   /*
+* JEDEC also defines an optional "extended device information"
+* string for after vendor-specific data, after the three bytes
+* we use here.  Supporting some chips might require using it.
+*
+* If the vendor ID isn't Atmel's (0x1f), assume this call failed.
+* That's not an error; only rev C and newer chips handle it, and
+* only Atmel sells these chips.
+*/
+   ret = spi_write_then_read(spi, , 1, id, id_size);
+   if (ret < 0) {
+  

[PATCH v4 3/6] mtd: dataflash: Replace pr_debug, printk with dev_* functions

[Andrey Smirnov]

Lion's share of calls to pr_debug in this driver follow the pattern of
pr_debug("%s ", dev_name(), ), which should
be semantically identical to dev_dbg(, "", ),
so replace such occurencies to simplify the code.

Convert the small minority of pr_debug that do not follow pattern from
above to use dev_dbg as well, for the sake of consistency.

Convert similar patter of printk(KERN_ERR, "%s: ...", dev_name(...),
...) to use dev_err instead.

No functional change intended.

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

Changes between since [v3]:

 - Collected Reviewd-by from Marek

Not present in v2, v1

[v3] https://patchwork.ozlabs.org/patch/752332/

 drivers/mtd/devices/mtd_dataflash.c | 74 +
 1 file changed, 33 insertions(+), 41 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 5b7a8c3..ccd1e02 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -130,8 +130,7 @@ static int dataflash_waitready(struct spi_device *spi)
for (;;) {
status = dataflash_status(spi);
if (status < 0) {
-   pr_debug("%s: status %d?\n",
-   dev_name(>dev), status);
+   dev_dbg(>dev, "status %d?\n", status);
status = 0;
}
 
@@ -157,9 +156,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
u8  *command;
u32 rem;
 
-   pr_debug("%s: erase addr=0x%llx len 0x%llx\n",
- dev_name(>dev), (long long)instr->addr,
- (long long)instr->len);
+   dev_dbg(>dev, "erase addr=0x%llx len 0x%llx\n",
+   (long long)instr->addr, (long long)instr->len);
 
div_u64_rem(instr->len, priv->page_size, );
if (rem)
@@ -192,7 +190,7 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
command[2] = (u8)(pageaddr >> 8);
command[3] = 0;
 
-   pr_debug("ERASE %s: (%x) %x %x %x [%i]\n",
+   dev_dbg(>dev, "ERASE %s: (%x) %x %x %x [%i]\n",
do_block ? "block" : "page",
command[0], command[1], command[2], command[3],
pageaddr);
@@ -201,8 +199,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
(void) dataflash_waitready(spi);
 
if (status < 0) {
-   printk(KERN_ERR "%s: erase %x, err %d\n",
-   dev_name(>dev), pageaddr, status);
+   dev_err(>dev, "erase %x, err %d\n",
+   pageaddr, status);
/* REVISIT:  can retry instr->retries times; or
 * giveup and instr->fail_addr = instr->addr;
 */
@@ -243,8 +241,8 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
u8  *command;
int status;
 
-   pr_debug("%s: read 0x%x..0x%x\n", dev_name(>spi->dev),
-   (unsigned)from, (unsigned)(from + len));
+   dev_dbg(>spi->dev, "read 0x%x..0x%x\n",
+ (unsigned int)from, (unsigned int)(from + len));
 
/* Calculate flash page/byte address */
addr = (((unsigned)from / priv->page_size) << priv->page_offset)
@@ -252,7 +250,7 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
 
command = priv->command;
 
-   pr_debug("READ: (%x) %x %x %x\n",
+   dev_dbg(>spi->dev, "READ: (%x) %x %x %x\n",
command[0], command[1], command[2], command[3]);
 
spi_message_init();
@@ -284,8 +282,7 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
*retlen = msg.actual_length - 8;
status = 0;
} else
-   pr_debug("%s: read %x..%x --> %d\n",
-   dev_name(>spi->dev),
+   dev_dbg(>spi->dev, "read %x..%x --> %d\n",
(unsigned)from, (unsigned)(from + len),
status);
return status;
@@ -311,8 +308,8 @@ static int dataflash_write(struct mtd_info *mtd, loff_t to, 
size_t len,
int status = -EINVAL;
u8  *command;
 
-   pr_debug("%s: write 0x%x..0x%x\n",
-   dev_name(>dev), (unsigned)to, (unsigned)(to + 

[PATCH v4 2/6] mtd: dataflash: Improve coding style in jedec_probe()

[Andrey Smirnov]

Change the following:

   - Replace indentation between type and name of local variable from
 tabs to spaces

   - Replace magic number 0x1F with CFI_MFR_ATMEL macro

   - Replace variable 'tmp' with 'ret' and 'i' where appropriate

   - Reformat multi-line comments and add newlines where appropriate

No functional change intended.

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: Marek Vasut 
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

No changes since [v3]

Changes since [v2]:

- Re-worded commit message

- Collected Acked-by from Marek

Not present in v1

[v2] http://lkml.kernel.org/r/20170418142127.23301-2-andrew.smir...@gmail.com
[v3] http://lkml.kernel.org/r/20170419152305.17226-2-andrew.smir...@gmail.com

 drivers/mtd/devices/mtd_dataflash.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index a566231..5b7a8c3 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -82,6 +82,7 @@
 #define OP_WRITE_SECURITY_REVC 0x9A
 #define OP_WRITE_SECURITY  0x9B/* revision D */
 
+#define CFI_MFR_ATMEL  0x1F
 
 struct dataflash {
u8  command[4];
@@ -738,14 +739,15 @@ static struct flash_info dataflash_data[] = {
 
 static struct flash_info *jedec_probe(struct spi_device *spi)
 {
-   int tmp;
-   u8  code = OP_READ_ID;
-   u8  id[3];
-   u32 jedec;
-   struct flash_info   *info;
+   int ret, i;
+   u8 code = OP_READ_ID;
+   u8 id[3];
+   u32 jedec;
+   struct flash_info *info;
int status;
 
-   /* JEDEC also defines an optional "extended device information"
+   /*
+* JEDEC also defines an optional "extended device information"
 * string for after vendor-specific data, after the three bytes
 * we use here.  Supporting some chips might require using it.
 *
@@ -753,13 +755,14 @@ static struct flash_info *jedec_probe(struct spi_device 
*spi)
 * That's not an error; only rev C and newer chips handle it, and
 * only Atmel sells these chips.
 */
-   tmp = spi_write_then_read(spi, , 1, id, 3);
-   if (tmp < 0) {
+   ret = spi_write_then_read(spi, , 1, id, 3);
+   if (ret < 0) {
pr_debug("%s: error %d reading JEDEC ID\n",
-   dev_name(>dev), tmp);
-   return ERR_PTR(tmp);
+   dev_name(>dev), ret);
+   return ERR_PTR(ret);
}
-   if (id[0] != 0x1f)
+
+   if (id[0] != CFI_MFR_ATMEL)
return NULL;
 
jedec = id[0];
@@ -768,9 +771,9 @@ static struct flash_info *jedec_probe(struct spi_device 
*spi)
jedec = jedec << 8;
jedec |= id[2];
 
-   for (tmp = 0, info = dataflash_data;
-   tmp < ARRAY_SIZE(dataflash_data);
-   tmp++, info++) {
+   for (i = 0, info = dataflash_data;
+   i < ARRAY_SIZE(dataflash_data);
+   i++, info++) {
if (info->jedec_id == jedec) {
pr_debug("%s: OTP, sector protect%s\n",
dev_name(>dev),
-- 
2.9.3

[PATCH v4 1/6] mtd: dataflash: Replace C99 types with their kernel counterparts

[Andrey Smirnov]

No functional change intended.

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

No changes since [v3]


Changes since [v2]:

- Re-worded commit message

- Collected Acked-by from Marek

Not present in v1

[v2]: http://lkml.kernel.org/r/20170418142127.23301-1-andrew.smir...@gmail.com
[v3]: http://lkml.kernel.org/r/20170419152305.17226-1-andrew.smir...@gmail.com


 drivers/mtd/devices/mtd_dataflash.c | 40 ++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index f9e9bd1..a566231 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -84,7 +84,7 @@
 
 
 struct dataflash {
-   uint8_t command[4];
+   u8  command[4];
charname[24];
 
unsigned short  page_offset;/* offset in flash address */
@@ -153,8 +153,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
struct spi_transfer x = { };
struct spi_message  msg;
unsignedblocksize = priv->page_size << 3;
-   uint8_t *command;
-   uint32_trem;
+   u8  *command;
+   u32 rem;
 
pr_debug("%s: erase addr=0x%llx len 0x%llx\n",
  dev_name(>dev), (long long)instr->addr,
@@ -187,8 +187,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
pageaddr = pageaddr << priv->page_offset;
 
command[0] = do_block ? OP_ERASE_BLOCK : OP_ERASE_PAGE;
-   command[1] = (uint8_t)(pageaddr >> 16);
-   command[2] = (uint8_t)(pageaddr >> 8);
+   command[1] = (u8)(pageaddr >> 16);
+   command[2] = (u8)(pageaddr >> 8);
command[3] = 0;
 
pr_debug("ERASE %s: (%x) %x %x %x [%i]\n",
@@ -239,7 +239,7 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
struct spi_transfer x[2] = { };
struct spi_message  msg;
unsigned intaddr;
-   uint8_t *command;
+   u8  *command;
int status;
 
pr_debug("%s: read 0x%x..0x%x\n", dev_name(>spi->dev),
@@ -271,9 +271,9 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
 * fewer "don't care" bytes.  Both buffers stay unchanged.
 */
command[0] = OP_READ_CONTINUOUS;
-   command[1] = (uint8_t)(addr >> 16);
-   command[2] = (uint8_t)(addr >> 8);
-   command[3] = (uint8_t)(addr >> 0);
+   command[1] = (u8)(addr >> 16);
+   command[2] = (u8)(addr >> 8);
+   command[3] = (u8)(addr >> 0);
/* plus 4 "don't care" bytes */
 
status = spi_sync(priv->spi, );
@@ -308,7 +308,7 @@ static int dataflash_write(struct mtd_info *mtd, loff_t to, 
size_t len,
size_t  remaining = len;
u_char  *writebuf = (u_char *) buf;
int status = -EINVAL;
-   uint8_t *command;
+   u8  *command;
 
pr_debug("%s: write 0x%x..0x%x\n",
dev_name(>dev), (unsigned)to, (unsigned)(to + len));
@@ -455,11 +455,11 @@ static int dataflash_get_otp_info(struct mtd_info *mtd, 
size_t len,
 }
 
 static ssize_t otp_read(struct spi_device *spi, unsigned base,
-   uint8_t *buf, loff_t off, size_t len)
+   u8 *buf, loff_t off, size_t len)
 {
struct spi_message  m;
size_t  l;
-   uint8_t *scratch;
+   u8  *scratch;
struct spi_transfer t;
int status;
 
@@ -538,7 +538,7 @@ static int dataflash_write_user_otp(struct mtd_info *mtd,
 {
struct spi_message  m;
const size_tl = 4 + 64;
-   uint8_t *scratch;
+   u8  *scratch;
struct spi_transfer t;
struct dataflash*priv = mtd->priv;
int status;
@@ -689,14 +689,14 @@ struct flash_info {
/* JEDEC id has a high byte of zero plus three data bytes:
 * the manufacturer id, then a two byte device id.
 */
-   uint32_tjedec_id;
+   u32 jedec_id;
 
/* The size listed here is what works with OP_ERASE_PAGE. */
unsigned  

Re: [PATCH] drivers, md: convert stripe_head.count from atomic_t to refcount_t

[Shaohua Li]

On Thu, Apr 20, 2017 at 09:15:00AM +, Reshetova, Elena wrote:
> Just a ping on this updated patch. Did you find any new issues or could you 
> please apply it?

sorry, for the dalay. I'm in vacation. Since the stripe_head.count could be 0
(and it's not freed), I assume it should stay as atomic_t.


Thanks,
Shaohua 
> Best Regards,
> Elena.
> 
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> > 
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/md/raid5-cache.c |  8 +++---
> >  drivers/md/raid5.c   | 68 
> > +---
> >  drivers/md/raid5.h   |  3 ++-
> >  3 files changed, 41 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> > index 3f307be..6c05e12 100644
> > --- a/drivers/md/raid5-cache.c
> > +++ b/drivers/md/raid5-cache.c
> > @@ -979,7 +979,7 @@ int r5l_write_stripe(struct r5l_log *log, struct 
> > stripe_head
> > *sh)
> >  * don't delay.
> >  */
> > clear_bit(STRIPE_DELAYED, >state);
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> > 
> > mutex_lock(>io_mutex);
> > /* meta + data */
> > @@ -1321,7 +1321,7 @@ static void r5c_flush_stripe(struct r5conf *conf, 
> > struct
> > stripe_head *sh)
> > assert_spin_locked(>device_lock);
> > 
> > list_del_init(>lru);
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> > 
> > set_bit(STRIPE_HANDLE, >state);
> > atomic_inc(>active_stripes);
> > @@ -1424,7 +1424,7 @@ static void r5c_do_reclaim(struct r5conf *conf)
> >  */
> > if (!list_empty(>lru) &&
> > !test_bit(STRIPE_HANDLE, 
> > >state) &&
> > -   atomic_read(>count) == 0) {
> > +   refcount_read(>count) == 0) {
> > r5c_flush_stripe(conf,
> > sh);
> > if (count++ >=
> > R5C_RECLAIM_STRIPE_GROUP)
> > break;
> > @@ -2650,7 +2650,7 @@ r5c_cache_data(struct r5l_log *log, struct stripe_head
> > *sh,
> >  * don't delay.
> >  */
> > clear_bit(STRIPE_DELAYED, >state);
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> > 
> > mutex_lock(>io_mutex);
> > /* meta + data */
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index 2ce23b0..7e3913a 100644
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -296,7 +296,7 @@ static void do_release_stripe(struct r5conf *conf, 
> > struct
> > stripe_head *sh,
> >  static void __release_stripe(struct r5conf *conf, struct stripe_head *sh,
> >  struct list_head
> > *temp_inactive_list)
> >  {
> > -   if (atomic_dec_and_test(>count))
> > +   if (refcount_dec_and_test(>count))
> > do_release_stripe(conf, sh, temp_inactive_list);
> >  }
> > 
> > @@ -388,7 +388,7 @@ void raid5_release_stripe(struct stripe_head *sh)
> > 
> > /* Avoid release_list until the last reference.
> >  */
> > -   if (atomic_add_unless(>count, -1, 1))
> > +   if (refcount_dec_not_one(>count))
> > return;
> > 
> > if (unlikely(!conf->mddev->thread) ||
> > @@ -401,7 +401,7 @@ void raid5_release_stripe(struct stripe_head *sh)
> >  slow_path:
> > local_irq_save(flags);
> > /* we are ok here if STRIPE_ON_RELEASE_LIST is set or not */
> > -   if (atomic_dec_and_lock(>count, >device_lock)) {
> > +   if (refcount_dec_and_lock(>count, >device_lock)) {
> > INIT_LIST_HEAD();
> > hash = sh->hash_lock_index;
> > do_release_stripe(conf, sh, );
> > @@ -491,7 +491,7 @@ static void init_stripe(struct stripe_head *sh, sector_t
> > sector, int previous)
> > struct r5conf *conf = sh->raid_conf;
> > int i, seq;
> > 
> > -   BUG_ON(atomic_read(>count) != 0);
> > +   BUG_ON(refcount_read(>count) != 0);
> > BUG_ON(test_bit(STRIPE_HANDLE, >state));
> > BUG_ON(stripe_operations_active(sh));
> > BUG_ON(sh->batch_head);
> > @@ -668,11 +668,11 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t
> > sector,
> >   
> > >cache_state);
> > } else {
> > init_stripe(sh, sector,
> > previous);
> > -   atomic_inc(
> > >count);
> > +   refcount_inc(
> > >count);
> > }
> > -   } else if (!atomic_inc_not_zero(>count)) {
> > +   } else if (!refcount_inc_not_zero(>count)) {
> > spin_lock(>device_lock);
> > -   if (!atomic_read(>count)) {
> 

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

[Jens Axboe]

On 04/20/2017 10:30 AM, Jens Axboe wrote:
> On 04/20/2017 10:29 AM, Keith Busch wrote:
>> On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg wrote:
>>>
> Hi Jens-
>
> These are just the quirk updates, split out.  The patches are
> unchanged.
>
> I think that, even if we want to apply a broader quirk for 4.11, we
> should still apply these so that we can cleanly revert the broader
> quirk later.  IOW, let's get the known regressions fixed before we
> get too excited about the unknown regressions.

 This looks good to me, and 4.11 appropriate. I'll expedite this
 through the block tree, if Keith/Sagi/Christoph agrees on this
 being the right approach for 4.11.
>>>
>>> I'm perfectly fine with this going to 4.11
>>
>> All good with me as well.
>>
>> Reviewed-by: Keith Busch 
> 
> Great, I have queued it up.

Spoke too soon. Andy, did you compile this?

drivers/nvme/host/core.c: In function ‘nvme_init_identify’:
drivers/nvme/host/core.c:1524:6: error: ‘force_apst’ undeclared (first use in 
this function)
  if (force_apst && (ctrl->quirks & NVME_QUIRK_NO_DEEPEST_PS)) {
  ^~
drivers/nvme/host/core.c:1524:6: note: each undeclared identifier is reported 
only once for each function it appears in

No, you did not.

-- 
Jens Axboe

Re: [PATCH] checkpatch: add --typedefsfile

[Joe Perches]

On Thu, 2017-04-20 at 17:39 +0200, Jerome Forissier wrote:
> When using checkpatch on out-of-tree code, it may occur that some
> project-specific types are used, which will cause spurious warnings.
> Add the --typedefsfile option as a way to extend the known types and
> deal with this issue.

I'm not opposed to the addition.
What out-of-tree project is this for?

> Signed-off-by: Jerome Forissier 
> ---
>  scripts/checkpatch.pl | 56 
> ++-
>  1 file changed, 37 insertions(+), 19 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index baa3c7b..eb55f5f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -55,6 +55,7 @@ my $spelling_file = "$D/spelling.txt";
>  my $codespell = 0;
>  my $codespellfile = "/usr/share/codespell/dictionary.txt";
>  my $conststructsfile = "$D/const_structs.checkpatch";
> +my $typedefsfile = "";
>  my $color = 1;
>  my $allow_c99_comments = 1;
>  
> @@ -113,6 +114,7 @@ Options:
>--codespellUse the codespell dictionary for spelling/typos
>   (default:/usr/share/codespell/dictionary.txt)
>--codespellfileUse this codespell dictionary
> +  --typedefsfile Read additional types from this file
>--colorUse colors when output is STDOUT (default: on)
>-h, --help, --version  display this help and exit
>  
> @@ -208,6 +210,7 @@ GetOptions(
>   'test-only=s'   => \$tst_only,
>   'codespell!'=> \$codespell,
>   'codespellfile=s'   => \$codespellfile,
> + 'typedefsfile=s'=> \$typedefsfile,
>   'color!'=> \$color,
>   'h|help'=> \$help,
>   'version'   => \$help
> @@ -629,28 +632,43 @@ if ($codespell) {
>  
>  $misspellings = join("|", sort keys %spelling_fix) if keys %spelling_fix;
>  
> +sub read_words {
> + my ($wordsRef, $file) = @_;
> +
> + if (open(my $words, '<', $file)) {
> + while (<$words>) {
> + my $line = $_;
> +
> + $line =~ s/\s*\n?$//g;
> + $line =~ s/^\s*//g;
> +
> + next if ($line =~ m/^\s*#/);
> + next if ($line =~ m/^\s*$/);
> + if ($line =~ /\s/) {
> + print("$file: '$line' invalid - ignored\n");
> + next;
> + }
> +
> + $$wordsRef .= '|' if ($$wordsRef ne "");
> + $$wordsRef .= $line;
> + }
> + close($file);
> + return 1;
> + }
> +
> + return 0;
> +}
> +
>  my $const_structs = "";
> -if (open(my $conststructs, '<', $conststructsfile)) {
> - while (<$conststructs>) {
> - my $line = $_;
> +read_words(\$const_structs, $conststructsfile)
> +or warn "No structs that should be const will be found - file 
> '$conststructsfile': $!\n";
>  
> - $line =~ s/\s*\n?$//g;
> - $line =~ s/^\s*//g;
> -
> - next if ($line =~ m/^\s*#/);
> - next if ($line =~ m/^\s*$/);
> - if ($line =~ /\s/) {
> - print("$conststructsfile: '$line' invalid - ignored\n");
> - next;
> - }
> -
> - $const_structs .= '|' if ($const_structs ne "");
> - $const_structs .= $line;
> - }
> - close($conststructsfile);
> -} else {
> - warn "No structs that should be const will be found - file 
> '$conststructsfile': $!\n";
> +my $typeOtherTypedefs = "";
> +if (length($typedefsfile)) {
> + read_words(\$typeOtherTypedefs, $typedefsfile)
> + or warn "No additional types will be considered - file 
> '$typedefsfile': $!\n";
>  }
> +$typeTypedefs .= '|' . $typeOtherTypedefs if ($typeOtherTypedefs ne "");
>  
>  sub build_types {
>   my $mods = "(?x:  \n" . join("|\n  ", (@modifierList, 
> @modifierListFile)) . "\n)";

Re: [PATCH] MAINTAINERS: Add bugzilla and documentation entites for kselftest, usbip

[Shuah Khan]

On 04/20/2017 09:52 AM, Greg KH wrote:
> On Thu, Apr 20, 2017 at 09:50:10AM -0600, Shuah Khan wrote:
>> @@ -13033,6 +13035,8 @@ M:   Valentina Manea 
>>  M:  Shuah Khan 
>>  M:  Shuah Khan 
>>  L:  linux-...@vger.kernel.org
>> +T:  git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
>> +B:  https://bugzilla.kernel.org
>>  S:  Maintained
>>  F:  Documentation/usb/usbip_protocol.txt
>>  F:  drivers/usb/usbip/
> 
> I don't like USB bugs in bugzilla at all, how are you going to separate
> the usbip bugs out from the rest of the usb bugs there?
> 

I didn't realize usb bugs aren't tracked in bugzilla. I quick search
would have told me that - my bad. My thinking is that we could use a
Tag for USB/IP. However, it could get messy.

I will resend the patch to just add the git entry which would be
helpful since you take these patches through your usb tree.

thanks,
-- Shuah

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Boris Ostrovsky]

On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote:
> Peter Zijlstra  writes:
>
>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>>> In this patch I suggest we set __max_logical_packages based on the
>>> max_physical_pkg_id and total_cpus,
>> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
>> instead of 4.
>>
>> This wastes quite a bit of memory for the per-node arrays. Luckily most
>> are just pointer arrays, but still, wasting 140*8 bytes for each of
>> them.
>>
>>> this should be safe and cover all
>>> possible cases. Alternatively, we may think about eliminating the concept
>>> of __max_logical_packages completely and relying on max_physical_pkg_id/
>>> total_cpus where we currently use topology_max_packages().
>>>
>>> The issue could've been solved in Xen too I guess. CPUID returning
>>> x86_max_cores can be tweaked to be the lowerest(?) possible number of
>>> all logical packages of the guest.
>> This is getting ludicrous. Xen is plain broken, and instead of fixing
>> it, you propose to somehow deal with its obviously crack induced
>> behaviour :-(
> Totally agree and I don't like the solution I propose (and that's why
> this is RFC)... The problem is that there are such Xen setups in the
> wild and with the recent changes some guests will BUG() :-(
>
> Alternatively, we can just remove the BUG() and do something with CPUs
> which have their pkg >= __max_logical_packages, e.g. assign them to the
> last package. Far from ideal but will help to avoid the regression.

Do you observe this failure on PV or HVM guest?

We've had a number of issues with topology discovery for PV guests but
AFAIK they have been addressed (so far). I wonder though whether it
would make sense to have some sort of a callback (or an smp_ops.op) to
override native topology info, if needed.

-boris

Re: [PATCH v3 1/3] dt-bindings: Add support for samsung s6e3hf2 panel

[Rob Herring]

On Tue, Apr 18, 2017 at 05:40:34PM +0900, Hoegeun Kwon wrote:
> The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
> 
> The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
> panel similar to the s6e3ha2. So add the compatible string and
> comments.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> ---
>  Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

[PATCH] powerpc/32: Avoid risk of unrecoverable TLBmiss inside entry_32.S

[Christophe Leroy]

By default, the 8xx pins an ITLB on the first 8M of memory in order
to avoid any ITLB miss on kernel code.
However, with some debug functions like DEBUG_PAGEALLOC and
DEBUG_RODATA, pinning TLBs is contradictory.

In order to avoid any ITLB miss in a critical section without pinning
TLBs, we have to ensure that there is no page boundary crossed between
the setup of a new value in SRR0/SRR1 and the associated RFI.

Today, the functions modifying srr0/srr1 are all located in
setup_32.S. They are spread over almost 4kbytes.

This patch reorganises setup_32.S to regroup those functions at the
beginning of the file. It regroups them within the first 2kbytes.

Then the patch forces an 11 bits (2kbytes) alignment for those
functions. This garanties that the functions remain in a
single 4k page.

Signed-off-by: Christophe Leroy 
---
 This patch superseeds previous patch named "powerpc/32: Move entry_32
 functions just after HEAD functions.", taking into account suggestion
 from Michael.

 No modification is done to the code, only a move was done.

 arch/powerpc/kernel/entry_32.S | 509 +
 1 file changed, 258 insertions(+), 251 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index a38600949f3a..b46556571580 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -44,6 +44,13 @@
 #define LOAD_MSR_KERNEL(r, x)  li r,(x)
 #endif
 
+/*
+ * Align to 2k in order to ensure that all functions modyfing srr0/srr1
+ * fit into one page in order to not encounter a TLB miss between the
+ * modification of srr0/srr1 and the associated rfi.
+ */
+   .align  11
+
 #ifdef CONFIG_BOOKE
.globl  mcheck_transfer_to_handler
 mcheck_transfer_to_handler:
@@ -441,257 +448,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
 66:li  r3,-ENOSYS
b   ret_from_syscall
 
-   .globl  ret_from_fork
-ret_from_fork:
-   REST_NVGPRS(r1)
-   bl  schedule_tail
-   li  r3,0
-   b   ret_from_syscall
-
-   .globl  ret_from_kernel_thread
-ret_from_kernel_thread:
-   REST_NVGPRS(r1)
-   bl  schedule_tail
-   mtlrr14
-   mr  r3,r15
-   PPC440EP_ERR42
-   blrl
-   li  r3,0
-   b   ret_from_syscall
-
-/* Traced system call support */
-syscall_dotrace:
-   SAVE_NVGPRS(r1)
-   li  r0,0xc00
-   stw r0,_TRAP(r1)
-   addir3,r1,STACK_FRAME_OVERHEAD
-   bl  do_syscall_trace_enter
-   /*
-* Restore argument registers possibly just changed.
-* We use the return value of do_syscall_trace_enter
-* for call number to look up in the table (r0).
-*/
-   mr  r0,r3
-   lwz r3,GPR3(r1)
-   lwz r4,GPR4(r1)
-   lwz r5,GPR5(r1)
-   lwz r6,GPR6(r1)
-   lwz r7,GPR7(r1)
-   lwz r8,GPR8(r1)
-   REST_NVGPRS(r1)
-
-   cmplwi  r0,NR_syscalls
-   /* Return code is already in r3 thanks to do_syscall_trace_enter() */
-   bge-ret_from_syscall
-   b   syscall_dotrace_cont
-
-syscall_exit_work:
-   andi.   r0,r9,_TIF_RESTOREALL
-   beq+0f
-   REST_NVGPRS(r1)
-   b   2f
-0: cmplw   0,r3,r8
-   blt+1f
-   andi.   r0,r9,_TIF_NOERROR
-   bne-1f
-   lwz r11,_CCR(r1)/* Load CR */
-   neg r3,r3
-   orisr11,r11,0x1000  /* Set SO bit in CR */
-   stw r11,_CCR(r1)
-
-1: stw r6,RESULT(r1)   /* Save result */
-   stw r3,GPR3(r1) /* Update return value */
-2: andi.   r0,r9,(_TIF_PERSYSCALL_MASK)
-   beq 4f
-
-   /* Clear per-syscall TIF flags if any are set.  */
-
-   li  r11,_TIF_PERSYSCALL_MASK
-   addir12,r12,TI_FLAGS
-3: lwarx   r8,0,r12
-   andcr8,r8,r11
-#ifdef CONFIG_IBM405_ERR77
-   dcbt0,r12
-#endif
-   stwcx.  r8,0,r12
-   bne-3b
-   subir12,r12,TI_FLAGS
-   
-4: /* Anything which requires enabling interrupts? */
-   andi.   r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP)
-   beq ret_from_except
-
-   /* Re-enable interrupts. There is no need to trace that with
-* lockdep as we are supposed to have IRQs on at this point
-*/
-   ori r10,r10,MSR_EE
-   SYNC
-   MTMSRD(r10)
-
-   /* Save NVGPRS if they're not saved already */
-   lwz r4,_TRAP(r1)
-   andi.   r4,r4,1
-   beq 5f
-   SAVE_NVGPRS(r1)
-   li  r4,0xc00
-   stw r4,_TRAP(r1)
-5:
-   addir3,r1,STACK_FRAME_OVERHEAD
-   bl  do_syscall_trace_leave
-   b   ret_from_except_full
-
-/*
- * The fork/clone functions need to copy the full register set into
- * the child process. Therefore we need to save all the nonvolatile
- * registers (r13 - r31) before calling the C code.
- */
-   .globl  ppc_fork
-ppc_fork:
-   SAVE_NVGPRS(r1)

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 5:39 PM, Andrey Konovalov  wrote:
> On Thu, Apr 20, 2017 at 5:35 PM, David Ahern  wrote:
>> On 4/20/17 9:28 AM, Andrey Konovalov wrote:
>>> This one seems to be much closer to what Dmitry reported intially.
>>
>> does not repro here; I ran in a loop and nothing.

Here's strace log, maybe it'll help figuring out why it doesn't reproduce:

# strace ./a.out
...
socket(PF_INET6, SOCK_RAW, IPPROTO_TCP) = 3
ioctl(3, SIOCSIFFLAGS, {ifr_name="lo",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI|0x8000}) = 0
socket(PF_INET6, SOCK_RAW|SOCK_CLOEXEC, 0x2b /* IPPROTO_??? */) = 4
socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 5
ioctl(5, SIOCGIFINDEX, {ifr_name="ip6_vti0", ifr_index=26}) = 0
ioctl(4, SIOCSIFADDR, {ifr_name="?", ifr_addr={AF_X25,
"\0\0\32\0\0\0\254*b\333\263\177\0\0"}}) = 0
socket(PF_INET6, SOCK_STREAM|SOCK_NONBLOCK, 0x84 /* IPPROTO_??? */) = 6
ioctl(6, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0x8000 /* IFF_??? */}) = 0
socket(PF_INET6, SOCK_RAW, 0x3 /* IPPROTO_??? */) = 7
ioctl(7, SIOCSIFFLAGS, {ifr_name="ip6_vti0",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI|0x8000}) = 0
ioctl(3, SIOCSIFFLAGS, {ifr_name="lo",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI|0x8000}) = 0
ioctl(6, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0x8000 /* IFF_??? */}) = 0
exit_group(0)   = ?

>
> You use the attached config, right?
>
>>
>> can you send output of "sysctl -a --pattern 'net.ipv6'"
>
> Uploaded here:
> https://gist.github.com/xairy/7b6988c9cd8fda5458005df05584ff27

RE: [PATCH 0/5] v2: block subsystem refcounter conversions

[Reshetova, Elena]

> All the objections from DaveM on the amount of cycles spent on the
> new refcount_t apply to the block layer fast path operations as well.

Ok, could you please indicate the correct way to measure the impact for the 
block layer? 
We can do the measurements. 

Best Regards,
Elena.

> 
> Please don't send any more conversions until those have been resolved.

Re: linux-next: Tree for Apr 20 (bfq)

[Randy Dunlap]

On 04/20/17 08:36, Jens Axboe wrote:
> On 04/20/2017 09:24 AM, Randy Dunlap wrote:
>> On 04/19/17 23:43, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20170419:
>>>
>>
>> on i386:
>> when CONFIG_CGROUPS is not enabled:
>>
>> In file included from ../block/bfq-iosched.c:105:0:
>> ../block/bfq-iosched.h:819:22: error: array type has incomplete element type
>>  extern struct cftype bfq_blkcg_legacy_files[];
>>   ^
>> ../block/bfq-iosched.h:820:22: error: array type has incomplete element type
>>  extern struct cftype bfq_blkg_files[];
> 
> This should fix it:
> 

Yes, it does.  Thanks.

Acked-by: Randy Dunlap 



-- 
~Randy

[PATCH v2 1/2] nvme: Adjust the Samsung APST quirk

[Andy Lutomirski]

I got a couple more reports: the Samsung APST issues appears to
affect multiple 950-series devices in Dell XPS 15 9550 and Precision
5510 laptops.  Change the quirk: rather than blacklisting the
firmware on the first problematic SSD that was reported, disable
APST on all 144d:a802 devices if they're installed in the two
affected Dell models.  While we're at it, disable only the deepest
sleep state instead of all of them -- the reporters say that this is
sufficient to fix the problem.

(I have a device that appears to be entirely identical to one of the
affected devices, but I have a different Dell laptop, so it's not
the case that all Samsung devices with firmware BXW75D0Q are broken
under all circumstances.)

Samsung engineers have an affected system, and hopefully they'll
give us a better workaround some time soon.  In the mean time, this
should minimize regressions.

See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184

Cc: Kai-Heng Feng 
Cc: Niranjan Sivakumar 
Signed-off-by: Andy Lutomirski 
---
 drivers/nvme/host/core.c | 23 +--
 drivers/nvme/host/nvme.h |  5 +
 drivers/nvme/host/pci.c  | 26 +-
 3 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 9583a5f58a1d..d618b20ce6c6 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1316,6 +1316,14 @@ static void nvme_configure_apst(struct nvme_ctrl *ctrl)
table->entries[state] = target;
 
/*
+* Don't allow transitions to the deepest state
+* if it's quirked off.
+*/
+   if (state == ctrl->npss &&
+   (ctrl->quirks & NVME_QUIRK_NO_DEEPEST_PS))
+   continue;
+
+   /*
 * Is this state a useful non-operational state for
 * higher-power states to autonomously transition to?
 */
@@ -1387,16 +1395,6 @@ struct nvme_core_quirk_entry {
 };
 
 static const struct nvme_core_quirk_entry core_quirks[] = {
-   /*
-* Seen on a Samsung "SM951 NVMe SAMSUNG 256GB": using APST causes
-* the controller to go out to lunch.  It dies when the watchdog
-* timer reads CSTS and gets 0x.
-*/
-   {
-   .vid = 0x144d,
-   .fr = "BXW75D0Q",
-   .quirks = NVME_QUIRK_NO_APST,
-   },
 };
 
 /* match is null-terminated but idstr is space-padded. */
@@ -1481,6 +1479,11 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
}
}
 
+   if (force_apst && (ctrl->quirks & NVME_QUIRK_NO_DEEPEST_PS)) {
+   dev_warn(ctrl->dev, "forcibly allowing all power states due to 
nvme_core.force_apst -- use at your own risk\n");
+   ctrl->quirks &= ~NVME_QUIRK_NO_DEEPEST_PS;
+   }
+
ctrl->oacs = le16_to_cpu(id->oacs);
ctrl->vid = le16_to_cpu(id->vid);
ctrl->oncs = le16_to_cpup(>oncs);
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 2aa20e3e5675..ab2d6ec7eb5c 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -83,6 +83,11 @@ enum nvme_quirks {
 * APST should not be used.
 */
NVME_QUIRK_NO_APST  = (1 << 4),
+
+   /*
+* The deepest sleep state should not be used.
+*/
+   NVME_QUIRK_NO_DEEPEST_PS= (1 << 5),
 };
 
 /*
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 26a5fd05fe88..5d309535abbd 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1943,10 +1944,31 @@ static int nvme_dev_map(struct nvme_dev *dev)
return -ENODEV;
 }
 
+static unsigned long check_dell_samsung_bug(struct pci_dev *pdev)
+{
+   if (pdev->vendor == 0x144d && pdev->device == 0xa802) {
+   /*
+* Several Samsung devices seem to drop off the PCIe bus
+* randomly when APST is on and uses the deepest sleep state.
+* This has been observed on a Samsung "SM951 NVMe SAMSUNG
+* 256GB", a "PM951 NVMe SAMSUNG 512GB", and a "Samsung SSD
+* 950 PRO 256GB", but it seems to be restricted to two Dell
+* laptops.
+*/
+   if (dmi_match(DMI_SYS_VENDOR, "Dell Inc.") &&
+   (dmi_match(DMI_PRODUCT_NAME, "XPS 15 9550") ||
+dmi_match(DMI_PRODUCT_NAME, "Precision 5510")))
+   return NVME_QUIRK_NO_DEEPEST_PS;
+   }
+
+   return 0;
+}
+
 static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
int node, result = 

[PATCH v2 0/2] nvme APST quirk updates, take two

[Andy Lutomirski]

Hi Jens-

These are just the quirk updates, split out.  The patches are
unchanged.

I think that, even if we want to apply a broader quirk for 4.11, we
should still apply these so that we can cleanly revert the broader
quirk later.  IOW, let's get the known regressions fixed before we
get too excited about the unknown regressions.

Andy Lutomirski (2):
  nvme: Adjust the Samsung APST quirk
  nvme: Quirk APST off on "THNSF5256GPUK TOSHIBA"

 drivers/nvme/host/core.c | 28 
 drivers/nvme/host/nvme.h |  5 +
 drivers/nvme/host/pci.c  | 26 +-
 3 files changed, 50 insertions(+), 9 deletions(-)

-- 
2.9.3

[PATCH v2 2/2] nvme: Quirk APST off on "THNSF5256GPUK TOSHIBA"

[Andy Lutomirski]

There's a report that it malfunctions with APST on.

See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184

Cc: Kai-Heng Feng 
Signed-off-by: Andy Lutomirski 
---
 drivers/nvme/host/core.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index d618b20ce6c6..1fbcdcdada78 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1395,6 +1395,15 @@ struct nvme_core_quirk_entry {
 };
 
 static const struct nvme_core_quirk_entry core_quirks[] = {
+   {
+   /*
+* This Toshiba device seems to die using any APST states.  See:
+* 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184/comments/11
+*/
+   .vid = 0x1179,
+   .mn = "THNSF5256GPUK TOSHIBA",
+   .quirks = NVME_QUIRK_NO_APST,
+   }
 };
 
 /* match is null-terminated but idstr is space-padded. */
-- 
2.9.3

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

[Jens Axboe]

On 04/20/2017 10:11 AM, Andy Lutomirski wrote:
> Hi Jens-
> 
> These are just the quirk updates, split out.  The patches are
> unchanged.
> 
> I think that, even if we want to apply a broader quirk for 4.11, we
> should still apply these so that we can cleanly revert the broader
> quirk later.  IOW, let's get the known regressions fixed before we
> get too excited about the unknown regressions.

This looks good to me, and 4.11 appropriate. I'll expedite this
through the block tree, if Keith/Sagi/Christoph agrees on this
being the right approach for 4.11.

-- 
Jens Axboe

[PATCH v4 4/8] ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board

[Hugues Fruchet]

Enable DCMI camera interface on STM32F429-EVAL board.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 3c99466..617f2f7 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -141,6 +141,15 @@
clock-frequency = <2500>;
 };
 
+ {
+   status = "okay";
+
+   port {
+   dcmi_0: endpoint {
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
1.9.1

Re: WARNING: kernel stack regs at ffffc9000024fea8 in udevadm:92 has bad 'bp' value 00007fffc4614d30

[Borislav Petkov]

On Thu, Apr 20, 2017 at 08:42:52AM -0500, Josh Poimboeuf wrote:
> If it's recreatable, can you test with the following patch?

Yap, it is. /me builds a kernel...

> 
> diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
> index bda82df..abe36ff 100644
> --- a/arch/x86/kernel/unwind_frame.c
> +++ b/arch/x86/kernel/unwind_frame.c

...

Looks good.

Reported-and-tested-by: Borislav Petkov 

Thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH v4 8/8] ARM: configs: stm32: DCMI + OV2640 camera support

[Hugues Fruchet]

Enable DCMI camera interface and OV2640 camera sensor drivers.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/configs/stm32_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 84adc88..3f2e4ce 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -53,6 +53,13 @@ CONFIG_GPIO_STMPE=y
 CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 # CONFIG_USB_SUPPORT is not set
+CONFIG_VIDEO_V4L2=y
+CONFIG_MEDIA_SUBDRV_AUTOSELECT=n
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_VIDEO_STM32_DCMI=y
+CONFIG_VIDEO_OV2640=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
-- 
1.9.1

Re: [PATCH 4/4] nvme/pci: switch to pci_request_irq

[Sagi Grimberg]

This is great. As an added bonus, more of struct nvme_queue's hot values
are in the same cache line!

Reviewed-by: Keith Busch 


I think I can kill off for mlx5 as well.

Very useful Christoph!

Reviewed-by: Sagi Grimberg 

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 09:18 AM, Ulf Hansson wrote:
>>
>> The Cavium hardware requires knowledge of the card addressing mode.
>> We need to either restore mmc_card_blockaddr(), or create another
>> way to generate the same information. You previously suggested use
>> of the 'blksz' value, however, it has the same value regardless of
>> the card capacity. What would you suggest? Cheers.
> 
> Right. Can you explain what the Cavium hardware need it for?
>
Uffe,

In Cavium's MMC controller, the DMA engine requires software to
specify the addressing mode of the card. For DMA write operations,
the CARD_ADDR field in the MIO_EMM_DMA register is programmed with
a byte address if the media card <= 2GB. If the card is > 2GB, the
address is interpreted as a 512 byte sector address. The SECTOR bit
tells the controller how to interpret the address in CARD_ADDR. If
set to 1, use 512 byte sector addressing, otherwise it is set to 0
and byte addressing is used.

Steve

[PATCHv5 8/9] x86: Enable 5-level paging support

[Kirill A. Shutemov]

Most of things are in place and we can enable support of 5-level paging.

Enabling XEN with 5-level paging requires more work. The patch makes XEN
dependent on !X86_5LEVEL.

Signed-off-by: Kirill A. Shutemov 
---
 arch/x86/Kconfig | 5 +
 arch/x86/xen/Kconfig | 1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4e153e93273f..7a76dcac357e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -318,6 +318,7 @@ config FIX_EARLYCON_MEM
 
 config PGTABLE_LEVELS
int
+   default 5 if X86_5LEVEL
default 4 if X86_64
default 3 if X86_PAE
default 2
@@ -1390,6 +1391,10 @@ config X86_PAE
  has the cost of more pagetable lookup overhead, and also
  consumes more pagetable space per process.
 
+config X86_5LEVEL
+   bool "Enable 5-level page tables support"
+   depends on X86_64
+
 config ARCH_PHYS_ADDR_T_64BIT
def_bool y
depends on X86_64 || X86_PAE
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 76b6dbd627df..b90d481ce5a1 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -5,6 +5,7 @@
 config XEN
bool "Xen guest support"
depends on PARAVIRT
+   depends on !X86_5LEVEL
select PARAVIRT_CLOCK
select XEN_HAVE_PVMMU
select XEN_HAVE_VPMU
-- 
2.11.0

Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

[Hugues FRUCHET]

Hi Hans,

v4 has been sent with "v4l2-compliance -s -f" report provided in cover 
letter. Bindings acked by Rob.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg111743.html

BR,
Hugues.

On 04/10/2017 10:55 AM, Hans Verkuil wrote:
> On 04/04/2017 05:44 PM, Hugues Fruchet wrote:
>> This patchset introduces a basic support for Digital Camera Memory Interface
>> (DCMI) of STMicroelectronics STM32 SoC series.
>>
>> This first basic support implements RGB565 & YUV frame grabbing.
>> Cropping and JPEG support will be added later on.
>>
>> This has been tested on STM324x9I-EVAL evaluation board embedding
>> an OV2640 camera sensor.
>>
>> This driver depends on:
>>   - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers 
>> http://www.spinics.net/lists/linux-media/msg113480.html
>>
>> ===
>> = history =
>> ===
>> version 3:
>>   - stm32-dcmi: Add "Reviewed-by: Hans Verkuil "
>>   - dt-bindings: Fix remarks from Rob Herring:
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html
>>
>> version 2:
>>   - Fix a Kbuild warning in probe:
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html
>>   - Fix a warning in dcmi_queue_setup()
>>   - dt-bindings: warn on sensor signals level inversion in board example
>>   - Typos fixing
>>
>> version 1:
>>   - Initial submission
>>
>> ===
>> = v4l2-compliance =
>> ===
>> Below is the v4l2-compliance report for this current version of the DCMI 
>> camera interface.
>> v4l2-compliance has been built from v4l-utils-1.12.3.
>
> Please test with 'v4l2-compliance -s -f' as well and mail me the output of
> that test.
>
> Once you have the Acks for the DT/bindings patches just let me know and I'll
> make a pull request.
>
> Regards,
>
>   Hans
>
>>
>> v4l2-compliance SHA   : f5f45e17ee98a0ebad7836ade2b34ceec909d751
>>
>> Driver Info:
>> Driver name   : stm32-dcmi
>> Card type : STM32 Digital Camera Memory Int
>> Bus info  : platform:dcmi
>> Driver version: 4.11.0
>> Capabilities  : 0x8521
>> Video Capture
>> Read/Write
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps   : 0x0521
>> Video Capture
>> Read/Write
>> Streaming
>> Extended Pix Format
>>
>> Compliance test for device /dev/video0 (not using libv4l2):
>>
>> Required ioctls:
>> test VIDIOC_QUERYCAP: OK
>>
>> Allow for multiple opens:
>> test second video open: OK
>> test VIDIOC_QUERYCAP: OK
>> test VIDIOC_G/S_PRIORITY: OK
>> test for unlimited opens: OK
>>
>> Debug ioctls:
>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>> test VIDIOC_LOG_STATUS: OK
>>
>> Input ioctls:
>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>> test VIDIOC_G/S/ENUMINPUT: OK
>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>> Inputs: 1 Audio Inputs: 0 Tuners: 0
>>
>> Output ioctls:
>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>
>> Input/Output configuration ioctls:
>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>
>> Test input 0:
>>
>> Control ioctls:
>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>> test VIDIOC_QUERYCTRL: OK
>> test VIDIOC_G/S_CTRL: OK
>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>> Standard Controls: 3 Private Controls: 0
>>
>> Format ioctls:
>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>> test VIDIOC_G/S_PARM: OK (Not Supported)
>> test VIDIOC_G_FBUF: OK (Not Supported)
>> test VIDIOC_G_FMT: OK
>> test VIDIOC_TRY_FMT: OK
>> test VIDIOC_S_FMT: OK
>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>> test Cropping: OK (Not Supported)
>> test Composing: OK (Not Supported)
>> test Scaling: OK
>>
>> Codec ioctls:
>> test 

[PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

[Haiyang Zhang]

From: Haiyang Zhang 

This patch uses the lower 16 bits of the serial number as PCI
domain, otherwise some drivers may not be able to handle it.

Signed-off-by: Haiyang Zhang 
---
 drivers/pci/host/pci-hyperv.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index e73880c..b18dff3 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1334,9 +1334,11 @@ static void put_pcichild(struct hv_pci_dev *hpdev,
 * can have shorter names than based on the bus instance UUID.
 * Only the first device serial number is used for domain, so the
 * domain number will not change after the first device is added.
+* The lower 16 bits of the serial number is used, otherwise some
+* drivers may not be able to handle it.
 */
if (list_empty(>children))
-   hbus->sysdata.domain = desc->ser;
+   hbus->sysdata.domain = desc->ser & 0x;
list_add_tail(>list_entry, >children);
spin_unlock_irqrestore(>device_list_lock, flags);
return hpdev;
-- 
1.7.1

Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds

[Suzuki K Poulose]

On Thu, Apr 13, 2017 at 04:50:46PM +0100, Suzuki K. Poulose wrote:
> On Thu, Apr 13, 2017 at 10:17:54AM +0100, Suzuki K Poulose wrote:
> > On 12/04/17 19:43, Marc Zyngier wrote:
> > > On 12/04/17 17:19, Andrey Konovalov wrote:
> > >
> > > Hi Andrey,
> > >
> > > > Apparently this wasn't fixed, I've got this report again on
> > > > linux-next-c4e7b35a3 (Apr 11), which includes 8b3405e34 "kvm:
> > > > arm/arm64: Fix locking for kvm_free_stage2_pgd".
> > >
> > > This looks like a different bug.
> > >
> > > >
> > > > I now have a way to reproduce it, so I can test proposed patches. I
> > > > don't have a simple C reproducer though.
> > > >
> > > > The bug happens when the following syzkaller program is executed:
> > > >
> > > > mmap(&(0x7f00/0xc000)=nil, (0xc000), 0x3, 0x32, 
> > > > 0x, 0x0)
> > > > unshare(0x400)
> > > > perf_event_open(&(0x7f02f000-0x78)={0x1, 0x78, 0x0, 0x0, 0x0, 0x0,
> > > > 0x0, 0x6, 0x0, 0x0, 0xd34, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> > > > 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 0x0, 0x,
> > > > 0x, 0x0)
> > > > r0 = openat$kvm(0xff9c,
> > > > &(0x7f00c000-0x9)="2f6465762f6b766d00", 0x0, 0x0)
> > > > ioctl$TIOCSBRK(0x, 0x5427)
> > > > r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
> > > > syz_kvm_setup_cpu$arm64(r1, 0x,
> > > > &(0x7fdc6000/0x18000)=nil, &(0x7f00c000)=[{0x0,
> > > > &(0x7f00c000)="5ba3c16f533efbed09f8221253c73763327fadce2371813b45dd7f7982f84a873e4ae89a6c2bd1af83a6024c36a1ff518318",
> > > > 0x32}], 0x1, 0x0, &(0x7f00d000-0x10)=[@featur2={0x1, 0x3}], 0x1)
> > >
> > > Is that the only thing the program does? Or is there anything running in
> > > parallel?
> > >
> > > > ==
> > > > BUG: KASAN: use-after-free in arch_spin_is_locked
> > > > include/linux/compiler.h:254 [inline]
> > > > BUG: KASAN: use-after-free in unmap_stage2_range+0x990/0x9a8
> > > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:295
> > > > Read of size 8 at addr 84476730 by task syz-executor/13106
> > > >
> > > > CPU: 1 PID: 13106 Comm: syz-executor Not tainted
> > > > 4.11.0-rc6-next-20170411-xc2-11025-gc4e7b35a33d4-dirty #5
> > > > Hardware name: Hardkernel ODROID-C2 (DT)
> > > > Call trace:
> > > > [] dump_backtrace+0x0/0x440 
> > > > arch/arm64/kernel/traps.c:505
> > > > [] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
> > > > [] __dump_stack lib/dump_stack.c:16 [inline]
> > > > [] dump_stack+0x110/0x168 lib/dump_stack.c:52
> > > > [] print_address_description+0x60/0x248 
> > > > mm/kasan/report.c:252
> > > > [] kasan_report_error mm/kasan/report.c:351 [inline]
> > > > [] kasan_report+0x218/0x300 mm/kasan/report.c:408
> > > > [] __asan_report_load8_noabort+0x18/0x20 
> > > > mm/kasan/report.c:429
> > > > [] arch_spin_is_locked include/linux/compiler.h:254 
> > > > [inline]
> > >
> > > This is the assert on the spinlock, and the memory is gone.
> > >
> > > > [] unmap_stage2_range+0x990/0x9a8
> > > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:295
> > > > [] kvm_free_stage2_pgd.part.16+0x30/0x98
> > > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:842
> > > > [] kvm_free_stage2_pgd
> > > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:838 [inline]
> > >
> > > But we've taken than lock here. There's only a handful of instructions
> > > in between, and the memory can only go away if there is something
> > > messing with us in parallel.
> > >
> > > > [] kvm_arch_flush_shadow_all+0x40/0x58
> > > > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1895
> > > > [] kvm_mmu_notifier_release+0x154/0x1d0
> > > > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:472
> > > > [] __mmu_notifier_release+0x1c0/0x3e0 
> > > > mm/mmu_notifier.c:75
> > > > [] mmu_notifier_release
> > > > include/linux/mmu_notifier.h:235 [inline]
> > > > [] exit_mmap+0x21c/0x288 mm/mmap.c:2941
> > > > [] __mmput kernel/fork.c:888 [inline]
> > > > [] mmput+0xdc/0x2e0 kernel/fork.c:910
> > > > [] exit_mm kernel/exit.c:557 [inline]
> > > > [] do_exit+0x648/0x2020 kernel/exit.c:865
> > > > [] do_group_exit+0xdc/0x260 kernel/exit.c:982
> > > > [] get_signal+0x358/0xf58 kernel/signal.c:2318
> > > > [] do_signal+0x170/0xc10 
> > > > arch/arm64/kernel/signal.c:370
> > > > [] do_notify_resume+0xe4/0x120 
> > > > arch/arm64/kernel/signal.c:421
> > > > [] work_pending+0x8/0x14
> > >
> > > So we're being serviced with a signal. Do you know if this signal is
> > > generated by your syzkaller program? We could be racing between do_exit
> > > triggered by a fatal signal (this trace) and the closing of the two file
> > > descriptors (vcpu and vm).
> > >
> > > Paolo: does this look possible to you? I can't see what locking we have
> > > that could prevent this race.
> >
> > On a quick look, I see two issues:
> >
> > 1) It looks like the mmu_notifier->ops.release could be called twice for a 
> > notifier,
> > from mmu_notifier_unregister() and exit_mmap()->mmu_notifier_release(), 
> > 

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

[Tyrel Datwyler]

On 04/19/2017 09:43 PM, Frank Rowand wrote:



>> Something else to keep in mind is that while pr_debugs could be used to
>> provide feedback on the reference counts and of_reconfig events they
>> don't in anyway tell us where they are happening in the kernel. The
> 
> Yes, that is critical information.  When there are refcount issues, the
> root cause is at varying levels back in the call stack.
> 
> 
>> trace infrastructure provides the ability to stack trace those events.
>> The following example provides me a lot more information about who is
>> doing what and where after I hot-add an ethernet adapter:
>>
>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>> # cat trace | grep -A6 "/pci@8002018"
>> ...
>>drmgr-7349  [006] d...  7138.821875: of_node_get: refcount=8,
>> dn->full_name=/pci@8002018
>>drmgr-7349  [006] d...  7138.821876: 
>>  => .msi_quota_for_device
>>  => .rtas_setup_msi_irqs
>>  => .arch_setup_msi_irqs
>>  => .__pci_enable_msix
>>  => .pci_enable_msix_range
> 
> Nice!  It is great to have function names in the call stack.

Agreed.



>> To get that same info as far as I know is to add a dump_stack() after
>> each pr_debug.
> 
> Here is a patch that I have used.  It is not as user friendly in terms
> of human readable stack traces (though a very small user space program
> should be able to fix that).  The patch is cut and pasted into this
> email, so probably white space damaged.
> 
> Instead of dumping the stack, each line in the "report" contains
> the top six addresses in the call stack.  If interesting, they
> can be post-processed (as I will show in some examples below).

Very cool. I wasn't familiar with the CALLER_ADDR* defines. Thanks for
sharing.

> 
> ---
>  drivers/of/dynamic.c |   29 +
>  1 file changed, 29 insertions(+)
> 
> Index: b/drivers/of/dynamic.c
> ===
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "of_private.h"
>  
> @@ -27,6 +28,20 @@ struct device_node *of_node_get(struct d
>  {
>   if (node)
>   kobject_get(>kobj);
> +
> + if (node) {
> + int k;
> + int refcount = refcount_read(>kobj.kref.refcount);
> + pr_err("XXX get 0x%p %3d [0x%08lx 0x%08lx 0x%08lx 0x%08lx 
> 0x%08lx 0x%08lx] ",
> + node, refcount,
> + CALLER_ADDR5, CALLER_ADDR4, CALLER_ADDR3,
> + CALLER_ADDR2, CALLER_ADDR1, CALLER_ADDR0);
> + // refcount = (refcount > 20) ? 20 : refcount; /* clamp max */
> + for (k = 0; k < refcount; k++)
> + pr_cont("+");
> + pr_cont(" %s\n", of_node_full_name(node));
> + }
> +
>   return node;
>  }
>  EXPORT_SYMBOL(of_node_get);
> @@ -38,8 +53,22 @@ EXPORT_SYMBOL(of_node_get);
>   */
>  void of_node_put(struct device_node *node)
>  {
> + if (node) {
> + int k;
> + int refcount = refcount_read(>kobj.kref.refcount);
> + pr_err("XXX put 0x%p %3d [0x%08lx 0x%08lx 0x%08lx 0x%08lx 
> 0x%08lx 0x%08lx] ",
> + node, refcount,
> + CALLER_ADDR5, CALLER_ADDR4, CALLER_ADDR3,
> + CALLER_ADDR2, CALLER_ADDR1, CALLER_ADDR0);
> + // refcount = (refcount > 20) ? 20 : refcount; /* clamp max */
> + for (k = 0; k < refcount; k++)
> + pr_cont("-");
> + pr_cont(" %s\n", of_node_full_name(node));
> + }
> +
>   if (node)
>   kobject_put(>kobj);
> +
>  }
>  EXPORT_SYMBOL(of_node_put);
> 
> 
> I have used this mostly in the context of boot time, so there is a lot
> of output.  My notes on configuration needed for my ARM boards are:
> 
>FIXME: Currently using pr_err() so I don't need to set loglevel on boot.
> 
>   So obviously not a user friendly tool!!!
>   The process is:
>  - apply patch
>  - configure, build, boot kernel
>  - analyze data
>  - remove patch
> 
>LOG_BUF_SHIFT (was 17)
>General Setup ->
>   [select 21] Kernel log buffer size (16 => 64KB, 17 => 128KB)
> 
> 
>Device Drivers ->
>   Device Tree and Open Firmware support ->
> Device Tree overlays
> 
> 
> Want CONFIG_FRAME_POINTER so that CALLER_ADDR* will work.
> To be able to enable CONFIG_FRAME_POINTER, need to disable CONFIG_ARM_UNWIND.
> 
>Kernel hacking ->
>   [unselect] Enable stack unwinding support (EXPERIMENTAL)
>   CONFIG_FRAME_POINTER will then be selected automatically
> 
> 
> The output looks like:
> 
> [0.231430] OF: XXX get 0xeefeb5dc   2 [0xc0814c58 0xc08148b0 0xc080e970 
> 0xc080e894 0xc080e678 0xc080de7c] ++ /smp2p-adsp/slave-kernel
> [0.231457] OF: XXX get 0xeefeb5dc   3 [0xc08103c4 0xc0810024 0xc080fd94 
> 

[PATCH 1/8] clk: si5351: Use devm_kcalloc() in si5351_i2c_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Apr 2017 22:37:30 +0200

Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "devm_kcalloc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/clk/clk-si5351.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index b051db43fae1..a4c009e1e70d 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1535,9 +1535,9 @@ static int si5351_i2c_probe(struct i2c_client *client,
else
parent_names[1] = si5351_pll_names[1];
 
-   drvdata->msynth = devm_kzalloc(>dev, num_clocks *
+   drvdata->msynth = devm_kcalloc(>dev, num_clocks,
   sizeof(*drvdata->msynth), GFP_KERNEL);
-   drvdata->clkout = devm_kzalloc(>dev, num_clocks *
+   drvdata->clkout = devm_kcalloc(>dev, num_clocks,
   sizeof(*drvdata->clkout), GFP_KERNEL);
drvdata->num_clkout = num_clocks;
 
-- 
2.12.2

[PATCH 0/8] clk: Fine-tuning for ten function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 20 Apr 2017 10:12:34 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (8):
  Use devm_kcalloc() in si5351_i2c_probe()
  Delete an error message for a failed memory allocation in si5351_i2c_probe()
  Adjust a null pointer check in si5351_dt_parse()
  Replace four seq_printf() calls by seq_putc()
  Combine two seq_puts() calls into one call in clk_summary_show()
  Improve a size determination in two functions
  Use seq_puts() in nomadik_src_clk_show()
  Delete error messages for a failed memory allocation in two functions

 drivers/clk/clk-nomadik.c | 12 
 drivers/clk/clk-si5351.c  | 10 --
 drivers/clk/clk.c | 19 +--
 3 files changed, 17 insertions(+), 24 deletions(-)

-- 
2.12.2

Re: [PATCH] ASoC: codec: wm9860: avoid maybe-uninitialized warning

[Daniel Baluta]

On Thu, Apr 20, 2017 at 10:44 AM, Arnd Bergmann  wrote:
> On Thu, Apr 20, 2017 at 8:48 AM, Daniel Baluta  
> wrote:
>> Hi Arnd,
>>
>> On Wed, Apr 19, 2017 at 8:04 PM, Arnd Bergmann  wrote:
>>> The new PLL configuration code triggers a harmless warning:
>>>
>>> sound/soc/codecs/wm8960.c: In function 'wm8960_configure_clocking':
>>> sound/soc/codecs/wm8960.c:735:3: error: 'best_freq_out' may be used 
>>> uninitialized in this function [-Werror=maybe-uninitialized]
>>>wm8960_set_pll(codec, freq_in, best_freq_out);
>>>^
>>> sound/soc/codecs/wm8960.c:699:12: note: 'best_freq_out' was declared here
>>>
>>> I think the warning was introduced by Daniel's bugfix. I've come up
>>> with a way to simplify the code in a way that is more readable to
>>> both humans and to gcc, which gets us rid of the warning.
>>
>> I've struggled with this kind of warning when reworking wm8960
>> bitclock computation.
>>
>> Anyhow, for this exact patch the warning didn't showed up.
>>
>> I used:
>>
>> gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)
>
> I'm using gcc-7.0.1 here, which overall has better warnings for
> -Wmaybe-uninitialized
> than older versions, but sometimes also finds new false positives.
>
>> My next patch:
>>
>> https://patchwork.kernel.org/patch/9666921/ [1]
>>
>> which is under review, had the issue you mention (in v1)
>>
>> https://lkml.org/lkml/2017/4/5/246
>>
>> but I initialized best_freq_out with 0 to get rid of the problem.
>
> I try hard not to do that, because it can hide real problems in case the
> code gets modified further to actually have an uninitialized use that we
> would otherwise get a warning for.
>
>>> @@ -720,22 +718,14 @@ int wm8960_configure_pll(struct snd_soc_codec *codec, 
>>> int freq_in,
>>> *sysclk_idx = i;
>>> *dac_idx = j;
>>> *bclk_idx = k;
>>> -   best_freq_out = freq_out;
>>> -   break;
>>> +   return freq_out;
>>> }
>>> }
>>> -   if (k != ARRAY_SIZE(bclk_divs))
>>> -   break;
>>> }
>>> -   if (j != ARRAY_SIZE(dac_divs))
>>> -   break;
>>> }
>>> -
>>> -   if (*bclk_idx != -1)
>>> -   wm8960_set_pll(codec, freq_in, best_freq_out);
>>
>> I think the compiler is tricked into thinking that best_freq_out might
>> be uninitialized. Notice
>> that each time *bclk_idx is assigned a value (which is always >=0) we
>> also initialize best_freq_out.
>
> Right. This is probably the result of one of two things that
> prevent the compiler from figuring it out:
>
> a) bclk_idx being an indirect pointer might cause the compiler to
> decide that another operation might overwrite it, e.g. if it points
> to the same location as one of the other pointers.
>
> b) The flow analysis might just get too tricky, so when gcc gives
> up trying to work out whether the assignment has happened
> at least once for the two variables, it concludes that it doesn't
> know, without seeing that the answer is always the same for
> both of them.
>
>>> @@ -783,11 +773,12 @@ static int wm8960_configure_clocking(struct 
>>> snd_soc_codec *codec)
>>> }
>>> }
>>>
>>> -   ret = wm8960_configure_pll(codec, freq_in, , , );
>>> -   if (ret < 0) {
>>> +   freq_out = wm8960_configure_pll(codec, freq_in, , , );
>>> +   if (freq_out < 0) {
>>> dev_err(codec->dev, "failed to configure clock via PLL\n");
>>> -   return -EINVAL;
>>> +   return freq_out;
>>> }
>>> +   wm8960_set_pll(codec, freq_in, freq_out);
>>>
>>>  configure_clock:
>>> /* configure sysclk clock */
>>
>> Your idea looks good, will need to rework my follow up patch on it:
>>
>> https://patchwork.kernel.org/patch/9666921/
>
> Ok. Or feel free to fold my patch into yours if that makes it easier for you.

Great! I will fold your patch into my changes.

thanks Arnd!

Daniel.

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

[Mason]

On 19/04/2017 13:19, Mason wrote:

> My biggest problem is that tango_unmask() is never called.

FTR, the missing incantation was:
Explicitly calling tango_{mask/unmask/ack} from the corresponding 
msi_{mask/unmask/ack}

Marc, I have one nagging doubt, wrt splitting MSI line selection
and MSI enable.

tango_irq_domain_alloc : finds an available MSI 'j' to allocate
tango_irq_domain_free : release MSI 'j'
tango_unmask : enable MSI 'j'
tango_mask : disable MSI 'j'

Is the following scenario guaranteed to never happen?

tango_irq_domain_alloc // alloc 0
tango_irq_domain_free  // free 0
tango_irq_domain_alloc // alloc 0
tango_unmask // enable 0
tango_unmask // enable 0 = NOP
tango_mask   // disable 0

In this theoretical scenario, we would be left with a non-functional
MSI 0.

Regards.

Re: [PATCH 7/9] mm, memory_hotplug: replace for_device by want_memblock in arch_add_memory

[Vlastimil Babka]

On 04/10/2017 01:03 PM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> arch_add_memory gets for_device argument which then controls whether we
> want to create memblocks for created memory sections. Simplify the logic
> by telling whether we want memblocks directly rather than going through
> pointless negation. This also makes the api easier to understand because
> it is clear what we want rather than nothing telling for_device which
> can mean anything.
> 
> This shouldn't introduce any functional change.
> 
> Cc: Dan Williams 
> Signed-off-by: Michal Hocko 

Acked-by: Vlastimil Babka 

[PATCH 4/8] clk: Replace four seq_printf() calls by seq_putc()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 20 Apr 2017 08:45:43 +0200

Four single characters should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/clk/clk.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 67201f67a14a..4c72a10a9a33 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2081,11 +2081,11 @@ static void clk_dump_subtree(struct seq_file *s, struct 
clk_core *c, int level)
clk_dump_one(s, c, level);
 
hlist_for_each_entry(child, >children, child_node) {
-   seq_printf(s, ",");
+   seq_putc(s, ',');
clk_dump_subtree(s, child, level + 1);
}
 
-   seq_printf(s, "}");
+   seq_putc(s, '}');
 }
 
 static int clk_dump(struct seq_file *s, void *data)
@@ -2094,14 +2094,13 @@ static int clk_dump(struct seq_file *s, void *data)
bool first_node = true;
struct hlist_head **lists = (struct hlist_head **)s->private;
 
-   seq_printf(s, "{");
-
+   seq_putc(s, '{');
clk_prepare_lock();
 
for (; *lists; lists++) {
hlist_for_each_entry(c, *lists, child_node) {
if (!first_node)
-   seq_puts(s, ",");
+   seq_putc(s, ',');
first_node = false;
clk_dump_subtree(s, c, 0);
}
-- 
2.12.2

[PATCH 6/8] clk: Improve a size determination in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 20 Apr 2017 09:30:52 +0200

Replace the specification of two data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/clk/clk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 684642ab4212..3f2ee0469d3e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2939,7 +2939,7 @@ int clk_notifier_register(struct clk *clk, struct 
notifier_block *nb)
 
/* if clk wasn't in the notifier list, allocate new clk_notifier */
if (cn->clk != clk) {
-   cn = kzalloc(sizeof(struct clk_notifier), GFP_KERNEL);
+   cn = kzalloc(sizeof(*cn), GFP_KERNEL);
if (!cn)
goto out;
 
@@ -3087,7 +3087,7 @@ int of_clk_add_provider(struct device_node *np,
struct of_clk_provider *cp;
int ret;
 
-   cp = kzalloc(sizeof(struct of_clk_provider), GFP_KERNEL);
+   cp = kzalloc(sizeof(*cp), GFP_KERNEL);
if (!cp)
return -ENOMEM;
 
-- 
2.12.2

[PATCH 5/8] clk: Combine two seq_puts() calls into one call in clk_summary_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 20 Apr 2017 09:12:35 +0200

Some text was put into a sequence by two separate function calls.
Print the same data by a single function call instead.

Signed-off-by: Markus Elfring 
---
 drivers/clk/clk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 4c72a10a9a33..684642ab4212 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2030,9 +2030,9 @@ static int clk_summary_show(struct seq_file *s, void 
*data)
struct clk_core *c;
struct hlist_head **lists = (struct hlist_head **)s->private;
 
-   seq_puts(s, "   clock enable_cnt  prepare_cnt   
 rate   accuracy   phase\n");
-   seq_puts(s, 
"\n");
-
+   seq_puts(s,
+"   clock enable_cnt  prepare_cnt  
  rate   accuracy   phase\n"
+
"\n");
clk_prepare_lock();
 
for (; *lists; lists++)
-- 
2.12.2

[PATCH 7/8] clk: nomadik: Use seq_puts() in nomadik_src_clk_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 20 Apr 2017 09:45:04 +0200

A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/clk/clk-nomadik.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
index 71677eb12565..8d57ab8d6ed8 100644
--- a/drivers/clk/clk-nomadik.c
+++ b/drivers/clk/clk-nomadik.c
@@ -467,7 +467,7 @@ static int nomadik_src_clk_show(struct seq_file *s, void 
*what)
u32 src_pckensr0 = readl(src_base + SRC_PCKENSR0);
u32 src_pckensr1 = readl(src_base + SRC_PCKENSR1);
 
-   seq_printf(s, "Clock:  Boot:   Now:Request: ASKED:\n");
+   seq_puts(s, "Clock:  Boot:   Now:Request: ASKED:\n");
for (i = 0; i < ARRAY_SIZE(src_clk_names); i++) {
u32 pcksrb = (i < 0x20) ? src_pcksr0_boot : src_pcksr1_boot;
u32 pcksr = (i < 0x20) ? src_pcksr0 : src_pcksr1;
-- 
2.12.2

[char-misc-next] mei: drop the TODO from samples

[Tomas Winkler]

The TODO file is not relevant anymore and it's just a leftover from
the time the driver was in the staging tree.

Signed-off-by: Tomas Winkler 
Reviewed-by: Alexander Usyskin 
---
 samples/mei/TODO | 2 --
 1 file changed, 2 deletions(-)
 delete mode 100644 samples/mei/TODO

diff --git a/samples/mei/TODO b/samples/mei/TODO
deleted file mode 100644
index 6b3625d3058c..
--- a/samples/mei/TODO
+++ /dev/null
@@ -1,2 +0,0 @@
-TODO:
-   - Cleanup and split the timer function
-- 
2.9.3

Re: [PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries

[Maxime Ripard]

Hi,

On Thu, Apr 20, 2017 at 11:14:16AM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
> 
> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> unit name, but no reg property
> 
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
> 
> Reported-by: Krzysztof Kozlowski 
> Reported-by: Masahiro Yamada 
> Suggested-by: Mark Rutland 
> Signed-off-by: Viresh Kumar 
> Acked-by: Maxime Ripard 
> Acked-by: Rob Herring 

This patch doesn't apply, please make sure to base them on linux-next

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sumit Semwal]

Hi Marek,

Thanks!

On 20 April 2017 at 13:36, Marek Szyprowski  wrote:
> Hi All,
>
> On 2017-04-20 09:51, Daniel Vetter wrote:
>>
>> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>>>
>>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>>> in highmem.h, the former can be aliased if any dma-buf user includes
>>> that header.
>>>
>>> I'm personally trying to include highmem.h inside scatterlist.h and this
>>> breaks the dma-buf code proper.
>>>
>>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
>>>
>>> To maintain consistency I've renamed all four of kmap* and kunmap* to be
>>> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
>>>
>>> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>>>
>>> Signed-off-by: Logan Gunthorpe 
>>> Reviewed-by: Sinclair Yeh 
>>
>> Acked-by: Daniel Vetter 
>>
>> Probably simplest if we pull this in through the drm-misc tree for 4.12.
>> Can we have an ack for the v4l side for that pls?
>
>
> For the V4L2/videobuf2:
> Acked-by: Marek Szyprowski 
>
I will queue it up for drm-misc-fixes so it gets into 4.12.
>
>
>> Thanks, Daniel
Best,
Sumit.

>>>
>>> ---
>>>
>>> Changes since v1:
>>>
>>> - Added the missing tegra driver (noticed by kbuild robot)
>>> - Rebased off of drm-intel-next to get the i915 selftest that is new
>>> - Fixed nits Sinclair pointed out.
>>>
>>>   drivers/dma-buf/dma-buf.c  | 16 
>>>   drivers/gpu/drm/armada/armada_gem.c|  8 
>>>   drivers/gpu/drm/drm_prime.c|  8 
>>>   drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>>>   drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>>>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>>>   drivers/gpu/drm/tegra/gem.c|  8 
>>>   drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>>>   drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>>>   drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>>>   drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>>>   drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>>>   drivers/staging/android/ion/ion.c  |  8 
>>>   include/linux/dma-buf.h| 22
>>> +++---
>>>   14 files changed, 61 insertions(+), 61 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index f72aaac..512bdbc 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct
>>> dma_buf_export_info *exp_info)
>>>   || !exp_info->ops->map_dma_buf
>>>   || !exp_info->ops->unmap_dma_buf
>>>   || !exp_info->ops->release
>>> - || !exp_info->ops->kmap_atomic
>>> - || !exp_info->ops->kmap
>>> + || !exp_info->ops->map_atomic
>>> + || !exp_info->ops->map
>>>   || !exp_info->ops->mmap)) {
>>> return ERR_PTR(-EINVAL);
>>> }
>>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
>>> unsigned long page_num)
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
>>> +   return dmabuf->ops->map_atomic(dmabuf, page_num);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>>
>>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
>>> unsigned long page_num,
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   if (dmabuf->ops->kunmap_atomic)
>>> -   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
>>> +   if (dmabuf->ops->unmap_atomic)
>>> +   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>>>
>>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned
>>> long page_num)
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   return dmabuf->ops->kmap(dmabuf, page_num);
>>> +   return dmabuf->ops->map(dmabuf, page_num);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kmap);
>>>
>>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned
>>> long page_num,
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   if (dmabuf->ops->kunmap)
>>> -   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
>>> +   if (dmabuf->ops->unmap)
>>> +   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>>>
>>> diff --git a/drivers/gpu/drm/armada/armada_gem.c
>>> b/drivers/gpu/drm/armada/armada_gem.c
>>> index 1597458..d6c2a5d 100644
>>> --- a/drivers/gpu/drm/armada/armada_gem.c
>>> +++ 

[PATCH] ASoC: mediatek: add I2C dependency for CS42XX8

[Arnd Bergmann]

We should not select drivers that depend on I2C when that is disabled,
as it results in a build error:

warning: (SND_SOC_MT2701_WM8960) selects SND_SOC_WM8960 which has unmet direct 
dependencies (SOUND && !M68K && !UML && SND && SND_SOC && I2C)
sound/soc/codecs/wm8960.c:1469:1: error: data definition has no type or storage 
class [-Werror]
sound/soc/codecs/wm8960.c:1469:1: error: type defaults to 'int' in declaration 
of 'module_i2c_driver' [-Werror=implicit-int]

Fixes: 8625c1dbd876 ("ASoC: mediatek: Add mt2701-wm8960 machine driver")
Signed-off-by: Arnd Bergmann 
---
 sound/soc/mediatek/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index c6f39040f71f..5c68797f36c4 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -24,7 +24,7 @@ config SND_SOC_MT2701_CS42448
 
 config SND_SOC_MT2701_WM8960
tristate "ASoc Audio driver for MT2701 with WM8960 codec"
-   depends on SND_SOC_MT2701
+   depends on SND_SOC_MT2701 && I2C
select SND_SOC_WM8960
help
  This adds ASoC driver for Mediatek MT2701 boards
-- 
2.9.0

Re: [PATCH v3 6/9] mm, memory_hotplug: do not associate hotadded memory to zones until online

[Vlastimil Babka]

On 04/10/2017 06:25 PM, Michal Hocko wrote:
> This contains two minor fixes spotted based on testing by Igor Mammedov.
> ---
> From d829579cc7061255f818f9aeaa3aa2cd82fec75a Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Wed, 29 Mar 2017 16:07:00 +0200
> Subject: [PATCH] mm, memory_hotplug: do not associate hotadded memory to zones
>  until online
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> The current memory hotplug implementation relies on having all the
> struct pages associate with a zone/node during the physical hotplug phase
> (arch_add_memory->__add_pages->__add_section->__add_zone). In the vast
> majority of cases this means that they are added to ZONE_NORMAL. This
> has been so since 9d99aaa31f59 ("[PATCH] x86_64: Support memory hotadd
> without sparsemem") and it wasn't a big deal back then because movable
> onlining didn't exist yet.
> 
> Much later memory hotplug wanted to (ab)use ZONE_MOVABLE for movable
> onlining 511c2aba8f07 ("mm, memory-hotplug: dynamic configure movable
> memory and portion memory") and then things got more complicated. Rather
> than reconsidering the zone association which was no longer needed
> (because the memory hotplug already depended on SPARSEMEM) a convoluted
> semantic of zone shifting has been developed. Only the currently last
> memblock or the one adjacent to the zone_movable can be onlined movable.
> This essentially means that the online type changes as the new memblocks
> are added.
> 
> Let's simulate memory hot online manually
> Normal Movable
> 
> /sys/devices/system/memory/memory32/valid_zones:Normal
> /sys/devices/system/memory/memory33/valid_zones:Normal Movable
> 
> /sys/devices/system/memory/memory32/valid_zones:Normal
> /sys/devices/system/memory/memory33/valid_zones:Normal
> /sys/devices/system/memory/memory34/valid_zones:Normal Movable
> 
> /sys/devices/system/memory/memory32/valid_zones:Normal
> /sys/devices/system/memory/memory33/valid_zones:Normal Movable
> /sys/devices/system/memory/memory34/valid_zones:Movable Normal

Commands seem to be missing above?

> This is an awkward semantic because an udev event is sent as soon as the
> block is onlined and an udev handler might want to online it based on
> some policy (e.g. association with a node) but it will inherently race
> with new blocks showing up.
> 
> This patch changes the physical online phase to not associate pages
> with any zone at all. All the pages are just marked reserved and wait
> for the onlining phase to be associated with the zone as per the online
> request. There are only two requirements
>   - existing ZONE_NORMAL and ZONE_MOVABLE cannot overlap
>   - ZONE_NORMAL precedes ZONE_MOVABLE in physical addresses
> the later on is not an inherent requirement and can be changed in the
> future. It preserves the current behavior and made the code slightly
> simpler. This is subject to change in future.
> 
> This means that the same physical online steps as above will lead to the
> following state:
> Normal Movable
> 
> /sys/devices/system/memory/memory32/valid_zones:Normal Movable
> /sys/devices/system/memory/memory33/valid_zones:Normal Movable
> 
> /sys/devices/system/memory/memory32/valid_zones:Normal Movable
> /sys/devices/system/memory/memory33/valid_zones:Normal Movable
> /sys/devices/system/memory/memory34/valid_zones:Normal Movable
> 
> /sys/devices/system/memory/memory32/valid_zones:Normal Movable
> /sys/devices/system/memory/memory33/valid_zones:Normal Movable
> /sys/devices/system/memory/memory34/valid_zones:Movable

Ditto.

> Implementation:
> The current move_pfn_range is reimplemented to check the above
> requirements (allow_online_pfn_range) and then updates the respective
> zone (move_pfn_range_to_zone), the pgdat and links all the pages in the
> pfn range with the zone/node. __add_pages is updated to not require the
> zone and only initializes sections in the range. This allowed to
> simplify the arch_add_memory code (s390 could get rid of quite some
> of code).
> 
> devm_memremap_pages is the only user of arch_add_memory which relies
> on the zone association because it only hooks into the memory hotplug
> only half way. It uses it to associate the new memory with ZONE_DEVICE
> but doesn't allow it to be {on,off}lined via sysfs. This means that this
> particular code path has to call move_pfn_range_to_zone explicitly.
> 
> The original zone shifting code is kept in place and will be removed in
> the follow up patch for an easier review.
> 
> Changes since v1
> - we have to associate the page with the node early (in __add_section),
>   because pfn_to_node depends on struct page containing this
>   information - based on testing by Reza Arbab
> - resize_{zone,pgdat}_range has to check whether they are popoulated -
>   Reza Arbab
> - fix devm_memremap_pages to use pfn rather than physical address -
>   Jérôme Glisse
> - move_pfn_range has to check for intersection with 

Re: [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse

[Arnd Bergmann]

On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen  wrote:
> On 19.04.2017 21:24, Arnd Bergmann wrote:
>>
>> When dma_addr_t and phys_addr_t are not the same size, we get a warning
>> from the dma_alloc_wc function:
>>
>> drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
>> drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of
>> 'dma_alloc_wc' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>>pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
>> ^
>> In file included from drivers/gpu/host1x/cdma.c:22:0:
>> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long
>> long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned
>> int *}'
>>  static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev,
>> size_t size,
>>  ^~~~
>> drivers/gpu/host1x/cdma.c:113:48: error: passing argument 3 of
>> 'dma_alloc_wc' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>>pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
>> ^
>> In file included from drivers/gpu/host1x/cdma.c:22:0:
>> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long
>> long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned
>> int *}'
>>  static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev,
>> size_t size,
>>  ^~~~
>>
>> The problem here is that dma_alloc_wc() returns a pointer to a dma_addr_t
>> that may already be translated by an IOMMU, but the driver passes this
>> into iommu_map() as a physical address. This works by accident only when
>> the IOMMU does not get registered with the DMA API and there is a 1:1
>> mapping between physical addresses as seen by the CPU and the device.
>>
>> The fundamental problem here is the lack of a generic API to do what the
>> driver wants: allocating CPU-visible memory for use by a device through
>> user-defined IOMMU settings. Neither the dma-mapping API nor the IOMMU
>> API can do this by itself, and combining the two is not well-defined.
>>
>> This patch addresses the type mismatch by adding a third pointer into the
>> push_buffer structure: in addition to the address as seen from the CPU
>> and the address inside of the local IOMMU domain, the pb->alloc pointer
>> is the token returned by dma_alloc_wc(), and this is what we later need
>> to pass into dma_free_wc().
>>
>> The address we pass into iommu_map() however is the physical address
>> computed from virt_to_phys(), assuming that the pointer we have here
>> is part of the linear mapping (which is also questionable, e.g. when we
>> have a non-coherent device on ARM32 this may be false). Also, when
>> the DMA API uses the IOMMU to allocate the pointer for the default
>> domain, we end up with two IOMMU mappings for the same physical address.
>>
>
> I think we have a "policy" on Tegra that the DMA API will never allocate
> using the IOMMU (Thierry can elaborate on this), which is why I wrote the
> code with that assumption. Essentially, we have made the DMA API into the
> API that allocates CPU-visible memory.

I don't think this can be a per-platform policy.

> Considering that, I'm wondering if we can just have a temporary local
> dma_addr_t and then cast that to phys_addr_t, combined with a good comment?

That was my first approach, and it does address the warning, but
I did not send it because it still felt too wrong.

 Arnd

Re: [GIT PULL 00/16] clocksource: arm_arch_timer: GTDT-based MMIO timer support

[Fu Wei]

Hi Daniel, Lorenzo, Mark,


On 20 April 2017 at 16:26, Mark Rutland  wrote:
> On Wed, Apr 19, 2017 at 11:39:44PM +0200, Daniel Lezcano wrote:
>> On Wed, Apr 19, 2017 at 05:44:17PM +0100, Mark Rutland wrote:
>> > Hi Daniel,
>
>> > I realise this is a little late, but I would very much appreciate if you 
>> > could
>> > pull these arch timer GTDT patches for v4.12. The series has been largely 
>> > fine
>> > for a while now, and the major hold-ups were edge cases in error handling 
>> > which
>> > have now been addressed.
>
>> Hi Thomas,
>>
>> the series is ok for me. Is it possible to pull these changes directly in
>> tip/timers/core?
>
> The tip-bot tells me it was.
>
> Many thanks for picking these up, it's much appreciated.

Great thanks to all of you, I very appreciate all the help and
suggestion from you :-)

>
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

[Dmitry Vyukov]

On Thu, Apr 20, 2017 at 1:51 AM, David Ahern  wrote:
> On 4/19/17 5:47 PM, Cong Wang wrote:
>> On Wed, Apr 19, 2017 at 9:12 AM, Andrey Konovalov  
>> wrote:
>>>
>>> Anyway, I just finished simplifying the reproducer. Give this one a try.
>>
>> Thanks for providing such a minimal reproducer!
>>
>> The following patch could fix this crash, but I am not 100% sure if we should
>> just clear these bits or reject them with an errno.
>>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 9db14189..cf524c2 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -2086,7 +2086,7 @@ static struct rt6_info
>> *ip6_route_info_create(struct fib6_config *cfg)
>> } else
>> rt->rt6i_prefsrc.plen = 0;
>>
>> -   rt->rt6i_flags = cfg->fc_flags;
>> +   rt->rt6i_flags = cfg->fc_flags & ~(RTF_PCPU | RTF_CACHE);
>>
>>  install_route:
>> rt->dst.dev = dev;
>>
>
> I sent a patch returning EINVAL if RTF_PCPU is set in fc_flags


Andrey, does it fix the other crashes?

[PATCH v2] mdio_bus: Issue GPIO RESET to PHYs.

[Roger Quadros]

Some boards [1] leave the PHYs at an invalid state
during system power-up or reset thus causing unreliability
issues with the PHY which manifests as PHY not being detected
or link not functional. To fix this, these PHYs need to be RESET
via a GPIO connected to the PHY's RESET pin.

Some boards have a single GPIO controlling the PHY RESET pin of all
PHYs on the bus whereas some others have separate GPIOs controlling
individual PHY RESETs.

In both cases, the RESET de-assertion cannot be done in the PHY driver
as the PHY will not probe till its reset is de-asserted.
So do the RESET de-assertion in the MDIO bus driver.

[1] - am572x-idk, am571x-idk, a437x-idk

Signed-off-by: Roger Quadros 
---
v2:
- add device tree binding document (mdio.txt)
- specify default reset delay in of_mdio.c instead of mdio_bus.c

 Documentation/devicetree/bindings/net/mdio.txt | 20 
 drivers/net/phy/mdio_bus.c | 22 ++
 drivers/of/of_mdio.c   |  7 +++
 include/linux/phy.h|  5 +
 4 files changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/mdio.txt

diff --git a/Documentation/devicetree/bindings/net/mdio.txt 
b/Documentation/devicetree/bindings/net/mdio.txt
new file mode 100644
index 000..6e703d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mdio.txt
@@ -0,0 +1,20 @@
+Common MDIO bus properties.
+
+These are generic properties that can apply to any MDIO bus.
+
+Optional properties:
+- reset-gpios: List of one or more GPIOs that control the RESET lines
+  of the PHYs on that MDIO bus.
+- reset-delay-us: RESET pulse width as per PHY datasheet.
+
+Example :
+
+   davinci_mdio: ethernet@0x5c03 {
+   compatible = "ti,davinci_mdio";
+   ti,hwmods = "davinci_mdio";
+   reg = <0x5c03 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+   reset-delay-us = <2>;   /* PHY datasheet states 1uS min */
+   };
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index fa7d51f..b353d99 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -22,8 +22,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -307,6 +310,7 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
 {
struct mdio_device *mdiodev;
int i, err;
+   struct gpio_desc *gpiod;
 
if (NULL == bus || NULL == bus->name ||
NULL == bus->read || NULL == bus->write)
@@ -333,6 +337,24 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
if (bus->reset)
bus->reset(bus);
 
+   /* de-assert bus level PHY GPIO resets */
+   for (i = 0; i < bus->num_reset_gpios; i++) {
+   gpiod = devm_gpiod_get_index(>dev, "reset", i,
+GPIOD_OUT_LOW);
+   if (IS_ERR(gpiod)) {
+   err = PTR_ERR(gpiod);
+   if (err != -ENOENT) {
+   pr_err("mii_bus %s couldn't get reset GPIO\n",
+  bus->id);
+   return err;
+   }
+   } else {
+   gpiod_set_value_cansleep(gpiod, 1);
+   udelay(bus->reset_delay_us);
+   gpiod_set_value_cansleep(gpiod, 0);
+   }
+   }
+
for (i = 0; i < PHY_MAX_ADDR; i++) {
if ((bus->phy_mask & (1 << i)) == 0) {
struct phy_device *phydev;
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 0b29798..7e4c80f 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 
+#define DEFAULT_GPIO_RESET_DELAY   10  /* in microseconds */
+
 MODULE_AUTHOR("Grant Likely ");
 MODULE_LICENSE("GPL");
 
@@ -221,6 +223,11 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
 
mdio->dev.of_node = np;
 
+   /* Get bus level PHY reset GPIO details */
+   mdio->reset_delay_us = DEFAULT_GPIO_RESET_DELAY;
+   of_property_read_u32(np, "reset-delay-us", >reset_delay_us);
+   mdio->num_reset_gpios = of_gpio_named_count(np, "reset-gpios");
+
/* Register the MDIO bus */
rc = mdiobus_register(mdio);
if (rc)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 43a7748..80a6574 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -217,6 +217,11 @@ struct mii_bus {
 * matching its address
 */
int irq[PHY_MAX_ADDR];
+
+   /* GPIO reset pulse width in uS */
+   int reset_delay_us;
+   /* Number of reset GPIOs */
+   int num_reset_gpios;
 };
 

Re: [PATCHv6] net: dsa: add SMSC/Microchip LAN9303 three port ethernet switch driver

[David Miller]

From: Juergen Borleis 
Date: Tue, 18 Apr 2017 10:48:23 +0200

> The LAN9303 is a three port 10/100 ethernet switch with integrated phys
> for the two external ethernet ports. The third port is an RMII/MII
> interface to a host master network interface (e.g. fixed link).
> 
> While the LAN9303 device itself supports offload packet processing, this
> driver does not make use of it yet. This driver just configures the device
> to provide two separate network interfaces (which is the default state of
> a DSA device).
> 
> Please note: the "MDIO managed mode" driver part isn't tested yet. I have
> used and tested the "I2C managed mode" only.
> 
> Changes in v6:
 ...

Series applied, thanks.

Re: [PATCH 2/3] x86/intel_rdt: Trim whitespace while parsing schemata input

[Shivappa Vikas]

On Thu, 20 Apr 2017, Thomas Gleixner wrote:


On Wed, 19 Apr 2017, Vikas Shivappa wrote:


Schemata is displayed in tabular format which introduces some whitespace
to show data in a tabular format. If user wants to input the same data
that is displayed, the parsing fails. Trim the leading and trailing
whitespace to help parse such data.

Reported-by: Prakhya, Sai Praneeth 
Signed-off-by: Vikas Shivappa 
Tested-by: Prakhya, Sai Praneeth 
---
 arch/x86/kernel/cpu/intel_rdt_schemata.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel_rdt_schemata.c 
b/arch/x86/kernel/cpu/intel_rdt_schemata.c
index 9467a00..3cfa1ca 100644
--- a/arch/x86/kernel/cpu/intel_rdt_schemata.c
+++ b/arch/x86/kernel/cpu/intel_rdt_schemata.c
@@ -143,7 +143,7 @@ static int parse_line(char *line, struct rdt_resource *r)
return -EINVAL;
list_for_each_entry(d, >domains, list) {
if (d->id == dom_id) {
-   if (r->parse_ctrlval(dom, r, d))
+   if (r->parse_ctrlval(strim(dom), r, d))
return -EINVAL;
goto next;
}
@@ -220,7 +220,7 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of,
goto out;
}
for_each_enabled_rdt_resource(r) {
-   if (!strcmp(resname, r->name) &&
+   if (!strcmp(strim(resname), r->name) &&


Both strims() invocations are just silly. They can be done before the loop
once instead of doing them over and over again.


Will fix. I went overboard not wanting to add a line

Thanks,
Vikas



Thanks,

tglx

Re: [PATCH 2/3] x86/intel_rdt: Trim whitespace while parsing schemata input

[Thomas Gleixner]

On Thu, 20 Apr 2017, Shivappa Vikas wrote:
> Will fix. I went overboard not wanting to add a line

Finish reading the thread before you start :)

Re: [PATCH 3/4] tty/serdev: add serdev registration interface

[Rob Herring]

On Tue, Apr 11, 2017 at 12:07 PM, Johan Hovold  wrote:
> Add a new interface for registering a serdev controller and clients, and
> a helper function to deregister serdev devices (or a tty device) that
> were previously registered using the new interface.
>
> Once every driver currently using the tty_port_register_device() helpers
> have been vetted and converted to use the new serdev registration
> interface (at least for deregistration), we can move serdev registration
> to the current helpers and get rid of the serdev-specific functions.

I don't really think this is necessary. While in theory any tty port
can work with serdev, the reality is it only ever going to be used
with a few. There's about 31 possible drivers. Of those, there's a
fair number that an attached device is not going to make sense (e.g.
ISDN CAPI, rfcomm?, goldfish, etc.). Second, right now serdev only
works with DT binding. There are only 3 drivers supporting DT:
serial_core, goldfish, and ehv_bytechan. Likely drivers I'm aware of
to use serdev in addition to serial_core are USB serial and greybus.
But for those, we currently only could support them if the whole bus
topology is described in DT. Otherwise, we first have to figure out
how to apply DT overlays to arbitrary devices not described in DT.

OTOH, we are at least explicit with what tty ports support serdev.

Rob

Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock

[Peter Zijlstra]

On Thu, Apr 20, 2017 at 10:13:26AM -0700, Davidlohr Bueso wrote:

> I have thought of some heuristics for avoiding sleeping under certain
> constraints, which could mitigate the spinning step we loose, but I fear it
> will never be exactly as fast as rwsems -- just consider
> we always take the tree->lock.

But tree->lock is a spinlock, so while this gets us out of rwsem-xadd
territory for the fast paths, the whole lock-stealing and optimistic
spinning stuff is on a different scale.

Those are about avoiding actually going to sleep and having to be woken
up (and waiting to become running) again, which is a long time.

Re: [PATCH 2/2] tick: Make sure tick timer is active when bypassing reprogramming

[Thomas Gleixner]

On Thu, 20 Apr 2017, Frederic Weisbecker wrote:

> So far we have run into too much troubles with the optimization path
> that skips reprogramming the clock on IRQ exit when the expiration
> deadline hasn't changed. If by accident the cached deadline happens to
> be out of sync with the hardware deadline, the buggy result and its
> cause are hard to investigate. So lets detect and warn about the issue
> early.
> 
> Signed-off-by: Frederic Weisbecker 
> Cc: Tim Wright 
> Cc: Pavel Machek 
> Cc: James Hartsock 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> ---
>  kernel/time/tick-sched.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 502b320..eb1366e 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -783,8 +783,10 @@ static ktime_t tick_nohz_stop_sched_tick(struct 
> tick_sched *ts,
>   tick = expires;
>  
>   /* Skip reprogram of event if its not changed */
> - if (ts->tick_stopped && (expires == ts->next_tick))
> + if (ts->tick_stopped && (expires == ts->next_tick)) {
> + WARN_ON_ONCE(dev->next_event > ts->next_tick);

What about handling it proper ? dev->next_event might be KTIME_MAX,
i.e. no more event for the next 500+ years.

Thanks,

tglx

[PATCH 1/4] scsi: pmcraid: use __iomem pointers for ioctl argument

[Arnd Bergmann]

kernelci.org reports a new compile warning for old code in the pmcraid
driver:

arch/mips/include/asm/uaccess.h:138:21: warning: passing argument 1 of 
'__access_ok' makes pointer from integer without a cast [-Wint-conversion]

The warning got introduced by a cleanup to the access_ok() helper
that requires the argument to be a pointer, where the old version
silently accepts 'unsigned long' arguments as it still does on most
other architectures.

The new behavior in MIPS however seems absolutely sensible, and so far I
could only find one other file with the same issue, so the best solution
seems to be to clean up the pmcraid driver.

This makes the driver consistently use 'void __iomem *' pointers for
passing around the address of the user space ioctl arguments, which gets
rid of the kernelci warning as well as several sparse warnings.

Fixes: f0a955f4eeec ("mips: sanitize __access_ok()")
Cc: Alexander Viro 
Signed-off-by: Arnd Bergmann 
---
I wanted to be sure that I get all the __iomem annotations right, so
I ended up fixing all other sparse warnings as well, see the three
follow-up patches.
---
 drivers/scsi/pmcraid.c | 44 
 1 file changed, 16 insertions(+), 28 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 49e70a383afa..096c704ca39a 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -3325,7 +3325,7 @@ static struct pmcraid_sglist *pmcraid_alloc_sglist(int 
buflen)
  */
 static int pmcraid_copy_sglist(
struct pmcraid_sglist *sglist,
-   unsigned long buffer,
+   void __user *buffer,
u32 len,
int direction
 )
@@ -3346,11 +3346,9 @@ static int pmcraid_copy_sglist(
 
kaddr = kmap(page);
if (direction == DMA_TO_DEVICE)
-   rc = __copy_from_user(kaddr,
- (void *)buffer,
- bsize_elem);
+   rc = __copy_from_user(kaddr, buffer, bsize_elem);
else
-   rc = __copy_to_user((void *)buffer, kaddr, bsize_elem);
+   rc = __copy_to_user(buffer, kaddr, bsize_elem);
 
kunmap(page);
 
@@ -3368,13 +3366,9 @@ static int pmcraid_copy_sglist(
kaddr = kmap(page);
 
if (direction == DMA_TO_DEVICE)
-   rc = __copy_from_user(kaddr,
- (void *)buffer,
- len % bsize_elem);
+   rc = __copy_from_user(kaddr, buffer, len % bsize_elem);
else
-   rc = __copy_to_user((void *)buffer,
-   kaddr,
-   len % bsize_elem);
+   rc = __copy_to_user(buffer, kaddr, len % bsize_elem);
 
kunmap(page);
 
@@ -3652,17 +3646,17 @@ static long pmcraid_ioctl_passthrough(
struct pmcraid_instance *pinstance,
unsigned int ioctl_cmd,
unsigned int buflen,
-   unsigned long arg
+   void __user *arg
 )
 {
struct pmcraid_passthrough_ioctl_buffer *buffer;
struct pmcraid_ioarcb *ioarcb;
struct pmcraid_cmd *cmd;
struct pmcraid_cmd *cancel_cmd;
-   unsigned long request_buffer;
+   void __user *request_buffer;
unsigned long request_offset;
unsigned long lock_flags;
-   void *ioasa;
+   void __user *ioasa;
u32 ioasc;
int request_size;
int buffer_size;
@@ -3701,13 +3695,10 @@ static long pmcraid_ioctl_passthrough(
 
request_buffer = arg + request_offset;
 
-   rc = __copy_from_user(buffer,
-(struct pmcraid_passthrough_ioctl_buffer *) arg,
+   rc = __copy_from_user(buffer, arg,
 sizeof(struct pmcraid_passthrough_ioctl_buffer));
 
-   ioasa =
-   (void *)(arg +
-   offsetof(struct pmcraid_passthrough_ioctl_buffer, ioasa));
+   ioasa = arg + offsetof(struct pmcraid_passthrough_ioctl_buffer, ioasa);
 
if (rc) {
pmcraid_err("ioctl: can't copy passthrough buffer\n");
@@ -4021,6 +4012,7 @@ static long pmcraid_chr_ioctl(
 {
struct pmcraid_instance *pinstance = NULL;
struct pmcraid_ioctl_header *hdr = NULL;
+   void __user *argp = (void __user *)arg;
int retval = -ENOTTY;
 
hdr = kmalloc(sizeof(struct pmcraid_ioctl_header), GFP_KERNEL);
@@ -4030,7 +4022,7 @@ static long pmcraid_chr_ioctl(
return -ENOMEM;
}
 
-   retval = pmcraid_check_ioctl_buffer(cmd, (void *)arg, hdr);
+   retval = pmcraid_check_ioctl_buffer(cmd, argp, hdr);
 
if (retval) {
pmcraid_info("chr_ioctl: header check failed\n");
@@ -4055,10 +4047,8 @@ static long pmcraid_chr_ioctl(
   

[PATCH 2/4] scsi: pmcraid: fix lock imbalance in pmcraid_reset_reload()

[Arnd Bergmann]

sparse found a bug that has always been present since the driver
was merged:

drivers/scsi/pmcraid.c:2353:12: warning: context imbalance in 
'pmcraid_reset_reload' - different lock contexts for basic block

This adds the missing unlock at the end of the function. I could
not figure out if this will happen in practice, but I could not
prove that it doesn't happen, so to be on the safe side, let's
backport this fix.

Cc: sta...@vger.kernel.org
Fixes: 89a368104150 ("[SCSI] pmcraid: PMC-Sierra MaxRAID driver to support 
6Gb/s SAS RAID controller")
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/pmcraid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 096c704ca39a..35087e94c2ad 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -2411,8 +2411,11 @@ static int pmcraid_reset_reload(
scsi_unblock_requests(pinstance->host);
if (pinstance->ioa_state == target_state)
reset = 0;
+   spin_lock_irqsave(pinstance->host->host_lock, lock_flags);
}
 
+   spin_unlock_irqrestore(pinstance->host->host_lock, lock_flags);
+
return reset;
 }
 
-- 
2.9.0

[PATCH 3/4] scsi: pmcraid: fix endianess sparse annotations

[Arnd Bergmann]

The use of le32_to_cpu() etc in this driver looks completely arbitrary.
It may have made sense at some point, but it is not applied consistently,
so this driver presumably won't work on big-endian kernel builds.

Unfortunately it's unclear whether the type names or the calls to
le32_to_cpu() are the correct ones. I'm taking educated guesses here
and assume that most of the __le32 and __le16 annotations are correct,
adding the conversion helpers whereever we access those fields.

The exceptions are the 'fw_version' field that is always accessed as
big-endian, so I'm changing the type here, and the 'hrrq' values that
are accessed as little-endian, so I'm changing those the other way.

None of these changes should have any effect on little-endian
architectures like x86, but it addresses the sparse warnings.

Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/pmcraid.c | 95 +-
 drivers/scsi/pmcraid.h |  8 ++---
 2 files changed, 51 insertions(+), 52 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 35087e94c2ad..58c7511c5bd5 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -175,7 +175,7 @@ static int pmcraid_slave_alloc(struct scsi_device *scsi_dev)
if (fw_version <= PMCRAID_FW_VERSION_1)
target = temp->cfg_entry.unique_flags1;
else
-   target = temp->cfg_entry.array_id & 0xFF;
+   target = le16_to_cpu(temp->cfg_entry.array_id) 
& 0xFF;
 
if (target > PMCRAID_MAX_VSET_TARGETS)
continue;
@@ -330,7 +330,7 @@ static void pmcraid_init_cmdblk(struct pmcraid_cmd *cmd, 
int index)
ioarcb->request_flags0 = 0;
ioarcb->request_flags1 = 0;
ioarcb->cmd_timeout = 0;
-   ioarcb->ioarcb_bus_addr &= (~0x1FULL);
+   ioarcb->ioarcb_bus_addr &= cpu_to_le64(~0x1FULL);
ioarcb->ioadl_bus_addr = 0;
ioarcb->ioadl_length = 0;
ioarcb->data_transfer_length = 0;
@@ -898,8 +898,7 @@ static void _pmcraid_fire_command(struct pmcraid_cmd *cmd)
 
/* driver writes lower 32-bit value of IOARCB address only */
mb();
-   iowrite32(le32_to_cpu(cmd->ioa_cb->ioarcb.ioarcb_bus_addr),
- pinstance->ioarrin);
+   iowrite32(le64_to_cpu(cmd->ioa_cb->ioarcb.ioarcb_bus_addr), 
pinstance->ioarrin);
 }
 
 /**
@@ -1051,7 +1050,7 @@ static void pmcraid_get_fwversion(struct pmcraid_cmd *cmd)
offsetof(struct pmcraid_ioarcb,
add_data.u.ioadl[0]));
ioarcb->ioadl_length = cpu_to_le32(sizeof(struct pmcraid_ioadl_desc));
-   ioarcb->ioarcb_bus_addr &= ~(0x1FULL);
+   ioarcb->ioarcb_bus_addr &= cpu_to_le64(~(0x1FULL));
 
ioarcb->request_flags0 |= NO_LINK_DESCS;
ioarcb->data_transfer_length = cpu_to_le32(data_size);
@@ -1077,7 +1076,7 @@ static void pmcraid_identify_hrrq(struct pmcraid_cmd *cmd)
struct pmcraid_ioarcb *ioarcb = >ioa_cb->ioarcb;
int index = cmd->hrrq_index;
__be64 hrrq_addr = cpu_to_be64(pinstance->hrrq_start_bus_addr[index]);
-   u32 hrrq_size = cpu_to_be32(sizeof(u32) * PMCRAID_MAX_CMD);
+   __be32 hrrq_size = cpu_to_be32(sizeof(u32) * PMCRAID_MAX_CMD);
void (*done_function)(struct pmcraid_cmd *);
 
pmcraid_reinit_cmdblk(cmd);
@@ -1202,7 +1201,7 @@ static struct pmcraid_cmd *pmcraid_init_hcam
 
ioadl[0].flags |= IOADL_FLAGS_READ_LAST;
ioadl[0].data_len = cpu_to_le32(rcb_size);
-   ioadl[0].address = cpu_to_le32(dma);
+   ioadl[0].address = cpu_to_le64(dma);
 
cmd->cmd_done = cmd_done;
return cmd;
@@ -1237,7 +1236,13 @@ static void pmcraid_prepare_cancel_cmd(
 )
 {
struct pmcraid_ioarcb *ioarcb = >ioa_cb->ioarcb;
-   __be64 ioarcb_addr = cmd_to_cancel->ioa_cb->ioarcb.ioarcb_bus_addr;
+   __be64 ioarcb_addr;
+
+   /* IOARCB address of the command to be cancelled is given in
+* cdb[2]..cdb[9] is Big-Endian format. Note that length bits in
+* IOARCB address are not masked.
+*/
+   ioarcb_addr = 
cpu_to_be64(le64_to_cpu(cmd_to_cancel->ioa_cb->ioarcb.ioarcb_bus_addr));
 
/* Get the resource handle to where the command to be aborted has been
 * sent.
@@ -1247,11 +1252,6 @@ static void pmcraid_prepare_cancel_cmd(
memset(ioarcb->cdb, 0, PMCRAID_MAX_CDB_LEN);
ioarcb->cdb[0] = PMCRAID_ABORT_CMD;
 
-   /* IOARCB address of the command to be cancelled is given in
-* cdb[2]..cdb[9] is Big-Endian format. Note that length bits in
-* IOARCB address are not masked.
-*/
-   ioarcb_addr = cpu_to_be64(ioarcb_addr);
memcpy(&(ioarcb->cdb[2]), _addr, sizeof(ioarcb_addr));
 }
 
@@ -1493,7 +1493,7 @@ 

[PATCH 4/4] scsi: pmcraid: fix minor sparse warnings

[Arnd Bergmann]

pmcraid_minor is only used in this one file and should be 'static' as suggested
by sparse:

drivers/scsi/pmcraid.c:80:1: warning: symbol 'pmcraid_minor' was not declared. 
Should it be static?

In Linux coding style, a literal '0' integer should not be used to represent
a NULL pointer:

drivers/scsi/pmcraid.c:348:29: warning: Using plain integer as NULL pointer
drivers/scsi/pmcraid.c:4824:49: warning: Using plain integer as NULL pointer

Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/pmcraid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 58c7511c5bd5..63298f017171 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -77,7 +77,7 @@ static atomic_t pmcraid_adapter_count = ATOMIC_INIT(0);
  */
 static unsigned int pmcraid_major;
 static struct class *pmcraid_class;
-DECLARE_BITMAP(pmcraid_minor, PMCRAID_MAX_ADAPTERS);
+static DECLARE_BITMAP(pmcraid_minor, PMCRAID_MAX_ADAPTERS);
 
 /*
  * Module parameters
@@ -345,7 +345,7 @@ static void pmcraid_init_cmdblk(struct pmcraid_cmd *cmd, 
int index)
cmd->scsi_cmd = NULL;
cmd->release = 0;
cmd->completion_req = 0;
-   cmd->sense_buffer = 0;
+   cmd->sense_buffer = NULL;
cmd->sense_buffer_dma = 0;
cmd->dma_handle = 0;
init_timer(>timer);
@@ -4824,7 +4824,7 @@ static int pmcraid_allocate_host_rrqs(struct 
pmcraid_instance *pinstance)
buffer_size,
&(pinstance->hrrq_start_bus_addr[i]));
 
-   if (pinstance->hrrq_start[i] == 0) {
+   if (!pinstance->hrrq_start[i]) {
pmcraid_err("pci_alloc failed for hrrq vector : %d\n",
i);
pmcraid_release_host_rrqs(pinstance, i);
-- 
2.9.0

Re: [PATCH v3] kbuild: Add support to generate LLVM bitcode files

[Matthias Kaehlcke]

El Tue, Apr 04, 2017 at 10:27:06AM -0700 Matthias Kaehlcke ha dit:

> From: Vinícius Tinti 
> 
> Add rules to kbuild in order to generate LLVM bitcode files with the .ll
> extension when using clang.
> 
>   # from c code
>   CC=clang make kernel/pid.ll
> 
>   # from asm code
>   CC=clang make arch/x86/kernel/preempt.ll
> 
> From: Vinícius Tinti 
> Signed-off-by: Vinícius Tinti 
> Signed-off-by: Behan Webster 
> Signed-off-by: Matthias Kaehlcke 
> ---

Ping, any comments on this patch?

Thanks

Matthias

Re: [PATCH v2] NFS: Avoid cross-structure casting

[Trond Myklebust]

On Wed, 2017-04-12 at 11:59 -0700, Kees Cook wrote:
> On Wed, Apr 5, 2017 at 8:29 AM, Kees Cook 
> wrote:
> > When the call to nfs_devname() fails, the error path attempts to
> > retain
> > the error via the mnt variable, but this requires a cast across
> > very
> > different types (char * to struct vfsmount *), which the upcoming
> > structure layout randomization plugin flags as being potentially
> > dangerous in the face of randomization. This is a false positive,
> > but
> > what this code actually wants to do is retain the error value, so
> > this
> > patch explicitly sets it, instead of using what seems to be an
> > unexpected cast.
> > 
> > Signed-off-by: Kees Cook 
> 
> If I can get an Acked-by on this, I could push it via the gcc-plugin
> tree.
> 
> Thanks!
> 
> -Kees
> 
> > ---
> > v2: duh, use ERR_CAST. thanks neilb!
> > ---
> >  fs/nfs/namespace.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
> > index 786f17580582..8ca5d147124d 100644
> > --- a/fs/nfs/namespace.c
> > +++ b/fs/nfs/namespace.c
> > @@ -259,9 +259,10 @@ struct vfsmount *nfs_do_submount(struct dentry
> > *dentry, struct nfs_fh *fh,
> > if (page == NULL)
> > goto out;
> > devname = nfs_devname(dentry, page, PAGE_SIZE);
> > -   mnt = (struct vfsmount *)devname;
> > -   if (IS_ERR(devname))
> > +   if (IS_ERR(devname)) {
> > +   mnt = ERR_CAST(devname);
> > goto free_page;
> > +   }
> > mnt = nfs_do_clone_mount(NFS_SB(dentry->d_sb), devname,
> > );
> >  free_page:
> > free_page((unsigned long)page);
> > --
> > 2.7.4
> > 
> > 
> > --
> > Kees Cook
> > Pixel Security
> 

Acked-by: Trond Myklebust 

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.com

Re: [PATCH v2 2/9] staging: ccree: add ahash support

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[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/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023


coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/ccree/ssi_hash.c:317:2-7: WARNING: NULL check before freeing 
>> functions like kfree, debugfs_remove, debugfs_remove_recursive or 
>> usb_free_urb is not needed. Maybe consider reorganizing relevant code to 
>> avoid passing NULL values.
   drivers/staging/ccree/ssi_hash.c:320:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:323:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:373:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:375:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:377:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:379:3-8: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:381:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:383:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.

Please review and possibly fold the followup patch.

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

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

[kbuild test robot]

drivers/staging/ccree/ssi_hash.c:317:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:320:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:323:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:373:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:375:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:377:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:379:3-8: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:381:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:383:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_hash.c |   27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -313,14 +313,11 @@ fail4:
state->digest_buff_dma_addr = 0;
}
 fail3:
-   if (state->opad_digest_buff != NULL)
-   kfree(state->opad_digest_buff);
+   kfree(state->opad_digest_buff);
 fail2:
-   if (state->digest_bytes_len != NULL)
-   kfree(state->digest_bytes_len);
+   kfree(state->digest_bytes_len);
 fail1:
-   if (state->digest_buff != NULL)
-   kfree(state->digest_buff);
+kfree(state->digest_buff);
 fail_digest_result_buff:
 if (state->digest_result_buff != NULL) {
 kfree(state->digest_result_buff);
@@ -369,18 +366,12 @@ static void ssi_hash_unmap_request(struc
state->opad_digest_dma_addr = 0;
}
 
-   if (state->opad_digest_buff != NULL)
-   kfree(state->opad_digest_buff);
-   if (state->digest_bytes_len != NULL)
-   kfree(state->digest_bytes_len);
-   if (state->digest_buff != NULL)
-   kfree(state->digest_buff);
-   if (state->digest_result_buff != NULL) 
-   kfree(state->digest_result_buff);
-   if (state->buff1 != NULL) 
-   kfree(state->buff1);
-   if (state->buff0 != NULL)
-   kfree(state->buff0);
+   kfree(state->opad_digest_buff);
+   kfree(state->digest_bytes_len);
+   kfree(state->digest_buff);
+   kfree(state->digest_result_buff);
+   kfree(state->buff1);
+   kfree(state->buff0);
 }
 
 static void ssi_hash_unmap_result(struct device *dev, 

Re: [PATCH] timer: fix timer_migration to accept only 0 and 1

[Myungho Jung]

On Thu, Apr 20, 2017 at 07:45:49PM +0200, Thomas Gleixner wrote:
> On Thu, 20 Apr 2017, Myungho Jung wrote:
> > I understood. I'll resubmit the patch after fixing log.
> 
> I recommend to check your inbox first.
> 
> Thanks,
> 
>   tglx
Yes, I confirmed a message from tip-bot. I'll refer to it.

Thanks,
Myungho

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

[Julien Grall]

Hi,

On 18/04/17 19:51, Juergen Gross wrote:

On 18/04/17 20:46, Stefano Stabellini wrote:

On Tue, 18 Apr 2017, Juergen Gross wrote:

On 18/04/17 20:37, Stefano Stabellini wrote:

On Thu, 6 Apr 2017, Juergen Gross wrote:

On 06/04/17 18:43, Daniel Kiper wrote:

On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:

On 06/04/17 18:06, Daniel Kiper wrote:

Hi Julien,

On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:

Hi Daniel,

On 06/04/17 16:20, Daniel Kiper wrote:

On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:

On 06/04/17 16:27, Daniel Kiper wrote:

On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:

Hi Juergen,

On 06/04/17 07:23, Juergen Gross wrote:

On 05/04/17 21:49, Boris Ostrovsky wrote:

On 04/05/2017 02:14 PM, Julien Grall wrote:

The x86 code has theoritically a similar issue, altought EFI does not
seem to be the preferred method. I have left it unimplemented on x86 and
CCed Linux Xen x86 maintainers to know their view here.


(+Daniel)

This could be a problem for x86 as well, at least theoretically.
xen_machine_power_off() may call pm_power_off(), which is efi.reset_system.

So I think we should have a similar routine there.


+1

I don't see any problem with such a routine added, in contrast to
potential "reboots" instead of power off without it.

So I think this dummy xen_efi_reset_system() should be added to
drivers/xen/efi.c instead.


I will resend the patch during day with xen_efi_reset_system moved
to common code and implement the x86 counterpart (thought, I will
not be able to test it).


I think that this is ARM specific issue. On x86 machine_restart() calls
xen_restart(). Hence, everything works. So, I think that it should be
fixed only for ARM. Anyway, please CC me when you send a patch.


What about xen_machine_power_off() (as stated in Boris' mail)?


Guys what do you think about that:

--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -55,7 +55,7 @@ static void efi_power_off(void)

static int __init efi_shutdown_init(void)
{
-   if (!efi_enabled(EFI_RUNTIME_SERVICES))
+   if (!efi_enabled(EFI_RUNTIME_SERVICES) || efi_enabled(EFI_PARAVIRT))
   return -ENODEV;

   if (efi_poweroff_required())


Julien, for ARM64 please take a look at 
arch/arm64/kernel/efi.c:efi_poweroff_required(void).

I hope that tweaks for both files should solve our problem.


This sounds good for power off (I haven't tried to power off DOM0
yet). But this will not solve the restart problem (see
machine_restart in arch/arm64/kernel/process.c) which call directly
efi_reboot.


Hmmm... It seems to me that efi.reset_system override with empty function
in arch/arm/xen/efi.c is the best solution. So, I see three patches here.
One for drivers/firmware/efi/reboot.c, one for arch/arm/xen/efi.c and one
for arch/arm64/kernel/efi.c. Does it make sense?


I still think the empty function should be in drivers/xen/efi.c and we
should use it in arch/x86/xen/efi.c, too.


If you wish we can go that way too. Though I thing that we should fix
drivers/firmware/efi/reboot.c:efi_shutdown_init() too. Just in case.


Sure, go ahead. I won't object.


For the Xen on ARM side, the original patch that started this thread
(20170405181417.15985-1-julien.gr...@arm.com) is good to go, right?



As I said: the dummy xen_efi_reset_system() should be in
drivers/xen/efi.c


OK. Who is working on it?


Didn't Julien say he would do it?


Yes. I looked at bit closer to the problem mention with power off. 
xen_efi_reset_system cannot be a NOP because there may not be fallback 
alternatives (see machine_power_off in arch/arm64/kernel/process.c)


So I think we would have to translate EFI_RESET* to Xen SHUTDOWN_* and 
then call HYPERVISOR_sched_op directly.


I will send a new version soon.

Cheers,

--
Julien Grall

Re: [RFC][PATCH] selftests: ftrace: Allow some tests to be run in a tracing instance

[Steven Rostedt]

On Thu, 20 Apr 2017 13:30:34 -0400
Steven Rostedt  wrote:

> An tracing instance has several of the same capabilities as the top level
> instance, but may be implemented slightly different. Instead of just writing
> tests that duplicat the same test cases of the top level instance, allow a
> test to be written for both the top level as well as for an instance.
> 
> If a test case can be run in both the top level as well as in an tracing
> instance directory, then it should have a ".itc" extension instead of just
> the ".tc" extension.
> 
> Cc: Shuah Khan 
> Cc: Masami Hiramatsu 
> Cc: Namhyung Kim 
> Signed-off-by: Steven Rostedt (VMware) 
> ---

Updated with:

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 889ec67..5e04f53 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -295,7 +295,7 @@ for t in $TEST_CASES; do
 done
 
 if [ $RUN_INSTANCES -eq 1 ]; then
-echo "Running tests in an tracing instance:"
+echo "Running tests in a tracing instance:"
 for t in $TEST_CASES; do
if [ "${t/*./}" != "itc" ]; then
continue


-- Steve

[PATCH] lightnvm: propagate pblk_init return to userspace

[Rakesh Pandit]

>From userspace calling ioctl(NVM_DEV_CREATE) was returning ENOMEM for
invalid arguments even though pblk (pblk_init) was returning correctly
-EINVAL to nvm_create_tgt inside core.  This patch propagates the
correct return value to userspace.

Because pblk was introduced recently this only needs to go in 4.12.

Fixes: a4bd217b4326 ("lightnvm: physical block device (pblk) target")
Signed-off-by: Rakesh Pandit 
---
 drivers/lightnvm/core.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5d7aa45..54a06c3 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -235,6 +235,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
struct nvm_target *t;
struct nvm_tgt_dev *tgt_dev;
void *targetdata;
+   int ret;
 
tt = nvm_find_target_type(create->tgttype, 1);
if (!tt) {
@@ -255,22 +256,29 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
return -ENOMEM;
 
t = kmalloc(sizeof(struct nvm_target), GFP_KERNEL);
-   if (!t)
+   if (!t) {
+   ret = -ENOMEM;
goto err_reserve;
+   }
 
tgt_dev = nvm_create_tgt_dev(dev, s->lun_begin, s->lun_end);
if (!tgt_dev) {
pr_err("nvm: could not create target device\n");
+   ret = -ENOMEM;
goto err_t;
}
 
tdisk = alloc_disk(0);
-   if (!tdisk)
+   if (!tdisk) {
+   ret = -ENOMEM;
goto err_dev;
+   }
 
tqueue = blk_alloc_queue_node(GFP_KERNEL, dev->q->node);
-   if (!tqueue)
+   if (!tqueue) {
+   ret = -ENOMEM;
goto err_disk;
+   }
blk_queue_make_request(tqueue, tt->make_rq);
 
strlcpy(tdisk->disk_name, create->tgtname, sizeof(tdisk->disk_name));
@@ -281,8 +289,10 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
tdisk->queue = tqueue;
 
targetdata = tt->init(tgt_dev, tdisk, create->flags);
-   if (IS_ERR(targetdata))
+   if (IS_ERR(targetdata)) {
+   ret = PTR_ERR(targetdata);
goto err_init;
+   }
 
tdisk->private_data = targetdata;
tqueue->queuedata = targetdata;
@@ -292,8 +302,10 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
set_capacity(tdisk, tt->capacity(targetdata));
add_disk(tdisk);
 
-   if (tt->sysfs_init && tt->sysfs_init(tdisk))
+   if (tt->sysfs_init && tt->sysfs_init(tdisk)) {
+   ret = -ENOMEM;
goto err_sysfs;
+   }
 
t->type = tt;
t->disk = tdisk;
@@ -318,7 +330,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
kfree(t);
 err_reserve:
nvm_release_luns_err(dev, s->lun_begin, s->lun_end);
-   return -ENOMEM;
+   return ret;
 }
 
 static void __nvm_remove_target(struct nvm_target *t)
-- 
2.9.3

Re: [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support

[Yury Norov]

On Thu, Apr 13, 2017 at 08:12:12PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 11, 2017 at 01:35:04AM +0400, Yury Norov wrote:
> 
> > +++ b/arch/arm64/include/asm/qspinlock.h
> > @@ -0,0 +1,20 @@
> > +#ifndef _ASM_ARM64_QSPINLOCK_H
> > +#define _ASM_ARM64_QSPINLOCK_H
> > +
> > +#include 
> > +
> > +#definequeued_spin_unlock queued_spin_unlock
> > +/**
> > + * queued_spin_unlock - release a queued spinlock
> > + * @lock : Pointer to queued spinlock structure
> > + *
> > + * A smp_store_release() on the least-significant byte.
> > + */
> > +static inline void queued_spin_unlock(struct qspinlock *lock)
> > +{
> > +   smp_store_release((u8 *)lock, 0);
> > +}
> 
> I'm afraid this isn't enough for arm64. I suspect you want your own
> variant of queued_spin_unlock_wait() and queued_spin_is_locked() as
> well.
> 
> Much memory ordering fun to be had there.

Hi Peter,

Is there some test to reproduce the locking failure for the case. I
ask because I run loctorture for many hours on my qemu (emulating
cortex-a57), and I see no failures in the test reports. And Jan did it
on ThunderX, and Adam on QDF2400 without any problems. So even if I
rework those functions, how could I check them for correctness?

Anyway, regarding the queued_spin_unlock_wait(), is my understanding
correct that you assume adding smp_mb() before entering the for(;;)
cycle, and using ldaxr/strxr instead of atomic_read()?

Yury

[PATCH v3] soc: brcmstb: enable drivers for ARM64 and BMIPS

[Markus Mayer]

From: Markus Mayer 

We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and
BMIPS.

Signed-off-by: Markus Mayer 
---

Changes since v2:
  - It is not necessary to use (COMPILE_TEST && OF)

Changes since v1:
  - Add BMIPS
  - Add COMPILE_TEST



 drivers/soc/bcm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
index a39b0d58ddd0..49f1e2a75d61 100644
--- a/drivers/soc/bcm/Kconfig
+++ b/drivers/soc/bcm/Kconfig
@@ -11,7 +11,7 @@ config RASPBERRYPI_POWER
 
 config SOC_BRCMSTB
bool "Broadcom STB SoC drivers"
-   depends on ARM
+   depends on ARM || ARM64 || BMIPS_GENERIC || COMPILE_TEST
select SOC_BUS
help
  Enables drivers for the Broadcom Set-Top Box (STB) series of chips.
-- 
2.12.0

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Andrew Cooper]

On 20/04/17 16:06, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>> In this patch I suggest we set __max_logical_packages based on the
>> max_physical_pkg_id and total_cpus,
> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
> instead of 4.
>
> This wastes quite a bit of memory for the per-node arrays. Luckily most
> are just pointer arrays, but still, wasting 140*8 bytes for each of
> them.
>
>> this should be safe and cover all
>> possible cases. Alternatively, we may think about eliminating the concept
>> of __max_logical_packages completely and relying on max_physical_pkg_id/
>> total_cpus where we currently use topology_max_packages().
>>
>> The issue could've been solved in Xen too I guess. CPUID returning
>> x86_max_cores can be tweaked to be the lowerest(?) possible number of
>> all logical packages of the guest.
> This is getting ludicrous. Xen is plain broken, and instead of fixing
> it, you propose to somehow deal with its obviously crack induced
> behaviour :-(

Xen is (and has been forever) plain broken in this specific regard. 
Fixing CPUID handling for guests has taken me 18 months and ~80 patches
so far, and it still isn't complete.

However, Linux needs to be able to function on existing production
systems (which is every instance of Xen currently running).

Linux shouldn't BUG() because something provided by the firmware looks
wonky.  This is conceptually no different from finding junk the APCI tables.

(I fully agree that we shouldn't have got to this state, but we are 12
years too late in this respect.)

~Andrew

Re: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v4)

[Florian Fainelli]

On 03/29/2017 05:26 PM, Eric Anholt wrote:
> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
> now, so it's useful to be able to test that mode on an upstream
> kernel.  It's also been useful for me to use the same board for 32-bit
> and 64-bit development.
> 
> Signed-off-by: Eric Anholt 
> ---
> 
> v1: Gerd's patch that put the ../../../arm64/... link in the Makefile
> v2: Michael's patch that #included from ../../../arm64/... in a new
> bcm2837-rpi-3-b.dts.
> v3: Mine, using symlinks to make sure that we don't break the split DT
> tree.
> v4: Rely on the new include/arm64 symlink.
> 
> Assuming positive review feedback, I assume it would be acceptable to
> merge the shared/dt-symlinks branch in a PR of my own for the 32-bit
> DT branch?

Either that, or I can take it directly through devicetree/next whichever
you prefer. We have not gotten feedback on whether this looks acceptable
or not though...

> 
>  arch/arm/boot/dts/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 011808490fed..27d258cb50f2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
>   bcm2835-rpi-b-plus.dtb \
>   bcm2835-rpi-a-plus.dtb \
>   bcm2836-rpi-2-b.dtb \
> + include/arm64/broadcom/bcm2837-rpi-3-b.dtb \
>   bcm2835-rpi-zero.dtb
>  dtb-$(CONFIG_ARCH_BCM_5301X) += \
>   bcm4708-asus-rt-ac56u.dtb \
> 


-- 
Florian

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

[Borislav Petkov]

On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote:
> When System Memory Encryption (SME) is enabled, the physical address
> space is reduced. Adjust the x86_phys_bits value to reflect this
> reduction.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/kernel/cpu/amd.c |   14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

...

> @@ -622,8 +624,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
>  
>   /* Check if SME is enabled */
>   rdmsrl(MSR_K8_SYSCFG, msr);
> - if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
> + if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT) {
> + unsigned int ebx;
> +
> + ebx = cpuid_ebx(0x801f);
> + c->x86_phys_bits -= (ebx >> 6) & 0x3f;
> + } else {
>   clear_cpu_cap(c, X86_FEATURE_SME);
> + }

Lemme do some simplifying to save an indent level, get rid of local var
ebx and kill some { }-brackets for a bit better readability:

if (c->extended_cpuid_level >= 0x801f) {
u64 msr;

if (!cpu_has(c, X86_FEATURE_SME))
return;

/* Check if SME is enabled */
rdmsrl(MSR_K8_SYSCFG, msr);
if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT)
c->x86_phys_bits -= (cpuid_ebx(0x801f) >> 6) & 0x3f;
else
clear_cpu_cap(c, X86_FEATURE_SME);
}

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] net/mlx4: suppress 'may be used uninitialized' warning

[David Miller]

From: Greg Thelen 
Date: Mon, 17 Apr 2017 23:21:35 -0700

> gcc 4.8.4 complains that mlx4_SW2HW_MPT_wrapper() uses an uninitialized
> 'mpt' variable:
>   drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 
> 'mlx4_SW2HW_MPT_wrapper':
>   drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2802:12: warning: 
> 'mpt' may be used uninitialized in this function [-Wmaybe-uninitialized]
>  mpt->mtt = mtt;
> 
> I think this warning is a false complaint.  mpt is only used when
> mr_res_start_move_to() return zero, and in all such cases it initializes
> mpt.  But apparently gcc cannot see that.
> 
> Initialize mpt to avoid the warning.
> 
> Signed-off-by: Greg Thelen 

Appied to net-next.

Re: [PATCH] fs:orangefs:orangefs-debug, orangefs-kernel: Fixing warning issues and use ARRAY_SIZE

[kbuild test robot]

Hi Karim,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc7 next-20170420]
[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/Karim-Eshapa/fs-orangefs-orangefs-debug-orangefs-kernel-Fixing-warning-issues-and-use-ARRAY_SIZE/20170420-221438
config: x86_64-randconfig-s3-04202303 (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=x86_64 

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

   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:22:8: error: redefinition of 'struct orangefs_khandle'
struct orangefs_khandle {
   ^~~~
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:22:8: note: originally defined here
struct orangefs_khandle {
   ^~~~
   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:29:8: error: redefinition of 'struct 
>> orangefs_object_kref'
struct orangefs_object_kref {
   ^~~~
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:29:8: note: originally defined here
struct orangefs_object_kref {
   ^~~~
   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:39:19: error: conflicting types for 
>> 'ORANGEFS_khandle_cmp'
static inline int ORANGEFS_khandle_cmp(const struct orangefs_khandle *kh1,
  ^~~~
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:39:19: note: previous definition of 
'ORANGEFS_khandle_cmp' was here
static inline int ORANGEFS_khandle_cmp(const struct orangefs_khandle *kh1,
  ^~~~
   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:54:20: error: conflicting types for 
>> 'ORANGEFS_khandle_to'
static inline void ORANGEFS_khandle_to(const struct orangefs_khandle *kh,
   ^~~
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:54:20: note: previous definition of 
'ORANGEFS_khandle_to' was here
static inline void ORANGEFS_khandle_to(const struct orangefs_khandle *kh,
   ^~~
   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:63:20: error: conflicting types for 
>> 'ORANGEFS_khandle_from'
static inline void ORANGEFS_khandle_from(struct orangefs_khandle *kh,
   ^
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:63:20: note: previous definition of 
'ORANGEFS_khandle_from' was here
static inline void ORANGEFS_khandle_from(struct orangefs_khandle *kh,
   ^
   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:216:6: error: nested redefinition of 'enum 
>> ORANGEFS_io_type'
enum ORANGEFS_io_type {
 ^~~~
>> fs/orangefs/protocol.h:216:6: error: redeclaration of 'enum ORANGEFS_io_type'
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:216:6: note: originally defined here
enum ORANGEFS_io_type {
 ^~~~
   In file included from fs/orangefs/orangefs-kernel.h:57:0,
from fs/orangefs/orangefs-debug.h:17,
from fs/orangefs/protocol.h:336,
from fs/orangefs/acl.c:7:
>> fs/orangefs/protocol.h:217:2: error: redeclaration of enumerator 
>> 'ORANGEFS_IO_READ'
 ORANGEFS_IO_READ = 1,
 ^~~~
   In file included from fs/orangefs/acl.c:7:0:
   fs/orangefs/protocol.h:217:2: note: previous definition of 
'ORANGEFS_IO_READ' was here
 ORANGEFS_IO_R

Re: [PATCH 0/5] fs, xfs refcount conversions

[Darrick J. Wong]

On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote:
> 
>  
> > v3:
> >  * fixed header file inclusion
> 
> I don't think I have heard anything back on this v3 patch set. 
> Is there still smth here to fix or could you take the changes in?

Generally I think it looks ok; it's running through shakedown testing as
we speak.

--D

> 
> Best Regards,
> Elena.
> 
> > 
> > Now when new refcount_t type and API are finally merged
> > (see include/linux/refcount.h), the following
> > patches convert various refcounters in the xfs susystem from atomic_t
> > to refcount_t. By doing this we prevent intentional or accidental
> > underflows or overflows that can led to use-after-free vulnerabilities.
> > 
> > 
> > Elena Reshetova (5):
> >   fs, xfs: convert xfs_bui_log_item.bui_refcount from atomic_t to
> > refcount_t
> >   fs, xfs: convert xfs_efi_log_item.efi_refcount from atomic_t to
> > refcount_t
> >   fs, xfs: convert xlog_ticket.t_ref from atomic_t to refcount_t
> >   fs, xfs: convert xfs_cui_log_item.cui_refcount from atomic_t to
> > refcount_t
> >   fs, xfs: convert xfs_rui_log_item.rui_refcount from atomic_t to
> > refcount_t
> > 
> >  fs/xfs/xfs_bmap_item.c |  4 ++--
> >  fs/xfs/xfs_bmap_item.h |  2 +-
> >  fs/xfs/xfs_extfree_item.c  |  4 ++--
> >  fs/xfs/xfs_extfree_item.h  |  2 +-
> >  fs/xfs/xfs_linux.h |  1 +
> >  fs/xfs/xfs_log.c   | 10 +-
> >  fs/xfs/xfs_log_priv.h  |  2 +-
> >  fs/xfs/xfs_refcount_item.c |  4 ++--
> >  fs/xfs/xfs_refcount_item.h |  2 +-
> >  fs/xfs/xfs_rmap_item.c |  4 ++--
> >  fs/xfs/xfs_rmap_item.h |  2 +-
> >  11 files changed, 19 insertions(+), 18 deletions(-)
> > 
> > --
> > 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

[Tom Lendacky]

On 4/20/2017 11:59 AM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote:

When System Memory Encryption (SME) is enabled, the physical address
space is reduced. Adjust the x86_phys_bits value to reflect this
reduction.

Signed-off-by: Tom Lendacky 
---
 arch/x86/kernel/cpu/amd.c |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)


...


@@ -622,8 +624,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)

/* Check if SME is enabled */
rdmsrl(MSR_K8_SYSCFG, msr);
-   if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
+   if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT) {
+   unsigned int ebx;
+
+   ebx = cpuid_ebx(0x801f);
+   c->x86_phys_bits -= (ebx >> 6) & 0x3f;
+   } else {
clear_cpu_cap(c, X86_FEATURE_SME);
+   }


Lemme do some simplifying to save an indent level, get rid of local var
ebx and kill some { }-brackets for a bit better readability:

if (c->extended_cpuid_level >= 0x801f) {
u64 msr;

if (!cpu_has(c, X86_FEATURE_SME))
return;

/* Check if SME is enabled */
rdmsrl(MSR_K8_SYSCFG, msr);
if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT)
c->x86_phys_bits -= (cpuid_ebx(0x801f) >> 6) & 0x3f;
else
clear_cpu_cap(c, X86_FEATURE_SME);
}



Hmmm... and actually if cpu_has(X86_FEATURE_SME) is true then it's a
given that extended_cpuid_level >= 0x801f.  So this can be
simplified to just:

if (cpu_has(c, X86_FEATURE_SME)) {
... the rest of your suggestion (minus cpu_has()) ...
}

Thanks,
Tom

Re: net/xfrm: stack-out-of-bounds in xfrm_state_find

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 6:47 PM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On linux-next commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>
> A reproducer and .config are attached.
>
> ==
> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x2ce7/0x2f70 at
> addr 88006654f790
> Read of size 4 by task a.out/4065
> page:ea00019953c0 count:0 mapcount:0 mapping:  (null) index:0x0
> flags: 0x100()
> raw: 0100   
> raw:  ea00019953e0  
> page dumped because: kasan: bad access detected
> CPU: 1 PID: 4065 Comm: a.out Not tainted 4.11.0-rc7+ #251
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:212
>  kasan_report+0x4d8/0x510 mm/kasan/report.c:347
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>  xfrm_state_find+0x2ce7/0x2f70 net/xfrm/xfrm_state.c:897

I'm not sure if the line numbers in the report are correct.

My guess is that the guilty line is actually this one:

h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);

but I might be wrong.

>  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:1470
>  xfrm_tmpl_resolve+0x308/0xc90 net/xfrm/xfrm_policy.c:1514
>  xfrm_resolve_and_create_bundle+0x16e/0x2590 net/xfrm/xfrm_policy.c:1889
>  xfrm_lookup+0xd72/0x1170 net/xfrm/xfrm_policy.c:2253
>  xfrm_lookup_route+0x39/0x1a0 net/xfrm/xfrm_policy.c:2375
>  ip_route_output_flow+0x7f/0xa0 net/ipv4/route.c:2483
>  udp_sendmsg+0x1565/0x2cd0 net/ipv4/udp.c:1015
>  udpv6_sendmsg+0x8af/0x3500 net/ipv6/udp.c:1083
>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
>  sock_sendmsg_nosec net/socket.c:633
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>  SyS_sendto+0x40/0x50 net/socket.c:1664
>  entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204
> RIP: 0033:0x7f3daefd0b79
> RSP: 002b:7ffdb39bb0b8 EFLAGS: 0206 ORIG_RAX: 002c
> RAX: ffda RBX: 7ffdb39bb210 RCX: 7f3daefd0b79
> RDX:  RSI: 20001000 RDI: 0003
> RBP: 004004a0 R08: 20013ff0 R09: 0010
> R10: 2000 R11: 0206 R12: 
> R13: 7ffdb39bb210 R14:  R15: 
> Memory state around the buggy address:
>  88006654f680: f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 f8 f2 f2 f2 f2
>  88006654f700: f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 00
>>88006654f780: 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
>  ^
>  88006654f800: f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
>  88006654f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==