[PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range

[Aneesh Kumar K.V]

We remove one instace of flush_tlb_range here. That was added by
f714f4f20e59ea6eea264a86b9a51fd51b88fc54 ("mm: numa: call MMU notifiers
on THP migration"). But the pmdp_huge_clear_flush_notify should have
done the require flush for us. Hence remove the extra flush.

Signed-off-by: Aneesh Kumar K.V 
---
Changes from V1:
* fix build error

 include/asm-generic/pgtable.h | 17 +
 mm/migrate.c  |  8 +---
 mm/pgtable-generic.c  | 14 --
 3 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index c370b261c720..9401f4819891 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -783,6 +783,23 @@ static inline int pmd_clear_huge(pmd_t *pmd)
 }
 #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
 
+#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * ARCHes with special requirements for evicting THP backing TLB entries can
+ * implement this. Otherwise also, it can help optimize normal TLB flush in
+ * THP regime. stock flush_tlb_range() typically has optimization to nuke the
+ * entire TLB TLB if flush span is greater than a threshold, which will
+ * likely be true for a single huge page. Thus a single thp flush will
+ * invalidate the entire TLB which is not desitable.
+ * e.g. see arch/arc: flush_pmd_tlb_range
+ */
+#define flush_pmd_tlb_range(vma, addr, end)flush_tlb_range(vma, addr, end)
+#else
+#define flush_pmd_tlb_range(vma, addr, end)BUILD_BUG()
+#endif
+#endif
+
 #endif /* !__ASSEMBLY__ */
 
 #ifndef io_remap_pfn_range
diff --git a/mm/migrate.c b/mm/migrate.c
index b1034f9c77e7..c079c115d038 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1767,7 +1767,10 @@ int migrate_misplaced_transhuge_page(struct mm_struct 
*mm,
put_page(new_page);
goto out_fail;
}
-
+   /*
+* We are not sure a pending tlb flush here is for a huge page
+* mapping or not. Hence use the tlb range variant
+*/
if (mm_tlb_flush_pending(mm))
flush_tlb_range(vma, mmun_start, mmun_end);
 
@@ -1823,12 +1826,11 @@ fail_putback:
page_add_anon_rmap(new_page, vma, mmun_start, true);
pmdp_huge_clear_flush_notify(vma, mmun_start, pmd);
set_pmd_at(mm, mmun_start, pmd, entry);
-   flush_tlb_range(vma, mmun_start, mmun_end);
update_mmu_cache_pmd(vma, address, );
 
if (page_count(page) != 2) {
set_pmd_at(mm, mmun_start, pmd, orig_entry);
-   flush_tlb_range(vma, mmun_start, mmun_end);
+   flush_pmd_tlb_range(vma, mmun_start, mmun_end);
mmu_notifier_invalidate_range(mm, mmun_start, mmun_end);
update_mmu_cache_pmd(vma, address, );
page_remove_rmap(new_page, true);
diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
index 9d4767698a1c..3c9c78400300 100644
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -84,20 +84,6 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned 
long address,
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 
-#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
-
-/*
- * ARCHes with special requirements for evicting THP backing TLB entries can
- * implement this. Otherwise also, it can help optimize normal TLB flush in
- * THP regime. stock flush_tlb_range() typically has optimization to nuke the
- * entire TLB TLB if flush span is greater than a threshhold, which will
- * likely be true for a single huge page. Thus a single thp flush will
- * invalidate the entire TLB which is not desitable.
- * e.g. see arch/arc: flush_pmd_tlb_range
- */
-#define flush_pmd_tlb_range(vma, addr, end)flush_tlb_range(vma, addr, end)
-#endif
-
 #ifndef __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
 int pmdp_set_access_flags(struct vm_area_struct *vma,
  unsigned long address, pmd_t *pmdp,
-- 
2.5.0

Re: [PATCH] Optimize int_sqrt for small values for faster idle

[Fengguang Wu]

On Tue, Feb 09, 2016 at 12:44:00PM -0800, Andi Kleen wrote:
> On Sun, Feb 07, 2016 at 10:32:26PM +0100, Rasmus Villemoes wrote:
> > On Mon, Feb 01 2016, Andi Kleen  wrote:
> > 
> > > On Mon, Feb 01, 2016 at 10:25:17PM +0100, Rasmus Villemoes wrote:
> > >> On Thu, Jan 28 2016, Andi Kleen  wrote:
> > >> 
> > >> > From: Andi Kleen 
> > >> >
> > >> > The menu cpuidle governor does at least two int_sqrt() each time
> > >> > we go into idle in get_typical_interval to compute stddev
> > >> >
> > >> > int_sqrts take 100-120 cycles each. Short idle latency is important
> > >> > for many workloads.
> > >> >
> > >> 
> > >> If you want to optimize get_typical_interval(), why not just take the
> > >> square root out of the equation (literally)?
> > >> 
> > >> Something like
> > >
> > > Looks good. Yes that's a better fix.
> > >
> > 
> > Andi, did you have a way to measure the impact, and if so, could I get
> > you to run the numbers again with my patch?
> 
> I got the numbers from the 0day runs (AIM7 gets faster)
> In theory if you post the patch that should happen automatically
> (checking with Fengguang)

Yes we bisect and report a lot of runtime performance changes.
On the other hand, some few will be missed, too, due to various
unstableness issues. Anyway if you would like to study performance
impacts of a patch, feel free to send us requests to gather the
numbers and do comparison.

Thanks,
Fengguang

Re: [PATCH 2/2] vhost: disentangle vring endianness stuff from the core code

[Greg Kurz]

On Wed, 10 Feb 2016 14:23:33 +0100
Cornelia Huck  wrote:

> On Wed, 10 Feb 2016 14:08:43 +0100
> Greg Kurz  wrote:
> 
> > But you are right, there is a bug: we should rollback if vhost_init_used()
> > fails. Something like below:
> > 
> >  err_used:
> > vq->private_data = oldsock;
> > vhost_net_enable_vq(n, vq);
> > +   vhost_adjust_vring_endian(vq);  
> 
> Shouldn't we switch back before we reenable? Or have I lost myself in
> this maze here again?
> 

I haven't spotted any path under vhost_net_enable_vq() that needs
the vring endianness, but indeed it looks safer to switch back
before a worker thread may be woken up.

> > if (ubufs)
> > vhost_net_ubuf_put_wait_and_free(ubufs);
> >  err_ubufs:  

Re: [PATCH v2 2/2] gpio: Add driver for SPI serializers

[Linus Walleij]

On Mon, Jan 25, 2016 at 5:37 PM, Andrew F. Davis  wrote:

> Add generic parallel-in/serial-out shift register GPIO driver.
>
> This includes SPI compatible devices like SN74165 serial-out shift
> registers and the SN65HVS88x series of industrial serializers that can
> be read over the SPI bus and used for GPI (General Purpose Input).
>
> Signed-off-by: Andrew F. Davis 

Patch applied, good work.

Yours,
Linus Walleij

Re: mm, compaction: fix build errors with kcompactd

[Vlastimil Babka]

On 02/09/2016 03:15 PM, Arnd Bergmann wrote:
> The newly added kcompactd code introduces multiple build errors:
> 
> include/linux/compaction.h:91:12: error: 'kcompactd_run' defined but not used 
> [-Werror=unused-function]
> mm/compaction.c:1953:2: error: implicit declaration of function 
> 'hotcpu_notifier' [-Werror=implicit-function-declaration]
> 
> This marks the new empty wrapper functions as 'inline' to avoid 
> unused-function warnings,
> and includes linux/cpu.h to get the hotcpu_notifier declaration.
> 
> Fixes: 8364acdfa45a ("mm, compaction: introduce kcompactd")
> Signed-off-by: Arnd Bergmann 

Thanks a lot!
Vlastimil

Re: [PATCH 14/23] perf ui/stdio: Implement hierarchy output mode

[Namhyung Kim]

On Wed, Feb 10, 2016 at 01:13:35PM +0100, Jiri Olsa wrote:
> On Fri, Feb 05, 2016 at 10:01:46PM +0900, Namhyung Kim wrote:
> 
> SNIP
> 
> > +   printed += fprintf(fp, "%s\n", buf);
> > +
> > +   if (symbol_conf.use_callchain && he->leaf) {
> > +   u64 total = hists__total_period(hists);
> > +
> > +   printed += hist_entry_callchain__fprintf(he, total, 0, fp);
> > +   goto out;
> > +   }
> > +
> > +out:
> > +   return printed;
> > +}
> > +
> >  static int hist_entry__fprintf(struct hist_entry *he, size_t size,
> >struct hists *hists,
> >char *bf, size_t bfsz, FILE *fp)
> > @@ -423,6 +488,13 @@ static int hist_entry__fprintf(struct hist_entry *he, 
> > size_t size,
> > if (size == 0 || size > bfsz)
> > size = hpp.size = bfsz;
> >  
> > +   if (symbol_conf.report_hierarchy) {
> 
> it'd be great for review to have symbol_conf.report_hierarchy already
> present, so I could try it early in the patchset like with this change

I'm okay with it and that's what I do during the development.  But
introducing the option prior to implementing all feature/UI caused
some troubles/crashes.  So I put it after the implementation.

Thanks,
Namhyung

Re: [PATCH 6/8] arm: initial machine port for artpec-6 SoC

[Arnd Bergmann]

On Wednesday 10 February 2016 13:41:55 Lars Persson wrote:
> @@ -0,0 +1,22 @@
> +menuconfig ARCH_ARTPEC
> + bool "Axis Communications ARM based ARTPEC SoCs" if ARCH_MULTI_V7
> +
> +if ARCH_ARTPEC
> +
> +config MACH_ARTPEC6
> + bool "Axis ARTPEC-6 ARM Cortex A9 Platform" if ARCH_MULTI_V7

Change both to use

depends on ARCH_MULTI_V7

like we changed all other platforms in 4.5

> + select ARM_AMBA
> + select ARM_GIC
> + select ARM_GLOBAL_TIMER
> + select ARM_PSCI
> + select COMMON_CLK
> + select GENERIC_CLOCKEVENTS
> + select HAVE_ARM_ARCH_TIMER
> + select HAVE_ARM_SCU
> + select HAVE_ARM_TWD if SMP
> + select SPARSE_IRQ
> + select USE_OF

No need for GENERIC_CLOCKEVENTS, COMMON_CLK, USE_OF or SPARSE_IRQ to be 
selected, they
are always enabled with ARCH_MULTIPLATFORM. Check the others as well to see if 
you can drop more of them.

> +
> +#define ARTPEC6_DMACFG 0xf810
> +#define ARTPEC6_DMACFG_UARTS_BURST 0xff
> +
> +#define SECURE_OP_L2C_WRITEREG 0xb401
> +
> +static void __init artpec6_init_machine(void)
> +{
> + void __iomem *dmacfg;
> +
> + /* Use PL011 DMA Burst Request signal instead of DMA Single Request */
> + dmacfg = ioremap(ARTPEC6_DMACFG, 4);
> + if (dmacfg) {
> + __raw_writel(ARTPEC6_DMACFG_UARTS_BURST, dmacfg);
> + iounmap(dmacfg);
> + }

Can you do this in the bootloader?

If not, please use a DT node to pass the address rather than hardcoding it,
and use writel() instead of __raw_writel() so it works with on big-endian 
kernels.

> +DT_MACHINE_START(ARTPEC6, "Axis ARTPEC-6 Platform")
> + .l2c_aux_val= 0x0C00,
> + .l2c_aux_mask   = 0xF3FF,
> + .l2c_write_sec  = artpec6_l2c310_write_sec,
> + .init_irq   = irqchip_init,
> + .init_machine   = artpec6_init_machine,
> + .dt_compat  = artpec6_dt_match,
> +MACHINE_END
> 

You can drop the irqchip_init.

Arnd

[PATCH v5 0/2] add support for DWC UFS Controller

[Joao Pinto]

The work consisted of:
- Fixed typo in ufshcd-pltfrm.c
- Tweak ufshcd.c for UFS 2.0 support
- Implement ufshcd-dwc which contains all DWC HW specific code
- Unipro attributes were added and new registers were added to the driver
- Implement a ufs-dwc glue platform driver
- Implement a ufs-dwc-pci glue pci driver

Joao Pinto (2):
  fixed typo in ufshcd-pltfrm
  add support for DWC UFS Host Controller

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  41 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 736 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  18 +
 drivers/scsi/ufs/ufshcd-pltfrm.c  |   2 +-
 drivers/scsi/ufs/ufshcd.c |  50 +-
 drivers/scsi/ufs/ufshcd.h |  13 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 14 files changed, 1232 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

-- 
1.8.1.5

Re: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC information

[Julien Grall]

Hi Marc,

On 10/02/16 14:46, Marc Zyngier wrote:

On 10/02/16 14:19, Julien Grall wrote:

On 09/02/16 20:49, Christoffer Dall wrote:

+static void __init gic_acpi_setup_kvm_info(void)
+{
+   gic_v2_kvm_info.type = GIC_V2;
+
+   gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
+ acpi_data.maint_irq,
+ acpi_data.maint_irq_mode,
+ ACPI_ACTIVE_HIGH);
+   gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
+   if (gic_v2_kvm_info.vctrl_base)
+   gic_v2_kvm_info.vctrl_size = SZ_8K;
+
+   gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
+   if (gic_v2_kvm_info.vcpu_base)
+   gic_v2_kvm_info.vcpu_size = SZ_8K;


why are the sizes hard-coded to 8K in this case?


The MADT only provides the base addresses and not the size. The default
value has been chosen based on the GICv2 spec (ARM IHI 0048B.b)
* GICV: See 5.5
* GICH: I can't find again the section about it. But the example
bindings in
Documents/devicetree/bindings/interrupt-controller/arm,gic.txt uses 8K.

I will add a comment in the code explaining where the 8K come from.


The GICH size can be found in the GIC400 TRM:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/CHDBJDCB.html

The first 4kB are banked per CPU, while the next 4kB are exposing all
CPUs, each in a 512 bytes window. We don't give a damn about the second
page, but hey, it is there...

Of course, this is GIC400, not the architecture spec. So maybe
considering a 4kB size would be better, just in case someone is
braindead enough to produce another GICv2 implementation without the
aliases...


Ok, I will change the GICH to 4KB in the next version.

Cheers,

--
Julien Grall

[PATCH v2] mfd: ab8500: Provide a small example using new MFD cell MACROs

[Lee Jones]

mfd: ab8500: Provide a small example using new MFD cell MACROs

Signed-off-by: Lee Jones 
---
 drivers/mfd/ab8500-core.c | 106 +++---
 1 file changed, 34 insertions(+), 72 deletions(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index f3d6891..c03a86e 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -634,79 +634,41 @@ static const struct mfd_cell ab8500_bm_devs[] = {
 
 static const struct mfd_cell ab8500_devs[] = {
 #ifdef CONFIG_DEBUG_FS
-   {
-   .name = "ab8500-debug",
-   .of_compatible = "stericsson,ab8500-debug",
-   },
+   OF_MFD_CELL("ab8500-debug",
+   NULL, NULL, 0, "stericsson,ab8500-debug"),
 #endif
-   {
-   .name = "ab8500-sysctrl",
-   .of_compatible = "stericsson,ab8500-sysctrl",
-   },
-   {
-   .name = "ab8500-ext-regulator",
-   .of_compatible = "stericsson,ab8500-ext-regulator",
-   },
-   {
-   .name = "ab8500-regulator",
-   .of_compatible = "stericsson,ab8500-regulator",
-   },
-   {
-   .name = "abx500-clk",
-   .of_compatible = "stericsson,abx500-clk",
-   },
-   {
-   .name = "ab8500-gpadc",
-   .of_compatible = "stericsson,ab8500-gpadc",
-   },
-   {
-   .name = "ab8500-rtc",
-   .of_compatible = "stericsson,ab8500-rtc",
-   },
-   {
-   .name = "ab8500-acc-det",
-   .of_compatible = "stericsson,ab8500-acc-det",
-   },
-   {
-
-   .name = "ab8500-poweron-key",
-   .of_compatible = "stericsson,ab8500-poweron-key",
-   },
-   {
-   .name = "ab8500-pwm",
-   .of_compatible = "stericsson,ab8500-pwm",
-   .id = 1,
-   },
-   {
-   .name = "ab8500-pwm",
-   .of_compatible = "stericsson,ab8500-pwm",
-   .id = 2,
-   },
-   {
-   .name = "ab8500-pwm",
-   .of_compatible = "stericsson,ab8500-pwm",
-   .id = 3,
-   },
-   {
-   .name = "ab8500-denc",
-   .of_compatible = "stericsson,ab8500-denc",
-   },
-   {
-   .name = "pinctrl-ab8500",
-   .of_compatible = "stericsson,ab8500-gpio",
-   },
-   {
-   .name = "abx500-temp",
-   .of_compatible = "stericsson,abx500-temp",
-   },
-   {
-   .name = "ab8500-usb",
-   .of_compatible = "stericsson,ab8500-usb",
-   },
-   {
-   .name = "ab8500-codec",
-   .of_compatible = "stericsson,ab8500-codec",
-   },
+   OF_MFD_CELL("ab8500-sysctrl",
+   NULL, NULL, 0, "stericsson,ab8500-sysctrl"),
+   OF_MFD_CELL("ab8500-ext-regulator",
+   NULL, NULL, 0, "stericsson,ab8500-ext-regulator"),
+   OF_MFD_CELL("ab8500-regulator",
+   NULL, NULL, 0, "stericsson,ab8500-regulator"),
+   OF_MFD_CELL("abx500-clk",
+   NULL, NULL, 0, "stericsson,abx500-clk"),
+   OF_MFD_CELL("ab8500-gpadc",
+   NULL, NULL, 0, "stericsson,ab8500-gpadc"),
+   OF_MFD_CELL("ab8500-rtc",
+   NULL, NULL, 0, "stericsson,ab8500-rtc"),
+   OF_MFD_CELL("ab8500-acc-det",
+   NULL, NULL, 0, "stericsson,ab8500-acc-det"),
+   OF_MFD_CELL("ab8500-poweron-key",
+   NULL, NULL, 0, "stericsson,ab8500-poweron-key"),
+   OF_MFD_CELL("ab8500-pwm",
+   NULL, NULL, 1, "stericsson,ab8500-pwm"),
+   OF_MFD_CELL("ab8500-pwm",
+   NULL, NULL, 2, "stericsson,ab8500-pwm"),
+   OF_MFD_CELL("ab8500-pwm",
+   NULL, NULL, 3, "stericsson,ab8500-pwm"),
+   OF_MFD_CELL("ab8500-denc",
+   NULL, NULL, 0, "stericsson,ab8500-denc"),
+   OF_MFD_CELL("pinctrl-ab8500",
+   NULL, NULL, 0, "stericsson,ab8500-gpio"),
+   OF_MFD_CELL("abx500-temp",
+   NULL, NULL, 0, "stericsson,abx500-temp"),
+   OF_MFD_CELL("ab8500-usb",
+   NULL, NULL, 0, "stericsson,ab8500-usb"),
+   OF_MFD_CELL("ab8500-codec",
+   NULL, NULL, 0, "stericsson,ab8500-codec"),
 };
 
 static const struct mfd_cell ab9540_devs[] = {

Re: [PATCH 1/2] vhost: helpers to enable/disable vring endianness

[Greg Kurz]

On Wed, 10 Feb 2016 17:08:52 +0200
"Michael S. Tsirkin"  wrote:

> On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz wrote:
> > On Wed, 10 Feb 2016 13:21:22 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote:  
> > > > The default use case for vhost is when the host and the vring have the
> > > > same endianness (default native endianness). But there are cases where
> > > > they differ and vhost should byteswap when accessing the vring:
> > > > - the host is big endian and the vring comes from a virtio 1.0 device
> > > >   which is always little endian
> > > > - the architecture is bi-endian and the vring comes from a legacy virtio
> > > >   device with a different endianness than the endianness of the host 
> > > > (aka
> > > >   legacy cross-endian)
> > > > 
> > > > These cases are handled by the vq->is_le and the optional vq->user_be,
> > > > with the following logic:
> > > > - if none of the fields is enabled, vhost access the vring without 
> > > > byteswap
> > > > - if the vring is virtio 1.0 and the host is big endian, vq->is_le is
> > > >   enabled to enforce little endian access to the vring
> > > > - if the vring is legacy cross-endian, userspace enables vq->user_be
> > > >   to inform vhost about the vring endianness. This endianness is then
> > > >   enforced for vring accesses through vq->is_le again
> > > > 
> > > > The logic is unclear in the current code.
> > > > 
> > > > This patch introduces helpers with explicit enable and disable 
> > > > semantics,
> > > > for better clarity.
> > > > 
> > > > No behaviour change.
> > > > 
> > > > Signed-off-by: Greg Kurz 
> > > > ---
> > > >  drivers/vhost/vhost.c |   28 +++-
> > > >  1 file changed, 19 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > index ad2146a9ab2d..e02e06755ab7 100644
> > > > --- a/drivers/vhost/vhost.c
> > > > +++ b/drivers/vhost/vhost.c
> > > > @@ -43,11 +43,16 @@ enum {
> > > >  #define vhost_avail_event(vq) ((__virtio16 __user 
> > > > *)>used->ring[vq->num])
> > > >  
> > > >  #ifdef CONFIG_VHOST_CROSS_ENDIAN_LEGACY
> > > > -static void vhost_vq_reset_user_be(struct vhost_virtqueue *vq)
> > > > +static void vhost_disable_user_be(struct vhost_virtqueue *vq)
> > > >  {
> > > > vq->user_be = !virtio_legacy_is_little_endian();
> > > >  }
> > > >  
> > > 
> > > Hmm this doesn't look like an improvement to me.
> > > What does it mean to disable big endian? Make it little endian?  
> > 
> > The default behavior for the device is native endian.
> > 
> > The SET_VRING_ENDIAN ioctl is used to make the device big endian
> > on little endian hosts, hence "enabling" cross-endian mode...
> >   
> > > Existing reset seems to make sense.
> > >   
> > 
> > ... and we "disable" cross-endian mode on reset.  
> 
> OK but that's enable cross-endian. Not enable be.  We could have
> something like vhost_disable_user_byte_swap though each time we try,
> the result makes my head hurt: "swap" is a relative thing and hard to
> keep track of.
> 

What about having something like below then ?

vhost_enable_cross_endian_big() to be called on little endian hosts with big 
endian devices

vhost_enable_cross_endian_little() to be called on big endian hosts with little 
endian devices

vhost_disable_cross_endian() to go back to the native endian default

> > > > +static void vhost_enable_user_be(struct vhost_virtqueue *vq, bool 
> > > > user_be)
> > > > +{
> > > > +   vq->user_be = user_be;
> > > > +}
> > > > +
> > > 
> > > And this is maybe "init_user_be"?
> > >   
> > 
> > Anyway I don't mind changing the names to reset/init_user_be if you think it
> > is clearer.
> >   
> > > >  static long vhost_set_vring_endian(struct vhost_virtqueue *vq, int 
> > > > __user *argp)
> > > >  {
> > > > struct vhost_vring_state s;
> > > > @@ -62,7 +67,7 @@ static long vhost_set_vring_endian(struct 
> > > > vhost_virtqueue *vq, int __user *argp)
> > > > s.num != VHOST_VRING_BIG_ENDIAN)
> > > > return -EINVAL;
> > > >  
> > > > -   vq->user_be = s.num;
> > > > +   vhost_enable_user_be(vq, !!s.num);
> > > >  
> > > > return 0;
> > > >  }
> > > > @@ -81,7 +86,7 @@ static long vhost_get_vring_endian(struct 
> > > > vhost_virtqueue *vq, u32 idx,
> > > > return 0;
> > > >  }
> > > >  
> > > > -static void vhost_init_is_le(struct vhost_virtqueue *vq)
> > > > +static void vhost_enable_is_le(struct vhost_virtqueue *vq)
> > > >  {
> > > > /* Note for legacy virtio: user_be is initialized at reset time
> > > >  * according to the host endianness. If userspace does not set 
> > > > an
> > > 
> > > Same thing really. I'd rather add "reset_is_le".
> > >   
> > > > @@ -91,7 +96,7 @@ static void vhost_init_is_le(struct vhost_virtqueue 
> > > > *vq)
> > > > vq->is_le = 

Re: [PATCH v5] pinctrl: rockchip: add support for the rk3399

[Linus Walleij]

On Mon, Feb 1, 2016 at 3:58 AM, David Wu  wrote:

> The pinctrl of rk3399 is much different from other's,
> especially the 3bits of drive strength.
>
> Signed-off-by: David Wu 
> Reviewed-by: Heiko Stuebner 
> ---
> Changes in v5:
> - merge the binding-doc-addition in one patch (Linus Heiko)
> - fix the comment of bit15 drive setting (Heiko)

Patch applied.

Yours,
Linus Walleij

Re: [RFC PATCH v4 2/6] module: preserve Elf information for livepatch modules

[Petr Mladek]

On Wed 2016-02-03 20:11:07, Jessica Yu wrote:
> diff --git a/kernel/module.c b/kernel/module.c
> index 71c77ed..9c16eb2 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2676,6 +2764,23 @@ static int copy_module_from_user(const void __user 
> *umod, unsigned long len,
>   return 0;
>  }
>  
> +#ifdef CONFIG_LIVEPATCH
> +static int find_livepatch_modinfo(struct module *mod, struct load_info *info)
> +{
> + mod->klp = get_modinfo(info, "livepatch") ? true : false;
> +
> + return 0;
> +}
> +#else /* !CONFIG_LIVEPATCH */
> +static int find_livepatch_modinfo(struct module *mod, struct load_info *info)
> +{
> + if (get_modinfo(info, "livepatch"))

One more thing. I suggest to write a friendly message here. For example:

pr_err("LifePatch support is not available. Rejecting the module: s\n",
   mod->name);

It might safe some debugging a poor user or developer.

> + return -ENOEXEC;
> +
> + return 0;
> +}
> +#endif /* CONFIG_LIVEPATCH */
> +

Best Regards,
Petr

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

[Juri Lelli]

On 10/02/16 13:48, Luca Abeni wrote:
> Hi,
> 
> On Wed, 10 Feb 2016 11:32:58 +
> Juri Lelli  wrote:
> [...]
> > From 62f70ca3051672dce209e8355cf5eddc9d825c2a Mon Sep 17 00:00:00 2001
> > From: Juri Lelli 
> > Date: Sat, 6 Feb 2016 12:41:09 +
> > Subject: [PATCH 1/2] sched/deadline: add per rq tracking of admitted
> > bandwidth
> > 
> > Currently SCHED_DEADLINE scheduling policy tracks bandwidth of tasks
> > that passed admission control at root_domain level only. This creates
> > problems when such data structure(s) are destroyed, when we
> > reconfigure scheduling domains for example.
> > 
> > This is part one of two changes required to fix the problem. In this
> > patch we add per-rq tracking of admitted bandwidth. Tasks bring with
> > them their bandwidth contribution when they enter the system and are
> > enqueued for the first time. Contributions are then moved around when
> > migrations happen and removed when tasks die.
> 
> I think this patch actually does two different things (addressing two
> separate problems):
> 1) it introduces the tracking of per-rq utilization (used in your next
>patch to address the root domain issues)
> 2) it fixes a bug in the current utilization tracking mechanism.
>Currently, a task doing
>   while(1) {
>   switch to SCHED_DEADLINE
>   switch to SCHED_OTHER
>   }
>brings dl_b->total_bw below 0. Thanks to Juri for showing me this
>problem (and how to reproduce it) in a private email.
>This happens because when the task switches back from SCHED_DEADLINE
>to SCHED_OTHER, switched_from_dl() does not clear its deadline
>parameters (they will be cleared by the deadline timer when it
>fires). But dl_overflow() removes its utilization from
>dl_b->total_bw. When the task switches back to SCHED_DEADLINE, the
>if (new_bw == p->dl.dl_bw) check in dl_overflow() prevents
>__dl_add() from being called, and so when the task switches back to
>SCHED_OTHER dl_b->total_bw becomes negative.
> 

Yep. That is also the reason why I think, whatever refactoring we are
goind to do, we should keep per-rq and root_domain accounting done
together.

> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 9503d59..0ee0ec2 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -2432,7 +2432,7 @@ static int dl_overflow(struct task_struct *p,
> > int policy, u64 new_bw = dl_policy(policy) ? to_ratio(period,
> > runtime) : 0; int cpus, err = -1;
> >  
> > -   if (new_bw == p->dl.dl_bw)
> > +   if (task_has_dl_policy(p) && new_bw == p->dl.dl_bw)
> > return 0;
> 
> This hunk actually fixes issue 2) mentioned above, so I think it should
> be committed in a short time (independently from the rest of the
> patch). And maybe is a good candidate for backporting to stable kernels?
> 

Yes, this is a sensible fix per se. I can split it and send it
separately.

Best,

- Juri

Re: [PATCH v2 3/3] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous

[Vlastimil Babka]

On 02/09/2016 09:53 PM, Andrew Morton wrote:
> On Tue, 9 Feb 2016 18:58:32 +0100 Vlastimil Babka  wrote:
> 
>> On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
>>> Yeah, it seems wrong to me. :)
>>> Here goes fix.
>>
>> Doesn't apply for me, even after fixing the most obvious line wraps.
>> Seems like the version in mmotm is still your original patch and
>> Andrew's hotfix?
> 
> Yes, that patch was hopelessly mailer-mangled.  I painstakingly fixed
> it up and generated the incremental:

Thanks a lot. My review of the final patch also involved pain (due to
the cold, not the patch!).

You can take my Acked-by, but I also find the definitions of
set_zone_contiguous/clear_zone_contiguous() "in the header of the
consumer" (hotplug) somewhat unusual. It works, but e.g. mm/internal.h
would be more expected.

Then there's this:

> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -509,6 +509,8 @@ int __ref __add_pages(int nid, struct zone *zone, 
> unsigned long phys_start_pfn,
>   int start_sec, end_sec;
>   struct vmem_altmap *altmap;
>  
> + clear_zone_contiguous(zone);
> +
>   /* during initialize mem_map, align hot-added range to section */
>   start_sec = pfn_to_section_nr(phys_start_pfn);
>   end_sec = pfn_to_section_nr(phys_start_pfn + nr_pages - 1);
> @@ -540,6 +542,8 @@ int __ref __add_pages(int nid, struct zone *zone, 
> unsigned long phys_start_pfn,
>   }
>   vmemmap_populate_print_last();
>  
> + set_zone_contiguous(zone);
> +
>   return err;
>  }
>  EXPORT_SYMBOL_GPL(__add_pages);

Between the clear and set, __add_pages() might return with -EINVAL,
leaving the flag cleared potentially forever. Not critical, probably
rare, but it should be possible to avoid this by moving the clear below
the altmap check?

Thanks,
Vlastimil

[PATCH] MIPS: OCTEON: Update OCTEON_FEATURE_PCIE for Octeon III

[Zubair Lutfullah Kakakhel]

Currently the driver tries to probe the pci driver and oops.

Add CN7XXX to case so that driver probes the pcie driver.

Signed-off-by: Zubair Lutfullah Kakakhel 

---
Based on v4.5-rc3

Boot tested only on CN7130 based utm8.

It does not oops and proceeds with the rest of the kernel boot.

---
 arch/mips/include/asm/octeon/octeon-feature.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/octeon/octeon-feature.h 
b/arch/mips/include/asm/octeon/octeon-feature.h
index 8ebd3f57..3ed10a8 100644
--- a/arch/mips/include/asm/octeon/octeon-feature.h
+++ b/arch/mips/include/asm/octeon/octeon-feature.h
@@ -128,7 +128,8 @@ static inline int octeon_has_feature(enum octeon_feature 
feature)
case OCTEON_FEATURE_PCIE:
return OCTEON_IS_MODEL(OCTEON_CN56XX)
|| OCTEON_IS_MODEL(OCTEON_CN52XX)
-   || OCTEON_IS_MODEL(OCTEON_CN6XXX);
+   || OCTEON_IS_MODEL(OCTEON_CN6XXX)
+   || OCTEON_IS_MODEL(OCTEON_CN7XXX);
 
case OCTEON_FEATURE_SRIO:
return OCTEON_IS_MODEL(OCTEON_CN63XX)
-- 
1.9.1

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 09/02/2016 19:41, Owen Hofmann wrote:
> Hi,
> Should this patch change the condition in pvclock_gtod_notify?
> Currently it looks like we'll only request a masterclock update when
> tsc is no longer a good clocksource.

Yes, you're right.

Paolo

Re: [PATCH V4 15/23] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region.

[Lorenzo Pieralisi]

On Thu, Feb 04, 2016 at 06:28:53PM +0100, Tomasz Nowicki wrote:
> Lets abstract two calls which allow to inject and remove MCFG regions
> which may come from DSDT table. These calls will be used for x86 and ARM64
> PCI host bridge driver in the later patches.
> 
> Signed-off-by: Tomasz Nowicki 
> Tested-by: Duc Dang 
> Tested-by: Dongdong Liu 
> Tested-by: Hanjun Guo 
> Tested-by: Graeme Gregory 
> Tested-by: Sinan Kaya 
> ---
>  drivers/acpi/mcfg.c  | 38 ++
>  include/linux/pci-acpi.h |  9 +
>  2 files changed, 47 insertions(+)
> 
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
> index 3e1e7be..dca4c4e 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define  PREFIX  "MCFG: "
>  
> @@ -77,6 +78,43 @@ int __init acpi_parse_mcfg(struct acpi_table_header 
> *header)
>   return 0;
>  }
>  
> +int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
> +{
> + struct pci_mmcfg_region *cfg;
> + struct acpi_pci_root *root;
> + int seg, start, end, err;
> +
> + root = ci->root;
> + seg = root->segment;
> + start = root->secondary.start;
> + end = root->secondary.end;
> +
> + cfg = pci_mmconfig_lookup(seg, start);
> + if (cfg)
> + return 0;
> +
> + cfg = pci_mmconfig_alloc(seg, start, end, root->mcfg_addr);
> + if (!cfg)
> + return -ENOMEM;
> +
> + err = pci_mmconfig_inject(cfg);
> + return err;

When you integrate Jayachandran's patch this whole function will
become a pci_mmconfig_insert() and that's where hot_added should
be set.

> +}
> +
> +void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci)
> +{
> + struct acpi_pci_root *root = ci->root;
> + struct pci_mmcfg_region *cfg;
> +
> + cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
> + if (!cfg)
> + return;
> +
> + if (cfg->hot_added)

Move the hot_added check in pci_mmconfig_delete() (that does the look
up again), we do not want to carry out pci_mmconfig_lookup only to
check that flag here (and we miss rcu locking for the look-up BTW).

Thanks,
Lorenzo

> + pci_mmconfig_delete(root->segment, root->secondary.start,
> + root->secondary.end);
> +}
> +
>  int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
>   struct acpi_mcfg_allocation *cfg)
>  {
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index a72e22d..65b91f3 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -80,6 +80,15 @@ extern struct pci_bus *acpi_pci_root_create(struct 
> acpi_pci_root *root,
>  void acpi_pci_add_bus(struct pci_bus *bus);
>  void acpi_pci_remove_bus(struct pci_bus *bus);
>  
> +#ifdef   CONFIG_PCI_MMCONFIG
> +int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci);
> +void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci);
> +#else
> +static inline int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
> +{ return 0; }
> +static inline void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci) { }
> +#endif
> +
>  #ifdef   CONFIG_ACPI_PCI_SLOT
>  void acpi_pci_slot_init(void);
>  void acpi_pci_slot_enumerate(struct pci_bus *bus);
> -- 
> 1.9.1
> 

