make[2]: *** No rule to make target 'alchemy/devboards/'.

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: cf2a5e0bb4c66e8c43caf9f1be93a1bd7fd07b17 MIPS: Support generating 
Flattened Image Trees (.itb)
date:   2 weeks ago
config: mips-db1xxx_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout cf2a5e0bb4c66e8c43caf9f1be93a1bd7fd07b17
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'alchemy/devboards/'.

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


.config.gz
Description: application/gzip

make[2]: *** No rule to make target 'alchemy/devboards/'.

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: cf2a5e0bb4c66e8c43caf9f1be93a1bd7fd07b17 MIPS: Support generating 
Flattened Image Trees (.itb)
date:   2 weeks ago
config: mips-db1xxx_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout cf2a5e0bb4c66e8c43caf9f1be93a1bd7fd07b17
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'alchemy/devboards/'.

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


.config.gz
Description: application/gzip

Re: [PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[Julia Lawall]

On Sat, 22 Oct 2016, SF Markus Elfring wrote:

> >> @@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, 
> >> void *data)
> >>int cpu;
> >>
> >>cpu = *(loff_t *) data;
> >> -
> >> -  if (!cpu) {
> >> +  if (!cpu)
> >>seq_printf(file,
> >> - "# cpu ptc_l newrid ptc_flushes nodes_flushed 
> >> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 
> >> ipi_fluches ipi_nsec\n");
> >> -  seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
> >> sn2_flush_opt);
> >> -  }
> >> + "# cpu ptc_l newrid ptc_flushes nodes_flushed 
> >> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 
> >> ipi_fluches ipi_nsec\n"
> >> + "# ptctest %d, flushopt %d\n",
> >> + sn2_ptctest, sn2_flush_opt);
> >>
> >>if (cpu < nr_cpu_ids && cpu_online(cpu)) {
> >>stat = _cpu(ptcstats, cpu);
> >
> > Please think more.
> >
> > printf has to inspect character by character looking for
> > a vsprintf % character and 0 termination.
> >
> > seq_puts does a strlen then memcpy.
>
> Would you prefer to use this function also at this source code place?

I think that he is expecting that you will figure out the answer by
yourself.

julia

Re: [PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[Julia Lawall]

On Sat, 22 Oct 2016, SF Markus Elfring wrote:

> >> @@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, 
> >> void *data)
> >>int cpu;
> >>
> >>cpu = *(loff_t *) data;
> >> -
> >> -  if (!cpu) {
> >> +  if (!cpu)
> >>seq_printf(file,
> >> - "# cpu ptc_l newrid ptc_flushes nodes_flushed 
> >> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 
> >> ipi_fluches ipi_nsec\n");
> >> -  seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
> >> sn2_flush_opt);
> >> -  }
> >> + "# cpu ptc_l newrid ptc_flushes nodes_flushed 
> >> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 
> >> ipi_fluches ipi_nsec\n"
> >> + "# ptctest %d, flushopt %d\n",
> >> + sn2_ptctest, sn2_flush_opt);
> >>
> >>if (cpu < nr_cpu_ids && cpu_online(cpu)) {
> >>stat = _cpu(ptcstats, cpu);
> >
> > Please think more.
> >
> > printf has to inspect character by character looking for
> > a vsprintf % character and 0 termination.
> >
> > seq_puts does a strlen then memcpy.
>
> Would you prefer to use this function also at this source code place?

I think that he is expecting that you will figure out the answer by
yourself.

julia

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   12 days ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   12 days ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

arch/mips/kernel/mips-cpc.c:47: undefined reference to `mips_cpc_default_phys_base'

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: eed0eabd12ef061821cbfa20d903476e07645320 MIPS: generic: Introduce 
generic DT-based board support
date:   2 weeks ago
config: mips-generic_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout eed0eabd12ef061821cbfa20d903476e07645320
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   arch/mips/built-in.o: In function `mips_cpc_phys_base':
>> arch/mips/kernel/mips-cpc.c:47: undefined reference to 
>> `mips_cpc_default_phys_base'

vim +47 arch/mips/kernel/mips-cpc.c

8dedde6b Bjorn Helgaas   2015-07-12  31  static phys_addr_t 
mips_cpc_phys_base(void)
9c38cf44 Paul Burton 2014-01-15  32  {
391057d9 Markos Chandras 2015-07-09  33 unsigned long cpc_base;
9c38cf44 Paul Burton 2014-01-15  34  
9c38cf44 Paul Burton 2014-01-15  35 if (!mips_cm_present())
9c38cf44 Paul Burton 2014-01-15  36 return 0;
9c38cf44 Paul Burton 2014-01-15  37  
9c38cf44 Paul Burton 2014-01-15  38 if (!(read_gcr_cpc_status() & 
CM_GCR_CPC_STATUS_EX_MSK))
9c38cf44 Paul Burton 2014-01-15  39 return 0;
9c38cf44 Paul Burton 2014-01-15  40  
9c38cf44 Paul Burton 2014-01-15  41 /* If the CPC is already 
enabled, leave it so */
9c38cf44 Paul Burton 2014-01-15  42 cpc_base = read_gcr_cpc_base();
9c38cf44 Paul Burton 2014-01-15  43 if (cpc_base & 
CM_GCR_CPC_BASE_CPCEN_MSK)
9c38cf44 Paul Burton 2014-01-15  44 return cpc_base & 
CM_GCR_CPC_BASE_CPCBASE_MSK;
9c38cf44 Paul Burton 2014-01-15  45  
9c38cf44 Paul Burton 2014-01-15  46 /* Otherwise, give it the 
default address & enable it */
9c38cf44 Paul Burton 2014-01-15 @47 cpc_base = 
mips_cpc_default_phys_base();
9c38cf44 Paul Burton 2014-01-15  48 write_gcr_cpc_base(cpc_base | 
CM_GCR_CPC_BASE_CPCEN_MSK);
9c38cf44 Paul Burton 2014-01-15  49 return cpc_base;
9c38cf44 Paul Burton 2014-01-15  50  }
9c38cf44 Paul Burton 2014-01-15  51  
9c38cf44 Paul Burton 2014-01-15  52  int mips_cpc_probe(void)
9c38cf44 Paul Burton 2014-01-15  53  {
15d45cce Ralf Baechle2014-11-22  54 phys_addr_t addr;
6b89d22e Matt Redfearn   2016-09-07  55 unsigned int cpu;

:: The code at line 47 was first introduced by commit
:: 9c38cf44712af95a5ec3937d63faaea9b43eab9a MIPS: Add CPC probe, access 
functions

:: TO: Paul Burton 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

arch/mips/kernel/mips-cpc.c:47: undefined reference to `mips_cpc_default_phys_base'

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: eed0eabd12ef061821cbfa20d903476e07645320 MIPS: generic: Introduce 
generic DT-based board support
date:   2 weeks ago
config: mips-generic_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout eed0eabd12ef061821cbfa20d903476e07645320
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   arch/mips/built-in.o: In function `mips_cpc_phys_base':
>> arch/mips/kernel/mips-cpc.c:47: undefined reference to 
>> `mips_cpc_default_phys_base'

vim +47 arch/mips/kernel/mips-cpc.c

8dedde6b Bjorn Helgaas   2015-07-12  31  static phys_addr_t 
mips_cpc_phys_base(void)
9c38cf44 Paul Burton 2014-01-15  32  {
391057d9 Markos Chandras 2015-07-09  33 unsigned long cpc_base;
9c38cf44 Paul Burton 2014-01-15  34  
9c38cf44 Paul Burton 2014-01-15  35 if (!mips_cm_present())
9c38cf44 Paul Burton 2014-01-15  36 return 0;
9c38cf44 Paul Burton 2014-01-15  37  
9c38cf44 Paul Burton 2014-01-15  38 if (!(read_gcr_cpc_status() & 
CM_GCR_CPC_STATUS_EX_MSK))
9c38cf44 Paul Burton 2014-01-15  39 return 0;
9c38cf44 Paul Burton 2014-01-15  40  
9c38cf44 Paul Burton 2014-01-15  41 /* If the CPC is already 
enabled, leave it so */
9c38cf44 Paul Burton 2014-01-15  42 cpc_base = read_gcr_cpc_base();
9c38cf44 Paul Burton 2014-01-15  43 if (cpc_base & 
CM_GCR_CPC_BASE_CPCEN_MSK)
9c38cf44 Paul Burton 2014-01-15  44 return cpc_base & 
CM_GCR_CPC_BASE_CPCBASE_MSK;
9c38cf44 Paul Burton 2014-01-15  45  
9c38cf44 Paul Burton 2014-01-15  46 /* Otherwise, give it the 
default address & enable it */
9c38cf44 Paul Burton 2014-01-15 @47 cpc_base = 
mips_cpc_default_phys_base();
9c38cf44 Paul Burton 2014-01-15  48 write_gcr_cpc_base(cpc_base | 
CM_GCR_CPC_BASE_CPCEN_MSK);
9c38cf44 Paul Burton 2014-01-15  49 return cpc_base;
9c38cf44 Paul Burton 2014-01-15  50  }
9c38cf44 Paul Burton 2014-01-15  51  
9c38cf44 Paul Burton 2014-01-15  52  int mips_cpc_probe(void)
9c38cf44 Paul Burton 2014-01-15  53  {
15d45cce Ralf Baechle2014-11-22  54 phys_addr_t addr;
6b89d22e Matt Redfearn   2016-09-07  55 unsigned int cpu;

:: The code at line 47 was first introduced by commit
:: 9c38cf44712af95a5ec3937d63faaea9b43eab9a MIPS: Add CPC probe, access 
functions

:: TO: Paul Burton 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

Re: [V4,2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

[Jonathan Liu]

On 20 October 2016 at 09:21, Sinan Kaya  wrote:
> The SCI penalize function was removed in two steps (first refactor
> and then remove) and these changes are reverted here in one go.
>
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. That change is partially
> reverted here, specifically for the SCI IRQ alone.
>
> The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> penalty API with penalty calculation carried out dynamically and based
> on the acpi_gbl_FADT.sci_interrupt value.
>
> However, that new algorithm relies on the accurate setting of IRQ
> types and that doesn't happen early enough on some platforms which
> leads to incorrect penalty assignments for PCI IRQs.  In those cases,
> irq_get_trigger_type() returns incorrect values for the IRQs in
> question, because they have not been registered yet by the time the
> penalties are calculated.
>
> To fix this problem, we only need to fix the penalty for the SCI interrupt.
> It seems better to add a single "sci_penalty" variable, set it to
> PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> otherwise, and add "sci_penalty" in when appropriate.  That should fix it
> for *any* SCI IRQ, not just those less than 256, and we don't have to add
> these extra penalty table entries that are all unused (except possibly for
> one entry if we have an SCI in the 16-255 range).
>
> For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> penalize function") completely to restore the correct behavior.
>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya 
> Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
> ---
>  arch/x86/kernel/acpi/boot.c |  1 +
>  drivers/acpi/pci_link.c | 30 +++---
>  include/linux/acpi.h|  1 +
>  3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 
> polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> +   acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
>  * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 4f37938..294b190 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -87,6 +87,7 @@ struct acpi_pci_link {
>
>  static LIST_HEAD(acpi_link_list);
>  static DEFINE_MUTEX(acpi_link_lock);
> +static int sci_irq = -1, sci_penalty;
>
>  /* --
>  PCI Link Device Management
> @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
>  {
> int penalty = 0;
>
> -   /*
> -   * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> -   * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> -   * use for PCI IRQs.
> -   */
> -   if (irq == acpi_gbl_FADT.sci_interrupt) {
> -   u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> -   if (type != IRQ_TYPE_LEVEL_LOW)
> -   penalty += PIRQ_PENALTY_ISA_ALWAYS;
> -   else
> -   penalty += PIRQ_PENALTY_PCI_USING;
> -   }
> +   if (irq == sci_irq)
> +   penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> return penalty + acpi_isa_irq_penalty[irq];
>
> -   penalty += acpi_irq_pci_sharing_penalty(irq);
> -   return penalty;
> +   return penalty + acpi_irq_pci_sharing_penalty(irq);
>  }
>
>  int __init acpi_irq_penalty_init(void)
> @@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
>  }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> +   sci_irq = irq;
> +
> +   if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
> +   polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
> +   sci_penalty = PIRQ_PENALTY_PCI_USING;
> +   else
> +   sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
> +}
> +
>  /*
>   * Over-ride default table to reserve additional IRQs for use by ISA
>   * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ 

Re: [V4,3/3] Revert "ACPI,PCI,IRQ: separate ISA penalty calculation"

[Jonathan Liu]

On 20 October 2016 at 09:21, Sinan Kaya  wrote:
> This reverts commit f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty
> calculation") and commit 487cf917ed0d ("revert "ACPI, PCI, IRQ: remove
> redundant code in acpi_irq_penalty_init()"").
>
> Now that we understand the real issue (SCI and ISA penalty getting
> calculated before ACPI start), there is no need for special handling
> for ISA interrupts.
>
> Let's try to simplify the code one more time to share code.
>
> Signed-off-by: Sinan Kaya 
> ---
>  arch/x86/pci/acpi.c |  1 -
>  drivers/acpi/pci_link.c | 44 +---
>  include/acpi/acpi_drivers.h |  1 -
>  3 files changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 3cd6983..b2a4e2a 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -396,7 +396,6 @@ int __init pci_acpi_init(void)
> return -ENODEV;
>
> printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
> -   acpi_irq_penalty_init();
> pcibios_enable_irq = acpi_pci_irq_enable;
> pcibios_disable_irq = acpi_pci_irq_disable;
> x86_init.pci.init_irq = x86_init_noop;
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 294b190..dd14d78 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -478,7 +478,8 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>  * If a link is active, penalize its IRQ heavily
>  * so we try to choose a different IRQ.
>  */
> -   if (link->irq.active && link->irq.active == irq)
> +   if ((link->irq.active && link->irq.active == irq) &&
> +   (link->irq.initialized == 1))
> penalty += PIRQ_PENALTY_PCI_USING;
>
> /*
> @@ -501,45 +502,10 @@ static int acpi_irq_get_penalty(int irq)
> penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> -   return penalty + acpi_isa_irq_penalty[irq];
> +   penalty += acpi_isa_irq_penalty[irq];
>
> -   return penalty + acpi_irq_pci_sharing_penalty(irq);
> -}
> -
> -int __init acpi_irq_penalty_init(void)
> -{
> -   struct acpi_pci_link *link;
> -   int i;
> -
> -   /*
> -* Update penalties to facilitate IRQ balancing.
> -*/
> -   list_for_each_entry(link, _link_list, list) {
> -
> -   /*
> -* reflect the possible and active irqs in the penalty table 
> --
> -* useful for breaking ties.
> -*/
> -   if (link->irq.possible_count) {
> -   int penalty =
> -   PIRQ_PENALTY_PCI_POSSIBLE /
> -   link->irq.possible_count;
> -
> -   for (i = 0; i < link->irq.possible_count; i++) {
> -   if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> -   acpi_isa_irq_penalty[link->irq.
> -possible[i]] +=
> -   penalty;
> -   }
> -
> -   } else if (link->irq.active &&
> -   (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> -   acpi_isa_irq_penalty[link->irq.active] +=
> -   PIRQ_PENALTY_PCI_POSSIBLE;
> -   }
> -   }
> -
> -   return 0;
> +   penalty += acpi_irq_pci_sharing_penalty(irq);
> +   return penalty;
>  }
>
>  static int acpi_irq_balance = -1;  /* 0: static, 1: balance */
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index 29c6912..797ae2e 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -78,7 +78,6 @@
>
>  /* ACPI PCI Interrupt Link (pci_link.c) */
>
> -int acpi_irq_penalty_init(void);
>  int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int 
> *triggering,
>int *polarity, char **name);
>  int acpi_pci_link_free_irq(acpi_handle handle);

This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

Tested-by: Jonathan Liu 

Re: [V4,2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

[Jonathan Liu]

On 20 October 2016 at 09:21, Sinan Kaya  wrote:
> The SCI penalize function was removed in two steps (first refactor
> and then remove) and these changes are reverted here in one go.
>
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. That change is partially
> reverted here, specifically for the SCI IRQ alone.
>
> The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> penalty API with penalty calculation carried out dynamically and based
> on the acpi_gbl_FADT.sci_interrupt value.
>
> However, that new algorithm relies on the accurate setting of IRQ
> types and that doesn't happen early enough on some platforms which
> leads to incorrect penalty assignments for PCI IRQs.  In those cases,
> irq_get_trigger_type() returns incorrect values for the IRQs in
> question, because they have not been registered yet by the time the
> penalties are calculated.
>
> To fix this problem, we only need to fix the penalty for the SCI interrupt.
> It seems better to add a single "sci_penalty" variable, set it to
> PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> otherwise, and add "sci_penalty" in when appropriate.  That should fix it
> for *any* SCI IRQ, not just those less than 256, and we don't have to add
> these extra penalty table entries that are all unused (except possibly for
> one entry if we have an SCI in the 16-255 range).
>
> For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> penalize function") completely to restore the correct behavior.
>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya 
> Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
> ---
>  arch/x86/kernel/acpi/boot.c |  1 +
>  drivers/acpi/pci_link.c | 30 +++---
>  include/linux/acpi.h|  1 +
>  3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 
> polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> +   acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
>  * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 4f37938..294b190 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -87,6 +87,7 @@ struct acpi_pci_link {
>
>  static LIST_HEAD(acpi_link_list);
>  static DEFINE_MUTEX(acpi_link_lock);
> +static int sci_irq = -1, sci_penalty;
>
>  /* --
>  PCI Link Device Management
> @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
>  {
> int penalty = 0;
>
> -   /*
> -   * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> -   * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> -   * use for PCI IRQs.
> -   */
> -   if (irq == acpi_gbl_FADT.sci_interrupt) {
> -   u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> -   if (type != IRQ_TYPE_LEVEL_LOW)
> -   penalty += PIRQ_PENALTY_ISA_ALWAYS;
> -   else
> -   penalty += PIRQ_PENALTY_PCI_USING;
> -   }
> +   if (irq == sci_irq)
> +   penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> return penalty + acpi_isa_irq_penalty[irq];
>
> -   penalty += acpi_irq_pci_sharing_penalty(irq);
> -   return penalty;
> +   return penalty + acpi_irq_pci_sharing_penalty(irq);
>  }
>
>  int __init acpi_irq_penalty_init(void)
> @@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
>  }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> +   sci_irq = irq;
> +
> +   if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
> +   polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
> +   sci_penalty = PIRQ_PENALTY_PCI_USING;
> +   else
> +   sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
> +}
> +
>  /*
>   * Over-ride default table to reserve additional IRQs for use by ISA
>   * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> 

Re: [V4,3/3] Revert "ACPI,PCI,IRQ: separate ISA penalty calculation"

[Jonathan Liu]

On 20 October 2016 at 09:21, Sinan Kaya  wrote:
> This reverts commit f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty
> calculation") and commit 487cf917ed0d ("revert "ACPI, PCI, IRQ: remove
> redundant code in acpi_irq_penalty_init()"").
>
> Now that we understand the real issue (SCI and ISA penalty getting
> calculated before ACPI start), there is no need for special handling
> for ISA interrupts.
>
> Let's try to simplify the code one more time to share code.
>
> Signed-off-by: Sinan Kaya 
> ---
>  arch/x86/pci/acpi.c |  1 -
>  drivers/acpi/pci_link.c | 44 +---
>  include/acpi/acpi_drivers.h |  1 -
>  3 files changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 3cd6983..b2a4e2a 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -396,7 +396,6 @@ int __init pci_acpi_init(void)
> return -ENODEV;
>
> printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
> -   acpi_irq_penalty_init();
> pcibios_enable_irq = acpi_pci_irq_enable;
> pcibios_disable_irq = acpi_pci_irq_disable;
> x86_init.pci.init_irq = x86_init_noop;
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 294b190..dd14d78 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -478,7 +478,8 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>  * If a link is active, penalize its IRQ heavily
>  * so we try to choose a different IRQ.
>  */
> -   if (link->irq.active && link->irq.active == irq)
> +   if ((link->irq.active && link->irq.active == irq) &&
> +   (link->irq.initialized == 1))
> penalty += PIRQ_PENALTY_PCI_USING;
>
> /*
> @@ -501,45 +502,10 @@ static int acpi_irq_get_penalty(int irq)
> penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> -   return penalty + acpi_isa_irq_penalty[irq];
> +   penalty += acpi_isa_irq_penalty[irq];
>
> -   return penalty + acpi_irq_pci_sharing_penalty(irq);
> -}
> -
> -int __init acpi_irq_penalty_init(void)
> -{
> -   struct acpi_pci_link *link;
> -   int i;
> -
> -   /*
> -* Update penalties to facilitate IRQ balancing.
> -*/
> -   list_for_each_entry(link, _link_list, list) {
> -
> -   /*
> -* reflect the possible and active irqs in the penalty table 
> --
> -* useful for breaking ties.
> -*/
> -   if (link->irq.possible_count) {
> -   int penalty =
> -   PIRQ_PENALTY_PCI_POSSIBLE /
> -   link->irq.possible_count;
> -
> -   for (i = 0; i < link->irq.possible_count; i++) {
> -   if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> -   acpi_isa_irq_penalty[link->irq.
> -possible[i]] +=
> -   penalty;
> -   }
> -
> -   } else if (link->irq.active &&
> -   (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> -   acpi_isa_irq_penalty[link->irq.active] +=
> -   PIRQ_PENALTY_PCI_POSSIBLE;
> -   }
> -   }
> -
> -   return 0;
> +   penalty += acpi_irq_pci_sharing_penalty(irq);
> +   return penalty;
>  }
>
>  static int acpi_irq_balance = -1;  /* 0: static, 1: balance */
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index 29c6912..797ae2e 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -78,7 +78,6 @@
>
>  /* ACPI PCI Interrupt Link (pci_link.c) */
>
> -int acpi_irq_penalty_init(void);
>  int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int 
> *triggering,
>int *polarity, char **name);
>  int acpi_pci_link_free_irq(acpi_handle handle);

This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

Tested-by: Jonathan Liu 

