Re: [RFC v2 PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

[Yisheng Xie]

hi Michal,
Thank you for reviewing and sorry for late reply.

On 01/26/2017 05:43 PM, Michal Hocko wrote:
> On Wed 25-01-17 14:59:45, Yisheng Xie wrote:
>
>  static unsigned long scan_movable_pages(unsigned long start, unsigned long 
> end)
>  {
> @@ -1531,6 +1531,16 @@ static unsigned long scan_movable_pages(unsigned long 
> start, unsigned long end)
>   pfn = round_up(pfn + 1,
>   1 << compound_order(page)) - 1;
>   }
> + /*
> +  * check __PageMovable in lock_page to avoid miss some
> +  * non-lru movable pages at race condition.
> +  */
> + lock_page(page);
> + if (__PageMovable(page)) {
> + unlock_page(page);
> + return pfn;
> + }
> + unlock_page(page);
> This doesn't make any sense to me. __PageMovable can change right after
> you drop the lock so why the race matters? If we cannot tolerate races
> then the above doesn't work and if we can then taking the lock is
> pointless.
hmm, for PageLRU check may also race without lru-lock，
I think it is ok to check __PageMovable without lock_page, here.

>>  }
>>  }
>>  return 0;
>> @@ -1600,21 +1610,25 @@ static struct page *new_node_page(struct page *page, 
>> unsigned long private,
>>  if (!get_page_unless_zero(page))
>>  continue;
>>  /*
>> - * We can skip free pages. And we can only deal with pages on
>> - * LRU.
>> + * We can skip free pages. And we can deal with pages on
>> + * LRU and non-lru movable pages.
>>   */
>> -ret = isolate_lru_page(page);
>> +if (PageLRU(page))
>> +ret = isolate_lru_page(page);
>> +else
>> +ret = !isolate_movable_page(page, ISOLATE_UNEVICTABLE);
> we really want to propagate the proper error code to the caller.
Yes , I make the same mistake again. Really sorry about that.

Maybe I can rewrite the isolate_movable_page to let it return int as 
isolate_lru_page
do in this patchset :)

Thanks
Yisheng Xie

Re: [RFC v2 PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

[Yisheng Xie]

hi Michal,
Thank you for reviewing and sorry for late reply.

On 01/26/2017 05:43 PM, Michal Hocko wrote:
> On Wed 25-01-17 14:59:45, Yisheng Xie wrote:
>
>  static unsigned long scan_movable_pages(unsigned long start, unsigned long 
> end)
>  {
> @@ -1531,6 +1531,16 @@ static unsigned long scan_movable_pages(unsigned long 
> start, unsigned long end)
>   pfn = round_up(pfn + 1,
>   1 << compound_order(page)) - 1;
>   }
> + /*
> +  * check __PageMovable in lock_page to avoid miss some
> +  * non-lru movable pages at race condition.
> +  */
> + lock_page(page);
> + if (__PageMovable(page)) {
> + unlock_page(page);
> + return pfn;
> + }
> + unlock_page(page);
> This doesn't make any sense to me. __PageMovable can change right after
> you drop the lock so why the race matters? If we cannot tolerate races
> then the above doesn't work and if we can then taking the lock is
> pointless.
hmm, for PageLRU check may also race without lru-lock，
I think it is ok to check __PageMovable without lock_page, here.

>>  }
>>  }
>>  return 0;
>> @@ -1600,21 +1610,25 @@ static struct page *new_node_page(struct page *page, 
>> unsigned long private,
>>  if (!get_page_unless_zero(page))
>>  continue;
>>  /*
>> - * We can skip free pages. And we can only deal with pages on
>> - * LRU.
>> + * We can skip free pages. And we can deal with pages on
>> + * LRU and non-lru movable pages.
>>   */
>> -ret = isolate_lru_page(page);
>> +if (PageLRU(page))
>> +ret = isolate_lru_page(page);
>> +else
>> +ret = !isolate_movable_page(page, ISOLATE_UNEVICTABLE);
> we really want to propagate the proper error code to the caller.
Yes , I make the same mistake again. Really sorry about that.

Maybe I can rewrite the isolate_movable_page to let it return int as 
isolate_lru_page
do in this patchset :)

Thanks
Yisheng Xie