Re: [RFC PATCH] mmc: sdhci-of-at91: don't put device in suspend after probe

[Ludovic Desroches]

On Wed, Feb 10, 2016 at 03:00:09PM +0200, Adrian Hunter wrote:
> On 10/02/16 14:51, Ludovic Desroches wrote:
> > Hi Adrian,
> > 
> > On Wed, Feb 10, 2016 at 01:50:44PM +0200, Adrian Hunter wrote:
> >> On 10/02/16 11:58, Ludovic Desroches wrote:
> >>> By putting the device in suspend at the end of the probe, it is
> >>> impossible to wake up on non software event such as card
> >>> insertion/removal.
> >>>
> >>> Signed-off-by: Ludovic Desroches 
> >>> ---
> >>>
> >>> Hi,
> >>>
> >>> Since I had no feedback on this topic:
> >>> http://permalink.gmane.org/gmane.linux.kernel.mmc/35160
> >>>
> >>> I would like to no more put the device in suspend at the end of the 
> >>> probe. If
> >>> my device is suspended at the end of the probe, I have no issue to resume 
> >>> on
> >>> a software event such as mounting my sdcard but hardware event such as 
> >>> card
> >>> insertion and removal do not trigger a resume.
> >>
> >> You can't use runtime PM unless you have a way to wake-up.
> >>
> > 
> > Thanks for your feedback. I am a bit disappointed since Ulf advised me to 
> > use
> > runtime PM instead of system PM.
> > 
> >> Currently, sdhci disables card detect interrupts when runtime suspended,
> >> and drivers use a card-detect GPIO to wake-up.
> >>
> > 
> > It is what I have seen going through the sdhci layer. So next question is:
> > is it normal to not take care of card detect interrupts? We keep enabled
> > some IRQs probably for SDIO modules IRQ but not for card detection. I
> > don't understand the reason.
> 
> Does sdhci-of-at91.c generate card detect interrupts while runtime suspended?

It could if I keep one or two clocks enabled (need extra tests to be
sure about the clock needed to get this interrupt). I have tried to modify
quickly sdhci_runtime_suspend_host() to enable card insertion/removal,
there is an irq generated but the kernel complains this irq is not
handled. I didn't dig further, it was only to do a simple test.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] arm: dts: add Artpec-6 soc dtsi file

[Arnd Bergmann]

On Wednesday 10 February 2016 13:41:53 Lars Persson wrote:
> Signed-off-by: Lars Persson 
> ---

Missing changelog