Re: [V4, 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages

[Jonathan Liu]

On 20 October 2016 at 09:21, Sinan Kaya  wrote:
> The penalty determination of ISA IRQ goes through 4 paths.
> 1. assign PCI_USING during power up via acpi_irq_penalty_init.
> 2. update the penalty with acpi_penalize_isa_irq function based on the
> active parameter.
> 3. kernel command line penalty update via acpi_irq_penalty_update function.
> 4. increment the penalty as USING right after the IRQ is assign to PCI.
>
> acpi_penalize_isa_irq and acpi_irq_penalty_update functions get called
> before the ACPI subsystem is started.
>
> These API need to bypass the acpi_irq_get_penalty function.
>
> Signed-off-by: Sinan Kaya 
> ---
>  drivers/acpi/pci_link.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..4f37938 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int 
> used)
> continue;
>
> if (used)
> -   new_penalty = acpi_irq_get_penalty(irq) +
> +   new_penalty = acpi_isa_irq_penalty[irq] +
> PIRQ_PENALTY_ISA_USED;
> else
> new_penalty = 0;
> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int 
> used)
>  void acpi_penalize_isa_irq(int irq, int active)
>  {
> if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> -   acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> +   acpi_isa_irq_penalty[irq] = acpi_isa_irq_penalty[irq] +
>   (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
>  }
>

This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

Tested-by: Jonathan Liu 

Re: [V4, 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages

[Jonathan Liu]

On 20 October 2016 at 09:21, Sinan Kaya  wrote:
> The penalty determination of ISA IRQ goes through 4 paths.
> 1. assign PCI_USING during power up via acpi_irq_penalty_init.
> 2. update the penalty with acpi_penalize_isa_irq function based on the
> active parameter.
> 3. kernel command line penalty update via acpi_irq_penalty_update function.
> 4. increment the penalty as USING right after the IRQ is assign to PCI.
>
> acpi_penalize_isa_irq and acpi_irq_penalty_update functions get called
> before the ACPI subsystem is started.
>
> These API need to bypass the acpi_irq_get_penalty function.
>
> Signed-off-by: Sinan Kaya 
> ---
>  drivers/acpi/pci_link.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..4f37938 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int 
> used)
> continue;
>
> if (used)
> -   new_penalty = acpi_irq_get_penalty(irq) +
> +   new_penalty = acpi_isa_irq_penalty[irq] +
> PIRQ_PENALTY_ISA_USED;
> else
> new_penalty = 0;
> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int 
> used)
>  void acpi_penalize_isa_irq(int irq, int active)
>  {
> if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> -   acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> +   acpi_isa_irq_penalty[irq] = acpi_isa_irq_penalty[irq] +
>   (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
>  }
>

This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

Tested-by: Jonathan Liu 

[PATCH v2 2/7] iio: mcp4531: provide range of available raw values

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 drivers/iio/potentiometer/mcp4531.c | 104 +---
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/drivers/iio/potentiometer/mcp4531.c 
b/drivers/iio/potentiometer/mcp4531.c
index 13b6ae2fcf7b..0d1bcf89ae17 100644
--- a/drivers/iio/potentiometer/mcp4531.c
+++ b/drivers/iio/potentiometer/mcp4531.c
@@ -38,7 +38,7 @@
 
 struct mcp4531_cfg {
int wipers;
-   int max_pos;
+   int avail[3];
int kohms;
 };
 
@@ -78,38 +78,38 @@ enum mcp4531_type {
 };
 
 static const struct mcp4531_cfg mcp4531_cfg[] = {
-   [MCP453x_502] = { .wipers = 1, .max_pos = 128, .kohms =   5, },
-   [MCP453x_103] = { .wipers = 1, .max_pos = 128, .kohms =  10, },
-   [MCP453x_503] = { .wipers = 1, .max_pos = 128, .kohms =  50, },
-   [MCP453x_104] = { .wipers = 1, .max_pos = 128, .kohms = 100, },
-   [MCP454x_502] = { .wipers = 1, .max_pos = 128, .kohms =   5, },
-   [MCP454x_103] = { .wipers = 1, .max_pos = 128, .kohms =  10, },
-   [MCP454x_503] = { .wipers = 1, .max_pos = 128, .kohms =  50, },
-   [MCP454x_104] = { .wipers = 1, .max_pos = 128, .kohms = 100, },
-   [MCP455x_502] = { .wipers = 1, .max_pos = 256, .kohms =   5, },
-   [MCP455x_103] = { .wipers = 1, .max_pos = 256, .kohms =  10, },
-   [MCP455x_503] = { .wipers = 1, .max_pos = 256, .kohms =  50, },
-   [MCP455x_104] = { .wipers = 1, .max_pos = 256, .kohms = 100, },
-   [MCP456x_502] = { .wipers = 1, .max_pos = 256, .kohms =   5, },
-   [MCP456x_103] = { .wipers = 1, .max_pos = 256, .kohms =  10, },
-   [MCP456x_503] = { .wipers = 1, .max_pos = 256, .kohms =  50, },
-   [MCP456x_104] = { .wipers = 1, .max_pos = 256, .kohms = 100, },
-   [MCP463x_502] = { .wipers = 2, .max_pos = 128, .kohms =   5, },
-   [MCP463x_103] = { .wipers = 2, .max_pos = 128, .kohms =  10, },
-   [MCP463x_503] = { .wipers = 2, .max_pos = 128, .kohms =  50, },
-   [MCP463x_104] = { .wipers = 2, .max_pos = 128, .kohms = 100, },
-   [MCP464x_502] = { .wipers = 2, .max_pos = 128, .kohms =   5, },
-   [MCP464x_103] = { .wipers = 2, .max_pos = 128, .kohms =  10, },
-   [MCP464x_503] = { .wipers = 2, .max_pos = 128, .kohms =  50, },
-   [MCP464x_104] = { .wipers = 2, .max_pos = 128, .kohms = 100, },
-   [MCP465x_502] = { .wipers = 2, .max_pos = 256, .kohms =   5, },
-   [MCP465x_103] = { .wipers = 2, .max_pos = 256, .kohms =  10, },
-   [MCP465x_503] = { .wipers = 2, .max_pos = 256, .kohms =  50, },
-   [MCP465x_104] = { .wipers = 2, .max_pos = 256, .kohms = 100, },
-   [MCP466x_502] = { .wipers = 2, .max_pos = 256, .kohms =   5, },
-   [MCP466x_103] = { .wipers = 2, .max_pos = 256, .kohms =  10, },
-   [MCP466x_503] = { .wipers = 2, .max_pos = 256, .kohms =  50, },
-   [MCP466x_104] = { .wipers = 2, .max_pos = 256, .kohms = 100, },
+   [MCP453x_502] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP453x_103] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP453x_503] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP453x_104] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP454x_502] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP454x_103] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP454x_503] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP454x_104] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP455x_502] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =   5, },
+   [MCP455x_103] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  10, },
+   [MCP455x_503] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  50, },
+   [MCP455x_104] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 100, },
+   [MCP456x_502] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =   5, },
+   [MCP456x_103] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  10, },
+   [MCP456x_503] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  50, },
+   [MCP456x_104] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 100, },
+   [MCP463x_502] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP463x_103] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP463x_503] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP463x_104] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP464x_502] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP464x_103] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP464x_503] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP464x_104] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP465x_502] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms =   5, },
+   [MCP465x_103] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms =  

[PATCH v2 2/7] iio: mcp4531: provide range of available raw values

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 drivers/iio/potentiometer/mcp4531.c | 104 +---
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/drivers/iio/potentiometer/mcp4531.c 
b/drivers/iio/potentiometer/mcp4531.c
index 13b6ae2fcf7b..0d1bcf89ae17 100644
--- a/drivers/iio/potentiometer/mcp4531.c
+++ b/drivers/iio/potentiometer/mcp4531.c
@@ -38,7 +38,7 @@
 
 struct mcp4531_cfg {
int wipers;
-   int max_pos;
+   int avail[3];
int kohms;
 };
 
@@ -78,38 +78,38 @@ enum mcp4531_type {
 };
 
 static const struct mcp4531_cfg mcp4531_cfg[] = {
-   [MCP453x_502] = { .wipers = 1, .max_pos = 128, .kohms =   5, },
-   [MCP453x_103] = { .wipers = 1, .max_pos = 128, .kohms =  10, },
-   [MCP453x_503] = { .wipers = 1, .max_pos = 128, .kohms =  50, },
-   [MCP453x_104] = { .wipers = 1, .max_pos = 128, .kohms = 100, },
-   [MCP454x_502] = { .wipers = 1, .max_pos = 128, .kohms =   5, },
-   [MCP454x_103] = { .wipers = 1, .max_pos = 128, .kohms =  10, },
-   [MCP454x_503] = { .wipers = 1, .max_pos = 128, .kohms =  50, },
-   [MCP454x_104] = { .wipers = 1, .max_pos = 128, .kohms = 100, },
-   [MCP455x_502] = { .wipers = 1, .max_pos = 256, .kohms =   5, },
-   [MCP455x_103] = { .wipers = 1, .max_pos = 256, .kohms =  10, },
-   [MCP455x_503] = { .wipers = 1, .max_pos = 256, .kohms =  50, },
-   [MCP455x_104] = { .wipers = 1, .max_pos = 256, .kohms = 100, },
-   [MCP456x_502] = { .wipers = 1, .max_pos = 256, .kohms =   5, },
-   [MCP456x_103] = { .wipers = 1, .max_pos = 256, .kohms =  10, },
-   [MCP456x_503] = { .wipers = 1, .max_pos = 256, .kohms =  50, },
-   [MCP456x_104] = { .wipers = 1, .max_pos = 256, .kohms = 100, },
-   [MCP463x_502] = { .wipers = 2, .max_pos = 128, .kohms =   5, },
-   [MCP463x_103] = { .wipers = 2, .max_pos = 128, .kohms =  10, },
-   [MCP463x_503] = { .wipers = 2, .max_pos = 128, .kohms =  50, },
-   [MCP463x_104] = { .wipers = 2, .max_pos = 128, .kohms = 100, },
-   [MCP464x_502] = { .wipers = 2, .max_pos = 128, .kohms =   5, },
-   [MCP464x_103] = { .wipers = 2, .max_pos = 128, .kohms =  10, },
-   [MCP464x_503] = { .wipers = 2, .max_pos = 128, .kohms =  50, },
-   [MCP464x_104] = { .wipers = 2, .max_pos = 128, .kohms = 100, },
-   [MCP465x_502] = { .wipers = 2, .max_pos = 256, .kohms =   5, },
-   [MCP465x_103] = { .wipers = 2, .max_pos = 256, .kohms =  10, },
-   [MCP465x_503] = { .wipers = 2, .max_pos = 256, .kohms =  50, },
-   [MCP465x_104] = { .wipers = 2, .max_pos = 256, .kohms = 100, },
-   [MCP466x_502] = { .wipers = 2, .max_pos = 256, .kohms =   5, },
-   [MCP466x_103] = { .wipers = 2, .max_pos = 256, .kohms =  10, },
-   [MCP466x_503] = { .wipers = 2, .max_pos = 256, .kohms =  50, },
-   [MCP466x_104] = { .wipers = 2, .max_pos = 256, .kohms = 100, },
+   [MCP453x_502] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP453x_103] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP453x_503] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP453x_104] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP454x_502] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP454x_103] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP454x_503] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP454x_104] = { .wipers = 1, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP455x_502] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =   5, },
+   [MCP455x_103] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  10, },
+   [MCP455x_503] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  50, },
+   [MCP455x_104] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 100, },
+   [MCP456x_502] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =   5, },
+   [MCP456x_103] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  10, },
+   [MCP456x_503] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms =  50, },
+   [MCP456x_104] = { .wipers = 1, .avail = { 0, 1, 256 }, .kohms = 100, },
+   [MCP463x_502] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP463x_103] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP463x_503] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP463x_104] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP464x_502] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =   5, },
+   [MCP464x_103] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  10, },
+   [MCP464x_503] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms =  50, },
+   [MCP464x_104] = { .wipers = 2, .avail = { 0, 1, 128 }, .kohms = 100, },
+   [MCP465x_502] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms =   5, },
+   [MCP465x_103] = { .wipers = 2, .avail = { 0, 1, 256 }, .kohms =  10, },
+   

[PATCH v2 7/7] iio: envelope-detector: ADC driver based on a DAC and a comparator

[Peter Rosin]

The DAC is used to find the peak level of an alternating voltage input
signal by a binary search using the output of a comparator wired to
an interrupt pin. Like so:
  _
 | \
input +-->---|+ \
 |   \
   .---. |}---.
   |   | |   /|
   |dac|-->--|- / |
   |   | |_/  |
   |   |  |
   |   |  |
   |irq|--<---'
   |   |
   '---'

Signed-off-by: Peter Rosin 
---
 .../testing/sysfs-bus-iio-adc-envelope-detector|  36 ++
 MAINTAINERS|   2 +
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/envelope-detector.c| 463 +
 5 files changed, 512 insertions(+)
 create mode 100644 
Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
 create mode 100644 drivers/iio/adc/envelope-detector.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
new file mode 100644
index ..8d890028a649
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
@@ -0,0 +1,36 @@
+What:  /sys/bus/iio/devices/iio:deviceX/invert
+Date:  October 2016
+KernelVersion: 4.9
+Contact:   Peter Rosin 
+Description:
+   The DAC is used to find the peak level of an alternating
+   voltage input signal by a binary search using the output
+   of a comparator wired to an interrupt pin. Like so:
+  _
+ | \
+input +-->---|+ \
+ |   \
+   .---. |}---.
+   |   | |   /|
+   |dac|-->--|- / |
+   |   | |_/  |
+   |   |  |
+   |   |  |
+   |irq|--<---'
+   |   |
+   '---'
+   The boolean invert attribute (0/1) should be set when the
+   input signal is centered around the maximum value of the
+   dac instead of zero. The envelope detector will search
+   from below in this case and will also invert the result.
+   The edge/level of the interrupt is also switched to its
+   opposite value.
+
+What:  /sys/bus/iio/devices/iio:deviceX/compare_interval_ms
+Date:  October 2016
+KernelVersion: 4.9
+Contact:   Peter Rosin 
+Description:
+   Number of milliseconds to wait for the comparator in each
+   step of the binary search for the input peak level. Needs
+   to relate to the frequency of the input signal.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4b6f6ec1b703..0d20f3561700 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6122,7 +6122,9 @@ IIO ENVELOPE DETECTOR
 M: Peter Rosin 
 L: linux-...@vger.kernel.org
 S: Maintained
+F: Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
 F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
+F: drivers/iio/adc/envelope-detector.c
 
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7edcf3238620..d5c4a95855c2 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -195,6 +195,16 @@ config DA9150_GPADC
  To compile this driver as a module, choose M here: the module will be
  called berlin2-adc.
 
+config ENVELOPE_DETECTOR
+   tristate "Envelope detector using a DAC and a comparator"
+   depends on OF
+   help
+ Say yes here to build support for an envelope detector using a DAC
+ and a comparator.
+
+ To compile this driver as a module, choose M here: the module will be
+ called iio-envelope-detector.
+
 config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && 
COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04c311f..0d773c6a0578 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
 obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
+obj-$(CONFIG_ENVELOPE_DETECTOR) += envelope-detector.o
 obj-$(CONFIG_EXYNOS_ADC) 

[PATCH v2 7/7] iio: envelope-detector: ADC driver based on a DAC and a comparator

[Peter Rosin]

The DAC is used to find the peak level of an alternating voltage input
signal by a binary search using the output of a comparator wired to
an interrupt pin. Like so:
  _
 | \
input +-->---|+ \
 |   \
   .---. |}---.
   |   | |   /|
   |dac|-->--|- / |
   |   | |_/  |
   |   |  |
   |   |  |
   |irq|--<---'
   |   |
   '---'

Signed-off-by: Peter Rosin 
---
 .../testing/sysfs-bus-iio-adc-envelope-detector|  36 ++
 MAINTAINERS|   2 +
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/envelope-detector.c| 463 +
 5 files changed, 512 insertions(+)
 create mode 100644 
Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
 create mode 100644 drivers/iio/adc/envelope-detector.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
new file mode 100644
index ..8d890028a649
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
@@ -0,0 +1,36 @@
+What:  /sys/bus/iio/devices/iio:deviceX/invert
+Date:  October 2016
+KernelVersion: 4.9
+Contact:   Peter Rosin 
+Description:
+   The DAC is used to find the peak level of an alternating
+   voltage input signal by a binary search using the output
+   of a comparator wired to an interrupt pin. Like so:
+  _
+ | \
+input +-->---|+ \
+ |   \
+   .---. |}---.
+   |   | |   /|
+   |dac|-->--|- / |
+   |   | |_/  |
+   |   |  |
+   |   |  |
+   |irq|--<---'
+   |   |
+   '---'
+   The boolean invert attribute (0/1) should be set when the
+   input signal is centered around the maximum value of the
+   dac instead of zero. The envelope detector will search
+   from below in this case and will also invert the result.
+   The edge/level of the interrupt is also switched to its
+   opposite value.
+
+What:  /sys/bus/iio/devices/iio:deviceX/compare_interval_ms
+Date:  October 2016
+KernelVersion: 4.9
+Contact:   Peter Rosin 
+Description:
+   Number of milliseconds to wait for the comparator in each
+   step of the binary search for the input peak level. Needs
+   to relate to the frequency of the input signal.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4b6f6ec1b703..0d20f3561700 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6122,7 +6122,9 @@ IIO ENVELOPE DETECTOR
 M: Peter Rosin 
 L: linux-...@vger.kernel.org
 S: Maintained
+F: Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
 F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
+F: drivers/iio/adc/envelope-detector.c
 
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7edcf3238620..d5c4a95855c2 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -195,6 +195,16 @@ config DA9150_GPADC
  To compile this driver as a module, choose M here: the module will be
  called berlin2-adc.
 
+config ENVELOPE_DETECTOR
+   tristate "Envelope detector using a DAC and a comparator"
+   depends on OF
+   help
+ Say yes here to build support for an envelope detector using a DAC
+ and a comparator.
+
+ To compile this driver as a module, choose M here: the module will be
+ called iio-envelope-detector.
+
 config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && 
COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04c311f..0d773c6a0578 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
 obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
+obj-$(CONFIG_ENVELOPE_DETECTOR) += envelope-detector.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
 obj-$(CONFIG_HI8435) 

{standard input}:199: Error: unknown opcode

[kbuild test robot]

Hi Rich,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: b4214e41b7152b1964a3421a40251d202ae2d2c0 sh: add SMP support for J2
date:   3 months ago
config: sh-j2_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b4214e41b7152b1964a3421a40251d202ae2d2c0
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   {standard input}: Assembler messages:
>> {standard input}:199: Error: unknown opcode
   {standard input}:1229: Error: unknown opcode
--
   {standard input}: Assembler messages:
   {standard input}:162: Error: unknown opcode
>> {standard input}:199: Error: unknown opcode
   {standard input}:324: Error: unknown opcode
   {standard input}:520: Error: unknown opcode
   {standard input}:619: Error: unknown opcode

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


.config.gz
Description: application/gzip

{standard input}:199: Error: unknown opcode

[kbuild test robot]

Hi Rich,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: b4214e41b7152b1964a3421a40251d202ae2d2c0 sh: add SMP support for J2
date:   3 months ago
config: sh-j2_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b4214e41b7152b1964a3421a40251d202ae2d2c0
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   {standard input}: Assembler messages:
>> {standard input}:199: Error: unknown opcode
   {standard input}:1229: Error: unknown opcode
--
   {standard input}: Assembler messages:
   {standard input}:162: Error: unknown opcode
>> {standard input}:199: Error: unknown opcode
   {standard input}:324: Error: unknown opcode
   {standard input}:520: Error: unknown opcode
   {standard input}:619: Error: unknown opcode

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


.config.gz
Description: application/gzip

Re: [PATCH v3] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

[Andrey Smirnov]

On Fri, Oct 21, 2016 at 2:09 AM, Neil Armstrong  wrote:
> Since the I2C sx150x GPIO expander driver uses platform_data to manage
> the pins configurations, rewrite the driver as a pinctrl driver using
> pinconf to get/set pin configurations from DT or debugfs.
>
> The pinctrl driver is functionnally equivalent as the gpio-only driver
> and can use DT for pinconf. The platform_data confirmation is dropped.
>
> This patchset removed the gpio-only driver and selects the Pinctrl driver
> config instead. This patchset also migrates the gpio dt-bindings to pinctrl
> and add the pinctrl optional properties.
>
> The driver was tested with a SX1509 device on a BeagleBone black with
> interrupt support and on an X86_64 machine over an I2C to USB converter.
>
> Signed-off-by: Neil Armstrong 
> ---
> This is a fixed version that builds and runs on non-OF platforms and on
> arm based OF. The GPIO version is removed and the bindings are also moved
> to the pinctrl bindings.
>
> Changes since v2 at 
> http://lkml.kernel.org/r/1474991325-1754-1-git-send-email-narmstr...@baylibre.com:
>  - rebased on v4.9-rc1
>  - removed MODULE_DEVICE_TABLE as in upstream bb411e771b0e [1]
>
> Changes since v1 at 
> http://lkml.kernel.org/r/1473166599-29266-1-git-send-email-narmstr...@baylibre.com:
>  - Fix Kconfig descriptions on pinctrl and gpio
>  - Fix Kconfig dependency
>  - Remove oscio support for non-789 devices
>  - correct typo in dt bindings
>  - remove probe reset for non-789 devices
>
> Changes since RFC at 
> http://lkml.kernel.org/r/1472130692-14404-1-git-send-email-narmstr...@baylibre.com:
>  - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
>  - No more rely on OF_GPIO config
>  - Moved and enhanced bindings to pinctrl bindings
>  - Removed gpio-sx150x.c
>  - Temporary select PINCTRL_SX150X when GPIO_SX150X
>  - Temporary mark GPIO_SX150X as deprecated
>
> [1] gpio: sx150x: fix implicit assumption module.h is present
>
>  .../gpio-sx150x.txt => pinctrl/pinctrl-sx150x.txt} |   46 +-
>  drivers/gpio/Kconfig   |   13 +-
>  drivers/gpio/Makefile  |1 -
>  drivers/pinctrl/Kconfig|   14 +
>  drivers/pinctrl/Makefile   |1 +
>  .../gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} | 1174 
> 
>  6 files changed, 779 insertions(+), 470 deletions(-)
>  rename Documentation/devicetree/bindings/{gpio/gpio-sx150x.txt => 
> pinctrl/pinctrl-sx150x.txt} (40%)
>  rename drivers/{gpio/gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} (23%)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt 
> b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> similarity index 40%
> rename from Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
> rename to Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> index c809acb..c293c8a 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> @@ -1,34 +1,54 @@
>  SEMTECH SX150x GPIO expander bindings
>
> +Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
> +../interrupt-controller/interrupts.txt for generic information regarding
> +pin controller, GPIO, and interrupt bindings.
>
>  Required properties:
> -
> -- compatible: should be "semtech,sx1506q",
> +- compatible: should be one of :
> +   "semtech,sx1506q",
> "semtech,sx1508q",
> "semtech,sx1509q",
> "semtech,sx1502q".
>
>  - reg: The I2C slave address for this device.
>
> -- interrupt-parent: phandle of the parent interrupt controller.
> -
> -- interrupts: Interrupt specifier for the controllers interrupt.
> -
>  - #gpio-cells: Should be 2. The first cell is the GPIO number and the
> second cell is used to specify optional parameters:
> bit 0: polarity (0: normal, 1: inverted)
>
>  - gpio-controller: Marks the device as a GPIO controller.
>
> +Optional properties :
> +- interrupt-parent: phandle of the parent interrupt controller.
> +
> +- interrupts: Interrupt specifier for the controllers interrupt.
> +
>  - interrupt-controller: Marks the device as a interrupt controller.
>
> +- semtech,probe-reset: Will trigger a reset of the GPIO expander on probe,
> +   only for sx1508q and sx1509q
> +
>  The GPIO expander can optionally be used as an interrupt controller, in
> -which case it uses the default two cell specifier as described in
> -Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
> +which case it uses the default two cell specifier.
> +
> +Required properties for pin configuration sub-nodes:
> + - pins: List of pins to which the configuration applies.
> +
> +Optional properties for pin configuration sub-nodes:
> 

Re: [PATCH v3] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

[Andrey Smirnov]