[PATCH v4 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic

[Pavel Tikhomirov]

Oleg Nesterov (1):
  introduce the walk_process_tree() helper

Pavel Tikhomirov (1):
  prctl: propagate has_child_subreaper flag to every descendant

 include/linux/sched.h |  3 +++
 kernel/fork.c | 42 +++---
 kernel/sys.c  | 22 ++
 3 files changed, 64 insertions(+), 3 deletions(-)

-- 
2.9.3

[PATCH v4 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic

[Pavel Tikhomirov]

Oleg Nesterov (1):
  introduce the walk_process_tree() helper

Pavel Tikhomirov (1):
  prctl: propagate has_child_subreaper flag to every descendant

 include/linux/sched.h |  3 +++
 kernel/fork.c | 42 +++---
 kernel/sys.c  | 22 ++
 3 files changed, 64 insertions(+), 3 deletions(-)

-- 
2.9.3

[PATCH v3 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic

[Pavel Tikhomirov]

Oleg Nesterov (1):
  introduce the walk_process_tree() helper

Pavel Tikhomirov (1):
  prctl: propagate has_child_subreaper flag to every descendant

 include/linux/sched.h |  3 +++
 kernel/fork.c | 42 +++---
 kernel/sys.c  | 22 ++
 3 files changed, 64 insertions(+), 3 deletions(-)

-- 
2.9.3

[PATCH] PCI/ASPM: Handle PCI-to-PCIe bridges as roots of PCIe hierarchies

[Bjorn Helgaas]

In a struct pcie_link_state, link->root points to the pcie_link_state of
the root of the PCIe hierarchy.  For the topmost link, this points to
itself (link->root = link).  For others, we copy the pointer from the
parent (link->root = link->parent->root).

Previously we recognized that Root Ports originated PCIe hierarchies, but
we treated PCI/PCI-X to PCIe Bridges as being in the middle of the
hierarchy, and when we tried to copy the pointer from link->parent->root,
there was no parent, and we dereferenced a NULL pointer:

  BUG: unable to handle kernel NULL pointer dereference at 0090
  IP: [] pcie_aspm_init_link_state+0x170/0x820

Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just
like Root Ports do, so link->root for these devices should also point to
itself.

Fixes: 51ebfc92b72b ("PCI: Enumerate switches below PCI-to-PCIe bridges")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181
Tested-by: li...@ssl-mail.com
Signed-off-by: Bjorn Helgaas 
CC: sta...@vger.kernel.org  # v4.2+
---
 drivers/pci/pcie/aspm.c |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 17ac1dce3286..3dd8bcbb3011 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -532,25 +532,32 @@ static struct pcie_link_state 
*alloc_pcie_link_state(struct pci_dev *pdev)
link = kzalloc(sizeof(*link), GFP_KERNEL);
if (!link)
return NULL;
+
INIT_LIST_HEAD(>sibling);
INIT_LIST_HEAD(>children);
INIT_LIST_HEAD(>link);
link->pdev = pdev;
-   if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) {
+
+   /*
+* Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe
+* hierarchies.
+*/
+   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT ||
+   pci_pcie_type(pdev) == PCI_EXP_TYPE_PCIE_BRIDGE) {
+   link->root = link;
+   } else {
struct pcie_link_state *parent;
+
parent = pdev->bus->parent->self->link_state;
if (!parent) {
kfree(link);
return NULL;
}
+
link->parent = parent;
+   link->root = link->parent->root;
list_add(>link, >children);
}
-   /* Setup a pointer to the root port link */
-   if (!link->parent)
-   link->root = link;
-   else
-   link->root = link->parent->root;
 
list_add(>sibling, _list);
pdev->link_state = link;

[PATCH v3 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic

[Pavel Tikhomirov]

Oleg Nesterov (1):
  introduce the walk_process_tree() helper

Pavel Tikhomirov (1):
  prctl: propagate has_child_subreaper flag to every descendant

 include/linux/sched.h |  3 +++
 kernel/fork.c | 42 +++---
 kernel/sys.c  | 22 ++
 3 files changed, 64 insertions(+), 3 deletions(-)

-- 
2.9.3

[PATCH] PCI/ASPM: Handle PCI-to-PCIe bridges as roots of PCIe hierarchies

[Bjorn Helgaas]

In a struct pcie_link_state, link->root points to the pcie_link_state of
the root of the PCIe hierarchy.  For the topmost link, this points to
itself (link->root = link).  For others, we copy the pointer from the
parent (link->root = link->parent->root).

Previously we recognized that Root Ports originated PCIe hierarchies, but
we treated PCI/PCI-X to PCIe Bridges as being in the middle of the
hierarchy, and when we tried to copy the pointer from link->parent->root,
there was no parent, and we dereferenced a NULL pointer:

  BUG: unable to handle kernel NULL pointer dereference at 0090
  IP: [] pcie_aspm_init_link_state+0x170/0x820

Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just
like Root Ports do, so link->root for these devices should also point to
itself.

Fixes: 51ebfc92b72b ("PCI: Enumerate switches below PCI-to-PCIe bridges")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181
Tested-by: li...@ssl-mail.com
Signed-off-by: Bjorn Helgaas 
CC: sta...@vger.kernel.org  # v4.2+
---
 drivers/pci/pcie/aspm.c |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 17ac1dce3286..3dd8bcbb3011 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -532,25 +532,32 @@ static struct pcie_link_state 
*alloc_pcie_link_state(struct pci_dev *pdev)
link = kzalloc(sizeof(*link), GFP_KERNEL);
if (!link)
return NULL;
+
INIT_LIST_HEAD(>sibling);
INIT_LIST_HEAD(>children);
INIT_LIST_HEAD(>link);
link->pdev = pdev;
-   if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) {
+
+   /*
+* Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe
+* hierarchies.
+*/
+   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT ||
+   pci_pcie_type(pdev) == PCI_EXP_TYPE_PCIE_BRIDGE) {
+   link->root = link;
+   } else {
struct pcie_link_state *parent;
+
parent = pdev->bus->parent->self->link_state;
if (!parent) {
kfree(link);
return NULL;
}
+
link->parent = parent;
+   link->root = link->parent->root;
list_add(>link, >children);
}
-   /* Setup a pointer to the root port link */
-   if (!link->parent)
-   link->root = link;
-   else
-   link->root = link->parent->root;
 
list_add(>sibling, _list);
pdev->link_state = link;

Re: [PATCH 4/9] ila: simplify a strange allocation pattern

[Vlastimil Babka]

On 01/30/2017 10:49 AM, Michal Hocko wrote:

From: Michal Hocko 

alloc_ila_locks seemed to c from alloc_bucket_locks allocation
pattern which is quite unusual. The default allocation size is 320 *
sizeof(spinlock_t) which is sub page unless lockdep is enabled when the
performance benefit is really questionable and not worth the subtle code
IMHO. Also note that the context when we call ila_init_net (modprobe or
a task creating a net namespace) has to be properly configured.

Let's just simplify the code and use kvmalloc helper which is a
transparent way to use kmalloc with vmalloc fallback.

Cc: Tom Herbert 
Cc: Eric Dumazet 
Signed-off-by: Michal Hocko 


Acked-by: Vlastimil Babka 


---
 net/ipv6/ila/ila_xlat.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/net/ipv6/ila/ila_xlat.c b/net/ipv6/ila/ila_xlat.c
index af8f52ee7180..2fd5ca151dcf 100644
--- a/net/ipv6/ila/ila_xlat.c
+++ b/net/ipv6/ila/ila_xlat.c
@@ -41,13 +41,7 @@ static int alloc_ila_locks(struct ila_net *ilan)
size = roundup_pow_of_two(nr_pcpus * LOCKS_PER_CPU);

if (sizeof(spinlock_t) != 0) {
-#ifdef CONFIG_NUMA
-   if (size * sizeof(spinlock_t) > PAGE_SIZE)
-   ilan->locks = vmalloc(size * sizeof(spinlock_t));
-   else
-#endif
-   ilan->locks = kmalloc_array(size, sizeof(spinlock_t),
-   GFP_KERNEL);
+   ilan->locks = kvmalloc(size * sizeof(spinlock_t), GFP_KERNEL);
if (!ilan->locks)
return -ENOMEM;
for (i = 0; i < size; i++)

Re: [PATCH 4/9] ila: simplify a strange allocation pattern

[Vlastimil Babka]

On 01/30/2017 10:49 AM, Michal Hocko wrote:

From: Michal Hocko 

alloc_ila_locks seemed to c from alloc_bucket_locks allocation
pattern which is quite unusual. The default allocation size is 320 *
sizeof(spinlock_t) which is sub page unless lockdep is enabled when the
performance benefit is really questionable and not worth the subtle code
IMHO. Also note that the context when we call ila_init_net (modprobe or
a task creating a net namespace) has to be properly configured.

Let's just simplify the code and use kvmalloc helper which is a
transparent way to use kmalloc with vmalloc fallback.

Cc: Tom Herbert 
Cc: Eric Dumazet 
Signed-off-by: Michal Hocko 


Acked-by: Vlastimil Babka 


---
 net/ipv6/ila/ila_xlat.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/net/ipv6/ila/ila_xlat.c b/net/ipv6/ila/ila_xlat.c
index af8f52ee7180..2fd5ca151dcf 100644
--- a/net/ipv6/ila/ila_xlat.c
+++ b/net/ipv6/ila/ila_xlat.c
@@ -41,13 +41,7 @@ static int alloc_ila_locks(struct ila_net *ilan)
size = roundup_pow_of_two(nr_pcpus * LOCKS_PER_CPU);

if (sizeof(spinlock_t) != 0) {
-#ifdef CONFIG_NUMA
-   if (size * sizeof(spinlock_t) > PAGE_SIZE)
-   ilan->locks = vmalloc(size * sizeof(spinlock_t));
-   else
-#endif
-   ilan->locks = kmalloc_array(size, sizeof(spinlock_t),
-   GFP_KERNEL);
+   ilan->locks = kvmalloc(size * sizeof(spinlock_t), GFP_KERNEL);
if (!ilan->locks)
return -ENOMEM;
for (i = 0; i < size; i++)

Re: [PATCH 1/2] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

[Joerg Roedel]

Hi Ashok,

On Fri, Jan 27, 2017 at 08:32:39AM -0800, Ashok Raj wrote:
> From: CQ Tang 
> 
> Some of the macros are incorrect with wrong bit-shifts resulting in picking
> the incorrect invalidation granularity. Incorrect Source-ID in extended
> devtlb invalidation caused device side errors.
> 
> To: Joerg Roedel 
> To: David Woodhouse 
> Cc: io...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Cc: CQ Tang 
> Cc: Ashok Raj 

Can you please also add valid Fixes: tags to both patches?


Thanks,

Joerg

Re: [PATCH 1/2] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

[Joerg Roedel]

Hi Ashok,

On Fri, Jan 27, 2017 at 08:32:39AM -0800, Ashok Raj wrote:
> From: CQ Tang 
> 
> Some of the macros are incorrect with wrong bit-shifts resulting in picking
> the incorrect invalidation granularity. Incorrect Source-ID in extended
> devtlb invalidation caused device side errors.
> 
> To: Joerg Roedel 
> To: David Woodhouse 
> Cc: io...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Cc: CQ Tang 
> Cc: Ashok Raj 

Can you please also add valid Fixes: tags to both patches?


Thanks,

Joerg

Re: [PATCH v8] perf: add qcom l2 cache perf events driver

[Mark Rutland]

Hi Neil,

Apologies for the delay in getting to this.

This is largely looking good now.

I have a couple of concerns with the hotplug logic, but I think we can
solve those without too much pain. More on that below.

On Mon, Jan 16, 2017 at 01:52:47PM -0500, Neil Leeder wrote:

> +#define L2PMRESR_EN ((u64)1 << 63)

Nit: please use BIT_ULL() for consistency with other definitions below.

> +#define L2_COUNTER_RELOAD   BIT_ULL(31)
> +#define L2_CYCLE_COUNTER_RELOAD BIT_ULL(63)

[...]

> +#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
> +#define L2CPUSRDR_EL1   S3_3_c15_c0_7

I should have realsied this before, but some old toolchains don't
support this format, as we discovered in commit 72c5839515260dce
("arm64: gicv3: Allow GICv3 compilation with older binutils").

So I think we need to use sys_reg() for these, i.e.

#define SYS_L2CPUSRSELR_EL1 sys_reg(3, 3, 15, 0, 6)
#defing SYS_L2CPUSRDR_EL1   sys_reg(3, 3, 15, 0, 7)

... and correspondingly we need to use {read_write}_sysreg_s() to
perform accesses to those.

[...]

> +static DEFINE_RAW_SPINLOCK(l2_access_lock);
> +
> +/**
> + * set_l2_indirect_reg: write value to an L2 register
> + * @reg: Address of L2 register.
> + * @value: Value to be written to register.
> + *
> + * Use architecturally required barriers for ordering between system register
> + * accesses
> + */
> +static void set_l2_indirect_reg(u64 reg, u64 val)
> +{
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(_access_lock, flags);
> + write_sysreg(reg, L2CPUSRSELR_EL1);
> + isb();
> + write_sysreg(val, L2CPUSRDR_EL1);
> + isb();
> + raw_spin_unlock_irqrestore(_access_lock, flags);
> +}

This is fine as is, but just for my understanding, I take it that the
locking is only strictly required to be per-cluster?

[...]

> +static void cluster_pmu_reset_on_cluster(void *x)
> +{
> + /* Reset all ctrs */
> + set_l2_indirect_reg(L2PMCR, L2PMCR_RESET_ALL);
> + set_l2_indirect_reg(L2PMCNTENCLR, l2_counter_present_mask);
> + set_l2_indirect_reg(L2PMINTENCLR, l2_counter_present_mask);
> + set_l2_indirect_reg(L2PMOVSCLR, l2_counter_present_mask);
> +}
> +
> +static inline void cluster_pmu_reset(struct cluster_pmu *cluster)
> +{
> + cpumask_t *mask = >cluster_cpus;
> +
> + if (smp_call_function_any(mask, cluster_pmu_reset_on_cluster, NULL, 1))
> + dev_err(>l2cache_pmu->pdev->dev,
> + "Failed to reset on cluster with cpu %d\n",
> + cpumask_first(>cluster_cpus));
> +}

We only ever call these in the probe path, which I don't think is
sufficient. We can boot with a limited set of CPUs since commit
44dbcc93ab67145b ("arm64: Fix behavior of maxcpus=N"), so this might not
reset all the PMU hardware.

I also assume that if a cluster is hotplugged off, the PMU hardware may
lose state (i.e. it is not in an always-on domain separated from the
CPUs), and therefore may need to be reset after CPUs have been
hotplugged in.

We can cater for both of these by moving the reset call into the hotplug
callback. I've give na a concrete example below for that.


[...]

> + counter_reg = (idx * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTR_BASE;
> + set_l2_indirect_reg(counter_reg, value & GENMASK(31, 0));

We should drop the masking here; it's not necessary given we only
program a fixed value. Were it necessary, there'd be a potential
mismatch with prev_count.

[...]

> + counter_reg = (idx * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTR_BASE;
> + value = get_l2_indirect_reg(counter_reg);

Given this pattern crops up a few times, can we drop something like:

#define reg_idx(reg, i) ((i * IA_L2_REG_OFFSET) + reg ## _BASE)

... at the top of the file, so we can write this inline:

value = get_l2_indirect_reg(reg_idx(IA_L2PMXEVCNTR, idx));

[...]

> +static int l2_cache_filter_match(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = >hw;
> + struct hw_perf_event *chwc;
> + struct cluster_pmu *cluster = get_cluster_pmu(event->cpu);
> + struct l2cache_pmu *l2cache_pmu;
> + struct perf_event *conflict_event;
> + unsigned int group = L2_EVT_GROUP(hwc->config_base);
> +
> + /*
> +  * Check for column exclusion: event column already in use by another
> +  * event. This is for events which are not in the same group.
> +  * Conflicting events in the same group are detected in event_init.
> +  */
> +
> + if (test_bit(group, cluster->used_groups)) {

Nit: this nesting is more painful than is necessary to read. Please
invert the condition and use an early return here.

> + conflict_event =
> + cluster->events[cluster->group_to_counter[group]];
> + if (conflict_event != event) {

If it's possible for conflict_event == event, it sounds like this is
fragile to the order events are added or removed.

When does conflict_event == event?

> +

Re: [PATCH 2/8] pinctrl: stm32: use gpio-ranges to declare bank range

[Linus Walleij]

On Fri, Jan 27, 2017 at 5:15 PM, Alexandre TORGUE
 wrote:

> Use device tree entries to declare gpio range. It will allow to use
> no contiguous gpio bank and holes inside a bank.
>
> Signed-off-by: Alexandre TORGUE 

(...)
> +   of_property_read_string(np, "st,bank-name", >gpio_chip.label);
> +
> +   if (!of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3, 0, ))
> +   bank_nr = args.args[1] / STM32_GPIO_PINS_PER_BANK;
> +   else {
> +   range->name = bank->gpio_chip.label;
> +   range->id = bank_nr;
> +   range->pin_base = range->id * STM32_GPIO_PINS_PER_BANK;
> +   range->base = range->id * STM32_GPIO_PINS_PER_BANK;
> +   range->npins = npins;
> +   range->gc = >gpio_chip;
> +   pinctrl_add_gpio_range(pctl->pctl_dev,
> +  >banks[bank_nr].range);
> +   }

Why are you doing this?

There is already code in drivers/gpio/gpiolib-of.c to pick ranges
from the device tree and add when you're adding the GPIO chips.

Please use that or figure out what is needed to make it work for
you instead of reimplementing it.

Yours,
Linus Walleij

Re: [PATCH 2/8] pinctrl: stm32: use gpio-ranges to declare bank range

[Linus Walleij]

On Fri, Jan 27, 2017 at 5:15 PM, Alexandre TORGUE
 wrote:

> Use device tree entries to declare gpio range. It will allow to use
> no contiguous gpio bank and holes inside a bank.
>
> Signed-off-by: Alexandre TORGUE 

(...)
> +   of_property_read_string(np, "st,bank-name", >gpio_chip.label);
> +
> +   if (!of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3, 0, ))
> +   bank_nr = args.args[1] / STM32_GPIO_PINS_PER_BANK;
> +   else {
> +   range->name = bank->gpio_chip.label;
> +   range->id = bank_nr;
> +   range->pin_base = range->id * STM32_GPIO_PINS_PER_BANK;
> +   range->base = range->id * STM32_GPIO_PINS_PER_BANK;
> +   range->npins = npins;
> +   range->gc = >gpio_chip;
> +   pinctrl_add_gpio_range(pctl->pctl_dev,
> +  >banks[bank_nr].range);
> +   }

Why are you doing this?

There is already code in drivers/gpio/gpiolib-of.c to pick ranges
from the device tree and add when you're adding the GPIO chips.

Please use that or figure out what is needed to make it work for
you instead of reimplementing it.

Yours,
Linus Walleij

Re: [PATCH v8] perf: add qcom l2 cache perf events driver

[Mark Rutland]

Hi Neil,

Apologies for the delay in getting to this.

This is largely looking good now.

I have a couple of concerns with the hotplug logic, but I think we can
solve those without too much pain. More on that below.

On Mon, Jan 16, 2017 at 01:52:47PM -0500, Neil Leeder wrote:

> +#define L2PMRESR_EN ((u64)1 << 63)

Nit: please use BIT_ULL() for consistency with other definitions below.

> +#define L2_COUNTER_RELOAD   BIT_ULL(31)
> +#define L2_CYCLE_COUNTER_RELOAD BIT_ULL(63)

[...]

> +#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
> +#define L2CPUSRDR_EL1   S3_3_c15_c0_7

I should have realsied this before, but some old toolchains don't
support this format, as we discovered in commit 72c5839515260dce
("arm64: gicv3: Allow GICv3 compilation with older binutils").

So I think we need to use sys_reg() for these, i.e.

#define SYS_L2CPUSRSELR_EL1 sys_reg(3, 3, 15, 0, 6)
#defing SYS_L2CPUSRDR_EL1   sys_reg(3, 3, 15, 0, 7)

... and correspondingly we need to use {read_write}_sysreg_s() to
perform accesses to those.

[...]

> +static DEFINE_RAW_SPINLOCK(l2_access_lock);
> +
> +/**
> + * set_l2_indirect_reg: write value to an L2 register
> + * @reg: Address of L2 register.
> + * @value: Value to be written to register.
> + *
> + * Use architecturally required barriers for ordering between system register
> + * accesses
> + */
> +static void set_l2_indirect_reg(u64 reg, u64 val)
> +{
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(_access_lock, flags);
> + write_sysreg(reg, L2CPUSRSELR_EL1);
> + isb();
> + write_sysreg(val, L2CPUSRDR_EL1);
> + isb();
> + raw_spin_unlock_irqrestore(_access_lock, flags);
> +}

This is fine as is, but just for my understanding, I take it that the
locking is only strictly required to be per-cluster?

[...]

> +static void cluster_pmu_reset_on_cluster(void *x)
> +{
> + /* Reset all ctrs */
> + set_l2_indirect_reg(L2PMCR, L2PMCR_RESET_ALL);
> + set_l2_indirect_reg(L2PMCNTENCLR, l2_counter_present_mask);
> + set_l2_indirect_reg(L2PMINTENCLR, l2_counter_present_mask);
> + set_l2_indirect_reg(L2PMOVSCLR, l2_counter_present_mask);
> +}
> +
> +static inline void cluster_pmu_reset(struct cluster_pmu *cluster)
> +{
> + cpumask_t *mask = >cluster_cpus;
> +
> + if (smp_call_function_any(mask, cluster_pmu_reset_on_cluster, NULL, 1))
> + dev_err(>l2cache_pmu->pdev->dev,
> + "Failed to reset on cluster with cpu %d\n",
> + cpumask_first(>cluster_cpus));
> +}

We only ever call these in the probe path, which I don't think is
sufficient. We can boot with a limited set of CPUs since commit
44dbcc93ab67145b ("arm64: Fix behavior of maxcpus=N"), so this might not
reset all the PMU hardware.

I also assume that if a cluster is hotplugged off, the PMU hardware may
lose state (i.e. it is not in an always-on domain separated from the
CPUs), and therefore may need to be reset after CPUs have been
hotplugged in.

We can cater for both of these by moving the reset call into the hotplug
callback. I've give na a concrete example below for that.


[...]

> + counter_reg = (idx * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTR_BASE;
> + set_l2_indirect_reg(counter_reg, value & GENMASK(31, 0));

We should drop the masking here; it's not necessary given we only
program a fixed value. Were it necessary, there'd be a potential
mismatch with prev_count.

[...]

> + counter_reg = (idx * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTR_BASE;
> + value = get_l2_indirect_reg(counter_reg);

Given this pattern crops up a few times, can we drop something like:

#define reg_idx(reg, i) ((i * IA_L2_REG_OFFSET) + reg ## _BASE)

... at the top of the file, so we can write this inline:

value = get_l2_indirect_reg(reg_idx(IA_L2PMXEVCNTR, idx));

[...]

> +static int l2_cache_filter_match(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = >hw;
> + struct hw_perf_event *chwc;
> + struct cluster_pmu *cluster = get_cluster_pmu(event->cpu);
> + struct l2cache_pmu *l2cache_pmu;
> + struct perf_event *conflict_event;
> + unsigned int group = L2_EVT_GROUP(hwc->config_base);
> +
> + /*
> +  * Check for column exclusion: event column already in use by another
> +  * event. This is for events which are not in the same group.
> +  * Conflicting events in the same group are detected in event_init.
> +  */
> +
> + if (test_bit(group, cluster->used_groups)) {

Nit: this nesting is more painful than is necessary to read. Please
invert the condition and use an early return here.

> + conflict_event =
> + cluster->events[cluster->group_to_counter[group]];
> + if (conflict_event != event) {

If it's possible for conflict_event == event, it sounds like this is
fragile to the order events are added or removed.

When does conflict_event == event?

> +

Re: [PATCH REPOST 2/2] cgroup, perf_event: make perf_event controller work on cgroup2 hierarchy

[Tejun Heo]

Hello,

On Mon, Jan 30, 2017 at 11:05:41AM -0300, Arnaldo Carvalho de Melo wrote:
> > This was posted months ago and acked by Peter.  I thought it was
> > applied but apparently wasn't.  Peter asked Arnaldo whether the
> > userspace part looked which didn't get replied and that probably was
> > how it slipped through the crack.
> > 
> > Peter, Arnanldo, how should we proceed?  Should I route this through
> > the cgroup tree?
> 
> It looks ok, haven't tested it tho. I don't have a problem for it to go
> thru the cgroup tree. The change is small and restrictred to cgroup
> glue in tools/perf/.

Alright, thanks.  Will apply it to cgroup/for-4.11 in a couple days.
If there's any objection, please holler.

Thanks.

-- 
tejun

Re: [PATCH REPOST 2/2] cgroup, perf_event: make perf_event controller work on cgroup2 hierarchy

[Tejun Heo]

Hello,

On Mon, Jan 30, 2017 at 11:05:41AM -0300, Arnaldo Carvalho de Melo wrote:
> > This was posted months ago and acked by Peter.  I thought it was
> > applied but apparently wasn't.  Peter asked Arnaldo whether the
> > userspace part looked which didn't get replied and that probably was
> > how it slipped through the crack.
> > 
> > Peter, Arnanldo, how should we proceed?  Should I route this through
> > the cgroup tree?
> 
> It looks ok, haven't tested it tho. I don't have a problem for it to go
> thru the cgroup tree. The change is small and restrictred to cgroup
> glue in tools/perf/.

Alright, thanks.  Will apply it to cgroup/for-4.11 in a couple days.
If there's any objection, please holler.

Thanks.

-- 
tejun

Re: [PATCH v4 2/2] HWPOISON: soft offlining for non-lru movable page

[Yisheng Xie]

Hi, Michal,
Sorry for late reply.

On 01/26/2017 05:27 PM, Michal Hocko wrote:
> On Wed 25-01-17 23:05:38, ys...@foxmail.com wrote:
>> From: Yisheng Xie 
>>
>> This patch is to extends soft offlining framework to support
>> non-lru page, which already support migration after
>> commit bda807d44454 ("mm: migrate: support non-lru movable page
>> migration")
>>
>> When memory corrected errors occur on a non-lru movable page,
>> we can choose to stop using it by migrating data onto another
>> page and disable the original (maybe half-broken) one.
>>
>> Signed-off-by: Yisheng Xie 
>> Suggested-by: Michal Hocko 
>> Suggested-by: Minchan Kim 
>> Reviewed-by: Minchan Kim 
>> Acked-by: Naoya Horiguchi 
>> CC: Vlastimil Babka 
>> ---
>>  mm/memory-failure.c | 26 --
>>  1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index f283c7e..56e39f8 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1527,7 +1527,8 @@ static int get_any_page(struct page *page, unsigned 
>> long pfn, int flags)
>>  {
>>  int ret = __get_any_page(page, pfn, flags);
>>  
>> -if (ret == 1 && !PageHuge(page) && !PageLRU(page)) {
>> +if (ret == 1 && !PageHuge(page) &&
>> +!PageLRU(page) && !__PageMovable(page)) {
>>  /*
>>   * Try to free it.
>>   */
> Is this sufficient? Not that I am familiar with get_any_page() but
> __get_any_page doesn't seem to be aware of movable pages and neither
> shake_page is.
Sorry,maybe I do not quite get what you mean.
 If the page can be migrated, it can skip "shake_page and __get_any_page once 
more" here,
though it is not a free page. right ?
Please let me know if I miss anything.

>> @@ -1649,7 +1650,10 @@ static int __soft_offline_page(struct page *page, int 
>> flags)
>>   * Try to migrate to a new page instead. migrate.c
>>   * handles a large number of cases for us.
>>   */
>> -ret = isolate_lru_page(page);
>> +if (PageLRU(page))
>> +ret = isolate_lru_page(page);
>> +else if (!isolate_movable_page(page, ISOLATE_UNEVICTABLE))
>> +ret = -EBUSY;
> As pointed out in the previous response isolate_movable_page should
> really have the same return value contract as [__]isolate_lru_page
Yes, I agree with your suggestion. I will rewrite it in later patch if it is 
suitable.
as I mention before.

Thanks again for your reviewing.

Yisheng Xie
>>  /*
>>   * Drop page reference which is came from get_any_page()
>>   * successful isolate_lru_page() already took another one.

Re: [PATCH v4 2/2] HWPOISON: soft offlining for non-lru movable page

[Yisheng Xie]

Hi, Michal,
Sorry for late reply.

On 01/26/2017 05:27 PM, Michal Hocko wrote:
> On Wed 25-01-17 23:05:38, ys...@foxmail.com wrote:
>> From: Yisheng Xie 
>>
>> This patch is to extends soft offlining framework to support
>> non-lru page, which already support migration after
>> commit bda807d44454 ("mm: migrate: support non-lru movable page
>> migration")
>>
>> When memory corrected errors occur on a non-lru movable page,
>> we can choose to stop using it by migrating data onto another
>> page and disable the original (maybe half-broken) one.
>>
>> Signed-off-by: Yisheng Xie 
>> Suggested-by: Michal Hocko 
>> Suggested-by: Minchan Kim 
>> Reviewed-by: Minchan Kim 
>> Acked-by: Naoya Horiguchi 
>> CC: Vlastimil Babka 
>> ---
>>  mm/memory-failure.c | 26 --
>>  1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index f283c7e..56e39f8 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1527,7 +1527,8 @@ static int get_any_page(struct page *page, unsigned 
>> long pfn, int flags)
>>  {
>>  int ret = __get_any_page(page, pfn, flags);
>>  
>> -if (ret == 1 && !PageHuge(page) && !PageLRU(page)) {
>> +if (ret == 1 && !PageHuge(page) &&
>> +!PageLRU(page) && !__PageMovable(page)) {
>>  /*
>>   * Try to free it.
>>   */
> Is this sufficient? Not that I am familiar with get_any_page() but
> __get_any_page doesn't seem to be aware of movable pages and neither
> shake_page is.
Sorry,maybe I do not quite get what you mean.
 If the page can be migrated, it can skip "shake_page and __get_any_page once 
more" here,
though it is not a free page. right ?
Please let me know if I miss anything.

>> @@ -1649,7 +1650,10 @@ static int __soft_offline_page(struct page *page, int 
>> flags)
>>   * Try to migrate to a new page instead. migrate.c
>>   * handles a large number of cases for us.
>>   */
>> -ret = isolate_lru_page(page);
>> +if (PageLRU(page))
>> +ret = isolate_lru_page(page);
>> +else if (!isolate_movable_page(page, ISOLATE_UNEVICTABLE))
>> +ret = -EBUSY;
> As pointed out in the previous response isolate_movable_page should
> really have the same return value contract as [__]isolate_lru_page
Yes, I agree with your suggestion. I will rewrite it in later patch if it is 
suitable.
as I mention before.

Thanks again for your reviewing.

Yisheng Xie
>>  /*
>>   * Drop page reference which is came from get_any_page()
>>   * successful isolate_lru_page() already took another one.

Re: [PATCH 1/8] pinctrl: stm32: fix bad location of gpiochip_lock_as_irq

[Linus Walleij]

On Fri, Jan 27, 2017 at 5:15 PM, Alexandre TORGUE
 wrote:

> Move gpio lock as irq from "domain alloc" callback to "domain activate"
> callback. It will allow to use gpiolib sysfs correctly.
>
> Signed-off-by: Alexandre TORGUE 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 1/9] drivers: pinctrl: add driver for Allwinner H5 SoC

[Linus Walleij]

On Thu, Jan 26, 2017 at 4:48 PM, Icenowy Zheng  wrote:

> Based on the Allwinner H5 datasheet and the pinctrl driver of the
> backward-compatible H3 this introduces the pin multiplex assignments for
> the H5 SoC.
>
> H5 introduced some more pin functions (e.g. three more groups of TS
> pins, and one more groups of SIM pins) than H3.
>
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Fixed interrupt banks. (There's one more GPIO banks (PF) that can do
>   interrupt handling on H5)

Patch applied with Maxime's ACK.

Yours,
Linus Walleij

Re: [PATCH 1/8] pinctrl: stm32: fix bad location of gpiochip_lock_as_irq

[Linus Walleij]

On Fri, Jan 27, 2017 at 5:15 PM, Alexandre TORGUE
 wrote:

> Move gpio lock as irq from "domain alloc" callback to "domain activate"
> callback. It will allow to use gpiolib sysfs correctly.
>
> Signed-off-by: Alexandre TORGUE 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 1/9] drivers: pinctrl: add driver for Allwinner H5 SoC

[Linus Walleij]

On Thu, Jan 26, 2017 at 4:48 PM, Icenowy Zheng  wrote:

> Based on the Allwinner H5 datasheet and the pinctrl driver of the
> backward-compatible H3 this introduces the pin multiplex assignments for
> the H5 SoC.
>
> H5 introduced some more pin functions (e.g. three more groups of TS
> pins, and one more groups of SIM pins) than H3.
>
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Fixed interrupt banks. (There's one more GPIO banks (PF) that can do
>   interrupt handling on H5)

Patch applied with Maxime's ACK.

Yours,
Linus Walleij

Re: [PATCH v4] add u64 number parser

[J. R. Okajima]

Hello James,

Your commit
a317178 2016-12-06 parser: add u64 number parser
was merged into v4.10-rc1. Good.
I have a very similar function and used for a long time. Here I'd
suggest you a tiny optimization based on my version.

If you think another value is more apropriate as the size of an internal
array, you can change it freely.


J. R. Okajima

commit 030361e78d327d9d89254dc3b320c092221c7cd0
Author: J. R. Okajima 
Date:   Tue Jan 31 00:01:16 2017 +0900

parser: match_u64, short string optimization
 =

When the given string is short enough, we can skip kmalloc/kfree.

Signed-off-by: J. R. Okajima 

diff --git a/lib/parser.c b/lib/parser.c
index 3278958..cfbc6ec 100644
--- a/lib/parser.c
+++ b/lib/parser.c
@@ -163,21 +163,25 @@ static int match_number(substring_t *s, int *result,=
 int base)
  */
 static int match_u64int(substring_t *s, u64 *result, int base)
 {
-   char *buf;
+   char *buf, a[32];
int ret;
u64 val;
size_t len =3D s->to - s->from;
 =

-   buf =3D kmalloc(len + 1, GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
+   buf =3D a;
+   if (len + 1 > sizeof(a)) {
+   buf =3D kmalloc(len + 1, GFP_KERNEL);
+   if (unlikely(!buf))
+   return -ENOMEM;
+   }
memcpy(buf, s->from, len);
buf[len] =3D '\0';
 =

ret =3D kstrtoull(buf, base, );
if (!ret)
*result =3D val;
-   kfree(buf);
+   if (buf !=3D a)
+   kfree(buf);
return ret;
 }
 =

Re: [PATCH v4] add u64 number parser

[J. R. Okajima]

Hello James,

Your commit
a317178 2016-12-06 parser: add u64 number parser
was merged into v4.10-rc1. Good.
I have a very similar function and used for a long time. Here I'd
suggest you a tiny optimization based on my version.

If you think another value is more apropriate as the size of an internal
array, you can change it freely.


J. R. Okajima

commit 030361e78d327d9d89254dc3b320c092221c7cd0
Author: J. R. Okajima 
Date:   Tue Jan 31 00:01:16 2017 +0900

parser: match_u64, short string optimization
 =

When the given string is short enough, we can skip kmalloc/kfree.

Signed-off-by: J. R. Okajima 

diff --git a/lib/parser.c b/lib/parser.c
index 3278958..cfbc6ec 100644
--- a/lib/parser.c
+++ b/lib/parser.c
@@ -163,21 +163,25 @@ static int match_number(substring_t *s, int *result,=
 int base)
  */
 static int match_u64int(substring_t *s, u64 *result, int base)
 {
-   char *buf;
+   char *buf, a[32];
int ret;
u64 val;
size_t len =3D s->to - s->from;
 =

-   buf =3D kmalloc(len + 1, GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
+   buf =3D a;
+   if (len + 1 > sizeof(a)) {
+   buf =3D kmalloc(len + 1, GFP_KERNEL);
+   if (unlikely(!buf))
+   return -ENOMEM;
+   }
memcpy(buf, s->from, len);
buf[len] =3D '\0';
 =

ret =3D kstrtoull(buf, base, );
if (!ret)
*result =3D val;
-   kfree(buf);
+   if (buf !=3D a)
+   kfree(buf);
return ret;
 }
 =

Re: [PATCH net] net: ethtool: add support for 2500BaseT and 5000BaseT link modes

[David Miller]

From: Pavel Belous 
Date: Sat, 28 Jan 2017 22:53:28 +0300

> This patch introduce support for 2500BaseT and 5000BaseT link modes.
> These modes are included in the new IEEE 802.3bz standard.
> 
> Signed-off-by: Pavel Belous 

Applied.

Re: [PATCH net] net: ethtool: add support for 2500BaseT and 5000BaseT link modes

[David Miller]

From: Pavel Belous 
Date: Sat, 28 Jan 2017 22:53:28 +0300

> This patch introduce support for 2500BaseT and 5000BaseT link modes.
> These modes are included in the new IEEE 802.3bz standard.
> 
> Signed-off-by: Pavel Belous 

Applied.

[PATCH v3] xen,input: try to read screen resolution for xen-kbdfront

[Juergen Gross]

Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 
---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
 drivers/input/misc/xen-kbdfront.c | 46 ---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..9a20800 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -39,6 +40,9 @@ struct xenkbd_info {
int irq;
struct xenbus_device *xbdev;
char phys[32];
+#ifdef CONFIG_FB_NOTIFY
+   struct notifier_block nb;
+#endif
 };
 
 static int xenkbd_remove(struct xenbus_device *);
@@ -105,10 +109,29 @@ static irqreturn_t input_handler(int rq, void *dev_id)
return IRQ_HANDLED;
 }
 
+#ifdef CONFIG_FB
+#ifdef CONFIG_FB_NOTIFY
+static int xenkbd_fb_event(struct notifier_block *self,
+  unsigned long action, void *data)
+{
+   struct xenkbd_info *info = container_of(self, struct xenkbd_info, nb);
+   struct fb_info *fb = registered_fb[0];
+
+   if (action != FB_EVENT_FB_REGISTERED || !fb)
+   return 0;
+
+   input_set_abs_params(info->ptr, ABS_X, 0, fb->var.xres_virtual, 0, 0);
+   input_set_abs_params(info->ptr, ABS_Y, 0, fb->var.yres_virtual, 0, 0);
+
+   return 0;
+}
+#endif
+#endif
+
 static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
-   int ret, i;
+   int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +196,22 @@ static int xenkbd_probe(struct xenbus_device *dev,
ptr->id.product = 0xfffe;
 
if (abs) {
+   width = XENFB_WIDTH;
+   height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+   if (registered_fb[0]) {
+   width = registered_fb[0]->var.xres_virtual;
+   height = registered_fb[0]->var.yres_virtual;
+   } else {
+#ifdef CONFIG_FB_NOTIFY
+   info->nb.notifier_call = xenkbd_fb_event;
+   fb_register_client(>nb);
+#endif
+   }
+#endif
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
@@ -222,6 +258,10 @@ static int xenkbd_remove(struct xenbus_device *dev)
struct xenkbd_info *info = dev_get_drvdata(>dev);
 
xenkbd_disconnect_backend(info);
+#ifdef CONFIG_FB_NOTIFY
+   if (info->nb.notifier_call)
+   fb_unregister_client(>nb);
+#endif
if (info->kbd)
input_unregister_device(info->kbd);
if (info->ptr)
-- 
2.10.2

[PATCH v3] xen,input: try to read screen resolution for xen-kbdfront

[Juergen Gross]

Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 
---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
 drivers/input/misc/xen-kbdfront.c | 46 ---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..9a20800 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -39,6 +40,9 @@ struct xenkbd_info {
int irq;
struct xenbus_device *xbdev;
char phys[32];
+#ifdef CONFIG_FB_NOTIFY
+   struct notifier_block nb;
+#endif
 };
 
 static int xenkbd_remove(struct xenbus_device *);
@@ -105,10 +109,29 @@ static irqreturn_t input_handler(int rq, void *dev_id)
return IRQ_HANDLED;
 }
 
+#ifdef CONFIG_FB
+#ifdef CONFIG_FB_NOTIFY
+static int xenkbd_fb_event(struct notifier_block *self,
+  unsigned long action, void *data)
+{
+   struct xenkbd_info *info = container_of(self, struct xenkbd_info, nb);
+   struct fb_info *fb = registered_fb[0];
+
+   if (action != FB_EVENT_FB_REGISTERED || !fb)
+   return 0;
+
+   input_set_abs_params(info->ptr, ABS_X, 0, fb->var.xres_virtual, 0, 0);
+   input_set_abs_params(info->ptr, ABS_Y, 0, fb->var.yres_virtual, 0, 0);
+
+   return 0;
+}
+#endif
+#endif
+
 static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
-   int ret, i;
+   int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +196,22 @@ static int xenkbd_probe(struct xenbus_device *dev,
ptr->id.product = 0xfffe;
 
if (abs) {
+   width = XENFB_WIDTH;
+   height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+   if (registered_fb[0]) {
+   width = registered_fb[0]->var.xres_virtual;
+   height = registered_fb[0]->var.yres_virtual;
+   } else {
+#ifdef CONFIG_FB_NOTIFY
+   info->nb.notifier_call = xenkbd_fb_event;
+   fb_register_client(>nb);
+#endif
+   }
+#endif
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
@@ -222,6 +258,10 @@ static int xenkbd_remove(struct xenbus_device *dev)
struct xenkbd_info *info = dev_get_drvdata(>dev);
 
xenkbd_disconnect_backend(info);
+#ifdef CONFIG_FB_NOTIFY
+   if (info->nb.notifier_call)
+   fb_unregister_client(>nb);
+#endif
if (info->kbd)
input_unregister_device(info->kbd);
if (info->ptr)
-- 
2.10.2

Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace

[Kirill Tkhai]

ping

On 14.01.2017 17:15, Kirill Tkhai wrote:
> For correct checkpointing/restoring of a task from userspace
> it's need to know the task's pid_ns_for_children. Currently,
> there is no a sane way to do that (the only possible trick
> is to force the task create a new child and to analize the
> child's /proc/[pid]/ns/pid link, that is performance-stupid).
> 
> The patch exposes pid_ns_for_children to ns directory
> in standard way with the name "pid_for_children":
> 
> ~# ls /proc/5531/ns -l | grep pid
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836]
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286]
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  fs/proc/namespaces.c|1 +
>  include/linux/proc_ns.h |1 +
>  kernel/pid_namespace.c  |   25 +
>  3 files changed, 27 insertions(+)
> 
> diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
> index 766f0c637ad1..3803b24ca220 100644
> --- a/fs/proc/namespaces.c
> +++ b/fs/proc/namespaces.c
> @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = {
>  #endif
>  #ifdef CONFIG_PID_NS
>   _operations,
> + _for_children_operations,
>  #endif
>  #ifdef CONFIG_USER_NS
>   _operations,
> diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h
> index 88dba3b53375..58ab28d81fc2 100644
> --- a/include/linux/proc_ns.h
> +++ b/include/linux/proc_ns.h
> @@ -27,6 +27,7 @@ extern const struct proc_ns_operations netns_operations;
>  extern const struct proc_ns_operations utsns_operations;
>  extern const struct proc_ns_operations ipcns_operations;
>  extern const struct proc_ns_operations pidns_operations;
> +extern const struct proc_ns_operations pidns_for_children_operations;
>  extern const struct proc_ns_operations userns_operations;
>  extern const struct proc_ns_operations mntns_operations;
>  extern const struct proc_ns_operations cgroupns_operations;
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index df9e8e9e0be7..cbe950d4a11e 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -369,6 +369,20 @@ static struct ns_common *pidns_get(struct task_struct 
> *task)
>   return ns ? >ns : NULL;
>  }
>  
> +static struct ns_common *pidns_for_children_get(struct task_struct *task)
> +{
> + struct pid_namespace *ns = NULL;
> +
> + task_lock(task);
> + if (task->nsproxy) {
> + ns = task->nsproxy->pid_ns_for_children;
> + get_pid_ns(ns);
> + }
> + task_unlock(task);
> +
> + return ns ? >ns : NULL;
> +}
> +
>  static void pidns_put(struct ns_common *ns)
>  {
>   put_pid_ns(to_pid_ns(ns));
> @@ -438,6 +452,17 @@ const struct proc_ns_operations pidns_operations = {
>   .get_parent = pidns_get_parent,
>  };
>  
> +const struct proc_ns_operations pidns_for_children_operations = {
> + .name   = "pid_for_children",
> + .real_ns_name   = "pid",
> + .type   = CLONE_NEWPID,
> + .get= pidns_for_children_get,
> + .put= pidns_put,
> + .install= pidns_install,
> + .owner  = pidns_owner,
> + .get_parent = pidns_get_parent,
> +};
> +
>  static __init int pid_namespaces_init(void)
>  {
>   pid_ns_cachep = KMEM_CACHE(pid_namespace, SLAB_PANIC);
> 

Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace

[Kirill Tkhai]

ping

On 14.01.2017 17:15, Kirill Tkhai wrote:
> For correct checkpointing/restoring of a task from userspace
> it's need to know the task's pid_ns_for_children. Currently,
> there is no a sane way to do that (the only possible trick
> is to force the task create a new child and to analize the
> child's /proc/[pid]/ns/pid link, that is performance-stupid).
> 
> The patch exposes pid_ns_for_children to ns directory
> in standard way with the name "pid_for_children":
> 
> ~# ls /proc/5531/ns -l | grep pid
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836]
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286]
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  fs/proc/namespaces.c|1 +
>  include/linux/proc_ns.h |1 +
>  kernel/pid_namespace.c  |   25 +
>  3 files changed, 27 insertions(+)
> 
> diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
> index 766f0c637ad1..3803b24ca220 100644
> --- a/fs/proc/namespaces.c
> +++ b/fs/proc/namespaces.c
> @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = {
>  #endif
>  #ifdef CONFIG_PID_NS
>   _operations,
> + _for_children_operations,
>  #endif
>  #ifdef CONFIG_USER_NS
>   _operations,
> diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h
> index 88dba3b53375..58ab28d81fc2 100644
> --- a/include/linux/proc_ns.h
> +++ b/include/linux/proc_ns.h
> @@ -27,6 +27,7 @@ extern const struct proc_ns_operations netns_operations;
>  extern const struct proc_ns_operations utsns_operations;
>  extern const struct proc_ns_operations ipcns_operations;
>  extern const struct proc_ns_operations pidns_operations;
> +extern const struct proc_ns_operations pidns_for_children_operations;
>  extern const struct proc_ns_operations userns_operations;
>  extern const struct proc_ns_operations mntns_operations;
>  extern const struct proc_ns_operations cgroupns_operations;
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index df9e8e9e0be7..cbe950d4a11e 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -369,6 +369,20 @@ static struct ns_common *pidns_get(struct task_struct 
> *task)
>   return ns ? >ns : NULL;
>  }
>  
> +static struct ns_common *pidns_for_children_get(struct task_struct *task)
> +{
> + struct pid_namespace *ns = NULL;
> +
> + task_lock(task);
> + if (task->nsproxy) {
> + ns = task->nsproxy->pid_ns_for_children;
> + get_pid_ns(ns);
> + }
> + task_unlock(task);
> +
> + return ns ? >ns : NULL;
> +}
> +
>  static void pidns_put(struct ns_common *ns)
>  {
>   put_pid_ns(to_pid_ns(ns));
> @@ -438,6 +452,17 @@ const struct proc_ns_operations pidns_operations = {
>   .get_parent = pidns_get_parent,
>  };
>  
> +const struct proc_ns_operations pidns_for_children_operations = {
> + .name   = "pid_for_children",
> + .real_ns_name   = "pid",
> + .type   = CLONE_NEWPID,
> + .get= pidns_for_children_get,
> + .put= pidns_put,
> + .install= pidns_install,
> + .owner  = pidns_owner,
> + .get_parent = pidns_get_parent,
> +};
> +
>  static __init int pid_namespaces_init(void)
>  {
>   pid_ns_cachep = KMEM_CACHE(pid_namespace, SLAB_PANIC);
> 

Re: [PATCH v2 0/2] drm: Add support for tiny LCD displays

[Noralf Trønnes]

Den 30.01.2017 09.44, skrev Daniel Vetter:

Hi Noralf,

On Fri, Jan 27, 2017 at 08:56:29PM +0100, Noralf Trønnes wrote:

This is an attempt at providing a DRM version of drivers/staging/fbtft.

The tinydrm library provides a very simplified view of DRM in particular
for tiny displays that has onboard video memory and is connected through
a slow bus like SPI/I2C.

Only core patches this time.


Noralf.


Changes since version 1:
- Add tinydrm.rst
- Set tdev->fbdev_cma=NULL on unregister (lastclose is called after that).

Hm, this sounds like a buglet in the drm framework ... how do we call
lastclose when the driver is disappearing? I do see a drm_lastclose call
at the beginning of drm_dev_unregister (which we might want to remove for
KMS drivers, it doesn't make much sense imo), but that shouldn't result in
troubles.


Ah, I see, I'm tearing down fbdev before unregistering drm.
That should be reversed.

static void tinydrm_unregister(struct tinydrm_device *tdev)
{
drm_crtc_force_disable_all(tdev->drm);

if (tdev->fbdev_cma) {
drm_fbdev_cma_fini(tdev->fbdev_cma);
tdev->fbdev_cma = NULL;
}

drm_dev_unregister(tdev->drm);
}


- Remove some DRM_DEBUG*()
- Write-combined memory has uncached reads, so speed up by copying/buffering
   one pixel line before conversion.

Hm, why are you using write-combining memory? Or is that needed so that
you can (if available) use hw spi engines?


That comes with using the CMA helper:
drm_fbdev_cma_create_with_funcs() -> drm_gem_cma_create() -> dma_alloc_wc()

Here's a comment I have added in the code for why I set the DMA mask on
the SPI device and why it will work:

/*
 * Even though it's not the SPI device that does DMA (the master does),
 * the dma mask is necessary for the dma_alloc_wc() in
 * drm_gem_cma_create(). The dma_addr returned will be a physical
 * adddress which might be different from the bus address, but this is
 * not a problem since the address will not be used.
 * The virtual address is used in the transfer and the SPI core
 * re-maps it on the SPI master device using the DMA streaming API
 * (spi_map_buf()).
 */


Either way, I think this all looks good, pls submit a pull request to Dave
with these two patches as soon as latest drm-misc has landed (I'll send a
pull request for that later today).


I'm confused, I thought you wanted the core patches through drm-misc
and the rest as a pull request to Dave.

This is what you said:

Looks all pretty. A bunch of ideas below, but all optional. For 
merging I
think simplest to first get the core patches in through drm-misc, 
and then
you can submit a pull request to Dave for tinydrm+backends (just 
needs an

ack for the dt parts from dt maintainers), including MAINTAINERS entry.
Ack from my side.


Another one: Do you want to maintain tinydrm as part of the drm-misc
group, i.e. want commit rights there? That would also help a bit with
pushing all your great drm refactoring patches through the machinery ...


My goal is to port staging/fbtft to drm. Whether or not I will do work
in drm core (refactoring) besides the tinydrm drivers when that is
accomplished, I don't know. Working on drm as a hobbyist is very
difficult (for me at least) because it is very complex, it changes all
the time and on top of that it has a high volume mailinglist.
It takes effort to keep up.

So I will probably end up doing only tinydrm maintanence.
As for how that is best done, I don't know. Once I have covered a 3-4
controller types, a new driver is just a copy of a similar one with a
different register initialization. This means that it's easy to review
patches. They will all look the same, more or less.
So for me it's ofc best if I can review the patches and then commit
them myself. As for my own patches, if I need that tit for tat
reviewing to get them in, it will be difficult for me to review other
drivers because I have no idea how a GPU operates, and to keep up with
drm best pratices will be next to impossible for me.

If the Device Tree guys allows me to add fbtft support to tinydrm, then
there won't be much activity once the fbtft drivers have been ported
over. The uncertainty stems from the fact that the fbtft drivers are
written as controller drivers, but they contain panel specific things
like register setup and how to do rotation.
So compatible = "fb_ili9341", supports a controller with a specific
panel, but it can support other panels through the 'init' DT property
which encodes register values and delays (which is a no-no).

Noralf.

Re: [PATCH v2 0/2] drm: Add support for tiny LCD displays

[Noralf Trønnes]

Den 30.01.2017 09.44, skrev Daniel Vetter:

Hi Noralf,

On Fri, Jan 27, 2017 at 08:56:29PM +0100, Noralf Trønnes wrote:

This is an attempt at providing a DRM version of drivers/staging/fbtft.

The tinydrm library provides a very simplified view of DRM in particular
for tiny displays that has onboard video memory and is connected through
a slow bus like SPI/I2C.

Only core patches this time.


Noralf.


Changes since version 1:
- Add tinydrm.rst
- Set tdev->fbdev_cma=NULL on unregister (lastclose is called after that).

Hm, this sounds like a buglet in the drm framework ... how do we call
lastclose when the driver is disappearing? I do see a drm_lastclose call
at the beginning of drm_dev_unregister (which we might want to remove for
KMS drivers, it doesn't make much sense imo), but that shouldn't result in
troubles.


Ah, I see, I'm tearing down fbdev before unregistering drm.
That should be reversed.

static void tinydrm_unregister(struct tinydrm_device *tdev)
{
drm_crtc_force_disable_all(tdev->drm);

if (tdev->fbdev_cma) {
drm_fbdev_cma_fini(tdev->fbdev_cma);
tdev->fbdev_cma = NULL;
}

drm_dev_unregister(tdev->drm);
}


- Remove some DRM_DEBUG*()
- Write-combined memory has uncached reads, so speed up by copying/buffering
   one pixel line before conversion.

Hm, why are you using write-combining memory? Or is that needed so that
you can (if available) use hw spi engines?


That comes with using the CMA helper:
drm_fbdev_cma_create_with_funcs() -> drm_gem_cma_create() -> dma_alloc_wc()

Here's a comment I have added in the code for why I set the DMA mask on
the SPI device and why it will work:

/*
 * Even though it's not the SPI device that does DMA (the master does),
 * the dma mask is necessary for the dma_alloc_wc() in
 * drm_gem_cma_create(). The dma_addr returned will be a physical
 * adddress which might be different from the bus address, but this is
 * not a problem since the address will not be used.
 * The virtual address is used in the transfer and the SPI core
 * re-maps it on the SPI master device using the DMA streaming API
 * (spi_map_buf()).
 */


Either way, I think this all looks good, pls submit a pull request to Dave
with these two patches as soon as latest drm-misc has landed (I'll send a
pull request for that later today).


I'm confused, I thought you wanted the core patches through drm-misc
and the rest as a pull request to Dave.

This is what you said:

Looks all pretty. A bunch of ideas below, but all optional. For 
merging I
think simplest to first get the core patches in through drm-misc, 
and then
you can submit a pull request to Dave for tinydrm+backends (just 
needs an

ack for the dt parts from dt maintainers), including MAINTAINERS entry.
Ack from my side.


Another one: Do you want to maintain tinydrm as part of the drm-misc
group, i.e. want commit rights there? That would also help a bit with
pushing all your great drm refactoring patches through the machinery ...


My goal is to port staging/fbtft to drm. Whether or not I will do work
in drm core (refactoring) besides the tinydrm drivers when that is
accomplished, I don't know. Working on drm as a hobbyist is very
difficult (for me at least) because it is very complex, it changes all
the time and on top of that it has a high volume mailinglist.
It takes effort to keep up.

So I will probably end up doing only tinydrm maintanence.
As for how that is best done, I don't know. Once I have covered a 3-4
controller types, a new driver is just a copy of a similar one with a
different register initialization. This means that it's easy to review
patches. They will all look the same, more or less.
So for me it's ofc best if I can review the patches and then commit
them myself. As for my own patches, if I need that tit for tat
reviewing to get them in, it will be difficult for me to review other
drivers because I have no idea how a GPU operates, and to keep up with
drm best pratices will be next to impossible for me.

If the Device Tree guys allows me to add fbtft support to tinydrm, then
there won't be much activity once the fbtft drivers have been ported
over. The uncertainty stems from the fact that the fbtft drivers are
written as controller drivers, but they contain panel specific things
like register setup and how to do rotation.
So compatible = "fb_ili9341", supports a controller with a specific
panel, but it can support other panels through the 'init' DT property
which encodes register values and delays (which is a no-no).

Noralf.

Re: [PATCH] tools/headers: Sync {tools/,}arch/powerpc/include/uapi/asm/kvm.h, {tools/,}arch/x86/include/asm/cpufeatures.h and {tools/,}arch/arm/include/uapi/asm/kvm.h

[Arnaldo Carvalho de Melo]

Em Mon, Jan 30, 2017 at 09:11:31AM +0100, Ingo Molnar escreveu:
> 
> The following upstream headers were updated:
> 
>  - The x86 cpufeatures.h file picked up a couple of new feature entries
>  - The PowerPC and ARM KVM headers picked up new features
> 
> None of which requires changes to perf tooling, so refresh the tooling copy.

Thanks, applied.

- Arnaldo
 
> Solves these build time warnings:
> 
>  Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
>  Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel
>  Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel
> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Peter Zijlstra 
> Cc: Namhyung Kim 
> Cc: David Ahern 
> Cc: Jiri Olsa 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ingo Molnar 
> ---
>  tools/arch/arm/include/uapi/asm/kvm.h |  9 +
>  tools/arch/powerpc/include/uapi/asm/kvm.h |  5 +
>  tools/arch/x86/include/asm/cpufeatures.h  | 12 +++-
>  3 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/arch/arm/include/uapi/asm/kvm.h 
> b/tools/arch/arm/include/uapi/asm/kvm.h
> index a2b3eb313a25..af05f8e0903e 100644
> --- a/tools/arch/arm/include/uapi/asm/kvm.h
> +++ b/tools/arch/arm/include/uapi/asm/kvm.h
> @@ -84,6 +84,15 @@ struct kvm_regs {
>  #define KVM_VGIC_V2_DIST_SIZE0x1000
>  #define KVM_VGIC_V2_CPU_SIZE 0x2000
>  
> +/* Supported VGICv3 address types  */
> +#define KVM_VGIC_V3_ADDR_TYPE_DIST   2
> +#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
> +#define KVM_VGIC_ITS_ADDR_TYPE   4
> +
> +#define KVM_VGIC_V3_DIST_SIZESZ_64K
> +#define KVM_VGIC_V3_REDIST_SIZE  (2 * SZ_64K)
> +#define KVM_VGIC_V3_ITS_SIZE (2 * SZ_64K)
> +
>  #define KVM_ARM_VCPU_POWER_OFF   0 /* CPU is started in OFF 
> state */
>  #define KVM_ARM_VCPU_PSCI_0_21 /* CPU uses PSCI v0.2 */
>  
> diff --git a/tools/arch/powerpc/include/uapi/asm/kvm.h 
> b/tools/arch/powerpc/include/uapi/asm/kvm.h
> index c93cf35ce379..3603b6f51b11 100644
> --- a/tools/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/tools/arch/powerpc/include/uapi/asm/kvm.h
> @@ -573,6 +573,10 @@ struct kvm_get_htab_header {
>  #define KVM_REG_PPC_SPRG9(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xba)
>  #define KVM_REG_PPC_DBSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xbb)
>  
> +/* POWER9 registers */
> +#define KVM_REG_PPC_TIDR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbc)
> +#define KVM_REG_PPC_PSSCR(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbd)
> +
>  /* Transactional Memory checkpointed state:
>   * This is all GPRs, all VSX regs and a subset of SPRs
>   */
> @@ -596,6 +600,7 @@ struct kvm_get_htab_header {
>  #define KVM_REG_PPC_TM_VSCR  (KVM_REG_PPC_TM | KVM_REG_SIZE_U32 | 0x67)
>  #define KVM_REG_PPC_TM_DSCR  (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x68)
>  #define KVM_REG_PPC_TM_TAR   (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x69)
> +#define KVM_REG_PPC_TM_XER   (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x6a)
>  
>  /* PPC64 eXternal Interrupt Controller Specification */
>  #define KVM_DEV_XICS_GRP_SOURCES 1   /* 64-bit source attributes */
> diff --git a/tools/arch/x86/include/asm/cpufeatures.h 
> b/tools/arch/x86/include/asm/cpufeatures.h
> index 3603556fa0d9..d45ab4b53396 100644
> --- a/tools/arch/x86/include/asm/cpufeatures.h
> +++ b/tools/arch/x86/include/asm/cpufeatures.h
> @@ -100,11 +100,12 @@
>  #define X86_FEATURE_XTOPOLOGY( 3*32+22) /* cpu topology enum 
> extensions */
>  #define X86_FEATURE_TSC_RELIABLE ( 3*32+23) /* TSC is known to be reliable */
>  #define X86_FEATURE_NONSTOP_TSC  ( 3*32+24) /* TSC does not stop in C 
> states */
> -/* free, was #define X86_FEATURE_CLFLUSH_MONITOR ( 3*32+25) * "" clflush 
> reqd with monitor */
> +#define X86_FEATURE_CPUID( 3*32+25) /* CPU has CPUID instruction itself 
> */
>  #define X86_FEATURE_EXTD_APICID  ( 3*32+26) /* has extended APICID (8 
> bits) */
>  #define X86_FEATURE_AMD_DCM ( 3*32+27) /* multi-node processor */
>  #define X86_FEATURE_APERFMPERF   ( 3*32+28) /* APERFMPERF */
>  #define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 
> state */
> +#define X86_FEATURE_TSC_KNOWN_FREQ ( 3*32+31) /* TSC has known frequency */
>  
>  /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
>  #define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */
> @@ -188,10 +189,14 @@
>  
>  #define X86_FEATURE_CPB  ( 7*32+ 2) /* AMD Core Performance 
> Boost */
>  #define X86_FEATURE_EPB  ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
> support */
> +#define X86_FEATURE_CAT_L3   ( 7*32+ 4) /* Cache Allocation Technology L3 */
> +#define X86_FEATURE_CAT_L2   ( 7*32+ 5) /* Cache Allocation Technology L2 */
> +#define X86_FEATURE_CDP_L3   ( 7*32+ 6) /* Code and Data Prioritization L3 */
>  
>  #define X86_FEATURE_HW_PSTATE( 7*32+ 

Re: [PATCH] tools/headers: Sync {tools/,}arch/powerpc/include/uapi/asm/kvm.h, {tools/,}arch/x86/include/asm/cpufeatures.h and {tools/,}arch/arm/include/uapi/asm/kvm.h

[Arnaldo Carvalho de Melo]

Em Mon, Jan 30, 2017 at 09:11:31AM +0100, Ingo Molnar escreveu:
> 
> The following upstream headers were updated:
> 
>  - The x86 cpufeatures.h file picked up a couple of new feature entries
>  - The PowerPC and ARM KVM headers picked up new features
> 
> None of which requires changes to perf tooling, so refresh the tooling copy.

Thanks, applied.

- Arnaldo
 
> Solves these build time warnings:
> 
>  Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
>  Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel
>  Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel
> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Peter Zijlstra 
> Cc: Namhyung Kim 
> Cc: David Ahern 
> Cc: Jiri Olsa 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ingo Molnar 
> ---
>  tools/arch/arm/include/uapi/asm/kvm.h |  9 +
>  tools/arch/powerpc/include/uapi/asm/kvm.h |  5 +
>  tools/arch/x86/include/asm/cpufeatures.h  | 12 +++-
>  3 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/arch/arm/include/uapi/asm/kvm.h 
> b/tools/arch/arm/include/uapi/asm/kvm.h
> index a2b3eb313a25..af05f8e0903e 100644
> --- a/tools/arch/arm/include/uapi/asm/kvm.h
> +++ b/tools/arch/arm/include/uapi/asm/kvm.h
> @@ -84,6 +84,15 @@ struct kvm_regs {
>  #define KVM_VGIC_V2_DIST_SIZE0x1000
>  #define KVM_VGIC_V2_CPU_SIZE 0x2000
>  
> +/* Supported VGICv3 address types  */
> +#define KVM_VGIC_V3_ADDR_TYPE_DIST   2
> +#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
> +#define KVM_VGIC_ITS_ADDR_TYPE   4
> +
> +#define KVM_VGIC_V3_DIST_SIZESZ_64K
> +#define KVM_VGIC_V3_REDIST_SIZE  (2 * SZ_64K)
> +#define KVM_VGIC_V3_ITS_SIZE (2 * SZ_64K)
> +
>  #define KVM_ARM_VCPU_POWER_OFF   0 /* CPU is started in OFF 
> state */
>  #define KVM_ARM_VCPU_PSCI_0_21 /* CPU uses PSCI v0.2 */
>  
> diff --git a/tools/arch/powerpc/include/uapi/asm/kvm.h 
> b/tools/arch/powerpc/include/uapi/asm/kvm.h
> index c93cf35ce379..3603b6f51b11 100644
> --- a/tools/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/tools/arch/powerpc/include/uapi/asm/kvm.h
> @@ -573,6 +573,10 @@ struct kvm_get_htab_header {
>  #define KVM_REG_PPC_SPRG9(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xba)
>  #define KVM_REG_PPC_DBSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xbb)
>  
> +/* POWER9 registers */
> +#define KVM_REG_PPC_TIDR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbc)
> +#define KVM_REG_PPC_PSSCR(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbd)
> +
>  /* Transactional Memory checkpointed state:
>   * This is all GPRs, all VSX regs and a subset of SPRs
>   */
> @@ -596,6 +600,7 @@ struct kvm_get_htab_header {
>  #define KVM_REG_PPC_TM_VSCR  (KVM_REG_PPC_TM | KVM_REG_SIZE_U32 | 0x67)
>  #define KVM_REG_PPC_TM_DSCR  (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x68)
>  #define KVM_REG_PPC_TM_TAR   (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x69)
> +#define KVM_REG_PPC_TM_XER   (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x6a)
>  
>  /* PPC64 eXternal Interrupt Controller Specification */
>  #define KVM_DEV_XICS_GRP_SOURCES 1   /* 64-bit source attributes */
> diff --git a/tools/arch/x86/include/asm/cpufeatures.h 
> b/tools/arch/x86/include/asm/cpufeatures.h
> index 3603556fa0d9..d45ab4b53396 100644
> --- a/tools/arch/x86/include/asm/cpufeatures.h
> +++ b/tools/arch/x86/include/asm/cpufeatures.h
> @@ -100,11 +100,12 @@
>  #define X86_FEATURE_XTOPOLOGY( 3*32+22) /* cpu topology enum 
> extensions */
>  #define X86_FEATURE_TSC_RELIABLE ( 3*32+23) /* TSC is known to be reliable */
>  #define X86_FEATURE_NONSTOP_TSC  ( 3*32+24) /* TSC does not stop in C 
> states */
> -/* free, was #define X86_FEATURE_CLFLUSH_MONITOR ( 3*32+25) * "" clflush 
> reqd with monitor */
> +#define X86_FEATURE_CPUID( 3*32+25) /* CPU has CPUID instruction itself 
> */
>  #define X86_FEATURE_EXTD_APICID  ( 3*32+26) /* has extended APICID (8 
> bits) */
>  #define X86_FEATURE_AMD_DCM ( 3*32+27) /* multi-node processor */
>  #define X86_FEATURE_APERFMPERF   ( 3*32+28) /* APERFMPERF */
>  #define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 
> state */
> +#define X86_FEATURE_TSC_KNOWN_FREQ ( 3*32+31) /* TSC has known frequency */
>  
>  /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
>  #define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */
> @@ -188,10 +189,14 @@
>  
>  #define X86_FEATURE_CPB  ( 7*32+ 2) /* AMD Core Performance 
> Boost */
>  #define X86_FEATURE_EPB  ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
> support */
> +#define X86_FEATURE_CAT_L3   ( 7*32+ 4) /* Cache Allocation Technology L3 */
> +#define X86_FEATURE_CAT_L2   ( 7*32+ 5) /* Cache Allocation Technology L2 */
> +#define X86_FEATURE_CDP_L3   ( 7*32+ 6) /* Code and Data Prioritization L3 */
>  
>  #define X86_FEATURE_HW_PSTATE( 7*32+ 8) /* AMD HW-PState */
>  #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
>  
> 

[PATCH v3 4/4] arm64: dts: msm8996: Add SLPI SMP2P dt node.

[Avaneesh Kumar Dwivedi]

Add smp2p support to communicate with slpi processor.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 29ed6b6..5bec315 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -551,5 +551,29 @@
#interrupt-cells = <2>;
};
};
+
+   smp2p-slpi {
+   compatible = "qcom,smp2p";
+   qcom,smem = <481>, <430>;
+
+   interrupts = ;
+
+   qcom,ipc = < 16 26>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <3>;
+
+   slpi_smp2p_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   slpi_smp2p_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+   };
+
 };
 #include "msm8996-pins.dtsi"
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH v3 4/4] arm64: dts: msm8996: Add SLPI SMP2P dt node.

[Avaneesh Kumar Dwivedi]

Add smp2p support to communicate with slpi processor.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 29ed6b6..5bec315 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -551,5 +551,29 @@
#interrupt-cells = <2>;
};
};
+
+   smp2p-slpi {
+   compatible = "qcom,smp2p";
+   qcom,smem = <481>, <430>;
+
+   interrupts = ;
+
+   qcom,ipc = < 16 26>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <3>;
+
+   slpi_smp2p_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   slpi_smp2p_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+   };
+
 };
 #include "msm8996-pins.dtsi"
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH 0/8] Add STM32F469 pinctrl and fix issues in STM32 pinctrl

[Alexandre Torgue]

Hi,

On 01/27/2017 05:15 PM, Alexandre TORGUE wrote:

This series adds support of a dedicated driver for STM32F469 MCU pinctroller.
This add generates some changes inside STM32 pinctrl driver and inside STM32
device tree.

Changes in STM32 pinctrl driver:
---

- Add STM32F469 driver.

- Change STM32 pinctrl core in order to use "gpio-ranges" devicetree 
definitions.
  Indeed, on STM32F469 there an hole in BANK J. We need to declare a 
gpio-ranges
  in gpioj controller node to handle this hole.

Changes in STM32 device tree:

I propose a new architecture (a new file split) for pinmux definition:

- Create a common stm32f4-pinctrl.dtsi for pinmuxing definitions
  which are common between STM32F429 and STM32F469 MCU.

- Create dedicated stm32fxxx-pinctrl.dtsi file for each MCU
  (stm32f429-pinctrl.dtsi and stm32f469-pinctrl.dtsi) each one will
  include stm32f4-pinctrl.dtsi. All differences (pinmuxing or GPIO
  bank holes) will be put inside the dedicated files.

This series fix a locking issue when a gpio is used as IRQ.

Regards
Alex

Alexandre TORGUE (8):
  pinctrl: stm32: fix bad location of gpiochip_lock_as_irq
  pinctrl: stm32: use gpio-ranges to declare bank range


I just see typo issue in patch 1&2. I will send a V2 when more review 
will be done.


Regards
Alex



  Documentation: dt: Add bindings for STM32 pinctrl
  includes: dt-bindings: Rename STM32F429 pinctrl DT bindings
  pinctrl: stm32: Add STM32F469 MCU support
  Documentation: dt: Add new compatible to STM32 pinctrl driver bindings
  ARM: Kconfig: Introduce MACH_STM32F469 flag
  ARM: dts: stm32: create dedicated files for pinctrl definitions

 .../bindings/pinctrl/st,stm32-pinctrl.txt  |   57 +-
 arch/arm/Kconfig   |5 +
 arch/arm/boot/dts/stm32429i-eval.dts   |1 +
 arch/arm/boot/dts/stm32f4-pinctrl.dtsi |  196 +++
 arch/arm/boot/dts/stm32f429-disco.dts  |1 +
 arch/arm/boot/dts/stm32f429-pinctrl.dtsi   |  106 ++
 arch/arm/boot/dts/stm32f429.dtsi   |  153 --
 arch/arm/boot/dts/stm32f469-disco.dts  |1 +
 arch/arm/boot/dts/stm32f469-pinctrl.dtsi   |  107 ++
 drivers/pinctrl/stm32/Kconfig  |6 +
 drivers/pinctrl/stm32/Makefile |1 +
 drivers/pinctrl/stm32/pinctrl-stm32.c  |  129 +-
 drivers/pinctrl/stm32/pinctrl-stm32f469.c  | 1574 
 include/dt-bindings/pinctrl/stm32f4-pinfunc.h  | 1302 
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h| 1239 ---
 15 files changed, 3414 insertions(+), 1464 deletions(-)
 create mode 100644 arch/arm/boot/dts/stm32f4-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32f429-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32f469-pinctrl.dtsi
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f469.c
 create mode 100644 include/dt-bindings/pinctrl/stm32f4-pinfunc.h
 delete mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

[PATCH v3 1/4] remoteproc: qcom: Compatible string based resource initialization.

[Avaneesh Kumar Dwivedi]

This patch initialize certain driver related data based on compatible
string. This enable driver to handle more than one similar device in
by differentiating in probe their private data.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 drivers/remoteproc/qcom_adsp_pil.c | 47 ++
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index 43a4ed2..f674301 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -32,9 +32,12 @@
 #include "qcom_mdt_loader.h"
 #include "remoteproc_internal.h"
 
-#define ADSP_CRASH_REASON_SMEM 423
-#define ADSP_FIRMWARE_NAME "adsp.mdt"
-#define ADSP_PAS_ID1
+struct adsp_data {
+   int crash_reason_smem;
+   const char *firmware_name;
+   int pas_id;
+};
+
 
 struct qcom_adsp {
struct device *dev;
@@ -53,6 +56,9 @@ struct qcom_adsp {
 
struct regulator *cx_supply;
 
+   int pas_id;
+   int crash_reason_smem;
+
struct completion start_done;
struct completion stop_done;
 
@@ -70,7 +76,7 @@ static int adsp_load(struct rproc *rproc, const struct 
firmware *fw)
bool relocate;
int ret;
 
-   ret = qcom_scm_pas_init_image(ADSP_PAS_ID, fw->data, fw->size);
+   ret = qcom_scm_pas_init_image(adsp->pas_id, fw->data, fw->size);
if (ret) {
dev_err(>dev, "invalid firmware metadata\n");
return ret;
@@ -85,7 +91,8 @@ static int adsp_load(struct rproc *rproc, const struct 
firmware *fw)
if (relocate) {
adsp->mem_reloc = fw_addr;
 
-   ret = qcom_scm_pas_mem_setup(ADSP_PAS_ID, adsp->mem_phys, 
fw_size);
+   ret = qcom_scm_pas_mem_setup(adsp->pas_id,
+   adsp->mem_phys, fw_size);
if (ret) {
dev_err(>dev, "unable to setup memory for 
image\n");
return ret;
@@ -113,7 +120,7 @@ static int adsp_start(struct rproc *rproc)
if (ret)
goto disable_clocks;
 
-   ret = qcom_scm_pas_auth_and_reset(ADSP_PAS_ID);
+   ret = qcom_scm_pas_auth_and_reset(adsp->pas_id);
if (ret) {
dev_err(adsp->dev,
"failed to authenticate image and release reset\n");
@@ -124,7 +131,7 @@ static int adsp_start(struct rproc *rproc)
  msecs_to_jiffies(5000));
if (!ret) {
dev_err(adsp->dev, "start timed out\n");
-   qcom_scm_pas_shutdown(ADSP_PAS_ID);
+   qcom_scm_pas_shutdown(adsp->pas_id);
ret = -ETIMEDOUT;
goto disable_regulators;
}
@@ -157,7 +164,7 @@ static int adsp_stop(struct rproc *rproc)
BIT(adsp->stop_bit),
0);
 
-   ret = qcom_scm_pas_shutdown(ADSP_PAS_ID);
+   ret = qcom_scm_pas_shutdown(adsp->pas_id);
if (ret)
dev_err(adsp->dev, "failed to shutdown: %d\n", ret);
 
@@ -197,7 +204,7 @@ static irqreturn_t adsp_fatal_interrupt(int irq, void *dev)
size_t len;
char *msg;
 
-   msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, ADSP_CRASH_REASON_SMEM, );
+   msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, adsp->crash_reason_smem, );
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(adsp->dev, "fatal error received: %s\n", msg);
 
@@ -311,20 +318,25 @@ static int adsp_alloc_memory_region(struct qcom_adsp 
*adsp)
 
 static int adsp_probe(struct platform_device *pdev)
 {
+   const struct adsp_data *desc;
struct qcom_adsp *adsp;
struct rproc *rproc;
int ret;
 
+   desc = of_device_get_match_data(>dev);
+   if (!desc)
+   return -EINVAL;
+
if (!qcom_scm_is_available())
return -EPROBE_DEFER;
 
-   if (!qcom_scm_pas_supported(ADSP_PAS_ID)) {
-   dev_err(>dev, "PAS is not available for ADSP\n");
+   if (!qcom_scm_pas_supported(desc->pas_id)) {
+   dev_err(>dev, "PAS is not available for subsystem\n");
return -ENXIO;
}
 
rproc = rproc_alloc(>dev, pdev->name, _ops,
-   ADSP_FIRMWARE_NAME, sizeof(*adsp));
+   desc->firmware_name, sizeof(*adsp));
if (!rproc) {
dev_err(>dev, "unable to allocate remoteproc\n");
return -ENOMEM;
@@ -344,6 +356,8 @@ static int adsp_probe(struct platform_device *pdev)
if (ret)
goto free_rproc;
 
+   adsp->pas_id = desc->pas_id;
+   adsp->crash_reason_smem = desc->crash_reason_smem;
ret = adsp_init_clock(adsp);
if (ret)
goto free_rproc;
@@ -407,9 +421,14 @@ static int adsp_remove(struct platform_device *pdev)
return 0;
 }
 

Re: [PATCH 0/8] Add STM32F469 pinctrl and fix issues in STM32 pinctrl

[Alexandre Torgue]

Hi,

On 01/27/2017 05:15 PM, Alexandre TORGUE wrote:

This series adds support of a dedicated driver for STM32F469 MCU pinctroller.
This add generates some changes inside STM32 pinctrl driver and inside STM32
device tree.

Changes in STM32 pinctrl driver:
---

- Add STM32F469 driver.

- Change STM32 pinctrl core in order to use "gpio-ranges" devicetree 
definitions.
  Indeed, on STM32F469 there an hole in BANK J. We need to declare a 
gpio-ranges
  in gpioj controller node to handle this hole.

Changes in STM32 device tree:

I propose a new architecture (a new file split) for pinmux definition:

- Create a common stm32f4-pinctrl.dtsi for pinmuxing definitions
  which are common between STM32F429 and STM32F469 MCU.

- Create dedicated stm32fxxx-pinctrl.dtsi file for each MCU
  (stm32f429-pinctrl.dtsi and stm32f469-pinctrl.dtsi) each one will
  include stm32f4-pinctrl.dtsi. All differences (pinmuxing or GPIO
  bank holes) will be put inside the dedicated files.

This series fix a locking issue when a gpio is used as IRQ.

Regards
Alex

Alexandre TORGUE (8):
  pinctrl: stm32: fix bad location of gpiochip_lock_as_irq
  pinctrl: stm32: use gpio-ranges to declare bank range


I just see typo issue in patch 1&2. I will send a V2 when more review 
will be done.


Regards
Alex



  Documentation: dt: Add bindings for STM32 pinctrl
  includes: dt-bindings: Rename STM32F429 pinctrl DT bindings
  pinctrl: stm32: Add STM32F469 MCU support
  Documentation: dt: Add new compatible to STM32 pinctrl driver bindings
  ARM: Kconfig: Introduce MACH_STM32F469 flag
  ARM: dts: stm32: create dedicated files for pinctrl definitions

 .../bindings/pinctrl/st,stm32-pinctrl.txt  |   57 +-
 arch/arm/Kconfig   |5 +
 arch/arm/boot/dts/stm32429i-eval.dts   |1 +
 arch/arm/boot/dts/stm32f4-pinctrl.dtsi |  196 +++
 arch/arm/boot/dts/stm32f429-disco.dts  |1 +
 arch/arm/boot/dts/stm32f429-pinctrl.dtsi   |  106 ++
 arch/arm/boot/dts/stm32f429.dtsi   |  153 --
 arch/arm/boot/dts/stm32f469-disco.dts  |1 +
 arch/arm/boot/dts/stm32f469-pinctrl.dtsi   |  107 ++
 drivers/pinctrl/stm32/Kconfig  |6 +
 drivers/pinctrl/stm32/Makefile |1 +
 drivers/pinctrl/stm32/pinctrl-stm32.c  |  129 +-
 drivers/pinctrl/stm32/pinctrl-stm32f469.c  | 1574 
 include/dt-bindings/pinctrl/stm32f4-pinfunc.h  | 1302 
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h| 1239 ---
 15 files changed, 3414 insertions(+), 1464 deletions(-)
 create mode 100644 arch/arm/boot/dts/stm32f4-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32f429-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32f469-pinctrl.dtsi
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f469.c
 create mode 100644 include/dt-bindings/pinctrl/stm32f4-pinfunc.h
 delete mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

[PATCH v3 1/4] remoteproc: qcom: Compatible string based resource initialization.

[Avaneesh Kumar Dwivedi]

This patch initialize certain driver related data based on compatible
string. This enable driver to handle more than one similar device in
by differentiating in probe their private data.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 drivers/remoteproc/qcom_adsp_pil.c | 47 ++
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index 43a4ed2..f674301 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -32,9 +32,12 @@
 #include "qcom_mdt_loader.h"
 #include "remoteproc_internal.h"
 
-#define ADSP_CRASH_REASON_SMEM 423
-#define ADSP_FIRMWARE_NAME "adsp.mdt"
-#define ADSP_PAS_ID1
+struct adsp_data {
+   int crash_reason_smem;
+   const char *firmware_name;
+   int pas_id;
+};
+
 
 struct qcom_adsp {
struct device *dev;
@@ -53,6 +56,9 @@ struct qcom_adsp {
 
struct regulator *cx_supply;
 
+   int pas_id;
+   int crash_reason_smem;
+
struct completion start_done;
struct completion stop_done;
 
@@ -70,7 +76,7 @@ static int adsp_load(struct rproc *rproc, const struct 
firmware *fw)
bool relocate;
int ret;
 
-   ret = qcom_scm_pas_init_image(ADSP_PAS_ID, fw->data, fw->size);
+   ret = qcom_scm_pas_init_image(adsp->pas_id, fw->data, fw->size);
if (ret) {
dev_err(>dev, "invalid firmware metadata\n");
return ret;
@@ -85,7 +91,8 @@ static int adsp_load(struct rproc *rproc, const struct 
firmware *fw)
if (relocate) {
adsp->mem_reloc = fw_addr;
 
-   ret = qcom_scm_pas_mem_setup(ADSP_PAS_ID, adsp->mem_phys, 
fw_size);
+   ret = qcom_scm_pas_mem_setup(adsp->pas_id,
+   adsp->mem_phys, fw_size);
if (ret) {
dev_err(>dev, "unable to setup memory for 
image\n");
return ret;
@@ -113,7 +120,7 @@ static int adsp_start(struct rproc *rproc)
if (ret)
goto disable_clocks;
 
-   ret = qcom_scm_pas_auth_and_reset(ADSP_PAS_ID);
+   ret = qcom_scm_pas_auth_and_reset(adsp->pas_id);
if (ret) {
dev_err(adsp->dev,
"failed to authenticate image and release reset\n");
@@ -124,7 +131,7 @@ static int adsp_start(struct rproc *rproc)
  msecs_to_jiffies(5000));
if (!ret) {
dev_err(adsp->dev, "start timed out\n");
-   qcom_scm_pas_shutdown(ADSP_PAS_ID);
+   qcom_scm_pas_shutdown(adsp->pas_id);
ret = -ETIMEDOUT;
goto disable_regulators;
}
@@ -157,7 +164,7 @@ static int adsp_stop(struct rproc *rproc)
BIT(adsp->stop_bit),
0);
 
-   ret = qcom_scm_pas_shutdown(ADSP_PAS_ID);
+   ret = qcom_scm_pas_shutdown(adsp->pas_id);
if (ret)
dev_err(adsp->dev, "failed to shutdown: %d\n", ret);
 
@@ -197,7 +204,7 @@ static irqreturn_t adsp_fatal_interrupt(int irq, void *dev)
size_t len;
char *msg;
 
-   msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, ADSP_CRASH_REASON_SMEM, );
+   msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, adsp->crash_reason_smem, );
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(adsp->dev, "fatal error received: %s\n", msg);
 
@@ -311,20 +318,25 @@ static int adsp_alloc_memory_region(struct qcom_adsp 
*adsp)
 
 static int adsp_probe(struct platform_device *pdev)
 {
+   const struct adsp_data *desc;
struct qcom_adsp *adsp;
struct rproc *rproc;
int ret;
 
+   desc = of_device_get_match_data(>dev);
+   if (!desc)
+   return -EINVAL;
+
if (!qcom_scm_is_available())
return -EPROBE_DEFER;
 
-   if (!qcom_scm_pas_supported(ADSP_PAS_ID)) {
-   dev_err(>dev, "PAS is not available for ADSP\n");
+   if (!qcom_scm_pas_supported(desc->pas_id)) {
+   dev_err(>dev, "PAS is not available for subsystem\n");
return -ENXIO;
}
 
rproc = rproc_alloc(>dev, pdev->name, _ops,
-   ADSP_FIRMWARE_NAME, sizeof(*adsp));
+   desc->firmware_name, sizeof(*adsp));
if (!rproc) {
dev_err(>dev, "unable to allocate remoteproc\n");
return -ENOMEM;
@@ -344,6 +356,8 @@ static int adsp_probe(struct platform_device *pdev)
if (ret)
goto free_rproc;
 
+   adsp->pas_id = desc->pas_id;
+   adsp->crash_reason_smem = desc->crash_reason_smem;
ret = adsp_init_clock(adsp);
if (ret)
goto free_rproc;
@@ -407,9 +421,14 @@ static int adsp_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct 

[PATCH v3 3/4] remoteproc: qcom: Add SLPI rproc support to load and boot slpi proc.

[Avaneesh Kumar Dwivedi]

This patch add slpi remoteproc support in existing adsp rproc driver.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 .../devicetree/bindings/remoteproc/qcom,adsp.txt   | 28 ++
 drivers/remoteproc/qcom_adsp_pil.c | 10 +++-
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
index b85885a..1fb63b8 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -9,6 +9,7 @@ on the Qualcomm ADSP Hexagon core.
Definition: must be one of:
"qcom,msm8974-adsp-pil"
"qcom,msm8996-adsp-pil"
+   "qcom,msm8996-slpi-pil"
 
 - interrupts-extended:
Usage: required
@@ -96,3 +97,30 @@ ADSP, as it is found on MSM8974 boards.
qcom,smd-edge = <1>;
};
};
+
+The following example describes the resources needed to boot control the
+SLPI, as it is found on MSM8996 boards.
+
+   slpi {
+   compatible = "qcom,msm8996-slpi-pil";
+   interrupts-extended = < 0 390 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+   "fatal",
+   "ready",
+   "handover",
+   "stop-ack";
+
+   clocks = < MSM8996_RPM_SMD_XO_CLK_SRC>,
+   < MSM8996_RPM_SMD_AGGR2_NOC_CLK>;
+   clock-names = "xo",
+   "aggre2";
+   vdd_cx-supply = <_l26_corner>;
+   vdd_px-supply = <_lvs2>;
+   memory-region = <_region>;
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+};
diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index 58cc46d..e6bb1f0 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -1,5 +1,5 @@
 /*
- * Qualcomm ADSP Peripheral Image Loader for MSM8974 and MSM8996
+ * Qualcomm ADSP/SLPI Peripheral Image Loader for MSM8974 and MSM8996
  *
  * Copyright (C) 2016 Linaro Ltd
  * Copyright (C) 2014 Sony Mobile Communications AB
@@ -455,9 +455,17 @@ static int adsp_remove(struct platform_device *pdev)
.pas_id = 1,
.has_aggre2_clk = 0,
 };
+
+static const struct adsp_data slpi_resource_init = {
+   .crash_reason_smem = 424,
+   .firmware_name = "slpi.mdt",
+   .pas_id = 12,
+   .has_aggre2_clk = 1,
+};
 static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,msm8974-adsp-pil", .data = _resource_init},
{ .compatible = "qcom,msm8996-adsp-pil", .data = _resource_init},
+   { .compatible = "qcom,msm8996-slpi-pil", .data = _resource_init},
{ },
 };
 MODULE_DEVICE_TABLE(of, adsp_of_match);
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH v3 0/4]remoteproc: qcom: Add support for Qualcomm low pass sensor peripheral loader.

[Avaneesh Kumar Dwivedi]

This patchset has changed from last patchset in below respect
1- Generic regulator and clock resource handling is dropped.
2- Introdused additional px supply and aggre2 clock initialization.
3- Add SLPI boot support in existing ADSP driver.
4- Address other minor comments on patchset 2.

Avaneesh Kumar Dwivedi (4):
  remoteproc: qcom: Compatible string based resource initialization.
  remoteproc: qcom: Add additional agree2_clk and px regulator resource.
  remoteproc: qcom: Add SLPI rproc support to load and boot slpi proc.
  arm64: dts: msm8996: Add SLPI SMP2P dt node.

 .../devicetree/bindings/remoteproc/qcom,adsp.txt   |  28 ++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  |  24 +
 drivers/remoteproc/qcom_adsp_pil.c | 100 -
 3 files changed, 130 insertions(+), 22 deletions(-)

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH v3 3/4] remoteproc: qcom: Add SLPI rproc support to load and boot slpi proc.

[Avaneesh Kumar Dwivedi]

This patch add slpi remoteproc support in existing adsp rproc driver.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 .../devicetree/bindings/remoteproc/qcom,adsp.txt   | 28 ++
 drivers/remoteproc/qcom_adsp_pil.c | 10 +++-
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
index b85885a..1fb63b8 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -9,6 +9,7 @@ on the Qualcomm ADSP Hexagon core.
Definition: must be one of:
"qcom,msm8974-adsp-pil"
"qcom,msm8996-adsp-pil"
+   "qcom,msm8996-slpi-pil"
 
 - interrupts-extended:
Usage: required
@@ -96,3 +97,30 @@ ADSP, as it is found on MSM8974 boards.
qcom,smd-edge = <1>;
};
};
+
+The following example describes the resources needed to boot control the
+SLPI, as it is found on MSM8996 boards.
+
+   slpi {
+   compatible = "qcom,msm8996-slpi-pil";
+   interrupts-extended = < 0 390 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+   "fatal",
+   "ready",
+   "handover",
+   "stop-ack";
+
+   clocks = < MSM8996_RPM_SMD_XO_CLK_SRC>,
+   < MSM8996_RPM_SMD_AGGR2_NOC_CLK>;
+   clock-names = "xo",
+   "aggre2";
+   vdd_cx-supply = <_l26_corner>;
+   vdd_px-supply = <_lvs2>;
+   memory-region = <_region>;
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+};
diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index 58cc46d..e6bb1f0 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -1,5 +1,5 @@
 /*
- * Qualcomm ADSP Peripheral Image Loader for MSM8974 and MSM8996
+ * Qualcomm ADSP/SLPI Peripheral Image Loader for MSM8974 and MSM8996
  *
  * Copyright (C) 2016 Linaro Ltd
  * Copyright (C) 2014 Sony Mobile Communications AB
@@ -455,9 +455,17 @@ static int adsp_remove(struct platform_device *pdev)
.pas_id = 1,
.has_aggre2_clk = 0,
 };
+
+static const struct adsp_data slpi_resource_init = {
+   .crash_reason_smem = 424,
+   .firmware_name = "slpi.mdt",
+   .pas_id = 12,
+   .has_aggre2_clk = 1,
+};
 static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,msm8974-adsp-pil", .data = _resource_init},
{ .compatible = "qcom,msm8996-adsp-pil", .data = _resource_init},
+   { .compatible = "qcom,msm8996-slpi-pil", .data = _resource_init},
{ },
 };
 MODULE_DEVICE_TABLE(of, adsp_of_match);
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH v3 0/4]remoteproc: qcom: Add support for Qualcomm low pass sensor peripheral loader.

[Avaneesh Kumar Dwivedi]

This patchset has changed from last patchset in below respect
1- Generic regulator and clock resource handling is dropped.
2- Introdused additional px supply and aggre2 clock initialization.
3- Add SLPI boot support in existing ADSP driver.
4- Address other minor comments on patchset 2.

Avaneesh Kumar Dwivedi (4):
  remoteproc: qcom: Compatible string based resource initialization.
  remoteproc: qcom: Add additional agree2_clk and px regulator resource.
  remoteproc: qcom: Add SLPI rproc support to load and boot slpi proc.
  arm64: dts: msm8996: Add SLPI SMP2P dt node.

 .../devicetree/bindings/remoteproc/qcom,adsp.txt   |  28 ++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  |  24 +
 drivers/remoteproc/qcom_adsp_pil.c | 100 -
 3 files changed, 130 insertions(+), 22 deletions(-)

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

[Avaneesh Kumar Dwivedi]

This patch add additional clock and regulator resource which are
initialized based on compatible and has no impact on existing driver
working. This resourse addition enable the existing driver to handle.
low pass sensor processor device also.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 drivers/remoteproc/qcom_adsp_pil.c | 43 +++---
 1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index f674301..58cc46d 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -36,6 +36,7 @@ struct adsp_data {
int crash_reason_smem;
const char *firmware_name;
int pas_id;
+   bool has_aggre2_clk;
 };
 
 
@@ -53,11 +54,13 @@ struct qcom_adsp {
unsigned stop_bit;
 
struct clk *xo;
-
+   struct clk *aggre2_clk;
struct regulator *cx_supply;
+   struct regulator *px_supply;
 
int pas_id;
int crash_reason_smem;
+   bool has_aggre2_clk;
 
struct completion start_done;
struct completion stop_done;
@@ -115,16 +118,22 @@ static int adsp_start(struct rproc *rproc)
ret = clk_prepare_enable(adsp->xo);
if (ret)
return ret;
+   ret = clk_prepare_enable(adsp->aggre2_clk);
+   if (ret)
+   goto disable_xo_clk;
 
ret = regulator_enable(adsp->cx_supply);
if (ret)
-   goto disable_clocks;
+   goto disable_aggre2_clk;
+   ret = regulator_enable(adsp->px_supply);
+   if (ret)
+   goto disable_cx_supply;
 
ret = qcom_scm_pas_auth_and_reset(adsp->pas_id);
if (ret) {
dev_err(adsp->dev,
"failed to authenticate image and release reset\n");
-   goto disable_regulators;
+   goto disable_px_supply;
}
 
ret = wait_for_completion_timeout(>start_done,
@@ -133,14 +142,18 @@ static int adsp_start(struct rproc *rproc)
dev_err(adsp->dev, "start timed out\n");
qcom_scm_pas_shutdown(adsp->pas_id);
ret = -ETIMEDOUT;
-   goto disable_regulators;
+   goto disable_px_supply;
}
 
ret = 0;
 
-disable_regulators:
+disable_px_supply:
+   regulator_disable(adsp->px_supply);
+disable_cx_supply:
regulator_disable(adsp->cx_supply);
-disable_clocks:
+disable_aggre2_clk:
+   clk_disable_unprepare(adsp->aggre2_clk);
+disable_xo_clk:
clk_disable_unprepare(adsp->xo);
 
return ret;
@@ -251,17 +264,31 @@ static int adsp_init_clock(struct qcom_adsp *adsp)
return ret;
}
 
+   if (adsp->has_aggre2_clk) {
+   adsp->aggre2_clk = devm_clk_get(adsp->dev, "aggre2");
+   if (IS_ERR(adsp->aggre2_clk)) {
+   ret = PTR_ERR(adsp->aggre2_clk);
+   if (ret != -EPROBE_DEFER)
+   dev_err(adsp->dev,
+   "failed to get aggre2 clock");
+   return ret;
+   }
+   }
+
return 0;
 }
 
 static int adsp_init_regulator(struct qcom_adsp *adsp)
 {
-   adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
+   adsp->cx_supply = devm_regulator_get(adsp->dev, "vdd_cx");
if (IS_ERR(adsp->cx_supply))
return PTR_ERR(adsp->cx_supply);
 
regulator_set_load(adsp->cx_supply, 10);
 
+   adsp->px_supply = devm_regulator_get(adsp->dev, "vdd_px");
+   if (IS_ERR(adsp->px_supply))
+   return PTR_ERR(adsp->px_supply);
return 0;
 }
 
@@ -358,6 +385,7 @@ static int adsp_probe(struct platform_device *pdev)
 
adsp->pas_id = desc->pas_id;
adsp->crash_reason_smem = desc->crash_reason_smem;
+   adsp->has_aggre2_clk = desc->has_aggre2_clk;
ret = adsp_init_clock(adsp);
if (ret)
goto free_rproc;
@@ -425,6 +453,7 @@ static int adsp_remove(struct platform_device *pdev)
.crash_reason_smem = 423,
.firmware_name = "adsp.mdt",
.pas_id = 1,
+   .has_aggre2_clk = 0,
 };
 static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,msm8974-adsp-pil", .data = _resource_init},
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

[Avaneesh Kumar Dwivedi]

This patch add additional clock and regulator resource which are
initialized based on compatible and has no impact on existing driver
working. This resourse addition enable the existing driver to handle.
low pass sensor processor device also.

Signed-off-by: Avaneesh Kumar Dwivedi 
---
 drivers/remoteproc/qcom_adsp_pil.c | 43 +++---
 1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c
index f674301..58cc46d 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -36,6 +36,7 @@ struct adsp_data {
int crash_reason_smem;
const char *firmware_name;
int pas_id;
+   bool has_aggre2_clk;
 };
 
 
@@ -53,11 +54,13 @@ struct qcom_adsp {
unsigned stop_bit;
 
struct clk *xo;
-
+   struct clk *aggre2_clk;
struct regulator *cx_supply;
+   struct regulator *px_supply;
 
int pas_id;
int crash_reason_smem;
+   bool has_aggre2_clk;
 
struct completion start_done;
struct completion stop_done;
@@ -115,16 +118,22 @@ static int adsp_start(struct rproc *rproc)
ret = clk_prepare_enable(adsp->xo);
if (ret)
return ret;
+   ret = clk_prepare_enable(adsp->aggre2_clk);
+   if (ret)
+   goto disable_xo_clk;
 
ret = regulator_enable(adsp->cx_supply);
if (ret)
-   goto disable_clocks;
+   goto disable_aggre2_clk;
+   ret = regulator_enable(adsp->px_supply);
+   if (ret)
+   goto disable_cx_supply;
 
ret = qcom_scm_pas_auth_and_reset(adsp->pas_id);
if (ret) {
dev_err(adsp->dev,
"failed to authenticate image and release reset\n");
-   goto disable_regulators;
+   goto disable_px_supply;
}
 
ret = wait_for_completion_timeout(>start_done,
@@ -133,14 +142,18 @@ static int adsp_start(struct rproc *rproc)
dev_err(adsp->dev, "start timed out\n");
qcom_scm_pas_shutdown(adsp->pas_id);
ret = -ETIMEDOUT;
-   goto disable_regulators;
+   goto disable_px_supply;
}
 
ret = 0;
 
-disable_regulators:
+disable_px_supply:
+   regulator_disable(adsp->px_supply);
+disable_cx_supply:
regulator_disable(adsp->cx_supply);
-disable_clocks:
+disable_aggre2_clk:
+   clk_disable_unprepare(adsp->aggre2_clk);
+disable_xo_clk:
clk_disable_unprepare(adsp->xo);
 
return ret;
@@ -251,17 +264,31 @@ static int adsp_init_clock(struct qcom_adsp *adsp)
return ret;
}
 
+   if (adsp->has_aggre2_clk) {
+   adsp->aggre2_clk = devm_clk_get(adsp->dev, "aggre2");
+   if (IS_ERR(adsp->aggre2_clk)) {
+   ret = PTR_ERR(adsp->aggre2_clk);
+   if (ret != -EPROBE_DEFER)
+   dev_err(adsp->dev,
+   "failed to get aggre2 clock");
+   return ret;
+   }
+   }
+
return 0;
 }
 
 static int adsp_init_regulator(struct qcom_adsp *adsp)
 {
-   adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
+   adsp->cx_supply = devm_regulator_get(adsp->dev, "vdd_cx");
if (IS_ERR(adsp->cx_supply))
return PTR_ERR(adsp->cx_supply);
 
regulator_set_load(adsp->cx_supply, 10);
 
+   adsp->px_supply = devm_regulator_get(adsp->dev, "vdd_px");
+   if (IS_ERR(adsp->px_supply))
+   return PTR_ERR(adsp->px_supply);
return 0;
 }
 
@@ -358,6 +385,7 @@ static int adsp_probe(struct platform_device *pdev)
 
adsp->pas_id = desc->pas_id;
adsp->crash_reason_smem = desc->crash_reason_smem;
+   adsp->has_aggre2_clk = desc->has_aggre2_clk;
ret = adsp_init_clock(adsp);
if (ret)
goto free_rproc;
@@ -425,6 +453,7 @@ static int adsp_remove(struct platform_device *pdev)
.crash_reason_smem = 423,
.firmware_name = "adsp.mdt",
.pas_id = 1,
+   .has_aggre2_clk = 0,
 };
 static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,msm8974-adsp-pil", .data = _resource_init},
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

[Frederic Weisbecker]

On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote:
> > Now lets admit one drawback: s390 and powerpc with
> > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion
> > on cputime accounting path. But this should be leveraged by the recent
> > changes which delay the cputime accounting to tick and context switch. 
> 
> I think it would be worth to mention that there are other drawbacks on
> 32bit architectures that use cputime-jiffies currently, like:
> - cache utilization will be worse

Due to utime and stime becoming 64 bits? Yeah indeed.

> - conversion cputime_to_jiffies() and cputime_to_clock_t() (with HZ == 
> USER_HS)
>   will no longer be an no-op

Yes probably some cputime_to_jiffies() have been replaced with 
nsecs_to_jiffies().
In turn many cputime_to_nsecs() are now no-op.

Now concerning cputime_to_clock_t(), it seems that USER_HZ=100 most of the 
time. This
value seems to be seldom used for HZ on distros in general.

> - to keep values consistent will need to add protection of u64 store/load,
>   which will create additional performance costs

Yes but note these issues were already there before this patchset.
Especially for kcpustat. And utime/stime also have these issues under 
CONFIG_NO_HZ_FULL.

Now this patchset extends the problem for utime/stime to all configs. That's 
certainly
one more reason to fix it. But that's outside the scope of this patchset.

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

[Frederic Weisbecker]

On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote:
> > Now lets admit one drawback: s390 and powerpc with
> > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion
> > on cputime accounting path. But this should be leveraged by the recent
> > changes which delay the cputime accounting to tick and context switch. 
> 
> I think it would be worth to mention that there are other drawbacks on
> 32bit architectures that use cputime-jiffies currently, like:
> - cache utilization will be worse

Due to utime and stime becoming 64 bits? Yeah indeed.

> - conversion cputime_to_jiffies() and cputime_to_clock_t() (with HZ == 
> USER_HS)
>   will no longer be an no-op

Yes probably some cputime_to_jiffies() have been replaced with 
nsecs_to_jiffies().
In turn many cputime_to_nsecs() are now no-op.

Now concerning cputime_to_clock_t(), it seems that USER_HZ=100 most of the 
time. This
value seems to be seldom used for HZ on distros in general.

> - to keep values consistent will need to add protection of u64 store/load,
>   which will create additional performance costs

Yes but note these issues were already there before this patchset.
Especially for kcpustat. And utime/stime also have these issues under 
CONFIG_NO_HZ_FULL.

Now this patchset extends the problem for utime/stime to all configs. That's 
certainly
one more reason to fix it. But that's outside the scope of this patchset.

Re: workqueue lockup due to process_unsol_events stuck in azx_rirb_get_response

[Vlastimil Babka]

On 01/25/2017 06:06 PM, Takashi Iwai wrote:

The code path is related with the runtime PM, so it's likely depending
on the device state, e.g. long-time pause or such.  I don't think Win
10 plays a role, but who knows.

In anyway, let me know if this helps.  Basically I can merge it even
for now, as the fix shouldn't give a regression.  But of course it'd
be better to have a test result :)


OK so unfortunately it now happened with the patch.

Re: workqueue lockup due to process_unsol_events stuck in azx_rirb_get_response

[Vlastimil Babka]

On 01/25/2017 06:06 PM, Takashi Iwai wrote:

The code path is related with the runtime PM, so it's likely depending
on the device state, e.g. long-time pause or such.  I don't think Win
10 plays a role, but who knows.

In anyway, let me know if this helps.  Basically I can merge it even
for now, as the fix shouldn't give a regression.  But of course it'd
be better to have a test result :)


OK so unfortunately it now happened with the patch.

Re: [RFC v2 06/10] KVM: arm/arm64: Update the physical timer interrupt level

[Christoffer Dall]

On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim  
> wrote:
> > Now that we maintain the EL1 physical timer register states of VMs,
> > update the physical timer interrupt level along with the virtual one.
> >
> > Note that the emulated EL1 physical timer is not mapped to any hardware
> > timer, so we call a proper vgic function.
> >
> > Signed-off-by: Jintack Lim 
> > ---
> >  virt/kvm/arm/arch_timer.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 0f6e935..3b6bd50 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -180,6 +180,21 @@ static void kvm_timer_update_mapped_irq(struct 
> > kvm_vcpu *vcpu, bool new_level,
> > WARN_ON(ret);
> >  }
> >  
> > +static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> > +struct arch_timer_context *timer)
> > +{
> > +   int ret;
> > +
> > +   BUG_ON(!vgic_initialized(vcpu->kvm));
> 
> Although I've added my fair share of BUG_ON() in the code base, I've
> since reconsidered my position. If we get in a situation where the vgic
> is not initialized, maybe it would be better to just WARN_ON and return
> early rather than killing the whole box. Thoughts?
> 

The distinction to me is whether this will cause fatal crashes or
exploits down the road if we're working on uninitialized data.  If all
that can happen if the vgic is not initialized, is that the guest
doesn't see interrupts, for example, then a WARN_ON is appropriate.

Which is the case here?

That being said, do we need this at all?  This is in the critial path
and is actually measurable (I know this from my work on the other timer
series), so it's better to get rid of it if we can.  Can we simply
convince ourselves this will never happen, and is the code ever likely
to change so that it gets called with the vgic disabled later?


Thanks,
-Christoffer

Re: [RFC v2 06/10] KVM: arm/arm64: Update the physical timer interrupt level

[Christoffer Dall]

On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim  
> wrote:
> > Now that we maintain the EL1 physical timer register states of VMs,
> > update the physical timer interrupt level along with the virtual one.
> >
> > Note that the emulated EL1 physical timer is not mapped to any hardware
> > timer, so we call a proper vgic function.
> >
> > Signed-off-by: Jintack Lim 
> > ---
> >  virt/kvm/arm/arch_timer.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 0f6e935..3b6bd50 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -180,6 +180,21 @@ static void kvm_timer_update_mapped_irq(struct 
> > kvm_vcpu *vcpu, bool new_level,
> > WARN_ON(ret);
> >  }
> >  
> > +static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> > +struct arch_timer_context *timer)
> > +{
> > +   int ret;
> > +
> > +   BUG_ON(!vgic_initialized(vcpu->kvm));
> 
> Although I've added my fair share of BUG_ON() in the code base, I've
> since reconsidered my position. If we get in a situation where the vgic
> is not initialized, maybe it would be better to just WARN_ON and return
> early rather than killing the whole box. Thoughts?
> 

The distinction to me is whether this will cause fatal crashes or
exploits down the road if we're working on uninitialized data.  If all
that can happen if the vgic is not initialized, is that the guest
doesn't see interrupts, for example, then a WARN_ON is appropriate.

Which is the case here?

That being said, do we need this at all?  This is in the critial path
and is actually measurable (I know this from my work on the other timer
series), so it's better to get rid of it if we can.  Can we simply
convince ourselves this will never happen, and is the code ever likely
to change so that it gets called with the vgic disabled later?


Thanks,
-Christoffer

Re: [PATCH v4 1/2] mm/migration: make isolate_movable_page always defined

[Yisheng Xie]

Hi， Michal，
Sorry for late reply.

On 01/26/2017 05:18 PM, Michal Hocko wrote:
> On Wed 25-01-17 23:05:37, ys...@foxmail.com wrote:
>> From: Yisheng Xie 
>>
>> Define isolate_movable_page as a static inline function when
>> CONFIG_MIGRATION is not enable. It should return false
>> here which means failed to isolate movable pages.
>>
>> This patch do not have any functional change but prepare for
>> later patch.
> I think it would make more sense to make isolate_movable_page return int
> and have the same semantic as __isolate_lru_page. This would be a better
> preparatory patch for the later work.
Yes, I think you are right, it is better to make isolate_movable_page return int
just as what isolate_lru_page do, to make a better code style.

It seems Andrew had already merged the fixed patch from Arnd Bergmann,
Maybe I can rewrite it in a later patch if it is suitable :)

Re: [PATCH v4 1/2] mm/migration: make isolate_movable_page always defined

[Yisheng Xie]

Hi， Michal，
Sorry for late reply.

On 01/26/2017 05:18 PM, Michal Hocko wrote:
> On Wed 25-01-17 23:05:37, ys...@foxmail.com wrote:
>> From: Yisheng Xie 
>>
>> Define isolate_movable_page as a static inline function when
>> CONFIG_MIGRATION is not enable. It should return false
>> here which means failed to isolate movable pages.
>>
>> This patch do not have any functional change but prepare for
>> later patch.
> I think it would make more sense to make isolate_movable_page return int
> and have the same semantic as __isolate_lru_page. This would be a better
> preparatory patch for the later work.
Yes, I think you are right, it is better to make isolate_movable_page return int
just as what isolate_lru_page do, to make a better code style.

It seems Andrew had already merged the fixed patch from Arnd Bergmann,
Maybe I can rewrite it in a later patch if it is suitable :)

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> > This header file is exported, thus move it to uapi.
> 
> Why? Why is this damn thing exported in the first place?
> 
> The moment we decide to change an MSR name or even remove it from that
> file, we break userspace. And what for, because userspace is using some
> arbitrary header file which was meant to be for the kernel solely.
> 
> NAKed-by: Borislav Petkov 

Here on my Fedora system:

$ less /usr/include/asm/msr-index.h
#ifndef _ASM_X86_MSR_INDEX_H
#define _ASM_X86_MSR_INDEX_H

/* CPU model specific register (MSR) numbers */

/* x86-64 specific MSRs */
#define MSR_EFER0xc080 /* extended feature register */
#define MSR_STAR0xc081 /* legacy mode SYSCALL target */
#define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
...

Like it or not, it is _already_ exported to userspace, so it forms
part of the user ABI.  You can try to remove it from userspace view,
but if anyone has already started to use it, removing it will already
cause a userspace regression.

So, I don't think we have any grounds to NAK these patches on the
basis of "we don't want this to be visible to userspace because it
may cause a userspace regression."  Removing it from userspace view
is likely to cause a userspace regression.

This patch just makes sure that such a regression doesn't happen when
kbuild stops exporting files in _non_-uapi directories.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 05:52:45PM +0100, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 03:58:37PM +0100, Nicolas Dichtel wrote:
> > This header file is exported, thus move it to uapi.
> 
> Why? Why is this damn thing exported in the first place?
> 
> The moment we decide to change an MSR name or even remove it from that
> file, we break userspace. And what for, because userspace is using some
> arbitrary header file which was meant to be for the kernel solely.
> 
> NAKed-by: Borislav Petkov 

Here on my Fedora system:

$ less /usr/include/asm/msr-index.h
#ifndef _ASM_X86_MSR_INDEX_H
#define _ASM_X86_MSR_INDEX_H

/* CPU model specific register (MSR) numbers */

/* x86-64 specific MSRs */
#define MSR_EFER0xc080 /* extended feature register */
#define MSR_STAR0xc081 /* legacy mode SYSCALL target */
#define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
...

Like it or not, it is _already_ exported to userspace, so it forms
part of the user ABI.  You can try to remove it from userspace view,
but if anyone has already started to use it, removing it will already
cause a userspace regression.

So, I don't think we have any grounds to NAK these patches on the
basis of "we don't want this to be visible to userspace because it
may cause a userspace regression."  Removing it from userspace view
is likely to cause a userspace regression.

This patch just makes sure that such a regression doesn't happen when
kbuild stops exporting files in _non_-uapi directories.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 10/18] ARM64: dts: meson-gxbb: Reorder nodes

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 10:52:08AM -0600, Rob Herring wrote:
> On Fri, Jan 20, 2017 at 11:21:10PM +0100, Andreas Färber wrote:
> > Sort nodes referenced by label alphabetically.
> 
> Seems to be pointless churn.

Depends - if, as the author of a dts file, I order the nodes
alphabetically, and then someone comes along and adds a new node
non-alphabetically, meanwhile someone else also adds a node
elsewhere in the file which conflicts, git will silently merge the
changes without complaint.

Having an alphabetical sorting order means that (a) conflicting
changes are more likely to be highlighted, and (b) non-conflicting
changes are less likely to cause merge issues.

I've noticed exactly this with clearfog when merging my tree with
arm-soc.  I have a version of the DSA patch, meanwhile the mvebu
people merged the DSA patch.  Somehow, the order of nodes in my
file are alphabetical, the order in their file has the pinctrl and
mdio nodes swapped, which results in totally unnecessary merge
conflicts when I try merging the two trees.

It's more, unnecessary work.

So, I'm going to be submitting a patch to fix the mis-ordered nodes
in the clearfog dts file today to avoid having to resolve this each
time I rebuild my nightly build tree.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 10/18] ARM64: dts: meson-gxbb: Reorder nodes

[Russell King - ARM Linux]

On Mon, Jan 23, 2017 at 10:52:08AM -0600, Rob Herring wrote:
> On Fri, Jan 20, 2017 at 11:21:10PM +0100, Andreas Färber wrote:
> > Sort nodes referenced by label alphabetically.
> 
> Seems to be pointless churn.

Depends - if, as the author of a dts file, I order the nodes
alphabetically, and then someone comes along and adds a new node
non-alphabetically, meanwhile someone else also adds a node
elsewhere in the file which conflicts, git will silently merge the
changes without complaint.

Having an alphabetical sorting order means that (a) conflicting
changes are more likely to be highlighted, and (b) non-conflicting
changes are less likely to cause merge issues.

I've noticed exactly this with clearfog when merging my tree with
arm-soc.  I have a version of the DSA patch, meanwhile the mvebu
people merged the DSA patch.  Somehow, the order of nodes in my
file are alphabetical, the order in their file has the pinctrl and
mdio nodes swapped, which results in totally unnecessary merge
conflicts when I try merging the two trees.

It's more, unnecessary work.

So, I'm going to be submitting a patch to fix the mis-ordered nodes
in the clearfog dts file today to avoid having to resolve this each
time I rebuild my nightly build tree.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [RFC v2 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer

[Christoffer Dall]

On Sun, Jan 29, 2017 at 12:07:48PM +, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:55 AM, Jintack Lim  
> wrote:
> > Initialize the emulated EL1 physical timer with the default irq number.
> >
> > Signed-off-by: Jintack Lim 
> > ---
> >  arch/arm/kvm/reset.c | 9 -
> >  arch/arm64/kvm/reset.c   | 9 -
> >  include/kvm/arm_arch_timer.h | 3 ++-
> >  virt/kvm/arm/arch_timer.c| 9 +++--
> >  4 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> > index 4b5e802..1da8b2d 100644
> > --- a/arch/arm/kvm/reset.c
> > +++ b/arch/arm/kvm/reset.c
> > @@ -37,6 +37,11 @@
> > .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
> >  };
> >  
> > +static const struct kvm_irq_level cortexa_ptimer_irq = {
> > +   { .irq = 30 },
> > +   .level = 1,
> > +};
> 
> At some point, we'll have to make that discoverable/configurable. Maybe
> the time for a discoverable arch timer has come (see below).
> 
> > +
> >  static const struct kvm_irq_level cortexa_vtimer_irq = {
> > { .irq = 27 },
> > .level = 1,
> > @@ -58,6 +63,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> >  {
> > struct kvm_regs *reset_regs;
> > const struct kvm_irq_level *cpu_vtimer_irq;
> > +   const struct kvm_irq_level *cpu_ptimer_irq;
> >  
> > switch (vcpu->arch.target) {
> > case KVM_ARM_TARGET_CORTEX_A7:
> > @@ -65,6 +71,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > reset_regs = _regs_reset;
> > vcpu->arch.midr = read_cpuid_id();
> > cpu_vtimer_irq = _vtimer_irq;
> > +   cpu_ptimer_irq = _ptimer_irq;
> > break;
> > default:
> > return -ENODEV;
> > @@ -77,5 +84,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > kvm_reset_coprocs(vcpu);
> >  
> > /* Reset arch_timer context */
> > -   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> > +   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
> >  }
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index e95d4f6..d9e9697 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -46,6 +46,11 @@
> > COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
> >  };
> >  
> > +static const struct kvm_irq_level default_ptimer_irq = {
> > +   .irq= 30,
> > +   .level  = 1,
> > +};
> > +
> >  static const struct kvm_irq_level default_vtimer_irq = {
> > .irq= 27,
> > .level  = 1,
> > @@ -104,6 +109,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, 
> > long ext)
> >  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> >  {
> > const struct kvm_irq_level *cpu_vtimer_irq;
> > +   const struct kvm_irq_level *cpu_ptimer_irq;
> > const struct kvm_regs *cpu_reset;
> >  
> > switch (vcpu->arch.target) {
> > @@ -117,6 +123,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > }
> >  
> > cpu_vtimer_irq = _vtimer_irq;
> > +   cpu_ptimer_irq = _ptimer_irq;
> > break;
> > }
> >  
> > @@ -130,5 +137,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > kvm_pmu_vcpu_reset(vcpu);
> >  
> > /* Reset timer */
> > -   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> > +   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
> >  }
> > diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> > index 69f648b..a364593 100644
> > --- a/include/kvm/arm_arch_timer.h
> > +++ b/include/kvm/arm_arch_timer.h
> > @@ -59,7 +59,8 @@ struct arch_timer_cpu {
> >  int kvm_timer_enable(struct kvm_vcpu *vcpu);
> >  void kvm_timer_init(struct kvm *kvm);
> >  int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> > -const struct kvm_irq_level *irq);
> > +const struct kvm_irq_level *virt_irq,
> > +const struct kvm_irq_level *phys_irq);
> >  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
> >  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
> >  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index f72005a..0f6e935 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -329,9 +329,11 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> >  }
> >  
> >  int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> > -const struct kvm_irq_level *irq)
> > +const struct kvm_irq_level *virt_irq,
> > +const struct kvm_irq_level *phys_irq)
> >  {
> > struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> > +   struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> >  
> > /*
> >  * The vcpu timer irq number cannot be determined in
> > @@ -339,7 +341,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> >  * kvm_vcpu_set_target(). To handle this, we determine
> >  * vcpu timer 

Re: [RFC v2 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer

[Christoffer Dall]

On Sun, Jan 29, 2017 at 12:07:48PM +, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:55 AM, Jintack Lim  
> wrote:
> > Initialize the emulated EL1 physical timer with the default irq number.
> >
> > Signed-off-by: Jintack Lim 
> > ---
> >  arch/arm/kvm/reset.c | 9 -
> >  arch/arm64/kvm/reset.c   | 9 -
> >  include/kvm/arm_arch_timer.h | 3 ++-
> >  virt/kvm/arm/arch_timer.c| 9 +++--
> >  4 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> > index 4b5e802..1da8b2d 100644
> > --- a/arch/arm/kvm/reset.c
> > +++ b/arch/arm/kvm/reset.c
> > @@ -37,6 +37,11 @@
> > .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
> >  };
> >  
> > +static const struct kvm_irq_level cortexa_ptimer_irq = {
> > +   { .irq = 30 },
> > +   .level = 1,
> > +};
> 
> At some point, we'll have to make that discoverable/configurable. Maybe
> the time for a discoverable arch timer has come (see below).
> 
> > +
> >  static const struct kvm_irq_level cortexa_vtimer_irq = {
> > { .irq = 27 },
> > .level = 1,
> > @@ -58,6 +63,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> >  {
> > struct kvm_regs *reset_regs;
> > const struct kvm_irq_level *cpu_vtimer_irq;
> > +   const struct kvm_irq_level *cpu_ptimer_irq;
> >  
> > switch (vcpu->arch.target) {
> > case KVM_ARM_TARGET_CORTEX_A7:
> > @@ -65,6 +71,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > reset_regs = _regs_reset;
> > vcpu->arch.midr = read_cpuid_id();
> > cpu_vtimer_irq = _vtimer_irq;
> > +   cpu_ptimer_irq = _ptimer_irq;
> > break;
> > default:
> > return -ENODEV;
> > @@ -77,5 +84,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > kvm_reset_coprocs(vcpu);
> >  
> > /* Reset arch_timer context */
> > -   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> > +   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
> >  }
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index e95d4f6..d9e9697 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -46,6 +46,11 @@
> > COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
> >  };
> >  
> > +static const struct kvm_irq_level default_ptimer_irq = {
> > +   .irq= 30,
> > +   .level  = 1,
> > +};
> > +
> >  static const struct kvm_irq_level default_vtimer_irq = {
> > .irq= 27,
> > .level  = 1,
> > @@ -104,6 +109,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, 
> > long ext)
> >  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> >  {
> > const struct kvm_irq_level *cpu_vtimer_irq;
> > +   const struct kvm_irq_level *cpu_ptimer_irq;
> > const struct kvm_regs *cpu_reset;
> >  
> > switch (vcpu->arch.target) {
> > @@ -117,6 +123,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > }
> >  
> > cpu_vtimer_irq = _vtimer_irq;
> > +   cpu_ptimer_irq = _ptimer_irq;
> > break;
> > }
> >  
> > @@ -130,5 +137,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> > kvm_pmu_vcpu_reset(vcpu);
> >  
> > /* Reset timer */
> > -   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> > +   return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
> >  }
> > diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> > index 69f648b..a364593 100644
> > --- a/include/kvm/arm_arch_timer.h
> > +++ b/include/kvm/arm_arch_timer.h
> > @@ -59,7 +59,8 @@ struct arch_timer_cpu {
> >  int kvm_timer_enable(struct kvm_vcpu *vcpu);
> >  void kvm_timer_init(struct kvm *kvm);
> >  int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> > -const struct kvm_irq_level *irq);
> > +const struct kvm_irq_level *virt_irq,
> > +const struct kvm_irq_level *phys_irq);
> >  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
> >  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
> >  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index f72005a..0f6e935 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -329,9 +329,11 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> >  }
> >  
> >  int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> > -const struct kvm_irq_level *irq)
> > +const struct kvm_irq_level *virt_irq,
> > +const struct kvm_irq_level *phys_irq)
> >  {
> > struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> > +   struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> >  
> > /*
> >  * The vcpu timer irq number cannot be determined in
> > @@ -339,7 +341,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> >  * kvm_vcpu_set_target(). To handle this, we determine
> >  * vcpu timer irq number when the vcpu is reset.
> >  */
> 

Re: [PATCH v3 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic

[Pavel Tikhomirov]

please drop it, errors in commit message

On 01/30/2017 05:48 PM, Pavel Tikhomirov wrote:

Oleg Nesterov (1):
  introduce the walk_process_tree() helper

Pavel Tikhomirov (1):
  prctl: propagate has_child_subreaper flag to every descendant

 include/linux/sched.h |  3 +++
 kernel/fork.c | 42 +++---
 kernel/sys.c  | 22 ++
 3 files changed, 64 insertions(+), 3 deletions(-)



--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.

Re: [PATCH v3 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic

[Pavel Tikhomirov]

please drop it, errors in commit message

On 01/30/2017 05:48 PM, Pavel Tikhomirov wrote:

Oleg Nesterov (1):
  introduce the walk_process_tree() helper

Pavel Tikhomirov (1):
  prctl: propagate has_child_subreaper flag to every descendant

 include/linux/sched.h |  3 +++
 kernel/fork.c | 42 +++---
 kernel/sys.c  | 22 ++
 3 files changed, 64 insertions(+), 3 deletions(-)



--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.

Re: [PATCH 1/2] gpio: mcp23s08: use regmap

[Linus Walleij]

On Fri, Jan 27, 2017 at 3:47 PM, Sebastian Reichel  wrote:

> Use regmap API to save some lines of codes and have
> debugfs support for all of the MCP's registers.
>
> Signed-off-by: Sebastian Reichel 

Patch applied. Irresistible cleanup!

Yours,
Linus Walleij

Re: [PATCH 1/2] gpio: mcp23s08: use regmap

[Linus Walleij]

On Fri, Jan 27, 2017 at 3:47 PM, Sebastian Reichel  wrote:

> Use regmap API to save some lines of codes and have
> debugfs support for all of the MCP's registers.
>
> Signed-off-by: Sebastian Reichel 

Patch applied. Irresistible cleanup!

Yours,
Linus Walleij

Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context

[Marc Zyngier]

On 30/01/17 14:45, Christoffer Dall wrote:
> On Sun, Jan 29, 2017 at 11:54:05AM +, Marc Zyngier wrote:
>> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim  
>> wrote:
>>> Make cntvoff per each timer context. This is helpful to abstract kvm
>>> timer functions to work with timer context without considering timer
>>> types (e.g. physical timer or virtual timer).
>>>
>>> This also would pave the way for ever doing adjustments of the cntvoff
>>> on a per-CPU basis if that should ever make sense.
>>>
>>> Signed-off-by: Jintack Lim 
>>> ---
>>>  arch/arm/include/asm/kvm_host.h   |  6 +++---
>>>  arch/arm64/include/asm/kvm_host.h |  4 ++--
>>>  include/kvm/arm_arch_timer.h  |  8 +++-
>>>  virt/kvm/arm/arch_timer.c | 26 --
>>>  virt/kvm/arm/hyp/timer-sr.c   |  3 +--
>>>  5 files changed, 29 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/kvm_host.h 
>>> b/arch/arm/include/asm/kvm_host.h
>>> index d5423ab..f5456a9 100644
>>> --- a/arch/arm/include/asm/kvm_host.h
>>> +++ b/arch/arm/include/asm/kvm_host.h
>>> @@ -60,9 +60,6 @@ struct kvm_arch {
>>> /* The last vcpu id that ran on each physical CPU */
>>> int __percpu *last_vcpu_ran;
>>>  
>>> -   /* Timer */
>>> -   struct arch_timer_kvm   timer;
>>> -
>>> /*
>>>  * Anything that is not used directly from assembly code goes
>>>  * here.
>>> @@ -75,6 +72,9 @@ struct kvm_arch {
>>> /* Stage-2 page table */
>>> pgd_t *pgd;
>>>  
>>> +   /* A lock to synchronize cntvoff among all vtimer context of vcpus */
>>> +   spinlock_t cntvoff_lock;
>>
>> Is there any condition where we need this to be a spinlock? I would have
>> thought that a mutex should have been enough, as this should only be
>> updated on migration or initialization. Not that it matters much in this
>> case, but I wondered if there is something I'm missing.
>>
> 
> I would think the critical section is small enough that a spinlock makes
> sense, but what I don't think we need is to add the additional lock.
> 
> I think just taking the kvm->lock should be sufficient, which happens to
> be a mutex, and while that may be a bit slower to take than the
> spinlock, it's not in the critical path so let's just keep things
> simple.
> 
> Perhaps this what Marc also meant.

That would be the logical conclusion, assuming that we can sleep on this
path.

Thanks,

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

Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context

[Marc Zyngier]

On 30/01/17 14:45, Christoffer Dall wrote:
> On Sun, Jan 29, 2017 at 11:54:05AM +, Marc Zyngier wrote:
>> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim  
>> wrote:
>>> Make cntvoff per each timer context. This is helpful to abstract kvm
>>> timer functions to work with timer context without considering timer
>>> types (e.g. physical timer or virtual timer).
>>>
>>> This also would pave the way for ever doing adjustments of the cntvoff
>>> on a per-CPU basis if that should ever make sense.
>>>
>>> Signed-off-by: Jintack Lim 
>>> ---
>>>  arch/arm/include/asm/kvm_host.h   |  6 +++---
>>>  arch/arm64/include/asm/kvm_host.h |  4 ++--
>>>  include/kvm/arm_arch_timer.h  |  8 +++-
>>>  virt/kvm/arm/arch_timer.c | 26 --
>>>  virt/kvm/arm/hyp/timer-sr.c   |  3 +--
>>>  5 files changed, 29 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/kvm_host.h 
>>> b/arch/arm/include/asm/kvm_host.h
>>> index d5423ab..f5456a9 100644
>>> --- a/arch/arm/include/asm/kvm_host.h
>>> +++ b/arch/arm/include/asm/kvm_host.h
>>> @@ -60,9 +60,6 @@ struct kvm_arch {
>>> /* The last vcpu id that ran on each physical CPU */
>>> int __percpu *last_vcpu_ran;
>>>  
>>> -   /* Timer */
>>> -   struct arch_timer_kvm   timer;
>>> -
>>> /*
>>>  * Anything that is not used directly from assembly code goes
>>>  * here.
>>> @@ -75,6 +72,9 @@ struct kvm_arch {
>>> /* Stage-2 page table */
>>> pgd_t *pgd;
>>>  
>>> +   /* A lock to synchronize cntvoff among all vtimer context of vcpus */
>>> +   spinlock_t cntvoff_lock;
>>
>> Is there any condition where we need this to be a spinlock? I would have
>> thought that a mutex should have been enough, as this should only be
>> updated on migration or initialization. Not that it matters much in this
>> case, but I wondered if there is something I'm missing.
>>
> 
> I would think the critical section is small enough that a spinlock makes
> sense, but what I don't think we need is to add the additional lock.
> 
> I think just taking the kvm->lock should be sufficient, which happens to
> be a mutex, and while that may be a bit slower to take than the
> spinlock, it's not in the critical path so let's just keep things
> simple.
> 
> Perhaps this what Marc also meant.

That would be the logical conclusion, assuming that we can sleep on this
path.

Thanks,

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

Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

[Jason Cooper]

Hi Bjorn,

On Sat, Jan 28, 2017 at 03:17:28PM -0600, Bjorn Helgaas wrote:
> On Wed, Jan 11, 2017 at 12:30:55PM -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote:
> > > The PCI core will write to the bridge window config multiple times
> > > while they are enabled. This can lead to mbus failures like:
> > > 
> > >  mvebu_mbus: cannot add window '4:e8', conflicts with another window
> > >  mvebu-pcie mbus:pex@e000: Could not create MBus window at [mem 
> > > 0xe000-0xe00f]: -22
> > > 
> > > For me this is happening during a hotplug cycle. The PCI core is
> > > not changing the values, just writing them twice while active.
> > > 
> > > The patch addresses the general case of any change to an active window,
> > > but not atomically. The code is slightly refactored so io and mem
> > > can share more of the window logic.
> > 
> > Looks good to me, but I'm waiting for an ack from Thomas or Jason (listed
> > as maintainers and already cc'd).
> 
> Ping, Thomas, Jason C?
> 
> > > Signed-off-by: Jason Gunthorpe 
> > > ---
> > >  drivers/pci/host/pci-mvebu.c | 101 
> > > +--
> > >  1 file changed, 60 insertions(+), 41 deletions(-)

Sorry, been on travel and I think Thomas is on holiday.

Acked-by: Jason Cooper 

thx,

Jason.

Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

[Jason Cooper]

Hi Bjorn,

On Sat, Jan 28, 2017 at 03:17:28PM -0600, Bjorn Helgaas wrote:
> On Wed, Jan 11, 2017 at 12:30:55PM -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote:
> > > The PCI core will write to the bridge window config multiple times
> > > while they are enabled. This can lead to mbus failures like:
> > > 
> > >  mvebu_mbus: cannot add window '4:e8', conflicts with another window
> > >  mvebu-pcie mbus:pex@e000: Could not create MBus window at [mem 
> > > 0xe000-0xe00f]: -22
> > > 
> > > For me this is happening during a hotplug cycle. The PCI core is
> > > not changing the values, just writing them twice while active.
> > > 
> > > The patch addresses the general case of any change to an active window,
> > > but not atomically. The code is slightly refactored so io and mem
> > > can share more of the window logic.
> > 
> > Looks good to me, but I'm waiting for an ack from Thomas or Jason (listed
> > as maintainers and already cc'd).
> 
> Ping, Thomas, Jason C?
> 
> > > Signed-off-by: Jason Gunthorpe 
> > > ---
> > >  drivers/pci/host/pci-mvebu.c | 101 
> > > +--
> > >  1 file changed, 60 insertions(+), 41 deletions(-)

Sorry, been on travel and I think Thomas is on holiday.

Acked-by: Jason Cooper 

thx,

Jason.

[PATCH 5/5] gpio: ws16c48: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
ws16c48_remove function. Now that the ws16c48_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-ws16c48.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index 65de20dfbe7a..48b35589b7d6 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -372,8 +372,6 @@ static int ws16c48_probe(struct device *dev, unsigned int 
id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, ws16c48gpio);
-
err = devm_gpiochip_add_data(dev, >chip, ws16c48gpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 5/5] gpio: ws16c48: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
ws16c48_remove function. Now that the ws16c48_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-ws16c48.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index 65de20dfbe7a..48b35589b7d6 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -372,8 +372,6 @@ static int ws16c48_probe(struct device *dev, unsigned int 
id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, ws16c48gpio);
-
err = devm_gpiochip_add_data(dev, >chip, ws16c48gpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 4/5] gpio: gpio-mm: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
gpiomm_remove function. Now that the gpiomm_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-gpio-mm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-gpio-mm.c b/drivers/gpio/gpio-gpio-mm.c
index 393c8f9cf30d..60017425b49f 100644
--- a/drivers/gpio/gpio-gpio-mm.c
+++ b/drivers/gpio/gpio-gpio-mm.c
@@ -261,8 +261,6 @@ static int gpiomm_probe(struct device *dev, unsigned int id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, gpiommgpio);
-
err = devm_gpiochip_add_data(dev, >chip, gpiommgpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 4/5] gpio: gpio-mm: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
gpiomm_remove function. Now that the gpiomm_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-gpio-mm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-gpio-mm.c b/drivers/gpio/gpio-gpio-mm.c
index 393c8f9cf30d..60017425b49f 100644
--- a/drivers/gpio/gpio-gpio-mm.c
+++ b/drivers/gpio/gpio-gpio-mm.c
@@ -261,8 +261,6 @@ static int gpiomm_probe(struct device *dev, unsigned int id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, gpiommgpio);
-
err = devm_gpiochip_add_data(dev, >chip, gpiommgpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

Re: [PATCHv5 0/5] Support for Marvell switches with integrated CPUs

[Gregory CLEMENT]

Hi Chris,
 
 On dim., janv. 29 2017, Chris Packham  
wrote:

> On 28/01/17 07:47, Stephen Boyd wrote:
>> On 01/27, Gregory CLEMENT wrote:
>>> Hi all,
>>>
>>>  On ven., janv. 27 2017, Chris Packham  
>>> wrote:
>>>
 The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
 integrated CPUs. They CPU block is common within these product lines and
 (as far as I can tell/have been told) is based on the Armada XP. There
 are a few differences due to the fact they have to squeeze the CPU into
 the same package as the switch.

 I've rebased this series against linux-pinctrl/devel to get access to
 mvebu_mmio_mpp_ctrl. Everything else still applies cleanly to
 v4.10.0-rc5.
>>>
>>> Just to let you know that I plan to apply the 3 arm patch once Chris
>>> will have sent the new series with the minor fixes I asked on patch 3.
>>>
>>> I already applied them in the for-next branch to benefit of some build
>>> test coverage.
>>>
>>> Stephen,
>>>
>>> you gave your Acked-by on the first patch, but don't you plan to apply
>>> it on the clk branch?
>>
>> It must have not been clear if I should apply it, hence the ack.
>> I'll apply it now.
>>
>
> Sorry my bad. I need all 5 together in one place to actually test the 
> series.

The 5 patches should be available soon (if it is not already the case),
in the linux-next branch.

The clk patch is already there, the 3 arm patch have been merged in my
mvebu/for-next branch, and the pinctrl patch is about to be merged in
the pinctrl/for-next branch.

Gregory

>
> I wasn't sure whether the series should go through mvebu with Acks from 
> clk and pinctrl or if things should go to the separate maintainers and 
> come together when they hit the main linux repo. Up until the latest 
> pinctrl change either approach would have worked.

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCHv5 0/5] Support for Marvell switches with integrated CPUs

[Gregory CLEMENT]

Hi Chris,
 
 On dim., janv. 29 2017, Chris Packham  
wrote:

> On 28/01/17 07:47, Stephen Boyd wrote:
>> On 01/27, Gregory CLEMENT wrote:
>>> Hi all,
>>>
>>>  On ven., janv. 27 2017, Chris Packham  
>>> wrote:
>>>
 The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
 integrated CPUs. They CPU block is common within these product lines and
 (as far as I can tell/have been told) is based on the Armada XP. There
 are a few differences due to the fact they have to squeeze the CPU into
 the same package as the switch.

 I've rebased this series against linux-pinctrl/devel to get access to
 mvebu_mmio_mpp_ctrl. Everything else still applies cleanly to
 v4.10.0-rc5.
>>>
>>> Just to let you know that I plan to apply the 3 arm patch once Chris
>>> will have sent the new series with the minor fixes I asked on patch 3.
>>>
>>> I already applied them in the for-next branch to benefit of some build
>>> test coverage.
>>>
>>> Stephen,
>>>
>>> you gave your Acked-by on the first patch, but don't you plan to apply
>>> it on the clk branch?
>>
>> It must have not been clear if I should apply it, hence the ack.
>> I'll apply it now.
>>
>
> Sorry my bad. I need all 5 together in one place to actually test the 
> series.

The 5 patches should be available soon (if it is not already the case),
in the linux-next branch.

The clk patch is already there, the 3 arm patch have been merged in my
mvebu/for-next branch, and the pinctrl patch is about to be merged in
the pinctrl/for-next branch.

Gregory

>
> I wasn't sure whether the series should go through mvebu with Acks from 
> clk and pinctrl or if things should go to the separate maintainers and 
> come together when they hit the main linux repo. Up until the latest 
> pinctrl change either approach would have worked.

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context

[Christoffer Dall]

On Sun, Jan 29, 2017 at 11:54:05AM +, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim  
> wrote:
> > Make cntvoff per each timer context. This is helpful to abstract kvm
> > timer functions to work with timer context without considering timer
> > types (e.g. physical timer or virtual timer).
> >
> > This also would pave the way for ever doing adjustments of the cntvoff
> > on a per-CPU basis if that should ever make sense.
> >
> > Signed-off-by: Jintack Lim 
> > ---
> >  arch/arm/include/asm/kvm_host.h   |  6 +++---
> >  arch/arm64/include/asm/kvm_host.h |  4 ++--
> >  include/kvm/arm_arch_timer.h  |  8 +++-
> >  virt/kvm/arm/arch_timer.c | 26 --
> >  virt/kvm/arm/hyp/timer-sr.c   |  3 +--
> >  5 files changed, 29 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/kvm_host.h 
> > b/arch/arm/include/asm/kvm_host.h
> > index d5423ab..f5456a9 100644
> > --- a/arch/arm/include/asm/kvm_host.h
> > +++ b/arch/arm/include/asm/kvm_host.h
> > @@ -60,9 +60,6 @@ struct kvm_arch {
> > /* The last vcpu id that ran on each physical CPU */
> > int __percpu *last_vcpu_ran;
> >  
> > -   /* Timer */
> > -   struct arch_timer_kvm   timer;
> > -
> > /*
> >  * Anything that is not used directly from assembly code goes
> >  * here.
> > @@ -75,6 +72,9 @@ struct kvm_arch {
> > /* Stage-2 page table */
> > pgd_t *pgd;
> >  
> > +   /* A lock to synchronize cntvoff among all vtimer context of vcpus */
> > +   spinlock_t cntvoff_lock;
> 
> Is there any condition where we need this to be a spinlock? I would have
> thought that a mutex should have been enough, as this should only be
> updated on migration or initialization. Not that it matters much in this
> case, but I wondered if there is something I'm missing.
> 

I would think the critical section is small enough that a spinlock makes
sense, but what I don't think we need is to add the additional lock.

I think just taking the kvm->lock should be sufficient, which happens to
be a mutex, and while that may be a bit slower to take than the
spinlock, it's not in the critical path so let's just keep things
simple.

Perhaps this what Marc also meant.

> > +
> > /* Interrupt controller */
> > struct vgic_distvgic;
> > int max_vcpus;
> > diff --git a/arch/arm64/include/asm/kvm_host.h 
> > b/arch/arm64/include/asm/kvm_host.h
> > index e505038..23749a8 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -71,8 +71,8 @@ struct kvm_arch {
> > /* Interrupt controller */
> > struct vgic_distvgic;
> >  
> > -   /* Timer */
> > -   struct arch_timer_kvm   timer;
> > +   /* A lock to synchronize cntvoff among all vtimer context of vcpus */
> > +   spinlock_t cntvoff_lock;
> >  };
> >  
> >  #define KVM_NR_MEM_OBJS 40
> > diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> > index daad3c1..1b9c988 100644
> > --- a/include/kvm/arm_arch_timer.h
> > +++ b/include/kvm/arm_arch_timer.h
> > @@ -23,11 +23,6 @@
> >  #include 
> >  #include 
> >  
> > -struct arch_timer_kvm {
> > -   /* Virtual offset */
> > -   u64 cntvoff;
> > -};
> > -
> >  struct arch_timer_context {
> > /* Registers: control register, timer value */
> > u32 cnt_ctl;
> > @@ -38,6 +33,9 @@ struct arch_timer_context {
> >  
> > /* Active IRQ state caching */
> > boolactive_cleared_last;
> > +
> > +   /* Virtual offset */
> > +   u64 cntvoff;
> >  };
> >  
> >  struct arch_timer_cpu {
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 6740efa..fa4c042 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -101,9 +101,10 @@ static void kvm_timer_inject_irq_work(struct 
> > work_struct *work)
> >  static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
> >  {
> > u64 cval, now;
> > +   struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> >  
> > -   cval = vcpu_vtimer(vcpu)->cnt_cval;
> > -   now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
> > +   cval = vtimer->cnt_cval;
> > +   now = kvm_phys_timer_read() - vtimer->cntvoff;
> >  
> > if (now < cval) {
> > u64 ns;
> > @@ -159,7 +160,7 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
> > return false;
> >  
> > cval = vtimer->cnt_cval;
> > -   now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
> > +   now = kvm_phys_timer_read() - vtimer->cntvoff;
> >  
> > return cval <= now;
> >  }
> > @@ -353,10 +354,23 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> > return 0;
> >  }
> >  
> > +/* Make the updates of cntvoff for all vtimer contexts atomic */
> > +static void update_vtimer_cntvoff(struct kvm_vcpu *vcpu, u64 cntvoff)
> 
> Arguably, this acts on the VM itself 

Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context

[Christoffer Dall]

On Sun, Jan 29, 2017 at 11:54:05AM +, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim  
> wrote:
> > Make cntvoff per each timer context. This is helpful to abstract kvm
> > timer functions to work with timer context without considering timer
> > types (e.g. physical timer or virtual timer).
> >
> > This also would pave the way for ever doing adjustments of the cntvoff
> > on a per-CPU basis if that should ever make sense.
> >
> > Signed-off-by: Jintack Lim 
> > ---
> >  arch/arm/include/asm/kvm_host.h   |  6 +++---
> >  arch/arm64/include/asm/kvm_host.h |  4 ++--
> >  include/kvm/arm_arch_timer.h  |  8 +++-
> >  virt/kvm/arm/arch_timer.c | 26 --
> >  virt/kvm/arm/hyp/timer-sr.c   |  3 +--
> >  5 files changed, 29 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/kvm_host.h 
> > b/arch/arm/include/asm/kvm_host.h
> > index d5423ab..f5456a9 100644
> > --- a/arch/arm/include/asm/kvm_host.h
> > +++ b/arch/arm/include/asm/kvm_host.h
> > @@ -60,9 +60,6 @@ struct kvm_arch {
> > /* The last vcpu id that ran on each physical CPU */
> > int __percpu *last_vcpu_ran;
> >  
> > -   /* Timer */
> > -   struct arch_timer_kvm   timer;
> > -
> > /*
> >  * Anything that is not used directly from assembly code goes
> >  * here.
> > @@ -75,6 +72,9 @@ struct kvm_arch {
> > /* Stage-2 page table */
> > pgd_t *pgd;
> >  
> > +   /* A lock to synchronize cntvoff among all vtimer context of vcpus */
> > +   spinlock_t cntvoff_lock;
> 
> Is there any condition where we need this to be a spinlock? I would have
> thought that a mutex should have been enough, as this should only be
> updated on migration or initialization. Not that it matters much in this
> case, but I wondered if there is something I'm missing.
> 

I would think the critical section is small enough that a spinlock makes
sense, but what I don't think we need is to add the additional lock.

I think just taking the kvm->lock should be sufficient, which happens to
be a mutex, and while that may be a bit slower to take than the
spinlock, it's not in the critical path so let's just keep things
simple.

Perhaps this what Marc also meant.

> > +
> > /* Interrupt controller */
> > struct vgic_distvgic;
> > int max_vcpus;
> > diff --git a/arch/arm64/include/asm/kvm_host.h 
> > b/arch/arm64/include/asm/kvm_host.h
> > index e505038..23749a8 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -71,8 +71,8 @@ struct kvm_arch {
> > /* Interrupt controller */
> > struct vgic_distvgic;
> >  
> > -   /* Timer */
> > -   struct arch_timer_kvm   timer;
> > +   /* A lock to synchronize cntvoff among all vtimer context of vcpus */
> > +   spinlock_t cntvoff_lock;
> >  };
> >  
> >  #define KVM_NR_MEM_OBJS 40
> > diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> > index daad3c1..1b9c988 100644
> > --- a/include/kvm/arm_arch_timer.h
> > +++ b/include/kvm/arm_arch_timer.h
> > @@ -23,11 +23,6 @@
> >  #include 
> >  #include 
> >  
> > -struct arch_timer_kvm {
> > -   /* Virtual offset */
> > -   u64 cntvoff;
> > -};
> > -
> >  struct arch_timer_context {
> > /* Registers: control register, timer value */
> > u32 cnt_ctl;
> > @@ -38,6 +33,9 @@ struct arch_timer_context {
> >  
> > /* Active IRQ state caching */
> > boolactive_cleared_last;
> > +
> > +   /* Virtual offset */
> > +   u64 cntvoff;
> >  };
> >  
> >  struct arch_timer_cpu {
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 6740efa..fa4c042 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -101,9 +101,10 @@ static void kvm_timer_inject_irq_work(struct 
> > work_struct *work)
> >  static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
> >  {
> > u64 cval, now;
> > +   struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> >  
> > -   cval = vcpu_vtimer(vcpu)->cnt_cval;
> > -   now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
> > +   cval = vtimer->cnt_cval;
> > +   now = kvm_phys_timer_read() - vtimer->cntvoff;
> >  
> > if (now < cval) {
> > u64 ns;
> > @@ -159,7 +160,7 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
> > return false;
> >  
> > cval = vtimer->cnt_cval;
> > -   now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
> > +   now = kvm_phys_timer_read() - vtimer->cntvoff;
> >  
> > return cval <= now;
> >  }
> > @@ -353,10 +354,23 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> > return 0;
> >  }
> >  
> > +/* Make the updates of cntvoff for all vtimer contexts atomic */
> > +static void update_vtimer_cntvoff(struct kvm_vcpu *vcpu, u64 cntvoff)
> 
> Arguably, this acts on the VM itself and not a single vcpu. maybe you
> should consider 

[PATCH 1/2] dts: arm64: add LS1043A DPAA support

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi |  33 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts  |   2 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts  |  75 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  73 +-
 .../boot/dts/freescale/qoriq-bman1-portals.dtsi|  93 ++
 .../boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi|  68 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi |  67 +
 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi   | 106 +
 .../boot/dts/freescale/qoriq-qman1-portals.dtsi| 102 
 14 files changed, 953 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
new file mode 100644
index 000..84c927c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
@@ -0,0 +1,33 @@
+ {
+
+/include/ "qoriq-fman3-0.dtsi"
+/include/ "qoriq-fman3-0-1g-0.dtsi"
+/include/ "qoriq-fman3-0-1g-1.dtsi"
+/include/ "qoriq-fman3-0-1g-2.dtsi"
+/include/ "qoriq-fman3-0-1g-3.dtsi"
+/include/ "qoriq-fman3-0-1g-4.dtsi"
+/include/ "qoriq-fman3-0-1g-5.dtsi"
+/include/ "qoriq-fman3-0-10g-0.dtsi"
+   fman@1a0 {
+   enet0: ethernet@e {
+   };
+
+   enet1: ethernet@e2000 {
+   };
+
+   enet2: ethernet@e4000 {
+   };
+
+   enet3: ethernet@e6000 {
+   };
+
+   enet4: ethernet@e8000 {
+   };
+
+   enet5: ethernet@ea000 {
+   };
+
+   enet6: ethernet@f {
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 0989d63..ee66bb2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -181,3 +181,5 @@
reg = <0>;
};
 };
+
+/include/ "fsl-ls1043-post.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index c37110b..d94f003 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -139,3 +139,78 @@
  {
status = "okay";
 };
+
+/include/ "fsl-ls1043-post.dtsi"
+
+ {
+   fman@1a0 {
+   ethernet@e {
+   phy-handle = <_phy1>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@e2000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@e4000 {
+   phy-handle = <_phy1>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e6000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e8000 {
+   phy-handle = <_phy3>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@ea000 {
+   phy-handle = <_phy4>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@f { /* 10GEC1 */
+   phy-handle = <_phy>;
+   phy-connection-type = "xgmii";
+   };
+
+   mdio@fc000 {
+   rgmii_phy1: ethernet-phy@1 {
+   reg = <0x1>;
+   };
+
+   rgmii_phy2: ethernet-phy@2 {
+

[PATCH 1/2] dts: arm64: add LS1043A DPAA support

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi |  33 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts  |   2 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts  |  75 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  73 +-
 .../boot/dts/freescale/qoriq-bman1-portals.dtsi|  93 ++
 .../boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi|  68 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi |  67 +
 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi   | 106 +
 .../boot/dts/freescale/qoriq-qman1-portals.dtsi| 102 
 14 files changed, 953 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
new file mode 100644
index 000..84c927c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
@@ -0,0 +1,33 @@
+ {
+
+/include/ "qoriq-fman3-0.dtsi"
+/include/ "qoriq-fman3-0-1g-0.dtsi"
+/include/ "qoriq-fman3-0-1g-1.dtsi"
+/include/ "qoriq-fman3-0-1g-2.dtsi"
+/include/ "qoriq-fman3-0-1g-3.dtsi"
+/include/ "qoriq-fman3-0-1g-4.dtsi"
+/include/ "qoriq-fman3-0-1g-5.dtsi"
+/include/ "qoriq-fman3-0-10g-0.dtsi"
+   fman@1a0 {
+   enet0: ethernet@e {
+   };
+
+   enet1: ethernet@e2000 {
+   };
+
+   enet2: ethernet@e4000 {
+   };
+
+   enet3: ethernet@e6000 {
+   };
+
+   enet4: ethernet@e8000 {
+   };
+
+   enet5: ethernet@ea000 {
+   };
+
+   enet6: ethernet@f {
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 0989d63..ee66bb2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -181,3 +181,5 @@
reg = <0>;
};
 };
+
+/include/ "fsl-ls1043-post.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index c37110b..d94f003 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -139,3 +139,78 @@
  {
status = "okay";
 };
+
+/include/ "fsl-ls1043-post.dtsi"
+
+ {
+   fman@1a0 {
+   ethernet@e {
+   phy-handle = <_phy1>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@e2000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@e4000 {
+   phy-handle = <_phy1>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e6000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e8000 {
+   phy-handle = <_phy3>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@ea000 {
+   phy-handle = <_phy4>;
+   phy-connection-type = "qsgmii";
+   };
+
+   ethernet@f { /* 10GEC1 */
+   phy-handle = <_phy>;
+   phy-connection-type = "xgmii";
+   };
+
+   mdio@fc000 {
+   rgmii_phy1: ethernet-phy@1 {
+   reg = <0x1>;
+   };
+
+   rgmii_phy2: ethernet-phy@2 {
+   reg 

[PATCH 0/2] dts: arm64: add DPAA 1 support for ARM based SoCs

[Madalin Bucur]

Add DPAA 1 nodes for LS1043A/LS1046A and networking support for RDB
and QDS boards with these SoCs.

Madalin Bucur (2):
  dts: arm64: add LS1043A DPAA support
  dts: arm64: add LS1046A DPAA support

 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi |  33 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts  |   2 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts  |  75 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  73 +-
 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi |  37 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts  |   2 +
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts  |  62 
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |  66 -
 .../boot/dts/freescale/qoriq-bman1-portals.dtsi|  93 ++
 .../boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi|  68 +
 .../boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi|  68 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi |  67 +
 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi   | 106 +
 .../boot/dts/freescale/qoriq-qman1-portals.dtsi| 102 
 19 files changed, 1187 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi

-- 
2.1.0

[PATCH 0/2] dts: arm64: add DPAA 1 support for ARM based SoCs

[Madalin Bucur]

Add DPAA 1 nodes for LS1043A/LS1046A and networking support for RDB
and QDS boards with these SoCs.

Madalin Bucur (2):
  dts: arm64: add LS1043A DPAA support
  dts: arm64: add LS1046A DPAA support

 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi |  33 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts  |   2 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts  |  75 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  73 +-
 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi |  37 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts  |   2 +
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts  |  62 
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |  66 -
 .../boot/dts/freescale/qoriq-bman1-portals.dtsi|  93 ++
 .../boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi|  68 +
 .../boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi|  68 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi |  67 +
 .../boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi |  67 +
 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi   | 106 +
 .../boot/dts/freescale/qoriq-qman1-portals.dtsi| 102 
 19 files changed, 1187 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi

-- 
2.1.0

[PATCH 2/2] dts: arm64: add LS1046A DPAA support

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi | 37 
 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts  |  2 +
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts  | 62 
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 66 -
 .../boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi| 68 ++
 5 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
new file mode 100644
index 000..cb2e4a3
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
@@ -0,0 +1,37 @@
+ {
+
+/include/ "qoriq-fman3-0.dtsi"
+/include/ "qoriq-fman3-0-1g-0.dtsi"
+/include/ "qoriq-fman3-0-1g-1.dtsi"
+/include/ "qoriq-fman3-0-1g-2.dtsi"
+/include/ "qoriq-fman3-0-1g-3.dtsi"
+/include/ "qoriq-fman3-0-1g-4.dtsi"
+/include/ "qoriq-fman3-0-1g-5.dtsi"
+/include/ "qoriq-fman3-0-10g-0.dtsi"
+/include/ "qoriq-fman3-0-10g-1.dtsi"
+   fman@1a0 {
+   enet0: ethernet@e {
+   };
+
+   enet1: ethernet@e2000 {
+   };
+
+   enet2: ethernet@e4000 {
+   };
+
+   enet3: ethernet@e6000 {
+   };
+
+   enet4: ethernet@e8000 {
+   };
+
+   enet5: ethernet@ea000 {
+   };
+
+   enet6: ethernet@f {
+   };
+
+   enet7: ethernet@f2000 {
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index 290e5b0..ccd3948 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -210,3 +210,5 @@
reg = <0>;
};
 };
+
+/include/ "fsl-ls1046-post.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index d1ccc00..78d5609 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -148,3 +148,65 @@
reg = <1>;
};
 };
+
+/include/ "fsl-ls1046-post.dtsi"
+
+ {
+   fman@1a0 {
+   ethernet@e4000 {
+   phy-handle = <_phy1>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e6000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e8000 {
+   phy-handle = <_phy1>;
+   phy-connection-type = "sgmii";
+   };
+
+   ethernet@ea000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "sgmii";
+   };
+
+   ethernet@f { /* 10GEC1 */
+   phy-handle = <_phy>;
+   phy-connection-type = "xgmii";
+   };
+
+   ethernet@f2000 { /* 10GEC2 */
+   fixed-link = <0 1 1000 0 0>;
+   phy-connection-type = "xgmii";
+   };
+
+   mdio@fc000 {
+   rgmii_phy1: ethernet-phy@1 {
+   reg = <0x1>;
+   };
+
+   rgmii_phy2: ethernet-phy@2 {
+   reg = <0x2>;
+   };
+
+   sgmii_phy1: ethernet-phy@3 {
+   reg = <0x3>;
+   };
+
+   sgmii_phy2: ethernet-phy@4 {
+   reg = <0x4>;
+   };
+   };
+
+   mdio@fd000 {
+   aqr106_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c45";
+   interrupts = <0 131 4>;
+   reg = <0x0>;
+   };
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..7aef0d8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -54,6 +54,15 @@
 
aliases {
crypto = 
+   fman0 = 
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   ethernet3 = 
+   ethernet4 = 
+   ethernet5 = 
+   ethernet6 = 
+   ethernet7 = 
};
 
cpus {
@@ -172,7 +181,7 @@
 IRQ_TYPE_LEVEL_LOW)>;
};
 
-   soc {
+   soc: soc {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
@@ -266,6 +275,18 @@
};
};
 
+   qman: qman@188 {
+   compatible = "fsl,qman";
+   reg = <0x00 0x188 0x0 

[PATCH 2/2] dts: arm64: add LS1046A DPAA support

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi | 37 
 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts  |  2 +
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts  | 62 
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 66 -
 .../boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi| 68 ++
 5 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
new file mode 100644
index 000..cb2e4a3
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
@@ -0,0 +1,37 @@
+ {
+
+/include/ "qoriq-fman3-0.dtsi"
+/include/ "qoriq-fman3-0-1g-0.dtsi"
+/include/ "qoriq-fman3-0-1g-1.dtsi"
+/include/ "qoriq-fman3-0-1g-2.dtsi"
+/include/ "qoriq-fman3-0-1g-3.dtsi"
+/include/ "qoriq-fman3-0-1g-4.dtsi"
+/include/ "qoriq-fman3-0-1g-5.dtsi"
+/include/ "qoriq-fman3-0-10g-0.dtsi"
+/include/ "qoriq-fman3-0-10g-1.dtsi"
+   fman@1a0 {
+   enet0: ethernet@e {
+   };
+
+   enet1: ethernet@e2000 {
+   };
+
+   enet2: ethernet@e4000 {
+   };
+
+   enet3: ethernet@e6000 {
+   };
+
+   enet4: ethernet@e8000 {
+   };
+
+   enet5: ethernet@ea000 {
+   };
+
+   enet6: ethernet@f {
+   };
+
+   enet7: ethernet@f2000 {
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index 290e5b0..ccd3948 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -210,3 +210,5 @@
reg = <0>;
};
 };
+
+/include/ "fsl-ls1046-post.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index d1ccc00..78d5609 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -148,3 +148,65 @@
reg = <1>;
};
 };
+
+/include/ "fsl-ls1046-post.dtsi"
+
+ {
+   fman@1a0 {
+   ethernet@e4000 {
+   phy-handle = <_phy1>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e6000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "rgmii";
+   };
+
+   ethernet@e8000 {
+   phy-handle = <_phy1>;
+   phy-connection-type = "sgmii";
+   };
+
+   ethernet@ea000 {
+   phy-handle = <_phy2>;
+   phy-connection-type = "sgmii";
+   };
+
+   ethernet@f { /* 10GEC1 */
+   phy-handle = <_phy>;
+   phy-connection-type = "xgmii";
+   };
+
+   ethernet@f2000 { /* 10GEC2 */
+   fixed-link = <0 1 1000 0 0>;
+   phy-connection-type = "xgmii";
+   };
+
+   mdio@fc000 {
+   rgmii_phy1: ethernet-phy@1 {
+   reg = <0x1>;
+   };
+
+   rgmii_phy2: ethernet-phy@2 {
+   reg = <0x2>;
+   };
+
+   sgmii_phy1: ethernet-phy@3 {
+   reg = <0x3>;
+   };
+
+   sgmii_phy2: ethernet-phy@4 {
+   reg = <0x4>;
+   };
+   };
+
+   mdio@fd000 {
+   aqr106_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c45";
+   interrupts = <0 131 4>;
+   reg = <0x0>;
+   };
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..7aef0d8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -54,6 +54,15 @@
 
aliases {
crypto = 
+   fman0 = 
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   ethernet3 = 
+   ethernet4 = 
+   ethernet5 = 
+   ethernet6 = 
+   ethernet7 = 
};
 
cpus {
@@ -172,7 +181,7 @@
 IRQ_TYPE_LEVEL_LOW)>;
};
 
-   soc {
+   soc: soc {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
@@ -266,6 +275,18 @@
};
};
 
+   qman: qman@188 {
+   compatible = "fsl,qman";
+   reg = <0x00 0x188 0x0 0x1>;
+   

[tip:irq/urgent] irqdomain: Avoid activating interrupts more than once

[tip-bot for Marc Zyngier]

Commit-ID:  08d85f3ea99f1eeafc4e8507936190e86a16ee8c
Gitweb: http://git.kernel.org/tip/08d85f3ea99f1eeafc4e8507936190e86a16ee8c
Author: Marc Zyngier 
AuthorDate: Tue, 17 Jan 2017 16:00:48 +
Committer:  Thomas Gleixner 
CommitDate: Mon, 30 Jan 2017 15:18:56 +0100

irqdomain: Avoid activating interrupts more than once

Since commit f3b0946d629c ("genirq/msi: Make sure PCI MSIs are
activated early"), we can end-up activating a PCI/MSI twice (once
at allocation time, and once at startup time).

This is normally of no consequences, except that there is some
HW out there that may misbehave if activate is used more than once
(the GICv3 ITS, for example, uses the activate callback
to issue the MAPVI command, and the architecture spec says that
"If there is an existing mapping for the EventID-DeviceID
combination, behavior is UNPREDICTABLE").

While this could be worked around in each individual driver, it may
make more sense to tackle the issue at the core level. In order to
avoid getting in that situation, let's have a per-interrupt flag
to remember if we have already activated that interrupt or not.

Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-and-tested-by: Andre Przywara 
Signed-off-by: Marc Zyngier 
Cc: sta...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner 

---
 include/linux/irq.h| 17 +
 kernel/irq/irqdomain.c | 44 ++--
 2 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index e798755..39e3254 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -184,6 +184,7 @@ struct irq_data {
  *
  * IRQD_TRIGGER_MASK   - Mask for the trigger type bits
  * IRQD_SETAFFINITY_PENDING- Affinity setting is pending
+ * IRQD_ACTIVATED  - Interrupt has already been activated
  * IRQD_NO_BALANCING   - Balancing disabled for this IRQ
  * IRQD_PER_CPU- Interrupt is per cpu
  * IRQD_AFFINITY_SET   - Interrupt affinity was set
@@ -202,6 +203,7 @@ struct irq_data {
 enum {
IRQD_TRIGGER_MASK   = 0xf,
IRQD_SETAFFINITY_PENDING= (1 <<  8),
+   IRQD_ACTIVATED  = (1 <<  9),
IRQD_NO_BALANCING   = (1 << 10),
IRQD_PER_CPU= (1 << 11),
IRQD_AFFINITY_SET   = (1 << 12),
@@ -312,6 +314,21 @@ static inline bool irqd_affinity_is_managed(struct 
irq_data *d)
return __irqd_to_state(d) & IRQD_AFFINITY_MANAGED;
 }
 
+static inline bool irqd_is_activated(struct irq_data *d)
+{
+   return __irqd_to_state(d) & IRQD_ACTIVATED;
+}
+
+static inline void irqd_set_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) |= IRQD_ACTIVATED;
+}
+
+static inline void irqd_clr_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) &= ~IRQD_ACTIVATED;
+}
+
 #undef __irqd_to_state
 
 static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8c0a0ae..b59e676 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1346,6 +1346,30 @@ void irq_domain_free_irqs_parent(struct irq_domain 
*domain,
 }
 EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
 
+static void __irq_domain_activate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (irq_data->parent_data)
+   __irq_domain_activate_irq(irq_data->parent_data);
+   if (domain->ops->activate)
+   domain->ops->activate(domain, irq_data);
+   }
+}
+
+static void __irq_domain_deactivate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (domain->ops->deactivate)
+   domain->ops->deactivate(domain, irq_data);
+   if (irq_data->parent_data)
+   __irq_domain_deactivate_irq(irq_data->parent_data);
+   }
+}
+
 /**
  * irq_domain_activate_irq - Call domain_ops->activate recursively to activate
  *  interrupt
@@ -1356,13 +1380,9 @@ EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
  */
 void irq_domain_activate_irq(struct irq_data *irq_data)
 {
-   if (irq_data && irq_data->domain) {
-   struct irq_domain *domain = irq_data->domain;
-
-   if (irq_data->parent_data)
-   irq_domain_activate_irq(irq_data->parent_data);
-   if (domain->ops->activate)
-   domain->ops->activate(domain, irq_data);
+   if (!irqd_is_activated(irq_data)) {
+   

[tip:irq/urgent] irqdomain: Avoid activating interrupts more than once

[tip-bot for Marc Zyngier]

Commit-ID:  08d85f3ea99f1eeafc4e8507936190e86a16ee8c
Gitweb: http://git.kernel.org/tip/08d85f3ea99f1eeafc4e8507936190e86a16ee8c
Author: Marc Zyngier 
AuthorDate: Tue, 17 Jan 2017 16:00:48 +
Committer:  Thomas Gleixner 
CommitDate: Mon, 30 Jan 2017 15:18:56 +0100

irqdomain: Avoid activating interrupts more than once

Since commit f3b0946d629c ("genirq/msi: Make sure PCI MSIs are
activated early"), we can end-up activating a PCI/MSI twice (once
at allocation time, and once at startup time).

This is normally of no consequences, except that there is some
HW out there that may misbehave if activate is used more than once
(the GICv3 ITS, for example, uses the activate callback
to issue the MAPVI command, and the architecture spec says that
"If there is an existing mapping for the EventID-DeviceID
combination, behavior is UNPREDICTABLE").

While this could be worked around in each individual driver, it may
make more sense to tackle the issue at the core level. In order to
avoid getting in that situation, let's have a per-interrupt flag
to remember if we have already activated that interrupt or not.

Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-and-tested-by: Andre Przywara 
Signed-off-by: Marc Zyngier 
Cc: sta...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner 

---
 include/linux/irq.h| 17 +
 kernel/irq/irqdomain.c | 44 ++--
 2 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index e798755..39e3254 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -184,6 +184,7 @@ struct irq_data {
  *
  * IRQD_TRIGGER_MASK   - Mask for the trigger type bits
  * IRQD_SETAFFINITY_PENDING- Affinity setting is pending
+ * IRQD_ACTIVATED  - Interrupt has already been activated
  * IRQD_NO_BALANCING   - Balancing disabled for this IRQ
  * IRQD_PER_CPU- Interrupt is per cpu
  * IRQD_AFFINITY_SET   - Interrupt affinity was set
@@ -202,6 +203,7 @@ struct irq_data {
 enum {
IRQD_TRIGGER_MASK   = 0xf,
IRQD_SETAFFINITY_PENDING= (1 <<  8),
+   IRQD_ACTIVATED  = (1 <<  9),
IRQD_NO_BALANCING   = (1 << 10),
IRQD_PER_CPU= (1 << 11),
IRQD_AFFINITY_SET   = (1 << 12),
@@ -312,6 +314,21 @@ static inline bool irqd_affinity_is_managed(struct 
irq_data *d)
return __irqd_to_state(d) & IRQD_AFFINITY_MANAGED;
 }
 
+static inline bool irqd_is_activated(struct irq_data *d)
+{
+   return __irqd_to_state(d) & IRQD_ACTIVATED;
+}
+
+static inline void irqd_set_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) |= IRQD_ACTIVATED;
+}
+
+static inline void irqd_clr_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) &= ~IRQD_ACTIVATED;
+}
+
 #undef __irqd_to_state
 
 static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8c0a0ae..b59e676 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1346,6 +1346,30 @@ void irq_domain_free_irqs_parent(struct irq_domain 
*domain,
 }
 EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
 
+static void __irq_domain_activate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (irq_data->parent_data)
+   __irq_domain_activate_irq(irq_data->parent_data);
+   if (domain->ops->activate)
+   domain->ops->activate(domain, irq_data);
+   }
+}
+
+static void __irq_domain_deactivate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (domain->ops->deactivate)
+   domain->ops->deactivate(domain, irq_data);
+   if (irq_data->parent_data)
+   __irq_domain_deactivate_irq(irq_data->parent_data);
+   }
+}
+
 /**
  * irq_domain_activate_irq - Call domain_ops->activate recursively to activate
  *  interrupt
@@ -1356,13 +1380,9 @@ EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
  */
 void irq_domain_activate_irq(struct irq_data *irq_data)
 {
-   if (irq_data && irq_data->domain) {
-   struct irq_domain *domain = irq_data->domain;
-
-   if (irq_data->parent_data)
-   irq_domain_activate_irq(irq_data->parent_data);
-   if (domain->ops->activate)
-   domain->ops->activate(domain, irq_data);
+   if (!irqd_is_activated(irq_data)) {
+   __irq_domain_activate_irq(irq_data);
+   irqd_set_activated(irq_data);
}
 }
 
@@ -1376,13 

RE: ibmvtpm byteswapping inconsistency

[David Laight]

From: Tyrel Datwyler
> Sent: 27 January 2017 18:03
> On 01/26/2017 05:50 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote:
> >> On 01/26/2017 12:22 PM, Michal Suchnek wrote:
> >>> Hello,
> >>>
> >>> building ibmvtpm I noticed gcc warning complaining that second word
> >>> of
> >>> struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized.
> >>>
> >>> The structure is defined as
> >>>
> >>> struct ibmvtpm_crq {
> >>> u8 valid;
> >>> u8 msg;
> >>> __be16 len;
> >>> __be32 data;
> >>> __be64 reserved;
> >>> } __attribute__((packed, aligned(8)));
> >>>
> >>> initialized as
> >>>
> >>> struct ibmvtpm_crq crq;
> >>> u64 *buf = (u64 *) 
> >>> ...
> >>> crq.valid = (u8)IBMVTPM_VALID_CMD;
> >>> crq.msg = (u8)VTPM_PREPARE_TO_SUSPEND;
> >>>
> >>> and submitted with
> >>>
> >>> rc = ibmvtpm_send_crq(ibmvtpm->vdev, cpu_to_be64(buf[0]),
> >>>   cpu_to_be64(buf[1]));

Isn't the real fubar here the use of that memory layout structure at all?
It would probably all be better if the call looked like:
rc = ibmvtpm_send_crq(ibmvtpm->vdev, MAKE_REQ(IBMVTPM_VALID_CMD,
VTPM_PREPARE_TO_SUSPEND, xxx_len, xxx_data), 0);
and MAKE_REQ() did all the required endian independant shifts to generate
the correct 32bit value.

David

RE: ibmvtpm byteswapping inconsistency

[David Laight]

From: Tyrel Datwyler
> Sent: 27 January 2017 18:03
> On 01/26/2017 05:50 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote:
> >> On 01/26/2017 12:22 PM, Michal Suchnek wrote:
> >>> Hello,
> >>>
> >>> building ibmvtpm I noticed gcc warning complaining that second word
> >>> of
> >>> struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized.
> >>>
> >>> The structure is defined as
> >>>
> >>> struct ibmvtpm_crq {
> >>> u8 valid;
> >>> u8 msg;
> >>> __be16 len;
> >>> __be32 data;
> >>> __be64 reserved;
> >>> } __attribute__((packed, aligned(8)));
> >>>
> >>> initialized as
> >>>
> >>> struct ibmvtpm_crq crq;
> >>> u64 *buf = (u64 *) 
> >>> ...
> >>> crq.valid = (u8)IBMVTPM_VALID_CMD;
> >>> crq.msg = (u8)VTPM_PREPARE_TO_SUSPEND;
> >>>
> >>> and submitted with
> >>>
> >>> rc = ibmvtpm_send_crq(ibmvtpm->vdev, cpu_to_be64(buf[0]),
> >>>   cpu_to_be64(buf[1]));

Isn't the real fubar here the use of that memory layout structure at all?
It would probably all be better if the call looked like:
rc = ibmvtpm_send_crq(ibmvtpm->vdev, MAKE_REQ(IBMVTPM_VALID_CMD,
VTPM_PREPARE_TO_SUSPEND, xxx_len, xxx_data), 0);
and MAKE_REQ() did all the required endian independant shifts to generate
the correct 32bit value.

David

[PATCH 3/5] Documentation: dt: iio: document stm32 exti trigger

[Fabrice Gasnier]

Add dt documentation for st,stm32-exti-trigger.
EXTi gpio signal can be routed internally as trigger source for various
IPs (e.g. for ADC or DAC conversions).

Signed-off-by: Fabrice Gasnier 
---
 .../bindings/iio/trigger/st,stm32-exti-trigger.txt  | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt

diff --git 
a/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt 
b/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
new file mode 100644
index 000..ebf2645
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
@@ -0,0 +1,17 @@
+STMicroelectronics STM32 EXTI trigger bindings
+
+EXTi gpio signal can be routed internally as trigger source for various
+IPs (e.g. for ADC or DAC conversions).
+
+Contents of a stm32 exti trigger root node:
+---
+Required properties:
+- compatible: Should be "st,stm32-exti-trigger"
+- extiN-gpio: optional gpio line that may be used as external trigger source
+  (e.g. N may be 0..15. For example, exti11-gpio can trig ADC on stm32f4).
+
+Example:
+   triggers {
+   compatible = "st,stm32-exti-trigger";
+   exti11-gpio=< 11 0>;
+   };
-- 
1.9.1

[PATCH 3/5] Documentation: dt: iio: document stm32 exti trigger

[Fabrice Gasnier]

Add dt documentation for st,stm32-exti-trigger.
EXTi gpio signal can be routed internally as trigger source for various
IPs (e.g. for ADC or DAC conversions).

Signed-off-by: Fabrice Gasnier 
---
 .../bindings/iio/trigger/st,stm32-exti-trigger.txt  | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt

diff --git 
a/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt 
b/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
new file mode 100644
index 000..ebf2645
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
@@ -0,0 +1,17 @@
+STMicroelectronics STM32 EXTI trigger bindings
+
+EXTi gpio signal can be routed internally as trigger source for various
+IPs (e.g. for ADC or DAC conversions).
+
+Contents of a stm32 exti trigger root node:
+---
+Required properties:
+- compatible: Should be "st,stm32-exti-trigger"
+- extiN-gpio: optional gpio line that may be used as external trigger source
+  (e.g. N may be 0..15. For example, exti11-gpio can trig ADC on stm32f4).
+
+Example:
+   triggers {
+   compatible = "st,stm32-exti-trigger";
+   exti11-gpio=< 11 0>;
+   };
-- 
1.9.1

[PATCH 3/5] gpio: 104-idio-16: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
idio_16_remove function. Now that the idio_16_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-104-idio-16.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
index 01a091e17614..67068b61b90b 100644
--- a/drivers/gpio/gpio-104-idio-16.c
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -242,8 +242,6 @@ static int idio_16_probe(struct device *dev, unsigned int 
id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, idio16gpio);
-
err = devm_gpiochip_add_data(dev, >chip, idio16gpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 3/5] gpio: 104-idio-16: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
idio_16_remove function. Now that the idio_16_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-104-idio-16.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
index 01a091e17614..67068b61b90b 100644
--- a/drivers/gpio/gpio-104-idio-16.c
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -242,8 +242,6 @@ static int idio_16_probe(struct device *dev, unsigned int 
id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, idio16gpio);
-
err = devm_gpiochip_add_data(dev, >chip, idio16gpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 2/5] gpio: 104-idi-48: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
idi_48_remove function. Now that the idi_48_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-104-idi-48.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index eafbf053f3e8..dc100dff6e13 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -246,8 +246,6 @@ static int idi_48_probe(struct device *dev, unsigned int id)
spin_lock_init(>lock);
spin_lock_init(>ack_lock);
 
-   dev_set_drvdata(dev, idi48gpio);
-
err = devm_gpiochip_add_data(dev, >chip, idi48gpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 2/5] gpio: 104-idi-48: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
idi_48_remove function. Now that the idi_48_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-104-idi-48.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index eafbf053f3e8..dc100dff6e13 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -246,8 +246,6 @@ static int idi_48_probe(struct device *dev, unsigned int id)
spin_lock_init(>lock);
spin_lock_init(>ack_lock);
 
-   dev_set_drvdata(dev, idi48gpio);
-
err = devm_gpiochip_add_data(dev, >chip, idi48gpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 1/5] gpio: 104-dio-48e: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
dio48e_remove function. Now that the dio48e_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-104-dio-48e.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index 221243f17d4e..b6b0378166c4 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -369,8 +369,6 @@ static int dio48e_probe(struct device *dev, unsigned int id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, dio48egpio);
-
err = devm_gpiochip_add_data(dev, >chip, dio48egpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 1/5] gpio: 104-dio-48e: Remove unnecessary driver_data set

[William Breathitt Gray]

Setting driver_data was necessary to access private data in the
dio48e_remove function. Now that the dio48e_remove function is gone,
driver_data is no longer used. This patch removes the relevant code.

Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/gpio-104-dio-48e.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index 221243f17d4e..b6b0378166c4 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -369,8 +369,6 @@ static int dio48e_probe(struct device *dev, unsigned int id)
 
spin_lock_init(>lock);
 
-   dev_set_drvdata(dev, dio48egpio);
-
err = devm_gpiochip_add_data(dev, >chip, dio48egpio);
if (err) {
dev_err(dev, "GPIO registering failed (%d)\n", err);
-- 
2.11.0

[PATCH 0/5] gpio: Remove unnecessary driver_data set operations

[William Breathitt Gray]

In a previous patchset ("gpio: Utilize devm_ functions in driver probe
callbacks") the device remove functions for several drivers were removed
as no longer necessary due to the patchset changes within. Setting
driver_data had been necessary in these drivers in order to access
private data in the respective device remove function. Now that the
device remove functions are gone, setting driver_data is no longer
necessary for these drivers. This patchset removes the relevant code.

William Breathitt Gray (5):
  gpio: 104-dio-48e: Remove unnecessary driver_data set
  gpio: 104-idi-48: Remove unnecessary driver_data set
  gpio: 104-idio-16: Remove unnecessary driver_data set
  gpio: gpio-mm: Remove unnecessary driver_data set
  gpio: ws16c48: Remove unnecessary driver_data set

 drivers/gpio/gpio-104-dio-48e.c | 2 --
 drivers/gpio/gpio-104-idi-48.c  | 2 --
 drivers/gpio/gpio-104-idio-16.c | 2 --
 drivers/gpio/gpio-gpio-mm.c | 2 --
 drivers/gpio/gpio-ws16c48.c | 2 --
 5 files changed, 10 deletions(-)

-- 
2.11.0

[PATCH 0/5] gpio: Remove unnecessary driver_data set operations

[William Breathitt Gray]

In a previous patchset ("gpio: Utilize devm_ functions in driver probe
callbacks") the device remove functions for several drivers were removed
as no longer necessary due to the patchset changes within. Setting
driver_data had been necessary in these drivers in order to access
private data in the respective device remove function. Now that the
device remove functions are gone, setting driver_data is no longer
necessary for these drivers. This patchset removes the relevant code.

William Breathitt Gray (5):
  gpio: 104-dio-48e: Remove unnecessary driver_data set
  gpio: 104-idi-48: Remove unnecessary driver_data set
  gpio: 104-idio-16: Remove unnecessary driver_data set
  gpio: gpio-mm: Remove unnecessary driver_data set
  gpio: ws16c48: Remove unnecessary driver_data set

 drivers/gpio/gpio-104-dio-48e.c | 2 --
 drivers/gpio/gpio-104-idi-48.c  | 2 --
 drivers/gpio/gpio-104-idio-16.c | 2 --
 drivers/gpio/gpio-gpio-mm.c | 2 --
 drivers/gpio/gpio-ws16c48.c | 2 --
 5 files changed, 10 deletions(-)

-- 
2.11.0

[PATCH v2 1/5] Documentation: dt: iio: document stm32 adc trigger polarity

[Fabrice Gasnier]

STM32 ADC trigger polarity can be set to either rising, falling
or both edges. Allow to configure it from dt.

Signed-off-by: Fabrice Gasnier 
---
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
index 5dfc88e..6c6d968 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
@@ -57,6 +57,8 @@ Optional properties:
 - dmas: Phandle to dma channel for this ADC instance.
   See ../../dma/dma.txt for details.
 - dma-names: Must be "rx" when dmas property is being used.
+- st,trigger-polarity: Must be 0 (default), 1 or 2 to set default trigger
+  polarity to respectively "rising-edge", "falling-edge" or "both-edges".
 
 Example:
adc: adc@40012000 {
@@ -84,6 +86,7 @@ Example:
st,adc-channels = <8>;
dmas = < 0 0 0x400 0x0>;
dma-names = "rx";
+   st,trigger-polarity = <1>;
};
...
other adc child nodes follow...
-- 
1.9.1

[PATCH v2 1/5] Documentation: dt: iio: document stm32 adc trigger polarity

[Fabrice Gasnier]

STM32 ADC trigger polarity can be set to either rising, falling
or both edges. Allow to configure it from dt.

Signed-off-by: Fabrice Gasnier 
---
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
index 5dfc88e..6c6d968 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
@@ -57,6 +57,8 @@ Optional properties:
 - dmas: Phandle to dma channel for this ADC instance.
   See ../../dma/dma.txt for details.
 - dma-names: Must be "rx" when dmas property is being used.
+- st,trigger-polarity: Must be 0 (default), 1 or 2 to set default trigger
+  polarity to respectively "rising-edge", "falling-edge" or "both-edges".
 
 Example:
adc: adc@40012000 {
@@ -84,6 +86,7 @@ Example:
st,adc-channels = <8>;
dmas = < 0 0 0x400 0x0>;
dma-names = "rx";
+   st,trigger-polarity = <1>;
};
...
other adc child nodes follow...
-- 
1.9.1