>  arch/arm/boot/dts/artpec6.dtsi | 238 
> +
>  1 file changed, 238 insertions(+)
>  create mode 100644 arch/arm/boot/dts/artpec6.dtsi
> 
> diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
> new file mode 100644
> index 000..c1790d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/artpec6.dtsi
> @@ -0,0 +1,238 @@
> +/*
> + * Device Tree Source for the Axis ARTPEC-6 SoC
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include 
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "axis,artpec6";
> + interrupt-parent = <>;
> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + };

Move the aliases into the board, not all boards might use all four
uarts, or some board might assign different numbers.

> + uart0: uart@f8036000 {

make this "serial@f8036000"

Arnd

Re: [PATCH v5 1/3] mailbox: Add support for APM X-Gene platform mailbox driver

[Mathieu Poirier]

On 9 February 2016 at 20:46, Duc Dang  wrote:
> On Tue, Feb 9, 2016 at 8:40 AM, Mathieu Poirier
>  wrote:
>> On 8 February 2016 at 15:04, Duc Dang  wrote:
>>> X-Gene mailbox controller provides 8 mailbox channels, with
>>> each channel has a dedicated interrupt line.
>>>
>>> Signed-off-by: Feng Kan 
>>> Signed-off-by: Duc Dang 
>>> ---
>>> Changes since v4:
>>> - Rebase over v4.5-rc1
>>> - Fix section mistmatch warning by removing
>>> __init in slimpro_mbox_probe declaration
>>> - Correctly print channel number when
>>> there is no IRQ for that channel
>>>
>>> Changes since v3:
>>> - Rebase over v4.4
>>> - Remove 'id' in slimpro_mbox_chan structure
>>> - Remove small functions that are only called once
>>> and fold them into the other callers
>>> - Remove void* pointer type cast
>>> - Relax the number of mailbox IRQs condition
>>> - Use subsys_initcall to guarantee mailbox driver
>>> will be registered before any other dependent driver
>>> is loaded.
>>>
>>>  drivers/mailbox/Kconfig |   9 ++
>>>  drivers/mailbox/Makefile|   2 +
>>>  drivers/mailbox/mailbox-xgene-slimpro.c | 264 
>>> 
>>>  3 files changed, 275 insertions(+)
>>>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>>>
>>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
>>> index 546d05f..678e434 100644
>>> --- a/drivers/mailbox/Kconfig
>>> +++ b/drivers/mailbox/Kconfig
>>> @@ -85,4 +85,13 @@ config MAILBOX_TEST
>>>   Test client to help with testing new Controller driver
>>>   implementations.
>>>
>>> +config XGENE_SLIMPRO_MBOX
>>> +   tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
>>> +   depends on ARCH_XGENE
>>> +   help
>>> + An implementation of the APM X-Gene Interprocessor Communication
>>> + Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro 
>>> controller.
>>> + It is used to send short messages between ARM64-bit cores and
>>> + the SLIMpro Management Engine, primarily for PM. Say Y here if you
>>> + want to use the APM X-Gene SLIMpro IPCM support.
>>>  endif
>>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
>>> index 92435ef..b602ef8 100644
>>> --- a/drivers/mailbox/Makefile
>>> +++ b/drivers/mailbox/Makefile
>>> @@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
>>>  obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
>>>
>>>  obj-$(CONFIG_STI_MBOX) += mailbox-sti.o
>>> +
>>> +obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
>>> diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
>>> b/drivers/mailbox/mailbox-xgene-slimpro.c
>>> new file mode 100644
>>> index 000..0ea1eb8
>>> --- /dev/null
>>> +++ b/drivers/mailbox/mailbox-xgene-slimpro.c
>>> @@ -0,0 +1,264 @@
>>> +/*
>>> + * APM X-Gene SLIMpro MailBox Driver
>>> + *
>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>> + * Author: Feng Kan f...@apm.com
>>> + *
>>> + * 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.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; if not, see .
>>> + *
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define MBOX_CON_NAME  "slimpro-mbox"
>>> +#define MBOX_REG_SET_OFFSET0x1000
>>> +#define MBOX_CNT   8
>>> +#define MBOX_STATUS_AVAIL_MASK BIT(16)
>>> +#define MBOX_STATUS_ACK_MASK   BIT(0)
>>> +
>>> +/* Configuration and Status Registers */
>>> +#define REG_DB_IN  0x00
>>> +#define REG_DB_DIN00x04
>>> +#define REG_DB_DIN10x08
>>> +#define REG_DB_OUT 0x10
>>> +#define REG_DB_DOUT0   0x14
>>> +#define REG_DB_DOUT1   0x18
>>> +#define REG_DB_STAT0x20
>>> +#define REG_DB_STATMASK0x24
>>> +
>>> +struct slimpro_mbox_chan {
>>> +   struct device *dev;
>>> +   struct mbox_chan *chan;
>>> +   void __iomem *reg;
>>> +   int irq;
>>> +   u32 rx_msg[3];
>>> +};
>>> +
>>> +struct slimpro_mbox {
>>> +   struct mbox_controller mb_ctrl;
>>> +   struct slimpro_mbox_chan 

Re: [PATCH] af_packet: Raw socket destruction warning fix

[Eric Dumazet]

On Wed, 2016-02-10 at 12:43 +, Vaneet Narang wrote:
> Hi,
> 
> >What driver are you using (is that in-tree)? Can you reproduce the same issue
> >with a latest -net kernel, for example (or, a 'reasonably' recent one like 
> >4.3 or
> >4.4)? There has been quite a bit of changes in err queue handling (which also
> >accounts rmem) as well. How reliably can you trigger the issue? Does it 
> >trigger
> >with a completely different in-tree network driver as well with your tests? 
> >Would
> >be useful to track/debug sk_rmem_alloc increases/decreases to see from which 
> >path
> >new rmem is being charged in the time between packet_release() and 
> >packet_sock_destruct()
> >for that socket ...
> >
> It seems race condition to us between packet_rcv and packet_close, we have 
> tried to reproduce
> this issue by adding delay in skb_set_owner_r and issue gets reproduced quite 
> frequently. 
> we have added some traces and on analyzing we have realised following 
> possible race condition.



Even if you add a delay in skb_set_owner_r(), this should not allow the
dismantle phase to complete, since at least one cpu is still in a
rcu_read_lock() section.

synchronize_rcu() must complete only when all cpus pass an rcu quiescent
point.

packet_close() should certainly not be called while another cpu is still
in the middle of packet_rcv()

Your patch does not address the root cause.

[PATCH] irq_work: unhide irq_work_queue_on declaration on non-SMP

[Arnd Bergmann]

The cpufreq code uses 'if (IS_ENABLED(CONFIG_SMP))' to check
whether it should queue a task on the local CPU or a remote
one, however the irq_work_queue_on() function is not declared
when CONFIG_SMP is not set:

drivers/cpufreq/cpufreq_governor.c: In function 'gov_queue_irq_work':
drivers/cpufreq/cpufreq_governor.c:251:3: error: implicit declaration of 
function 'irq_work_queue_on' [-Werror=implicit-function-declaration]
   irq_work_queue_on(_dbs->irq_work, smp_processor_id());

This changes the conditional declaration so that irq_work_queue_on
just queues the irq work on the only available CPU when CONFIG_SMP
is not set, which is presumably what most people need anyway.

Signed-off-by: Arnd Bergmann 
Fixes: 0144fa03ef46 ("cpufreq: governor: Replace timers with utilization update 
callbacks")

diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index 47b9ebd4a74f..c9bde50ef317 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -33,9 +33,13 @@ void init_irq_work(struct irq_work *work, void 
(*func)(struct irq_work *))
 #define DEFINE_IRQ_WORK(name, _f) struct irq_work name = { .func = (_f), }
 
 bool irq_work_queue(struct irq_work *work);
-
 #ifdef CONFIG_SMP
 bool irq_work_queue_on(struct irq_work *work, int cpu);
+#else
+static inline bool irq_work_queue_on(struct irq_work *work, int cpu)
+{
+   return irq_work_queue(work);
+}
 #endif
 
 void irq_work_tick(void);

Re: [linux-sunxi] Re: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3

[Maxime Ripard]

Hi,

On Wed, Feb 10, 2016 at 08:17:14AM +0100, Krzysztof Adamski wrote:
> On Tue, Feb 09, 2016 at 06:10:40PM +0100, Maxime Ripard wrote:
> It seems that the other compatible strings are there for historical
> reasons. Why do you need a new one with such a specific name?
> 
> It would have been more sensible to add a generic compatible string as
> "allwinner,apb-gates", letting the removal of the other strings for a
> later patch...
> >>>
> >>>Yeah, it's a good idea, and it's probably time that we move to that.
> >>>
> >>>However, I'd like to keep per-soc and per-clocks compatibles in the
> >>>DT, in case we need to protect a clock in the future. That doesn't
> >>>prevent to have two compatibles thoughe, the specific and the generic.
> >>>
> >>
> >>So now I'm not sure what you mean. You suggest that I should keep using
> >>specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch?
> >
> >Both.
> >
> >To have something like that:
> >
> >compatible = "allwinner,sun8i-h3-apb0-gates-clk", 
> >"allwinner,sun4i-a10-gates-clk";
> >
> >sun4i-a10-gates-clk being the generic compatible that we would use,
> >and we can always match against the h3 specific compatible if we need
> >to have a different behaviour.
> 
> This seems like a good idea to me but since this is new thing anyways (other
> sunxi SoCs don't do this right now) shouldn't we introduce other
> more generic name for generic clock (like "allwinner,apb-gates" mentioned
> earlier, or maybe "allwinner,simple-apb-gates")?

This is not specific to the APB bus, and the earlier SoC that
introduced those kind of clocks was the A10, hence why I was
suggesting that compatible (since we generally try to use the SoC that
introduced that hardware block in the compatible name).

> Also, wouldn't this be cleaner if I use only specific compatible string
> right now and provide separate patch that adds generic compatible string to
> all current SoCs at once? The downside of this is that it's easier to get
> merge conflicts unless I wait for applying this patchset.

I'd prefer if you added the generic one and were using it in your
subsequent patches. We can always mass convert the existing drivers
later on.

Thanks!
Maxime

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


signature.asc
Description: Digital signature

[PATCH v6 2/3] cpufreq: intel_pstate: Replace timers with utilization update callbacks

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Instead of using a per-CPU deferrable timer for utilization sampling
and P-states adjustments, register a utilization update callback that
will be invoked from the scheduler on utilization changes.

The sampling rate is still the same as what was used for the deferrable
timers, so the functional impact of this patch should not be significant.

Based on an earlier patch from Srinivas Pandruvada.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Srinivas Pandruvada 
---

No changes from the previous version.

---
 drivers/cpufreq/intel_pstate.c |  103 +++--
 1 file changed, 39 insertions(+), 64 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -71,7 +71,7 @@ struct sample {
u64 mperf;
u64 tsc;
int freq;
-   ktime_t time;
+   u64 time;
 };
 
 struct pstate_data {
@@ -103,13 +103,13 @@ struct _pid {
 struct cpudata {
int cpu;
 
-   struct timer_list timer;
+   struct update_util_data update_util;
 
struct pstate_data pstate;
struct vid_data vid;
struct _pid pid;
 
-   ktime_t last_sample_time;
+   u64 last_sample_time;
u64 prev_aperf;
u64 prev_mperf;
u64 prev_tsc;
@@ -120,6 +120,7 @@ struct cpudata {
 static struct cpudata **all_cpu_data;
 struct pstate_adjust_policy {
int sample_rate_ms;
+   s64 sample_rate_ns;
int deadband;
int setpoint;
int p_gain_pct;
@@ -712,7 +713,7 @@ static void core_set_pstate(struct cpuda
if (limits->no_turbo && !limits->turbo_disabled)
val |= (u64)1 << 32;
 
-   wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val);
+   wrmsrl(MSR_IA32_PERF_CTL, val);
 }
 
 static int knl_get_turbo_pstate(void)
@@ -883,7 +884,7 @@ static inline void intel_pstate_calc_bus
sample->core_pct_busy = (int32_t)core_pct;
 }
 
-static inline void intel_pstate_sample(struct cpudata *cpu)
+static inline void intel_pstate_sample(struct cpudata *cpu, u64 time)
 {
u64 aperf, mperf;
unsigned long flags;
@@ -900,7 +901,7 @@ static inline void intel_pstate_sample(s
local_irq_restore(flags);
 
cpu->last_sample_time = cpu->sample.time;
-   cpu->sample.time = ktime_get();
+   cpu->sample.time = time;
cpu->sample.aperf = aperf;
cpu->sample.mperf = mperf;
cpu->sample.tsc =  tsc;
@@ -915,22 +916,6 @@ static inline void intel_pstate_sample(s
cpu->prev_tsc = tsc;
 }
 
-static inline void intel_hwp_set_sample_time(struct cpudata *cpu)
-{
-   int delay;
-
-   delay = msecs_to_jiffies(50);
-   mod_timer_pinned(>timer, jiffies + delay);
-}
-
-static inline void intel_pstate_set_sample_time(struct cpudata *cpu)
-{
-   int delay;
-
-   delay = msecs_to_jiffies(pid_params.sample_rate_ms);
-   mod_timer_pinned(>timer, jiffies + delay);
-}
-
 static inline int32_t get_target_pstate_use_cpu_load(struct cpudata *cpu)
 {
struct sample *sample = >sample;
@@ -970,8 +955,7 @@ static inline int32_t get_target_pstate_
 static inline int32_t get_target_pstate_use_performance(struct cpudata *cpu)
 {
int32_t core_busy, max_pstate, current_pstate, sample_ratio;
-   s64 duration_us;
-   u32 sample_time;
+   u64 duration_ns;
 
/*
 * core_busy is the ratio of actual performance to max
@@ -990,18 +974,16 @@ static inline int32_t get_target_pstate_
core_busy = mul_fp(core_busy, div_fp(max_pstate, current_pstate));
 
/*
-* Since we have a deferred timer, it will not fire unless
-* we are in C0.  So, determine if the actual elapsed time
-* is significantly greater (3x) than our sample interval.  If it
-* is, then we were idle for a long enough period of time
-* to adjust our busyness.
+* Since our utilization update callback will not run unless we are
+* in C0, check if the actual elapsed time is significantly greater (3x)
+* than our sample interval.  If it is, then we were idle for a long
+* enough period of time to adjust our busyness.
 */
-   sample_time = pid_params.sample_rate_ms  * USEC_PER_MSEC;
-   duration_us = ktime_us_delta(cpu->sample.time,
-cpu->last_sample_time);
-   if (duration_us > sample_time * 3) {
-   sample_ratio = div_fp(int_tofp(sample_time),
- int_tofp(duration_us));
+   duration_ns = cpu->sample.time - cpu->last_sample_time;
+   if ((s64)duration_ns > pid_params.sample_rate_ns * 3
+   && cpu->last_sample_time > 0) {
+   sample_ratio = 

[PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup

[Tejun Heo]

Hello,

With 874bbfe600a6 reverted, this doesn't matter as much but I'm still
committing it to wq/for-4.5-fixes.  The commit message has been
updated accordingly.

Thanks.

-- 8< --
>From 9354baa208f47bf088c28c1da5f38abe172db5d6 Mon Sep 17 00:00:00 2001
From: Tejun Heo 
Date: Wed, 3 Feb 2016 13:54:25 -0500

When looking up the pool_workqueue to use for an unbound workqueue,
workqueue assumes that the target CPU is always bound to a valid NUMA
node.  However, currently, when a CPU goes offline, the mapping is
destroyed and cpu_to_node() returns NUMA_NO_NODE.

This has always been broken but hasn't triggered often enough before
874bbfe600a6 ("workqueue: make sure delayed work run in local cpu").
After the commit, workqueue forcifully assigns the local CPU for
delayed work items without explicit target CPU to fix a different
issue.  This widens the window where CPU can go offline while a
delayed work item is pending causing delayed work items dispatched
with target CPU set to an already offlined CPU.  The resulting
NUMA_NO_NODE mapping makes workqueue try to queue the work item on a
NULL pool_workqueue and thus crash.

While 874bbfe600a6 has been reverted for a different reason making the
bug less visible again, it can still happen.  Fix it by mapping
NUMA_NO_NODE to the default pool_workqueue from unbound_pwq_by_node().
This is a temporary workaround.  The long term solution is keeping CPU
-> NODE mapping stable across CPU off/online cycles which is being
worked on.

Signed-off-by: Tejun Heo 
Reported-by: Mike Galbraith 
Cc: Tang Chen 
Cc: Rafael J. Wysocki 
Cc: Len Brown 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/g/1454424264.11183.46.ca...@gmail.com
Link: 
http://lkml.kernel.org/g/1453702100-2597-1-git-send-email-tangc...@cn.fujitsu.com
---
 kernel/workqueue.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index dc7faad..3ca7ab8 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -570,6 +570,16 @@ static struct pool_workqueue *unbound_pwq_by_node(struct 
workqueue_struct *wq,
  int node)
 {
assert_rcu_or_wq_mutex_or_pool_mutex(wq);
+
+   /*
+* XXX: @node can be NUMA_NO_NODE if CPU goes offline while a
+* delayed item is pending.  The plan is to keep CPU -> NODE
+* mapping valid and stable across CPU on/offlines.  Once that
+* happens, this workaround can be removed.
+*/
+   if (unlikely(node == NUMA_NO_NODE))
+   return wq->dfl_pwq;
+
return rcu_dereference_raw(wq->numa_pwq_tbl[node]);
 }
 
-- 
2.5.0

Re: [PATCH v9 2/2] mfd: add documentation for ACT8945A DT bindings

[Lee Jones]

On Wed, 27 Jan 2016, Wenyou Yang wrote:

> The Active-semi ACT8945A PMIC is a Multi-Function Device, it has
> two subdevices:
>  - Regulator
>  - Charger
> 
> This patch adds documentation for ACT8945A DT bindings.
> 
> Signed-off-by: Wenyou Yang 
> Acked-by: Rob Herring 
> Acked-by: Lee Jones 
> ---
> 
> Changes in v9: None
> Changes in v8: None
> Changes in v7:
>  - collect Acked-by from Lee Jones
> 
> Changes in v6:
>  - change the regulator name.
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - fix the tabbing errors in Example.
>  - use "pmic@5b" label, not "act8945a@5b" in Example.
>  - collect Acked-by from Rob.
> 
> Changes in v2:
>  - use more specific label in Example.
>  - add pmic and charger nodes in Example.
> 
>  Documentation/devicetree/bindings/mfd/act8945a.txt |   82 
> 
>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/act8945a.txt

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt 
> b/Documentation/devicetree/bindings/mfd/act8945a.txt
> new file mode 100644
> index 000..f2a8387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/act8945a.txt
> @@ -0,0 +1,82 @@
> +Device-Tree bindings for Active-semi ACT8945A MFD driver
> +
> +Required properties:
> + - compatible: "active-semi,act8945a".
> + - reg: the I2C slave address for the ACT8945A chip
> +
> +The chip exposes two subdevices:
> + - a regulators: see ../regulator/act8945a-regulator.txt
> + - a charger: see ../power/act8945a-charger.txt
> +
> +Example:
> + pmic@5b {
> + compatible = "active-semi,act8945a";
> + reg = <0x5b>;
> + status = "okay";
> +
> + pmic {
> + compatible = "active-semi,act8945a-regulator";
> + active-semi,vsel-high;
> +
> + regulators {
> + vdd_1v35_reg: REG_DCDC1 {
> + regulator-name = "VDD_1V35";
> + regulator-min-microvolt = <135>;
> + regulator-max-microvolt = <135>;
> + regulator-always-on;
> + };
> +
> + vdd_1v2_reg: REG_DCDC2 {
> + regulator-name = "VDD_1V2";
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <130>;
> + regulator-always-on;
> + };
> +
> + vdd_3v3_reg: REG_DCDC3 {
> + regulator-name = "VDD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_fuse_reg: REG_LDO1 {
> + regulator-name = "VDD_FUSE";
> + regulator-min-microvolt = <250>;
> + regulator-max-microvolt = <250>;
> + regulator-always-on;
> + };
> +
> + vdd_3v3_lp_reg: REG_LDO2 {
> + regulator-name = "VDD_3V3_LP";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_led_reg: REG_LDO3 {
> + regulator-name = "VDD_LED";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_sdhc_1v8_reg: REG_LDO4 {
> + regulator-name = "VDD_SDHC_1V8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + charger {
> + compatible = "active-semi,act8945a-charger";
> + pinctrl-names = "default";
> + pinctrl-0 = <_charger_chglev>;
> + active-semi,chglev-gpio = < 12 GPIO_ACTIVE_HIGH>;
> + 

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[Dan Williams]

On Wed, 2016-02-10 at 17:07 +0100, Johannes Berg wrote:
> On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote:
> > I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> > RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> > state. It's just an indicator with no relationship to any of the
> > registered rfkill switches, right?
> 
> Yes. I'm not sure I'm totally happy with this userspace API.
> 
> > I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't
> > also
> > softblock all switches, otherwise you can set airplane mode all day
> > long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually
> > enable
> > airplane mode at all?
> 
> No, this is kinda the point that you could implement your policy in
> userspace now.

Yeah, I get that now.  It's just that to me, something called
"AIRPLANE_MODE_CHANGE" seems like it should actually change airplane
mode on/off, which implies killing radios.  I wouldn't have had the
problem if it was named AIRPLANE_MODE_INDICATOR_CHANGE, which makes it
clear this is simply an indicator and has no actual effect on anything
other than a LED.

Dan

Re: [PATCH V1] mfd: da9062: fix missing volatile registers in the core regmap_range volatile lists

[Lee Jones]

On Mon, 01 Feb 2016, Steve Twiss wrote:

> From: Steve Twiss 
> 
> Add an updated set of registers listed in the core regmap_range volatile
> ranges defined for the DA9062.
> 
> These new registers contain bits that cannot be considered under the full
> control of software. Under various conditions the hardware will set and/or
> automatically clear bit(s) contained in these registers.
> 
> When using a cached version of regmap, the volatility of these registers must
> be identified otherwise the regmap operations may not ensure the registers
> are explicitly altered.
> 
> As well as updating the list of volatile registers, this change will fix a
> corner case discovered in the DA9063 ONKEY which is used by the DA9062 core.
>  
> In the ONKEY case, the CONTROL_B register is now listed as volatile in the
> regmap_range because it contains the bit field NONKEY_LOCK. This bit can be
> altered by hardware, in which case regmap must be notified of its ability
> to be manpiulated outside of software control.
> 
> Signed-off-by: Steve Twiss 

Applied, thanks.

> ---
> Checks performed with linux-next/v4.5-rc1/scripts/checkpatch.pl
>  da9062-core.c total: 0 errors, 0 warnings, 554 lines checked
> This patch applies against linux-next and v4.5-rc1
> 
> Regards,
> Steve
> 
> 
>  drivers/mfd/da9062-core.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index a9ad024..8f873866 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
> @@ -388,11 +388,32 @@ static const struct regmap_range 
> da9062_aa_volatile_ranges[] = {
>   .range_min = DA9062AA_STATUS_D,
>   .range_max = DA9062AA_EVENT_C,
>   }, {
> - .range_min = DA9062AA_CONTROL_F,
> + .range_min = DA9062AA_CONTROL_A,
> + .range_max = DA9062AA_CONTROL_B,
> + }, {
> + .range_min = DA9062AA_CONTROL_E,
>   .range_max = DA9062AA_CONTROL_F,
>   }, {
> + .range_min = DA9062AA_BUCK2_CONT,
> + .range_max = DA9062AA_BUCK4_CONT,
> + }, {
> + .range_min = DA9062AA_BUCK3_CONT,
> + .range_max = DA9062AA_BUCK3_CONT,
> + }, {
> + .range_min = DA9062AA_LDO1_CONT,
> + .range_max = DA9062AA_LDO4_CONT,
> + }, {
> + .range_min = DA9062AA_DVC_1,
> + .range_max = DA9062AA_DVC_1,
> + }, {
>   .range_min = DA9062AA_COUNT_S,
>   .range_max = DA9062AA_SECOND_D,
> + }, {
> + .range_min = DA9062AA_SEQ,
> + .range_max = DA9062AA_SEQ,
> + }, {
> + .range_min = DA9062AA_EN_32K,
> + .range_max = DA9062AA_EN_32K,
>   },
>  };
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v10 2/2] mfd: add documentation for ACT8945A DT bindings

[Lee Jones]

On Fri, 05 Feb 2016, Wenyou Yang wrote:

> The Active-semi ACT8945A PMIC is a Multi-Function Device, it has
> two subdevices:
>  - Regulator
>  - Charger
> 
> This patch adds documentation for ACT8945A DT bindings.
> 
> Signed-off-by: Wenyou Yang 
> Acked-by: Rob Herring 
> Acked-by: Lee Jones 
> ---
> 
> Changes in v10:
>  - update the example, due to the subdevices are not regarded as
>a child node.

v9 unapplied, v10 applied.

> Changes in v9: None
> Changes in v8: None
> Changes in v7:
>  - collect Acked-by from Lee Jones
> 
> Changes in v6:
>  - change the regulator name.
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - fix the tabbing errors in Example.
>  - use "pmic@5b" label, not "act8945a@5b" in Example.
>  - collect Acked-by from Rob.
> 
> Changes in v2:
>  - use more specific label in Example.
>  - add pmic and charger nodes in Example.
> 
>  Documentation/devicetree/bindings/mfd/act8945a.txt |   76 
> 
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/act8945a.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt 
> b/Documentation/devicetree/bindings/mfd/act8945a.txt
> new file mode 100644
> index 000..f712830
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/act8945a.txt
> @@ -0,0 +1,76 @@
> +Device-Tree bindings for Active-semi ACT8945A MFD driver
> +
> +Required properties:
> + - compatible: "active-semi,act8945a".
> + - reg: the I2C slave address for the ACT8945A chip
> +
> +The chip exposes two subdevices:
> + - a regulators: see ../regulator/act8945a-regulator.txt
> + - a charger: see ../power/act8945a-charger.txt
> +
> +Example:
> + pmic@5b {
> + compatible = "active-semi,act8945a";
> + reg = <0x5b>;
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_charger_chglev>;
> + active-semi,chglev-gpio = < 12 GPIO_ACTIVE_HIGH>;
> + active-semi,input-voltage-threshold-microvolt = <6600>;
> + active-semi,precondition-timeout = <40>;
> + active-semi,total-timeout = <3>;
> +
> + active-semi,vsel-high;
> +
> + regulators {
> + vdd_1v35_reg: REG_DCDC1 {
> + regulator-name = "VDD_1V35";
> + regulator-min-microvolt = <135>;
> + regulator-max-microvolt = <135>;
> + regulator-always-on;
> + };
> +
> + vdd_1v2_reg: REG_DCDC2 {
> + regulator-name = "VDD_1V2";
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <130>;
> + regulator-always-on;
> + };
> +
> + vdd_3v3_reg: REG_DCDC3 {
> + regulator-name = "VDD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_fuse_reg: REG_LDO1 {
> + regulator-name = "VDD_FUSE";
> + regulator-min-microvolt = <250>;
> + regulator-max-microvolt = <250>;
> + regulator-always-on;
> + };
> +
> + vdd_3v3_lp_reg: REG_LDO2 {
> + regulator-name = "VDD_3V3_LP";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_led_reg: REG_LDO3 {
> + regulator-name = "VDD_LED";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_sdhc_1v8_reg: REG_LDO4 {
> + regulator-name = "VDD_SDHC_1V8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> + };
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH] sched-deadline: Trivial fix to printk spelling typo

[Steven Rostedt]

It's "too much" not "to much".

Signed-off-by: Steven Rostedt 
---
 kernel/sched/deadline.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-trace.git/kernel/sched/deadline.c
===
--- linux-trace.git.orig/kernel/sched/deadline.c2016-02-08 
10:55:56.314287814 -0500
+++ linux-trace.git/kernel/sched/deadline.c 2016-02-08 10:57:19.692983493 
-0500
@@ -420,7 +420,7 @@ static void replenish_dl_entity(struct s
 * entity.
 */
if (dl_time_before(dl_se->deadline, rq_clock(rq))) {
-   printk_deferred_once("sched: DL replenish lagged to much\n");
+   printk_deferred_once("sched: DL replenish lagged too much\n");
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}

Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Martin Kepplinger]

Am 2016-02-09 um 12:44 schrieb Takashi Iwai:
> On Tue, 09 Feb 2016 07:34:48 +0100,
> Martin Kepplinger wrote:
>>
>> The following change:
>>
>> 788d441 ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling
>>
>> breaks audio over HDMI on my snd_hda_intel laptop. It is the first bad
>> commit.
>>
>> This was merged for -rc1 and isn't fixed until now, so I got nervous.
>> There are
>> no errors in the log that stand out. I'm no sound or alsa developer, and
>> just reverting it isn't easy since there is stuff depending on this.
>>
>> I'm happy to test possible fixes and hope v4.5 not to ship with such a big
>> regression ;)
> 
> Could you give a bit more detail about your hardware?  At best, give
> alsa-info.sh output (run with --no-upload option).  Also, give the
> output of dmesg, too.
> 
> In addition, what shows /proc/asound/card*/eld#*.* files?  Does any of
> it show the proper connection state and ELD?

alsa-info and dmesg are appended, and

root@laptop:/home/martin/dev# cat /proc/asound/card*/eld#*
monitor_present 0
eld_valid   0


> 
> A simple revert of the commit is a patch like below.  Does it make the
> HDMI audio working again?
> 

It does! Everything back to normal in this case. Any idea for a proper
fix? Again, I'm happy to test.

martin


> 
> thanks,
> 
> Takashi
> 
> ---
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -156,7 +156,7 @@ struct hdmi_spec {
>   bool i915_bound; /* was i915 bound in this driver? */
>  };
>  
> -#ifdef CONFIG_SND_HDA_I915
> +#if 0
>  #define codec_has_acomp(codec) \
>   ((codec)->bus->core.audio_component != NULL)
>  #else
> 

upload=true=true=
!!
!!ALSA Information Script v 0.4.64
!!

!!Script ran on: Wed Feb 10 14:56:37 UTC 2016


!!Linux Distribution
!!--

Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian 
GNU/Linux" ID=debian HOME_URL="http://www.debian.org/; 
SUPPORT_URL="http://www.debian.org/support; 
BUG_REPORT_URL="https://bugs.debian.org/;


!!DMI Information
!!---

Manufacturer:  Acer
Product Name:  TravelMate B113
Product Version:   V1.09
Firmware Version:  V1.09


!!Kernel Information
!!--

Kernel release:4.5.0-rc3
Operating System:  GNU/Linux
Architecture:  x86_64
Processor: unknown
SMP Enabled:   Yes


!!ALSA Version
!!

Driver version: k4.5.0-rc3
Library version:1.0.28
Utilities version:  1.0.28


!!Loaded ALSA modules
!!---

snd_hda_intel


!!Sound Servers on this system
!!

Pulseaudio:
  Installed - Yes (/usr/bin/pulseaudio)
  Running - Yes


!!Soundcards recognised by ALSA
!!-

 0 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0xc061 irq 29


!!PCI Soundcards installed in the system
!!--

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family 
High Definition Audio Controller (rev 04)


!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!---

00:1b.0 0403: 8086:1e20 (rev 04)
Subsystem: 1025:0748


!!Modprobe options (Sound related)
!!

snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2


!!Loaded sound module options
!!---

!!Module: snd_hda_intel
align_buffer_size : -1
bdl_pos_adj : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
beep_mode : 
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable_msi : -1
id : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
index : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
jackpoll_ms : 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
model : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
patch : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
position_fix : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
  

[PATCH] Bluetooth: hci_intel: Fix a wrong comparison

[Anton Protopopov]

A return value of the intel_wait_booting() function compared with
a constant ETIMEDOUT instead of -ETIMEDOUT.

Signed-off-by: Anton Protopopov 
---
 drivers/bluetooth/hci_intel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
index 3d63ea3..91d6051 100644
--- a/drivers/bluetooth/hci_intel.c
+++ b/drivers/bluetooth/hci_intel.c
@@ -488,7 +488,7 @@ static int intel_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
clear_bit(STATE_BOOTING, >flags);
 
/* In case of timeout, try to continue anyway */
-   if (err && err != ETIMEDOUT)
+   if (err && err != -ETIMEDOUT)
return err;
 
bt_dev_info(hdev, "Change controller speed to %d", speed);
@@ -581,7 +581,7 @@ static int intel_setup(struct hci_uart *hu)
clear_bit(STATE_BOOTING, >flags);
 
/* In case of timeout, try to continue anyway */
-   if (err && err != ETIMEDOUT)
+   if (err && err != -ETIMEDOUT)
return err;
 
set_bit(STATE_BOOTLOADER, >flags);
-- 
2.6.5

Re: [PATCH] printk: avoid livelock if another CPU printks continuously

[Petr Mladek]

On Wed 2016-02-10 09:44:07, Steven Rostedt wrote:
> On Wed, 10 Feb 2016 15:36:49 +0100
> Petr Mladek  wrote:
> 
> > Bcc: 
> > Subject: Re: [PATCH] printk: avoid livelock if another CPU printks
> >  continuously
> > Reply-To: 
> > In-Reply-To: <1454963703-20433-1-git-send-email-dvlas...@redhat.com>
> > 
> 
> Hmm, playing with mail headers?

Yeah. I am trying to do this reply back in the original thread.

> > > + /* Good, other CPU entered "for(;;)" loop */
> > > + goto out;
> > > + }
> > > + }
> > > + /* No one seems to be willing to take it... */
> > > + if (console_trylock())
> > > + goto again; /* we took it */
> > > + /* Nope, someone else holds console_sem! Good */  
> > 
> > The cycle gives a big chance other CPUs to enter console_unlock().
> > It means that more CPUs might end up in the above busy cycle.
> > 
> > It gives a chance to move the printing to another CPU. It likely
> > slows down the flood of messages because the producer end up
> > here as well.
> > 
> > So, it probably works but the performance is far from optimal.
> > Many CPUs might end up doing nothing. I am afraid that this is
> > not the right way to go.
> 
> Note, it's not that performance critical, and the loop only happens if
> someone else is adding to the console, which hopefully, should be rare.

I probably used too strong words. It is possible that the performance
impact will not be critical. But the behavior is non-deterministic.
I think that the approach taken by Jack is more promising.
I mean the offloading of the console stuff to a workqueue.

Best Regards,
Petr

Re: [PATCH RESEND 6/7] mfd: arizona: Update small typo in Arizona SPI Kconfig

[Lee Jones]

On Tue, 09 Feb 2016, Charles Keepax wrote:

> The help text had a copy and paste error and refers to I2C in the SPI
> section. This patch corrects this typo.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9f012b7..d438a73 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1385,7 +1385,7 @@ config MFD_ARIZONA_SPI
>   depends on SPI_MASTER
>   help
> Support for the Cirrus Logic/Wolfson Microelectronics Arizona platform
> -   audio SoC core functionality controlled via I2C.
> +   audio SoC core functionality controlled via SPI.
>  
>  config MFD_CS47L24
>   bool "Cirrus Logic CS47L24 and WM1831"

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] printk: avoid livelock if another CPU printks continuously

[Steven Rostedt]

On Wed, 10 Feb 2016 17:10:16 +0100
Petr Mladek  wrote:

> > Note, it's not that performance critical, and the loop only happens if
> > someone else is adding to the console, which hopefully, should be rare.  
> 
> I probably used too strong words. It is possible that the performance
> impact will not be critical. But the behavior is non-deterministic.
> I think that the approach taken by Jack is more promising.
> I mean the offloading of the console stuff to a workqueue.

My worry about that is that it never comes out. The point about printk,
is that it should pretty much be guaranteed to print. If the system is
dying, and we push it off to a work queue, and that workqueue never
runs, then we lose critical data.

-- Steve

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > Hi Sricharan,
> > 
> > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > right?
> >
>  Yes.
>  
> > I'm asking this because this driver doesn't seem to support runtime pm and
> > there is no check for regmap_write/regmap_write return code in the probe
> > function.
>Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> right ?
>I was tracking that when there are i2c_xfers from pwm. I did not see any 
> failures there.
>So wanted to know the correct sequence to reproduce.
>

The problem was discovered using the patch that this thread is on. The PWM 
driver does
not have the problem.

When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

> Regards,
>   Sricharan
>   
> 
> 

Re: [PATCH v1 6/6] platform/chrome: Check the USB PD feature before creating a charger

[Lee Jones]

On Fri, 05 Feb 2016, Tomeu Vizoso wrote:

> From: Vincent Palatin 
> 
> Use the EC_CMD_GET_FEATURES message to check the supported features for
> each MCU before instantied a USB-PD charger.
> 
> Signed-off-by: Vincent Palatin 
> [tomeu: adapted to changes in mainline]
> Signed-off-by: Tomeu Vizoso 
> Reviewed-by: Gwendal Grignou 
> 
> ---
> 
>  drivers/platform/chrome/cros_ec_dev.c | 40 -
>  include/linux/mfd/cros_ec.h   |  1 +
>  include/linux/mfd/cros_ec_commands.h  | 84 
> +++

Acked-by: Lee Jones 

>  3 files changed, 124 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_dev.c 
> b/drivers/platform/chrome/cros_ec_dev.c
> index 7a97cd313c68..1995cccfc59c 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -87,6 +87,41 @@ exit:
>   return ret;
>  }
>  
> +static int cros_ec_check_features(struct cros_ec_dev *ec, int feature)
> +{
> + struct cros_ec_command *msg;
> + int ret;
> +
> + if (ec->features[0] == -1U && ec->features[1] == -1U) {
> + /* features bitmap not read yet */
> +
> + msg = kmalloc(sizeof(*msg) + sizeof(ec->features), GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
> +
> + msg->version = 0;
> + msg->command = EC_CMD_GET_FEATURES + ec->cmd_offset;
> + msg->insize = sizeof(ec->features);
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec->ec_dev, msg);
> + if ((ret < 0) || msg->result != EC_RES_SUCCESS) {
> + dev_warn(ec->dev, "cannot get EC features: %d/%d\n",
> +  ret, msg->result);
> + memset(ec->features, 0, sizeof(ec->features));
> + }
> +
> + memcpy(ec->features, msg->data, sizeof(ec->features));
> +
> + dev_dbg(ec->dev, "EC features %08x %08x\n",
> + ec->features[0], ec->features[1]);
> +
> + kfree(msg);
> + }
> +
> + return ec->features[feature / 32] & EC_FEATURE_MASK_0(feature);
> +}
> +
>  static int cros_ec_has_cmd_usb_pd_ports(struct cros_ec_dev *ec)
>  {
>   struct cros_ec_command *msg;
> @@ -255,6 +290,8 @@ static int ec_device_probe(struct platform_device *pdev)
>   ec->ec_dev = dev_get_drvdata(dev->parent);
>   ec->dev = dev;
>   ec->cmd_offset = ec_platform->cmd_offset;
> + ec->features[0] = -1U; /* Not cached yet */
> + ec->features[1] = -1U; /* Not cached yet */
>   device_initialize(>class_dev);
>   cdev_init(>cdev, );
>  
> @@ -293,7 +330,8 @@ static int ec_device_probe(struct platform_device *pdev)
>   }
>  
>   /* check whether this EC instance has the PD charge manager */
> - if (cros_ec_has_cmd_usb_pd_ports(ec)) {
> + if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) ||
> + cros_ec_has_cmd_usb_pd_ports(ec)) {
>   retval = cros_ec_usb_pd_charger_register(dev);
>   if (retval) {
>   dev_err(dev, "failed to add usb-pd-charger device\n");
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 543191f493a9..02ad92572d5a 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -193,6 +193,7 @@ struct cros_ec_dev {
>   struct cros_ec_device *ec_dev;
>   struct device *dev;
>   u16 cmd_offset;
> + u32 features[2];
>  };
>  
>  /**
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index 4f056d2747ff..cc3a4b1b19e8 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -716,6 +716,90 @@ struct ec_response_get_set_value {
>  /* More than one command can use these structs to get/set paramters. */
>  #define EC_CMD_GSV_PAUSE_IN_S5   0x0c
>  
> +/*/
> +/* List the features supported by the firmware */
> +#define EC_CMD_GET_FEATURES  0x0d
> +
> +/* Supported features */
> +enum ec_feature_code {
> + /*
> +  * This image contains a limited set of features. Another image
> +  * in RW partition may support more features.
> +  */
> + EC_FEATURE_LIMITED = 0,
> + /*
> +  * Commands for probing/reading/writing/erasing the flash in the
> +  * EC are present.
> +  */
> + EC_FEATURE_FLASH = 1,
> + /*
> +  * Can control the fan speed directly.
> +  */
> + EC_FEATURE_PWM_FAN = 2,
> + /*
> +  * Can control the intensity of the keyboard backlight.
> +  */
> + EC_FEATURE_PWM_KEYB = 3,
> + /*
> +  * Support Google lightbar, introduced on Pixel.
> +  */
> + EC_FEATURE_LIGHTBAR = 4,
> + /* Control of LEDs  */
> + EC_FEATURE_LED = 

Re: [PATCH v1 5/6] platform/chrome: Register USB PD charger device

[Lee Jones]

On Fri, 05 Feb 2016, Tomeu Vizoso wrote:

> Check if a EC considers EC_CMD_USB_PD_PORTS a valid command and register
> a USB PD charger device if so. This check is needed for older versions
> of the ChromeOS EC firmware that don't support the EC_CMD_GET_FEATURES
> command.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
>  drivers/mfd/cros_ec.c | 15 +++
>  drivers/platform/chrome/cros_ec_dev.c | 34 ++
>  include/linux/mfd/cros_ec.h   |  2 ++
>  3 files changed, 51 insertions(+)
> 
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index fbe78b819fdd..20ca9794d2f3 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -202,5 +202,20 @@ EXPORT_SYMBOL(cros_ec_resume);
>  
>  #endif
>  
> +static const struct mfd_cell cros_usb_pd_charger_devs[] = {
> + {
> + .name = "cros-usb-pd-charger",
> + .id   = -1,
> + },
> +};
> +
> +int cros_ec_usb_pd_charger_register(struct device *dev)
> +{
> + return mfd_add_devices(dev, 0, cros_usb_pd_charger_devs,
> +ARRAY_SIZE(cros_usb_pd_charger_devs),
> +NULL, 0, NULL);
> +}
> +EXPORT_SYMBOL(cros_ec_usb_pd_charger_register);

I'm not keen on this idea at all.

You're calling cros_ec_usb_pd_charger_register() from a device you
registered from this same source file.  Seems very incestuous and
hacky.

It's bad enough that we're calling into the platform driver from here
already, but seeing as we are, just extend the call to
cros_ec_query_all() to suit your purposes.

>  MODULE_LICENSE("GPL");
>  MODULE_DESCRIPTION("ChromeOS EC core driver");
> diff --git a/drivers/platform/chrome/cros_ec_dev.c 
> b/drivers/platform/chrome/cros_ec_dev.c
> index d45cd254ed1c..7a97cd313c68 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -87,6 +87,29 @@ exit:
>   return ret;
>  }
>  
> +static int cros_ec_has_cmd_usb_pd_ports(struct cros_ec_dev *ec)
> +{
> + struct cros_ec_command *msg;
> + int ret;
> +
> + msg = kmalloc(sizeof(*msg) + sizeof(struct ec_response_usb_pd_ports),
> +   GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
> +
> + msg->version = 0;
> + msg->command = EC_CMD_USB_PD_PORTS + ec->cmd_offset;
> + msg->insize = sizeof(struct ec_response_usb_pd_ports);
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec->ec_dev, msg);
> + ret = ret >= 0 && msg->result == EC_RES_SUCCESS;
> +
> + kfree(msg);
> +
> + return ret;
> +}
> +
>  /* Device file ops */
>  static int ec_device_open(struct inode *inode, struct file *filp)
>  {
> @@ -269,8 +292,19 @@ static int ec_device_probe(struct platform_device *pdev)
>   goto dev_reg_failed;
>   }
>  
> + /* check whether this EC instance has the PD charge manager */
> + if (cros_ec_has_cmd_usb_pd_ports(ec)) {
> + retval = cros_ec_usb_pd_charger_register(dev);
> + if (retval) {
> + dev_err(dev, "failed to add usb-pd-charger device\n");
> + goto pd_reg_failed;
> + }
> + }
> +
>   return 0;
>  
> +pd_reg_failed:
> + put_device(>class_dev);
>  dev_reg_failed:
>  set_named_failed:
>   dev_set_drvdata(dev, NULL);
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index c21583411ba0..543191f493a9 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -329,4 +329,6 @@ extern struct attribute_group cros_ec_vbc_attr_group;
>   */
>  uint32_t cros_ec_get_host_event(struct cros_ec_device *ec_dev);
>  
> +int cros_ec_usb_pd_charger_register(struct device *dev);
> +
>  #endif /* __LINUX_MFD_CROS_EC_H */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v1 4/6] power: cros_usbpd-charger: Add EC-based USB PD charger driver

[Lee Jones]

On Fri, 05 Feb 2016, Tomeu Vizoso wrote:

> From: Sameer Nanda 
> 
> This driver exposes the charger functionality in the PD EC to userspace.
> 
> Signed-off-by: Tomeu Vizoso 
> Cc: Sameer Nanda 
> Cc: Benson Leung 
> Cc: Shawn Nematbakhsh 
> ---
> 
>  drivers/platform/chrome/cros_ec_proto.c |  37 ++
>  drivers/power/Kconfig   |  10 +
>  drivers/power/Makefile  |   1 +
>  drivers/power/cros_usbpd-charger.c  | 907 
> 
>  include/linux/mfd/cros_ec.h |  28 +
>  include/linux/mfd/cros_ec_commands.h| 324 +++-
>  6 files changed, 1302 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/power/cros_usbpd-charger.c

A 1300 line patch crossing 3 subsystems is not the way you should be
submitting code.  Please split these up into separate commits.  The
only time you should squash all this functionality into a single patch
is to mitigate otherwise unavoidable build issues.  I do not believe
that's the case here.

> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index 6e138e2333f3..083a32461f2d 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -482,3 +482,40 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev)
>   return get_keyboard_state_event(ec_dev);
>  }
>  EXPORT_SYMBOL(cros_ec_get_next_event);
> +
> +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *msg)
> +{
> + int ret = cros_ec_cmd_xfer(ec_dev, msg);
> +
> + if (ret < 0)
> + dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
> + else if (msg->result)
> + return -EECRESULT - msg->result;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
> +
> +u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev)
> +{
> + u32 host_event;
> +
> + if (!ec_dev->mkbp_event_supported) {
> + dev_warn(ec_dev->dev,
> +  "This EC does not support EC_MKBP_EVENT_HOST_EVENT");
> + return -EPROTONOSUPPORT;
> + }
> +
> + if (ec_dev->event_data.event_type != EC_MKBP_EVENT_HOST_EVENT)
> + return 0;
> +
> + if (ec_dev->event_size != sizeof(host_event)) {
> + dev_warn(ec_dev->dev, "Invalid host event size\n");
> + return 0;
> + }
> +
> + host_event = get_unaligned_le32(_dev->event_data.data.host_event);
> + return host_event;
> +}
> +EXPORT_SYMBOL(cros_ec_get_host_event);
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 1ddd13cc0c07..26355850d91b 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -502,6 +502,16 @@ config AXP20X_POWER
> This driver provides support for the power supply features of
> AXP20x PMIC.
>  
> +config CHARGER_CROS_USB_PD
> + tristate "Chrome OS EC based USB PD charger"
> + depends on MFD_CROS_EC
> + default y
> + help
> +   Say Y here to enable Chrome OS EC based USB PD charger driver. This
> +   driver gets various bits of information about what is connected to
> +   USB PD ports from the EC and converts that into power_supply
> +   properties.
> +
>  endif # POWER_SUPPLY
>  
>  source "drivers/power/reset/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 0e4eab55f8d7..b83685bfae61 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -73,3 +73,4 @@ obj-$(CONFIG_CHARGER_TPS65217)  += tps65217_charger.o
>  obj-$(CONFIG_POWER_RESET)+= reset/
>  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>  obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
> +obj-$(CONFIG_CHARGER_CROS_USB_PD)+= cros_usbpd-charger.o
> diff --git a/drivers/power/cros_usbpd-charger.c 
> b/drivers/power/cros_usbpd-charger.c
> new file mode 100644
> index ..72c427554b56
> --- /dev/null
> +++ b/drivers/power/cros_usbpd-charger.c
> @@ -0,0 +1,907 @@
> +/*
> + * Power supply driver for ChromeOS EC based USB PD Charger.
> + *
> + * Copyright (c) 2014 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CROS_USB_PD_MAX_PORTS8
> +#define CROS_USB_PD_MAX_LOG_ENTRIES  30
> +
> 

Re: [PATCH v10 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD driver

[Lee Jones]

On Fri, 05 Feb 2016, Wenyou Yang wrote:

> This patch adds support for the Active-semi ACT8945A PMIC.
> It is a Multi Function Device with the following subdevices:
>  - Regulator
>  - Charger
> 
> It is interfaced to the host controller using I2C interface,
> ACT8945A is a child device of the I2C.
> 
> Signed-off-by: Wenyou Yang 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Lee Jones 
> Acked-by: Peter Korsgaard 
> ---
> 
> Changes in v10:
>  - remove the mfd cell .of_compatible.

v9 unapplied, v10 applied.

> Changes in v9:
>  - remove unneeded struct act8945a_dev structure.
>  - collect Acked from Lee.
>  - collect Acked from Peter.
> 
> Changes in v8:
>  - change the subdevice's name "act8945a-pmic" to "act8945a-regulator".
> 
> Changes in v7:
>  - remove struct act8945a_dev to .c file.
>  - remove unused .h file.
> 
> Changes in v6:
>  - change MFD_ACT8945A type from bool to tristate.
>  - revert depends on to 'I2C'.
> 
> Changes in v5:
>  - change depends on to 'I2C=y'.
> 
> Changes in v4:
>  - add a space before .compatible.
>  - collect Reviewed-by from Krzysztof Kozlowski.
> 
> Changes in v3: None
> Changes in v2:
>  - add more help information in Kconfig.
>  - update the file header with short version license and author line.
>  - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
>  - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
>  - use more explicit info to indicate the failure to add sub devices.
>  - remove the unnecessary print out.
>  - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> 
>  drivers/mfd/Kconfig|   11 ++
>  drivers/mfd/Makefile   |1 +
>  drivers/mfd/act8945a.c |  102 
> 
>  3 files changed, 114 insertions(+)
>  create mode 100644 drivers/mfd/act8945a.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6c4ebd9..38994bb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -18,6 +18,17 @@ config MFD_CS5535
> This is the core driver for CS5535/CS5536 MFD functions.  This is
>necessary for using the board's GPIO and MFGPT functionality.
>  
> +config MFD_ACT8945A
> + tristate "Active-semi ACT8945A"
> + select MFD_CORE
> + select REGMAP_I2C
> + depends on I2C && OF
> + help
> +   Support for the ACT8945A PMIC from Active-semi. This device
> +   features three step-down DC/DC converters and four low-dropout
> +   linear regulators, along with a complete ActivePath battery
> +   charger.
> +
>  config MFD_AS3711
>   bool "AMS AS3711"
>   select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..2f1ca82 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -6,6 +6,7 @@
>  obj-$(CONFIG_MFD_88PM860X)   += 88pm860x.o
>  obj-$(CONFIG_MFD_88PM800)+= 88pm800.o 88pm80x.o
>  obj-$(CONFIG_MFD_88PM805)+= 88pm805.o 88pm80x.o
> +obj-$(CONFIG_MFD_ACT8945A)   += act8945a.o
>  obj-$(CONFIG_MFD_SM501)  += sm501.o
>  obj-$(CONFIG_MFD_ASIC3)  += asic3.o tmio_core.o
>  obj-$(CONFIG_MFD_BCM590XX)   += bcm590xx.o
> diff --git a/drivers/mfd/act8945a.c b/drivers/mfd/act8945a.c
> new file mode 100644
> index 000..525b546
> --- /dev/null
> +++ b/drivers/mfd/act8945a.c
> @@ -0,0 +1,102 @@
> +/*
> + * MFD driver for Active-semi ACT8945a PMIC
> + *
> + * Copyright (C) 2015 Atmel Corporation.
> + *
> + * Author: Wenyou Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under  the terms of the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct mfd_cell act8945a_devs[] = {
> + {
> + .name = "act8945a-regulator",
> + },
> + {
> + .name = "act8945a-charger",
> + },
> +};
> +
> +static const struct regmap_config act8945a_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +static int act8945a_i2c_probe(struct i2c_client *i2c,
> +   const struct i2c_device_id *id)
> +{
> + int ret;
> + struct regmap *regmap;
> +
> + regmap = devm_regmap_init_i2c(i2c, _regmap_config);
> + if (IS_ERR(regmap)) {
> + ret = PTR_ERR(regmap);
> + dev_err(>dev, "regmap init failed: %d\n", ret);
> + return ret;
> + }
> +
> + i2c_set_clientdata(i2c, regmap);
> +
> + ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, act8945a_devs,
> +   ARRAY_SIZE(act8945a_devs), NULL, 0, NULL);
> + if (ret) {
> + dev_err(>dev, "Failed to add sub devices\n");
> + return ret;
> + }
> +
> +

Re: [PATCH V3 2/4] mfd: mt6397: int_con and int_status may vary in location

[Lee Jones]

On Wed, 27 Jan 2016, John Crispin wrote:

> MT6323 has the INT_CON and INT_STATUS located at a different position.
> Make the registers locations configurable.
> 
> Signed-off-by: John Crispin 
> ---
>  drivers/mfd/mt6397-core.c   |   27 +--
>  include/linux/mfd/mt6397/core.h |2 ++
>  2 files changed, 19 insertions(+), 10 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 1749c1c..75ad0fe 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -69,8 +69,10 @@ static void mt6397_irq_sync_unlock(struct irq_data *data)
>  {
>   struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
>  
> - regmap_write(mt6397->regmap, MT6397_INT_CON0, mt6397->irq_masks_cur[0]);
> - regmap_write(mt6397->regmap, MT6397_INT_CON1, mt6397->irq_masks_cur[1]);
> + regmap_write(mt6397->regmap, mt6397->int_con[0],
> +  mt6397->irq_masks_cur[0]);
> + regmap_write(mt6397->regmap, mt6397->int_con[1],
> +  mt6397->irq_masks_cur[1]);
>  
>   mutex_unlock(>irqlock);
>  }
> @@ -147,8 +149,8 @@ static irqreturn_t mt6397_irq_thread(int irq, void *data)
>  {
>   struct mt6397_chip *mt6397 = data;
>  
> - mt6397_irq_handle_reg(mt6397, MT6397_INT_STATUS0, 0);
> - mt6397_irq_handle_reg(mt6397, MT6397_INT_STATUS1, 16);
> + mt6397_irq_handle_reg(mt6397, mt6397->int_status[0], 0);
> + mt6397_irq_handle_reg(mt6397, mt6397->int_status[1], 16);
>  
>   return IRQ_HANDLED;
>  }
> @@ -177,8 +179,8 @@ static int mt6397_irq_init(struct mt6397_chip *mt6397)
>   mutex_init(>irqlock);
>  
>   /* Mask all interrupt sources */
> - regmap_write(mt6397->regmap, MT6397_INT_CON0, 0x0);
> - regmap_write(mt6397->regmap, MT6397_INT_CON1, 0x0);
> + regmap_write(mt6397->regmap, mt6397->int_con[0], 0x0);
> + regmap_write(mt6397->regmap, mt6397->int_con[1], 0x0);
>  
>   mt6397->irq_domain = irq_domain_add_linear(mt6397->dev->of_node,
>   MT6397_IRQ_NR, _irq_domain_ops, mt6397);
> @@ -203,8 +205,8 @@ static int mt6397_irq_suspend(struct device *dev)
>  {
>   struct mt6397_chip *chip = dev_get_drvdata(dev);
>  
> - regmap_write(chip->regmap, MT6397_INT_CON0, chip->wake_mask[0]);
> - regmap_write(chip->regmap, MT6397_INT_CON1, chip->wake_mask[1]);
> + regmap_write(chip->regmap, chip->int_con[0], chip->wake_mask[0]);
> + regmap_write(chip->regmap, chip->int_con[1], chip->wake_mask[1]);
>  
>   enable_irq_wake(chip->irq);
>  
> @@ -215,8 +217,8 @@ static int mt6397_irq_resume(struct device *dev)
>  {
>   struct mt6397_chip *chip = dev_get_drvdata(dev);
>  
> - regmap_write(chip->regmap, MT6397_INT_CON0, chip->irq_masks_cur[0]);
> - regmap_write(chip->regmap, MT6397_INT_CON1, chip->irq_masks_cur[1]);
> + regmap_write(chip->regmap, chip->int_con[0], chip->irq_masks_cur[0]);
> + regmap_write(chip->regmap, chip->int_con[1], chip->irq_masks_cur[1]);
>  
>   disable_irq_wake(chip->irq);
>  
> @@ -237,6 +239,11 @@ static int mt6397_probe(struct platform_device *pdev)
>   return -ENOMEM;
>  
>   mt6397->dev = >dev;
> + mt6397->int_con[0] = MT6397_INT_CON0;
> + mt6397->int_con[1] = MT6397_INT_CON1;
> + mt6397->int_status[0] = MT6397_INT_STATUS0;
> + mt6397->int_status[1] = MT6397_INT_STATUS1;
> +
>   /*
>* mt6397 MFD is child device of soc pmic wrapper.
>* Regmap is set from its parent.
> diff --git a/include/linux/mfd/mt6397/core.h b/include/linux/mfd/mt6397/core.h
> index 45b8e8a..d678f52 100644
> --- a/include/linux/mfd/mt6397/core.h
> +++ b/include/linux/mfd/mt6397/core.h
> @@ -60,6 +60,8 @@ struct mt6397_chip {
>   u16 wake_mask[2];
>   u16 irq_masks_cur[2];
>   u16 irq_masks_cache[2];
> + u16 int_con[2];
> + u16 int_status[2];
>  };
>  
>  #endif /* __MFD_MT6397_CORE_H__ */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V3 5/5] perf/amd/iommu: Enable support for multiple IOMMUs

[Borislav Petkov]

On Tue, Feb 09, 2016 at 04:53:55PM -0600, Suravee Suthikulpanit wrote:
> The current amd_iommu_pc_get_set_reg_val() does not support muli-IOMMU
> system. This patch replace amd_iommu_pc_get_set_reg_val() with
> amd_iommu_pc_set_reg_val() and amd_iommu_pc_[set|get]_cnt_vals().
> 
> Also, the current struct hw_perf_event.prev_count can only store the
> previous counter value only from one IOMMU. So, this patch introduces
> a new data structure, perf_amd_iommu.prev_cnts, to track previous value
> of each performance counter of each bank of each IOMMU.
> 
> Last, this patch introduce perf_iommu_cnts to temporary hold counter
> values from each IOMMU for internal use when manages counters among
> multiple IOMMUs.
> 
> Note that this implementation makes an assumption that the counters
> on all IOMMUs will be programmed the same way (i.e with the same events).
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  arch/x86/kernel/cpu/perf_event_amd_iommu.c | 125 
> +
>  drivers/iommu/amd_iommu_init.c |  87 +---
>  include/linux/perf/perf_event_amd_iommu.h  |   8 +-
>  3 files changed, 174 insertions(+), 46 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event_amd_iommu.c 
> b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
> index 791bbcf..ce6ba3f 100644
> --- a/arch/x86/kernel/cpu/perf_event_amd_iommu.c
> +++ b/arch/x86/kernel/cpu/perf_event_amd_iommu.c
> @@ -42,6 +42,12 @@ struct perf_amd_iommu {
>   u64 cntr_assign_mask;
>   raw_spinlock_t lock;
>   const struct attribute_group *attr_groups[4];
> +
> + /* This is a 3D array used to store the previous count values
> +  * from each performance counter of each bank of each IOMMU.
> +  * I.E. size of array = (num iommus * num banks * num counters)
> +  */
> + local64_t *prev_cnts;
>  };
>  
>  #define format_group attr_groups[0]
> @@ -121,6 +127,11 @@ static struct amd_iommu_event_desc 
> amd_iommu_v2_event_descs[] = {
>   { /* end: all zeroes */ },
>  };
>  
> +/* This is an array used to temporary hold the current values
> + * read from a particular perf counter from each IOMMU.
> + */
> +static u64 *perf_iommu_cnts;
> +
>  /*-
>   * sysfs cpumask attributes
>   *-*/
> @@ -256,44 +267,46 @@ static void perf_iommu_enable_event(struct perf_event 
> *ev)
>   u64 reg = 0ULL;
>  
>   reg = csource;
> - amd_iommu_pc_get_set_reg_val(devid,
> + amd_iommu_pc_set_reg_val(devid,
>   _GET_BANK(ev), _GET_CNTR(ev) ,
> -  IOMMU_PC_COUNTER_SRC_REG, , true);
> +  IOMMU_PC_COUNTER_SRC_REG, );

Read-impairing indentation. It should be aligned at the opening brace:

function_name(param1, param2,
  param3, ...

Ditto for the calls below.

>  
>   reg = 0ULL | devid | (_GET_DEVID_MASK(ev) << 32);

0ULL?

Is this supposed to clear the old value from the previous read above?

What's wrong with

reg = devid | (_GET_DEVID_MASK(ev) << 32);

?

Same for the rest.

>   if (reg)
>   reg |= (1UL << 31);

All those can be turned into

reg |= BIT(31);

> - amd_iommu_pc_get_set_reg_val(devid,
> + amd_iommu_pc_set_reg_val(devid,
>   _GET_BANK(ev), _GET_CNTR(ev) ,
> -  IOMMU_PC_DEVID_MATCH_REG, , true);
> +  IOMMU_PC_DEVID_MATCH_REG, );
>  
>   reg = 0ULL | _GET_PASID(ev) | (_GET_PASID_MASK(ev) << 32);
>   if (reg)
>   reg |= (1UL << 31);
> - amd_iommu_pc_get_set_reg_val(devid,
> + amd_iommu_pc_set_reg_val(devid,
>   _GET_BANK(ev), _GET_CNTR(ev) ,
> -  IOMMU_PC_PASID_MATCH_REG, , true);
> +  IOMMU_PC_PASID_MATCH_REG, );
>  
>   reg = 0ULL | _GET_DOMID(ev) | (_GET_DOMID_MASK(ev) << 32);
>   if (reg)
>   reg |= (1UL << 31);
> - amd_iommu_pc_get_set_reg_val(devid,
> + amd_iommu_pc_set_reg_val(devid,
>   _GET_BANK(ev), _GET_CNTR(ev) ,
> -  IOMMU_PC_DOMID_MATCH_REG, , true);
> +  IOMMU_PC_DOMID_MATCH_REG, );
>  }
>  
>  static void perf_iommu_disable_event(struct perf_event *event)
>  {
>   u64 reg = 0ULL;
>  
> - amd_iommu_pc_get_set_reg_val(_GET_DEVID(event),
> + amd_iommu_pc_set_reg_val(_GET_DEVID(event),
>   _GET_BANK(event), _GET_CNTR(event),
> - IOMMU_PC_COUNTER_SRC_REG, , true);
> + IOMMU_PC_COUNTER_SRC_REG, );
>  }
>  
>  static void perf_iommu_start(struct perf_event *event, int flags)
>  {
>   struct hw_perf_event *hwc = >hw;
> + struct perf_amd_iommu *perf_iommu =
> + container_of(event->pmu, struct perf_amd_iommu, pmu);

There's no need to make it less readable and still fit within the 80
cols rule. 

kernel BUG at net/netfilter/nf_nat_core.c:395

[Oleksandr Natalenko]

Hi.

With 4.4.1 I've got BUG_ON() triggered in net/netfilter/nf_nat_core.c:395, 
nf_nat_setup_info(), today on my home router.

Here is full trace got via netconsole: [1]

I perform LAN NATting using nftables like this:

===
table ip nat {
chain prerouting {
type nat hook prerouting priority -150;
}
 
chain postrouting {
type nat hook postrouting priority -150;
 
oifname enp2s0 ip saddr 172.17.28.0/24 counter snat 1.2.3.4
oifname enp2s0 ip saddr 172.17.29.0/24 counter snat 1.2.3.4
oifname enp2s0 ip saddr 172.17.31.0/24 counter snat 1.2.3.4
oifname enp2s0 ip saddr 172.17.35.0/24 counter snat 1.2.3.4
oifname enp2s0 ip saddr 172.17.37.0/24 counter snat 1.2.3.4
oifname tun0 ip saddr 172.17.28.0/24 counter masquerade
oifname tun0 ip saddr 172.17.29.0/24 counter masquerade
oifname tinc0 ip saddr 172.17.28.0/24 counter masquerade
oifname tinc0 ip saddr 172.17.29.0/24 counter masquerade
}
}
===

Traffic filtering is done via nftables as well.

Ideas? What could I do to debug the issue better?

[1] https://gist.github.com/bbb3712f40a7753537fe

[PATCH v8 2/8] ppc64le FTRACE_WITH_REGS implementation

[Torsten Duwe]

Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2.
Initial work started by Vojtech Pavlik, used with permission.

  * arch/powerpc/kernel/entry_64.S:
- Implement an effective ftrace_caller that works from
  within the kernel binary as well as from modules.
  * arch/powerpc/kernel/ftrace.c:
- be prepared to deal with ppc64 ELF ABI v2, especially
  calls to _mcount that result from gcc -mprofile-kernel
- a little more error verbosity
  * arch/powerpc/kernel/module_64.c:
- do not save the TOC pointer on the trampoline when the
  destination is ftrace_caller. This trampoline jump happens from
  a function prologue before a new stack frame is set up, so bad
  things may happen otherwise...
- relax is_module_trampoline() to recognise the modified
  trampoline.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/include/asm/ftrace.h |  5 +++
 arch/powerpc/kernel/entry_64.S| 78 +++
 arch/powerpc/kernel/ftrace.c  | 64 +---
 arch/powerpc/kernel/module_64.c   | 25 -
 4 files changed, 165 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/ftrace.h 
b/arch/powerpc/include/asm/ftrace.h
index ef89b14..50ca758 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -46,6 +46,8 @@
 extern void _mcount(void);
 
 #ifdef CONFIG_DYNAMIC_FTRACE
+# define FTRACE_ADDR ((unsigned long)ftrace_caller)
+# define FTRACE_REGS_ADDR FTRACE_ADDR
 static inline unsigned long ftrace_call_adjust(unsigned long addr)
 {
/* reloction of mcount call site is the same as the address */
@@ -58,6 +60,9 @@ struct dyn_arch_ftrace {
 #endif /*  CONFIG_DYNAMIC_FTRACE */
 #endif /* __ASSEMBLY__ */
 
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#endif
 #endif
 
 #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64) && 
!defined(__ASSEMBLY__)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2a7313c..c063564 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1148,6 +1148,7 @@ _GLOBAL(_mcount)
mtlrr0
bctr
 
+#ifndef CC_USING_MPROFILE_KERNEL
 _GLOBAL_TOC(ftrace_caller)
/* Taken from output of objdump from lib64/glibc */
mflrr3
@@ -1169,6 +1170,83 @@ _GLOBAL(ftrace_graph_stub)
ld  r0, 128(r1)
mtlrr0
addir1, r1, 112
+#else
+_GLOBAL(ftrace_caller)
+   std r0,LRSAVE(r1)
+#if defined(_CALL_ELF) && _CALL_ELF == 2
+   mflrr0
+   bl  2f
+2: mflrr12
+   mtlrr0
+   mr  r0,r2   /* save callee's TOC */
+   addis   r2,r12,(.TOC.-ftrace_caller-12)@ha
+   addir2,r2,(.TOC.-ftrace_caller-12)@l
+#else
+   mr  r0,r2
+#endif
+   ld  r12,LRSAVE(r1)  /* get caller's address */
+
+   stdur1,-SWITCH_FRAME_SIZE(r1)
+
+   std r12, _LINK(r1)
+   SAVE_8GPRS(0,r1)
+   std r0, 24(r1)  /* save TOC */
+   SAVE_8GPRS(8,r1)
+   SAVE_8GPRS(16,r1)
+   SAVE_8GPRS(24,r1)
+
+   addis   r3,r2,function_trace_op@toc@ha
+   addir3,r3,function_trace_op@toc@l
+   ld  r5,0(r3)
+
+   mflrr3
+   std r3, _NIP(r1)
+   std r3, 16(r1)
+   subir3, r3, MCOUNT_INSN_SIZE
+   mfmsr   r4
+   std r4, _MSR(r1)
+   mfctr   r4
+   std r4, _CTR(r1)
+   mfxer   r4
+   std r4, _XER(r1)
+   mr  r4, r12
+   addir6, r1 ,STACK_FRAME_OVERHEAD
+
+.globl ftrace_call
+ftrace_call:
+   bl  ftrace_stub
+   nop
+
+   ld  r3, _NIP(r1)
+   mtlrr3
+
+   REST_8GPRS(0,r1)
+   REST_8GPRS(8,r1)
+   REST_8GPRS(16,r1)
+   REST_8GPRS(24,r1)
+
+   addi r1, r1, SWITCH_FRAME_SIZE
+
+   ld  r12, LRSAVE(r1)  /* get caller's address */
+   mtlrr12
+   mr  r2,r0   /* restore callee's TOC */
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+   stdur1, -112(r1)
+.globl ftrace_graph_call
+ftrace_graph_call:
+   b   ftrace_graph_stub
+_GLOBAL(ftrace_graph_stub)
+   addir1, r1, 112
+#endif
+
+   mflrr0  /* move this LR to CTR */
+   mtctr   r0
+
+   ld  r0,LRSAVE(r1)   /* restore callee's lr at _mcount site */
+   mtlrr0
+   bctr/* jump after _mcount site */
+#endif /* CC_USING_MPROFILE_KERNEL */
 _GLOBAL(ftrace_stub)
blr
 #else
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 861af90..1fad1b3 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -61,8 +61,11 @@ ftrace_modify_code(unsigned long ip, unsigned int old, 
unsigned int new)
return -EFAULT;
 
/* Make sure it is what we expect it to be */
-   if (replaced != old)
+   if (replaced != old) {
+   pr_err("%p: replaced (%#x) != old (%#x)",

[PATCH v8 1/8] ppc64 (le): prepare for -mprofile-kernel

[Torsten Duwe]

The gcc switch -mprofile-kernel, available for ppc64 on gcc > 4.8.5,
allows to call _mcount very early in the function, which low-level
ASM code and code patching functions need to consider.
Especially the link register and the parameter registers are still
alive and not yet saved into a new stack frame.

  * arch/powerpc/kernel/entry_64.S:
- modify the default _mcount to be prepared for such call sites
- have the ftrace_graph_caller save function arguments before
  calling its C helper prepare_ftrace_return
  * arch/powerpc/include/asm/code-patching.h:
- define some common macros to make things readable.
- pull the R2 stack location definition from
  arch/powerpc/kernel/module_64.c
  * arch/powerpc/kernel/module_64.c:
- enhance binary code examination to handle the new patterns.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/include/asm/code-patching.h | 24 
 arch/powerpc/kernel/entry_64.S   | 48 +++-
 arch/powerpc/kernel/ftrace.c | 44 ++---
 arch/powerpc/kernel/module_64.c  | 31 +++--
 4 files changed, 133 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index 840a550..7820b32 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -99,4 +99,28 @@ static inline unsigned long ppc_global_function_entry(void 
*func)
 #endif
 }
 
+#ifdef CONFIG_PPC64
+/* Some instruction encodings commonly used in dynamic ftracing
+ * and function live patching:
+ */
+
+/* This must match the definition of STK_GOT in  */
+#if defined(_CALL_ELF) && _CALL_ELF == 2
+#define R2_STACK_OFFSET 24
+#else
+#define R2_STACK_OFFSET 40
+#endif
+
+/* load / store the TOC from / into the stack frame */
+#define PPC_INST_LD_TOC(PPC_INST_LD  | ___PPC_RT(__REG_R2) | \
+___PPC_RA(__REG_R1) | R2_STACK_OFFSET)
+#define PPC_INST_STD_TOC   (PPC_INST_STD | ___PPC_RS(__REG_R2) | \
+___PPC_RA(__REG_R1) | R2_STACK_OFFSET)
+
+/* usually preceded by a mflr r0 */
+#define PPC_INST_STD_LR(PPC_INST_STD | ___PPC_RS(__REG_R0) | \
+___PPC_RA(__REG_R1) | PPC_LR_STKOFF)
+
+#endif /* CONFIG_PPC64 */
+
 #endif /* _ASM_POWERPC_CODE_PATCHING_H */
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 0d525ce..2a7313c 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1143,7 +1143,10 @@ _GLOBAL(enter_prom)
 #ifdef CONFIG_DYNAMIC_FTRACE
 _GLOBAL(mcount)
 _GLOBAL(_mcount)
-   blr
+   mflrr12
+   mtctr   r12
+   mtlrr0
+   bctr
 
 _GLOBAL_TOC(ftrace_caller)
/* Taken from output of objdump from lib64/glibc */
@@ -1198,6 +1201,7 @@ _GLOBAL(ftrace_stub)
 #endif /* CONFIG_DYNAMIC_FTRACE */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
+#ifndef CC_USING_MPROFILE_KERNEL
 _GLOBAL(ftrace_graph_caller)
/* load r4 with local address */
ld  r4, 128(r1)
@@ -1222,6 +1226,48 @@ _GLOBAL(ftrace_graph_caller)
addir1, r1, 112
blr
 
+#else /* CC_USING_MPROFILE_KERNEL */
+_GLOBAL(ftrace_graph_caller)
+   /* with -mprofile-kernel, parameter regs are still alive at _mcount */
+   std r10, 104(r1)
+   std r9, 96(r1)
+   std r8, 88(r1)
+   std r7, 80(r1)
+   std r6, 72(r1)
+   std r5, 64(r1)
+   std r4, 56(r1)
+   std r3, 48(r1)
+   mfctr   r4  /* ftrace_caller has moved local addr here */
+   std r4, 40(r1)
+   mflrr3  /* ftrace_caller has restored LR from stack */
+   subir4, r4, MCOUNT_INSN_SIZE
+
+   bl  prepare_ftrace_return
+   nop
+
+   /*
+* prepare_ftrace_return gives us the address we divert to.
+* Change the LR to this.
+*/
+   mtlrr3
+
+   ld  r0, 40(r1)
+   mtctr   r0
+   ld  r10, 104(r1)
+   ld  r9, 96(r1)
+   ld  r8, 88(r1)
+   ld  r7, 80(r1)
+   ld  r6, 72(r1)
+   ld  r5, 64(r1)
+   ld  r4, 56(r1)
+   ld  r3, 48(r1)
+
+   addir1, r1, 112
+   mflrr0
+   std r0, LRSAVE(r1)
+   bctr
+#endif /* CC_USING_MPROFILE_KERNEL */
+
 _GLOBAL(return_to_handler)
/* need to save return values */
std r4,  -32(r1)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 44d4d8e..861af90 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -287,16 +287,14 @@ int ftrace_make_nop(struct module *mod,
 
 #ifdef CONFIG_MODULES
 #ifdef CONFIG_PPC64
+/* Examine the existing instructions for __ftrace_make_call.
+ * They should effectively be a NOP, and follow formal constraints,
+ * depending on the ABI. Return 

Re: [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks

[Juri Lelli]

On 10/02/16 16:46, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 3:46 PM, Juri Lelli  wrote:
> > On 10/02/16 15:26, Rafael J. Wysocki wrote:
> >> On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli  wrote:
> >> > On 10/02/16 14:23, Rafael J. Wysocki wrote:
> >> >> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli  wrote:
> >> >> > Hi Rafael,
> >> >> >
> >> >> > On 09/02/16 21:05, Rafael J. Wysocki wrote:
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> >> +/**
> >> >> >> + * cpufreq_update_util - Take a note about CPU utilization changes.
> >> >> >> + * @util: Current utilization.
> >> >> >> + * @max: Utilization ceiling.
> >> >> >> + *
> >> >> >> + * This function is called by the scheduler on every invocation of
> >> >> >> + * update_load_avg() on the CPU whose utilization is being updated.
> >> >> >> + */
> >> >> >> +void cpufreq_update_util(unsigned long util, unsigned long max)
> >> >> >> +{
> >> >> >> + struct update_util_data *data;
> >> >> >> +
> >> >> >> + rcu_read_lock();
> >> >> >> +
> >> >> >> + data = 
> >> >> >> rcu_dereference(*this_cpu_ptr(_update_util_data));
> >> >> >> + if (data && data->func)
> >> >> >> + data->func(data, cpu_clock(smp_processor_id()), util, 
> >> >> >> max);
> >> >> >
> >> >> > Are util and max used anywhere?
> >> >>
> >> >> They aren't yet, but they will be.
> >> >>
> >> >> Maybe not in this cycle (it it takes too much time to integrate the
> >> >> preliminary changes), but we definitely are going to use those
> >> >> numbers.
> >> >>
> >> >
> >> > Oh OK. However, I was under the impression that this set was only
> >> > proposing a way to get rid of timers and use the scheduler as heartbeat
> >> > for cpufreq governors. The governors' sample based approach wouldn't
> >> > change, though. Am I wrong in assuming this?
> >>
> >> Your assumption is correct.
> >>
> >
> > In this case. Wouldn't be possible to simply put the kicks in
> > sched/core.c? scheduler_tick() seems a good candidate for that, and you
> > could complement that with enqueue/dequeue/etc., if needed.
> 
> That can be done, but they are not needed for things like idle and
> stop, are they?
> 

Sorry, I'm not sure I understand you here. In a NO_HZ system tick will
be stopped when idle.

> > I'm actually wondering if a slow CONFIG_HZ might affect governors'
> > sampling rate. We might have scheduler tick firing every 40ms and
> > sampling rate set to 10 or 20ms, don't we?
> 
> The smallest HZ you can get from the standard config is 100.  That
> would translate to an update every 10ms roughly if my understanding of
> things is correct.
> 

Right. Please, forget my question above :).

> Also I think that the scheduler and cpufreq should really work at the
> same pace as they affect each other in any case.
> 

Makes sense yes.

> >> The sample-based approach doesn't change at this time, simply to avoid
> >> making too many changes in one go.
> >>
> >> The next step, as I'm seeing it, would be to use the
> >> scheduler-provided utilization in the governor computations instead of
> >> the load estimation made by governors themselves.
> >>
> >
> > OK. But, I'm not sure what does this buy us. If the end goal is still to
> > do sampling, aren't we better off using the (1 - idle) estimation as
> > today?
> 
> First of all, we can avoid the need to compute this number entirely if
> we use the scheduler-provided one.
> 
> Second, what if we come up with a different idea about the CPU
> utilization than the scheduler has?  Who's right then?
> 
> Finally, the way this number is currently computed by cpufreq is based
> on some questionable heuristics (and not just in one place), so maybe
> it's better to stop doing that?
> 
> Also I didn't say that the *final* goal would be to do sampling.  I
> was talking about the next step. :-)
> 

Oh, this changes things indeed. :)

Thanks,

- Juri

Re: [PATCH v8 0/3] tty: Introduce software RS485 direction control support

[Peter Hurley]

Hi Matwey,

On 02/01/2016 10:09 AM, Matwey V. Kornilov wrote:
> Changes from v7:
>  - rework comments to follow guidelines
>  - minor style changes
> Changes from v6:
>  - minor style changes
>  - timers are not IRQSAFE now
> Changes from v5:
>  - rs485_emul variable has been renamed to em485 to follow function names 
> convention
> Changes from v4:
>  - Add commit message to 1/3
> Changes from v3:
>  - Completely redesigned.
> Changes from v2:
>  - Introduced SER_RS485_SOFTWARE to show that software implementation is 
> being used
>  - serial8250_rs485_config is located as required
>  - Timers are used to implement delay_before and delay_after timeouts
> 
> Signed-off-by: Matwey V. Kornilov 

The holdup here is that I'd like to unit test this, which is 3rd on my todo 
list.
Should be done before the end of the week which will be soon enough
for this series to make linux-next.

Thanks for your work on this.

Regards,
Peter Hurley

Re: [PATCH RESEND 2/7] mfd: wm5102: Fix defaults array based on testing

[Lee Jones]

On Tue, 09 Feb 2016, Charles Keepax wrote:

> My automated test is back and now can check defaults against the actual
> hardware. This patch updates the defaults array for the differences
> detected and removes a couple of completely unused registers.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/wm5102-tables.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
> index 0386eaf..ab8b23b 100644
> --- a/drivers/mfd/wm5102-tables.c
> +++ b/drivers/mfd/wm5102-tables.c
> @@ -297,7 +297,6 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x0174, 0x007D },   /* R372   - FLL1 Control 4 */ 
>   { 0x0175, 0x0004 },   /* R373   - FLL1 Control 5 */ 
>   { 0x0176, 0x },   /* R374   - FLL1 Control 6 */ 
> - { 0x0177, 0x0181 },   /* R375   - FLL1 Loop Filter Test 1 */ 
>   { 0x0179, 0x },   /* R377   - FLL1 Control 7 */
>   { 0x0181, 0x },   /* R385   - FLL1 Synchroniser 1 */ 
>   { 0x0182, 0x },   /* R386   - FLL1 Synchroniser 2 */ 
> @@ -314,7 +313,6 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x0194, 0x007D },   /* R404   - FLL2 Control 4 */ 
>   { 0x0195, 0x0004 },   /* R405   - FLL2 Control 5 */ 
>   { 0x0196, 0x },   /* R406   - FLL2 Control 6 */ 
> - { 0x0197, 0x },   /* R407   - FLL2 Loop Filter Test 1 */ 
>   { 0x0199, 0x },   /* R409   - FLL2 Control 7 */
>   { 0x01A1, 0x },   /* R417   - FLL2 Synchroniser 1 */ 
>   { 0x01A2, 0x },   /* R418   - FLL2 Synchroniser 2 */ 
> @@ -338,7 +336,7 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x02A3, 0x1102 },   /* R675   - Mic Detect 1 */ 
>   { 0x02A4, 0x009F },   /* R676   - Mic Detect 2 */ 
>   { 0x02A6, 0x3737 },   /* R678   - Mic Detect Level 1 */
> - { 0x02A7, 0x372C },   /* R679   - Mic Detect Level 2 */
> + { 0x02A7, 0x2C37 },   /* R679   - Mic Detect Level 2 */
>   { 0x02A8, 0x1422 },   /* R680   - Mic Detect Level 3 */
>   { 0x02A9, 0x030A },   /* R681   - Mic Detect Level 4 */
>   { 0x02C3, 0x },   /* R707   - Mic noise mix control 1 */ 
> @@ -402,7 +400,7 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x0435, 0x0180 },   /* R1077  - DAC Digital Volume 5R */ 
>   { 0x0436, 0x0081 },   /* R1078  - DAC Volume Limit 5R */
>   { 0x0437, 0x0200 },   /* R1079  - Noise Gate Select 5R */
> - { 0x0440, 0x8FFF },   /* R1088  - DRE Enable */
> + { 0x0440, 0x0FFF },   /* R1088  - DRE Enable */
>   { 0x0442, 0x3F0A },   /* R1090  - DRE Control 2 */
>   { 0x0443, 0xDC1F },   /* R1090  - DRE Control 3 */
>   { 0x0450, 0x },   /* R1104  - DAC AEC Control 1 */ 
> @@ -863,7 +861,7 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x0C0F, 0x0400 },   /* R3087  - IRQ CTRL 1 */ 
>   { 0x0C10, 0x1000 },   /* R3088  - GPIO Debounce Config */ 
>   { 0x0C20, 0x8002 },   /* R3104  - Misc Pad Ctrl 1 */ 
> - { 0x0C21, 0x8001 },   /* R3105  - Misc Pad Ctrl 2 */ 
> + { 0x0C21, 0x0001 },   /* R3105  - Misc Pad Ctrl 2 */
>   { 0x0C22, 0x },   /* R3106  - Misc Pad Ctrl 3 */ 
>   { 0x0C23, 0x },   /* R3107  - Misc Pad Ctrl 4 */ 
>   { 0x0C24, 0x },   /* R3108  - Misc Pad Ctrl 5 */ 
> @@ -984,7 +982,7 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x0ECD, 0x },   /* R3789  - HPLPF4_2 */ 
>   { 0x0EE0, 0x },   /* R3808  - ASRC_ENABLE */ 
>   { 0x0EE2, 0x },   /* R3810  - ASRC_RATE1 */ 
> - { 0x0EE3, 0x0400 },   /* R3811  - ASRC_RATE2 */
> + { 0x0EE3, 0x4000 },   /* R3811  - ASRC_RATE2 */
>   { 0x0EF0, 0x },   /* R3824  - ISRC 1 CTRL 1 */ 
>   { 0x0EF1, 0x },   /* R3825  - ISRC 1 CTRL 2 */ 
>   { 0x0EF2, 0x },   /* R3826  - ISRC 1 CTRL 3 */ 
> @@ -1062,8 +1060,6 @@ static bool wm5102_readable_register(struct device 
> *dev, unsigned int reg)
>   case ARIZONA_FLL1_CONTROL_4:
>   case ARIZONA_FLL1_CONTROL_5:
>   case ARIZONA_FLL1_CONTROL_6:
> - case ARIZONA_FLL1_LOOP_FILTER_TEST_1:
> - case ARIZONA_FLL1_NCO_TEST_0:
>   case ARIZONA_FLL1_CONTROL_7:
>   case ARIZONA_FLL1_SYNCHRONISER_1:
>   case ARIZONA_FLL1_SYNCHRONISER_2:
> @@ -1080,8 +1076,6 @@ static bool wm5102_readable_register(struct device 
> *dev, unsigned int reg)
>   case ARIZONA_FLL2_CONTROL_4:
>   case ARIZONA_FLL2_CONTROL_5:
>   case ARIZONA_FLL2_CONTROL_6:
> - case ARIZONA_FLL2_LOOP_FILTER_TEST_1:
> - case ARIZONA_FLL2_NCO_TEST_0:
>   case ARIZONA_FLL2_CONTROL_7:
>   case ARIZONA_FLL2_SYNCHRONISER_1:
>   case ARIZONA_FLL2_SYNCHRONISER_2:
> @@ -1849,8 +1843,6 @@ 

Re: [PATCH RESEND 3/7] mfd: wm8998: Fix defaults array based on testing

[Lee Jones]

On Tue, 09 Feb 2016, Charles Keepax wrote:

> My automated test is back and now can check defaults against the actual
> hardware. This patch updates the defaults array for the differences
> detected and removes a couple of completely unused registers.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/wm8998-tables.c | 12 ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/wm8998-tables.c b/drivers/mfd/wm8998-tables.c
> index 4c2dce77..a0de300 100644
> --- a/drivers/mfd/wm8998-tables.c
> +++ b/drivers/mfd/wm8998-tables.c
> @@ -229,8 +229,6 @@ static const struct reg_default wm8998_reg_default[] = {
>   { 0x0174, 0x007D },/* R372   - FLL1 Control 4 */
>   { 0x0175, 0x0004 },/* R373   - FLL1 Control 5 */
>   { 0x0176, 0x },/* R374   - FLL1 Control 6 */
> - { 0x0177, 0x0181 },/* R375   - FLL1 Loop Filter Test 1 */
> - { 0x0178, 0x },/* R376   - FLL1 NCO Test 0 */
>   { 0x0179, 0x },/* R377   - FLL1 Control 7 */
>   { 0x0181, 0x },/* R385   - FLL1 Synchroniser 1 */
>   { 0x0182, 0x },/* R386   - FLL1 Synchroniser 2 */
> @@ -247,8 +245,6 @@ static const struct reg_default wm8998_reg_default[] = {
>   { 0x0194, 0x007D },/* R404   - FLL2 Control 4 */
>   { 0x0195, 0x0004 },/* R405   - FLL2 Control 5 */
>   { 0x0196, 0x },/* R406   - FLL2 Control 6 */
> - { 0x0197, 0x },/* R407   - FLL2 Loop Filter Test 1 */
> - { 0x0198, 0x },/* R408   - FLL2 NCO Test 0 */
>   { 0x0199, 0x },/* R409   - FLL2 Control 7 */
>   { 0x01A1, 0x },/* R417   - FLL2 Synchroniser 1 */
>   { 0x01A2, 0x },/* R418   - FLL2 Synchroniser 2 */
> @@ -320,7 +316,7 @@ static const struct reg_default wm8998_reg_default[] = {
>   { 0x0434, 0x },/* R1076  - Output Path Config 5R */
>   { 0x0435, 0x0180 },/* R1077  - DAC Digital Volume 5R */
>   { 0x0437, 0x0200 },/* R1079  - Noise Gate Select 5R */
> - { 0x0440, 0x8FFF },/* R1088  - DRE Enable */
> + { 0x0440, 0x002F },/* R1088  - DRE Enable */
>   { 0x0441, 0xC759 },/* R1089  - DRE Control 1 */
>   { 0x0442, 0x2A08 },/* R1089  - DRE Control 2 */
>   { 0x0443, 0x5CFA },/* R1089  - DRE Control 3 */
> @@ -686,7 +682,7 @@ static const struct reg_default wm8998_reg_default[] = {
>   { 0x0C10, 0x1000 },/* R3088  - GPIO Debounce Config */
>   { 0x0C18, 0x },/* R3096  - GP Switch 1 */
>   { 0x0C20, 0x8002 },/* R3104  - Misc Pad Ctrl 1 */
> - { 0x0C21, 0x8001 },/* R3105  - Misc Pad Ctrl 2 */
> + { 0x0C21, 0x0001 },/* R3105  - Misc Pad Ctrl 2 */
>   { 0x0C22, 0x },/* R3106  - Misc Pad Ctrl 3 */
>   { 0x0C23, 0x },/* R3107  - Misc Pad Ctrl 4 */
>   { 0x0C24, 0x },/* R3108  - Misc Pad Ctrl 5 */
> @@ -888,8 +884,6 @@ static bool wm8998_readable_register(struct device *dev, 
> unsigned int reg)
>   case ARIZONA_FLL1_CONTROL_5:
>   case ARIZONA_FLL1_CONTROL_6:
>   case ARIZONA_FLL1_CONTROL_7:
> - case ARIZONA_FLL1_LOOP_FILTER_TEST_1:
> - case ARIZONA_FLL1_NCO_TEST_0:
>   case ARIZONA_FLL1_SYNCHRONISER_1:
>   case ARIZONA_FLL1_SYNCHRONISER_2:
>   case ARIZONA_FLL1_SYNCHRONISER_3:
> @@ -906,8 +900,6 @@ static bool wm8998_readable_register(struct device *dev, 
> unsigned int reg)
>   case ARIZONA_FLL2_CONTROL_5:
>   case ARIZONA_FLL2_CONTROL_6:
>   case ARIZONA_FLL2_CONTROL_7:
> - case ARIZONA_FLL2_LOOP_FILTER_TEST_1:
> - case ARIZONA_FLL2_NCO_TEST_0:
>   case ARIZONA_FLL2_SYNCHRONISER_1:
>   case ARIZONA_FLL2_SYNCHRONISER_2:
>   case ARIZONA_FLL2_SYNCHRONISER_3:

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH RESEND 1/7] mfd: wm5110: Fix defaults array based on testing

[Lee Jones]

On Tue, 09 Feb 2016, Charles Keepax wrote:

> My automated test is back and now can check defaults against the actual
> hardware. This patch updates the defaults array for the differences
> detected and removes a couple of completely unused registers.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/wm5110-tables.c | 82 
> -
>  1 file changed, 37 insertions(+), 45 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
> index c18e11f..8e74e71 100644
> --- a/drivers/mfd/wm5110-tables.c
> +++ b/drivers/mfd/wm5110-tables.c
> @@ -676,8 +676,8 @@ static const struct reg_default wm5110_reg_default[] = {
>   { 0x0008, 0x0019 },/* R8 - Ctrl IF SPI CFG 1 */
>   { 0x0009, 0x0001 },/* R9 - Ctrl IF I2C1 CFG 1 */
>   { 0x000A, 0x0001 },/* R10- Ctrl IF I2C2 CFG 1 */
> - { 0x000B, 0x0036 },/* R11- Ctrl IF I2C1 CFG 2 */
> - { 0x000C, 0x0036 },/* R12- Ctrl IF I2C2 CFG 2 */
> + { 0x000B, 0x001A },/* R11- Ctrl IF I2C1 CFG 2 */
> + { 0x000C, 0x001A },/* R12- Ctrl IF I2C2 CFG 2 */
>   { 0x0020, 0x },/* R32- Tone Generator 1 */
>   { 0x0021, 0x1000 },/* R33- Tone Generator 2 */
>   { 0x0022, 0x },/* R34- Tone Generator 3 */
> @@ -723,14 +723,12 @@ static const struct reg_default wm5110_reg_default[] = {
>   { 0x0154, 0x },/* R340   - Rate Estimator 3 */
>   { 0x0155, 0x },/* R341   - Rate Estimator 4 */
>   { 0x0156, 0x },/* R342   - Rate Estimator 5 */
> - { 0x0171, 0x },/* R369   - FLL1 Control 1 */
> + { 0x0171, 0x0002 },/* R369   - FLL1 Control 1 */
>   { 0x0172, 0x0008 },/* R370   - FLL1 Control 2 */
>   { 0x0173, 0x0018 },/* R371   - FLL1 Control 3 */
>   { 0x0174, 0x007D },/* R372   - FLL1 Control 4 */
>   { 0x0175, 0x0006 },/* R373   - FLL1 Control 5 */
>   { 0x0176, 0x },/* R374   - FLL1 Control 6 */
> - { 0x0177, 0x0281 },/* R375   - FLL1 Loop Filter Test 1 */
> - { 0x0178, 0x },/* R376   - FLL1 NCO Test 0 */
>   { 0x0179, 0x },/* R376   - FLL1 Control 7 */
>   { 0x0181, 0x },/* R385   - FLL1 Synchroniser 1 */
>   { 0x0182, 0x },/* R386   - FLL1 Synchroniser 2 */
> @@ -740,15 +738,13 @@ static const struct reg_default wm5110_reg_default[] = {
>   { 0x0186, 0x },/* R390   - FLL1 Synchroniser 6 */
>   { 0x0187, 0x0001 },/* R390   - FLL1 Synchroniser 7 */
>   { 0x0189, 0x },/* R393   - FLL1 Spread Spectrum */
> - { 0x018A, 0x0004 },/* R394   - FLL1 GPIO Clock */
> - { 0x0191, 0x },/* R401   - FLL2 Control 1 */
> + { 0x018A, 0x000C },/* R394   - FLL1 GPIO Clock */
> + { 0x0191, 0x0002 },/* R401   - FLL2 Control 1 */
>   { 0x0192, 0x0008 },/* R402   - FLL2 Control 2 */
>   { 0x0193, 0x0018 },/* R403   - FLL2 Control 3 */
>   { 0x0194, 0x007D },/* R404   - FLL2 Control 4 */
>   { 0x0195, 0x000C },/* R405   - FLL2 Control 5 */
>   { 0x0196, 0x },/* R406   - FLL2 Control 6 */
> - { 0x0197, 0x },/* R407   - FLL2 Loop Filter Test 1 */
> - { 0x0198, 0x },/* R408   - FLL2 NCO Test 0 */
>   { 0x0199, 0x },/* R408   - FLL2 Control 7 */
>   { 0x01A1, 0x },/* R417   - FLL2 Synchroniser 1 */
>   { 0x01A2, 0x },/* R418   - FLL2 Synchroniser 2 */
> @@ -758,7 +754,7 @@ static const struct reg_default wm5110_reg_default[] = {
>   { 0x01A6, 0x },/* R422   - FLL2 Synchroniser 6 */
>   { 0x01A7, 0x0001 },/* R422   - FLL2 Synchroniser 7 */
>   { 0x01A9, 0x },/* R425   - FLL2 Spread Spectrum */
> - { 0x01AA, 0x0004 },/* R426   - FLL2 GPIO Clock */
> + { 0x01AA, 0x000C },/* R426   - FLL2 GPIO Clock */
>   { 0x0200, 0x0006 },/* R512   - Mic Charge Pump 1 */
>   { 0x0210, 0x0184 },/* R528   - LDO1 Control 1 */
>   { 0x0213, 0x03E4 },/* R531   - LDO2 Control 1 */
> @@ -771,9 +767,9 @@ static const struct reg_default wm5110_reg_default[] = {
>   { 0x02A3, 0x1102 },/* R675   - Mic Detect 1 */
>   { 0x02A4, 0x009F },/* R676   - Mic Detect 2 */
>   { 0x02A6, 0x3737 },/* R678   - Mic Detect Level 1 */
> - { 0x02A7, 0x372C },/* R679   - Mic Detect Level 2 */
> + { 0x02A7, 0x2C37 },/* R679   - Mic Detect Level 2 */
>   { 0x02A8, 0x1422 },/* R680   - Mic Detect Level 3 */
> - { 0x02A9, 0x300A },/* R681   - Mic Detect Level 4 */
> + { 0x02A9, 0x030A },/* R681   - Mic Detect Level 4 */
>   { 0x02C3, 

Re: [PATCH v1 1/6] mfd: cros_ec: small kerneldoc fix

[Lee Jones]

On Fri, 05 Feb 2016, Tomeu Vizoso wrote:

> s/cros_ec_register/cros_ec_query_all
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
>  include/linux/mfd/cros_ec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 494682ce4bf3..a677c2bd485c 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -245,7 +245,7 @@ int cros_ec_remove(struct cros_ec_device *ec_dev);
>  int cros_ec_register(struct cros_ec_device *ec_dev);
>  
>  /**
> - * cros_ec_register -  Query the protocol version supported by the ChromeOS 
> EC
> + * cros_ec_query_all -  Query the protocol version supported by the ChromeOS 
> EC
>   *
>   * @ec_dev: Device to register
>   * @return 0 if ok, -ve on error

I'll fix the subject line for you this time.

In future please submit using the format set by the subsystem.

`git log --oneline -- ` helps with this.

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v8 0/3] tty: Introduce software RS485 direction control support

[Matwey V. Kornilov]

2016-02-10 19:05 GMT+03:00 Peter Hurley :
> Hi Matwey,
>
> On 02/01/2016 10:09 AM, Matwey V. Kornilov wrote:
>> Changes from v7:
>>  - rework comments to follow guidelines
>>  - minor style changes
>> Changes from v6:
>>  - minor style changes
>>  - timers are not IRQSAFE now
>> Changes from v5:
>>  - rs485_emul variable has been renamed to em485 to follow function names 
>> convention
>> Changes from v4:
>>  - Add commit message to 1/3
>> Changes from v3:
>>  - Completely redesigned.
>> Changes from v2:
>>  - Introduced SER_RS485_SOFTWARE to show that software implementation is 
>> being used
>>  - serial8250_rs485_config is located as required
>>  - Timers are used to implement delay_before and delay_after timeouts
>>
>> Signed-off-by: Matwey V. Kornilov 
>
> The holdup here is that I'd like to unit test this, which is 3rd on my todo 
> list.
> Should be done before the end of the week which will be soon enough
> for this series to make linux-next.

Hi Peter,

Is something required from me?

>
> Thanks for your work on this.
>
> Regards,
> Peter Hurley
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: [PATCH 2/2] KVM: x86: allow BSP to handle INIT IPIs like APs do

[Bruce Rogers]

>>> On 2/8/2016 at 10:53 AM, Jan Kiszka  wrote: 
> On 2016-02-08 18:38, Bruce Rogers wrote:
> On 2/8/2016 at 10:27 AM, Bruce Rogers wrote: 
>> On 2/8/2016 at 09:40 AM, Paolo Bonzini  wrote: 
>>>

 On 08/02/2016 17:33, Bruce Rogers wrote:
>
> KVM_MP_STATE_INIT_RECEIVED is what Intel calls the "wait for SIPI"
> state.  The BSP never gets a SIPI, it goes straight to 0xFFF0
> instead.  Can you explain the problem more in detail?
>>>
>>> I suspect this is about sending INIT-SIPI from another CPU, directed to
>>> the BSP, isn't it? We may have to differentiate between CPU (including
>>> system) reset and that IPI case.
> That is correct. In looking over the KVM code which deals with BSP, this 
> was
> the only place which seemed wrong to me wrt special casing for BSP 
> outside 
 the
> context of initial system initialization / reset. As far as I understand 
> the
> BSP shouldn't be treated differently in this case.

 See 8.4.2 of the SDM:

 If the MP protocol has completed and a BSP is chosen, subsequent INITs
 (either to a specific processor or system wide) do not cause the MP
 protocol to be repeated. Instead, each logical processor examines its
 BSP flag (in the IA32_APIC_BASE MSR) to determine whether it should
 execute the BIOS boot-strap code (if it is the BSP) or enter a
 wait-for-SIPI state (if it is an AP).

 So it is correct to treat the BSP differently here, I think.
>>>
>>> I had read that, but I though this was speaking from the perspective of the
>>> SMP aware BIOS code only. In other words, the BIOS would sidetrack AP's
>>> (based on BSP flag not being present), while BSP would be allowed to go 
>>> through
>>> the regular BIOS code, checking for reset case, etc. An OS on the other hand
>>> would be free to treat all x86 processors equally, once it has booted into
>>> fully symmetrical mode.
>>> I certainly could be wrong about my above interpretation, but with these
>>> changes I'm proposing, things work well for the test case of manually 
>>> onlining
>>> the BSP after the crash kernel has been started (via kexec -e on a AP 
>>> processor
>>> with maxcpus=1 on the crash kernel command line). From looking through the
>>> kernel git history it appears this sequence of events was explicitly 
>>> supported
>>> quite a while ago, and we've got a customer who uses this for fast recovery 
>>> from
>>> a guest kernel crash.
>>>
>>> Bruce
>> 
>> I mean kexec - p ... above, not kexec -e. Sorry about that.
> 
> How does real HW behave with your kexec case? Did you try this?


I appreciate the review of these patches. I think I was premature in sharing
these patches, not having more fully vetting our customer's claims, and by
trying to satisfy their request that it also work the same under KVM
Virtualization without more complete details.

I had initially tried it on real hardware I have and it didn't behave as the
customer claimed, but mistakenly I dropped that concern, More recent testing
on additional machines continues to show that this approach does not work
on real hardware, and I think we want KVM to act like real hardware here.

I've asked for more details from the customer on their hardware and the 
specifics
of their use case. I'm also taking more time to get familiar with how this part 
of
KVM works.

Thanks,

Bruce

[PATCH V1] mfd: da9063: fix missing volatile registers in the core regmap_range volatile lists

[Steve Twiss]

From: Steve Twiss 

Add an updated set of registers listed in the core regmap_range volatile
ranges defined for the DA9063.

These new registers contain bits that cannot be considered under the full
control of software. Under various conditions the hardware will set and/or
automatically clear bit(s) contained in these registers.

When using a cached version of regmap, the volatility of these registers must
be identified otherwise the regmap operations may not ensure the registers
are explicitly altered.

As well as updating the list of volatile registers, this change will fix a
corner case discovered in the DA9063 ONKEY which is used by the DA9063 core.
 
In the ONKEY case, the CONTROL_B register is now listed as volatile in the
regmap_range because it contains the bit field NONKEY_LOCK. This bit can be
altered by hardware, in which case regmap must be notified of its ability
to be manpiulated outside of software control.

Signed-off-by: Steve Twiss 

---

Hi Lee,

This patch applies against linux-next and v4.5-rc1

It is quite similar to a previous patch you recently applied
- https://lkml.org/lkml/2016/2/1/485

But this is for the DA9063 not DA9062

Regards,
Steve


 drivers/mfd/da9063-i2c.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 2d4e3e0..7390108 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -74,18 +74,30 @@ static const struct regmap_range 
da9063_ad_writeable_ranges[] = {
 
 static const struct regmap_range da9063_ad_volatile_ranges[] = {
{
-   .range_min = DA9063_REG_STATUS_A,
+   .range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_EVENT_D,
}, {
-   .range_min = DA9063_REG_CONTROL_F,
+   .range_min = DA9063_REG_CONTROL_A,
+   .range_max = DA9063_REG_CONTROL_B,
+   }, {
+   .range_min = DA9063_REG_CONTROL_E,
.range_max = DA9063_REG_CONTROL_F,
}, {
-   .range_min = DA9063_REG_ADC_MAN,
+   .range_min = DA9063_REG_BCORE2_CONT,
+   .range_max = DA9063_REG_LDO11_CONT,
+   }, {
+   .range_min = DA9063_REG_DVC_1,
.range_max = DA9063_REG_ADC_MAN,
}, {
.range_min = DA9063_REG_ADC_RES_L,
.range_max = DA9063_AD_REG_SECOND_D,
}, {
+   .range_min = DA9063_REG_SEQ,
+   .range_max = DA9063_REG_SEQ,
+   }, {
+   .range_min = DA9063_REG_EN_32K,
+   .range_max = DA9063_REG_EN_32K,
+   }, {
.range_min = DA9063_AD_REG_MON_REG_5,
.range_max = DA9063_AD_REG_MON_REG_6,
},
@@ -152,18 +164,30 @@ static const struct regmap_range 
da9063_bb_writeable_ranges[] = {
 
 static const struct regmap_range da9063_bb_volatile_ranges[] = {
{
-   .range_min = DA9063_REG_STATUS_A,
+   .range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_EVENT_D,
}, {
-   .range_min = DA9063_REG_CONTROL_F,
+   .range_min = DA9063_REG_CONTROL_A,
+   .range_max = DA9063_REG_CONTROL_B,
+   }, {
+   .range_min = DA9063_REG_CONTROL_E,
.range_max = DA9063_REG_CONTROL_F,
}, {
-   .range_min = DA9063_REG_ADC_MAN,
+   .range_min = DA9063_REG_BCORE2_CONT,
+   .range_max = DA9063_REG_LDO11_CONT,
+   }, {
+   .range_min = DA9063_REG_DVC_1,
.range_max = DA9063_REG_ADC_MAN,
}, {
.range_min = DA9063_REG_ADC_RES_L,
.range_max = DA9063_BB_REG_SECOND_D,
}, {
+   .range_min = DA9063_REG_SEQ,
+   .range_max = DA9063_REG_SEQ,
+   }, {
+   .range_min = DA9063_REG_EN_32K,
+   .range_max = DA9063_REG_EN_32K,
+   }, {
.range_min = DA9063_BB_REG_MON_REG_5,
.range_max = DA9063_BB_REG_MON_REG_6,
},
-- 
end-of-patch for PATCH V1

Re: Another proposal for DAX fault locking

[Boaz Harrosh]

On 02/09/2016 07:24 PM, Jan Kara wrote:
> Hello,
> 
> I was thinking about current issues with DAX fault locking [1] (data
> corruption due to racing faults allocating blocks) and also races which
> currently don't allow us to clear dirty tags in the radix tree due to races
> between faults and cache flushing [2]. Both of these exist because we don't
> have an equivalent of page lock available for DAX. While we have a
> reasonable solution available for problem [1], so far I'm not aware of a
> decent solution for [2]. After briefly discussing the issue with Mel he had
> a bright idea that we could used hashed locks to deal with [2] (and I think
> we can solve [1] with them as well). So my proposal looks as follows:
> 
> DAX will have an array of mutexes (the array can be made per device but
> initially a global one should be OK). We will use mutexes in the array as a
> replacement for page lock - we will use hashfn(mapping, index) to get
> particular mutex protecting our offset in the mapping. On fault / page
> mkwrite, we'll grab the mutex similarly to page lock and release it once we
> are done updating page tables. This deals with races in [1]. When flushing
> caches we grab the mutex before clearing writeable bit in page tables
> and clearing dirty bit in the radix tree and drop it after we have flushed
> caches for the pfn. This deals with races in [2].
> 
> Thoughts?
> 

You could also use one of the radix-tree's special-bits as a bit lock.
So no need for any extra allocations.

[latest page-lock is a bit-lock so performance is the same]

Thanks
Boaz

[GIT PULL] libata fixes for v4.5-rc3

[Tejun Heo]

Hello, Linus.

libata fixes for v4.5-rc3.

* PORTS_IMPL workaround for very early ahci controllers is misbehaving
  on new systems.  Disabled on recent ahci versions.

* Old-style PIO state machine had a horrible locking problem.  Don't
  know how we've been getting away this far.  Fixed.

* Other device specific updates.

Thanks.

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.5-fixes

for you to fetch changes up to 342decff2b846b46fa61eb5ee40986fab79a9a32:

  ahci: Intel DNV device IDs SATA (2016-02-10 11:35:55 -0500)


Alexandra Yates (1):
  ahci: Intel DNV device IDs SATA

Danesh Petigara (1):
  drivers: ata: wake port before DMA stop for ALPM

Shikha Jain (1):
  libata: blacklist a Viking flash model for MWDMA corruption

Tejun Heo (3):
  libata: disable forced PORTS_IMPL for >= AHCI 1.3
  libata-sff: use WARN instead of BUG on illegal host state machine state
  libata: fix sff host state machine locking while polling

 drivers/ata/ahci.c | 20 
 drivers/ata/ahci.h |  1 +
 drivers/ata/ahci_brcmstb.c |  1 +
 drivers/ata/libahci.c  | 27 ---
 drivers/ata/libata-core.c  |  1 +
 drivers/ata/libata-sff.c   | 35 +--
 include/linux/libata.h |  1 +
 7 files changed, 61 insertions(+), 25 deletions(-)

-- 
tejun

[PATCH] ceph: fix a wrong comparison

[Anton Protopopov]

A negative value rc compared to the positive value ENOENT in the
finish_read() function.

Signed-off-by: Anton Protopopov 
---
 fs/ceph/addr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index c222137..1b809c9 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -276,7 +276,7 @@ static void finish_read(struct ceph_osd_request *req, 
struct ceph_msg *msg)
for (i = 0; i < num_pages; i++) {
struct page *page = osd_data->pages[i];
 
-   if (rc < 0 && rc != ENOENT)
+   if (rc < 0 && rc != -ENOENT)
goto unlock;
if (bytes < (int)PAGE_CACHE_SIZE) {
/* zero (remainder of) page */
-- 
2.6.5

[PATCH v8 5/8] ppc64 ftrace_with_regs: disable profiling for some files

[Torsten Duwe]

Using -mprofile-kernel on early boot code not only confuses the
checker but is also useless, as the infrastructure is not yet in
place. Proceed like with -pg (remove it from CFLAGS), equally with
time.o, ftrace and its helper files.

  * arch/powerpc/kernel/Makefile,
arch/powerpc/lib/Makefile:
- remove -mprofile-kernel from low level, boot code and
  code-patching objects' CFLAGS.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/kernel/Makefile | 12 ++--
 arch/powerpc/lib/Makefile|  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 794f22a..44667fd 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -16,14 +16,14 @@ endif
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog -mprofile-kernel
+CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog -mprofile-kernel
+CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog -mprofile-kernel
+CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog -mprofile-kernel
 # do not trace tracer code
-CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog -mprofile-kernel
 # timers used by tracing
-CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog -mprofile-kernel
 endif
 
 obj-y  := cputable.o ptrace.o syscalls.o \
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index a47e142..98e22b2 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -6,8 +6,8 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
 
 ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
 
-CFLAGS_REMOVE_code-patching.o = -pg
-CFLAGS_REMOVE_feature-fixups.o = -pg
+CFLAGS_REMOVE_code-patching.o = -pg -mprofile-kernel
+CFLAGS_REMOVE_feature-fixups.o = -pg -mprofile-kernel
 
 obj-y += string.o alloc.o crtsavres.o ppc_ksyms.o code-patching.o \
 feature-fixups.o
-- 
1.8.5.6

Re: [PATCH V1 0/6] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

[Will Deacon]

On Fri, Feb 05, 2016 at 12:13:22PM -0700, Tyler Baicar wrote:
> Add support for Generic Hardware Error Source (GHES) v2, which introduces the
> capability for the OS to acknowledge the consumption of the error record
> generated by the Reliability, Availability and Serviceability (RAS) 
> controller.
> This eliminates potential race conditions between the OS and the RAS 
> controller.
> 
> Add support for the timestamp field added to the Generic Error Data Entry v3,
> allowing the OS to log the time that the error is generated by the firmware,
> rather than the time the error is consumed. This improves the correctness of
> event sequences when analyzing error logs. The timestamp is added in
> ACPI 6.1, reference Table 18-343 Generic Error Data Entry.
> 
> Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
> specification. ARMv8 specific processor error information is reported as part 
> of
> the CPER records.  This provides more detail on for processor error logs.
> 
> Synchronous External Abort (SEA) represents a specific processor error 
> condition
> in ARM systems. A handler is added to recognize SEA errors, and a notifier is
> added to parse and report the errors before the process is killed. Refer to
> section N.2.1.1 in the Common Platform Error Record appendix of the UEFI 2.6
> specification.
> 
> Depends on: [PATCH v5] acpi, apei, arm64: APEI initial support for aarch64.
> https://lkml.org/lkml/2015/12/10/131

Did the TLB flushing issue ever get sorted out with that series?

http://marc.info/?l=linux-arm-kernel=145009373307418=2

It doesn't affect arm64, but I think it's a real issue for x86 when local
invalidation is in effect to avoid IPIs from interrupt context.

Will

[PATCH v6 1/2] fixed typo in ufshcd-pltfrm

[Joao Pinto]

Fixed typo in ufshcd-pltfrm.

Signed-off-by: Joao Pinto 
---
Changes v0->v6:
- Nothing changed (just to keep up with patch set version).

 drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index d2a7b12..0522891 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -353,6 +353,6 @@ EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init);
 
 MODULE_AUTHOR("Santosh Yaragnavi ");
 MODULE_AUTHOR("Vinayak Holikatti ");
-MODULE_DESCRIPTION("UFS host controller Pltform bus based glue driver");
+MODULE_DESCRIPTION("UFS host controller Platform bus based glue driver");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(UFSHCD_DRIVER_VERSION);
-- 
1.8.1.5

Re: [PATCH v3] powerpc32: provide VIRT_CPU_ACCOUNTING

[kbuild test robot]

Hi Christophe,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.5-rc3 next-20160210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc32-provide-VIRT_CPU_ACCOUNTING/20160210-230049
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   In file included from arch/powerpc/kernel/head_64.S:180:0:
>> arch/powerpc/kernel/exceptions-64s.S:776:1: error: macro 
>> "ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:778:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
^
   arch/powerpc/kernel/exceptions-64s.S:779:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt)
^
   arch/powerpc/kernel/exceptions-64s.S:780:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt)
^
   arch/powerpc/kernel/exceptions-64s.S:782:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:786:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:787:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:788:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:789:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt)
^
   arch/powerpc/kernel/exceptions-64s.S:790:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:792:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:796:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, 
performance_monitor_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:797:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, 
instruction_breakpoint_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:798:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:800:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:805:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:806:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:807:1: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
^
   arch/powerpc/kernel/exceptions-64s.S:980:43: error: macro 
"ACCOUNT_CPU_USER_ENTRY" requires 3 arguments, but only 2 given
 EXCEPTION_PROLOG_COMMON(0x300, PACA_EXGEN)
  ^
   arch/powerpc/kernel/exceptions-64s.S:995:43: error: macro 
"ACCOUNT

[PATCH] let kernfs_name_locked & kernfs_name return size_t

[Christian Brauner]

They return the length of kn->parent or kn->name and should be aligned with
kernfs_path_len which also returns size_t.

Signed-off-by: Christian Brauner 
---
 fs/kernfs/dir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 742bf4a..a3553b8 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -39,7 +39,7 @@ static bool kernfs_lockdep(struct kernfs_node *kn)
 #endif
 }
 
-static int kernfs_name_locked(struct kernfs_node *kn, char *buf, size_t buflen)
+static size_t kernfs_name_locked(struct kernfs_node *kn, char *buf, size_t 
buflen)
 {
return strlcpy(buf, kn->parent ? kn->name : "/", buflen);
 }
@@ -80,7 +80,7 @@ static char * __must_check kernfs_path_locked(struct 
kernfs_node *kn, char *buf,
  *
  * This function can be called from any context.
  */
-int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen)
+size_t kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen)
 {
unsigned long flags;
int ret;
-- 
2.7.0

Re: [PATCH v7 04/10] mfd: axp20x: Add missing copyright notice

[Lee Jones]

On Mon, 25 Jan 2016, Maxime Ripard wrote:
> On Mon, Jan 25, 2016 at 02:39:57PM +, Lee Jones wrote:
> > On Wed, 13 Jan 2016, Chen-Yu Tsai wrote:
> > 
> > > When the driver was merged, the original author did not include a proper
> > > copyright notice. This patch adds the notice, backdated to when the
> > > driver was merged.
> > 
> > This is very wordy. 
> > 
> > "Supply a backdated copyright notice."
> > 
> > > Cc: Carlo Caione 
> > > Signed-off-by: Chen-Yu Tsai 
> > > ---
> > > 
> > > New patch in v7.
> > > 
> > > ---
> > >  drivers/mfd/axp20x.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > 
> > Patch looks fine though:
> > 
> > Acked-by: Lee Jones 
> 
> How do you want to merge these patches ?
> 
> AFAIK, it's mostly MFD patches that could go through your tree, so
> feel free to apply them, I'll apply the DT parts.

Apologies for the delay, I've been super busy.

Yes, please take the ARM patches, I'll take the rest.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range

[Aneesh Kumar K.V]

"Aneesh Kumar K.V"  writes:

> We remove one instace of flush_tlb_range here. That was added by
> f714f4f20e59ea6eea264a86b9a51fd51b88fc54 ("mm: numa: call MMU notifiers
> on THP migration"). But the pmdp_huge_clear_flush_notify should have
> done the require flush for us. Hence remove the extra flush.
>
> Signed-off-by: Aneesh Kumar K.V 
> ---
> Changes from V1:
> * fix build error
>
>  include/asm-generic/pgtable.h | 17 +
>  mm/migrate.c  |  8 +---
>  mm/pgtable-generic.c  | 14 --
>  3 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index c370b261c720..9401f4819891 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -783,6 +783,23 @@ static inline int pmd_clear_huge(pmd_t *pmd)
>  }
>  #endif   /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>
> +#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +/*
> + * ARCHes with special requirements for evicting THP backing TLB entries can
> + * implement this. Otherwise also, it can help optimize normal TLB flush in
> + * THP regime. stock flush_tlb_range() typically has optimization to nuke the
> + * entire TLB TLB if flush span is greater than a threshold, which will
> + * likely be true for a single huge page. Thus a single thp flush will
> + * invalidate the entire TLB which is not desitable.
> + * e.g. see arch/arc: flush_pmd_tlb_range
> + */
> +#define flush_pmd_tlb_range(vma, addr, end)  flush_tlb_range(vma, addr, end)
> +#else
> +#define flush_pmd_tlb_range(vma, addr, end)  BUILD_BUG()
> +#endif
> +#endif
> +
>  #endif /* !__ASSEMBLY__ */
>
>  #ifndef io_remap_pfn_range
> diff --git a/mm/migrate.c b/mm/migrate.c
> index b1034f9c77e7..c079c115d038 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1767,7 +1767,10 @@ int migrate_misplaced_transhuge_page(struct mm_struct 
> *mm,
>   put_page(new_page);
>   goto out_fail;
>   }
> -
> + /*
> +  * We are not sure a pending tlb flush here is for a huge page
> +  * mapping or not. Hence use the tlb range variant
> +  */
>   if (mm_tlb_flush_pending(mm))
>   flush_tlb_range(vma, mmun_start, mmun_end);
>

I was thinking we should be able to switch this flush_pmd_tlb_range. But
Kirill was not sure when we discussed this last time. Can we have a
pending tlb flush with PAGE_SIZE page translation, when we are parallely
trying to handle a autonuma fault on that ?


> @@ -1823,12 +1826,11 @@ fail_putback:
>   page_add_anon_rmap(new_page, vma, mmun_start, true);
>   pmdp_huge_clear_flush_notify(vma, mmun_start, pmd);
>   set_pmd_at(mm, mmun_start, pmd, entry);
> - flush_tlb_range(vma, mmun_start, mmun_end);
>   update_mmu_cache_pmd(vma, address, );
>
>   if (page_count(page) != 2) {
>   set_pmd_at(mm, mmun_start, pmd, orig_entry);
> - flush_tlb_range(vma, mmun_start, mmun_end);
> + flush_pmd_tlb_range(vma, mmun_start, mmun_end);
>   mmu_notifier_invalidate_range(mm, mmun_start, mmun_end);
>   update_mmu_cache_pmd(vma, address, );
>   page_remove_rmap(new_page, true);
> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> index 9d4767698a1c..3c9c78400300 100644
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -84,20 +84,6 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma, 
> unsigned long address,
>
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>
> -#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> -
> -/*
> - * ARCHes with special requirements for evicting THP backing TLB entries can
> - * implement this. Otherwise also, it can help optimize normal TLB flush in
> - * THP regime. stock flush_tlb_range() typically has optimization to nuke the
> - * entire TLB TLB if flush span is greater than a threshhold, which will
> - * likely be true for a single huge page. Thus a single thp flush will
> - * invalidate the entire TLB which is not desitable.
> - * e.g. see arch/arc: flush_pmd_tlb_range
> - */
> -#define flush_pmd_tlb_range(vma, addr, end)  flush_tlb_range(vma, addr, end)
> -#endif
> -
>  #ifndef __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
>  int pmdp_set_access_flags(struct vm_area_struct *vma,
> unsigned long address, pmd_t *pmdp,
> -- 
> 2.5.0

-aneesh

[PATCH] let kernfs_name_locked & kernfs_name return size_t

[Christian Brauner]

Simple patch that changes the return value of kernfs_name_locked and kernfs_name
to size_t which alignes these functions with kernfs_path_len which also returns
size_t.

Patch was made against for-4.5 branch.
(As per Tejun's request, ccing gre...@linuxfoundation.org and
 linux-kernel@vger.kernel.org.)

Christian Brauner (1):
  let kernfs_name_locked & kernfs_name return size_t

 fs/kernfs/dir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.7.0

Re: [PATCHSET] workqueue: break local execution guarantee of unbound work items

[Tejun Heo]

Hello, Jiri.

On Wed, Feb 10, 2016 at 09:01:38AM +0100, Jiri Slaby wrote:
> Thanks all for sorting the issue out. Now it remains to decide what
> should go to stable. Given only 0001 is marked as "Fixes", is that enough?

I think so.  The other two are primarily for debugging anyway.

> And what about the vmstat fix:
> commit 176bed1de5bf977938cad26551969eca8f0883b1
> Author: Linus Torvalds 
> Date:   Thu Oct 15 13:01:50 2015 -0700
> 
> vmstat: explicitly schedule per-cpu work on the CPU we need it to run on
> 
> ? It should fix better than what 0001 is reverting AFAIU, right?

Yes, definitely.  Didn't know that one wasn't tagged for stable.

Thanks.

-- 
tejun

Re: [PATCH V7 4/5] mfd: max77686: do not set i2c client data for rtc i2c client

[Lee Jones]

On Tue, 09 Feb 2016, Laxman Dewangan wrote:

> There is different RTC I2C address for RTC block in MAX77686.
> Driver is creating dummy i2c client for this address to access
> the register of this IP block.
> 
> As there is no call to i2c_get_clientdata() for rtc_i2c client,
> there is no need to store pointer and hence removing the call
> to set client data for rtc i2c client.
> 
> Suggested-by: Krzysztof Kozlowski 
> Signed-off-by: Laxman Dewangan 
> CC: Krzysztof Kozlowski 
> CC: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> Tested-by: Javier Martinez Canillas 
> Reviewed-by: Javier Martinez Canillas 
> 
> ---
> This is new in this series based on review comment from V1.
> 
> Changes from V2:
> - Rephrase description.
> - Added reviewed by.
> 
> Changes from V3:
> - None, become 5th on series.
> 
> Changes from V4:
> None
> 
> Changes from V5:
> None
> 
> Changes from V6:
> Make this as 4th of series as regmap change applied independently.
> 
>  drivers/mfd/max77686.c | 1 -
>  1 file changed, 1 deletion(-)

Appart from the subject line being wrong:

Acked-by: Lee Jones 

[...]

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V7 5/5] rtc: max77686: move initialisation of rtc regmap, irq chip locally

[Lee Jones]

On Tue, 09 Feb 2016, Laxman Dewangan wrote:

> To make RTC block of MAX77686/MAX77802 as independent driver,
> move the registration of i2c device, regmap for register access
> and irq_chip for interrupt support inside the RTC driver.
> Removed the same initialisation from MFD driver.
> 
> Having this change will allow to reuse this driver for different
> PMIC/devices from Maxim Semiconductor if they kept same RTC IP on
> different PMIC. Some of examples as PMIC MAX77620, MAX20024 where
> same RTC IP used and hence driver for these chips will use this
> driver only for RTC support.
> 
> Suggested-by: Krzysztof Kozlowski 
> Signed-off-by: Laxman Dewangan 
> CC: Krzysztof Kozlowski 
> CC: Javier Martinez Canillas 
> Tested-by: Javier Martinez Canillas 
> Reviewed-by: Javier Martinez Canillas 
> 
> ---
> Changes from V1:
> - Remove changes from Kconfig.
> - Maintain all register definition in max77686 private header and remove
>   the movement to rtc driver.
> - Taken care of all comments on V1 from Krzysztof and Javier.
> 
> Changes from V2:
> - Taken care of missed sequence for removing the resource.
> - Fix the crash when doing unbind by using requested_threaded_irq()
>   instead of demv_requested_threaded_irq().
> 
> Changes from V3:
> - Fix the issue of suspend-resume with unbind/bind by unmapping the
>   virq.
> 
> Changes from V4:
> - Dispose mapped irq in error path in probe
> 
> Changes from V5:
> - Remove the new APIs from regmap as functionality added to dispose the
>   virq inside the regmap_del_irq_chip().
> 
> Changes from V6:
> Make this as 5th of series as regmap change applied independently.
> Also rebase on linux-next 20160209
> 
>  drivers/mfd/max77686.c   |  85 +---
>  drivers/rtc/rtc-max77686.c   | 148 
> ++-
>  include/linux/mfd/max77686-private.h |   3 -
>  3 files changed, 130 insertions(+), 106 deletions(-)

Yes, yes, yes!

This is how it should have been done in the first place IMHO.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

[Juri Lelli]

On 10/02/16 09:37, Steven Rostedt wrote:
> On Wed, 10 Feb 2016 11:32:58 +
> Juri Lelli  wrote:
> 
> > Hi,
> > 
> > I've updated this patch since, with a bit more testing and talking with
> > Luca in private, I realized that the previous version didn't manage
> > switching back and forth from SCHED_DEADLINE correctly. Thanks a lot
> > Luca for your feedback (even if not visible on the list).
> > 
> > I updated the testing branch accordingly and added a test to my tests
> > that stresses switch-in/switch-out.
> > 
> > I don't particularly like the fact that we break the scheduling classes
> > abstraction in __dl_overflow(), so I think a little bit of refactoring
> > is still needed. But that can also happen afterwards, if we fix the
> > problem with root domains.
> > 
> > Best,
> > 
> > - Juri
> > 
> > --->8---  
> > 
> > >From 62f70ca3051672dce209e8355cf5eddc9d825c2a Mon Sep 17 00:00:00 2001  
> > From: Juri Lelli 
> > Date: Sat, 6 Feb 2016 12:41:09 +
> > Subject: [PATCH 1/2] sched/deadline: add per rq tracking of admitted 
> > bandwidth
> > 
> 
> 
> I applied this patch and patch 2 and hit this:
> 
> [ 2298.134284] [ cut here ]
> [ 2298.138933] WARNING: CPU: 4 PID: 0 at 
> /home/rostedt/work/git/linux-trace.git/kernel/sched/sched.h:735 
> task_dead_dl+0xc5/0xd0()
> [ 2298.150350] Modules linked in: ip6table_filter ip6_tables ebtable_nat 
> ebtables xt_CHECKSUM iptable_mangle bridge stp llc bluetooth lockd grace 
> snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
> snd_hda_codec snd_hwdep snd_hda_core x86_pkg_temp_thermal snd_seq vhost_net 
> snd_seq_device tun vhost macvtap macvlan coretemp iTCO_wdt snd_pcm hp_wmi 
> rfkill kvm_intel sparse_keymap iTCO_vendor_support snd_timer snd acpi_cpufreq 
> kvm i2c_i801 mei_me mei soundcore lpc_ich mfd_core irqbypass wmi serio_raw 
> uinput i915 i2c_algo_bit e1000e drm_kms_helper crc32_pclmul ptp crc32c_intel 
> drm pps_core i2c_core video sunrpc
> [ 2298.207495] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.5.0-rc1-test+ #204
> [ 2298.214392] Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, 
> BIOS K01 v02.05 05/07/2012
> [ 2298.223371]  81abc680 880119433d68 81411c3f 
> 
> [ 2298.230904]  81abc680 880119433da0 810acf66 
> 88011eb16f40
> [ 2298.238435]  88001ee16200 81fd4a00 000a 
> 0001
> [ 2298.245958] Call Trace:
> [ 2298.248431]  [] dump_stack+0x50/0xb1
> [ 2298.253597]  [] warn_slowpath_common+0x86/0xc0
> [ 2298.259627]  [] warn_slowpath_null+0x1a/0x20
> [ 2298.265490]  [] task_dead_dl+0xc5/0xd0
> [ 2298.270828]  [] finish_task_switch+0x16f/0x310
> [ 2298.276871]  [] ? pick_next_task_dl+0xb3/0x250
> [ 2298.282906]  [] __schedule+0x3d3/0x9e0
> [ 2298.288252]  [] schedule+0x41/0xc0
> [ 2298.293242]  [] schedule_preempt_disabled+0x18/0x30
> [ 2298.299712]  [] cpu_startup_entry+0x74/0x4e0
> [ 2298.305573]  [] start_secondary+0x2bf/0x330
> [ 2298.311347] ---[ end trace 732d16efabe456f1 ]---
> 
> It's the warning you added in __dl_sub_ac().
> 

OK. There are still holes where we fail to properly update per-rq bw. It
seems (by running you test) that we fail to move the per-rq bw when we
move the root_domain bw due css_set_move_task(). So, the final
task_dead_dl() tries to remove bw from where there isn't.

I'm trying to see how we can close this hole.

Thanks,

- Juri

Re: [PATCH] let kernfs_name_locked & kernfs_name return size_t

[Tejun Heo]

On Wed, Feb 10, 2016 at 05:18:59PM +0100, Christian Brauner wrote:
> They return the length of kn->parent or kn->name and should be aligned with
> kernfs_path_len which also returns size_t.
> 
> Signed-off-by: Christian Brauner 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

Re: [PATCHv3 1/3] rdmacg: Added rdma cgroup controller.

[Haggai Eran]

On 01/02/2016 20:59, Parav Pandit wrote:
> On Tue, Feb 2, 2016 at 12:10 AM, Tejun Heo  wrote:
>> So, I'm really not gonna go for individual drivers defining resources
>> on their own.  That's a trainwreck waiting to happen.  There needs to
>> be a lot more scrutiny than that.
>>
> Not every low level driver. I started with that infrastructure in
> v2,v3 but I got your inputs and
> I align with that. It could be just single IB stack in one header file
> in one enum list would be sufficient.
> You have already given that example.
> With that mostly two resource type that I have can also shrink to just
> single type.
> Will wait to hear from them, in case if they have any different thought.

Hi,

Sorry for the late reply.

I think that starting with the standard set of resources that uverbs 
provide is good, and if we need in the future new types of resources 
we can add them later.

On 31/01/2016 19:50, Parav Pandit wrote:
> How would you like to see RDMA verb resources being defined - in RDMA
> cgroup or in IB stack?
> In current patch v5, its defined by the IB stack which is often
> shipped as different package due to high amount of changes, bug fixes,
> features.
> In v0 patch it was defined by the RDMA cgroup, which means any new
> resource addition/definition requires kernel upgrade. Which is hard to
> change often.

There is indeed an effort to backport the latest RDMA subsystem modules to 
older kernels, and it would be preferable to be able to introduce new
resources through these modules. However, I understand that there are no
other cgroups that are modules or depend on modules this way, so I would
understand if you decide against it.

> If resources are defined by RDMA cgroup kernel than adding/removing
> resource means, someone have to do lot of engineering with different
> versions of kernel support and loadable module support using compat.h
> etc at driver level, which in my mind is some amount of engineering
> compare to what v5 has to offer and its already available. With one
> round of cleanup in resource definition, it should be usable.
If I understand correctly, if the resources are defined in the cgroup,
you simply won't be able to add new resources with a module update,
no matter how hard you work.

I agree that if the cgroup code is changed for cleanup or whatever 
reason, the backporting may become difficult, but that's just life.

> Its important to provide this feedback to Tejun and me, so that we
> take informed design decision.

Sure. I hope this patchset gets accepted eventually, as I believe it 
solves a real problem. Today RDMA application can easily hog these 
resources and the rdma cgroup allows users to prevent that.

Regards,
Haggai

Re: [PATCH] usb: core: hub: hub_port_init lock controller instead of bus

[Mathias Nyman]

On 08.02.2016 15:49, Chris Bainbridge wrote:

The XHCI controller presents two USB buses to the system - one for USB 2
and one for USB 3. When only one bus is locked there is a race condition
with two threads in hub_port_init:

[8.984500] Call Trace:
[8.985698]  [] schedule+0x37/0x90
[8.986918]  [] usb_kill_urb+0x8d/0xd0
[8.988130]  [] ? wake_up_atomic_t+0x30/0x30
[8.989343]  [] usb_start_wait_urb+0xbe/0x150
[8.990561]  [] usb_control_msg+0xbc/0xf0
[8.991766]  [] hub_port_init+0x51e/0xb70
[8.992964]  [] hub_event+0x817/0x1570
[8.994156]  [] process_one_work+0x1ff/0x620
[8.995342]  [] ? process_one_work+0x15f/0x620
[8.996528]  [] worker_thread+0x64/0x4b0
[8.997707]  [] ? rescuer_thread+0x390/0x390
[8.998883]  [] kthread+0x105/0x120
[9.56]  [] ? kthread_create_on_node+0x200/0x200
[9.001241]  [] ret_from_fork+0x3f/0x70
[9.002420]  [] ? kthread_create_on_node+0x200/0x200

[9.870837] Call Trace:
[9.875664]  [] xhci_setup_device+0x53d/0xa40
[9.876871]  [] xhci_address_device+0xe/0x10
[9.878068]  [] hub_port_init+0x1bf/0xb70
[9.879262]  [] ? trace_hardirqs_on+0xd/0x10
[9.880465]  [] hub_event+0x817/0x1570
[9.881668]  [] process_one_work+0x1ff/0x620
[9.882869]  [] ? process_one_work+0x15f/0x620
[9.884074]  [] worker_thread+0x64/0x4b0
[9.885268]  [] ? rescuer_thread+0x390/0x390
[9.886457]  [] kthread+0x105/0x120
[9.887634]  [] ? kthread_create_on_node+0x200/0x200
[9.17]  [] ret_from_fork+0x3f/0x70
[9.889995]  [] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
  usb_get_device_descriptor
   usb_get_descriptor
usb_control_msg
 usb_internal_control_msg
  usb_start_wait_urb
   usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
  hub_set_address
   xhci_address_device
xhci_setup_device

The logged kernel errors are:

[8.034843] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

Hypothetically, it should perhaps be possible to set the address of the
hub on one bus while the hub on the other bus already has an outstanding
descriptor read request. But as this is not working reliably, fix it by
locking the controller in hub_port_init to prevent parallel
initialisation of both buses.



Most likely xhci is messed up after two device slots are in default state at 
the same time.
This happens when both threads are in hub_port_init() have called 
hub_port_reset()

The issue becomes visible when the the descriptor read and set address both 
fail after
the port resets.

xhci specs 4.5.3 has one tiny note about this:
"Note: Software shall not transition more than one Device Slot to the Default State 
at a time"

So to me, and from xhci pov this patch looks like the correct solution,
but I might be missing some usb core side details.

-Mathias

Re: [PATCH] gpio: TS-4800: remove useless bgpio_init flags

[Julien Grossholtz]

From: "Julien Grossholtz" 
To: "linus walleij" 
Cc: gnu...@gmail.com, linux-g...@vger.kernel.org, linux-kernel@vger.kernel.org, 
"Dan Carpenter" , ker...@savoirfairelinux.com, 
"Julien Grossholtz" 
Sent: Wednesday, February 10, 2016 11:58:34 AM
Subject: [PATCH] gpio: TS-4800: remove useless bgpio_init flags

No flags are required for bgpio_init in the TS-4800 gpio driver. This
patch set zero instead. The driver will have the same behaviour since
the | operator between the flags already resulted to zero.

There is a typo here, I will send it again.

Fixes: 5041e791440a ("gpio: add TS-4800 fpga GPIO support")

Signed-off-by: Julien Grossholtz 
---
 drivers/gpio/gpio-ts4800.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-ts4800.c b/drivers/gpio/gpio-ts4800.c
index c4908a4..9da79e4 100644
--- a/drivers/gpio/gpio-ts4800.c
+++ b/drivers/gpio/gpio-ts4800.c
@@ -48,8 +48,7 @@ static int ts4800_gpio_probe(struct platform_device *pdev)
 
retval = bgpio_init(chip, >dev, 2, base_addr + INPUT_REG_OFFSET,
base_addr + OUTPUT_REG_OFFSET, NULL,
-   base_addr + DIRECTION_REG_OFFSET, NULL,
-   BGPIOF_BIG_ENDIAN & BGPIOF_BIG_ENDIAN_BYTE_ORDER);
+   base_addr + DIRECTION_REG_OFFSET, NULL, 0);
if (retval) {
dev_err(>dev, "bgpio_init failed\n");
return retval;
-- 
2.5.0

Re: [mpt3sas driver patches 00/10] mpt3sas driver enhancements and

[Martin K. Petersen]

> "Suganath" == Suganath prabu Subaramani 
>  writes:

Applied to 4.6/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] selftests/cgroupns: new test for cgroup namespaces

[Serge E. Hallyn]

On Sun, Jan 31, 2016 at 06:48:12PM +0100, Alban Crequy wrote:
> From: Alban Crequy 
> 
> This adds the selftest "cgroupns_test" in order to test the CGroup
> Namespace patchset.
> 
> cgroupns_test creates two child processes. They perform a list of
> actions defined by the array cgroupns_test. This array can easily be
> extended to more scenarios without adding much code. They are
> synchronized with eventfds to ensure only one action is performed at a
> time.
> 
> The memory is shared between the processes (CLONE_VM) so each child
> process can know the pid of their siblings without extra IPC.
> 
> The output explains the scenario being played. Short extract:
> 
> > current cgroup: /user.slice/user-0.slice/session-1.scope
> > child process #0: check that process #self (pid=482) has cgroup 
> > /user.slice/user-0.slice/session-1.scope
> > child process #0: unshare cgroupns
> > child process #0: move process #self (pid=482) to cgroup 
> > cgroup-a/subcgroup-a
> > child process #0: join parent cgroupns
> 
> The test does not change the mount namespace and does not mount any
> new cgroup2 filesystem. Therefore this does not test that the cgroup2
> mount is correctly rooted to the cgroupns root at mount time.
> 
> Signed-off-by: Alban Crequy 

Thanks, Alban!

> Acked-by: Serge E. Hallyn 
> 
> ---
> 
> Changelog:
> 20160131 - rebase on sergeh/cgroupns.v10 and fix conflicts
> 
> 20160115 - Detect where cgroup2 is mounted, don't assume
>/sys/fs/cgroup (suggested by sergeh)
>  - Check more error conditions (from krnowak's review)
>  - Coding style (from krnowak's review)
>  - Update error message for Linux >= 4.5 (from krnowak's
>review)
> 
> 20160104 - Fix coding style (from sergeh's review)
>  - Fix printf formatting (from sergeh's review)
>  - Fix parsing of /proc/pid/cgroup (from sergeh's review)
>  - Fix concatenation of cgroup paths
> 
> 20151219 - First version
> 
> This patch is available in the cgroupns.v10-tests branch of
> https://github.com/kinvolk/linux.git
> It is rebased on top of Serge Hallyn's cgroupns.v10 branch of
> https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/
> 
> Test results:
> 
> - SUCCESS on kernel cgroupns.v10 booted with 
> systemd.unified_cgroup_hierarchy=1
> - SUCCESS on kernel cgroupns.v10 booted with 
> systemd.unified_cgroup_hierarchy=0
> ---
>  tools/testing/selftests/Makefile |   1 +
>  tools/testing/selftests/cgroupns/Makefile|  11 +
>  tools/testing/selftests/cgroupns/cgroupns_test.c | 445 
> +++
>  3 files changed, 457 insertions(+)
>  create mode 100644 tools/testing/selftests/cgroupns/Makefile
>  create mode 100644 tools/testing/selftests/cgroupns/cgroupns_test.c
> 
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index b04afc3..b373135 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -1,5 +1,6 @@
>  TARGETS = breakpoints
>  TARGETS += capabilities
> +TARGETS += cgroupns
>  TARGETS += cpu-hotplug
>  TARGETS += efivarfs
>  TARGETS += exec
> diff --git a/tools/testing/selftests/cgroupns/Makefile 
> b/tools/testing/selftests/cgroupns/Makefile
> new file mode 100644
> index 000..0fdbe0a
> --- /dev/null
> +++ b/tools/testing/selftests/cgroupns/Makefile
> @@ -0,0 +1,11 @@
> +CFLAGS += -I../../../../usr/include/
> +CFLAGS += -I../../../../include/uapi/
> +
> +all: cgroupns_test
> +
> +TEST_PROGS := cgroupns_test
> +
> +include ../lib.mk
> +
> +clean:
> + $(RM) cgroupns_test
> diff --git a/tools/testing/selftests/cgroupns/cgroupns_test.c 
> b/tools/testing/selftests/cgroupns/cgroupns_test.c
> new file mode 100644
> index 000..71e2336
> --- /dev/null
> +++ b/tools/testing/selftests/cgroupns/cgroupns_test.c
> @@ -0,0 +1,445 @@
> +#define _GNU_SOURCE
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "../kselftest.h"
> +
> +#define STACK_SIZE 65536
> +
> +static char cgroup_mountpoint[4096];
> +static char root_cgroup[4096];
> +
> +#define CHILDREN_COUNT 2
> +typedef struct {
> + pid_t pid;
> + uint8_t *stack;
> + int start_semfd;
> + int end_semfd;
> +} cgroupns_child_t;
> +cgroupns_child_t children[CHILDREN_COUNT];
> +
> +typedef enum {
> + UNSHARE_CGROUPNS,
> + JOIN_CGROUPNS,
> + CHECK_CGROUP,
> + CHECK_CGROUP_WITH_ROOT_PREFIX,
> + MOVE_CGROUP,
> + MOVE_CGROUP_WITH_ROOT_PREFIX,
> +} cgroupns_action_t;
> +
> +static const struct {
> + int actor_id;
> + cgroupns_action_t action;
> + int target_id;
> + char *path;
> +} cgroupns_tests[] = {
> + { 0, CHECK_CGROUP_WITH_ROOT_PREFIX, -1, "/"},
> + { 0, 

Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register

[Ray Jui]

Hi Linus,

On 2/10/2016 5:58 AM, Linus Walleij wrote:

On Wed, Feb 25, 2015 at 10:01 PM, Arun Ramamurthy
 wrote:


Added code based on linaro tree:
http://git.linaro.org/kernel/linux-linaro-stable.git
with commit id:6846e7822c4cab5a84672baace3b768c2d0db142
at drivers/video/amba-clcd.c. This lets the driver set
certain tim2 register bits after reading them from
device tree.

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Arun Ramamurthy 


I have now implemented this properly in this patch:
http://marc.info/?l=linux-fbdev=145459469913983=2

Please provide your Tested-by/Reviewed-by/Ack if you're
still working on this.


Could you please add me to the email thread and I can review it there (I 
won't have time to test, but I can help to review the code and find time 
to test later)?


This may be a dumb question, is there any way for me to directly reply 
to the thread here?


http://marc.info/?l=linux-fbdev=145459469913983=2



Yours,
Linus Walleij

Re: [PATCH v8] SATA: OCTEON: support SATA on OCTEON platform

[Tejun Heo]

On Tue, Feb 09, 2016 at 12:04:29PM +, Zubair Lutfullah Kakakhel wrote:
...
>  .../devicetree/bindings/ata/ahci-platform.txt  |   1 +
>  .../devicetree/bindings/mips/cavium/sata-uctl.txt  |  42 +
>  arch/mips/include/asm/octeon/cvmx.h|   9 ++
>  drivers/ata/Kconfig|   9 ++
>  drivers/ata/Makefile   |   1 +
>  drivers/ata/ahci_platform.c|   1 +
>  drivers/ata/sata_octeon.c  | 105 
> +

Don't we usually name these ahci variants ahci_xxx?

Thanks.

-- 
tejun

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[Johannes Berg]

On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote:
> I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> state. It's just an indicator with no relationship to any of the
> registered rfkill switches, right?

Yes. I'm not sure I'm totally happy with this userspace API.

> I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't
> also
> softblock all switches, otherwise you can set airplane mode all day
> long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually
> enable
> airplane mode at all?

No, this is kinda the point that you could implement your policy in
userspace now.

johannes

Re: [PATCH v3] powerpc32: provide VIRT_CPU_ACCOUNTING

[kbuild test robot]

Hi Christophe,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.5-rc3 next-20160210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc32-provide-VIRT_CPU_ACCOUNTING/20160210-230049
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allnoconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

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

   In file included from arch/powerpc/kernel/asm-offsets.c:30:0:
   arch/powerpc/kernel/asm-offsets.c: In function 'main':
>> include/linux/compiler-gcc.h:158:2: error: 'struct thread_info' has no 
>> member named 'starttime'
 __builtin_offsetof(a, b)
 ^
   include/linux/kbuild.h:5:55: note: in definition of macro 'DEFINE'
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
  ^
   include/linux/stddef.h:16:32: note: in expansion of macro 
'__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
   ^
>> arch/powerpc/kernel/asm-offsets.c:260:25: note: in expansion of macro 
>> 'offsetof'
 DEFINE(PACA_STARTTIME, offsetof(struct thread_info, starttime));
^
>> include/linux/compiler-gcc.h:158:2: error: 'struct thread_info' has no 
>> member named 'starttime_user'
 __builtin_offsetof(a, b)
 ^
   include/linux/kbuild.h:5:55: note: in definition of macro 'DEFINE'
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
  ^
   include/linux/stddef.h:16:32: note: in expansion of macro 
'__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
   ^
   arch/powerpc/kernel/asm-offsets.c:261:30: note: in expansion of macro 
'offsetof'
 DEFINE(PACA_STARTTIME_USER, offsetof(struct thread_info, starttime_user));
 ^
>> include/linux/compiler-gcc.h:158:2: error: 'struct thread_info' has no 
>> member named 'user_time'
 __builtin_offsetof(a, b)
 ^
   include/linux/kbuild.h:5:55: note: in definition of macro 'DEFINE'
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
  ^
   include/linux/stddef.h:16:32: note: in expansion of macro 
'__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
   ^
   arch/powerpc/kernel/asm-offsets.c:262:25: note: in expansion of macro 
'offsetof'
 DEFINE(PACA_USER_TIME, offsetof(struct thread_info, user_time));
^
>> include/linux/compiler-gcc.h:158:2: error: 'struct thread_info' has no 
>> member named 'system_time'
 __builtin_offsetof(a, b)
 ^
   include/linux/kbuild.h:5:55: note: in definition of macro 'DEFINE'
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
  ^
   include/linux/stddef.h:16:32: note: in expansion of macro 
'__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
   ^
   arch/powerpc/kernel/asm-offsets.c:263:27: note: in expansion of macro 
'offsetof'
 DEFINE(PACA_SYSTEM_TIME, offsetof(struct thread_info, system_time));
  ^
   make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +158 include/linux/compiler-gcc.h

cb984d10 Joe Perches 2015-06-25  152  #  error Your version of gcc miscompiles 
the __weak directive
cb984d10 Joe Perches 2015-06-25  153  # endif
cb984d10 Joe Perches 2015-06-25  154  #endif
cb984d10 Joe Perches 2015-06-25  155  
cb984d10 Joe Perches 2015-06-25  156  #define __used
__attribute__((__used__))
cb984d10 Joe Perches 2015-06-25  157  #define __compiler_offsetof(a, b) 
\
cb984d10 Joe Perches 2015-06-25 @158__builtin_offsetof(a, b)
cb984d10 Joe Perches 2015-06-25  159  
cb984d10 Joe Perches 2015-06-25  160  #if GCC_VERSION >= 40100 && GCC_VERSION < 
40600
cb984d10 Joe Perches 2015-06-25  161  # define __compiletime_object_size(obj) 
__builtin_object_size(obj, 0)

:: The

Re: [PATCH] mfd: mt6397: Add platform device ID table

[Lee Jones]

On Tue, 09 Feb 2016, Javier Martinez Canillas wrote:

> The platform bus_type .match callback attempts to match the platform device
> name with an entry on the .id_table if provided and fallbacks to match with
> the driver's name if a table is not provided.
> 
> Using a platform device ID to match is more explicit, allows the driver to
> support more than one device and also the MODULE_DEVICE_TABLE macro can be
> used to export the module aliases information instead of the MODULE_ALIAS.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/mfd/mt6397-core.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 1749c1c9f405..11c28caf4e5a 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -275,6 +275,12 @@ static const struct of_device_id mt6397_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, mt6397_of_match);
>  
> +static const struct platform_device_id mt6397_id[] = {
> + {"mt6397", 0},

Please insert spaces at both ends.

> + { /* sentinel */ },

We know what a NULL entry does.  No need for the comment.

> +};
> +MODULE_DEVICE_TABLE(platform, mt6397_id);
> +
>  static struct platform_driver mt6397_driver = {
>   .probe = mt6397_probe,
>   .remove = mt6397_remove,
> @@ -283,6 +289,7 @@ static struct platform_driver mt6397_driver = {
>   .of_match_table = of_match_ptr(mt6397_of_match),
>   .pm = _pm_ops,
>   },
> + .id_table = mt6397_id,
>  };
>  
>  module_platform_driver(mt6397_driver);
> @@ -290,4 +297,3 @@ module_platform_driver(mt6397_driver);
>  MODULE_AUTHOR("Flora Fu, MediaTek");
>  MODULE_DESCRIPTION("Driver for MediaTek MT6397 PMIC");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("platform:mt6397");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v8 0/3] tty: Introduce software RS485 direction control support

[Peter Hurley]

On 02/10/2016 08:24 AM, Matwey V. Kornilov wrote:
> 2016-02-10 19:05 GMT+03:00 Peter Hurley :
>> Hi Matwey,
>>
>> On 02/01/2016 10:09 AM, Matwey V. Kornilov wrote:
>>> Changes from v7:
>>>  - rework comments to follow guidelines
>>>  - minor style changes
>>> Changes from v6:
>>>  - minor style changes
>>>  - timers are not IRQSAFE now
>>> Changes from v5:
>>>  - rs485_emul variable has been renamed to em485 to follow function names 
>>> convention
>>> Changes from v4:
>>>  - Add commit message to 1/3
>>> Changes from v3:
>>>  - Completely redesigned.
>>> Changes from v2:
>>>  - Introduced SER_RS485_SOFTWARE to show that software implementation is 
>>> being used
>>>  - serial8250_rs485_config is located as required
>>>  - Timers are used to implement delay_before and delay_after timeouts
>>>
>>> Signed-off-by: Matwey V. Kornilov 
>>
>> The holdup here is that I'd like to unit test this, which is 3rd on my todo 
>> list.
>> Should be done before the end of the week which will be soon enough
>> for this series to make linux-next.
> 
> Hi Peter,
> 
> Is something required from me?

Not unless my tests identify a problem. I'll let you know.

Re: [PATCH] Intel DNV device IDs SATA

[Tejun Heo]

On Fri, Feb 05, 2016 at 03:27:49PM -0800, Alexandra Yates wrote:
> Adding Intel codename DNV platform device IDs for SATA.
> 
> Signed-off-by: Alexandra Yates 

Applied to libata/for-4.5-fixes w/ stable cc'd.

Thanks.

-- 
tejun

Re: [PATCH] usb: host: xhci: Replace bus lock with host controller lock

[Mathias Nyman]

On 05.02.2016 17:14, Chris Bainbridge wrote:

Running task list at fail point:


...


Some of the functions appear to be inlined, the exact call chain is:

hub_port_init
 usb_get_device_descriptor
 usb_get_descriptor
 usb_control_msg
 usb_internal_control_msg
 usb_start_wait_urb
 usb_submit_urb / wait_for_completion_timeout / 
usb_kill_urb

hub_port_init
 hub_set_address
 xhci_address_device
 xhci_setup_device



hub_port_reset() will end up moving the corresponding xhci device slot to 
default state.

As hub_port_reset() is called several times in hub_port_init() It sounds 
reasonable
that we could end up with two threads having their xhci device slots in default 
state at
the same time,  which according to xhci 4.5.3 specs still is a big no no.

So both threads fail at their next task after this.
One fails to read the descriptor, and the other fails addressing the device.

Nice catch btw.


So xhci_setup_device is entered while there is an outstanding URB on the
other bus. Unless anyone can think of a better way to fix this I'll make
the requested changes and resend my patch.



For what it's wort I think that this suggested controller mutex sounds like a 
good idea.
Should work for xhci at least.

-Mathias

Re: [PATCH V3 1/4] dt-bindings: mfd: Add bindings for the MediaTek MT6323 PMIC

[Lee Jones]

On Wed, 27 Jan 2016, John Crispin wrote:

> Signed-off-by: John Crispin 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/mfd/mt6397.txt |   10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt 
> b/Documentation/devicetree/bindings/mfd/mt6397.txt
> index 15043e6..949c85f 100644
> --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> @@ -1,6 +1,6 @@
> -MediaTek MT6397 Multifunction Device Driver
> +MediaTek MT6397/MT6323 Multifunction Device Driver
>  
> -MT6397 is a multifunction device with the following sub modules:
> +MT6397/MT6323 is a multifunction device with the following sub modules:
>  - Regulator
>  - RTC
>  - Audio codec
> @@ -8,14 +8,14 @@ MT6397 is a multifunction device with the following sub 
> modules:
>  - Clock
>  
>  It is interfaced to host controller using SPI interface by a proprietary 
> hardware
> -called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.
> +called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
>  See the following for pwarp node definitions:
>  Documentation/devicetree/bindings/soc/pwrap.txt
>  
>  This document describes the binding for MFD device and its sub module.
>  
>  Required properties:
> -compatible: "mediatek,mt6397"
> +compatible: "mediatek,mt6397" or "mediatek,mt6323"
>  
>  Optional subnodes:
>  
> @@ -26,6 +26,8 @@ Optional subnodes:
>   Required properties:
>   - compatible: "mediatek,mt6397-regulator"
>   see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> + - compatible: "mediatek,mt6323-regulator"
> + see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
>  - codec
>   Required properties:
>   - compatible: "mediatek,mt6397-codec"

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RFC][PATCH v3 2/4] printk: do not console_cont_flush() on every jump to again

[Petr Mladek]

On Sat 2016-01-23 17:15:11, Sergey Senozhatsky wrote:
> Every jump to `again' label will call console_cont_flush(),
> which is not really something big -- it just adds one extra
> raw_spin_lock_irqsave/raw_spin_unlock_irqrestore. However, to
> keep the previous behaviour we can call console_cont_flush()
> only when `retry' is false -- which happens once, all jumps
> to `again' label have `retry' set to true.

The patch is correct and restores the original behavior, so

Reviewed-by: Petr Mladek 

But I would personally omit it. We see the cont buffer earlier
without this patch.

Best Regards,
Petr

PS: I will review the other patches tomorrow.

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

[Marc Zyngier]

On 10/02/16 01:56, Duc Dang wrote:
> This patch makes pci-xgene-msi driver ACPI-aware and provides
> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
> 
> Signed-off-by: Duc Dang 

Another nail on the ACPI "standardization" coffin, I suppose... Oh well.

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

RE: [PATCH V1] mfd: da9062: fix missing volatile registers in the core regmap_range volatile lists

[Opensource [Steve Twiss]]

On 10 February 2016 16:56, Lee Jones wrote:

> To: Opensource [Steve Twiss]
> Cc: LINUXKERNEL; David Dajun Chen; Support Opensource
> Subject: Re: [PATCH V1] mfd: da9062: fix missing volatile registers in the 
> core
> regmap_range volatile lists
> 
> On Mon, 01 Feb 2016, Steve Twiss wrote:
> 
> > From: Steve Twiss 
> >
> > Add an updated set of registers listed in the core regmap_range volatile
> > ranges defined for the DA9062.
> >
> > These new registers contain bits that cannot be considered under the full
> > control of software. Under various conditions the hardware will set and/or
> > automatically clear bit(s) contained in these registers.
> >
> > When using a cached version of regmap, the volatility of these registers 
> > must
> > be identified otherwise the regmap operations may not ensure the registers
> > are explicitly altered.
> >
> > As well as updating the list of volatile registers, this change will fix a
> > corner case discovered in the DA9063 ONKEY which is used by the DA9062 core.
> >
> > In the ONKEY case, the CONTROL_B register is now listed as volatile in the
> > regmap_range because it contains the bit field NONKEY_LOCK. This bit can be
> > altered by hardware, in which case regmap must be notified of its ability
> > to be manpiulated outside of software control.
> >
> > Signed-off-by: Steve Twiss 
> 
> Applied, thanks.

Thanks.
Regards,
Steve

[...]

[PATCH] iwlwifi: fix erroneous return value

[Anton Protopopov]

The iwl_trans_pcie_start_fw() function may return the positive value EIO
instead of -EIO in case of error.

Signed-off-by: Anton Protopopov 
---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index d60a467..920ea9d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1034,7 +1034,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans 
*trans,
if (trans_pcie->is_down) {
IWL_WARN(trans,
 "Can't start_fw since the HW hasn't been started\n");
-   ret = EIO;
+   ret = -EIO;
goto out;
}
 
-- 
2.6.5

Re: [PATCH v2 1/7] irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity

[Marc Zyngier]

On 10/02/16 13:22, Antoine Tenart wrote:
> Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the
> affinity has been updated. When using stacked irqchips, returning
> IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips.
> 
> Signed-off-by: Antoine Tenart 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] wlcore: Fix regression in wlcore_set_partition()

[Kalle Valo]

Emil Goode  writes:

> The below commit introduced a regression causing the wlcore
> to time out and go into recovery.
>
> commit 3719c17e1816695f415dd3b4ddcb679f7dc617c8
> ("wlcore/wl18xx: fw logger over sdio")
>
> Reverting the changes regarding write of the last partition size
> brings the module back to it's functional state.
>
> Reported-by: Ross Green 
> Signed-off-by: Emil Goode 

A proper "Fixes:" line is good to have, but I can add it.

I'm planning to queue this to 4.5.

-- 
Kalle Valo

[PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables

[Torsten Duwe]

  * arch/powerpc/Makefile:
- globally use -mprofile-kernel in case it's configured,
  available and bug-free.
  * arch/powerpc/gcc-mprofile-kernel-notrace.sh:
- make sure -mprofile-kernel works and has none of the
  known bugs.
  * arch/powerpc/kernel/ftrace.c:
- error out on compile with HAVE_DYNAMIC_FTRACE_WITH_REGS
  and a buggy compiler.
  * arch/powerpc/Kconfig / kernel/trace/Kconfig:
- declare that ppc64le HAVE_MPROFILE_KERNEL and
  HAVE_DYNAMIC_FTRACE_WITH_REGS, and use it.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/Kconfig|  2 ++
 arch/powerpc/Makefile   | 17 +++
 arch/powerpc/gcc-mprofile-kernel-notrace.sh | 33 +
 arch/powerpc/kernel/ftrace.c|  5 +
 kernel/trace/Kconfig|  5 +
 5 files changed, 62 insertions(+)
 create mode 100755 arch/powerpc/gcc-mprofile-kernel-notrace.sh

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e4824fd..e5f288c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -94,8 +94,10 @@ config PPC
select OF_RESERVED_MEM
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
+   select HAVE_DYNAMIC_FTRACE_WITH_REGS if PPC64 && CPU_LITTLE_ENDIAN
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
+   select HAVE_MPROFILE_KERNEL if PPC64 && CPU_LITTLE_ENDIAN
select SYSCTL_EXCEPTION_TRACE
select ARCH_WANT_OPTIONAL_GPIOLIB
select VIRT_TO_BUS if !PPC64
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 96efd82..08a3952 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -133,6 +133,23 @@ else
 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
 endif
 
+ifeq ($(CONFIG_PPC64),y)
+ifdef CONFIG_HAVE_MPROFILE_KERNEL
+
+ifdef CONFIG_DYNAMIC_FTRACE
+ifeq ($(shell $(CONFIG_SHELL) 
$(srctree)/arch/powerpc/gcc-mprofile-kernel-notrace.sh $(CC) 
-I$(srctree)/include -D__KERNEL__), y)
+CC_USING_MPROFILE_KERNEL := -mprofile-kernel
+endif
+endif
+
+ifdef CC_USING_MPROFILE_KERNEL
+CC_FLAGS_FTRACE:= -pg $(CC_USING_MPROFILE_KERNEL)
+KBUILD_CPPFLAGS+= -DCC_USING_MPROFILE_KERNEL
+endif
+
+endif
+endif
+
 CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
 CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4)
 CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5)
diff --git a/arch/powerpc/gcc-mprofile-kernel-notrace.sh 
b/arch/powerpc/gcc-mprofile-kernel-notrace.sh
new file mode 100755
index 000..68d6482
--- /dev/null
+++ b/arch/powerpc/gcc-mprofile-kernel-notrace.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+# Test whether the compile option -mprofile-kernel
+# generates profiling code ( = a call to mcount), and
+# whether a function without any global references sets
+# the TOC pointer properly at the beginning, and
+# whether the "notrace" function attribute successfully
+# suppresses the _mcount call.
+
+echo "int func() { return 0; }" | \
+$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
+grep -q "mcount"
+
+trace_result=$?
+
+echo "int func() { return 0; }" | \
+$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
+sed -n -e '/func:/,/bl _mcount/p' | grep -q TOC
+
+leaf_toc_result=$?
+
+/bin/echo -e "#include \nnotrace int func() { return 0; }" | 
\
+$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
+grep -q "mcount"
+
+notrace_result=$?
+
+if [ "$trace_result" -eq "0" -a \
+   "$leaf_toc_result" -eq "0" -a \
+   "$notrace_result" -eq "1" ]; then
+   echo y
+else
+   echo n
+fi
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index ef8b916..29b7014 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -28,6 +28,11 @@
 
 
 #ifdef CONFIG_DYNAMIC_FTRACE
+#if defined(CONFIG_DYNAMIC_FTRACE_WITH_REGS) && defined(CONFIG_PPC64) && \
+  !defined(CC_USING_MPROFILE_KERNEL)
+#error "DYNAMIC_FTRACE_WITH_REGS requires working -mprofile-kernel"
+#endif
+
 static unsigned int
 ftrace_call_replace(unsigned long ip, unsigned long addr, int link)
 {
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index e45db6b..a138f6d 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -52,6 +52,11 @@ config HAVE_FENTRY
help
  Arch supports the gcc options -pg with -mfentry
 
+config HAVE_MPROFILE_KERNEL
+   bool
+   help
+ Arch supports the gcc options -pg with -mprofile-kernel
+
 config HAVE_C_RECORDMCOUNT
bool
help
-- 
1.8.5.6

[PATCH v8 8/8] livepatch: Detect offset for the ftrace location during build

[Torsten Duwe]

From: Petr Mladek 

Livepatch works on x86_64 and s390 only when the ftrace call
is at the very beginning of the function. But PPC is different.
We need to handle TOC and save LR there before calling the
global ftrace handler.

Now, the problem is that the extra operations have different
length on PPC depending on the used gcc version. It is
4 instructions (16 bytes) before gcc-6 and only 3 instructions
(12 bytes) with gcc-6.

This patch tries to detect the offset a generic way during
build. It assumes that the offset of the ftrace location
is the same for all functions. It modifies the existing
recordmcount tool that is able to find read mcount locations
directly from the object files. It adds an option -p
to print the first found offset.

The recordmcount tool is then used in the kernel/livepatch
subdirectory to generate a header file. It defines
a constant that is used to compute the ftrace location
from the function address.

Finally, we have to enable the C implementation of the
recordmcount tool to be used on PPC and S390. It seems
to work fine there. It should be more reliable because
it reads the standardized elf structures. The old perl
implementation uses rather complex regular expressions
to parse objdump output and is therefore much more tricky.

Signed-off-by: Petr Mladek 
Signed-off-by: Torsten Duwe 
---
 arch/powerpc/Kconfig   |  1 +
 arch/s390/Kconfig  |  1 +
 kernel/livepatch/Makefile  | 13 +
 kernel/livepatch/core.c| 12 +---
 kernel/livepatch/ftrace-test.c |  6 ++
 scripts/recordmcount.c |  6 +-
 scripts/recordmcount.h | 17 +++--
 7 files changed, 50 insertions(+), 6 deletions(-)
 create mode 100644 kernel/livepatch/ftrace-test.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c7a327..a546829 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -93,6 +93,7 @@ config PPC
select OF_EARLY_FLATTREE
select OF_RESERVED_MEM
select HAVE_FTRACE_MCOUNT_RECORD
+   select HAVE_C_RECORDMCOUNT
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS if PPC64 && CPU_LITTLE_ENDIAN
select HAVE_FUNCTION_TRACER
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 3be9c83..c574bc4 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -121,6 +121,7 @@ config S390
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
select HAVE_BPF_JIT if PACK_STACK && HAVE_MARCH_Z196_FEATURES
+   select HAVE_C_RECORDMCOUNT
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
select HAVE_DEBUG_KMEMLEAK
diff --git a/kernel/livepatch/Makefile b/kernel/livepatch/Makefile
index e8780c0..65a44b6 100644
--- a/kernel/livepatch/Makefile
+++ b/kernel/livepatch/Makefile
@@ -1,3 +1,16 @@
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 
 livepatch-objs := core.o
+
+always := $(hostprogs-y) ftrace-test.o
+
+# dependencies on generated files need to be listed explicitly
+$(obj)/core.o: $(obj)/livepatch-ftrace.h
+
+quiet_cmd_livepatch-rmcount = RMCOUNT $@
+  cmd_livepatch-rmcount = $(objtree)/scripts/recordmcount -p $< > $@
+
+$(obj)/livepatch-ftrace.h: $(obj)/ftrace-test.o $(objtree)/scripts/recordmcount
+   $(call if_changed,livepatch-rmcount)
+
+targets += livepatch-ftrace.h
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index bc2c85c..864d589 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include "livepatch-ftrace.h"
+
 /**
  * struct klp_ops - structure for tracking registered ftrace ops structs
  *
@@ -312,8 +314,10 @@ static void klp_disable_func(struct klp_func *func)
return;
 
if (list_is_singular(>func_stack)) {
+   unsigned long ftrace_loc = func->old_addr + KLP_FTRACE_LOCATION;
+
WARN_ON(unregister_ftrace_function(>fops));
-   WARN_ON(ftrace_set_filter_ip(>fops, func->old_addr, 1, 0));
+   WARN_ON(ftrace_set_filter_ip(>fops, ftrace_loc, 1, 0));
 
list_del_rcu(>stack_node);
list_del(>node);
@@ -338,6 +342,8 @@ static int klp_enable_func(struct klp_func *func)
 
ops = klp_find_ops(func->old_addr);
if (!ops) {
+   unsigned long ftrace_loc = func->old_addr + KLP_FTRACE_LOCATION;
+
ops = kzalloc(sizeof(*ops), GFP_KERNEL);
if (!ops)
return -ENOMEM;
@@ -352,7 +358,7 @@ static int klp_enable_func(struct klp_func *func)
INIT_LIST_HEAD(>func_stack);
list_add_rcu(>stack_node, >func_stack);
 
-   ret = ftrace_set_filter_ip(>fops, func->old_addr, 0, 0);
+   ret = ftrace_set_filter_ip(>fops, ftrace_loc, 0, 0);
if (ret) {
pr_err("failed to set ftrace filter for function '%s' 

[PATCH v8 7/8] Enable LIVEPATCH to be configured on ppc64le and add livepatch.o if it is selected

[Torsten Duwe]

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/Kconfig | 3 +++
 arch/powerpc/kernel/Makefile | 1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e5f288c..8c7a327 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -160,6 +160,7 @@ config PPC
select ARCH_HAS_DEVMEM_IS_ALLOWED
select HAVE_ARCH_SECCOMP_FILTER
select ARCH_HAS_UBSAN_SANITIZE_ALL
+   select HAVE_LIVEPATCH if PPC64 && CPU_LITTLE_ENDIAN
 
 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
@@ -1093,3 +1094,5 @@ config PPC_LIB_RHEAP
bool
 
 source "arch/powerpc/kvm/Kconfig"
+
+source "kernel/livepatch/Kconfig"
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 44667fd..405efce 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -119,6 +119,7 @@ obj-$(CONFIG_DYNAMIC_FTRACE)+= ftrace.o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)  += ftrace.o
 obj-$(CONFIG_TRACING)  += trace_clock.o
+obj-$(CONFIG_LIVEPATCH)+= livepatch.o
 
 ifneq ($(CONFIG_PPC_INDIRECT_PIO),y)
 obj-y  += iomap.o
-- 
1.8.5.6

[PATCH v8 6/8] Implement kernel live patching for ppc64le (ABIv2)

[Torsten Duwe]

  * create the appropriate files+functions
arch/powerpc/include/asm/livepatch.h
klp_check_compiler_support,
klp_arch_set_pc
arch/powerpc/kernel/livepatch.c with a stub for
klp_write_module_reloc
This is architecture-independent work in progress.
  * introduce a fixup in arch/powerpc/kernel/entry_64.S
for local calls that are becoming global due to live patching.
And of course do the main KLP thing: return to a maybe different
address, possibly altered by the live patching ftrace op.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/include/asm/livepatch.h | 45 +++
 arch/powerpc/kernel/entry_64.S   | 51 +---
 arch/powerpc/kernel/livepatch.c  | 38 +++
 3 files changed, 130 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/include/asm/livepatch.h
 create mode 100644 arch/powerpc/kernel/livepatch.c

diff --git a/arch/powerpc/include/asm/livepatch.h 
b/arch/powerpc/include/asm/livepatch.h
new file mode 100644
index 000..44e8a2d
--- /dev/null
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -0,0 +1,45 @@
+/*
+ * livepatch.h - powerpc-specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2015 SUSE
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+#ifndef _ASM_POWERPC64_LIVEPATCH_H
+#define _ASM_POWERPC64_LIVEPATCH_H
+
+#include 
+#include 
+
+#ifdef CONFIG_LIVEPATCH
+static inline int klp_check_compiler_support(void)
+{
+#if !defined(_CALL_ELF) || _CALL_ELF != 2 || !defined(CC_USING_MPROFILE_KERNEL)
+   return 1;
+#endif
+   return 0;
+}
+
+extern int klp_write_module_reloc(struct module *mod, unsigned long type,
+  unsigned long loc, unsigned long value);
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+   regs->nip = ip;
+}
+#else
+#error Live patching support is disabled; check CONFIG_LIVEPATCH
+#endif
+
+#endif /* _ASM_POWERPC64_LIVEPATCH_H */
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index c063564..52c7a15 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1202,6 +1202,9 @@ _GLOBAL(ftrace_caller)
mflrr3
std r3, _NIP(r1)
std r3, 16(r1)
+#ifdef CONFIG_LIVEPATCH
+   mr  r14,r3  /* remember old NIP */
+#endif
subir3, r3, MCOUNT_INSN_SIZE
mfmsr   r4
std r4, _MSR(r1)
@@ -1218,7 +1221,10 @@ ftrace_call:
nop
 
ld  r3, _NIP(r1)
-   mtlrr3
+   mtctr   r3  /* prepare to jump there */
+#ifdef CONFIG_LIVEPATCH
+   cmpdr14,r3  /* has NIP been altered? */
+#endif
 
REST_8GPRS(0,r1)
REST_8GPRS(8,r1)
@@ -1231,6 +1237,27 @@ ftrace_call:
mtlrr12
mr  r2,r0   /* restore callee's TOC */
 
+#ifdef CONFIG_LIVEPATCH
+   beq+4f  /* likely(old_NIP == new_NIP) */
+
+   /* For a local call, restore this TOC after calling the patch function.
+* For a global call, it does not matter what we restore here,
+* since the global caller does its own restore right afterwards,
+* anyway. Just insert a KLP_return_helper frame in any case,
+* so a patch function can always count on the changed stack offsets.
+*/
+   stdur1,-32(r1)  /* open new mini stack frame */
+   std r0,24(r1)   /* save TOC now, unconditionally. */
+   bl  5f
+5: mflrr12
+   addir12,r12,(KLP_return_helper+4-.)@l
+   std r12,LRSAVE(r1)
+   mtlrr12
+   mfctr   r12 /* allow for TOC calculation in newfunc */
+   bctr
+4:
+#endif
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
stdur1, -112(r1)
 .globl ftrace_graph_call
@@ -1240,15 +1267,31 @@ _GLOBAL(ftrace_graph_stub)
addir1, r1, 112
 #endif
 
-   mflrr0  /* move this LR to CTR */
-   mtctr   r0
-
ld  r0,LRSAVE(r1)   /* restore callee's lr at _mcount site */
mtlrr0
bctr/* jump after _mcount site */
 #endif /* CC_USING_MPROFILE_KERNEL */
 _GLOBAL(ftrace_stub)
blr
+
+#ifdef CONFIG_LIVEPATCH
+/* Helper function for local calls that are becoming global
+   due to live patching.
+   We can't 

Re: [GIT PULL] bcm2835 DT changes for 4.6

[Martin Sperl]

> On 09.02.2016, at 01:32, Eric Anholt  wrote:
> 
> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
> We've got more DT patches that are going to happen for new boards,
> too, but they're still getting polished.
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>  g...@github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
> 
> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
> 
>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. 
> (2016-02-02 20:02:45 -0800)
> 
> 
> This pull request covers mostly DT changes that didn't make it into
> 4.5 because required header files went through other trees.
> 
> 
> Alexander Aring (1):
>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
> 
> Lubomir Rintel (1):
>  ARM: bcm2835: dt: Add Raspberry Pi Model A
> 
> Martin Sperl (2):
>  ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>  ARM: bcm2835: follow dt uart node-naming convention

Do you want me to resend a rebased version of:
 ARM: bcm2835: add bcm2835-aux-uart support to default DT

The corresponding driver has been added to tty/tty-next.

Thanks,
Martin

Re: [PATCH v5 RESEND 2/5] ARM: sa1111: ensure no negative value gets returned on positive match

[Ulf Hansson]

On 10 February 2016 at 11:47, Marek Szyprowski  wrote:
> This patch ensures that existing bus match callbacks don't return
> negative values (which might be interpreted as potential errors in the
> future) in case of positive match.
>
> Signed-off-by: Marek Szyprowski 

FYI:
This one has actually been acked by Russell.
https://lkml.org/lkml/2015/12/23/111

Kind regards
Uffe

> ---
>  arch/arm/common/sa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
> index 3d22494..fb0a0a4 100644
> --- a/arch/arm/common/sa.c
> +++ b/arch/arm/common/sa.c
> @@ -1290,7 +1290,7 @@ static int sa_match(struct device *_dev, struct 
> device_driver *_drv)
> struct sa_dev *dev = SA_DEV(_dev);
> struct sa_driver *drv = SA_DRV(_drv);
>
> -   return dev->devid & drv->devid;
> +   return !!(dev->devid & drv->devid);
>  }
>
>  static int sa_bus_suspend(struct device *dev, pm_message_t state)
> --
> 1.9.2
>

Re: [RFC][PATCH v3 1/4] printk: move can_use_console out of console_trylock_for_printk

[Petr Mladek]

On Sat 2016-01-23 17:15:10, Sergey Senozhatsky wrote:
> This patch moves can_use_console() check out of
> console_trylock_for_printk(). Instead it calls it in
> console_unlock(), so now console_lock()/console_unlock() are
> also 'protected' by can_use_console().
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  kernel/printk/printk.c | 86 
> --
>  1 file changed, 42 insertions(+), 44 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 7ebcfea..c39232a 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1519,21 +1492,7 @@ static inline int can_use_console(unsigned int cpu)
>   */
>  static int console_trylock_for_printk(void)
>  {
> - unsigned int cpu = smp_processor_id();
> -
> - if (!console_trylock())
> - return 0;
> - /*
> -  * If we can't use the console, we need to release the console
> -  * semaphore by hand to avoid flushing the buffer. We need to hold the
> -  * console semaphore in order to do this test safely.
> -  */
> - if (!can_use_console(cpu)) {
> - console_locked = 0;
> - up_console_sem();
> - return 0;
> - }
> - return 1;
> + return console_trylock();
>  }

I would personally remove console_trylock_for_printk() already in this
patch. I mean to fold the 3rd patch into this one.

>  int printk_delay_msec __read_mostly;

> @@ -2247,9 +2233,21 @@ void console_unlock(void)
>   do_cond_resched = console_may_schedule;
>   console_may_schedule = 0;
>  
> +again:
> + /*
> +  * We released the console_sem lock, so we need to recheck if
> +  * cpu is online and (if not) is there at least one CON_ANYTIME
> +  * console.
> +  */
> + if (!can_use_console()) {
> + console_locked = 0;
> + up_console_sem();
> + return;
> + }

This is a bug fix and a nice clean up together.

Reviewed-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH v2 14/16] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver

[Lee Jones]

On Mon, 30 Nov 2015, Andy Shevchenko wrote:

> From: Mika Westerberg 
> 
> Intel Skylake the LPSS I2C pad circuit has internal delays that require
> programming non-zero SDA hold time for the I2C host controller. If this is
> not done communication to slave devices may fail with arbitration lost
> errors like the one seen below taken from Lenovo Yoga 900:
> 
>   i2c_hid i2c-SYNA2B29:00: Fetching the HID descriptor
>   i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=20 00
>   i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
> 
> To fix this we follow what the Windows driver is doing and pass the default
> SDA hold time of 230 ns to all Intel Skylake host controllers. This still
> allows the platform to override these values by passing special ACPI
> methods SSCN and FMCN.
> 
> Reported-by: Kevin Fenzi 
> Signed-off-by: Mika Westerberg 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/intel-lpss-acpi.c | 19 +--
>  drivers/mfd/intel-lpss-pci.c  | 31 +++
>  2 files changed, 40 insertions(+), 10 deletions(-)

Seems fine in principle.

Acked-by: Lee Jones 

> diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
> index b6fd904..06f00d6 100644
> --- a/drivers/mfd/intel-lpss-acpi.c
> +++ b/drivers/mfd/intel-lpss-acpi.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "intel-lpss.h"
>  
> @@ -25,6 +26,20 @@ static const struct intel_lpss_platform_info spt_info = {
>   .clk_rate = 12000,
>  };
>  
> +static struct property_entry spt_i2c_properties[] = {
> + PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
> + { },
> +};
> +
> +static struct property_set spt_i2c_pset = {
> + .properties = spt_i2c_properties,
> +};
> +
> +static const struct intel_lpss_platform_info spt_i2c_info = {
> + .clk_rate = 12000,
> + .pset = _i2c_pset,
> +};
> +
>  static const struct intel_lpss_platform_info bxt_info = {
>   .clk_rate = 1,
>  };
> @@ -35,8 +50,8 @@ static const struct intel_lpss_platform_info bxt_i2c_info = 
> {
>  
>  static const struct acpi_device_id intel_lpss_acpi_ids[] = {
>   /* SPT */
> - { "INT3446", (kernel_ulong_t)_info },
> - { "INT3447", (kernel_ulong_t)_info },
> + { "INT3446", (kernel_ulong_t)_i2c_info },
> + { "INT3447", (kernel_ulong_t)_i2c_info },
>   /* BXT */
>   { "80860AAC", (kernel_ulong_t)_i2c_info },
>   { "80860ABC", (kernel_ulong_t)_info },
> diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
> index 5bfdfcc..a677480 100644
> --- a/drivers/mfd/intel-lpss-pci.c
> +++ b/drivers/mfd/intel-lpss-pci.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "intel-lpss.h"
>  
> @@ -65,6 +66,20 @@ static const struct intel_lpss_platform_info spt_info = {
>   .clk_rate = 12000,
>  };
>  
> +static struct property_entry spt_i2c_properties[] = {
> + PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
> + { },
> +};
> +
> +static struct property_set spt_i2c_pset = {
> + .properties = spt_i2c_properties,
> +};
> +
> +static const struct intel_lpss_platform_info spt_i2c_info = {
> + .clk_rate = 12000,
> + .pset = _i2c_pset,
> +};
> +
>  static const struct intel_lpss_platform_info spt_uart_info = {
>   .clk_rate = 12000,
>   .clk_con_id = "baudclk",
> @@ -121,20 +136,20 @@ static const struct pci_device_id intel_lpss_pci_ids[] 
> = {
>   { PCI_VDEVICE(INTEL, 0x9d28), (kernel_ulong_t)_uart_info },
>   { PCI_VDEVICE(INTEL, 0x9d29), (kernel_ulong_t)_info },
>   { PCI_VDEVICE(INTEL, 0x9d2a), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)_info },
> + { PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)_i2c_info },
> + { PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)_i2c_info },
> + { PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)_i2c_info },
> + { PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)_i2c_info },
> + { PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)_i2c_info },
> + { PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)_i2c_info },
>   { PCI_VDEVICE(INTEL, 0x9d66), (kernel_ulong_t)_uart_info },
>   /* SPT-H */
>   { PCI_VDEVICE(INTEL, 0xa127), (kernel_ulong_t)_uart_info },
>   { PCI_VDEVICE(INTEL, 0xa128), (kernel_ulong_t)_uart_info },
>   { PCI_VDEVICE(INTEL, 0xa129), (kernel_ulong_t)_info },
>   { PCI_VDEVICE(INTEL, 0xa12a), (kernel_ulong_t)_info },
> - { PCI_VDEVICE(INTEL, 0xa160), 

Re: [PATCH] let kernfs_name_locked & kernfs_name return size_t

[Greg KH]

On Wed, Feb 10, 2016 at 05:18:59PM +0100, Christian Brauner wrote:
> They return the length of kn->parent or kn->name and should be aligned with
> kernfs_path_len which also returns size_t.
> 
> Signed-off-by: Christian Brauner 
> ---
>  fs/kernfs/dir.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
> index 742bf4a..a3553b8 100644
> --- a/fs/kernfs/dir.c
> +++ b/fs/kernfs/dir.c
> @@ -39,7 +39,7 @@ static bool kernfs_lockdep(struct kernfs_node *kn)
>  #endif
>  }
>  
> -static int kernfs_name_locked(struct kernfs_node *kn, char *buf, size_t 
> buflen)
> +static size_t kernfs_name_locked(struct kernfs_node *kn, char *buf, size_t 
> buflen)
>  {
>   return strlcpy(buf, kn->parent ? kn->name : "/", buflen);
>  }
> @@ -80,7 +80,7 @@ static char * __must_check kernfs_path_locked(struct 
> kernfs_node *kn, char *buf,
>   *
>   * This function can be called from any context.
>   */
> -int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen)
> +size_t kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen)
>  {
>   unsigned long flags;
>   int ret;

Now if only you had test built this patch :(

Please be more careful, it just makes maintainers grumpy and annoyed
when you do that...