On Fri, Oct 21, 2016 at 2:09 AM, Neil Armstrong  wrote:
> Since the I2C sx150x GPIO expander driver uses platform_data to manage
> the pins configurations, rewrite the driver as a pinctrl driver using
> pinconf to get/set pin configurations from DT or debugfs.
>
> The pinctrl driver is functionnally equivalent as the gpio-only driver
> and can use DT for pinconf. The platform_data confirmation is dropped.
>
> This patchset removed the gpio-only driver and selects the Pinctrl driver
> config instead. This patchset also migrates the gpio dt-bindings to pinctrl
> and add the pinctrl optional properties.
>
> The driver was tested with a SX1509 device on a BeagleBone black with
> interrupt support and on an X86_64 machine over an I2C to USB converter.
>
> Signed-off-by: Neil Armstrong 
> ---
> This is a fixed version that builds and runs on non-OF platforms and on
> arm based OF. The GPIO version is removed and the bindings are also moved
> to the pinctrl bindings.
>
> Changes since v2 at 
> http://lkml.kernel.org/r/1474991325-1754-1-git-send-email-narmstr...@baylibre.com:
>  - rebased on v4.9-rc1
>  - removed MODULE_DEVICE_TABLE as in upstream bb411e771b0e [1]
>
> Changes since v1 at 
> http://lkml.kernel.org/r/1473166599-29266-1-git-send-email-narmstr...@baylibre.com:
>  - Fix Kconfig descriptions on pinctrl and gpio
>  - Fix Kconfig dependency
>  - Remove oscio support for non-789 devices
>  - correct typo in dt bindings
>  - remove probe reset for non-789 devices
>
> Changes since RFC at 
> http://lkml.kernel.org/r/1472130692-14404-1-git-send-email-narmstr...@baylibre.com:
>  - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
>  - No more rely on OF_GPIO config
>  - Moved and enhanced bindings to pinctrl bindings
>  - Removed gpio-sx150x.c
>  - Temporary select PINCTRL_SX150X when GPIO_SX150X
>  - Temporary mark GPIO_SX150X as deprecated
>
> [1] gpio: sx150x: fix implicit assumption module.h is present
>
>  .../gpio-sx150x.txt => pinctrl/pinctrl-sx150x.txt} |   46 +-
>  drivers/gpio/Kconfig   |   13 +-
>  drivers/gpio/Makefile  |1 -
>  drivers/pinctrl/Kconfig|   14 +
>  drivers/pinctrl/Makefile   |1 +
>  .../gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} | 1174 
> 
>  6 files changed, 779 insertions(+), 470 deletions(-)
>  rename Documentation/devicetree/bindings/{gpio/gpio-sx150x.txt => 
> pinctrl/pinctrl-sx150x.txt} (40%)
>  rename drivers/{gpio/gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} (23%)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt 
> b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> similarity index 40%
> rename from Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
> rename to Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> index c809acb..c293c8a 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> @@ -1,34 +1,54 @@
>  SEMTECH SX150x GPIO expander bindings
>
> +Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
> +../interrupt-controller/interrupts.txt for generic information regarding
> +pin controller, GPIO, and interrupt bindings.
>
>  Required properties:
> -
> -- compatible: should be "semtech,sx1506q",
> +- compatible: should be one of :
> +   "semtech,sx1506q",
> "semtech,sx1508q",
> "semtech,sx1509q",
> "semtech,sx1502q".
>
>  - reg: The I2C slave address for this device.
>
> -- interrupt-parent: phandle of the parent interrupt controller.
> -
> -- interrupts: Interrupt specifier for the controllers interrupt.
> -
>  - #gpio-cells: Should be 2. The first cell is the GPIO number and the
> second cell is used to specify optional parameters:
> bit 0: polarity (0: normal, 1: inverted)
>
>  - gpio-controller: Marks the device as a GPIO controller.
>
> +Optional properties :
> +- interrupt-parent: phandle of the parent interrupt controller.
> +
> +- interrupts: Interrupt specifier for the controllers interrupt.
> +
>  - interrupt-controller: Marks the device as a interrupt controller.
>
> +- semtech,probe-reset: Will trigger a reset of the GPIO expander on probe,
> +   only for sx1508q and sx1509q
> +
>  The GPIO expander can optionally be used as an interrupt controller, in
> -which case it uses the default two cell specifier as described in
> -Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
> +which case it uses the default two cell specifier.
> +
> +Required properties for pin configuration sub-nodes:
> + - pins: List of pins to which the configuration applies.
> +
> +Optional properties for pin configuration sub-nodes:
> +
> + - bias-disable: disable any pin bias, 

arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)

[kbuild test robot]

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove 
HAVE_LATENCYTOP_SUPPORT
date:   9 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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
git checkout da48d094ce5d7c7dcdad9011648a81c42fd1c2ef
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   arch/ia64/kernel/entry.S: Assembler messages:
>> arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit 
>> integer (-8192-8191)
   arch/ia64/kernel/entry.S:728: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
   arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
--
   arch/ia64/kernel/fsys.S: Assembler messages:
>> arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general 
>> register r0-r3
   arch/ia64/kernel/fsys.S:97: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:193: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:336: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:338: Error: Operand 3 of `add' should be a general 
register r0-r3
--
   arch/ia64/kernel/ivt.S: Assembler messages:
>> arch/ia64/kernel/ivt.S:759: Error: Operand 3 of `add' should be a general 
>> register r0-r3

vim +621 arch/ia64/kernel/entry.S

^1da177e Linus Torvalds 2005-04-16  605 PT_REGS_UNWIND_INFO(0)
^1da177e Linus Torvalds 2005-04-16  606  {  /*
^1da177e Linus Torvalds 2005-04-16  607  * Some versions of gas 
generate bad unwind info if the first instruction of a
^1da177e Linus Torvalds 2005-04-16  608  * procedure doesn't go into 
the first slot of a bundle.  This is a workaround.
^1da177e Linus Torvalds 2005-04-16  609  */
^1da177e Linus Torvalds 2005-04-16  610 nop.m 0
^1da177e Linus Torvalds 2005-04-16  611 nop.i 0
^1da177e Linus Torvalds 2005-04-16  612 /*
^1da177e Linus Torvalds 2005-04-16  613  * We need to call 
schedule_tail() to complete the scheduling process.
^1da177e Linus Torvalds 2005-04-16  614  * Called by ia64_switch_to() 
after do_fork()->copy_thread().  r8 contains the
^1da177e Linus Torvalds 2005-04-16  615  * address of the previously 
executing task.
^1da177e Linus Torvalds 2005-04-16  616  */
^1da177e Linus Torvalds 2005-04-16  617 br.call.sptk.many 
rp=ia64_invoke_schedule_tail
^1da177e Linus Torvalds 2005-04-16  618  }
^1da177e Linus Torvalds 2005-04-16  619  .ret8:
54d496c3 Al Viro2012-10-14  620  (pKStk)br.call.sptk.many 
rp=call_payload
^1da177e Linus Torvalds 2005-04-16 @621 adds 
r2=TI_FLAGS+IA64_TASK_SIZE,r13
^1da177e Linus Torvalds 2005-04-16  622 ;;
^1da177e Linus Torvalds 2005-04-16  623 ld4 r2=[r2]
^1da177e Linus Torvalds 2005-04-16  624 ;;
^1da177e Linus Torvalds 2005-04-16  625 mov r8=0
^1da177e Linus Torvalds 2005-04-16  626 and 
r2=_TIF_SYSCALL_TRACEAUDIT,r2
^1da177e Linus Torvalds 2005-04-16  627 ;;
^1da177e Linus Torvalds 2005-04-16  628 cmp.ne p6,p0=r2,r0
^1da177e Linus Torvalds 2005-04-16  629  (p6)   br.cond.spnt 
.strace_check_retval

:: The code at line 621 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)

[kbuild test robot]

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove 
HAVE_LATENCYTOP_SUPPORT
date:   9 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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
git checkout da48d094ce5d7c7dcdad9011648a81c42fd1c2ef
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   arch/ia64/kernel/entry.S: Assembler messages:
>> arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit 
>> integer (-8192-8191)
   arch/ia64/kernel/entry.S:728: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
   arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
--
   arch/ia64/kernel/fsys.S: Assembler messages:
>> arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general 
>> register r0-r3
   arch/ia64/kernel/fsys.S:97: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:193: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:336: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:338: Error: Operand 3 of `add' should be a general 
register r0-r3
--
   arch/ia64/kernel/ivt.S: Assembler messages:
>> arch/ia64/kernel/ivt.S:759: Error: Operand 3 of `add' should be a general 
>> register r0-r3

vim +621 arch/ia64/kernel/entry.S

^1da177e Linus Torvalds 2005-04-16  605 PT_REGS_UNWIND_INFO(0)
^1da177e Linus Torvalds 2005-04-16  606  {  /*
^1da177e Linus Torvalds 2005-04-16  607  * Some versions of gas 
generate bad unwind info if the first instruction of a
^1da177e Linus Torvalds 2005-04-16  608  * procedure doesn't go into 
the first slot of a bundle.  This is a workaround.
^1da177e Linus Torvalds 2005-04-16  609  */
^1da177e Linus Torvalds 2005-04-16  610 nop.m 0
^1da177e Linus Torvalds 2005-04-16  611 nop.i 0
^1da177e Linus Torvalds 2005-04-16  612 /*
^1da177e Linus Torvalds 2005-04-16  613  * We need to call 
schedule_tail() to complete the scheduling process.
^1da177e Linus Torvalds 2005-04-16  614  * Called by ia64_switch_to() 
after do_fork()->copy_thread().  r8 contains the
^1da177e Linus Torvalds 2005-04-16  615  * address of the previously 
executing task.
^1da177e Linus Torvalds 2005-04-16  616  */
^1da177e Linus Torvalds 2005-04-16  617 br.call.sptk.many 
rp=ia64_invoke_schedule_tail
^1da177e Linus Torvalds 2005-04-16  618  }
^1da177e Linus Torvalds 2005-04-16  619  .ret8:
54d496c3 Al Viro2012-10-14  620  (pKStk)br.call.sptk.many 
rp=call_payload
^1da177e Linus Torvalds 2005-04-16 @621 adds 
r2=TI_FLAGS+IA64_TASK_SIZE,r13
^1da177e Linus Torvalds 2005-04-16  622 ;;
^1da177e Linus Torvalds 2005-04-16  623 ld4 r2=[r2]
^1da177e Linus Torvalds 2005-04-16  624 ;;
^1da177e Linus Torvalds 2005-04-16  625 mov r8=0
^1da177e Linus Torvalds 2005-04-16  626 and 
r2=_TIF_SYSCALL_TRACEAUDIT,r2
^1da177e Linus Torvalds 2005-04-16  627 ;;
^1da177e Linus Torvalds 2005-04-16  628 cmp.ne p6,p0=r2,r0
^1da177e Linus Torvalds 2005-04-16  629  (p6)   br.cond.spnt 
.strace_check_retval

:: The code at line 621 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[GIT PULL] target fixes for v4.9-rc2

[Nicholas A. Bellinger]

Hello Linus,

Here are the outstanding target-pending fixes for v4.9-rc2.  Please go
ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

This includes:

  - Fix v4.1.y+ reference leak regression with concurrent TMR ABORT_TASK +
session shutdown. (Vaibhav Tandon)
  - Enable tcm_fc w/ SCF_USE_CPUID to avoid host exchange timeouts (Hannes)
  - target/user error sense handling fixes. (Andy + MNC + HCH)
  - Fix iscsi-target NOP_OUT error path iscsi_cmd descriptor leak (Varun)
  - Two EXTENDED_COPY SCSI status fixes for ESX VAAI (Dinesh Israni + Nixon 
Vincent)
  - Revert a v4.8 residual overflow change, that breaks sg_inq with
small allocation lengths.

There are a number of folks stress testing the v4.1.y regression fix in
their environments, and more folks doing iser-target I/O stress testing
atop recent v4.x.y code.

There is also one v4.2.y+ RCU conversion regression related to explicit
NodeACL configfs changes, that is still being tracked down.

Thank you,

--nab

Andy Grover (3):
  target/user: Use sense_reason_t in tcmu_queue_cmd_ring
  target/user: Return an error if cmd data size is too large
  target/user: Fix comments to not refer to data ring

Colin Ian King (1):
  iscsi-target: fix spelling mistake "Unsolicitied" -> "Unsolicited"

Dinesh Israni (1):
  target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code

Hannes Reinecke (5):
  target: fix potential race window in target_sess_cmd_list_waiting()
  target/tcm_fc: print command pointer in debug message
  target/tcm_fc: return detailed error in ft_sess_create()
  target/tcm_fc: Update debugging statements to match libfc usage
  target/tcm_fc: use CPU affinity for responses

Nicholas Bellinger (3):
  target: Re-add missing SCF_ACK_KREF assignment in v4.1.y
  target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT
REACHABLE
  Revert "target: Fix residual overflow handling in
target_complete_cmd_with_length"

Varun Prakash (1):
  iscsi-target: fix iscsi cmd leak

 drivers/target/iscsi/iscsi_target.c   |  6 +++-
 drivers/target/iscsi/iscsi_target_login.c |  4 +--
 drivers/target/target_core_transport.c| 39 
 drivers/target/target_core_user.c | 50 +--
 drivers/target/target_core_xcopy.c| 34 -
 drivers/target/tcm_fc/tfc_cmd.c   |  4 +--
 drivers/target/tcm_fc/tfc_sess.c  | 42 ++
 include/target/target_core_base.h |  1 +
 8 files changed, 105 insertions(+), 75 deletions(-)

[GIT PULL] target fixes for v4.9-rc2

[Nicholas A. Bellinger]

Hello Linus,

Here are the outstanding target-pending fixes for v4.9-rc2.  Please go
ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

This includes:

  - Fix v4.1.y+ reference leak regression with concurrent TMR ABORT_TASK +
session shutdown. (Vaibhav Tandon)
  - Enable tcm_fc w/ SCF_USE_CPUID to avoid host exchange timeouts (Hannes)
  - target/user error sense handling fixes. (Andy + MNC + HCH)
  - Fix iscsi-target NOP_OUT error path iscsi_cmd descriptor leak (Varun)
  - Two EXTENDED_COPY SCSI status fixes for ESX VAAI (Dinesh Israni + Nixon 
Vincent)
  - Revert a v4.8 residual overflow change, that breaks sg_inq with
small allocation lengths.

There are a number of folks stress testing the v4.1.y regression fix in
their environments, and more folks doing iser-target I/O stress testing
atop recent v4.x.y code.

There is also one v4.2.y+ RCU conversion regression related to explicit
NodeACL configfs changes, that is still being tracked down.

Thank you,

--nab

Andy Grover (3):
  target/user: Use sense_reason_t in tcmu_queue_cmd_ring
  target/user: Return an error if cmd data size is too large
  target/user: Fix comments to not refer to data ring

Colin Ian King (1):
  iscsi-target: fix spelling mistake "Unsolicitied" -> "Unsolicited"

Dinesh Israni (1):
  target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code

Hannes Reinecke (5):
  target: fix potential race window in target_sess_cmd_list_waiting()
  target/tcm_fc: print command pointer in debug message
  target/tcm_fc: return detailed error in ft_sess_create()
  target/tcm_fc: Update debugging statements to match libfc usage
  target/tcm_fc: use CPU affinity for responses

Nicholas Bellinger (3):
  target: Re-add missing SCF_ACK_KREF assignment in v4.1.y
  target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT
REACHABLE
  Revert "target: Fix residual overflow handling in
target_complete_cmd_with_length"

Varun Prakash (1):
  iscsi-target: fix iscsi cmd leak

 drivers/target/iscsi/iscsi_target.c   |  6 +++-
 drivers/target/iscsi/iscsi_target_login.c |  4 +--
 drivers/target/target_core_transport.c| 39 
 drivers/target/target_core_user.c | 50 +--
 drivers/target/target_core_xcopy.c| 34 -
 drivers/target/tcm_fc/tfc_cmd.c   |  4 +--
 drivers/target/tcm_fc/tfc_sess.c  | 42 ++
 include/target/target_core_base.h |  1 +
 8 files changed, 105 insertions(+), 75 deletions(-)

cc1: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   12 days ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3000' requires '-mfp32'

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   12 days ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3000' requires '-mfp32'

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


.config.gz
Description: application/gzip

Re: [PATCH v4 2/5] drivers/of: do not add memory for unavailable nodes

[Reza Arbab]

Hi Alistair,

On Fri, Oct 21, 2016 at 05:22:54PM +1100, Alistair Popple wrote:
From what I can tell it seems that kernels without this patch will try 
and use this memory even if it is marked in the device-tree as 
status="disabled" which could lead to problems for older kernels when 
we start exporting this property from firmware.


Arguably this might not be such a problem in practice as we probably 
don't have many (if any) existing kernels that will boot on hardware 
exporting these properties.


Yes, I think you've got it right.

However given this patch seems fairly independent perhaps it is worth 
sending as a separate fix if it is not going to make it into this 
release?


Michael,

If this set as a whole is going to miss the release, would it be helpful 
for me to resend 1/5 and 2/5 as a separate set? They are the minimum 
needed to prevent the possible forward compatibility issue Alistair 
describes.


--
Reza Arbab

Re: [PATCH v4 2/5] drivers/of: do not add memory for unavailable nodes

[Reza Arbab]

Hi Alistair,

On Fri, Oct 21, 2016 at 05:22:54PM +1100, Alistair Popple wrote:
From what I can tell it seems that kernels without this patch will try 
and use this memory even if it is marked in the device-tree as 
status="disabled" which could lead to problems for older kernels when 
we start exporting this property from firmware.


Arguably this might not be such a problem in practice as we probably 
don't have many (if any) existing kernels that will boot on hardware 
exporting these properties.


Yes, I think you've got it right.

However given this patch seems fairly independent perhaps it is worth 
sending as a separate fix if it is not going to make it into this 
release?


Michael,

If this set as a whole is going to miss the release, would it be helpful 
for me to resend 1/5 and 2/5 as a separate set? They are the minimum 
needed to prevent the possible forward compatibility issue Alistair 
describes.


--
Reza Arbab

Email blocked due to detection of unsafe file attachment

[ITSupport]

Your e-mail has been blocked due to detection of unsafe file attachment.

--- Additional Information ---:

Subject:
Sender: linux-kernel@vger.kernel.org

Time received: 10/22/2016 11:14:24 PM
Message 
ID:<147717805956.1197.11354522112670710...@173-13-69-253-newengland.hfc.comcastbusiness.net>
Detections found:
EMAIL_1140335578045_nick.entwistle.zip   JS/Nemucod.OB
For our email disclaimer, please visit 
http://www.nus.org.uk/nus-email-disclaimer National Union of Students (United 
Kingdom), Registered office: Ian King House, Snape Road, Macclesfield, SK10 2NZ 
Registered in England and Wales. A company limited by guarantee (08015198)

Email blocked due to detection of unsafe file attachment

[ITSupport]

Your e-mail has been blocked due to detection of unsafe file attachment.

--- Additional Information ---:

Subject:
Sender: linux-kernel@vger.kernel.org

Time received: 10/22/2016 11:14:24 PM
Message 
ID:<147717805956.1197.11354522112670710...@173-13-69-253-newengland.hfc.comcastbusiness.net>
Detections found:
EMAIL_1140335578045_nick.entwistle.zip   JS/Nemucod.OB
For our email disclaimer, please visit 
http://www.nus.org.uk/nus-email-disclaimer National Union of Students (United 
Kingdom), Registered office: Ian King House, Snape Road, Macclesfield, SK10 2NZ 
Registered in England and Wales. A company limited by guarantee (08015198)

Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers

[Jarod Wilson]

On Sat, Oct 22, 2016 at 09:27:59PM +0200, Stefan Richter wrote:
> Adding Cc: linux1394-devel, dropping several Ccs, no additional comment.
> 
> On Oct 22 Stefan Richter wrote:
> > On Oct 20 Jarod Wilson wrote:
> > > firewire-net:
> > > - set min/max_mtu
> > > - remove fwnet_change_mtu  
> > [...]
> > > --- a/drivers/firewire/net.c
> > > +++ b/drivers/firewire/net.c
> > > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff
> > > *skb, struct net_device *net) return NETDEV_TX_OK;
> > >  }
> > >  
> > > -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> > > -{
> > > - if (new_mtu < 68)
> > > - return -EINVAL;
> > > -
> > > - net->mtu = new_mtu;
> > > - return 0;
> > > -}
> > > -
> > >  static const struct ethtool_ops fwnet_ethtool_ops = {
> > >   .get_link   = ethtool_op_get_link,
> > >  };
> > > @@ -1366,7 +1357,6 @@ static const struct net_device_ops
> > > fwnet_netdev_ops = { .ndo_open   = fwnet_open,
> > >   .ndo_stop   = fwnet_stop,
> > >   .ndo_start_xmit = fwnet_tx,
> > > - .ndo_change_mtu = fwnet_change_mtu,
> > >  };
> > >  
> > >  static void fwnet_init_dev(struct net_device *net)
> > > @@ -1435,7 +1425,6 @@ static int fwnet_probe(struct fw_unit *unit,
> > >   struct net_device *net;
> > >   bool allocated_netdev = false;
> > >   struct fwnet_device *dev;
> > > - unsigned max_mtu;
> > >   int ret;
> > >   union fwnet_hwaddr *ha;
> > >  
> > > @@ -1478,9 +1467,10 @@ static int fwnet_probe(struct fw_unit *unit,
> > >* Use the RFC 2734 default 1500 octets or the maximum payload
> > >* as initial MTU
> > >*/
> > > - max_mtu = (1 << (card->max_receive + 1))
> > > -   - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > - net->mtu = min(1500U, max_mtu);
> > > + net->max_mtu = (1 << (card->max_receive + 1))
> > > +- sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > + net->mtu = min(1500U, net->max_mtu);
> > > + net->min_mtu = ETH_MIN_MTU;
> > >  
> > >   /* Set our hardware address while we're at it */
> > >   ha = (union fwnet_hwaddr *)net->dev_addr;
> > 
> > Please preserve the current behavior, i.e. do not enforce any particular
> > upper bound.  (Especially none based on the local link layer controller's
> > max_receive parameter.)
> > 
> > BTW, after having read RFC 2734, RFC 3146, and the code, I am convinced
> > that net->mtu should be initialized to 1500, not less.  But such a change
> > should be done in a separate patch.

Okay, since it's already merged in net-next, I can do a follow-up patch
here to set max_mtu to ETH_MAX_MTU (65535), which is the largest possible
size the kernel can handle, so far as I can tell. But as long as I'm going
to be in here, if we just want to use an initial mtu of 1500, I could
clean that up at the same time, and entirely remove the max_mtu
calculation stuff, if that's what you think is more correct here.

-- 
Jarod Wilson
ja...@redhat.com

Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers

[Jarod Wilson]

On Sat, Oct 22, 2016 at 09:27:59PM +0200, Stefan Richter wrote:
> Adding Cc: linux1394-devel, dropping several Ccs, no additional comment.
> 
> On Oct 22 Stefan Richter wrote:
> > On Oct 20 Jarod Wilson wrote:
> > > firewire-net:
> > > - set min/max_mtu
> > > - remove fwnet_change_mtu  
> > [...]
> > > --- a/drivers/firewire/net.c
> > > +++ b/drivers/firewire/net.c
> > > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff
> > > *skb, struct net_device *net) return NETDEV_TX_OK;
> > >  }
> > >  
> > > -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> > > -{
> > > - if (new_mtu < 68)
> > > - return -EINVAL;
> > > -
> > > - net->mtu = new_mtu;
> > > - return 0;
> > > -}
> > > -
> > >  static const struct ethtool_ops fwnet_ethtool_ops = {
> > >   .get_link   = ethtool_op_get_link,
> > >  };
> > > @@ -1366,7 +1357,6 @@ static const struct net_device_ops
> > > fwnet_netdev_ops = { .ndo_open   = fwnet_open,
> > >   .ndo_stop   = fwnet_stop,
> > >   .ndo_start_xmit = fwnet_tx,
> > > - .ndo_change_mtu = fwnet_change_mtu,
> > >  };
> > >  
> > >  static void fwnet_init_dev(struct net_device *net)
> > > @@ -1435,7 +1425,6 @@ static int fwnet_probe(struct fw_unit *unit,
> > >   struct net_device *net;
> > >   bool allocated_netdev = false;
> > >   struct fwnet_device *dev;
> > > - unsigned max_mtu;
> > >   int ret;
> > >   union fwnet_hwaddr *ha;
> > >  
> > > @@ -1478,9 +1467,10 @@ static int fwnet_probe(struct fw_unit *unit,
> > >* Use the RFC 2734 default 1500 octets or the maximum payload
> > >* as initial MTU
> > >*/
> > > - max_mtu = (1 << (card->max_receive + 1))
> > > -   - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > - net->mtu = min(1500U, max_mtu);
> > > + net->max_mtu = (1 << (card->max_receive + 1))
> > > +- sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > + net->mtu = min(1500U, net->max_mtu);
> > > + net->min_mtu = ETH_MIN_MTU;
> > >  
> > >   /* Set our hardware address while we're at it */
> > >   ha = (union fwnet_hwaddr *)net->dev_addr;
> > 
> > Please preserve the current behavior, i.e. do not enforce any particular
> > upper bound.  (Especially none based on the local link layer controller's
> > max_receive parameter.)
> > 
> > BTW, after having read RFC 2734, RFC 3146, and the code, I am convinced
> > that net->mtu should be initialized to 1500, not less.  But such a change
> > should be done in a separate patch.

Okay, since it's already merged in net-next, I can do a follow-up patch
here to set max_mtu to ETH_MAX_MTU (65535), which is the largest possible
size the kernel can handle, so far as I can tell. But as long as I'm going
to be in here, if we just want to use an initial mtu of 1500, I could
clean that up at the same time, and entirely remove the max_mtu
calculation stuff, if that's what you think is more correct here.

-- 
Jarod Wilson
ja...@redhat.com

[PATCH v2 0/7] IIO wrapper drivers, dpot-dac and envelope-detector

[Peter Rosin]

Hi!

These two drivers share the fact that they wrap another iio channel,
and I use the first in combination with the second, which is why I'm
submitting them as a pair.

The first driver is a simple wrapper converting an iio dpot into an
iio dac. It only changes the unit and scale. It also does not add any
fancy iio buffer support that I don't need. I suppose that can be
added. By someone else :-)

The second driver (the envelope detector) is more involved. It also
explains why I need the dpot-dac driver. I wanted the envelope
detector to be generic and work with any dac, but I had a dpot...

But before those two new drivers, there is some infrastructure added
to provide available values for a channel.

v1 -> v2
- provide out_resistanceX_raw_available channel attribute in mcp4531 dpot

dpot-dac:
- change Vref to vref
- the module will be called dpot-dac (in Kconfig help)
- removed a 'the'
- removed (s64) cast
- make the channel indexed, makes libiio find the channel (tested with 0.5)
- add a comment on how integer scale is converted to fractional scale
  and clarify the code a bit
- dig out max-ohms by looking at scale and maximum available raw value
  from the dpot channel and drop the 'dpot-dac,max-ohms' devicetree property
- provide out_voltageX_raw_available channel attribute

envelope-detector:
- change compatible from envelope-detector to axentia,tse850-envelope-detector
- remove envelope-detector,invert and envelope-detector,comp-interval-ms from
  devicetree and add them as iio device attributes instead
- make the channel indexed, makes libiio find the channel (tested with 0.5)
- reorder struct envelope to better indicate what is covered by read_lock
- add comment on interaction between envelope_detector_comp_latch (renamed
  from envelope_detector_latch) and envelope_detector_comp_isr (renamed
  from envelope_detector_isr)
- fixup a problem in envelope_detector_comp_latch where interrupts pending
  from when the interrupt has been disabled interferes with expected
  operation
- slight rewrite of the initial high/low assignments
- use a better name when requesting the interrupt
- dig out dac_max by looking at scale and maximum available raw value
  from the dac channel and drop the 'envelope-detector,dac-max' devicetree
  property

Ok, so the devicetree compatible string for the envelope-detector gained
the "axentia,tse850-" prefix, but at the same time the driver also gained
generality that in my mind puts it in about the same position as the
dpot-dac driver. The driver really has very little to do with the specifics
of the TSE-850. But at the same time there are more ways to build an
envelope detector compared to the obviousness of building a dac from a dpot...

One thing I don't like is that the irq needs to be changed for cases where
it is only ever interesting with the 'invert' variant, and it may not work
to set up the irq the wrong way first. For the TSE-850, this does not
matter, since we have a mux on the envelope detector input and can make use
of both 'invert' and 'normal' for different signals (we could have gotten
by with only 'invert' since the only signals we are measuring that are
'normal' are also DC signals and can thus be detected both from below and
from above), but it is nice to have it both ways.

Also, perhaps the new device attributes (invert and compare_interval_ms)
should really be channel attributes?

Cheers,
Peter

PS. I have not tried to forward port anything else from the thread with
the old thread with the initial iio:core patch.

Jonathan Cameron (1):
  iio:core: add a callback to allow drivers to provide _available
attributes

Peter Rosin (6):
  iio: mcp4531: provide range of available raw values
  dt-bindings: add axentia to vendor-prefixes
  dt-bindings: iio: document dpot-dac bindings
  iio: dpot-dac: DAC driver based on a digital potentiometer
  dt-bindings: iio: document envelope-detector bindings
  iio: envelope-detector: ADC driver based on a DAC and a comparator

 .../testing/sysfs-bus-iio-adc-envelope-detector|  36 ++
 .../bindings/iio/adc/envelope-detector.txt |  55 +++
 .../devicetree/bindings/iio/dac/dpot-dac.txt   |  41 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|  15 +
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/envelope-detector.c| 463 +
 drivers/iio/dac/Kconfig|  10 +
 drivers/iio/dac/Makefile   |   1 +
 drivers/iio/dac/dpot-dac.c | 298 +
 drivers/iio/industrialio-core.c| 232 +--
 drivers/iio/potentiometer/mcp4531.c| 104 +++--
 include/linux/iio/iio.h|  11 +
 include/linux/iio/types.h  |   5 +
 15 files changed, 1216 insertions(+), 67 deletions(-)
 

[PATCH v2 4/7] dt-bindings: iio: document dpot-dac bindings

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/iio/dac/dpot-dac.txt   | 41 ++
 MAINTAINERS|  6 
 2 files changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/dpot-dac.txt

diff --git a/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt 
b/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
new file mode 100644
index ..4fd5d63cc2d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
@@ -0,0 +1,41 @@
+Bindings for DAC emulation using a digital potentiometer
+
+It is assumed the that the dpot is used as a voltage divider between the
+current dpot wiper setting and the maximum resistance of the dpot. The
+divided voltage is provided by a vref regulator.
+
+  .--.
+   .---.  |  |
+   | vref  |--'.---.
+   | regulator |--.|   |
+   '---'  || d |
+  || p |
+  || o |  wiper
+  || t |<-+
+  ||   |
+  |'---'   dac output voltage
+  |  |
+  '--++
+
+Required properties:
+- compatible: Should be "dpot-dac"
+- vref-supply: The regulator supplying the voltage divider.
+- io-channels: Channel node of the dpot to be used for the voltage division.
+- io-channel-names: Should be "dpot".
+
+Example:
+
+{
+   dpot: mcp4651-503@28 {
+   compatible = "microchip,mcp4651-503";
+   reg = <0x28>;
+   #io-channel-cells = <1>;
+   };
+   };
+
+   dac {
+   compatible = "dpot-dac";
+   vref-supply = <_3v3>;
+   io-channels = < 0>;
+   io-channel-names = "dpot";
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7e0064..c68b72088945 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6111,6 +6111,12 @@ L:   linux-me...@vger.kernel.org
 S: Maintained
 F: drivers/media/rc/iguanair.c
 
+IIO DIGITAL POTENTIOMETER DAC
+M: Peter Rosin 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Hartmut Knaack 
-- 
2.1.4

[PATCH v2 6/7] dt-bindings: iio: document envelope-detector bindings

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 .../bindings/iio/adc/envelope-detector.txt | 55 ++
 MAINTAINERS|  6 +++
 2 files changed, 61 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/adc/envelope-detector.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt 
b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
new file mode 100644
index ..9099531c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
@@ -0,0 +1,55 @@
+Bindings for ADC envelope detector using a DAC and a comparator
+
+The DAC is used to find the peak level of an alternating voltage input
+signal by a binary search using the output of a comparator wired to
+an interrupt pin. Like so:
+  _
+ | \
+input +-->---|+ \
+ |   \
+   .---. |}---.
+   |   | |   /|
+   |dac|-->--|- / |
+   |   | |_/  |
+   |   |  |
+   |   |  |
+   |irq|--<---'
+   |   |
+   '---'
+
+Required properties:
+- compatible: Should be "axentia,tse850-envelope-detector"
+- io-channels: Channel node of the dac to be used for comparator input.
+- io-channel-names: Should be "dac".
+- interrupt specification for one client interrupt,
+  see ../../interrupt-controller/interrupts.txt for details.
+- interrupt-names: Should be "comp".
+
+Example:
+
+{
+   dpot: mcp4651-104@28 {
+   compatible = "microchip,mcp4651-104";
+   reg = <0x28>;
+   #io-channel-cells = <1>;
+   };
+   };
+
+   dac: dac {
+   compatible = "dpot-dac";
+   vref-supply = <_3v3>;
+   io-channels = < 0>;
+   io-channel-names = "dpot";
+   dpot-dac,max-ohms = <10>;
+   #io-channel-cells = <1>;
+   };
+
+   envelope-detector {
+   compatible = "axentia,tse850-envelope-detector";
+   io-channels = < 0>;
+   io-channel-names = "dac";
+
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-names = "comp";
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c8aae24b96b..4b6f6ec1b703 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6118,6 +6118,12 @@ S:   Maintained
 F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
 F: drivers/iio/dac/dpot-dac.c
 
+IIO ENVELOPE DETECTOR
+M: Peter Rosin 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Hartmut Knaack 
-- 
2.1.4

[PATCH v2 4/7] dt-bindings: iio: document dpot-dac bindings

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/iio/dac/dpot-dac.txt   | 41 ++
 MAINTAINERS|  6 
 2 files changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/dpot-dac.txt

diff --git a/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt 
b/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
new file mode 100644
index ..4fd5d63cc2d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
@@ -0,0 +1,41 @@
+Bindings for DAC emulation using a digital potentiometer
+
+It is assumed the that the dpot is used as a voltage divider between the
+current dpot wiper setting and the maximum resistance of the dpot. The
+divided voltage is provided by a vref regulator.
+
+  .--.
+   .---.  |  |
+   | vref  |--'.---.
+   | regulator |--.|   |
+   '---'  || d |
+  || p |
+  || o |  wiper
+  || t |<-+
+  ||   |
+  |'---'   dac output voltage
+  |  |
+  '--++
+
+Required properties:
+- compatible: Should be "dpot-dac"
+- vref-supply: The regulator supplying the voltage divider.
+- io-channels: Channel node of the dpot to be used for the voltage division.
+- io-channel-names: Should be "dpot".
+
+Example:
+
+{
+   dpot: mcp4651-503@28 {
+   compatible = "microchip,mcp4651-503";
+   reg = <0x28>;
+   #io-channel-cells = <1>;
+   };
+   };
+
+   dac {
+   compatible = "dpot-dac";
+   vref-supply = <_3v3>;
+   io-channels = < 0>;
+   io-channel-names = "dpot";
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7e0064..c68b72088945 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6111,6 +6111,12 @@ L:   linux-me...@vger.kernel.org
 S: Maintained
 F: drivers/media/rc/iguanair.c
 
+IIO DIGITAL POTENTIOMETER DAC
+M: Peter Rosin 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Hartmut Knaack 
-- 
2.1.4

[PATCH v2 6/7] dt-bindings: iio: document envelope-detector bindings

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 .../bindings/iio/adc/envelope-detector.txt | 55 ++
 MAINTAINERS|  6 +++
 2 files changed, 61 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/adc/envelope-detector.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt 
b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
new file mode 100644
index ..9099531c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
@@ -0,0 +1,55 @@
+Bindings for ADC envelope detector using a DAC and a comparator
+
+The DAC is used to find the peak level of an alternating voltage input
+signal by a binary search using the output of a comparator wired to
+an interrupt pin. Like so:
+  _
+ | \
+input +-->---|+ \
+ |   \
+   .---. |}---.
+   |   | |   /|
+   |dac|-->--|- / |
+   |   | |_/  |
+   |   |  |
+   |   |  |
+   |irq|--<---'
+   |   |
+   '---'
+
+Required properties:
+- compatible: Should be "axentia,tse850-envelope-detector"
+- io-channels: Channel node of the dac to be used for comparator input.
+- io-channel-names: Should be "dac".
+- interrupt specification for one client interrupt,
+  see ../../interrupt-controller/interrupts.txt for details.
+- interrupt-names: Should be "comp".
+
+Example:
+
+{
+   dpot: mcp4651-104@28 {
+   compatible = "microchip,mcp4651-104";
+   reg = <0x28>;
+   #io-channel-cells = <1>;
+   };
+   };
+
+   dac: dac {
+   compatible = "dpot-dac";
+   vref-supply = <_3v3>;
+   io-channels = < 0>;
+   io-channel-names = "dpot";
+   dpot-dac,max-ohms = <10>;
+   #io-channel-cells = <1>;
+   };
+
+   envelope-detector {
+   compatible = "axentia,tse850-envelope-detector";
+   io-channels = < 0>;
+   io-channel-names = "dac";
+
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-names = "comp";
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c8aae24b96b..4b6f6ec1b703 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6118,6 +6118,12 @@ S:   Maintained
 F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
 F: drivers/iio/dac/dpot-dac.c
 
+IIO ENVELOPE DETECTOR
+M: Peter Rosin 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Hartmut Knaack 
-- 
2.1.4

[PATCH v2 0/7] IIO wrapper drivers, dpot-dac and envelope-detector

[Peter Rosin]

Hi!

These two drivers share the fact that they wrap another iio channel,
and I use the first in combination with the second, which is why I'm
submitting them as a pair.

The first driver is a simple wrapper converting an iio dpot into an
iio dac. It only changes the unit and scale. It also does not add any
fancy iio buffer support that I don't need. I suppose that can be
added. By someone else :-)

The second driver (the envelope detector) is more involved. It also
explains why I need the dpot-dac driver. I wanted the envelope
detector to be generic and work with any dac, but I had a dpot...

But before those two new drivers, there is some infrastructure added
to provide available values for a channel.

v1 -> v2
- provide out_resistanceX_raw_available channel attribute in mcp4531 dpot

dpot-dac:
- change Vref to vref
- the module will be called dpot-dac (in Kconfig help)
- removed a 'the'
- removed (s64) cast
- make the channel indexed, makes libiio find the channel (tested with 0.5)
- add a comment on how integer scale is converted to fractional scale
  and clarify the code a bit
- dig out max-ohms by looking at scale and maximum available raw value
  from the dpot channel and drop the 'dpot-dac,max-ohms' devicetree property
- provide out_voltageX_raw_available channel attribute

envelope-detector:
- change compatible from envelope-detector to axentia,tse850-envelope-detector
- remove envelope-detector,invert and envelope-detector,comp-interval-ms from
  devicetree and add them as iio device attributes instead
- make the channel indexed, makes libiio find the channel (tested with 0.5)
- reorder struct envelope to better indicate what is covered by read_lock
- add comment on interaction between envelope_detector_comp_latch (renamed
  from envelope_detector_latch) and envelope_detector_comp_isr (renamed
  from envelope_detector_isr)
- fixup a problem in envelope_detector_comp_latch where interrupts pending
  from when the interrupt has been disabled interferes with expected
  operation
- slight rewrite of the initial high/low assignments
- use a better name when requesting the interrupt
- dig out dac_max by looking at scale and maximum available raw value
  from the dac channel and drop the 'envelope-detector,dac-max' devicetree
  property

Ok, so the devicetree compatible string for the envelope-detector gained
the "axentia,tse850-" prefix, but at the same time the driver also gained
generality that in my mind puts it in about the same position as the
dpot-dac driver. The driver really has very little to do with the specifics
of the TSE-850. But at the same time there are more ways to build an
envelope detector compared to the obviousness of building a dac from a dpot...

One thing I don't like is that the irq needs to be changed for cases where
it is only ever interesting with the 'invert' variant, and it may not work
to set up the irq the wrong way first. For the TSE-850, this does not
matter, since we have a mux on the envelope detector input and can make use
of both 'invert' and 'normal' for different signals (we could have gotten
by with only 'invert' since the only signals we are measuring that are
'normal' are also DC signals and can thus be detected both from below and
from above), but it is nice to have it both ways.

Also, perhaps the new device attributes (invert and compare_interval_ms)
should really be channel attributes?

Cheers,
Peter

PS. I have not tried to forward port anything else from the thread with
the old thread with the initial iio:core patch.

Jonathan Cameron (1):
  iio:core: add a callback to allow drivers to provide _available
attributes

Peter Rosin (6):
  iio: mcp4531: provide range of available raw values
  dt-bindings: add axentia to vendor-prefixes
  dt-bindings: iio: document dpot-dac bindings
  iio: dpot-dac: DAC driver based on a digital potentiometer
  dt-bindings: iio: document envelope-detector bindings
  iio: envelope-detector: ADC driver based on a DAC and a comparator

 .../testing/sysfs-bus-iio-adc-envelope-detector|  36 ++
 .../bindings/iio/adc/envelope-detector.txt |  55 +++
 .../devicetree/bindings/iio/dac/dpot-dac.txt   |  41 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|  15 +
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/envelope-detector.c| 463 +
 drivers/iio/dac/Kconfig|  10 +
 drivers/iio/dac/Makefile   |   1 +
 drivers/iio/dac/dpot-dac.c | 298 +
 drivers/iio/industrialio-core.c| 232 +--
 drivers/iio/potentiometer/mcp4531.c| 104 +++--
 include/linux/iio/iio.h|  11 +
 include/linux/iio/types.h  |   5 +
 15 files changed, 1216 insertions(+), 67 deletions(-)
 

[PATCH v2 5/7] iio: dpot-dac: DAC driver based on a digital potentiometer

[Peter Rosin]

It is assumed the that the dpot is used as a voltage divider between the
current dpot wiper setting and the maximum resistance of the dpot. The
divided voltage is provided by a vref regulator.

  .--.
   .---.  |  |
   | vref  |--'.---.
   | regulator |--.|   |
   '---'  || d |
  || p |
  || o |  wiper
  || t |<-+
  ||   |
  |'---'   dac output voltage
  |  |
  '--++

Signed-off-by: Peter Rosin 
---
 MAINTAINERS|   1 +
 drivers/iio/dac/Kconfig|  10 ++
 drivers/iio/dac/Makefile   |   1 +
 drivers/iio/dac/dpot-dac.c | 298 +
 4 files changed, 310 insertions(+)
 create mode 100644 drivers/iio/dac/dpot-dac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c68b72088945..8c8aae24b96b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6116,6 +6116,7 @@ M:Peter Rosin 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
+F: drivers/iio/dac/dpot-dac.c
 
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 120b24478469..d3084028905b 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -200,6 +200,16 @@ config AD8801
  To compile this driver as a module choose M here: the module will be 
called
  ad8801.
 
+config DPOT_DAC
+   tristate "DAC emulation using a DPOT"
+   depends on OF
+   help
+ Say yes here to build support for DAC emulation using a digital
+ potentiometer.
+
+ To compile this driver as a module, choose M here: the module will be
+ called dpot-dac.
+
 config LPC18XX_DAC
tristate "NXP LPC18xx DAC driver"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 27642bbf75f2..f01bf4a99867 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AD5686) += ad5686.o
 obj-$(CONFIG_AD7303) += ad7303.o
 obj-$(CONFIG_AD8801) += ad8801.o
 obj-$(CONFIG_CIO_DAC) += cio-dac.o
+obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
 obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
 obj-$(CONFIG_M62332) += m62332.o
 obj-$(CONFIG_MAX517) += max517.o
diff --git a/drivers/iio/dac/dpot-dac.c b/drivers/iio/dac/dpot-dac.c
new file mode 100644
index ..5613eae32347
--- /dev/null
+++ b/drivers/iio/dac/dpot-dac.c
@@ -0,0 +1,298 @@
+/*
+ * IIO DAC emulation driver using a digital potentiometer
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * It is assumed that the dpot is used as a voltage divider between the
+ * current dpot wiper setting and the maximum resistance of the dpot. The
+ * divided voltage is provided by a vref regulator.
+ *
+ *   .--.
+ *.---.  |  |
+ *| vref  |--'.---.
+ *| regulator |--.|   |
+ *'---'  || d |
+ *   || p |
+ *   || o |  wiper
+ *   || t |<-+
+ *   ||   |
+ *   |'---'   dac output voltage
+ *   |  |
+ *   '--++
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dpot_dac {
+   struct regulator *vref;
+   struct iio_channel *dpot;
+   u32 max_ohms;
+};
+
+static const struct iio_chan_spec dpot_dac_iio_channel = {
+   .type = IIO_VOLTAGE,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
+   | BIT(IIO_CHAN_INFO_SCALE),
+   .info_mask_separate_available = BIT(IIO_CHAN_INFO_RAW),
+   .output = 1,
+   .indexed = 1,
+};
+
+static int dpot_dac_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int *val, int *val2, long mask)
+{
+   struct dpot_dac *dac = iio_priv(indio_dev);
+   int ret;
+   unsigned long long tmp;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   return iio_read_channel_raw(dac->dpot, val);
+
+   case IIO_CHAN_INFO_SCALE:
+   ret = iio_read_channel_scale(dac->dpot, val, val2);
+   switch (ret) {
+   case IIO_VAL_FRACTIONAL_LOG2:
+   tmp = *val * 10LL;
+   do_div(tmp, dac->max_ohms);
+   tmp *= regulator_get_voltage(dac->vref) / 1000;
+ 

[PATCH v2 3/7] dt-bindings: add axentia to vendor-prefixes

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..a437120a7eee 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -39,6 +39,7 @@ auo   AU Optronics Corporation
 auvidea Auvidea GmbH
 avago  Avago Technologies
 avic   Shanghai AVIC Optoelectronics Co., Ltd.
+axentiaAxentia Technologies AB
 axis   Axis Communications AB
 boeBOE Technology Group Co., Ltd.
 bosch  Bosch Sensortec GmbH
-- 
2.1.4

[PATCH v2 5/7] iio: dpot-dac: DAC driver based on a digital potentiometer

[Peter Rosin]

It is assumed the that the dpot is used as a voltage divider between the
current dpot wiper setting and the maximum resistance of the dpot. The
divided voltage is provided by a vref regulator.

  .--.
   .---.  |  |
   | vref  |--'.---.
   | regulator |--.|   |
   '---'  || d |
  || p |
  || o |  wiper
  || t |<-+
  ||   |
  |'---'   dac output voltage
  |  |
  '--++

Signed-off-by: Peter Rosin 
---
 MAINTAINERS|   1 +
 drivers/iio/dac/Kconfig|  10 ++
 drivers/iio/dac/Makefile   |   1 +
 drivers/iio/dac/dpot-dac.c | 298 +
 4 files changed, 310 insertions(+)
 create mode 100644 drivers/iio/dac/dpot-dac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c68b72088945..8c8aae24b96b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6116,6 +6116,7 @@ M:Peter Rosin 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
+F: drivers/iio/dac/dpot-dac.c
 
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 120b24478469..d3084028905b 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -200,6 +200,16 @@ config AD8801
  To compile this driver as a module choose M here: the module will be 
called
  ad8801.
 
+config DPOT_DAC
+   tristate "DAC emulation using a DPOT"
+   depends on OF
+   help
+ Say yes here to build support for DAC emulation using a digital
+ potentiometer.
+
+ To compile this driver as a module, choose M here: the module will be
+ called dpot-dac.
+
 config LPC18XX_DAC
tristate "NXP LPC18xx DAC driver"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 27642bbf75f2..f01bf4a99867 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AD5686) += ad5686.o
 obj-$(CONFIG_AD7303) += ad7303.o
 obj-$(CONFIG_AD8801) += ad8801.o
 obj-$(CONFIG_CIO_DAC) += cio-dac.o
+obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
 obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
 obj-$(CONFIG_M62332) += m62332.o
 obj-$(CONFIG_MAX517) += max517.o
diff --git a/drivers/iio/dac/dpot-dac.c b/drivers/iio/dac/dpot-dac.c
new file mode 100644
index ..5613eae32347
--- /dev/null
+++ b/drivers/iio/dac/dpot-dac.c
@@ -0,0 +1,298 @@
+/*
+ * IIO DAC emulation driver using a digital potentiometer
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * It is assumed that the dpot is used as a voltage divider between the
+ * current dpot wiper setting and the maximum resistance of the dpot. The
+ * divided voltage is provided by a vref regulator.
+ *
+ *   .--.
+ *.---.  |  |
+ *| vref  |--'.---.
+ *| regulator |--.|   |
+ *'---'  || d |
+ *   || p |
+ *   || o |  wiper
+ *   || t |<-+
+ *   ||   |
+ *   |'---'   dac output voltage
+ *   |  |
+ *   '--++
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dpot_dac {
+   struct regulator *vref;
+   struct iio_channel *dpot;
+   u32 max_ohms;
+};
+
+static const struct iio_chan_spec dpot_dac_iio_channel = {
+   .type = IIO_VOLTAGE,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
+   | BIT(IIO_CHAN_INFO_SCALE),
+   .info_mask_separate_available = BIT(IIO_CHAN_INFO_RAW),
+   .output = 1,
+   .indexed = 1,
+};
+
+static int dpot_dac_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int *val, int *val2, long mask)
+{
+   struct dpot_dac *dac = iio_priv(indio_dev);
+   int ret;
+   unsigned long long tmp;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   return iio_read_channel_raw(dac->dpot, val);
+
+   case IIO_CHAN_INFO_SCALE:
+   ret = iio_read_channel_scale(dac->dpot, val, val2);
+   switch (ret) {
+   case IIO_VAL_FRACTIONAL_LOG2:
+   tmp = *val * 10LL;
+   do_div(tmp, dac->max_ohms);
+   tmp *= regulator_get_voltage(dac->vref) / 1000;
+   do_div(tmp, 10LL);
+   *val = tmp;

[PATCH v2 3/7] dt-bindings: add axentia to vendor-prefixes

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..a437120a7eee 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -39,6 +39,7 @@ auo   AU Optronics Corporation
 auvidea Auvidea GmbH
 avago  Avago Technologies
 avic   Shanghai AVIC Optoelectronics Co., Ltd.
+axentiaAxentia Technologies AB
 axis   Axis Communications AB
 boeBOE Technology Group Co., Ltd.
 bosch  Bosch Sensortec GmbH
-- 
2.1.4

Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"

[Jarod Wilson]

On Sat, Oct 22, 2016 at 09:46:24AM +0200, Sven Eckelmann wrote:
> The maximum MTU is defined via the slave devices of an batman-adv
> interface. Thus it is not possible to calculate the max_mtu during the
> creation of the batman-adv device when no slave devices are attached. Doing
> so would for example break non-fragmentation setups which then
> (incorrectly) allow an MTU of 1500 even when underlying device cannot
> transport 1500 bytes + batman-adv headers.
> 
> Checking the dynamically calculated max_mtu via the minimum of the slave
> devices MTU during .ndo_change_mtu is also used by the bridge interface.
> 
> Cc: Jarod Wilson 
> Fixes: b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> Signed-off-by: Sven Eckelmann 
> ---
> Original patch + my comment: https://patchwork.ozlabs.org/patch/684722/
> 
> I just got informed about this patch when it was already applied in net-next.
> So I can only ask for an revet of the batman-adv parts

Apologies, I tried to cc everyone I could find in MAINTAINERS, but your
name wasn't one of the three listed for batman devices. You're going to
need more than just this revert though, since batman-adv calls
ether_setup, which will set min_mtu = 68, max_mtu = 1500, unless
batadv_hardif_min_mtu() always returns something 1500 or less. Actually,
looking at that, you could omit the mtu < 68 bit from
batadv_interface_change_mtu() too, since that'll already get done in the
core, but I have no clue what you need for max_mtu.

-- 
Jarod Wilson
ja...@redhat.com

Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"

[Jarod Wilson]

On Sat, Oct 22, 2016 at 09:46:24AM +0200, Sven Eckelmann wrote:
> The maximum MTU is defined via the slave devices of an batman-adv
> interface. Thus it is not possible to calculate the max_mtu during the
> creation of the batman-adv device when no slave devices are attached. Doing
> so would for example break non-fragmentation setups which then
> (incorrectly) allow an MTU of 1500 even when underlying device cannot
> transport 1500 bytes + batman-adv headers.
> 
> Checking the dynamically calculated max_mtu via the minimum of the slave
> devices MTU during .ndo_change_mtu is also used by the bridge interface.
> 
> Cc: Jarod Wilson 
> Fixes: b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> Signed-off-by: Sven Eckelmann 
> ---
> Original patch + my comment: https://patchwork.ozlabs.org/patch/684722/
> 
> I just got informed about this patch when it was already applied in net-next.
> So I can only ask for an revet of the batman-adv parts

Apologies, I tried to cc everyone I could find in MAINTAINERS, but your
name wasn't one of the three listed for batman devices. You're going to
need more than just this revert though, since batman-adv calls
ether_setup, which will set min_mtu = 68, max_mtu = 1500, unless
batadv_hardif_min_mtu() always returns something 1500 or less. Actually,
looking at that, you could omit the mtu < 68 bit from
batadv_interface_change_mtu() too, since that'll already get done in the
core, but I have no clue what you need for max_mtu.

-- 
Jarod Wilson
ja...@redhat.com

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   10 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   10 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'

[kbuild test robot]

Hi Vincent,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware 
download support
date:   12 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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
git checkout 3194c6870158e305dac2af52f83681e9cb67280f
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
>> 'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:6:19: note: previous definition of 
'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
>> 'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:11:19: note: previous definition of 
'get_unaligned_le32' was here
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
>> 'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:16:19: note: previous definition of 
'get_unaligned_le64' was here
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/be_byteshift.h:40:19: note: previous definition of 
'get_unaligned_be16' was here
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
  

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'

[kbuild test robot]

Hi Vincent,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware 
download support
date:   12 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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
git checkout 3194c6870158e305dac2af52f83681e9cb67280f
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
>> 'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:6:19: note: previous definition of 
'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
>> 'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:11:19: note: previous definition of 
'get_unaligned_le32' was here
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
>> 'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:16:19: note: previous definition of 
'get_unaligned_le64' was here
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/be_byteshift.h:40:19: note: previous definition of 
'get_unaligned_be16' was here
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
  

arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   12 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip

arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0c2b6dc4fd4fa13796b319aae969a009f03222c6
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   12 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip

[RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

There may be reasons to use generic cpufreq governors (eg. schedutil)
on Intel platforms instead of the intel_pstate driver's internal
governor.  However, that currently can only be done by disabling
intel_pstate altogether and using the acpi-cpufreq driver instead
of it, which is subject to limitations.

First of all, acpi-cpufreq only works on systems where the _PSS
object is present in the ACPI tables for all logical CPUs.  Second,
on those systems acpi-cpufreq will only use frequencies listed by
_PSS which may be suboptimal.  In particular, by convention, the
whole turbo range is represented in _PSS as a single P-state and
the frequency assigned to it is greater by 1 MHz than the greatest
non-turbo frequency listed by _PSS.  That may confuse governors to
use turbo frequencies less frequently which may lead to suboptimal
performance.

For this reason, make it possible to use the intel_pstate driver
with generic cpufreq governors as a "normal" cpufreq driver.  That
mode is enforced by adding intel_pstate=passive to the kernel
command line and cannot be disabled at run time.  In that mode,
intel_pstate provides a cpufreq driver interface including
the ->target() and ->fast_switch() callbacks and is listed in
scaling_driver as "intel_cpufreq".

Signed-off-by: Rafael J. Wysocki 
---

This is all experimental at this point, although it has been tested with
various governors.  In any case, it will have to be rebased on top of
some fixes currently in the works, like

https://patchwork.kernel.org/patch/9389599/
https://patchwork.kernel.org/patch/9389597/

Technically, it is on top of

https://patchwork.kernel.org/patch/9383383/
https://patchwork.kernel.org/patch/9383387/

but it should apply without the two on top of 4.9-rc1 (or -rc2 when it's out).

This mostly is intended as a heads-up about what may be coming or in case
somebody wants to play with it and let me know about the impressions. :-)

Thanks,
Rafael

---
 Documentation/kernel-parameters.txt |6 +
 drivers/cpufreq/intel_pstate.c  |  212 
 2 files changed, 172 insertions(+), 46 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -122,6 +122,8 @@ struct sample {
  * @scaling:   Scaling factor to  convert frequency to cpufreq
  * frequency units
  * @turbo_pstate:  Max Turbo P state possible for this platform
+ * @max_freq:  @max_pstate frequency in cpufreq units
+ * @turbo_freq:@turbo_pstate frequency in cpufreq units
  *
  * Stores the per cpu model P state limits and current P state.
  */
@@ -132,6 +134,8 @@ struct pstate_data {
int max_pstate_physical;
int scaling;
int turbo_pstate;
+   unsigned int max_freq;
+   unsigned int turbo_freq;
 };
 
 /**
@@ -459,7 +463,7 @@ static void intel_pstate_init_acpi_perf_
 {
 }
 
-static void intel_pstate_exit_perf_limits(struct cpufreq_policy *policy)
+static inline int intel_pstate_exit_perf_limits(struct cpufreq_policy *policy)
 {
 }
 #endif
@@ -1171,6 +1175,8 @@ static void intel_pstate_get_cpu_pstates
cpu->pstate.max_pstate_physical = pstate_funcs.get_max_physical();
cpu->pstate.turbo_pstate = pstate_funcs.get_turbo();
cpu->pstate.scaling = pstate_funcs.get_scaling();
+   cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
+   cpu->pstate.turbo_freq = cpu->pstate.turbo_pstate * cpu->pstate.scaling;
 
if (pstate_funcs.get_vid)
pstate_funcs.get_vid(cpu);
@@ -1312,8 +1318,6 @@ static inline void intel_pstate_update_p
 {
int max_perf, min_perf;
 
-   update_turbo_state();
-
intel_pstate_get_min_max(cpu, _perf, _perf);
pstate = clamp_t(int, pstate, min_perf, max_perf);
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
@@ -1333,6 +1337,8 @@ static inline void intel_pstate_adjust_b
 
target_pstate = pstate_funcs.get_target_pstate(cpu);
 
+   update_turbo_state();
+
intel_pstate_update_pstate(cpu, target_pstate);
 
sample = >sample;
@@ -1487,6 +1493,32 @@ static void intel_pstate_set_performance
limits->min_sysfs_pct = 0;
 }
 
+static void intel_pstate_adjust_limits(struct cpufreq_policy *policy)
+{
+   limits->min_policy_pct = (policy->min * 100) / policy->cpuinfo.max_freq;
+   limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , 100);
+   limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100,
+ policy->cpuinfo.max_freq);
+   limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100);
+
+   /* Normalize user input to [min_policy_pct, max_policy_pct] */
+   limits->min_perf_pct 

[RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

There may be reasons to use generic cpufreq governors (eg. schedutil)
on Intel platforms instead of the intel_pstate driver's internal
governor.  However, that currently can only be done by disabling
intel_pstate altogether and using the acpi-cpufreq driver instead
of it, which is subject to limitations.

First of all, acpi-cpufreq only works on systems where the _PSS
object is present in the ACPI tables for all logical CPUs.  Second,
on those systems acpi-cpufreq will only use frequencies listed by
_PSS which may be suboptimal.  In particular, by convention, the
whole turbo range is represented in _PSS as a single P-state and
the frequency assigned to it is greater by 1 MHz than the greatest
non-turbo frequency listed by _PSS.  That may confuse governors to
use turbo frequencies less frequently which may lead to suboptimal
performance.

For this reason, make it possible to use the intel_pstate driver
with generic cpufreq governors as a "normal" cpufreq driver.  That
mode is enforced by adding intel_pstate=passive to the kernel
command line and cannot be disabled at run time.  In that mode,
intel_pstate provides a cpufreq driver interface including
the ->target() and ->fast_switch() callbacks and is listed in
scaling_driver as "intel_cpufreq".

Signed-off-by: Rafael J. Wysocki 
---

This is all experimental at this point, although it has been tested with
various governors.  In any case, it will have to be rebased on top of
some fixes currently in the works, like

https://patchwork.kernel.org/patch/9389599/
https://patchwork.kernel.org/patch/9389597/

Technically, it is on top of

https://patchwork.kernel.org/patch/9383383/
https://patchwork.kernel.org/patch/9383387/

but it should apply without the two on top of 4.9-rc1 (or -rc2 when it's out).

This mostly is intended as a heads-up about what may be coming or in case
somebody wants to play with it and let me know about the impressions. :-)

Thanks,
Rafael

---
 Documentation/kernel-parameters.txt |6 +
 drivers/cpufreq/intel_pstate.c  |  212 
 2 files changed, 172 insertions(+), 46 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -122,6 +122,8 @@ struct sample {
  * @scaling:   Scaling factor to  convert frequency to cpufreq
  * frequency units
  * @turbo_pstate:  Max Turbo P state possible for this platform
+ * @max_freq:  @max_pstate frequency in cpufreq units
+ * @turbo_freq:@turbo_pstate frequency in cpufreq units
  *
  * Stores the per cpu model P state limits and current P state.
  */
@@ -132,6 +134,8 @@ struct pstate_data {
int max_pstate_physical;
int scaling;
int turbo_pstate;
+   unsigned int max_freq;
+   unsigned int turbo_freq;
 };
 
 /**
@@ -459,7 +463,7 @@ static void intel_pstate_init_acpi_perf_
 {
 }
 
-static void intel_pstate_exit_perf_limits(struct cpufreq_policy *policy)
+static inline int intel_pstate_exit_perf_limits(struct cpufreq_policy *policy)
 {
 }
 #endif
@@ -1171,6 +1175,8 @@ static void intel_pstate_get_cpu_pstates
cpu->pstate.max_pstate_physical = pstate_funcs.get_max_physical();
cpu->pstate.turbo_pstate = pstate_funcs.get_turbo();
cpu->pstate.scaling = pstate_funcs.get_scaling();
+   cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
+   cpu->pstate.turbo_freq = cpu->pstate.turbo_pstate * cpu->pstate.scaling;
 
if (pstate_funcs.get_vid)
pstate_funcs.get_vid(cpu);
@@ -1312,8 +1318,6 @@ static inline void intel_pstate_update_p
 {
int max_perf, min_perf;
 
-   update_turbo_state();
-
intel_pstate_get_min_max(cpu, _perf, _perf);
pstate = clamp_t(int, pstate, min_perf, max_perf);
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
@@ -1333,6 +1337,8 @@ static inline void intel_pstate_adjust_b
 
target_pstate = pstate_funcs.get_target_pstate(cpu);
 
+   update_turbo_state();
+
intel_pstate_update_pstate(cpu, target_pstate);
 
sample = >sample;
@@ -1487,6 +1493,32 @@ static void intel_pstate_set_performance
limits->min_sysfs_pct = 0;
 }
 
+static void intel_pstate_adjust_limits(struct cpufreq_policy *policy)
+{
+   limits->min_policy_pct = (policy->min * 100) / policy->cpuinfo.max_freq;
+   limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , 100);
+   limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100,
+ policy->cpuinfo.max_freq);
+   limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100);
+
+   /* Normalize user input to [min_policy_pct, max_policy_pct] */
+   limits->min_perf_pct = max(limits->min_policy_pct,
+  

Re: [PATCH] acpi/apei: Fix in-correct return value

[Rafael J. Wysocki]

On Saturday, October 22, 2016 06:37:35 PM Borislav Petkov wrote:
> On Fri, Oct 21, 2016 at 11:28:29PM +0200, Rafael J. Wysocki wrote:
> > Boris, all fine here?
> 
> Short answer: Yeah, looks ok to me.
> 
> Longer answer: I mean, this way ghes_proc() *actually* propagates the
> return value of ghes_read_estatus() and we don't do any processing if it
> failed.
> 
> Which doesn't really tell me a whole lot about the actual processing,
> i.e., what ghes_do_proc() did.
> 
> But ghes_do_proc() doesn't return anything and ghes_proc()'s retval is
> used only in contexts where we're asking whether something got processed
> or not.
> 
> And for that, that fix is adequate. So:
> 
> Reviewed-by: Borislav Petkov 

Thanks!

Re: [PATCH] acpi/apei: Fix in-correct return value

[Rafael J. Wysocki]

On Saturday, October 22, 2016 06:37:35 PM Borislav Petkov wrote:
> On Fri, Oct 21, 2016 at 11:28:29PM +0200, Rafael J. Wysocki wrote:
> > Boris, all fine here?
> 
> Short answer: Yeah, looks ok to me.
> 
> Longer answer: I mean, this way ghes_proc() *actually* propagates the
> return value of ghes_read_estatus() and we don't do any processing if it
> failed.
> 
> Which doesn't really tell me a whole lot about the actual processing,
> i.e., what ghes_do_proc() did.
> 
> But ghes_do_proc() doesn't return anything and ghes_proc()'s retval is
> used only in contexts where we're asking whether something got processed
> or not.
> 
> And for that, that fix is adequate. So:
> 
> Reviewed-by: Borislav Petkov 

Thanks!

Re: [PATCH V4 3/3] Revert "ACPI, PCI, IRQ: separate ISA penalty calculation"

[Bjorn Helgaas]

On Thu, Oct 20, 2016 at 07:58:57PM -0700, Sinan Kaya wrote:
> On 10/20/2016 7:31 PM, Bjorn Helgaas wrote:
> ...
> > And I don't think it fixes a user-visible problem, so it doesn't need
> > to be applied immediately.  I'm not sure this is worth doing by
> > itself; maybe it should wait until we can do more cleanup and think
> > about all these issues together?
> 
> It does fix the PCI_USING penalty assignment. 
> 
> if (link->irq.active && link->irq.active == irq)
>  penalty += PIRQ_PENALTY_PCI_USING;
> 
> 
> If we drop this patch, then we need
> [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
> 
> http://www.gossamer-threads.com/lists/linux/kernel/2547605
> 
> as somebody needs to increment the penalty with PCI_USING when IRQ is assigned
> for a given ISA IRQ.
> 
> We might as well take [PATCH V4 1/3], [PATCH V4 2/3] and [PATCH V3 1/3]
> for this regression.

It sounds like either V3 1/3 or V4 3/3 will fix the regression.  The
V3 1/3 patch is much smaller and essentially makes this piece look
like it did in v4.6.

The V4 3/3 patch removes acpi_irq_penalty_init() and compensates by
using acpi_irq_pci_sharing_penalty() for ISA IRQs again.  But
acpi_irq_penalty_init() added PIRQ_PENALTY_PCI_POSSIBLE for _CRS, and
only if there was no _PRS, while acpi_irq_pci_sharing_penalty() always
adds PIRQ_PENALTY_PCI_USING for _CRS, regardless of whether _PRS
exists.

Since V4 3/3 is so much bigger and makes this quite subtle change in
how _CRS is handled, I like V3 1/3 better.

Are we all set to go now?  I think I've acked the patches you
mentioned.

Bjorn

Re: [PATCH V4 3/3] Revert "ACPI, PCI, IRQ: separate ISA penalty calculation"

[Bjorn Helgaas]

On Thu, Oct 20, 2016 at 07:58:57PM -0700, Sinan Kaya wrote:
> On 10/20/2016 7:31 PM, Bjorn Helgaas wrote:
> ...
> > And I don't think it fixes a user-visible problem, so it doesn't need
> > to be applied immediately.  I'm not sure this is worth doing by
> > itself; maybe it should wait until we can do more cleanup and think
> > about all these issues together?
> 
> It does fix the PCI_USING penalty assignment. 
> 
> if (link->irq.active && link->irq.active == irq)
>  penalty += PIRQ_PENALTY_PCI_USING;
> 
> 
> If we drop this patch, then we need
> [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
> 
> http://www.gossamer-threads.com/lists/linux/kernel/2547605
> 
> as somebody needs to increment the penalty with PCI_USING when IRQ is assigned
> for a given ISA IRQ.
> 
> We might as well take [PATCH V4 1/3], [PATCH V4 2/3] and [PATCH V3 1/3]
> for this regression.

It sounds like either V3 1/3 or V4 3/3 will fix the regression.  The
V3 1/3 patch is much smaller and essentially makes this piece look
like it did in v4.6.

The V4 3/3 patch removes acpi_irq_penalty_init() and compensates by
using acpi_irq_pci_sharing_penalty() for ISA IRQs again.  But
acpi_irq_penalty_init() added PIRQ_PENALTY_PCI_POSSIBLE for _CRS, and
only if there was no _PRS, while acpi_irq_pci_sharing_penalty() always
adds PIRQ_PENALTY_PCI_USING for _CRS, regardless of whether _PRS
exists.

Since V4 3/3 is so much bigger and makes this quite subtle change in
how _CRS is handled, I like V3 1/3 better.

Are we all set to go now?  I think I've acked the patches you
mentioned.

Bjorn

Re: [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts

[Bjorn Helgaas]

On Sat, Oct 15, 2016 at 12:31:05AM -0400, Sinan Kaya wrote:
> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed PCI_USING penalty from
> acpi_pci_link_allocate function as there is no longer a fixed size penalty
> array for both PCI interrupts greater than 16.
> 
> The array size has been reduced to 16 and array name got prefixed as ISA
> since it only is accountable for the ISA interrupts.
> 
> The original change in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed penalty assignment in the code for PCI
> thinking that we will add the penalty later in acpi_irq_pci_sharing_penalty
> function.
> 
> However, this function only gets called if the IRQ number is greater than
> 16 and acpi_irq_get_penalty function gets called before ACPI start in
> acpi_isa_irq_available and acpi_penalize_isa_irq functions. We can't rely
> on iterating the link list.
> 
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.

I think the history about the array size is more than is necessary for this
changelog.  I think the useful part is something like this:

  ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs

  103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") replaced
  the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
  with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
  ("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
  of acpi_irq_pci_sharing_penalty() for ISA IRQs.

  Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
  interrupt links.  Include that penalty by adding it in the
  acpi_pci_link_allocate() path.

  Fixes: f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty calculation")
  
> Signed-off-by: Sinan Kaya 

Acked-by: Bjorn Helgaas 

> ---
>  drivers/acpi/pci_link.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..a212709 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -619,6 +619,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link 
> *link)
>   acpi_device_bid(link->device));
>   return -ENODEV;
>   } else {
> + if (link->irq.active < ACPI_MAX_ISA_IRQS)
> + acpi_isa_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
>   printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
>  acpi_device_name(link->device),
>  acpi_device_bid(link->device), link->irq.active);
> -- 
> 1.9.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts

[Bjorn Helgaas]

On Sat, Oct 15, 2016 at 12:31:05AM -0400, Sinan Kaya wrote:
> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed PCI_USING penalty from
> acpi_pci_link_allocate function as there is no longer a fixed size penalty
> array for both PCI interrupts greater than 16.
> 
> The array size has been reduced to 16 and array name got prefixed as ISA
> since it only is accountable for the ISA interrupts.
> 
> The original change in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed penalty assignment in the code for PCI
> thinking that we will add the penalty later in acpi_irq_pci_sharing_penalty
> function.
> 
> However, this function only gets called if the IRQ number is greater than
> 16 and acpi_irq_get_penalty function gets called before ACPI start in
> acpi_isa_irq_available and acpi_penalize_isa_irq functions. We can't rely
> on iterating the link list.
> 
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.

I think the history about the array size is more than is necessary for this
changelog.  I think the useful part is something like this:

  ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs

  103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") replaced
  the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
  with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
  ("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
  of acpi_irq_pci_sharing_penalty() for ISA IRQs.

  Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
  interrupt links.  Include that penalty by adding it in the
  acpi_pci_link_allocate() path.

  Fixes: f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty calculation")
  
> Signed-off-by: Sinan Kaya 

Acked-by: Bjorn Helgaas 

> ---
>  drivers/acpi/pci_link.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..a212709 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -619,6 +619,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link 
> *link)
>   acpi_device_bid(link->device));
>   return -ENODEV;
>   } else {
> + if (link->irq.active < ACPI_MAX_ISA_IRQS)
> + acpi_isa_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
>   printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
>  acpi_device_name(link->device),
>  acpi_device_bid(link->device), link->irq.active);
> -- 
> 1.9.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4.8 00/57] 4.8.4-stable review

[Rafael J. Wysocki]

On Saturday, October 22, 2016 11:58:51 AM Greg Kroah-Hartman wrote:
> On Fri, Oct 21, 2016 at 11:02:13PM +0200, Rafael J. Wysocki wrote:
> > On Friday, October 21, 2016 11:17:23 AM Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.8.4 release.
> > > There are 57 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun Oct 23 09:14:19 UTC 2016.
> > > Anything received after that time might be too late.
> > 
> > Please also add commit c6fe46a79ecd "cpufreq: fix overflow in
> > cpufreq_table_find_index_dl()" to this series.
> > 
> > This is needed to fix a regression in an earlier somewhat broken fix that 
> > went
> > into previous 4.8.y unfortunately.
> 
> Really?  It doesn't apply to 4.8-stable at all.  I haven't applied
> 899bb6642f2a2f2cd3f77abd6c5a14550e3b37e6 to the 4.8-stable tree yet,

OK

In that case please make sure that it doesn't go in without c6fe46a79ecd.

> so why should I add it at this point in time?

Clearly, no need. :-)

Thanks,
Rafael

Re: [PATCH 4.8 00/57] 4.8.4-stable review

[Rafael J. Wysocki]

On Saturday, October 22, 2016 11:58:51 AM Greg Kroah-Hartman wrote:
> On Fri, Oct 21, 2016 at 11:02:13PM +0200, Rafael J. Wysocki wrote:
> > On Friday, October 21, 2016 11:17:23 AM Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.8.4 release.
> > > There are 57 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun Oct 23 09:14:19 UTC 2016.
> > > Anything received after that time might be too late.
> > 
> > Please also add commit c6fe46a79ecd "cpufreq: fix overflow in
> > cpufreq_table_find_index_dl()" to this series.
> > 
> > This is needed to fix a regression in an earlier somewhat broken fix that 
> > went
> > into previous 4.8.y unfortunately.
> 
> Really?  It doesn't apply to 4.8-stable at all.  I haven't applied
> 899bb6642f2a2f2cd3f77abd6c5a14550e3b37e6 to the 4.8-stable tree yet,

OK

In that case please make sure that it doesn't go in without c6fe46a79ecd.

> so why should I add it at this point in time?

Clearly, no need. :-)

Thanks,
Rafael

[ANNOUNCE] /dev/random - a new approach code for 4.9-rc1

[Stephan Mueller]

Hi,

The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect 
entropy within the Linux kernel. The main improvements compared to the legacy 
/dev/random is to provide sufficient entropy during boot time as well as in 
virtual environments and when using SSDs or Device Mapper targets. A secondary 
design goal is to limit the impact of the entropy collection on massive 
parallel systems and also allow the use accelerated cryptographic primitives. 
Also, all steps of the entropic data processing are testable. Finally 
performance improvements are visible at /dev/urandom and get_random_bytes.

The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.

[1] http://www.chronox.de/lrng.html

[2] http://www.chronox.de/lrng/doc/lrng.pdf

Ciao
Stephan

[ANNOUNCE] /dev/random - a new approach code for 4.9-rc1

[Stephan Mueller]

Hi,

The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect 
entropy within the Linux kernel. The main improvements compared to the legacy 
/dev/random is to provide sufficient entropy during boot time as well as in 
virtual environments and when using SSDs or Device Mapper targets. A secondary 
design goal is to limit the impact of the entropy collection on massive 
parallel systems and also allow the use accelerated cryptographic primitives. 
Also, all steps of the entropic data processing are testable. Finally 
performance improvements are visible at /dev/urandom and get_random_bytes.

The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.

[1] http://www.chronox.de/lrng.html

[2] http://www.chronox.de/lrng/doc/lrng.pdf

Ciao
Stephan

Re: [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

[Bjorn Helgaas]

On Thu, Oct 20, 2016 at 08:58:14PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 19, 2016 at 06:21:03PM -0400, Sinan Kaya wrote:
> > The SCI penalize function was removed in two steps (first refactor
> > and then remove) and these changes are reverted here in one go.
> > 
> > The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> > refactored the original code so that SCI penalty is calculated dynamically
> > by the time get_penalty function is called. That change is partially
> > reverted here, specifically for the SCI IRQ alone.
> > 
> > The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> > ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> > penalty API with penalty calculation carried out dynamically and based
> > on the acpi_gbl_FADT.sci_interrupt value.
> > 
> > However, that new algorithm relies on the accurate setting of IRQ
> > types and that doesn't happen early enough on some platforms which
> > leads to incorrect penalty assignments for PCI IRQs.  In those cases,
> > irq_get_trigger_type() returns incorrect values for the IRQs in
> > question, because they have not been registered yet by the time the
> > penalties are calculated.
> > 
> > To fix this problem, we only need to fix the penalty for the SCI interrupt.
> > It seems better to add a single "sci_penalty" variable, set it to
> > PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> > otherwise, and add "sci_penalty" in when appropriate.  That should fix it
> > for *any* SCI IRQ, not just those less than 256, and we don't have to add
> > these extra penalty table entries that are all unused (except possibly for
> > one entry if we have an SCI in the 16-255 range).
> > 
> > For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> > penalize function") completely to restore the correct behavior.
> 
> I like this patch fine, except for the changelog.  I don't think it's
> useful to describe this as a revert and give all the historical
> details.  I think the important part is something like this:
> 
>   We previously used irq_get_trigger_type(irq) to help compute the
>   penalty for the SCI, but that depends on the SCI having been
>   registered already.  Add acpi_penalize_sci_irq() so platforms can
>   tell us the SCI IRQ, trigger, and polarity so we can compute the
>   penalty even before the SCI has been registered.

I think this is actually the critical patch that fixes the regression
reported by Ondrej, so the changelog really should include details
about the regression, e.g., something like this:

  ACPI: pci_link: Penalize SCI correctly

  Ondrej reported that IRQs stopped working in v4.7 on several
  platforms.  A typical scenario, from Ondrej's VT82C694X/694X, is:

ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: No IRQ available for PCI Interrupt Link [LNKA]
8139too :00:0f.0: PCI INT A: no GSI

  We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
  active at IRQ 11.  In that case, acpi_pci_link_allocate() only tries
  to use the active IRQ (IRQ 11) which also happens to be the SCI.

  We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
  irq_get_trigger_type(11) returns something other than
  IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
  instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
  available and give up.

  Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
  trigger, and polarity directly and we don't have to depend on
  irq_get_trigger_type().

  Link: http://lkml.kernel.org/r/201609251512.05657.li...@rainbow-software.org
  Reported-by: Ondrej Zary 

I don't understand what's broken about using irq_get_trigger_type().
The SCI is registered in the following path, which is certainly before
we try to enable LNKA for the 8139too device:

  acpi_init   # subsys_initcall
acpi_bus_init
  acpi_enable_subsystem
acpi_ev_install_xrupt_handlers
  acpi_ev_install_sci_handler
acpi_os_install_interrupt_handler(sci_interrupt, ...)
  acpi_gsi_to_irq
acpi_register_gsi
  irq_create_fwspec_mapping
irqd_set_trigger_type

In any event, I think this patch to add acpi_penalize_sci_irq() is
fine.

> Acked-by: Bjorn Helgaas 
> 
> > Link: https://lkml.org/lkml/2016/10/4/283
> > Signed-off-by: Sinan Kaya 
> > Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> > Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
> 
> "commit" is redundant; it's sufficient to say:
> 
>   Fixes: 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> 
> In fact, I don't think you really need to include "commit" in the
> reference to 9e5ed6d1fb87 above either.
> 
> 

Re: [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

[Bjorn Helgaas]

On Thu, Oct 20, 2016 at 08:58:14PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 19, 2016 at 06:21:03PM -0400, Sinan Kaya wrote:
> > The SCI penalize function was removed in two steps (first refactor
> > and then remove) and these changes are reverted here in one go.
> > 
> > The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> > refactored the original code so that SCI penalty is calculated dynamically
> > by the time get_penalty function is called. That change is partially
> > reverted here, specifically for the SCI IRQ alone.
> > 
> > The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> > ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> > penalty API with penalty calculation carried out dynamically and based
> > on the acpi_gbl_FADT.sci_interrupt value.
> > 
> > However, that new algorithm relies on the accurate setting of IRQ
> > types and that doesn't happen early enough on some platforms which
> > leads to incorrect penalty assignments for PCI IRQs.  In those cases,
> > irq_get_trigger_type() returns incorrect values for the IRQs in
> > question, because they have not been registered yet by the time the
> > penalties are calculated.
> > 
> > To fix this problem, we only need to fix the penalty for the SCI interrupt.
> > It seems better to add a single "sci_penalty" variable, set it to
> > PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> > otherwise, and add "sci_penalty" in when appropriate.  That should fix it
> > for *any* SCI IRQ, not just those less than 256, and we don't have to add
> > these extra penalty table entries that are all unused (except possibly for
> > one entry if we have an SCI in the 16-255 range).
> > 
> > For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> > penalize function") completely to restore the correct behavior.
> 
> I like this patch fine, except for the changelog.  I don't think it's
> useful to describe this as a revert and give all the historical
> details.  I think the important part is something like this:
> 
>   We previously used irq_get_trigger_type(irq) to help compute the
>   penalty for the SCI, but that depends on the SCI having been
>   registered already.  Add acpi_penalize_sci_irq() so platforms can
>   tell us the SCI IRQ, trigger, and polarity so we can compute the
>   penalty even before the SCI has been registered.

I think this is actually the critical patch that fixes the regression
reported by Ondrej, so the changelog really should include details
about the regression, e.g., something like this:

  ACPI: pci_link: Penalize SCI correctly

  Ondrej reported that IRQs stopped working in v4.7 on several
  platforms.  A typical scenario, from Ondrej's VT82C694X/694X, is:

ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: No IRQ available for PCI Interrupt Link [LNKA]
8139too :00:0f.0: PCI INT A: no GSI

  We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
  active at IRQ 11.  In that case, acpi_pci_link_allocate() only tries
  to use the active IRQ (IRQ 11) which also happens to be the SCI.

  We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
  irq_get_trigger_type(11) returns something other than
  IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
  instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
  available and give up.

  Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
  trigger, and polarity directly and we don't have to depend on
  irq_get_trigger_type().

  Link: http://lkml.kernel.org/r/201609251512.05657.li...@rainbow-software.org
  Reported-by: Ondrej Zary 

I don't understand what's broken about using irq_get_trigger_type().
The SCI is registered in the following path, which is certainly before
we try to enable LNKA for the 8139too device:

  acpi_init   # subsys_initcall
acpi_bus_init
  acpi_enable_subsystem
acpi_ev_install_xrupt_handlers
  acpi_ev_install_sci_handler
acpi_os_install_interrupt_handler(sci_interrupt, ...)
  acpi_gsi_to_irq
acpi_register_gsi
  irq_create_fwspec_mapping
irqd_set_trigger_type

In any event, I think this patch to add acpi_penalize_sci_irq() is
fine.

> Acked-by: Bjorn Helgaas 
> 
> > Link: https://lkml.org/lkml/2016/10/4/283
> > Signed-off-by: Sinan Kaya 
> > Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> > Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
> 
> "commit" is redundant; it's sufficient to say:
> 
>   Fixes: 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> 
> In fact, I don't think you really need to include "commit" in the
> reference to 9e5ed6d1fb87 above either.
> 
> > ---
> >  arch/x86/kernel/acpi/boot.c |  1 +
> >  

[PATCH] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lukasz Majewski]

The commit: a55944ca82d287ca099ca90413af857af9086773 has posed some extra
restrictions on blanking and unblanking frame buffer device.

Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.

This code in case of initial unblank of backlight device (default behaviour)
sets use_count to 1 and marks this particular backlight device as used
by all available fb devices (since it is not known during probe how much
and which fb devices will be assigned).

Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.


Signed-off-by: Lukasz Majewski 
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8 kernels.
It applies on 4.9-rcX SHA1: dcd4693cf47801b7d988ea897519de90dfd25d17.

---
 drivers/video/backlight/pwm_bl.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 8040fd6..def39e8 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -203,7 +203,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
struct pwm_args pargs;
-   int ret;
+   int ret, i;
 
if (!data) {
ret = pwm_backlight_parse_dt(>dev, );
@@ -349,6 +349,14 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 
bl->props.brightness = data->dft_brightness;
bl->props.power = initial_blank;
+
+   if (initial_blank == FB_BLANK_UNBLANK) {
+   for (i = 0; i < FB_MAX; i++)
+   bl->fb_bl_on[i] = true;
+
+   bl->use_count = 1;
+   }
+
backlight_update_status(bl);
 
platform_set_drvdata(pdev, bl);
-- 
2.1.4

[PATCH] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lukasz Majewski]

The commit: a55944ca82d287ca099ca90413af857af9086773 has posed some extra
restrictions on blanking and unblanking frame buffer device.

Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.

This code in case of initial unblank of backlight device (default behaviour)
sets use_count to 1 and marks this particular backlight device as used
by all available fb devices (since it is not known during probe how much
and which fb devices will be assigned).

Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.


Signed-off-by: Lukasz Majewski 
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8 kernels.
It applies on 4.9-rcX SHA1: dcd4693cf47801b7d988ea897519de90dfd25d17.

---
 drivers/video/backlight/pwm_bl.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 8040fd6..def39e8 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -203,7 +203,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
struct pwm_args pargs;
-   int ret;
+   int ret, i;
 
if (!data) {
ret = pwm_backlight_parse_dt(>dev, );
@@ -349,6 +349,14 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 
bl->props.brightness = data->dft_brightness;
bl->props.power = initial_blank;
+
+   if (initial_blank == FB_BLANK_UNBLANK) {
+   for (i = 0; i < FB_MAX; i++)
+   bl->fb_bl_on[i] = true;
+
+   bl->use_count = 1;
+   }
+
backlight_update_status(bl);
 
platform_set_drvdata(pdev, bl);
-- 
2.1.4

Re: Disabling an interrupt in the handler locks the system up

[Mason]

On 22/10/2016 13:37, Marc Zyngier wrote:

> Mason wrote:
> 
>> In my mental picture of interrupts (which is obviously so
>> incomplete as to be wrong) interrupts are a way for hardware
>> to tell the CPU that they urgently need the CPU's attention.
> 
> That's how the CPU interprets it, but this is even more basic than
> that, see below.
> 
>> Obviously, the hardware being idle (line high) is not an urgent
>> matter which interests the CPU. Likewise, I'm not sure the CPU
>> cares that the hardware is busy (line low). It seems to me the
>> interesting event from the CPU's perspective is when the
>> hardware completes a "task" (transition from low to high).
> 
> There is no such thing as "busy" when it comes to interrupts. An
> interrupt signals the CPU that some device-specific condition has been
> satisfied. It could be "I've received a packet" or "Battery is about to
> explode", depending if the device is a network controller or a
> temperature sensor. The interrupt doesn't describe the process that
> leads to that condition (packet being received or temperature rising),
> but the condition itself.
> 
> In your cases, as the device seems to do some form of processing
> (you're talking about task completion), then the interrupt seems to
> describe exactly this ("I'm done").

The device is a graphics engine, which can be programmed to perform
some operation on one or several frame buffers stored in memory.
It outputs its state (idle vs busy) on interrupt line 23.

>> So I had originally configured the interrupt as IRQ_TYPE_EDGE_RISING.
>> (There is an edge detection block in the irqchip, but the HW designer
>> warned me that at low frequencies, it is possible to "miss" some edges,
>> and we should prefer level triggers if possible.)
> 
> Level and edge are not interchangeable. They do describe very different
> thing:
> 
> - Level indicates a persistent state, which implies that the device
>   needs to be serviced so that this condition can be cleared (the UART
>   has received a character, and won't be able to received another until
>   it has been read by the CPU). Once the device has been serviced and
>   that condition cleared, it will lower its interrupt line.

With this graphics engine, there is nothing the CPU can do to
change what the engine outputs on the interrupt line:

When the graphics engine is idle, the line remains high, forever.
When the graphics engine is busy, the line remains low, until
all operations have been performed (engine idle).

All the CPU can do is mask the interrupt line at the interrupt
controller, as far as I understand.

> - Edge is indicative of an event having occurred ("I'm done") that
>   doesn't require any action from the CPU. Because the device can
>   continue its life without being poked by the CPU, it can continue
>   delivering interrupts even if the first one hasn't been serviced.
>   Being edge triggered, the signals get coalesced into a single
>   interrupt. For example, the temperature sensor will say "Temperature
>   rising" multiple times before the battery explodes, and it is the
>   CPU's job to go and read the sensor to find out by how much it has
>   risen.
> 
> If your device only sends a pulse, then it is edge triggered, and it
> should be treated as such, no matter what your HW guy is saying. This
> usually involves looking at the device to find out how many times the
> interrupt has been generated (assuming the device is some kind of
> processing element). Of course, this is racy (interrupts can still be
> generated whilst you're processing them), and you should design your
> interrupt handler to take care of the possible race.

It is clear that the block does not send a pulse on the
interrupt line.

For reasons I don't understand, Linux didn't hang when I set
the IRQ type to IRQ_TYPE_EDGE_RISING, so it seemed better
than locking up the system.

I'm also fuzzy on what purpose the edge detector is supposed
to serve... I had the impression is what supposed to "capture"
an edge, to turn it into a level?

> So, to make it short: find out how your device works, and configure
> your interrupt controller in a similar way. Write your device driver
> with the interrupt policy in mind (state vs event). Keep it simple.

Thomas said "We describe the level which is raising the interrupt".
But I'm not sure I want the state "engine is busy" to raise an
interrupt. "engine is idle" makes more sense. But you said it's
stupid to set IRQ_TYPE_LEVEL_HIGH... /me confused

Maybe the fact that disable_irq locks the system up is an orthogonal
issue that needs to be fixed anyway.

Regards.

Re: Disabling an interrupt in the handler locks the system up

[Mason]

On 22/10/2016 13:37, Marc Zyngier wrote:

> Mason wrote:
> 
>> In my mental picture of interrupts (which is obviously so
>> incomplete as to be wrong) interrupts are a way for hardware
>> to tell the CPU that they urgently need the CPU's attention.
> 
> That's how the CPU interprets it, but this is even more basic than
> that, see below.
> 
>> Obviously, the hardware being idle (line high) is not an urgent
>> matter which interests the CPU. Likewise, I'm not sure the CPU
>> cares that the hardware is busy (line low). It seems to me the
>> interesting event from the CPU's perspective is when the
>> hardware completes a "task" (transition from low to high).
> 
> There is no such thing as "busy" when it comes to interrupts. An
> interrupt signals the CPU that some device-specific condition has been
> satisfied. It could be "I've received a packet" or "Battery is about to
> explode", depending if the device is a network controller or a
> temperature sensor. The interrupt doesn't describe the process that
> leads to that condition (packet being received or temperature rising),
> but the condition itself.
> 
> In your cases, as the device seems to do some form of processing
> (you're talking about task completion), then the interrupt seems to
> describe exactly this ("I'm done").

The device is a graphics engine, which can be programmed to perform
some operation on one or several frame buffers stored in memory.
It outputs its state (idle vs busy) on interrupt line 23.

>> So I had originally configured the interrupt as IRQ_TYPE_EDGE_RISING.
>> (There is an edge detection block in the irqchip, but the HW designer
>> warned me that at low frequencies, it is possible to "miss" some edges,
>> and we should prefer level triggers if possible.)
> 
> Level and edge are not interchangeable. They do describe very different
> thing:
> 
> - Level indicates a persistent state, which implies that the device
>   needs to be serviced so that this condition can be cleared (the UART
>   has received a character, and won't be able to received another until
>   it has been read by the CPU). Once the device has been serviced and
>   that condition cleared, it will lower its interrupt line.

With this graphics engine, there is nothing the CPU can do to
change what the engine outputs on the interrupt line:

When the graphics engine is idle, the line remains high, forever.
When the graphics engine is busy, the line remains low, until
all operations have been performed (engine idle).

All the CPU can do is mask the interrupt line at the interrupt
controller, as far as I understand.

> - Edge is indicative of an event having occurred ("I'm done") that
>   doesn't require any action from the CPU. Because the device can
>   continue its life without being poked by the CPU, it can continue
>   delivering interrupts even if the first one hasn't been serviced.
>   Being edge triggered, the signals get coalesced into a single
>   interrupt. For example, the temperature sensor will say "Temperature
>   rising" multiple times before the battery explodes, and it is the
>   CPU's job to go and read the sensor to find out by how much it has
>   risen.
> 
> If your device only sends a pulse, then it is edge triggered, and it
> should be treated as such, no matter what your HW guy is saying. This
> usually involves looking at the device to find out how many times the
> interrupt has been generated (assuming the device is some kind of
> processing element). Of course, this is racy (interrupts can still be
> generated whilst you're processing them), and you should design your
> interrupt handler to take care of the possible race.

It is clear that the block does not send a pulse on the
interrupt line.

For reasons I don't understand, Linux didn't hang when I set
the IRQ type to IRQ_TYPE_EDGE_RISING, so it seemed better
than locking up the system.

I'm also fuzzy on what purpose the edge detector is supposed
to serve... I had the impression is what supposed to "capture"
an edge, to turn it into a level?

> So, to make it short: find out how your device works, and configure
> your interrupt controller in a similar way. Write your device driver
> with the interrupt policy in mind (state vs event). Keep it simple.

Thomas said "We describe the level which is raising the interrupt".
But I'm not sure I want the state "engine is busy" to raise an
interrupt. "engine is idle" makes more sense. But you said it's
stupid to set IRQ_TYPE_LEVEL_HIGH... /me confused

Maybe the fact that disable_irq locks the system up is an orthogonal
issue that needs to be fixed anyway.

Regards.

[PATCH v2 1/7] iio:core: add a callback to allow drivers to provide _available attributes

[Peter Rosin]

From: Jonathan Cameron 

A large number of attributes can only take a limited range of values.
Currently in IIO this is handled by directly registering additional
*_available attributes thus providing this information to userspace.

It is desirable to provide this information via the core for much the same
reason this was done for the actual channel information attributes in the
first place.  If it isn't there, then it can only really be accessed from
userspace.  Other in kernel IIO consumers have no access to what valid
parameters are.

Two forms are currently supported:
* list of values in one particular IIO_VAL_* format.
e.g. 1.30 1.50 1.73
* range specification with a step size:
e.g. [1.00 0.50 2.50]
equivalent to 1.00 1.500 2.00 2.50

An addition set of masks are used to allow different sharing rules for the
*_available attributes generated.

This allows for example:

in_accel_x_offset
in_accel_y_offset
in_accel_offset_available.

We could have gone with having a specification for each and every
info_mask element but that would have meant changing the existing userspace
ABI.  This approach does not.

Signed-off-by: Jonathan Cameron 
[rather mindlessly forward ported from approx 3 years ago /peda]
Signed-off-by: Peter Rosin 
---
 drivers/iio/industrialio-core.c | 232 +++-
 include/linux/iio/iio.h |  11 ++
 include/linux/iio/types.h   |   5 +
 3 files changed, 223 insertions(+), 25 deletions(-)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index fc340ed3dca1..93c69ebeda1e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -575,51 +575,41 @@ int of_iio_read_mount_matrix(const struct device *dev,
 #endif
 EXPORT_SYMBOL(of_iio_read_mount_matrix);
 
-/**
- * iio_format_value() - Formats a IIO value into its string representation
- * @buf:   The buffer to which the formatted value gets written
- * @type:  One of the IIO_VAL_... constants. This decides how the val
- * and val2 parameters are formatted.
- * @size:  Number of IIO value entries contained in vals
- * @vals:  Pointer to the values, exact meaning depends on the
- * type parameter.
- *
- * Return: 0 by default, a negative number on failure or the
- *total number of characters written for a type that belongs
- *to the IIO_VAL_... constant.
- */
-ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals)
+static ssize_t __iio_format_value(char *buf, unsigned int type,
+ int size, const int *vals)
 {
unsigned long long tmp;
+   int tmp0, tmp1;
bool scale_db = false;
 
switch (type) {
case IIO_VAL_INT:
-   return sprintf(buf, "%d\n", vals[0]);
+   return sprintf(buf, "%d", vals[0]);
case IIO_VAL_INT_PLUS_MICRO_DB:
scale_db = true;
case IIO_VAL_INT_PLUS_MICRO:
if (vals[1] < 0)
-   return sprintf(buf, "-%d.%06u%s\n", abs(vals[0]),
+   return sprintf(buf, "-%d.%06u%s", abs(vals[0]),
   -vals[1], scale_db ? " dB" : "");
else
-   return sprintf(buf, "%d.%06u%s\n", vals[0], vals[1],
+   return sprintf(buf, "%d.%06u%s", vals[0], vals[1],
scale_db ? " dB" : "");
case IIO_VAL_INT_PLUS_NANO:
if (vals[1] < 0)
-   return sprintf(buf, "-%d.%09u\n", abs(vals[0]),
+   return sprintf(buf, "-%d.%09u", abs(vals[0]),
   -vals[1]);
else
-   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
+   return sprintf(buf, "%d.%09u", vals[0], vals[1]);
case IIO_VAL_FRACTIONAL:
tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
-   vals[0] = (int)div_s64_rem(tmp, 10, [1]);
-   return sprintf(buf, "%d.%09u\n", vals[0], abs(vals[1]));
+   tmp1 = vals[1];
+   tmp0 = (int)div_s64_rem(tmp, 10, );
+   return sprintf(buf, "%d.%09u", tmp0, abs(tmp1));
case IIO_VAL_FRACTIONAL_LOG2:
tmp = (s64)vals[0] * 10LL >> vals[1];
-   vals[1] = do_div(tmp, 10LL);
-   vals[0] = tmp;
-   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
+   tmp1 = do_div(tmp, 10LL);
+   tmp0 = tmp;
+   return sprintf(buf, "%d.%09u", tmp0, tmp1);
case IIO_VAL_INT_MULTIPLE:
{
int i;
@@ -628,13 +618,34 @@ ssize_t iio_format_value(char *buf, unsigned int type, 
int size, int *vals)
for (i = 0; i < size; 

[PATCH v2 1/7] iio:core: add a callback to allow drivers to provide _available attributes

[Peter Rosin]

From: Jonathan Cameron 

A large number of attributes can only take a limited range of values.
Currently in IIO this is handled by directly registering additional
*_available attributes thus providing this information to userspace.

It is desirable to provide this information via the core for much the same
reason this was done for the actual channel information attributes in the
first place.  If it isn't there, then it can only really be accessed from
userspace.  Other in kernel IIO consumers have no access to what valid
parameters are.

Two forms are currently supported:
* list of values in one particular IIO_VAL_* format.
e.g. 1.30 1.50 1.73
* range specification with a step size:
e.g. [1.00 0.50 2.50]
equivalent to 1.00 1.500 2.00 2.50

An addition set of masks are used to allow different sharing rules for the
*_available attributes generated.

This allows for example:

in_accel_x_offset
in_accel_y_offset
in_accel_offset_available.

We could have gone with having a specification for each and every
info_mask element but that would have meant changing the existing userspace
ABI.  This approach does not.

Signed-off-by: Jonathan Cameron 
[rather mindlessly forward ported from approx 3 years ago /peda]
Signed-off-by: Peter Rosin 
---
 drivers/iio/industrialio-core.c | 232 +++-
 include/linux/iio/iio.h |  11 ++
 include/linux/iio/types.h   |   5 +
 3 files changed, 223 insertions(+), 25 deletions(-)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index fc340ed3dca1..93c69ebeda1e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -575,51 +575,41 @@ int of_iio_read_mount_matrix(const struct device *dev,
 #endif
 EXPORT_SYMBOL(of_iio_read_mount_matrix);
 
-/**
- * iio_format_value() - Formats a IIO value into its string representation
- * @buf:   The buffer to which the formatted value gets written
- * @type:  One of the IIO_VAL_... constants. This decides how the val
- * and val2 parameters are formatted.
- * @size:  Number of IIO value entries contained in vals
- * @vals:  Pointer to the values, exact meaning depends on the
- * type parameter.
- *
- * Return: 0 by default, a negative number on failure or the
- *total number of characters written for a type that belongs
- *to the IIO_VAL_... constant.
- */
-ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals)
+static ssize_t __iio_format_value(char *buf, unsigned int type,
+ int size, const int *vals)
 {
unsigned long long tmp;
+   int tmp0, tmp1;
bool scale_db = false;
 
switch (type) {
case IIO_VAL_INT:
-   return sprintf(buf, "%d\n", vals[0]);
+   return sprintf(buf, "%d", vals[0]);
case IIO_VAL_INT_PLUS_MICRO_DB:
scale_db = true;
case IIO_VAL_INT_PLUS_MICRO:
if (vals[1] < 0)
-   return sprintf(buf, "-%d.%06u%s\n", abs(vals[0]),
+   return sprintf(buf, "-%d.%06u%s", abs(vals[0]),
   -vals[1], scale_db ? " dB" : "");
else
-   return sprintf(buf, "%d.%06u%s\n", vals[0], vals[1],
+   return sprintf(buf, "%d.%06u%s", vals[0], vals[1],
scale_db ? " dB" : "");
case IIO_VAL_INT_PLUS_NANO:
if (vals[1] < 0)
-   return sprintf(buf, "-%d.%09u\n", abs(vals[0]),
+   return sprintf(buf, "-%d.%09u", abs(vals[0]),
   -vals[1]);
else
-   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
+   return sprintf(buf, "%d.%09u", vals[0], vals[1]);
case IIO_VAL_FRACTIONAL:
tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
-   vals[0] = (int)div_s64_rem(tmp, 10, [1]);
-   return sprintf(buf, "%d.%09u\n", vals[0], abs(vals[1]));
+   tmp1 = vals[1];
+   tmp0 = (int)div_s64_rem(tmp, 10, );
+   return sprintf(buf, "%d.%09u", tmp0, abs(tmp1));
case IIO_VAL_FRACTIONAL_LOG2:
tmp = (s64)vals[0] * 10LL >> vals[1];
-   vals[1] = do_div(tmp, 10LL);
-   vals[0] = tmp;
-   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
+   tmp1 = do_div(tmp, 10LL);
+   tmp0 = tmp;
+   return sprintf(buf, "%d.%09u", tmp0, tmp1);
case IIO_VAL_INT_MULTIPLE:
{
int i;
@@ -628,13 +618,34 @@ ssize_t iio_format_value(char *buf, unsigned int type, 
int size, int *vals)
for (i = 0; i < size; ++i)
len += snprintf([len], 

Re: [PATCH v7] net: ip, diag -- Add diag interface for raw sockets

[David Miller]

From: Cyrill Gorcunov 
Date: Fri, 21 Oct 2016 13:03:44 +0300

> In criu we are actively using diag interface to collect sockets
> present in the system when dumping applications. And while for
> unix, tcp, udp[lite], packet, netlink it works as expected,
> the raw sockets do not have. Thus add it.

Applied, thanks.

Re: [PATCH v7] net: ip, diag -- Add diag interface for raw sockets

[David Miller]

From: Cyrill Gorcunov 
Date: Fri, 21 Oct 2016 13:03:44 +0300

> In criu we are actively using diag interface to collect sockets
> present in the system when dumping applications. And while for
> unix, tcp, udp[lite], packet, netlink it works as expected,
> the raw sockets do not have. Thus add it.

Applied, thanks.

Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

[Marek Vasut]

On 10/22/2016 01:00 PM, Jagan Teki wrote:
> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen
>  wrote:
>> Hi all,
>>
>> This series extends support of SPI protocols to new protocols such as
>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the right
>> op codes, timing parameters (number of mode and dummy cycles) and erase
>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP)
>> tables, when available, as defined in the JEDEC JESD216 specifications.
>>
>> When SFDP tables are not available, legacy settings are still used for
>> backward compatibility (SPI and earlier QSPI memories).
>>
>> Support of SPI memories >128Mbits is also improved by using the 4byte
>> address instruction set, when available. Using those dedicated op codes
>> is stateless as opposed to enter the 4byte address mode, hence a better
>> compatibility with some boot loaders which expect to use 3byte address
>> op codes.
> 
> The memories which are > 128Mbits should have 4-bytes addressing
> support based on my experience, do you think BAR is also required
> atleast from spi-nor side?

Yes, I believe BAR is still required for broken/dumb flash chips.
Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-(

-- 
Best regards,
Marek Vasut

Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

[Marek Vasut]

On 10/22/2016 01:00 PM, Jagan Teki wrote:
> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen
>  wrote:
>> Hi all,
>>
>> This series extends support of SPI protocols to new protocols such as
>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the right
>> op codes, timing parameters (number of mode and dummy cycles) and erase
>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP)
>> tables, when available, as defined in the JEDEC JESD216 specifications.
>>
>> When SFDP tables are not available, legacy settings are still used for
>> backward compatibility (SPI and earlier QSPI memories).
>>
>> Support of SPI memories >128Mbits is also improved by using the 4byte
>> address instruction set, when available. Using those dedicated op codes
>> is stateless as opposed to enter the 4byte address mode, hence a better
>> compatibility with some boot loaders which expect to use 3byte address
>> op codes.
> 
> The memories which are > 128Mbits should have 4-bytes addressing
> support based on my experience, do you think BAR is also required
> atleast from spi-nor side?

Yes, I believe BAR is still required for broken/dumb flash chips.
Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-(

-- 
Best regards,
Marek Vasut

[PATCH] miscdevice: introduce builtin_misc_device

[Paul Gortmaker]

This is basically the same as module_misc_device but without the
presence of an exit/remove function.   Similar in nature to the
commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance").

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Paul Gortmaker 
---

[I've got several users of this in my local queue; but I'll stagger
 those and this by a merge window to avoid dependency issues.]

 include/linux/miscdevice.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
index 722698a43d79..a426cb55dc43 100644
--- a/include/linux/miscdevice.h
+++ b/include/linux/miscdevice.h
@@ -72,6 +72,13 @@ extern int misc_register(struct miscdevice *misc);
 extern void misc_deregister(struct miscdevice *misc);
 
 /*
+ * Helper macro for drivers that don't do anything special in the initcall.
+ * This helps in eleminating of boilerplate code.
+ */
+#define builtin_misc_device(__misc_device) \
+   builtin_driver(__misc_device, misc_register)
+
+/*
  * Helper macro for drivers that don't do anything special in module init / 
exit
  * call. This helps in eleminating of boilerplate code.
  */
-- 
2.8.4

[PATCH] miscdevice: introduce builtin_misc_device

[Paul Gortmaker]

This is basically the same as module_misc_device but without the
presence of an exit/remove function.   Similar in nature to the
commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance").

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Paul Gortmaker 
---

[I've got several users of this in my local queue; but I'll stagger
 those and this by a merge window to avoid dependency issues.]

 include/linux/miscdevice.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
index 722698a43d79..a426cb55dc43 100644
--- a/include/linux/miscdevice.h
+++ b/include/linux/miscdevice.h
@@ -72,6 +72,13 @@ extern int misc_register(struct miscdevice *misc);
 extern void misc_deregister(struct miscdevice *misc);
 
 /*
+ * Helper macro for drivers that don't do anything special in the initcall.
+ * This helps in eleminating of boilerplate code.
+ */
+#define builtin_misc_device(__misc_device) \
+   builtin_driver(__misc_device, misc_register)
+
+/*
  * Helper macro for drivers that don't do anything special in module init / 
exit
  * call. This helps in eleminating of boilerplate code.
  */
-- 
2.8.4

[PATCH] dma: tegra210-adma: convert TEGRA210_ADMA from bool to tristate

[Paul Gortmaker]

This driver currently uses modular infrastructure but is controlled
by a bool Kconfig.

There is a general consensus from the DMA reviewers and maintainers
that "if it can be modular, it should be modular" in order to keep
the bzImage size under control for multi platform kernels.

Build tested only.  Also needed some new pm_clk symbols exported
before this commit is applied to tree in order to avoid modpost
errors like:

  ERROR: "pm_clk_add_clk" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_create" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_destroy" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_suspend" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_resume" [drivers/dma/tegra210-adma.ko] undefined!

These were added as exports in the v4.8-rc1 merge window.

Cc: Laxman Dewangan 
Cc: Jon Hunter 
Acked-by: Jon Hunter 
Cc: Dan Williams 
Cc: Vinod Koul 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: dmaeng...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index af63a6bcf564..4595f5009244 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -479,7 +479,7 @@ config TEGRA20_APB_DMA
  or vice versa. It does not support memory to memory data transfer.
 
 config TEGRA210_ADMA
-   bool "NVIDIA Tegra210 ADMA support"
+   tristate "NVIDIA Tegra210 ADMA support"
depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) && PM_CLK
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
-- 
2.10.0

[PATCH] dma: tegra210-adma: convert TEGRA210_ADMA from bool to tristate

[Paul Gortmaker]

This driver currently uses modular infrastructure but is controlled
by a bool Kconfig.

There is a general consensus from the DMA reviewers and maintainers
that "if it can be modular, it should be modular" in order to keep
the bzImage size under control for multi platform kernels.

Build tested only.  Also needed some new pm_clk symbols exported
before this commit is applied to tree in order to avoid modpost
errors like:

  ERROR: "pm_clk_add_clk" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_create" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_destroy" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_suspend" [drivers/dma/tegra210-adma.ko] undefined!
  ERROR: "pm_clk_resume" [drivers/dma/tegra210-adma.ko] undefined!

These were added as exports in the v4.8-rc1 merge window.

Cc: Laxman Dewangan 
Cc: Jon Hunter 
Acked-by: Jon Hunter 
Cc: Dan Williams 
Cc: Vinod Koul 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: dmaeng...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index af63a6bcf564..4595f5009244 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -479,7 +479,7 @@ config TEGRA20_APB_DMA
  or vice versa. It does not support memory to memory data transfer.
 
 config TEGRA210_ADMA
-   bool "NVIDIA Tegra210 ADMA support"
+   tristate "NVIDIA Tegra210 ADMA support"
depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) && PM_CLK
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
-- 
2.10.0

Re: [PATCH 0/5] reset: make non-modular drivers really non modular

[Paul Gortmaker]

[[PATCH 0/5] reset: make non-modular drivers really non modular] On 13/06/2016 
(Mon 14:03) Paul Gortmaker wrote:

> For anyone new to the underlying goal of this cleanup, we are trying to
> not use module support for code that can never be built as a module since:

Hi Philipp,

I sent this several months ago, and aside from a couple Ack'd by, there
was no negative feedback or similar.

Since then there have been two more drivers added with the same issue.

reset-make-ath79-explicitly-non-modular.patch
reset-pistachio-make-it-explicitly-non-modular.patch

Should I assume that the original send has fallen through the cracks and
resend with the two new patches, or do you still have the original five
in a queue somewhere?

I'd like to merge as many of these as I can via their respective
maintainers vs. trying to send them to Linus directly.

Thanks,
Paul.
--

> 
>  (1) it is easy to accidentally write unused module_exit and remove code
>  (2) it can be misleading when reading the source, thinking it can be
>  modular when the Makefile and/or Kconfig prohibit it
>  (3) it requires the include of the module.h header file which in turn
>  includes nearly everything else, thus adding to CPP overhead.
>  (4) it gets copied/replicated into other code and spreads like weeds.
> 
> Fortunately the reset dir is in pretty good shape, and there are only
> five instances of non-modular code using modular funcionality/macros.
> 
> Changes seen here cover the following categories:
> 
>   -just replacement of modular macros with their non-modular
>equivalents that CPP would have inserted anyway
> 
>   -the removal of including module.h ; replaced with init.h
>as required based on whether the file already had it.
> 
>   -the removal of any ".remove" functions that were hooked into
>the driver struct.   This ".remove" function would of
>course not be called from the __exit function since that was
>never run.  However in theory, someone could have triggered it
>via sysfs unbind, even though there isn't a sensible use case
>for doing so.  So to cover that possibility, we've also disabled
>sysfs unbind in the driver.
> 
> Recently several of these drivers got removal of the ".remove" fcns
> via other changes, so only one remains for which that happens here.
> 
> There are no initcall level changes here; everything was at the level
> of device_initcall and remains so, by using the builtin equivalents.
> 
> Build tested for several different key arch on a recent linux-next
> tree to ensure no silly typos crept in.
> 
> If there is a desire for any of these to be modular, we can definitely
> consider that, but by default the changes here keep the code consistent
> with existing behaviour and do not expand functionality into the modular
> realm that I can't run time test.
> 
> Paul.
> 
> ---
> 
> Cc: Antoine Tenart 
> Cc: Joachim Eastwood 
> Cc: Masahiro Yamada 
> Cc: Maxime Ripard 
> Cc: Michal Simek 
> Cc: Moritz Fischer 
> Cc: Philipp Zabel 
> Cc: Sebastian Hesselbarth 
> Cc: "Sören Brinkmann" 
> Cc: Steffen Trumtrar 
> 
> 
> Paul Gortmaker (5):
>   reset: berlin: make it explicitly non-modular
>   reset: socfpga: make it explicitly non-modular
>   reset: sunxi: make it explicitly non-modular
>   reset: zynq: make it explicitly non-modular
>   reset: lpc18xx: make it explicitly non-modular
> 
>  drivers/reset/reset-berlin.c  | 12 
>  drivers/reset/reset-lpc18xx.c | 32 +---
>  drivers/reset/reset-socfpga.c | 10 --
>  drivers/reset/reset-sunxi.c   |  9 ++---
>  drivers/reset/reset-zynq.c| 10 --
>  5 files changed, 19 insertions(+), 54 deletions(-)
> 
> -- 
> 2.8.4
> 

Re: [PATCH 0/5] reset: make non-modular drivers really non modular

[Paul Gortmaker]

[[PATCH 0/5] reset: make non-modular drivers really non modular] On 13/06/2016 
(Mon 14:03) Paul Gortmaker wrote:

> For anyone new to the underlying goal of this cleanup, we are trying to
> not use module support for code that can never be built as a module since:

Hi Philipp,

I sent this several months ago, and aside from a couple Ack'd by, there
was no negative feedback or similar.

Since then there have been two more drivers added with the same issue.

reset-make-ath79-explicitly-non-modular.patch
reset-pistachio-make-it-explicitly-non-modular.patch

Should I assume that the original send has fallen through the cracks and
resend with the two new patches, or do you still have the original five
in a queue somewhere?

I'd like to merge as many of these as I can via their respective
maintainers vs. trying to send them to Linus directly.

Thanks,
Paul.
--

> 
>  (1) it is easy to accidentally write unused module_exit and remove code
>  (2) it can be misleading when reading the source, thinking it can be
>  modular when the Makefile and/or Kconfig prohibit it
>  (3) it requires the include of the module.h header file which in turn
>  includes nearly everything else, thus adding to CPP overhead.
>  (4) it gets copied/replicated into other code and spreads like weeds.
> 
> Fortunately the reset dir is in pretty good shape, and there are only
> five instances of non-modular code using modular funcionality/macros.
> 
> Changes seen here cover the following categories:
> 
>   -just replacement of modular macros with their non-modular
>equivalents that CPP would have inserted anyway
> 
>   -the removal of including module.h ; replaced with init.h
>as required based on whether the file already had it.
> 
>   -the removal of any ".remove" functions that were hooked into
>the driver struct.   This ".remove" function would of
>course not be called from the __exit function since that was
>never run.  However in theory, someone could have triggered it
>via sysfs unbind, even though there isn't a sensible use case
>for doing so.  So to cover that possibility, we've also disabled
>sysfs unbind in the driver.
> 
> Recently several of these drivers got removal of the ".remove" fcns
> via other changes, so only one remains for which that happens here.
> 
> There are no initcall level changes here; everything was at the level
> of device_initcall and remains so, by using the builtin equivalents.
> 
> Build tested for several different key arch on a recent linux-next
> tree to ensure no silly typos crept in.
> 
> If there is a desire for any of these to be modular, we can definitely
> consider that, but by default the changes here keep the code consistent
> with existing behaviour and do not expand functionality into the modular
> realm that I can't run time test.
> 
> Paul.
> 
> ---
> 
> Cc: Antoine Tenart 
> Cc: Joachim Eastwood 
> Cc: Masahiro Yamada 
> Cc: Maxime Ripard 
> Cc: Michal Simek 
> Cc: Moritz Fischer 
> Cc: Philipp Zabel 
> Cc: Sebastian Hesselbarth 
> Cc: "Sören Brinkmann" 
> Cc: Steffen Trumtrar 
> 
> 
> Paul Gortmaker (5):
>   reset: berlin: make it explicitly non-modular
>   reset: socfpga: make it explicitly non-modular
>   reset: sunxi: make it explicitly non-modular
>   reset: zynq: make it explicitly non-modular
>   reset: lpc18xx: make it explicitly non-modular
> 
>  drivers/reset/reset-berlin.c  | 12 
>  drivers/reset/reset-lpc18xx.c | 32 +---
>  drivers/reset/reset-socfpga.c | 10 --
>  drivers/reset/reset-sunxi.c   |  9 ++---
>  drivers/reset/reset-zynq.c| 10 --
>  5 files changed, 19 insertions(+), 54 deletions(-)
> 
> -- 
> 2.8.4
> 

Re: [PATCH v2 4/4] cpufreq: pxa: convert to clock API

[Robert Jarzmik]

Viresh Kumar  writes:

> On 15-10-16, 21:57, Robert Jarzmik wrote:
>> As the clock settings have been introduced into the clock pxa drivers,
>> which are now available to change the CPU clock by themselves, remove
>> the clock handling from this driver, and rely on pxa clock drivers.
>> 
>> Signed-off-by: Robert Jarzmik 
>> ---
>> Since v1: added !OF Kconfig dependency
>> ---
>>  drivers/cpufreq/Kconfig.arm  |   2 +-
>>  drivers/cpufreq/pxa2xx-cpufreq.c | 191 
>> ---
>>  2 files changed, 40 insertions(+), 153 deletions(-)
>
> Acked-by: Viresh Kumar 

Okay, after some more testing, I'd like to remove the !OF for next iteration.
The reason is that I have a usecase where I have a single kernel image with
devictree support (ie CONFIG_OF=y), but with support for both devicetree and
legacy platforms. In this case, a platform such as lubbock can boot :
 - with devicetree
 - with legacy arch/arm/mach-pxa/lubbock.c

In this kernel, the !OF Kconfig prevents the legacy version from working, as
pxa2xx-cpufreq is descarded even if it is needed in the legacy version.

Therefore, I'd like to respin without this !OF.

Cheers.

-- 
Robert

Re: [PATCH v2 4/4] cpufreq: pxa: convert to clock API

[Robert Jarzmik]

Viresh Kumar  writes:

> On 15-10-16, 21:57, Robert Jarzmik wrote:
>> As the clock settings have been introduced into the clock pxa drivers,
>> which are now available to change the CPU clock by themselves, remove
>> the clock handling from this driver, and rely on pxa clock drivers.
>> 
>> Signed-off-by: Robert Jarzmik 
>> ---
>> Since v1: added !OF Kconfig dependency
>> ---
>>  drivers/cpufreq/Kconfig.arm  |   2 +-
>>  drivers/cpufreq/pxa2xx-cpufreq.c | 191 
>> ---
>>  2 files changed, 40 insertions(+), 153 deletions(-)
>
> Acked-by: Viresh Kumar 

Okay, after some more testing, I'd like to remove the !OF for next iteration.
The reason is that I have a usecase where I have a single kernel image with
devictree support (ie CONFIG_OF=y), but with support for both devicetree and
legacy platforms. In this case, a platform such as lubbock can boot :
 - with devicetree
 - with legacy arch/arm/mach-pxa/lubbock.c

In this kernel, the !OF Kconfig prevents the legacy version from working, as
pxa2xx-cpufreq is descarded even if it is needed in the legacy version.

Therefore, I'd like to respin without this !OF.

Cheers.

-- 
Robert

Re: [PATCH] net: skip genenerating uevents for network namespaces that are exiting

[David Miller]

From: Andrei Vagin 
Date: Thu, 20 Oct 2016 19:46:26 -0700

> @@ -1525,6 +1530,9 @@ void netdev_unregister_kobject(struct net_device *ndev)
>  {
>   struct device *dev = &(ndev->dev);
>  
> + if (!list_empty(_net(ndev)->exit_list))
> + dev->kobj.uevent_suppress = 1;
> +

Please use "dev_set_uevent_suppress(dev, 1);"

Re: [PATCH] net: skip genenerating uevents for network namespaces that are exiting

[David Miller]

From: Andrei Vagin 
Date: Thu, 20 Oct 2016 19:46:26 -0700

> @@ -1525,6 +1530,9 @@ void netdev_unregister_kobject(struct net_device *ndev)
>  {
>   struct device *dev = &(ndev->dev);
>  
> + if (!list_empty(_net(ndev)->exit_list))
> + dev->kobj.uevent_suppress = 1;
> +

Please use "dev_set_uevent_suppress(dev, 1);"

Re: [PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[SF Markus Elfring]

>> @@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, 
>> void *data)
>>  int cpu;
>>  
>>  cpu = *(loff_t *) data;
>> -
>> -if (!cpu) {
>> +if (!cpu)
>>  seq_printf(file,
>> -   "# cpu ptc_l newrid ptc_flushes nodes_flushed 
>> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
>> ipi_nsec\n");
>> -seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
>> sn2_flush_opt);
>> -}
>> +   "# cpu ptc_l newrid ptc_flushes nodes_flushed 
>> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
>> ipi_nsec\n"
>> +   "# ptctest %d, flushopt %d\n",
>> +   sn2_ptctest, sn2_flush_opt);
>>  
>>  if (cpu < nr_cpu_ids && cpu_online(cpu)) {
>>  stat = _cpu(ptcstats, cpu);
> 
> Please think more.
> 
> printf has to inspect character by character looking for
> a vsprintf % character and 0 termination.
> 
> seq_puts does a strlen then memcpy.

Would you prefer to use this function also at this source code place?

Regards,
Markus

Re: [PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[SF Markus Elfring]

>> @@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, 
>> void *data)
>>  int cpu;
>>  
>>  cpu = *(loff_t *) data;
>> -
>> -if (!cpu) {
>> +if (!cpu)
>>  seq_printf(file,
>> -   "# cpu ptc_l newrid ptc_flushes nodes_flushed 
>> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
>> ipi_nsec\n");
>> -seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
>> sn2_flush_opt);
>> -}
>> +   "# cpu ptc_l newrid ptc_flushes nodes_flushed 
>> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
>> ipi_nsec\n"
>> +   "# ptctest %d, flushopt %d\n",
>> +   sn2_ptctest, sn2_flush_opt);
>>  
>>  if (cpu < nr_cpu_ids && cpu_online(cpu)) {
>>  stat = _cpu(ptcstats, cpu);
> 
> Please think more.
> 
> printf has to inspect character by character looking for
> a vsprintf % character and 0 termination.
> 
> seq_puts does a strlen then memcpy.

Would you prefer to use this function also at this source code place?

Regards,
Markus

Re: [PATCH v4 4/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

Hi Jonathan,

> Am 22.10.2016 um 20:33 schrieb Jonathan Cameron :
> 
> On 17/10/16 14:57, H. Nikolaus Schaller wrote:
>> The tsc2007 chip not only has a resistive touch screen controller but
>> also an external AUX adc imput which can be used for an ambient
>> light sensor, battery voltage monitoring or any general purpose.
>> 
>> Additionally it can measure the chip temperature.
>> 
>> This extension provides an iio interface for these adc channels.
>> 
>> Since it is not wasting much resources and is very straightforward,
>> we simply provide all other adc channels as optional iio interfaces
>> as weel. This can be used for debugging or special applications.
> well
>> 
>> Signed-off-by: H. Nikolaus Schaller 
> This could be cleaner done perhaps by factoring out the IIO stuff into a 
> separate
> file and using a header with stubs to deal with the no available case.
> 
> There will only be a handful of stubs and it'll give you a lot cleaner code
> in here.
> 
> If def fun in .c files is always harder to deal with than in a header
> where stubs are really obvious.

Yes, it became a lot of #ifdefs spread over the source file.

The easiest thing would be to require IIO to be enabled :)

With your proposal to consider refactoring, I think the crucial part
is the conditional allocation either through devm_iio_device_alloc()
or devm_kzalloc(). This can be refactored into some conditional
tsc2007_alloc().

I have tried some draft (not tested and not tidied up) to check if the
direction is good.

This reduces the number of #ifdef CONFIG_IIO from 7 to 2 without introducing
new files or includes. There are also 2 other #ifdef CONFIG_OF so it doesn't
seem to be very complex now in comparison. And the patch itself has only a
handful of hunks (8).

Moving tsc2007_alloc into a separate file tsc2007_iio.c would only move around
one #ifdef CONFIG_OF from tsc2007.c but IMHO makes it more difficult to 
understand
because it is not really iio specific and one has to switch between two source
files. And I would have to touch the Makefile as well.

What do you think?

If generally ok, I can include that in [PATCH v5].

BR and thanks,
Nikolaus


diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5e3c4bf..691e79f 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -69,9 +70,13 @@ struct ts_event {
 
 struct tsc2007 {
struct input_dev*input;
+#ifdef CONFIG_IIO
+   struct iio_dev  *indio;
+#endif
charphys[32];
 
struct i2c_client   *client;
+   struct mutexmlock;
 
u16 model;
u16 x_plate_ohms;
@@ -192,7 +197,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
/* pen is down, continue with the measurement */
+
+   mutex_lock(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -319,6 +327,162 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
 }
 
+#ifdef CONFIG_IIO
+
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+   .datasheet_name = _name, \
+   .type = _type, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+   BIT(_chan_info), \
+   .indexed = 1, \
+   .channel = _chan, \
+}
+
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+   TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+   TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+   struct  tsc2007 *tsc = iio_priv(indio_dev);
+   int adc_chan = chan->channel;
+   int ret = 0;
+
+   if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+   return -EINVAL;
+
+   if (mask != IIO_CHAN_INFO_RAW)
+   return -EINVAL;
+
+   mutex_lock(>mlock);
+
+   switch (chan->channel) {
+   case 0:
+   *val = tsc2007_xfer(tsc, READ_X);
+   break;
+   

Re: [PATCH v4 4/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

Hi Jonathan,

> Am 22.10.2016 um 20:33 schrieb Jonathan Cameron :
> 
> On 17/10/16 14:57, H. Nikolaus Schaller wrote:
>> The tsc2007 chip not only has a resistive touch screen controller but
>> also an external AUX adc imput which can be used for an ambient
>> light sensor, battery voltage monitoring or any general purpose.
>> 
>> Additionally it can measure the chip temperature.
>> 
>> This extension provides an iio interface for these adc channels.
>> 
>> Since it is not wasting much resources and is very straightforward,
>> we simply provide all other adc channels as optional iio interfaces
>> as weel. This can be used for debugging or special applications.
> well
>> 
>> Signed-off-by: H. Nikolaus Schaller 
> This could be cleaner done perhaps by factoring out the IIO stuff into a 
> separate
> file and using a header with stubs to deal with the no available case.
> 
> There will only be a handful of stubs and it'll give you a lot cleaner code
> in here.
> 
> If def fun in .c files is always harder to deal with than in a header
> where stubs are really obvious.

Yes, it became a lot of #ifdefs spread over the source file.

The easiest thing would be to require IIO to be enabled :)

With your proposal to consider refactoring, I think the crucial part
is the conditional allocation either through devm_iio_device_alloc()
or devm_kzalloc(). This can be refactored into some conditional
tsc2007_alloc().

I have tried some draft (not tested and not tidied up) to check if the
direction is good.

This reduces the number of #ifdef CONFIG_IIO from 7 to 2 without introducing
new files or includes. There are also 2 other #ifdef CONFIG_OF so it doesn't
seem to be very complex now in comparison. And the patch itself has only a
handful of hunks (8).

Moving tsc2007_alloc into a separate file tsc2007_iio.c would only move around
one #ifdef CONFIG_OF from tsc2007.c but IMHO makes it more difficult to 
understand
because it is not really iio specific and one has to switch between two source
files. And I would have to touch the Makefile as well.

What do you think?

If generally ok, I can include that in [PATCH v5].

BR and thanks,
Nikolaus


diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5e3c4bf..691e79f 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -69,9 +70,13 @@ struct ts_event {
 
 struct tsc2007 {
struct input_dev*input;
+#ifdef CONFIG_IIO
+   struct iio_dev  *indio;
+#endif
charphys[32];
 
struct i2c_client   *client;
+   struct mutexmlock;
 
u16 model;
u16 x_plate_ohms;
@@ -192,7 +197,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
/* pen is down, continue with the measurement */
+
+   mutex_lock(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -319,6 +327,162 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
 }
 
+#ifdef CONFIG_IIO
+
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+   .datasheet_name = _name, \
+   .type = _type, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+   BIT(_chan_info), \
+   .indexed = 1, \
+   .channel = _chan, \
+}
+
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+   TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+   TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+   struct  tsc2007 *tsc = iio_priv(indio_dev);
+   int adc_chan = chan->channel;
+   int ret = 0;
+
+   if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+   return -EINVAL;
+
+   if (mask != IIO_CHAN_INFO_RAW)
+   return -EINVAL;
+
+   mutex_lock(>mlock);
+
+   switch (chan->channel) {
+   case 0:
+   *val = tsc2007_xfer(tsc, READ_X);
+   break;
+   case 1:
+   *val = 

[PATCH] iio: dac: mcp4725: fix odd_ptr_err.cocci warnings

[Julia Lawall]

PTR_ERR should access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Tomas Novotny 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

Not checked at all.  This is being reported on the following tree:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
testing
head:   2796a310d462f73954c0ce8ffabaf4baacaecca1
commit: e0b80def1faa901d83a7d580e8aa4ad4a512bedf [109/113] iio: dac:
mcp4725: support voltage reference selection
:: branch date: 2 hours ago
:: commit date: 2 hours ago


 mcp4725.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iio/dac/mcp4725.c
+++ b/drivers/iio/dac/mcp4725.c
@@ -418,7 +418,7 @@ static int mcp4725_probe(struct i2c_clie
if (pdata->use_vref) {
data->vref_reg = devm_regulator_get(>dev, "vref");
if (IS_ERR(data->vref_reg)) {
-   err = PTR_ERR(data->vdd_reg);
+   err = PTR_ERR(data->vref_reg);
goto err_disable_vdd_reg;
}

[PATCH] iio: dac: mcp4725: fix odd_ptr_err.cocci warnings

[Julia Lawall]

PTR_ERR should access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Tomas Novotny 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

Not checked at all.  This is being reported on the following tree:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
testing
head:   2796a310d462f73954c0ce8ffabaf4baacaecca1
commit: e0b80def1faa901d83a7d580e8aa4ad4a512bedf [109/113] iio: dac:
mcp4725: support voltage reference selection
:: branch date: 2 hours ago
:: commit date: 2 hours ago


 mcp4725.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iio/dac/mcp4725.c
+++ b/drivers/iio/dac/mcp4725.c
@@ -418,7 +418,7 @@ static int mcp4725_probe(struct i2c_clie
if (pdata->use_vref) {
data->vref_reg = devm_regulator_get(>dev, "vref");
if (IS_ERR(data->vref_reg)) {
-   err = PTR_ERR(data->vdd_reg);
+   err = PTR_ERR(data->vref_reg);
goto err_disable_vdd_reg;
}

Re: [PATCH net 0/2] net: dsa: bcm_sf2: Do not rely on kexec_in_progress

[David Miller]

From: Florian Fainelli 
Date: Fri, 21 Oct 2016 14:21:54 -0700

> These are the two patches following the discussing we had on
> kexec_in_progress.
> 
> Feel free to apply or discard them, thanks!

Applied, thanks.

Re: [PATCH net 0/2] net: dsa: bcm_sf2: Do not rely on kexec_in_progress

[David Miller]

From: Florian Fainelli 
Date: Fri, 21 Oct 2016 14:21:54 -0700

> These are the two patches following the discussing we had on
> kexec_in_progress.
> 
> Feel free to apply or discard them, thanks!

Applied, thanks.

Re: [PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[Joe Perches]

On Sat, 2016-10-22 at 21:58 +0200, SF Markus Elfring wrote:
> Some data were printed into a sequence by two separate function calls.
> Print the same data by a single function call instead.
[]
> diff --git a/arch/ia64/sn/kernel/sn2/sn2_smp.c 
> b/arch/ia64/sn/kernel/sn2/sn2_smp.c
[]
> @@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, void 
> *data)
>   int cpu;
>  
>   cpu = *(loff_t *) data;
> -
> - if (!cpu) {
> + if (!cpu)
>   seq_printf(file,
> -"# cpu ptc_l newrid ptc_flushes nodes_flushed 
> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
> ipi_nsec\n");
> - seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
> sn2_flush_opt);
> - }
> +"# cpu ptc_l newrid ptc_flushes nodes_flushed 
> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
> ipi_nsec\n"
> +"# ptctest %d, flushopt %d\n",
> +sn2_ptctest, sn2_flush_opt);
>  
>   if (cpu < nr_cpu_ids && cpu_online(cpu)) {
>   stat = _cpu(ptcstats, cpu);

Please think more.

printf has to inspect character by character looking for
a vsprintf % character and 0 termination.

seq_puts does a strlen then memcpy.

Which is faster?
When is it better to call 2 functions?
When does readability matter more than efficiency?

Re: [PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[Joe Perches]

On Sat, 2016-10-22 at 21:58 +0200, SF Markus Elfring wrote:
> Some data were printed into a sequence by two separate function calls.
> Print the same data by a single function call instead.
[]
> diff --git a/arch/ia64/sn/kernel/sn2/sn2_smp.c 
> b/arch/ia64/sn/kernel/sn2/sn2_smp.c
[]
> @@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, void 
> *data)
>   int cpu;
>  
>   cpu = *(loff_t *) data;
> -
> - if (!cpu) {
> + if (!cpu)
>   seq_printf(file,
> -"# cpu ptc_l newrid ptc_flushes nodes_flushed 
> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
> ipi_nsec\n");
> - seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
> sn2_flush_opt);
> - }
> +"# cpu ptc_l newrid ptc_flushes nodes_flushed 
> deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
> ipi_nsec\n"
> +"# ptctest %d, flushopt %d\n",
> +sn2_ptctest, sn2_flush_opt);
>  
>   if (cpu < nr_cpu_ids && cpu_online(cpu)) {
>   stat = _cpu(ptcstats, cpu);

Please think more.

printf has to inspect character by character looking for
a vsprintf % character and 0 termination.

seq_puts does a strlen then memcpy.

Which is faster?
When is it better to call 2 functions?
When does readability matter more than efficiency?

[PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 22 Oct 2016 21:19:03 +0200

Some data were printed into a sequence by two separate function calls.
Print the same data by a single function call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/ia64/sn/kernel/sn2/sn2_smp.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/sn/kernel/sn2/sn2_smp.c 
b/arch/ia64/sn/kernel/sn2/sn2_smp.c
index c98dc96..1beac3c 100644
--- a/arch/ia64/sn/kernel/sn2/sn2_smp.c
+++ b/arch/ia64/sn/kernel/sn2/sn2_smp.c
@@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, void 
*data)
int cpu;
 
cpu = *(loff_t *) data;
-
-   if (!cpu) {
+   if (!cpu)
seq_printf(file,
-  "# cpu ptc_l newrid ptc_flushes nodes_flushed 
deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
ipi_nsec\n");
-   seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
sn2_flush_opt);
-   }
+  "# cpu ptc_l newrid ptc_flushes nodes_flushed 
deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
ipi_nsec\n"
+  "# ptctest %d, flushopt %d\n",
+  sn2_ptctest, sn2_flush_opt);
 
if (cpu < nr_cpu_ids && cpu_online(cpu)) {
stat = _cpu(ptcstats, cpu);
-- 
2.10.1

[PATCH 6/6] IA64-sn2_smp: Combine two seq_printf() calls into one call in sn2_ptc_seq_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 22 Oct 2016 21:19:03 +0200

Some data were printed into a sequence by two separate function calls.
Print the same data by a single function call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/ia64/sn/kernel/sn2/sn2_smp.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/sn/kernel/sn2/sn2_smp.c 
b/arch/ia64/sn/kernel/sn2/sn2_smp.c
index c98dc96..1beac3c 100644
--- a/arch/ia64/sn/kernel/sn2/sn2_smp.c
+++ b/arch/ia64/sn/kernel/sn2/sn2_smp.c
@@ -494,12 +494,11 @@ static int sn2_ptc_seq_show(struct seq_file *file, void 
*data)
int cpu;
 
cpu = *(loff_t *) data;
-
-   if (!cpu) {
+   if (!cpu)
seq_printf(file,
-  "# cpu ptc_l newrid ptc_flushes nodes_flushed 
deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
ipi_nsec\n");
-   seq_printf(file, "# ptctest %d, flushopt %d\n", sn2_ptctest, 
sn2_flush_opt);
-   }
+  "# cpu ptc_l newrid ptc_flushes nodes_flushed 
deadlocks lock_nsec shub_nsec shub_nsec_max not_my_mm deadlock2 ipi_fluches 
ipi_nsec\n"
+  "# ptctest %d, flushopt %d\n",
+  sn2_ptctest, sn2_flush_opt);
 
if (cpu < nr_cpu_ids && cpu_online(cpu)) {
stat = _cpu(ptcstats, cpu);
-- 
2.10.1

[PATCH 5/6] IA64-sn_hwperf: Use seq_puts() in sn_topology_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 22 Oct 2016 20:53:38 +0200

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

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/ia64/sn/kernel/sn2/sn_hwperf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/sn/kernel/sn2/sn_hwperf.c 
b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
index b999257..435002a 100644
--- a/arch/ia64/sn/kernel/sn2/sn_hwperf.c
+++ b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
@@ -400,9 +400,9 @@ static int sn_topology_show(struct seq_file *s, void *d)
int nasid_msb;
 
if (obj == objs) {
-   seq_printf(s, "# sn_topology version 2\n");
-   seq_printf(s, "# objtype ordinal location partition"
-   " [attribute value [, ...]]\n");
+   seq_puts(s,
+"# sn_topology version 2\n"
+"# objtype ordinal location partition [attribute value 
[, ...]]\n");
 
if (ia64_sn_get_sn_info(0,
, _mask, _shift, _size,
-- 
2.10.1

[PATCH 5/6] IA64-sn_hwperf: Use seq_puts() in sn_topology_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 22 Oct 2016 20:53:38 +0200

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

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/ia64/sn/kernel/sn2/sn_hwperf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/sn/kernel/sn2/sn_hwperf.c 
b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
index b999257..435002a 100644
--- a/arch/ia64/sn/kernel/sn2/sn_hwperf.c
+++ b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
@@ -400,9 +400,9 @@ static int sn_topology_show(struct seq_file *s, void *d)
int nasid_msb;
 
if (obj == objs) {
-   seq_printf(s, "# sn_topology version 2\n");
-   seq_printf(s, "# objtype ordinal location partition"
-   " [attribute value [, ...]]\n");
+   seq_puts(s,
+"# sn_topology version 2\n"
+"# objtype ordinal location partition [attribute value 
[, ...]]\n");
 
if (ia64_sn_get_sn_info(0,
, _mask, _shift, _size,
-- 
2.10.1