[DRAFT 1/2] mm/cpuset: Exclude CDM nodes from each task's mems_allowed node mask

[Anshuman Khandual]

task->mems_allowed decides the final node mask of nodes from which memory
can be allocated irrespective of process or VMA based memory policy. CDM
nodes should not be used for any user space memory allocation, hence they
should not be part of any mems_allowed mask in user space to begin with.
This adds a function system_ram() which computes system RAM only nodes
and excludes all the CDM nodes on the platform. This resultant system RAM
nodemask is used instead of N_MEMORY mask during cpuset and mems_allowed
initialization. This achieves isolation of the coherent device memory
from userspace allocations.

Signed-off-by: Anshuman Khandual 
---
This completely isolates CDM nodes from user space allocations. Hence
explicit allocation to the CDM nodes would not be possible any more.
To again enable explicit allocation capability from user space, cpuset
needs to be changed to accommodate CDM nodes into task's mems_allowed.

 include/linux/mm.h |  9 +
 kernel/cpuset.c| 12 +++-
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index a92c8d7..f338492 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -446,6 +446,15 @@ static inline int put_page_testzero(struct page *page)
return page_ref_dec_and_test(page);
 }
 
+static inline nodemask_t system_ram(void)
+{
+   nodemask_t ram_nodes;
+
+   nodes_clear(ram_nodes);
+   nodes_andnot(ram_nodes, node_states[N_MEMORY], 
node_states[N_COHERENT_DEVICE]);
+   return ram_nodes;
+}
+
 /*
  * Try to grab a ref unless the page has a refcount of zero, return false if
  * that is the case.
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 29f815d..78c6fa3 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -364,9 +364,11 @@ static void guarantee_online_cpus(struct cpuset *cs, 
struct cpumask *pmask)
  */
 static void guarantee_online_mems(struct cpuset *cs, nodemask_t *pmask)
 {
-   while (!nodes_intersects(cs->effective_mems, node_states[N_MEMORY]))
+   nodemask_t nodes = system_ram();
+
+   while (!nodes_intersects(cs->effective_mems, nodes))
cs = parent_cs(cs);
-   nodes_and(*pmask, cs->effective_mems, node_states[N_MEMORY]);
+   nodes_and(*pmask, cs->effective_mems, nodes);
 }
 
 /*
@@ -2301,7 +2303,7 @@ static void cpuset_hotplug_workfn(struct work_struct 
*work)
 
/* fetch the available cpus/mems and find out which changed how */
cpumask_copy(_cpus, cpu_active_mask);
-   new_mems = node_states[N_MEMORY];
+   new_mems = system_ram();
 
cpus_updated = !cpumask_equal(top_cpuset.effective_cpus, _cpus);
mems_updated = !nodes_equal(top_cpuset.effective_mems, new_mems);
@@ -2393,11 +2395,11 @@ static int cpuset_track_online_nodes(struct 
notifier_block *self,
 void __init cpuset_init_smp(void)
 {
cpumask_copy(top_cpuset.cpus_allowed, cpu_active_mask);
-   top_cpuset.mems_allowed = node_states[N_MEMORY];
+   top_cpuset.mems_allowed = system_ram();
top_cpuset.old_mems_allowed = top_cpuset.mems_allowed;
 
cpumask_copy(top_cpuset.effective_cpus, cpu_active_mask);
-   top_cpuset.effective_mems = node_states[N_MEMORY];
+   top_cpuset.effective_mems = system_ram();
 
register_hotmemory_notifier(_track_online_nodes_nb);
 
-- 
1.8.3.1

[DRAFT 2/2] mm/hugetlb: Restrict HugeTLB allocations only to the system RAM nodes

[Anshuman Khandual]

HugeTLB allocation/release/accounting currently spans across all the nodes
under N_MEMORY mask. CDM nodes should not be part of these. So use
system_ram() call to fetch system RAM only nodes on the platform which can
then be used for HugeTLB purpose instead of N_MEMORY. This isolates CDM
nodes from HugeTLB allocation.

Signed-off-by: Anshuman Khandual 
---
This also completely isolates CDM nodes from user space HugeTLB allocations
. Hence explicit allocation to the CDM nodes would not be possible any more
. To again enable explicit HugeTLB allocation capability from user space,
HugeTLB subsystem needs to be changed.

 mm/hugetlb.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 418bf01..1936c5a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1782,6 +1782,9 @@ static void return_unused_surplus_pages(struct hstate *h,
unsigned long unused_resv_pages)
 {
unsigned long nr_pages;
+   nodemask_t nodes;
+
+   nodes = system_ram();
 
/* Uncommit the reservation */
h->resv_huge_pages -= unused_resv_pages;
@@ -1801,7 +1804,7 @@ static void return_unused_surplus_pages(struct hstate *h,
 * on-line nodes with memory and will handle the hstate accounting.
 */
while (nr_pages--) {
-   if (!free_pool_huge_page(h, _states[N_MEMORY], 1))
+   if (!free_pool_huge_page(h, , 1))
break;
cond_resched_lock(_lock);
}
@@ -2088,8 +2091,10 @@ int __weak alloc_bootmem_huge_page(struct hstate *h)
 {
struct huge_bootmem_page *m;
int nr_nodes, node;
+   nodemask_t nodes;
 
-   for_each_node_mask_to_alloc(h, nr_nodes, node, _states[N_MEMORY]) {
+   nodes = system_ram();
+   for_each_node_mask_to_alloc(h, nr_nodes, node, ) {
void *addr;
 
addr = memblock_virt_alloc_try_nid_nopanic(
@@ -2158,13 +2163,15 @@ static void __init gather_bootmem_prealloc(void)
 static void __init hugetlb_hstate_alloc_pages(struct hstate *h)
 {
unsigned long i;
+   nodemask_t nodes;
+
 
+   nodes = system_ram();
for (i = 0; i < h->max_huge_pages; ++i) {
if (hstate_is_gigantic(h)) {
if (!alloc_bootmem_huge_page(h))
break;
-   } else if (!alloc_fresh_huge_page(h,
-_states[N_MEMORY]))
+   } else if (!alloc_fresh_huge_page(h, ))
break;
}
h->max_huge_pages = i;
@@ -2401,8 +2408,11 @@ static ssize_t __nr_hugepages_store_common(bool 
obey_mempolicy,
   unsigned long count, size_t len)
 {
int err;
+   nodemask_t ram_nodes;
+
NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
 
+   ram_nodes = system_ram();
if (hstate_is_gigantic(h) && !gigantic_page_supported()) {
err = -EINVAL;
goto out;
@@ -2415,7 +2425,7 @@ static ssize_t __nr_hugepages_store_common(bool 
obey_mempolicy,
if (!(obey_mempolicy &&
init_nodemask_of_mempolicy(nodes_allowed))) {
NODEMASK_FREE(nodes_allowed);
-   nodes_allowed = _states[N_MEMORY];
+   nodes_allowed = _nodes;
}
} else if (nodes_allowed) {
/*
@@ -2425,11 +2435,11 @@ static ssize_t __nr_hugepages_store_common(bool 
obey_mempolicy,
count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
init_nodemask_of_node(nodes_allowed, nid);
} else
-   nodes_allowed = _states[N_MEMORY];
+   nodes_allowed = _nodes;
 
h->max_huge_pages = set_max_huge_pages(h, count, nodes_allowed);
 
-   if (nodes_allowed != _states[N_MEMORY])
+   if (nodes_allowed != _nodes)
NODEMASK_FREE(nodes_allowed);
 
return len;
@@ -2726,9 +2736,11 @@ static void hugetlb_register_node(struct node *node)
  */
 static void __init hugetlb_register_all_nodes(void)
 {
+   nodemask_t nodes;
int nid;
 
-   for_each_node_state(nid, N_MEMORY) {
+   nodes = system_ram();
+   for_each_node_mask(nid, nodes) {
struct node *node = node_devices[nid];
if (node->dev.id == nid)
hugetlb_register_node(node);
@@ -2998,13 +3010,15 @@ int hugetlb_report_node_meminfo(int nid, char *buf)
 
 void hugetlb_show_meminfo(void)
 {
+   nodemask_t nodes;
struct hstate *h;
int nid;
 
if (!hugepages_supported())
return;
 
-   for_each_node_state(nid, N_MEMORY)
+   nodes = system_ram();
+   for_each_node_mask(nid, nodes)
for_each_hstate(h)
   

[DRAFT 1/2] mm/cpuset: Exclude CDM nodes from each task's mems_allowed node mask

[Anshuman Khandual]

task->mems_allowed decides the final node mask of nodes from which memory
can be allocated irrespective of process or VMA based memory policy. CDM
nodes should not be used for any user space memory allocation, hence they
should not be part of any mems_allowed mask in user space to begin with.
This adds a function system_ram() which computes system RAM only nodes
and excludes all the CDM nodes on the platform. This resultant system RAM
nodemask is used instead of N_MEMORY mask during cpuset and mems_allowed
initialization. This achieves isolation of the coherent device memory
from userspace allocations.

Signed-off-by: Anshuman Khandual 
---
This completely isolates CDM nodes from user space allocations. Hence
explicit allocation to the CDM nodes would not be possible any more.
To again enable explicit allocation capability from user space, cpuset
needs to be changed to accommodate CDM nodes into task's mems_allowed.

 include/linux/mm.h |  9 +
 kernel/cpuset.c| 12 +++-
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index a92c8d7..f338492 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -446,6 +446,15 @@ static inline int put_page_testzero(struct page *page)
return page_ref_dec_and_test(page);
 }
 
+static inline nodemask_t system_ram(void)
+{
+   nodemask_t ram_nodes;
+
+   nodes_clear(ram_nodes);
+   nodes_andnot(ram_nodes, node_states[N_MEMORY], 
node_states[N_COHERENT_DEVICE]);
+   return ram_nodes;
+}
+
 /*
  * Try to grab a ref unless the page has a refcount of zero, return false if
  * that is the case.
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 29f815d..78c6fa3 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -364,9 +364,11 @@ static void guarantee_online_cpus(struct cpuset *cs, 
struct cpumask *pmask)
  */
 static void guarantee_online_mems(struct cpuset *cs, nodemask_t *pmask)
 {
-   while (!nodes_intersects(cs->effective_mems, node_states[N_MEMORY]))
+   nodemask_t nodes = system_ram();
+
+   while (!nodes_intersects(cs->effective_mems, nodes))
cs = parent_cs(cs);
-   nodes_and(*pmask, cs->effective_mems, node_states[N_MEMORY]);
+   nodes_and(*pmask, cs->effective_mems, nodes);
 }
 
 /*
@@ -2301,7 +2303,7 @@ static void cpuset_hotplug_workfn(struct work_struct 
*work)
 
/* fetch the available cpus/mems and find out which changed how */
cpumask_copy(_cpus, cpu_active_mask);
-   new_mems = node_states[N_MEMORY];
+   new_mems = system_ram();
 
cpus_updated = !cpumask_equal(top_cpuset.effective_cpus, _cpus);
mems_updated = !nodes_equal(top_cpuset.effective_mems, new_mems);
@@ -2393,11 +2395,11 @@ static int cpuset_track_online_nodes(struct 
notifier_block *self,
 void __init cpuset_init_smp(void)
 {
cpumask_copy(top_cpuset.cpus_allowed, cpu_active_mask);
-   top_cpuset.mems_allowed = node_states[N_MEMORY];
+   top_cpuset.mems_allowed = system_ram();
top_cpuset.old_mems_allowed = top_cpuset.mems_allowed;
 
cpumask_copy(top_cpuset.effective_cpus, cpu_active_mask);
-   top_cpuset.effective_mems = node_states[N_MEMORY];
+   top_cpuset.effective_mems = system_ram();
 
register_hotmemory_notifier(_track_online_nodes_nb);
 
-- 
1.8.3.1

[DRAFT 2/2] mm/hugetlb: Restrict HugeTLB allocations only to the system RAM nodes

[Anshuman Khandual]

HugeTLB allocation/release/accounting currently spans across all the nodes
under N_MEMORY mask. CDM nodes should not be part of these. So use
system_ram() call to fetch system RAM only nodes on the platform which can
then be used for HugeTLB purpose instead of N_MEMORY. This isolates CDM
nodes from HugeTLB allocation.

Signed-off-by: Anshuman Khandual 
---
This also completely isolates CDM nodes from user space HugeTLB allocations
. Hence explicit allocation to the CDM nodes would not be possible any more
. To again enable explicit HugeTLB allocation capability from user space,
HugeTLB subsystem needs to be changed.

 mm/hugetlb.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 418bf01..1936c5a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1782,6 +1782,9 @@ static void return_unused_surplus_pages(struct hstate *h,
unsigned long unused_resv_pages)
 {
unsigned long nr_pages;
+   nodemask_t nodes;
+
+   nodes = system_ram();
 
/* Uncommit the reservation */
h->resv_huge_pages -= unused_resv_pages;
@@ -1801,7 +1804,7 @@ static void return_unused_surplus_pages(struct hstate *h,
 * on-line nodes with memory and will handle the hstate accounting.
 */
while (nr_pages--) {
-   if (!free_pool_huge_page(h, _states[N_MEMORY], 1))
+   if (!free_pool_huge_page(h, , 1))
break;
cond_resched_lock(_lock);
}
@@ -2088,8 +2091,10 @@ int __weak alloc_bootmem_huge_page(struct hstate *h)
 {
struct huge_bootmem_page *m;
int nr_nodes, node;
+   nodemask_t nodes;
 
-   for_each_node_mask_to_alloc(h, nr_nodes, node, _states[N_MEMORY]) {
+   nodes = system_ram();
+   for_each_node_mask_to_alloc(h, nr_nodes, node, ) {
void *addr;
 
addr = memblock_virt_alloc_try_nid_nopanic(
@@ -2158,13 +2163,15 @@ static void __init gather_bootmem_prealloc(void)
 static void __init hugetlb_hstate_alloc_pages(struct hstate *h)
 {
unsigned long i;
+   nodemask_t nodes;
+
 
+   nodes = system_ram();
for (i = 0; i < h->max_huge_pages; ++i) {
if (hstate_is_gigantic(h)) {
if (!alloc_bootmem_huge_page(h))
break;
-   } else if (!alloc_fresh_huge_page(h,
-_states[N_MEMORY]))
+   } else if (!alloc_fresh_huge_page(h, ))
break;
}
h->max_huge_pages = i;
@@ -2401,8 +2408,11 @@ static ssize_t __nr_hugepages_store_common(bool 
obey_mempolicy,
   unsigned long count, size_t len)
 {
int err;
+   nodemask_t ram_nodes;
+
NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
 
+   ram_nodes = system_ram();
if (hstate_is_gigantic(h) && !gigantic_page_supported()) {
err = -EINVAL;
goto out;
@@ -2415,7 +2425,7 @@ static ssize_t __nr_hugepages_store_common(bool 
obey_mempolicy,
if (!(obey_mempolicy &&
init_nodemask_of_mempolicy(nodes_allowed))) {
NODEMASK_FREE(nodes_allowed);
-   nodes_allowed = _states[N_MEMORY];
+   nodes_allowed = _nodes;
}
} else if (nodes_allowed) {
/*
@@ -2425,11 +2435,11 @@ static ssize_t __nr_hugepages_store_common(bool 
obey_mempolicy,
count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
init_nodemask_of_node(nodes_allowed, nid);
} else
-   nodes_allowed = _states[N_MEMORY];
+   nodes_allowed = _nodes;
 
h->max_huge_pages = set_max_huge_pages(h, count, nodes_allowed);
 
-   if (nodes_allowed != _states[N_MEMORY])
+   if (nodes_allowed != _nodes)
NODEMASK_FREE(nodes_allowed);
 
return len;
@@ -2726,9 +2736,11 @@ static void hugetlb_register_node(struct node *node)
  */
 static void __init hugetlb_register_all_nodes(void)
 {
+   nodemask_t nodes;
int nid;
 
-   for_each_node_state(nid, N_MEMORY) {
+   nodes = system_ram();
+   for_each_node_mask(nid, nodes) {
struct node *node = node_devices[nid];
if (node->dev.id == nid)
hugetlb_register_node(node);
@@ -2998,13 +3010,15 @@ int hugetlb_report_node_meminfo(int nid, char *buf)
 
 void hugetlb_show_meminfo(void)
 {
+   nodemask_t nodes;
struct hstate *h;
int nid;
 
if (!hugepages_supported())
return;
 
-   for_each_node_state(nid, N_MEMORY)
+   nodes = system_ram();
+   for_each_node_mask(nid, nodes)
for_each_hstate(h)
pr_info("Node %d 

Re: [PATCH v2 0/7] mtd: nand: Abstract away the NAND interface type

[Boris Brezillon]

Hi Peter,

On Thu, 17 Nov 2016 14:26:37 +0800
Peter Pan  wrote:

> Hi Boris,
> 
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>  wrote:
> > Hi,
> >
> > This series is aiming at providing a generic NAND layer to share code
> > between different NAND based devices.
> >
> > We currently have 3 different interfaces to interact with NANDs:
> > - Raw NANDs
> > - OneNANDs
> > - SPI NANDs
> >
> > Apart from the way these NAND devices are accessed they have a lot
> > in common, like the way the memory is organized, or their constraints.
> > This is usually a good sign that some work should be done to factorize
> > the code.
> >
> > This work has been started by Peter who wanted to re-use the BBT
> > code for its SPI-NAND driver. But I think we can push it further
> > other stuff (the software ECC implementation, or the way offsets are
> > converted to block/page number).
> >
> > Peter, can you please review/test this version, and if possible, post
> > the code you've done to support SPI NANDs.
> >  
> 
> I already finished review and test work. The BBT works well after I applied
> my modification which I already sent to your by email. I tried to build a new
> BBT on a new NAND and then mark one block to bad. Both works well.
> My test platform is Xilinx Zed board.

Thanks a lot for testing and reviewing this series. I'll address your
comments and send a new version soon.

My plan is to have it in -next just after 4.10-rc1 is released, in order
to detect bugs early.

> 
> I will try to rebase my SPI NAND patch on your patch and send it out.
> It will take me some time because I'm quite busy with other company affairs.

I'd be happy to review this part.

Regards,

Boris

Re: [PATCH v2 0/7] mtd: nand: Abstract away the NAND interface type

[Boris Brezillon]

Hi Peter,

On Thu, 17 Nov 2016 14:26:37 +0800
Peter Pan  wrote:

> Hi Boris,
> 
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>  wrote:
> > Hi,
> >
> > This series is aiming at providing a generic NAND layer to share code
> > between different NAND based devices.
> >
> > We currently have 3 different interfaces to interact with NANDs:
> > - Raw NANDs
> > - OneNANDs
> > - SPI NANDs
> >
> > Apart from the way these NAND devices are accessed they have a lot
> > in common, like the way the memory is organized, or their constraints.
> > This is usually a good sign that some work should be done to factorize
> > the code.
> >
> > This work has been started by Peter who wanted to re-use the BBT
> > code for its SPI-NAND driver. But I think we can push it further
> > other stuff (the software ECC implementation, or the way offsets are
> > converted to block/page number).
> >
> > Peter, can you please review/test this version, and if possible, post
> > the code you've done to support SPI NANDs.
> >  
> 
> I already finished review and test work. The BBT works well after I applied
> my modification which I already sent to your by email. I tried to build a new
> BBT on a new NAND and then mark one block to bad. Both works well.
> My test platform is Xilinx Zed board.

Thanks a lot for testing and reviewing this series. I'll address your
comments and send a new version soon.

My plan is to have it in -next just after 4.10-rc1 is released, in order
to detect bugs early.

> 
> I will try to rebase my SPI NAND patch on your patch and send it out.
> It will take me some time because I'm quite busy with other company affairs.

I'd be happy to review this part.

Regards,

Boris

Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Chen-Yu Tsai]

On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja  wrote:
> Hi,
>
> Thanks for the patch.
>
>
> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> Acked-by: Rob Herring 
>> ---
>>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35
>> ++
>>  2 files changed, 37 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>>  - Video port 0 for RGB input
>>  - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>>  Example
>>  ---
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..15b549f94307 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connectorconnector;
>>
>> struct i2c_adapter  *ddc;
>> +   struct regulator*vdd;
>>  };
>>
>>  static inline struct dumb_vga *
>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>>  }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +   int ret = 0;
>> +
>> +   if (vga->vdd)
>> +   ret = regulator_enable(vga->vdd);
>> +
>> +   if (ret) {
>> +   DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> +   return;
>
>
> We don't need this return for now. If you're okay with it, can I fix this
> and queue to misc?

Yes, please!

Thanks
ChenYu

>
> Thanks,
> Archit
>
>
>> +   }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> +   if (vga->vdd)
>> +   regulator_disable(vga->vdd);
>> +}
>> +
>>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> +   .enable = dumb_vga_enable,
>> +   .disable= dumb_vga_disable,
>>  };
>>
>>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> +   vga->vdd = devm_regulator_get_optional(>dev, "vdd");
>> +   if (IS_ERR(vga->vdd)) {
>> +   ret = PTR_ERR(vga->vdd);
>> +   if (ret == -EPROBE_DEFER)
>> +   return -EPROBE_DEFER;
>> +   vga->vdd = NULL;
>> +   dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>> +   }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(>dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Chen-Yu Tsai]

On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja  wrote:
> Hi,
>
> Thanks for the patch.
>
>
> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> Acked-by: Rob Herring 
>> ---
>>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35
>> ++
>>  2 files changed, 37 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>>  - Video port 0 for RGB input
>>  - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>>  Example
>>  ---
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..15b549f94307 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connectorconnector;
>>
>> struct i2c_adapter  *ddc;
>> +   struct regulator*vdd;
>>  };
>>
>>  static inline struct dumb_vga *
>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>>  }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +   int ret = 0;
>> +
>> +   if (vga->vdd)
>> +   ret = regulator_enable(vga->vdd);
>> +
>> +   if (ret) {
>> +   DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> +   return;
>
>
> We don't need this return for now. If you're okay with it, can I fix this
> and queue to misc?

Yes, please!

Thanks
ChenYu

>
> Thanks,
> Archit
>
>
>> +   }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> +   if (vga->vdd)
>> +   regulator_disable(vga->vdd);
>> +}
>> +
>>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> +   .enable = dumb_vga_enable,
>> +   .disable= dumb_vga_disable,
>>  };
>>
>>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> +   vga->vdd = devm_regulator_get_optional(>dev, "vdd");
>> +   if (IS_ERR(vga->vdd)) {
>> +   ret = PTR_ERR(vga->vdd);
>> +   if (ret == -EPROBE_DEFER)
>> +   return -EPROBE_DEFER;
>> +   vga->vdd = NULL;
>> +   dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>> +   }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(>dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH 1/2] kcov: size of arena is now given in bytes.

[Dmitry Vyukov]

On Wed, Nov 16, 2016 at 10:27 PM, Quentin Casasnovas
 wrote:
> We'll introduce a different mode of tracing a-la AFL fixed table and Dmitry
> suggests that the code would be simpler with the size expressed in bytes as
> opposed unsigned longs.
>
> We only change the kcov::size field, which will be shared between different
> modes, but leave the task_struct::kcov_size field expressed in unsigned
> long in order to save an unecessary bitshift/division in the hot path when
> using KCOV_MODE_TRACE.


Thanks!

Reviewed-and-tested-by: Dmitry Vyukov 

I've tested that KCOV_MODE_TRACE works for me with these two patches applied.

> but leave the task_struct::kcov_size field expressed in unsigned long

The only purpose of the cache in task struct is to make coverage fast
path fast, so this looks good to me.



> Cc: Dmitry Vyukov 
> Cc: Michal Zalewski 
> Cc: Kees Cook 
> Signed-off-by: Quentin Casasnovas 
> Signed-off-by: Vegard Nossum 
> ---
>  kernel/kcov.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index 30e6d05aa5a9..c2aa93851f93 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -32,7 +32,7 @@ struct kcov {
> /* The lock protects mode, size, area and t. */
> spinlock_t  lock;
> enum kcov_mode  mode;
> -   /* Size of arena (in long's for KCOV_MODE_TRACE). */
> +   /* Size of arena in bytes. */
> unsignedsize;
> /* Coverage buffer shared with user space. */
> void*area;
> @@ -140,7 +140,7 @@ static int kcov_mmap(struct file *filep, struct 
> vm_area_struct *vma)
> return -ENOMEM;
>
> spin_lock(>lock);
> -   size = kcov->size * sizeof(unsigned long);
> +   size = kcov->size;
> if (kcov->mode == KCOV_MODE_DISABLED || vma->vm_pgoff != 0 ||
> vma->vm_end - vma->vm_start != size) {
> res = -EINVAL;
> @@ -198,13 +198,11 @@ static int kcov_ioctl_locked(struct kcov *kcov, 
> unsigned int cmd,
> return -EBUSY;
> /*
>  * Size must be at least 2 to hold current position and one 
> PC.
> -* Later we allocate size * sizeof(unsigned long) memory,
> -* that must not overflow.
>  */
> size = arg;
> if (size < 2 || size > INT_MAX / sizeof(unsigned long))
> return -EINVAL;
> -   kcov->size = size;
> +   kcov->size = size * sizeof(unsigned long);
> kcov->mode = KCOV_MODE_TRACE;
> return 0;
> case KCOV_ENABLE:
> @@ -223,7 +221,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned 
> int cmd,
> return -EBUSY;
> t = current;
> /* Cache in task struct for performance. */
> -   t->kcov_size = kcov->size;
> +   t->kcov_size = kcov->size / sizeof(unsigned long);
> t->kcov_area = kcov->area;
> /* See comment in __sanitizer_cov_trace_pc(). */
> barrier();
> --
> 2.10.2
>

Re: [PATCH 1/2] kcov: size of arena is now given in bytes.

[Dmitry Vyukov]

On Wed, Nov 16, 2016 at 10:27 PM, Quentin Casasnovas
 wrote:
> We'll introduce a different mode of tracing a-la AFL fixed table and Dmitry
> suggests that the code would be simpler with the size expressed in bytes as
> opposed unsigned longs.
>
> We only change the kcov::size field, which will be shared between different
> modes, but leave the task_struct::kcov_size field expressed in unsigned
> long in order to save an unecessary bitshift/division in the hot path when
> using KCOV_MODE_TRACE.


Thanks!

Reviewed-and-tested-by: Dmitry Vyukov 

I've tested that KCOV_MODE_TRACE works for me with these two patches applied.

> but leave the task_struct::kcov_size field expressed in unsigned long

The only purpose of the cache in task struct is to make coverage fast
path fast, so this looks good to me.



> Cc: Dmitry Vyukov 
> Cc: Michal Zalewski 
> Cc: Kees Cook 
> Signed-off-by: Quentin Casasnovas 
> Signed-off-by: Vegard Nossum 
> ---
>  kernel/kcov.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index 30e6d05aa5a9..c2aa93851f93 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -32,7 +32,7 @@ struct kcov {
> /* The lock protects mode, size, area and t. */
> spinlock_t  lock;
> enum kcov_mode  mode;
> -   /* Size of arena (in long's for KCOV_MODE_TRACE). */
> +   /* Size of arena in bytes. */
> unsignedsize;
> /* Coverage buffer shared with user space. */
> void*area;
> @@ -140,7 +140,7 @@ static int kcov_mmap(struct file *filep, struct 
> vm_area_struct *vma)
> return -ENOMEM;
>
> spin_lock(>lock);
> -   size = kcov->size * sizeof(unsigned long);
> +   size = kcov->size;
> if (kcov->mode == KCOV_MODE_DISABLED || vma->vm_pgoff != 0 ||
> vma->vm_end - vma->vm_start != size) {
> res = -EINVAL;
> @@ -198,13 +198,11 @@ static int kcov_ioctl_locked(struct kcov *kcov, 
> unsigned int cmd,
> return -EBUSY;
> /*
>  * Size must be at least 2 to hold current position and one 
> PC.
> -* Later we allocate size * sizeof(unsigned long) memory,
> -* that must not overflow.
>  */
> size = arg;
> if (size < 2 || size > INT_MAX / sizeof(unsigned long))
> return -EINVAL;
> -   kcov->size = size;
> +   kcov->size = size * sizeof(unsigned long);
> kcov->mode = KCOV_MODE_TRACE;
> return 0;
> case KCOV_ENABLE:
> @@ -223,7 +221,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned 
> int cmd,
> return -EBUSY;
> t = current;
> /* Cache in task struct for performance. */
> -   t->kcov_size = kcov->size;
> +   t->kcov_size = kcov->size / sizeof(unsigned long);
> t->kcov_area = kcov->area;
> /* See comment in __sanitizer_cov_trace_pc(). */
> barrier();
> --
> 2.10.2
>

Re: [PATCH 2/2] kcov: add AFL-style tracing

[Dmitry Vyukov]

On Wed, Nov 16, 2016 at 10:27 PM, Quentin Casasnovas
 wrote:
> AFL uses a fixed-size buffer (typically 64 KiB) where each byte is
> a counter representing how many times an A -> B branch was taken.
> Of course, since the buffer is fixed size, it's a little imprecise
> in that e.g. two different branches could map to the same counter,
> but in practice it works well.
>
> See afl:docs/technical_details.txt for more information.
>
> Here is a small test program that demonstrates the new capability:
>
> #include 
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include 
>
> #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
> #define KCOV_INIT_TABLE _IOR('c', 2, unsigned long)
> #define KCOV_ENABLE _IO('c', 100)
> #define KCOV_DISABLE_IO('c', 101)
>
> int main(int argc, char *argv[])
> {
> int fd = open("/sys/kernel/debug/kcov", O_RDWR);
> if (fd == -1)
> error(1, errno, "open()");
>
> unsigned long size = 1 << 10;
> if (ioctl(fd, KCOV_INIT_TABLE, size) != 0)
> error(1, errno, "ioctl(KCOV_INIT_TABLE)");
>
> void *mem = mmap(NULL, size, PROT_READ | PROT_WRITE, 
> MAP_SHARED, fd, 0);
> if (mem == MAP_FAILED)
> error(1, errno, "mmap()");
>
> /* Start kernel instrumentation */
> if (ioctl(fd, KCOV_ENABLE, 0) != 0)
> error(1, errno, "ioctl(KCOV_ENABLE)");
>
> printf("Hello world!\n");
>
> /* End kernel instrumentation*/
> if (ioctl(fd, KCOV_DISABLE, 0) != 0)
> error(1, errno, "ioctl(KCOV_DISABLE)");
>
> /* Hex dump of memory area */
> unsigned char *mem2 = mem;
> for (unsigned int i = 0; i < size / sizeof(i); ++i) {
> printf("%02x ", mem2[i]);
> if (i % 32 == 31)
> printf("\n");
> }
>
> close(fd);
> return 0;
> }
>
> This patch is a collaboration between Quentin Casasnovas and Vegard Nossum.
>
> v2: As per Dmitry's suggestions:
>   - Initialize location after barrier
>   - Avoid additional indirections in __sanitizer_cov_trace_pc
>   - Renamed KCOV_INIT_AFL/KCOV_MODE_AFL to KCOV_INIT_TABLE/KCOV_MODE_TABLE.
>
> Cc: Dmitry Vyukov 
> Cc: Michal Zalewski 
> Cc: Kees Cook 
> Signed-off-by: Quentin Casasnovas 
> Signed-off-by: Vegard Nossum 
> ---
>  include/linux/kcov.h  |  6 ++
>  include/linux/sched.h | 10 --
>  include/uapi/linux/kcov.h |  1 +
>  kernel/kcov.c | 37 -
>  4 files changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kcov.h b/include/linux/kcov.h
> index 2883ac98c280..5450b8296113 100644
> --- a/include/linux/kcov.h
> +++ b/include/linux/kcov.h
> @@ -18,6 +18,12 @@ enum kcov_mode {
>  * Covered PCs are collected in a per-task buffer.
>  */
> KCOV_MODE_TRACE = 1,
> +   /*
> +* AFL-style collection.
> +* Covered branches are hashed and collected in a fixed size buffer
> +* (see AFL documentation for more information).
> +*/
> +   KCOV_MODE_TABLE = 2,
>  };
>
>  #else
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 348f51b0ec92..31f1bde64961 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1919,8 +1919,14 @@ struct task_struct {
>  #ifdef CONFIG_KCOV
> /* Coverage collection mode enabled for this task (0 if disabled). */
> enum kcov_mode kcov_mode;
> -   /* Size of the kcov_area. */
> -   unsignedkcov_size;
> +   union {
> +   /* Size of the kcov_area. */
> +   unsigned kcov_size;
> +   /* Mask to fit within kcov_area */
> +   unsigned kcov_mask;
> +   };
> +   /* Hash of previous branch taken, to differentiate A > B from B > A */
> +   unsigned long   kcov_prev_location;
> /* Buffer for coverage collection. */
> void*kcov_area;
> /* kcov desciptor wired with this task or NULL. */
> diff --git a/include/uapi/linux/kcov.h b/include/uapi/linux/kcov.h
> index 574e22ec640d..19b8ff763243 100644
> --- a/include/uapi/linux/kcov.h
> +++ b/include/uapi/linux/kcov.h
> @@ -4,6 +4,7 @@
>  #include 
>
>  #define KCOV_INIT_TRACE_IOR('c', 1, unsigned long)
> +#define KCOV_INIT_TABLE

Re: [PATCH 2/2] kcov: add AFL-style tracing

[Dmitry Vyukov]

On Wed, Nov 16, 2016 at 10:27 PM, Quentin Casasnovas
 wrote:
> AFL uses a fixed-size buffer (typically 64 KiB) where each byte is
> a counter representing how many times an A -> B branch was taken.
> Of course, since the buffer is fixed size, it's a little imprecise
> in that e.g. two different branches could map to the same counter,
> but in practice it works well.
>
> See afl:docs/technical_details.txt for more information.
>
> Here is a small test program that demonstrates the new capability:
>
> #include 
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include 
>
> #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
> #define KCOV_INIT_TABLE _IOR('c', 2, unsigned long)
> #define KCOV_ENABLE _IO('c', 100)
> #define KCOV_DISABLE_IO('c', 101)
>
> int main(int argc, char *argv[])
> {
> int fd = open("/sys/kernel/debug/kcov", O_RDWR);
> if (fd == -1)
> error(1, errno, "open()");
>
> unsigned long size = 1 << 10;
> if (ioctl(fd, KCOV_INIT_TABLE, size) != 0)
> error(1, errno, "ioctl(KCOV_INIT_TABLE)");
>
> void *mem = mmap(NULL, size, PROT_READ | PROT_WRITE, 
> MAP_SHARED, fd, 0);
> if (mem == MAP_FAILED)
> error(1, errno, "mmap()");
>
> /* Start kernel instrumentation */
> if (ioctl(fd, KCOV_ENABLE, 0) != 0)
> error(1, errno, "ioctl(KCOV_ENABLE)");
>
> printf("Hello world!\n");
>
> /* End kernel instrumentation*/
> if (ioctl(fd, KCOV_DISABLE, 0) != 0)
> error(1, errno, "ioctl(KCOV_DISABLE)");
>
> /* Hex dump of memory area */
> unsigned char *mem2 = mem;
> for (unsigned int i = 0; i < size / sizeof(i); ++i) {
> printf("%02x ", mem2[i]);
> if (i % 32 == 31)
> printf("\n");
> }
>
> close(fd);
> return 0;
> }
>
> This patch is a collaboration between Quentin Casasnovas and Vegard Nossum.
>
> v2: As per Dmitry's suggestions:
>   - Initialize location after barrier
>   - Avoid additional indirections in __sanitizer_cov_trace_pc
>   - Renamed KCOV_INIT_AFL/KCOV_MODE_AFL to KCOV_INIT_TABLE/KCOV_MODE_TABLE.
>
> Cc: Dmitry Vyukov 
> Cc: Michal Zalewski 
> Cc: Kees Cook 
> Signed-off-by: Quentin Casasnovas 
> Signed-off-by: Vegard Nossum 
> ---
>  include/linux/kcov.h  |  6 ++
>  include/linux/sched.h | 10 --
>  include/uapi/linux/kcov.h |  1 +
>  kernel/kcov.c | 37 -
>  4 files changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kcov.h b/include/linux/kcov.h
> index 2883ac98c280..5450b8296113 100644
> --- a/include/linux/kcov.h
> +++ b/include/linux/kcov.h
> @@ -18,6 +18,12 @@ enum kcov_mode {
>  * Covered PCs are collected in a per-task buffer.
>  */
> KCOV_MODE_TRACE = 1,
> +   /*
> +* AFL-style collection.
> +* Covered branches are hashed and collected in a fixed size buffer
> +* (see AFL documentation for more information).
> +*/
> +   KCOV_MODE_TABLE = 2,
>  };
>
>  #else
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 348f51b0ec92..31f1bde64961 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1919,8 +1919,14 @@ struct task_struct {
>  #ifdef CONFIG_KCOV
> /* Coverage collection mode enabled for this task (0 if disabled). */
> enum kcov_mode kcov_mode;
> -   /* Size of the kcov_area. */
> -   unsignedkcov_size;
> +   union {
> +   /* Size of the kcov_area. */
> +   unsigned kcov_size;
> +   /* Mask to fit within kcov_area */
> +   unsigned kcov_mask;
> +   };
> +   /* Hash of previous branch taken, to differentiate A > B from B > A */
> +   unsigned long   kcov_prev_location;
> /* Buffer for coverage collection. */
> void*kcov_area;
> /* kcov desciptor wired with this task or NULL. */
> diff --git a/include/uapi/linux/kcov.h b/include/uapi/linux/kcov.h
> index 574e22ec640d..19b8ff763243 100644
> --- a/include/uapi/linux/kcov.h
> +++ b/include/uapi/linux/kcov.h
> @@ -4,6 +4,7 @@
>  #include 
>
>  #define KCOV_INIT_TRACE_IOR('c', 1, unsigned long)
> +#define KCOV_INIT_TABLE_IOR('c', 2, unsigned long)
>  #define KCOV_ENABLE_IO('c', 100)
>  #define KCOV_DISABLE   _IO('c', 101)
>
> diff 

Re: [PATCH v2 3/7] mtd: nand: add a nand.h file to expose basic NAND stuff

[Boris Brezillon]

On Thu, 17 Nov 2016 14:14:21 +0800
Peter Pan  wrote:

> Hi Boris,
> 
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>  wrote:
> > Now that raw NAND header has been moved to rawnand.h, we can add a new
> > nand.h file and define the common nand stuff in there.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> >  include/linux/mtd/nand.h | 480 
> > +++
> >  1 file changed, 480 insertions(+)
> >  create mode 100644 include/linux/mtd/nand.h
> >
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > new file mode 100644
> > index ..b9b5d3c1bdf9
> > --- /dev/null
> > +++ b/include/linux/mtd/nand.h  
> [...]
> > +
> > +/**
> > + * nand_offs_to_die - Convert an absolute offset to a die number
> > + * @nand: NAND device
> > + * @offs: absolute offset
> > + *
> > + * Returns the die number containing @offs.
> > + */
> > +static inline int nand_offs_to_die(struct nand_device *nand, loff_t offs)
> > +{
> > +   u64 die = offs;
> > +
> > +   do_div(die, nand->memorg.diesize);
> > +
> > +   return die;  
> 
> Is it proper to use do_div here?. If I'm right, the divisor of do_div is 
> 32bit.
> It may cause division 0 exception when die size is larger than 4GB.
> div64_u64 may be better.

Nice catch! Indeed, div64_u64() should be used here. I'll fix that.

Thanks,

Boris

Re: [PATCH v2 3/7] mtd: nand: add a nand.h file to expose basic NAND stuff

[Boris Brezillon]

On Thu, 17 Nov 2016 14:14:21 +0800
Peter Pan  wrote:

> Hi Boris,
> 
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>  wrote:
> > Now that raw NAND header has been moved to rawnand.h, we can add a new
> > nand.h file and define the common nand stuff in there.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> >  include/linux/mtd/nand.h | 480 
> > +++
> >  1 file changed, 480 insertions(+)
> >  create mode 100644 include/linux/mtd/nand.h
> >
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > new file mode 100644
> > index ..b9b5d3c1bdf9
> > --- /dev/null
> > +++ b/include/linux/mtd/nand.h  
> [...]
> > +
> > +/**
> > + * nand_offs_to_die - Convert an absolute offset to a die number
> > + * @nand: NAND device
> > + * @offs: absolute offset
> > + *
> > + * Returns the die number containing @offs.
> > + */
> > +static inline int nand_offs_to_die(struct nand_device *nand, loff_t offs)
> > +{
> > +   u64 die = offs;
> > +
> > +   do_div(die, nand->memorg.diesize);
> > +
> > +   return die;  
> 
> Is it proper to use do_div here?. If I'm right, the divisor of do_div is 
> 32bit.
> It may cause division 0 exception when die size is larger than 4GB.
> div64_u64 may be better.

Nice catch! Indeed, div64_u64() should be used here. I'll fix that.

Thanks,

Boris

Re: [PATCH v2 6/7] mtd: nand: raw: make BBT code more generic

[Boris Brezillon]

On Thu, 17 Nov 2016 14:19:29 +0800
Peter Pan  wrote:

> Hi Boris,
> 
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>  wrote:
> > BBT support is currently tightly tied to raw NAND, though this is the kind
> > of code we could share across all NAND based devices, no matter what
> > physical interface is to communicate with the NAND chip.
> >
> > Make BBT code interface agnostic by replacing all occurrence of
> > struct nand_chip by struct nand_device, and move functions that are
> > specific to raw NANDs to drivers/mtd/nand/rawnand/nand_base.c.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/nand/raw/nand_base.c |  78 -
> >  drivers/mtd/nand/raw/nand_bbt.c  | 609 
> > ++-
> >  include/linux/mtd/nand.h |   8 +
> >  include/linux/mtd/rawnand.h  |   4 -
> >  4 files changed, 361 insertions(+), 338 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/nand_base.c 
> > b/drivers/mtd/nand/raw/nand_base.c
> > index b86f4a1bfbe1..4930b3569de9 100644
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -471,7 +471,7 @@ static int nand_block_markbad_lowlevel(struct mtd_info 
> > *mtd, loff_t ofs)
> >
> > /* Mark block bad in BBT */
> > if (chip->bbt) {  
> 
> Should be "if (!nand->bbt.bbt)".

Indeed. And this makes me realize this chip->bbt field should be gone
(which is not the case since I had no compilation error).

> 
> > -   res = nand_markbad_bbt(mtd, ofs);
> > +   res = nand_markbad_bbt(mtd_to_nand(mtd), ofs);
> > if (!ret)
> > ret = res;
> > }  

Re: [PATCH v2 6/7] mtd: nand: raw: make BBT code more generic

[Boris Brezillon]

On Thu, 17 Nov 2016 14:19:29 +0800
Peter Pan  wrote:

> Hi Boris,
> 
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>  wrote:
> > BBT support is currently tightly tied to raw NAND, though this is the kind
> > of code we could share across all NAND based devices, no matter what
> > physical interface is to communicate with the NAND chip.
> >
> > Make BBT code interface agnostic by replacing all occurrence of
> > struct nand_chip by struct nand_device, and move functions that are
> > specific to raw NANDs to drivers/mtd/nand/rawnand/nand_base.c.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/nand/raw/nand_base.c |  78 -
> >  drivers/mtd/nand/raw/nand_bbt.c  | 609 
> > ++-
> >  include/linux/mtd/nand.h |   8 +
> >  include/linux/mtd/rawnand.h  |   4 -
> >  4 files changed, 361 insertions(+), 338 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/nand_base.c 
> > b/drivers/mtd/nand/raw/nand_base.c
> > index b86f4a1bfbe1..4930b3569de9 100644
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -471,7 +471,7 @@ static int nand_block_markbad_lowlevel(struct mtd_info 
> > *mtd, loff_t ofs)
> >
> > /* Mark block bad in BBT */
> > if (chip->bbt) {  
> 
> Should be "if (!nand->bbt.bbt)".

Indeed. And this makes me realize this chip->bbt field should be gone
(which is not the case since I had no compilation error).

> 
> > -   res = nand_markbad_bbt(mtd, ofs);
> > +   res = nand_markbad_bbt(mtd_to_nand(mtd), ofs);
> > if (!ret)
> > ret = res;
> > }  

[tip:x86/asm] selftests/x86: Add test_vdso to test getcpu()

[tip-bot for Andy Lutomirski]

Commit-ID:  3200ca806942d3d8f78d0d0c822e345dfb8789e7
Gitweb: http://git.kernel.org/tip/3200ca806942d3d8f78d0d0c822e345dfb8789e7
Author: Andy Lutomirski 
AuthorDate: Wed, 16 Nov 2016 10:23:28 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 08:31:22 +0100

selftests/x86: Add test_vdso to test getcpu()

I'll eventually add tests for more vDSO functions here.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Megha 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/945cd29901a62a3cc6ea7d6ee5e389ab1ec1ac0c.1479320367.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/Makefile|   2 +-
 tools/testing/selftests/x86/test_vdso.c | 123 
 2 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index a89f80a..8c1cb42 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -6,7 +6,7 @@ include ../lib.mk
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt 
ptrace_syscall test_mremap_vdso \
check_initial_reg_state sigreturn ldt_gdt iopl \
-   protection_keys
+   protection_keys test_vdso
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso 
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
diff --git a/tools/testing/selftests/x86/test_vdso.c 
b/tools/testing/selftests/x86/test_vdso.c
new file mode 100644
index 000..65d7a2b
--- /dev/null
+++ b/tools/testing/selftests/x86/test_vdso.c
@@ -0,0 +1,123 @@
+/*
+ * ldt_gdt.c - Test cases for LDT and GDT access
+ * Copyright (c) 2011-2015 Andrew Lutomirski
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef SYS_getcpu
+# ifdef __x86_64__
+#  define SYS_getcpu 309
+# else
+#  define SYS_getcpu 318
+# endif
+#endif
+
+int nerrs = 0;
+
+#ifdef __x86_64__
+# define VSYS(x) (x)
+#else
+# define VSYS(x) 0
+#endif
+
+typedef long (*getcpu_t)(unsigned *, unsigned *, void *);
+
+const getcpu_t vgetcpu = (getcpu_t)VSYS(0xff600800);
+getcpu_t vdso_getcpu;
+
+void fill_function_pointers()
+{
+   void *vdso = dlopen("linux-vdso.so.1",
+   RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD);
+   if (!vdso)
+   vdso = dlopen("linux-gate.so.1",
+ RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD);
+   if (!vdso) {
+   printf("[WARN]\tfailed to find vDSO\n");
+   return;
+   }
+
+   vdso_getcpu = (getcpu_t)dlsym(vdso, "__vdso_getcpu");
+   if (!vdso_getcpu)
+   printf("Warning: failed to find getcpu in vDSO\n");
+}
+
+static long sys_getcpu(unsigned * cpu, unsigned * node,
+  void* cache)
+{
+   return syscall(__NR_getcpu, cpu, node, cache);
+}
+
+static void test_getcpu(void)
+{
+   printf("[RUN]\tTesting getcpu...\n");
+
+   for (int cpu = 0; ; cpu++) {
+   cpu_set_t cpuset;
+   CPU_ZERO();
+   CPU_SET(cpu, );
+   if (sched_setaffinity(0, sizeof(cpuset), ) != 0)
+   return;
+
+   unsigned cpu_sys, cpu_vdso, cpu_vsys,
+   node_sys, node_vdso, node_vsys;
+   long ret_sys, ret_vdso = 1, ret_vsys = 1;
+   unsigned node;
+
+   ret_sys = sys_getcpu(_sys, _sys, 0);
+   if (vdso_getcpu)
+   ret_vdso = vdso_getcpu(_vdso, _vdso, 0);
+   if (vgetcpu)
+   ret_vsys = vgetcpu(_vsys, _vsys, 0);
+
+   if (!ret_sys)
+   node = node_sys;
+   else if (!ret_vdso)
+   node = node_vdso;
+   else if (!ret_vsys)
+   node = node_vsys;
+
+   bool ok = true;
+   if (!ret_sys && (cpu_sys != cpu || node_sys != node))
+   ok = false;
+   if (!ret_vdso && (cpu_vdso != cpu || node_vdso != node))
+   ok = false;
+   if (!ret_vsys && (cpu_vsys != cpu || node_vsys != node))
+   ok = false;
+
+   printf("[%s]\tCPU %u:", ok ? "OK" : "FAIL", cpu);
+   if (!ret_sys)
+   printf(" syscall: cpu %u, node %u", cpu_sys, node_sys);
+   if (!ret_vdso)
+   printf(" vdso: cpu 

[tip:x86/asm] selftests/x86: Add test_vdso to test getcpu()

[tip-bot for Andy Lutomirski]

Commit-ID:  3200ca806942d3d8f78d0d0c822e345dfb8789e7
Gitweb: http://git.kernel.org/tip/3200ca806942d3d8f78d0d0c822e345dfb8789e7
Author: Andy Lutomirski 
AuthorDate: Wed, 16 Nov 2016 10:23:28 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 08:31:22 +0100

selftests/x86: Add test_vdso to test getcpu()

I'll eventually add tests for more vDSO functions here.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Megha 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/945cd29901a62a3cc6ea7d6ee5e389ab1ec1ac0c.1479320367.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/Makefile|   2 +-
 tools/testing/selftests/x86/test_vdso.c | 123 
 2 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index a89f80a..8c1cb42 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -6,7 +6,7 @@ include ../lib.mk
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt 
ptrace_syscall test_mremap_vdso \
check_initial_reg_state sigreturn ldt_gdt iopl \
-   protection_keys
+   protection_keys test_vdso
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso 
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
diff --git a/tools/testing/selftests/x86/test_vdso.c 
b/tools/testing/selftests/x86/test_vdso.c
new file mode 100644
index 000..65d7a2b
--- /dev/null
+++ b/tools/testing/selftests/x86/test_vdso.c
@@ -0,0 +1,123 @@
+/*
+ * ldt_gdt.c - Test cases for LDT and GDT access
+ * Copyright (c) 2011-2015 Andrew Lutomirski
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef SYS_getcpu
+# ifdef __x86_64__
+#  define SYS_getcpu 309
+# else
+#  define SYS_getcpu 318
+# endif
+#endif
+
+int nerrs = 0;
+
+#ifdef __x86_64__
+# define VSYS(x) (x)
+#else
+# define VSYS(x) 0
+#endif
+
+typedef long (*getcpu_t)(unsigned *, unsigned *, void *);
+
+const getcpu_t vgetcpu = (getcpu_t)VSYS(0xff600800);
+getcpu_t vdso_getcpu;
+
+void fill_function_pointers()
+{
+   void *vdso = dlopen("linux-vdso.so.1",
+   RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD);
+   if (!vdso)
+   vdso = dlopen("linux-gate.so.1",
+ RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD);
+   if (!vdso) {
+   printf("[WARN]\tfailed to find vDSO\n");
+   return;
+   }
+
+   vdso_getcpu = (getcpu_t)dlsym(vdso, "__vdso_getcpu");
+   if (!vdso_getcpu)
+   printf("Warning: failed to find getcpu in vDSO\n");
+}
+
+static long sys_getcpu(unsigned * cpu, unsigned * node,
+  void* cache)
+{
+   return syscall(__NR_getcpu, cpu, node, cache);
+}
+
+static void test_getcpu(void)
+{
+   printf("[RUN]\tTesting getcpu...\n");
+
+   for (int cpu = 0; ; cpu++) {
+   cpu_set_t cpuset;
+   CPU_ZERO();
+   CPU_SET(cpu, );
+   if (sched_setaffinity(0, sizeof(cpuset), ) != 0)
+   return;
+
+   unsigned cpu_sys, cpu_vdso, cpu_vsys,
+   node_sys, node_vdso, node_vsys;
+   long ret_sys, ret_vdso = 1, ret_vsys = 1;
+   unsigned node;
+
+   ret_sys = sys_getcpu(_sys, _sys, 0);
+   if (vdso_getcpu)
+   ret_vdso = vdso_getcpu(_vdso, _vdso, 0);
+   if (vgetcpu)
+   ret_vsys = vgetcpu(_vsys, _vsys, 0);
+
+   if (!ret_sys)
+   node = node_sys;
+   else if (!ret_vdso)
+   node = node_vdso;
+   else if (!ret_vsys)
+   node = node_vsys;
+
+   bool ok = true;
+   if (!ret_sys && (cpu_sys != cpu || node_sys != node))
+   ok = false;
+   if (!ret_vdso && (cpu_vdso != cpu || node_vdso != node))
+   ok = false;
+   if (!ret_vsys && (cpu_vsys != cpu || node_vsys != node))
+   ok = false;
+
+   printf("[%s]\tCPU %u:", ok ? "OK" : "FAIL", cpu);
+   if (!ret_sys)
+   printf(" syscall: cpu %u, node %u", cpu_sys, node_sys);
+   if (!ret_vdso)
+   printf(" vdso: cpu %u, node %u", cpu_vdso, node_vdso);
+   if (!ret_vsys)
+   printf(" vsyscall: cpu %u, node %u", cpu_vsys,
+  node_vsys);
+   printf("\n");
+
+   if (!ok)
+  

[tip:x86/asm] x86/vdso: Use RDPID in preference to LSL when available

[tip-bot for Andy Lutomirski]

Commit-ID:  a582c540ac1b10f0a7d37415e04c4af42409fd08
Gitweb: http://git.kernel.org/tip/a582c540ac1b10f0a7d37415e04c4af42409fd08
Author: Andy Lutomirski 
AuthorDate: Wed, 16 Nov 2016 10:23:27 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 08:31:14 +0100

x86/vdso: Use RDPID in preference to LSL when available

RDPID is a new instruction that reads MSR_TSC_AUX quickly.  This
should be considerably faster than reading the GDT.  Add a
cpufeature for it and use it from __vdso_getcpu() when available.

Tested-by: Megha Dey 
Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/4f6c3a22012d10f1c65b9ca15800e01b42c7d39d.1479320367.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/include/asm/vgtod.h   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index a3e8cd7..eac7572 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -283,6 +283,7 @@
 #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation 
instructions*/
 #define X86_FEATURE_PKU(16*32+ 3) /* Protection Keys for 
Userspace */
 #define X86_FEATURE_OSPKE  (16*32+ 4) /* OS Protection Keys Enable */
+#define X86_FEATURE_RDPID  (16*32+ 22) /* RDPID instruction */
 
 /* AMD-defined CPU features, CPUID level 0x8007 (ebx), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV (17*32+0) /* MCA overflow recovery support 
*/
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index e728699..3a01996 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -89,8 +89,13 @@ static inline unsigned int __getcpu(void)
 * works on all CPUs.  This is volatile so that it orders
 * correctly wrt barrier() and to keep gcc from cleverly
 * hoisting it out of the calling function.
+*
+* If RDPID is available, use it.
 */
-   asm volatile ("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+   alternative_io ("lsl %[p],%[seg]",
+   ".byte 0xf3,0x0f,0xc7,0xf8", /* RDPID %eax/rax */
+   X86_FEATURE_RDPID,
+   [p] "=a" (p), [seg] "r" (__PER_CPU_SEG));
 
return p;
 }

[tip:x86/asm] x86/vdso: Use RDPID in preference to LSL when available

[tip-bot for Andy Lutomirski]

Commit-ID:  a582c540ac1b10f0a7d37415e04c4af42409fd08
Gitweb: http://git.kernel.org/tip/a582c540ac1b10f0a7d37415e04c4af42409fd08
Author: Andy Lutomirski 
AuthorDate: Wed, 16 Nov 2016 10:23:27 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 08:31:14 +0100

x86/vdso: Use RDPID in preference to LSL when available

RDPID is a new instruction that reads MSR_TSC_AUX quickly.  This
should be considerably faster than reading the GDT.  Add a
cpufeature for it and use it from __vdso_getcpu() when available.

Tested-by: Megha Dey 
Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/4f6c3a22012d10f1c65b9ca15800e01b42c7d39d.1479320367.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/include/asm/vgtod.h   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index a3e8cd7..eac7572 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -283,6 +283,7 @@
 #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation 
instructions*/
 #define X86_FEATURE_PKU(16*32+ 3) /* Protection Keys for 
Userspace */
 #define X86_FEATURE_OSPKE  (16*32+ 4) /* OS Protection Keys Enable */
+#define X86_FEATURE_RDPID  (16*32+ 22) /* RDPID instruction */
 
 /* AMD-defined CPU features, CPUID level 0x8007 (ebx), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV (17*32+0) /* MCA overflow recovery support 
*/
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index e728699..3a01996 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -89,8 +89,13 @@ static inline unsigned int __getcpu(void)
 * works on all CPUs.  This is volatile so that it orders
 * correctly wrt barrier() and to keep gcc from cleverly
 * hoisting it out of the calling function.
+*
+* If RDPID is available, use it.
 */
-   asm volatile ("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+   alternative_io ("lsl %[p],%[seg]",
+   ".byte 0xf3,0x0f,0xc7,0xf8", /* RDPID %eax/rax */
+   X86_FEATURE_RDPID,
+   [p] "=a" (p), [seg] "r" (__PER_CPU_SEG));
 
return p;
 }

[tip:locking/core] locking/core: Provide common cpu_relax_yield() definition

[tip-bot for Christian Borntraeger]

Commit-ID:  6d0d287891a022ebba572327cbd70b5de69a63a2
Gitweb: http://git.kernel.org/tip/6d0d287891a022ebba572327cbd70b5de69a63a2
Author: Christian Borntraeger 
AuthorDate: Wed, 16 Nov 2016 13:23:05 +0100
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 08:17:36 +0100

locking/core: Provide common cpu_relax_yield() definition

No need to duplicate the same define everywhere. Since
the only user is stop-machine and the only provider is
s390, we can use a default implementation of cpu_relax_yield()
in sched.h.

Suggested-by: Russell King 
Signed-off-by: Christian Borntraeger 
Reviewed-by: David Hildenbrand 
Acked-by: Russell King 
Cc: Andrew Morton 
Cc: Catalin Marinas 
Cc: Heiko Carstens 
Cc: Linus Torvalds 
Cc: Martin Schwidefsky 
Cc: Nicholas Piggin 
Cc: Noam Camus 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: k...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-s390 
Cc: linuxppc-...@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1479298985-191589-1-git-send-email-borntrae...@de.ibm.com
Signed-off-by: Ingo Molnar 
---
 arch/alpha/include/asm/processor.h  | 1 -
 arch/arc/include/asm/processor.h| 3 ---
 arch/arm/include/asm/processor.h| 2 --
 arch/arm64/include/asm/processor.h  | 2 --
 arch/avr32/include/asm/processor.h  | 1 -
 arch/blackfin/include/asm/processor.h   | 1 -
 arch/c6x/include/asm/processor.h| 1 -
 arch/cris/include/asm/processor.h   | 1 -
 arch/frv/include/asm/processor.h| 1 -
 arch/h8300/include/asm/processor.h  | 1 -
 arch/hexagon/include/asm/processor.h| 1 -
 arch/ia64/include/asm/processor.h   | 1 -
 arch/m32r/include/asm/processor.h   | 1 -
 arch/m68k/include/asm/processor.h   | 1 -
 arch/metag/include/asm/processor.h  | 1 -
 arch/microblaze/include/asm/processor.h | 1 -
 arch/mips/include/asm/processor.h   | 1 -
 arch/mn10300/include/asm/processor.h| 1 -
 arch/nios2/include/asm/processor.h  | 1 -
 arch/openrisc/include/asm/processor.h   | 1 -
 arch/parisc/include/asm/processor.h | 1 -
 arch/powerpc/include/asm/processor.h| 2 --
 arch/s390/include/asm/processor.h   | 1 +
 arch/score/include/asm/processor.h  | 1 -
 arch/sh/include/asm/processor.h | 1 -
 arch/sparc/include/asm/processor_32.h   | 1 -
 arch/sparc/include/asm/processor_64.h   | 1 -
 arch/tile/include/asm/processor.h   | 2 --
 arch/unicore32/include/asm/processor.h  | 1 -
 arch/x86/include/asm/processor.h| 2 --
 arch/x86/um/asm/processor.h | 1 -
 arch/xtensa/include/asm/processor.h | 1 -
 include/linux/sched.h   | 4 
 33 files changed, 5 insertions(+), 38 deletions(-)

diff --git a/arch/alpha/include/asm/processor.h 
b/arch/alpha/include/asm/processor.h
index 31e8dbe..2fec2de 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -58,7 +58,6 @@ unsigned long get_wchan(struct task_struct *p);
   ((tsk) == current ? rdusp() : task_thread_info(tsk)->pcb.usp)
 
 #define cpu_relax()barrier()
-#define cpu_relax_yield() cpu_relax()
 
 #define ARCH_HAS_PREFETCH
 #define ARCH_HAS_PREFETCHW
diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index d102a49..6e1242d 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -60,15 +60,12 @@ struct task_struct;
 #ifndef CONFIG_EZNPS_MTM_EXT
 
 #define cpu_relax()barrier()
-#define cpu_relax_yield()  cpu_relax()
 
 #else
 
 #define cpu_relax() \
__asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
 
-#define cpu_relax_yield()  cpu_relax()
-
 #endif
 
 #define copy_segments(tsk, mm)  do { } while (0)
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 9e71c58b..c3d5fc1 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -82,8 +82,6 @@ unsigned long get_wchan(struct task_struct *p);
 #define cpu_relax()barrier()
 #endif
 
-#define cpu_relax_yield()cpu_relax()
-
 #define task_pt_regs(p) \
((struct pt_regs *)(THREAD_START_SP + task_stack_page(p)) - 1)
 
diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index 6132f64..747c65a 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -149,8 

[tip:locking/core] locking/core: Provide common cpu_relax_yield() definition

[tip-bot for Christian Borntraeger]

Commit-ID:  6d0d287891a022ebba572327cbd70b5de69a63a2
Gitweb: http://git.kernel.org/tip/6d0d287891a022ebba572327cbd70b5de69a63a2
Author: Christian Borntraeger 
AuthorDate: Wed, 16 Nov 2016 13:23:05 +0100
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 08:17:36 +0100

locking/core: Provide common cpu_relax_yield() definition

No need to duplicate the same define everywhere. Since
the only user is stop-machine and the only provider is
s390, we can use a default implementation of cpu_relax_yield()
in sched.h.

Suggested-by: Russell King 
Signed-off-by: Christian Borntraeger 
Reviewed-by: David Hildenbrand 
Acked-by: Russell King 
Cc: Andrew Morton 
Cc: Catalin Marinas 
Cc: Heiko Carstens 
Cc: Linus Torvalds 
Cc: Martin Schwidefsky 
Cc: Nicholas Piggin 
Cc: Noam Camus 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: k...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-s390 
Cc: linuxppc-...@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1479298985-191589-1-git-send-email-borntrae...@de.ibm.com
Signed-off-by: Ingo Molnar 
---
 arch/alpha/include/asm/processor.h  | 1 -
 arch/arc/include/asm/processor.h| 3 ---
 arch/arm/include/asm/processor.h| 2 --
 arch/arm64/include/asm/processor.h  | 2 --
 arch/avr32/include/asm/processor.h  | 1 -
 arch/blackfin/include/asm/processor.h   | 1 -
 arch/c6x/include/asm/processor.h| 1 -
 arch/cris/include/asm/processor.h   | 1 -
 arch/frv/include/asm/processor.h| 1 -
 arch/h8300/include/asm/processor.h  | 1 -
 arch/hexagon/include/asm/processor.h| 1 -
 arch/ia64/include/asm/processor.h   | 1 -
 arch/m32r/include/asm/processor.h   | 1 -
 arch/m68k/include/asm/processor.h   | 1 -
 arch/metag/include/asm/processor.h  | 1 -
 arch/microblaze/include/asm/processor.h | 1 -
 arch/mips/include/asm/processor.h   | 1 -
 arch/mn10300/include/asm/processor.h| 1 -
 arch/nios2/include/asm/processor.h  | 1 -
 arch/openrisc/include/asm/processor.h   | 1 -
 arch/parisc/include/asm/processor.h | 1 -
 arch/powerpc/include/asm/processor.h| 2 --
 arch/s390/include/asm/processor.h   | 1 +
 arch/score/include/asm/processor.h  | 1 -
 arch/sh/include/asm/processor.h | 1 -
 arch/sparc/include/asm/processor_32.h   | 1 -
 arch/sparc/include/asm/processor_64.h   | 1 -
 arch/tile/include/asm/processor.h   | 2 --
 arch/unicore32/include/asm/processor.h  | 1 -
 arch/x86/include/asm/processor.h| 2 --
 arch/x86/um/asm/processor.h | 1 -
 arch/xtensa/include/asm/processor.h | 1 -
 include/linux/sched.h   | 4 
 33 files changed, 5 insertions(+), 38 deletions(-)

diff --git a/arch/alpha/include/asm/processor.h 
b/arch/alpha/include/asm/processor.h
index 31e8dbe..2fec2de 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -58,7 +58,6 @@ unsigned long get_wchan(struct task_struct *p);
   ((tsk) == current ? rdusp() : task_thread_info(tsk)->pcb.usp)
 
 #define cpu_relax()barrier()
-#define cpu_relax_yield() cpu_relax()
 
 #define ARCH_HAS_PREFETCH
 #define ARCH_HAS_PREFETCHW
diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index d102a49..6e1242d 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -60,15 +60,12 @@ struct task_struct;
 #ifndef CONFIG_EZNPS_MTM_EXT
 
 #define cpu_relax()barrier()
-#define cpu_relax_yield()  cpu_relax()
 
 #else
 
 #define cpu_relax() \
__asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
 
-#define cpu_relax_yield()  cpu_relax()
-
 #endif
 
 #define copy_segments(tsk, mm)  do { } while (0)
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 9e71c58b..c3d5fc1 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -82,8 +82,6 @@ unsigned long get_wchan(struct task_struct *p);
 #define cpu_relax()barrier()
 #endif
 
-#define cpu_relax_yield()cpu_relax()
-
 #define task_pt_regs(p) \
((struct pt_regs *)(THREAD_START_SP + task_stack_page(p)) - 1)
 
diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index 6132f64..747c65a 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -149,8 +149,6 @@ static inline void cpu_relax(void)
asm volatile("yield" ::: "memory");
 }
 
-#define cpu_relax_yield() cpu_relax()
-
 /* Thread switching */
 extern struct task_struct *cpu_switch_to(struct task_struct *prev,
 struct task_struct *next);
diff --git a/arch/avr32/include/asm/processor.h 
b/arch/avr32/include/asm/processor.h
index ee62365..972adcc 100644
--- 

Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Archit Taneja]

Hi,

Thanks for the patch.

On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:

Some dumb VGA DACs are active components which require external power.
Add support for specifying a regulator as its power supply.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Rob Herring 
---
 .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
 drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35 ++
 2 files changed, 37 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
index 003bc246a270..164cbb15f04c 100644
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
@@ -16,6 +16,8 @@ graph bindings specified in 
Documentation/devicetree/bindings/graph.txt.
 - Video port 0 for RGB input
 - Video port 1 for VGA output

+Optional properties:
+- vdd-supply: Power supply for DAC

 Example
 ---
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..15b549f94307 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -12,6 +12,7 @@

 #include 
 #include 
+#include 

 #include 
 #include 
@@ -23,6 +24,7 @@ struct dumb_vga {
struct drm_connectorconnector;

struct i2c_adapter  *ddc;
+   struct regulator*vdd;
 };

 static inline struct dumb_vga *
@@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
return 0;
 }

+static void dumb_vga_enable(struct drm_bridge *bridge)
+{
+   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+   int ret = 0;
+
+   if (vga->vdd)
+   ret = regulator_enable(vga->vdd);
+
+   if (ret) {
+   DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
+   return;


We don't need this return for now. If you're okay with it, can I fix this
and queue to misc?

Thanks,
Archit


+   }
+}
+
+static void dumb_vga_disable(struct drm_bridge *bridge)
+{
+   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+   if (vga->vdd)
+   regulator_disable(vga->vdd);
+}
+
 static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
.attach = dumb_vga_attach,
+   .enable = dumb_vga_enable,
+   .disable= dumb_vga_disable,
 };

 static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
@@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, vga);

+   vga->vdd = devm_regulator_get_optional(>dev, "vdd");
+   if (IS_ERR(vga->vdd)) {
+   ret = PTR_ERR(vga->vdd);
+   if (ret == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   vga->vdd = NULL;
+   dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
+   }
+
vga->ddc = dumb_vga_retrieve_ddc(>dev);
if (IS_ERR(vga->ddc)) {
if (PTR_ERR(vga->ddc) == -ENODEV) {



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: ILP32 for ARM64 - testing with lmbench

[Zhangjian (Bamvor)]

Hi, Maxim

On 2016/11/17 13:02, Maxim Kuvyrkov wrote:

Hi Bamvor,

I'm surprised that you see this much difference from ILP32 patches on SPEC 
CPU2006int at all.  The SPEC CPU2006 benchmarks spend almost no time in the 
kernel syscalls.  I can imagine memory, TLB, and cache handling in the kernel 
could affect CPU2006 benchmarks.  Do ILP32 patches touch code in those areas?

Other than that, it would be interesting to check what the variance is between 
the 3 iterations of benchmark runs.  Could you check what relative standard 
deviation is between the 3 iterations -- (STDEV(RUN1, RUN2, RUN3) / 
RUNselected)?

For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2,  0.8% 
for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum.

Here is my result:
ILP32_mergedILP32_unmerged
  401.bzip20.31%0.26%
  429.mcf  1.61%1.36%
  456.hmmer1.37%1.57%
  462.libquantum   0.29%0.28%

Regards

Bamvor



--
Maxim Kuvyrkov
www.linaro.org




On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor)  
wrote:

Hi, all

I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
libquantum are the top four differences[1]. Note that bigger is better in
specint test.

In order to make sure the above results, I retest these four testcases in
reportable way(reference the command in the end). The result[2] show that
libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in
significant.

The result of lmbench is not stable in my board. I plan to dig it later.

[1] The following test result is tested through --size=ref --iterations=3.
1.1 Test when aarch32_el0 is enabled.
   ILP32 disabledbase line
 400.perlbench100.00% 100%
 401.bzip2 99.35% 100%
 403.gcc  100.26% 100%
 429.mcf  102.75% 100%
 445.gobmk100.00% 100%
 456.hmmer 95.66% 100%
 458.sjeng100.00% 100%
 462.libquantum   100.00% 100%
 471.omnetpp  100.59% 100%
 473.astar 99.66% 100%
 483.xalancbmk 99.10% 100%

1.2 Test when aarch32_el0 is disabled
   ILP32 disabled base line
 400.perlbench100.22%  100%
 401.bzip2100.95%  100%
 403.gcc  100.20%  100%
 429.mcf  100.76%  100%
 445.gobmk100.36%  100%
 456.hmmer 97.94%  100%
 458.sjeng 99.73%  100%
 462.libquantum98.72%  100%
 471.omnetpp  100.86%  100%
 473.astar 99.15%  100%
 483.xalancbmk100.08%  100%

[2] The following test result is tested through: runspec --config=my.cfg 
--size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf 
hmmer libquantum
2.1 Test when aarch32_el0 is enabled.
ILP32_enabled base line
 401.bzip2100.82%  100%
 429.mcf  100.18%  100%
 456.hmmer 99.64%  100%
 462.libquantum97.91%  100%

Regards

Bamvor

On 2016/10/28 20:46, Yury Norov wrote:

[Add Steve Ellcey, thanks for testing on ThunderX]

Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
ILP32 series does not add performance regressions for LP64. Test
summary is in the table below. Our measurements doesn't show
significant performance regression of LP64 if ILP32 code is merged,
both enabled or disabled.

  ILP32 enabled   ILP32  disabled   Standard Kernel
null syscall   0.1066  0.11210.1121
  95.09%  100.00%

stat   1.3947  1.38141.3864
  100.60% 99.64%

fstat  0.4459  0.43440.4524
  98.56%  96.02%

open/close 4.0606  4.04114.0453
  100.38% 99.90%

read   0.4819  0.50140.5014
  96.11%  100.00%

Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
Other system details below.

Yury.

ubuntu@crb6:~$ uname -a
Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 

Re: ILP32 for ARM64 - testing with lmbench

[Zhangjian (Bamvor)]

Hi, Maxim

On 2016/11/17 13:02, Maxim Kuvyrkov wrote:

Hi Bamvor,

I'm surprised that you see this much difference from ILP32 patches on SPEC 
CPU2006int at all.  The SPEC CPU2006 benchmarks spend almost no time in the 
kernel syscalls.  I can imagine memory, TLB, and cache handling in the kernel 
could affect CPU2006 benchmarks.  Do ILP32 patches touch code in those areas?

Other than that, it would be interesting to check what the variance is between 
the 3 iterations of benchmark runs.  Could you check what relative standard 
deviation is between the 3 iterations -- (STDEV(RUN1, RUN2, RUN3) / 
RUNselected)?

For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2,  0.8% 
for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum.

Here is my result:
ILP32_mergedILP32_unmerged
  401.bzip20.31%0.26%
  429.mcf  1.61%1.36%
  456.hmmer1.37%1.57%
  462.libquantum   0.29%0.28%

Regards

Bamvor



--
Maxim Kuvyrkov
www.linaro.org




On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor)  
wrote:

Hi, all

I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
libquantum are the top four differences[1]. Note that bigger is better in
specint test.

In order to make sure the above results, I retest these four testcases in
reportable way(reference the command in the end). The result[2] show that
libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in
significant.

The result of lmbench is not stable in my board. I plan to dig it later.

[1] The following test result is tested through --size=ref --iterations=3.
1.1 Test when aarch32_el0 is enabled.
   ILP32 disabledbase line
 400.perlbench100.00% 100%
 401.bzip2 99.35% 100%
 403.gcc  100.26% 100%
 429.mcf  102.75% 100%
 445.gobmk100.00% 100%
 456.hmmer 95.66% 100%
 458.sjeng100.00% 100%
 462.libquantum   100.00% 100%
 471.omnetpp  100.59% 100%
 473.astar 99.66% 100%
 483.xalancbmk 99.10% 100%

1.2 Test when aarch32_el0 is disabled
   ILP32 disabled base line
 400.perlbench100.22%  100%
 401.bzip2100.95%  100%
 403.gcc  100.20%  100%
 429.mcf  100.76%  100%
 445.gobmk100.36%  100%
 456.hmmer 97.94%  100%
 458.sjeng 99.73%  100%
 462.libquantum98.72%  100%
 471.omnetpp  100.86%  100%
 473.astar 99.15%  100%
 483.xalancbmk100.08%  100%

[2] The following test result is tested through: runspec --config=my.cfg 
--size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf 
hmmer libquantum
2.1 Test when aarch32_el0 is enabled.
ILP32_enabled base line
 401.bzip2100.82%  100%
 429.mcf  100.18%  100%
 456.hmmer 99.64%  100%
 462.libquantum97.91%  100%

Regards

Bamvor

On 2016/10/28 20:46, Yury Norov wrote:

[Add Steve Ellcey, thanks for testing on ThunderX]

Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
ILP32 series does not add performance regressions for LP64. Test
summary is in the table below. Our measurements doesn't show
significant performance regression of LP64 if ILP32 code is merged,
both enabled or disabled.

  ILP32 enabled   ILP32  disabled   Standard Kernel
null syscall   0.1066  0.11210.1121
  95.09%  100.00%

stat   1.3947  1.38141.3864
  100.60% 99.64%

fstat  0.4459  0.43440.4524
  98.56%  96.02%

open/close 4.0606  4.04114.0453
  100.38% 99.90%

read   0.4819  0.50140.5014
  96.11%  100.00%

Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
Other system details below.

Yury.

ubuntu@crb6:~$ uname -a
Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 aarch64 
GNU/Linux

Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Archit Taneja]

Hi,

Thanks for the patch.

On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:

Some dumb VGA DACs are active components which require external power.
Add support for specifying a regulator as its power supply.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Rob Herring 
---
 .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
 drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35 ++
 2 files changed, 37 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
index 003bc246a270..164cbb15f04c 100644
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
@@ -16,6 +16,8 @@ graph bindings specified in 
Documentation/devicetree/bindings/graph.txt.
 - Video port 0 for RGB input
 - Video port 1 for VGA output

+Optional properties:
+- vdd-supply: Power supply for DAC

 Example
 ---
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..15b549f94307 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -12,6 +12,7 @@

 #include 
 #include 
+#include 

 #include 
 #include 
@@ -23,6 +24,7 @@ struct dumb_vga {
struct drm_connectorconnector;

struct i2c_adapter  *ddc;
+   struct regulator*vdd;
 };

 static inline struct dumb_vga *
@@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
return 0;
 }

+static void dumb_vga_enable(struct drm_bridge *bridge)
+{
+   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+   int ret = 0;
+
+   if (vga->vdd)
+   ret = regulator_enable(vga->vdd);
+
+   if (ret) {
+   DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
+   return;


We don't need this return for now. If you're okay with it, can I fix this
and queue to misc?

Thanks,
Archit


+   }
+}
+
+static void dumb_vga_disable(struct drm_bridge *bridge)
+{
+   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+   if (vga->vdd)
+   regulator_disable(vga->vdd);
+}
+
 static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
.attach = dumb_vga_attach,
+   .enable = dumb_vga_enable,
+   .disable= dumb_vga_disable,
 };

 static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
@@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, vga);

+   vga->vdd = devm_regulator_get_optional(>dev, "vdd");
+   if (IS_ERR(vga->vdd)) {
+   ret = PTR_ERR(vga->vdd);
+   if (ret == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   vga->vdd = NULL;
+   dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
+   }
+
vga->ddc = dumb_vga_retrieve_ddc(>dev);
if (IS_ERR(vga->ddc)) {
if (PTR_ERR(vga->ddc) == -ENODEV) {



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] mremap: fix race between mremap() and page cleanning

[Aaron Lu]

+LKML.

Also attached the kernel patch that enlarges the race window and the
user space test code raceremap.c, which you can put in will-it-scale's
tests directory and run it as:
# ./raceremap_threads -t 2 -s 1

Make sure "cpu0 runs" appeared in the first line.

If you get SEGFAULT:
[aaron@aaronlu will-it-scale]$ sudo ./raceremap_threads -t 2 -s 1
cpu0 runs
cpu1 runs
cpu0: going to remap
testcase:mremap
warmup
cpu1: going to clean the page
cpu1: going to write 2
min:0 max:0 total:0
min:0 max:0 total:0
cpu0: remap done
Segmentation fault

That means the race doesn't occur.

If you get "*cpu1 wrote 2 gets lost":
[aaron@aaronlu will-it-scale]$ sudo ./raceremap_threads -t 2 -s 1
cpu1 runs
testcase:mremap
warmup
cpu0 runs
cpu0: going to remap
cpu1: going to clean the page
cpu1: going to write 2
cpu1 wrote 2
min:0 max:0 total:0
min:0 max:0 total:0
cpu0: remap done
*cpu1 wrote 2 gets lost

That means the race occurred.

Thanks,
Aaron

On Thu, Nov 10, 2016 at 05:16:33PM +0800, Aaron Lu wrote:
> Prior to 3.15, there was a race between zap_pte_range() and
> page_mkclean() where writes to a page could be lost.  Dave Hansen
> discovered by inspection that there is a similar race between
> move_ptes() and  page_mkclean().
> 
> We've been able to reproduce the issue by enlarging the race window with
> a msleep(), but have not been able to hit it without modifying the code.
> So, we think it's a real issue, but is difficult or impossible to hit
> in practice.
> 
> The zap_pte_range() issue is fixed by commit 1cf35d47712d("mm: split
> 'tlb_flush_mmu()' into tlb flushing and memory freeing parts"). And
> this patch is to fix the race between page_mkclean() and mremap().
> 
> Here is one possible way to hit the race: suppose a process mmapped a
> file with READ | WRITE and SHARED, it has two threads and they are bound
> to 2 different CPUs, e.g. CPU1 and CPU2. mmap returned X, then thread 1
> did a write to addr X so that CPU1 now has a writable TLB for addr X
> on it. Thread 2 starts mremaping from addr X to Y while thread 1 cleaned
> the page and then did another write to the old addr X again. The 2nd
> write from thread 1 could succeed but the value will get lost.
> 
> thread 1   thread 2
>  (bound to CPU1)(bound to CPU2)
> 
>   1: write 1 to addr X to get a
>  writeable TLB on this CPU
> 
> 2: mremap starts
> 
> 3: move_ptes emptied PTE for addr X
>and setup new PTE for addr Y and
>then dropped PTL for X and Y
> 
>   4: page laundering for N by doing
>  fadvise FADV_DONTNEED. When done,
>  pageframe N is deemed clean.
> 
>   5: *write 2 to addr X
> 
> 6: tlb flush for addr X
> 
>   7: munmap (Y, pagesize) to make the
>  page unmapped
> 
>   8: fadvise with FADV_DONTNEED again
>  to kick the page off the pagecache
> 
>   9: pread the page from file to verify
>  the value. If 1 is there, it means
>  we have lost the written 2.
> 
>   *the write may or may not cause segmentation fault, it depends on
>   if the TLB is still on the CPU.
> 
> Please note that this is only one specific way of how the race could
> occur, it didn't mean that the race could only occur in exact the above
> config, e.g. more than 2 threads could be involved and fadvise() could
> be done in another thread, etc.
> 
> For anonymous pages, they could race between mremap() and page reclaim:
> THP: a huge PMD is moved by mremap to a new huge PMD, then the new huge PMD
> gets unmapped/splitted/pagedout before the flush tlb happened for the old
> huge PMD in move_page_tables() and we could still write data to it.
> The normal anonymous page has similar situation.
> 
> To fix this, check for any dirty PTE in move_ptes()/move_huge_pmd() and
> if any, did the flush before dropping the PTL. If we did the flush for
> every move_ptes()/move_huge_pmd() call then we do not need to do the
> flush in move_pages_tables() for the whole range. But if we didn't, we
> still need to do the whole range flush.
> 
> Alternatively, we can track which part of the range is flushed in
> move_ptes()/move_huge_pmd() and which didn't to avoid flushing the whole
> range in move_page_tables(). But that would require multiple tlb flushes
> for the different sub-ranges and should be less efficient than the
> single whole range flush.
> 
> KBuild test on my Sandybridge desktop doesn't show any noticeable change.
> v4.9-rc4:
> real5m14.048s
> user32m19.800s
> sys 4m50.320s
> 
> With this commit:
> real5m13.888s
> user32m19.330s
> sys 4m51.200s
> 
> Reported-by: Dave Hansen 
> Signed-off-by: Aaron Lu 
> ---
>  include/linux/huge_mm.h |  2 +-
>  mm/huge_memory.c|  9 -
>  mm/mremap.c | 30 

Re: [PATCH] mremap: fix race between mremap() and page cleanning

[Aaron Lu]

+LKML.

Also attached the kernel patch that enlarges the race window and the
user space test code raceremap.c, which you can put in will-it-scale's
tests directory and run it as:
# ./raceremap_threads -t 2 -s 1

Make sure "cpu0 runs" appeared in the first line.

If you get SEGFAULT:
[aaron@aaronlu will-it-scale]$ sudo ./raceremap_threads -t 2 -s 1
cpu0 runs
cpu1 runs
cpu0: going to remap
testcase:mremap
warmup
cpu1: going to clean the page
cpu1: going to write 2
min:0 max:0 total:0
min:0 max:0 total:0
cpu0: remap done
Segmentation fault

That means the race doesn't occur.

If you get "*cpu1 wrote 2 gets lost":
[aaron@aaronlu will-it-scale]$ sudo ./raceremap_threads -t 2 -s 1
cpu1 runs
testcase:mremap
warmup
cpu0 runs
cpu0: going to remap
cpu1: going to clean the page
cpu1: going to write 2
cpu1 wrote 2
min:0 max:0 total:0
min:0 max:0 total:0
cpu0: remap done
*cpu1 wrote 2 gets lost

That means the race occurred.

Thanks,
Aaron

On Thu, Nov 10, 2016 at 05:16:33PM +0800, Aaron Lu wrote:
> Prior to 3.15, there was a race between zap_pte_range() and
> page_mkclean() where writes to a page could be lost.  Dave Hansen
> discovered by inspection that there is a similar race between
> move_ptes() and  page_mkclean().
> 
> We've been able to reproduce the issue by enlarging the race window with
> a msleep(), but have not been able to hit it without modifying the code.
> So, we think it's a real issue, but is difficult or impossible to hit
> in practice.
> 
> The zap_pte_range() issue is fixed by commit 1cf35d47712d("mm: split
> 'tlb_flush_mmu()' into tlb flushing and memory freeing parts"). And
> this patch is to fix the race between page_mkclean() and mremap().
> 
> Here is one possible way to hit the race: suppose a process mmapped a
> file with READ | WRITE and SHARED, it has two threads and they are bound
> to 2 different CPUs, e.g. CPU1 and CPU2. mmap returned X, then thread 1
> did a write to addr X so that CPU1 now has a writable TLB for addr X
> on it. Thread 2 starts mremaping from addr X to Y while thread 1 cleaned
> the page and then did another write to the old addr X again. The 2nd
> write from thread 1 could succeed but the value will get lost.
> 
> thread 1   thread 2
>  (bound to CPU1)(bound to CPU2)
> 
>   1: write 1 to addr X to get a
>  writeable TLB on this CPU
> 
> 2: mremap starts
> 
> 3: move_ptes emptied PTE for addr X
>and setup new PTE for addr Y and
>then dropped PTL for X and Y
> 
>   4: page laundering for N by doing
>  fadvise FADV_DONTNEED. When done,
>  pageframe N is deemed clean.
> 
>   5: *write 2 to addr X
> 
> 6: tlb flush for addr X
> 
>   7: munmap (Y, pagesize) to make the
>  page unmapped
> 
>   8: fadvise with FADV_DONTNEED again
>  to kick the page off the pagecache
> 
>   9: pread the page from file to verify
>  the value. If 1 is there, it means
>  we have lost the written 2.
> 
>   *the write may or may not cause segmentation fault, it depends on
>   if the TLB is still on the CPU.
> 
> Please note that this is only one specific way of how the race could
> occur, it didn't mean that the race could only occur in exact the above
> config, e.g. more than 2 threads could be involved and fadvise() could
> be done in another thread, etc.
> 
> For anonymous pages, they could race between mremap() and page reclaim:
> THP: a huge PMD is moved by mremap to a new huge PMD, then the new huge PMD
> gets unmapped/splitted/pagedout before the flush tlb happened for the old
> huge PMD in move_page_tables() and we could still write data to it.
> The normal anonymous page has similar situation.
> 
> To fix this, check for any dirty PTE in move_ptes()/move_huge_pmd() and
> if any, did the flush before dropping the PTL. If we did the flush for
> every move_ptes()/move_huge_pmd() call then we do not need to do the
> flush in move_pages_tables() for the whole range. But if we didn't, we
> still need to do the whole range flush.
> 
> Alternatively, we can track which part of the range is flushed in
> move_ptes()/move_huge_pmd() and which didn't to avoid flushing the whole
> range in move_page_tables(). But that would require multiple tlb flushes
> for the different sub-ranges and should be less efficient than the
> single whole range flush.
> 
> KBuild test on my Sandybridge desktop doesn't show any noticeable change.
> v4.9-rc4:
> real5m14.048s
> user32m19.800s
> sys 4m50.320s
> 
> With this commit:
> real5m13.888s
> user32m19.330s
> sys 4m51.200s
> 
> Reported-by: Dave Hansen 
> Signed-off-by: Aaron Lu 
> ---
>  include/linux/huge_mm.h |  2 +-
>  mm/huge_memory.c|  9 -
>  mm/mremap.c | 30 +-
>  3 files changed, 30 

Re: [RFC 2/8] mm: Add specialized fallback zonelist for coherent device memory nodes

[Anshuman Khandual]

On 10/24/2016 10:01 AM, Anshuman Khandual wrote:
> This change is part of the isolation requiring coherent device memory
> node's implementation.
> 
> Isolation seeking coherent memory node requires isolation from implicit
> memory allocations from user space but at the same time there should also
> have an explicit way to do the allocation. Kernel allocation to this memory
> can be prevented by putting the entire memory in ZONE_MOVABLE for example.
> 
> Platform node's both zonelists are fundamental to where the memory comes
> when there is an allocation request. In order to achieve the two objectives
> stated above, zonelists building process has to change as both zonelists
> (FALLBACK and NOFALLBACK) gives access to the node's memory zones during
> any kind of memory allocation. The following changes are implemented in
> this regard.
> 
> (1) Coherent node's zones are not part of any other node's FALLBACK list
> (2) Coherent node's FALLBACK list contains it's own memory zones followed
> by all system RAM zones in normal order
> (3) Coherent node's zones are part of it's own NOFALLBACK list
> 
> The above changes which will ensure the following which in turn isolates
> the coherent memory node as desired.
> 
> (1) There wont be any implicit allocation ending up in the coherent node
> (2) __GFP_THISNODE marked allocations will come from the coherent node
> (3) Coherent memory can also be allocated through MPOL_BIND interface
> 
> Sample zonelist configuration:
> 
> [NODE (0)]System RAM node
> ZONELIST_FALLBACK (0xc140da00)
> (0) (node 0) (DMA 0xc140c000)
> (1) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc1411a10)
> (0) (node 0) (DMA 0xc140c000)
> [NODE (1)]System RAM node
> ZONELIST_FALLBACK (0xc0011a00)
> (0) (node 1) (DMA 0xc001)
> (1) (node 0) (DMA 0xc140c000)
> ZONELIST_NOFALLBACK (0xc0015a10)
> (0) (node 1) (DMA 0xc001)
> [NODE (2)]Coherent memory
> ZONELIST_FALLBACK (0xc1427700)
> (0) (node 2) (Movable 0xc1427080)
> (1) (node 0) (DMA 0xc140c000)
> (2) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc142b710)
> (0) (node 2) (Movable 0xc1427080)
> [NODE (3)]Coherent memory
> ZONELIST_FALLBACK (0xc1431400)
> (0) (node 3) (Movable 0xc1430d80)
> (1) (node 0) (DMA 0xc140c000)
> (2) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc1435410)
> (0) (node 3) (Movable 0xc1430d80)
> [NODE (4)]Coherent memory
> ZONELIST_FALLBACK (0xc143b100)
> (0) (node 4) (Movable 0xc143aa80)
> (1) (node 0) (DMA 0xc140c000)
> (2) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc143f110)
> (0) (node 4) (Movable 0xc143aa80)
> 
> Signed-off-by: Anshuman Khandual 
> ---

Another way of achieving isolation of the CDM nodes from user space
allocations would be through cpuset changes. Will be sending out
couple of draft patches in this direction. Then we can look into
whether the current method or the cpuset method is a better way to
go forward.

Re: [RFC 2/8] mm: Add specialized fallback zonelist for coherent device memory nodes

[Anshuman Khandual]

On 10/24/2016 10:01 AM, Anshuman Khandual wrote:
> This change is part of the isolation requiring coherent device memory
> node's implementation.
> 
> Isolation seeking coherent memory node requires isolation from implicit
> memory allocations from user space but at the same time there should also
> have an explicit way to do the allocation. Kernel allocation to this memory
> can be prevented by putting the entire memory in ZONE_MOVABLE for example.
> 
> Platform node's both zonelists are fundamental to where the memory comes
> when there is an allocation request. In order to achieve the two objectives
> stated above, zonelists building process has to change as both zonelists
> (FALLBACK and NOFALLBACK) gives access to the node's memory zones during
> any kind of memory allocation. The following changes are implemented in
> this regard.
> 
> (1) Coherent node's zones are not part of any other node's FALLBACK list
> (2) Coherent node's FALLBACK list contains it's own memory zones followed
> by all system RAM zones in normal order
> (3) Coherent node's zones are part of it's own NOFALLBACK list
> 
> The above changes which will ensure the following which in turn isolates
> the coherent memory node as desired.
> 
> (1) There wont be any implicit allocation ending up in the coherent node
> (2) __GFP_THISNODE marked allocations will come from the coherent node
> (3) Coherent memory can also be allocated through MPOL_BIND interface
> 
> Sample zonelist configuration:
> 
> [NODE (0)]System RAM node
> ZONELIST_FALLBACK (0xc140da00)
> (0) (node 0) (DMA 0xc140c000)
> (1) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc1411a10)
> (0) (node 0) (DMA 0xc140c000)
> [NODE (1)]System RAM node
> ZONELIST_FALLBACK (0xc0011a00)
> (0) (node 1) (DMA 0xc001)
> (1) (node 0) (DMA 0xc140c000)
> ZONELIST_NOFALLBACK (0xc0015a10)
> (0) (node 1) (DMA 0xc001)
> [NODE (2)]Coherent memory
> ZONELIST_FALLBACK (0xc1427700)
> (0) (node 2) (Movable 0xc1427080)
> (1) (node 0) (DMA 0xc140c000)
> (2) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc142b710)
> (0) (node 2) (Movable 0xc1427080)
> [NODE (3)]Coherent memory
> ZONELIST_FALLBACK (0xc1431400)
> (0) (node 3) (Movable 0xc1430d80)
> (1) (node 0) (DMA 0xc140c000)
> (2) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc1435410)
> (0) (node 3) (Movable 0xc1430d80)
> [NODE (4)]Coherent memory
> ZONELIST_FALLBACK (0xc143b100)
> (0) (node 4) (Movable 0xc143aa80)
> (1) (node 0) (DMA 0xc140c000)
> (2) (node 1) (DMA 0xc001)
> ZONELIST_NOFALLBACK (0xc143f110)
> (0) (node 4) (Movable 0xc143aa80)
> 
> Signed-off-by: Anshuman Khandual 
> ---

Another way of achieving isolation of the CDM nodes from user space
allocations would be through cpuset changes. Will be sending out
couple of draft patches in this direction. Then we can look into
whether the current method or the cpuset method is a better way to
go forward.

Re: [PATCH] vgaarb: Use dev_printk() when possible

[Daniel Vetter]

On Wed, Nov 16, 2016 at 03:45:22PM -0600, Bjorn Helgaas wrote:
> For consistency with other device-related messages, use dev_printk() when
> possible instead of pr_*() and pci_name().  This changes messages like
> this:
> 
>   vgaarb: setting as boot device: PCI::01:00.0
>   vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
>   vgaarb: bridge control possible :01:00.0
> 
> to this:
> 
>   pci :01:00.0: vgaarb: setting as boot device
>   pci :01:00.0: vgaarb: device added: 
> decodes=io+mem,owns=io+mem,locks=none
>   pci :01:00.0: vgaarb: bridge control possible
> 
> No functional change intended.
> 
> Signed-off-by: Bjorn Helgaas 

Hm, not convinced this is better (vgaarb is kinda not a device driver),
and the code becomes a bit more unpretty imo with placing DRV all over.
I guess if you go with a 

#define vgaarb_info(dev, fmt) dev_info(dev, "vgaarg: " fmt)

or so I can be convinced.
-Daniel

> ---
>  drivers/gpu/vga/vgaarb.c |   27 ---
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 1887f19..8a3f212 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -29,7 +29,8 @@
>   *
>   */
>  
> -#define pr_fmt(fmt) "vgaarb: " fmt
> +#define DRV "vgaarb: "
> +#define pr_fmt(fmt) DRV fmt
>  
>  #include 
>  #include 
> @@ -663,7 +664,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>*/
>   if (vga_default == NULL &&
>   ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
> - pr_info("setting as boot device: PCI:%s\n", pci_name(pdev));
> + dev_info(>dev, DRV "setting as boot device\n");
>   vga_set_default_device(pdev);
>   }
>  
> @@ -672,8 +673,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>   /* Add to the list */
>   list_add(>list, _list);
>   vga_count++;
> - pr_info("device added: PCI:%s,decodes=%s,owns=%s,locks=%s\n",
> - pci_name(pdev),
> + dev_info(>dev, DRV "device added: decodes=%s,owns=%s,locks=%s\n",
>   vga_iostate_to_str(vgadev->decodes),
>   vga_iostate_to_str(vgadev->owns),
>   vga_iostate_to_str(vgadev->locks));
> @@ -732,8 +732,7 @@ static inline void vga_update_device_decodes(struct 
> vga_device *vgadev,
>   decodes_unlocked = vgadev->locks & decodes_removed;
>   vgadev->decodes = new_decodes;
>  
> - pr_info("device changed decodes: 
> PCI:%s,olddecodes=%s,decodes=%s:owns=%s\n",
> - pci_name(vgadev->pdev),
> + dev_info(>pdev->dev, DRV "device changed decodes: 
> olddecodes=%s,decodes=%s:owns=%s\n",
>   vga_iostate_to_str(old_decodes),
>   vga_iostate_to_str(vgadev->decodes),
>   vga_iostate_to_str(vgadev->owns));
> @@ -1206,7 +1205,7 @@ static ssize_t vga_arb_write(struct file *file, const 
> char __user *buf,
>   pr_debug("vgadev %p\n", vgadev);
>   if (vgadev == NULL) {
>   if (pdev) {
> - pr_err("this pci device is not a vga device\n");
> + dev_err(>dev, DRV "this device is not a 
> vga device\n");
>   pci_dev_put(pdev);
>   }
>  
> @@ -1408,6 +1407,7 @@ static int __init vga_arb_device_init(void)
>   int rc;
>   struct pci_dev *pdev;
>   struct vga_device *vgadev;
> + struct device *dev;
>  
>   rc = misc_register(_arb_device);
>   if (rc < 0)
> @@ -1440,6 +1440,7 @@ static int __init vga_arb_device_init(void)
>   int i;
>  
>   limit = screen_info.lfb_base + screen_info.lfb_size;
> + dev = >pdev->dev;
>  
>   /* Does firmware framebuffer belong to us? */
>   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> @@ -1458,20 +1459,16 @@ static int __init vga_arb_device_init(void)
>   continue;
>  
>   if (!vga_default_device())
> - pr_info("setting as boot device: PCI:%s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "setting as boot device\n");
>   else if (vgadev->pdev != vga_default_device())
> - pr_info("overriding boot device: PCI:%s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "overriding boot device\n");
>   vga_set_default_device(vgadev->pdev);
>   }
>  #endif
>   if (vgadev->bridge_has_one_vga)
> - pr_info("bridge control possible %s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "bridge control possible\n");
>   else
> -

Re: [PATCH] vgaarb: Use dev_printk() when possible

[Daniel Vetter]

On Wed, Nov 16, 2016 at 03:45:22PM -0600, Bjorn Helgaas wrote:
> For consistency with other device-related messages, use dev_printk() when
> possible instead of pr_*() and pci_name().  This changes messages like
> this:
> 
>   vgaarb: setting as boot device: PCI::01:00.0
>   vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
>   vgaarb: bridge control possible :01:00.0
> 
> to this:
> 
>   pci :01:00.0: vgaarb: setting as boot device
>   pci :01:00.0: vgaarb: device added: 
> decodes=io+mem,owns=io+mem,locks=none
>   pci :01:00.0: vgaarb: bridge control possible
> 
> No functional change intended.
> 
> Signed-off-by: Bjorn Helgaas 

Hm, not convinced this is better (vgaarb is kinda not a device driver),
and the code becomes a bit more unpretty imo with placing DRV all over.
I guess if you go with a 

#define vgaarb_info(dev, fmt) dev_info(dev, "vgaarg: " fmt)

or so I can be convinced.
-Daniel

> ---
>  drivers/gpu/vga/vgaarb.c |   27 ---
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 1887f19..8a3f212 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -29,7 +29,8 @@
>   *
>   */
>  
> -#define pr_fmt(fmt) "vgaarb: " fmt
> +#define DRV "vgaarb: "
> +#define pr_fmt(fmt) DRV fmt
>  
>  #include 
>  #include 
> @@ -663,7 +664,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>*/
>   if (vga_default == NULL &&
>   ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
> - pr_info("setting as boot device: PCI:%s\n", pci_name(pdev));
> + dev_info(>dev, DRV "setting as boot device\n");
>   vga_set_default_device(pdev);
>   }
>  
> @@ -672,8 +673,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>   /* Add to the list */
>   list_add(>list, _list);
>   vga_count++;
> - pr_info("device added: PCI:%s,decodes=%s,owns=%s,locks=%s\n",
> - pci_name(pdev),
> + dev_info(>dev, DRV "device added: decodes=%s,owns=%s,locks=%s\n",
>   vga_iostate_to_str(vgadev->decodes),
>   vga_iostate_to_str(vgadev->owns),
>   vga_iostate_to_str(vgadev->locks));
> @@ -732,8 +732,7 @@ static inline void vga_update_device_decodes(struct 
> vga_device *vgadev,
>   decodes_unlocked = vgadev->locks & decodes_removed;
>   vgadev->decodes = new_decodes;
>  
> - pr_info("device changed decodes: 
> PCI:%s,olddecodes=%s,decodes=%s:owns=%s\n",
> - pci_name(vgadev->pdev),
> + dev_info(>pdev->dev, DRV "device changed decodes: 
> olddecodes=%s,decodes=%s:owns=%s\n",
>   vga_iostate_to_str(old_decodes),
>   vga_iostate_to_str(vgadev->decodes),
>   vga_iostate_to_str(vgadev->owns));
> @@ -1206,7 +1205,7 @@ static ssize_t vga_arb_write(struct file *file, const 
> char __user *buf,
>   pr_debug("vgadev %p\n", vgadev);
>   if (vgadev == NULL) {
>   if (pdev) {
> - pr_err("this pci device is not a vga device\n");
> + dev_err(>dev, DRV "this device is not a 
> vga device\n");
>   pci_dev_put(pdev);
>   }
>  
> @@ -1408,6 +1407,7 @@ static int __init vga_arb_device_init(void)
>   int rc;
>   struct pci_dev *pdev;
>   struct vga_device *vgadev;
> + struct device *dev;
>  
>   rc = misc_register(_arb_device);
>   if (rc < 0)
> @@ -1440,6 +1440,7 @@ static int __init vga_arb_device_init(void)
>   int i;
>  
>   limit = screen_info.lfb_base + screen_info.lfb_size;
> + dev = >pdev->dev;
>  
>   /* Does firmware framebuffer belong to us? */
>   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> @@ -1458,20 +1459,16 @@ static int __init vga_arb_device_init(void)
>   continue;
>  
>   if (!vga_default_device())
> - pr_info("setting as boot device: PCI:%s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "setting as boot device\n");
>   else if (vgadev->pdev != vga_default_device())
> - pr_info("overriding boot device: PCI:%s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "overriding boot device\n");
>   vga_set_default_device(vgadev->pdev);
>   }
>  #endif
>   if (vgadev->bridge_has_one_vga)
> - pr_info("bridge control possible %s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "bridge control possible\n");
>   else
> - 

[tip:x86/urgent] x86/boot: Avoid warning for zero-filling .bss

[tip-bot for Arnd Bergmann]

Commit-ID:  553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985
Gitweb: http://git.kernel.org/tip/553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985
Author: Arnd Bergmann 
AuthorDate: Wed, 16 Nov 2016 15:17:09 +0100
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 07:34:58 +0100

x86/boot: Avoid warning for zero-filling .bss

The latest binutils are warning about a .fill directive with an explicit
value in a .bss section:

  arch/x86/kernel/head_32.S: Assembler messages:
  arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section 
`.bss..page_aligned'
  arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section 
`.bss..page_aligned'

This comes from the 'ENTRY()' macro padding the space between the symbols
with 'nop' via:

  .align 4,0x90

Open-coding the .globl directive without the padding avoids that warning,
as all the symbols are already page aligned.

Signed-off-by: Arnd Bergmann 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20161116141726.2013389-1-a...@arndb.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/head_32.S | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index b6b2f02..2dabea4 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -665,14 +665,17 @@ __PAGE_ALIGNED_BSS
 initial_pg_pmd:
.fill 1024*KPMDS,4,0
 #else
-ENTRY(initial_page_table)
+.globl initial_page_table
+initial_page_table:
.fill 1024,4,0
 #endif
 initial_pg_fixmap:
.fill 1024,4,0
-ENTRY(empty_zero_page)
+.globl empty_zero_page
+empty_zero_page:
.fill 4096,1,0
-ENTRY(swapper_pg_dir)
+.globl swapper_pg_dir
+swapper_pg_dir:
.fill 1024,4,0
 EXPORT_SYMBOL(empty_zero_page)
 

[tip:x86/asm] x86/dumpstack: Handle NULL stack pointer in show_trace_log_lvl()

[tip-bot for Josh Poimboeuf]

Commit-ID:  f4474c9f0bba17857b1a47c8dc89c07a0845c2b2
Gitweb: http://git.kernel.org/tip/f4474c9f0bba17857b1a47c8dc89c07a0845c2b2
Author: Josh Poimboeuf 
AuthorDate: Thu, 17 Nov 2016 00:04:58 -0600
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 07:48:39 +0100

x86/dumpstack: Handle NULL stack pointer in show_trace_log_lvl()

When show_trace_log_lvl() is called from show_regs(), it completely
fails to dump the stack.  This bug was introduced when
show_stack_log_lvl() was removed with the following commit:

  0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")

Previous callers of that function now call show_trace_log_lvl()
directly.  That resulted in a subtle change, in that the 'stack'
argument can now be NULL in certain cases.

A NULL 'stack' pointer means that the stack dump should start from the
topmost stack frame unless 'regs' is valid, in which case it should
start from 'regs->sp'.

Signed-off-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")
Link: 
http://lkml.kernel.org/r/c551842302a9c222d96a14e42e4003f059509f69.1479362652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 499aa6f..1e057b0 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -59,6 +59,7 @@ void show_trace_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
printk("%sCall Trace:\n", log_lvl);
 
unwind_start(, task, regs, stack);
+   stack = stack ? : get_stack_pointer(task, regs);
 
/*
 * Iterate through the stacks, starting with the current stack pointer.

[tip:x86/urgent] x86/boot: Avoid warning for zero-filling .bss

[tip-bot for Arnd Bergmann]

Commit-ID:  553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985
Gitweb: http://git.kernel.org/tip/553bbc11aa6c1f9e0f529a06aeeca15fbe4a3985
Author: Arnd Bergmann 
AuthorDate: Wed, 16 Nov 2016 15:17:09 +0100
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 07:34:58 +0100

x86/boot: Avoid warning for zero-filling .bss

The latest binutils are warning about a .fill directive with an explicit
value in a .bss section:

  arch/x86/kernel/head_32.S: Assembler messages:
  arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section 
`.bss..page_aligned'
  arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section 
`.bss..page_aligned'

This comes from the 'ENTRY()' macro padding the space between the symbols
with 'nop' via:

  .align 4,0x90

Open-coding the .globl directive without the padding avoids that warning,
as all the symbols are already page aligned.

Signed-off-by: Arnd Bergmann 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20161116141726.2013389-1-a...@arndb.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/head_32.S | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index b6b2f02..2dabea4 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -665,14 +665,17 @@ __PAGE_ALIGNED_BSS
 initial_pg_pmd:
.fill 1024*KPMDS,4,0
 #else
-ENTRY(initial_page_table)
+.globl initial_page_table
+initial_page_table:
.fill 1024,4,0
 #endif
 initial_pg_fixmap:
.fill 1024,4,0
-ENTRY(empty_zero_page)
+.globl empty_zero_page
+empty_zero_page:
.fill 4096,1,0
-ENTRY(swapper_pg_dir)
+.globl swapper_pg_dir
+swapper_pg_dir:
.fill 1024,4,0
 EXPORT_SYMBOL(empty_zero_page)
 

[tip:x86/asm] x86/dumpstack: Handle NULL stack pointer in show_trace_log_lvl()

[tip-bot for Josh Poimboeuf]

Commit-ID:  f4474c9f0bba17857b1a47c8dc89c07a0845c2b2
Gitweb: http://git.kernel.org/tip/f4474c9f0bba17857b1a47c8dc89c07a0845c2b2
Author: Josh Poimboeuf 
AuthorDate: Thu, 17 Nov 2016 00:04:58 -0600
Committer:  Ingo Molnar 
CommitDate: Thu, 17 Nov 2016 07:48:39 +0100

x86/dumpstack: Handle NULL stack pointer in show_trace_log_lvl()

When show_trace_log_lvl() is called from show_regs(), it completely
fails to dump the stack.  This bug was introduced when
show_stack_log_lvl() was removed with the following commit:

  0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")

Previous callers of that function now call show_trace_log_lvl()
directly.  That resulted in a subtle change, in that the 'stack'
argument can now be NULL in certain cases.

A NULL 'stack' pointer means that the stack dump should start from the
topmost stack frame unless 'regs' is valid, in which case it should
start from 'regs->sp'.

Signed-off-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")
Link: 
http://lkml.kernel.org/r/c551842302a9c222d96a14e42e4003f059509f69.1479362652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 499aa6f..1e057b0 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -59,6 +59,7 @@ void show_trace_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
printk("%sCall Trace:\n", log_lvl);
 
unwind_start(, task, regs, stack);
+   stack = stack ? : get_stack_pointer(task, regs);
 
/*
 * Iterate through the stacks, starting with the current stack pointer.

Re: [PATCH 0/1] One bug fix for FPGA

[Greg Kroah-Hartman]

On Wed, Nov 16, 2016 at 07:54:39PM -0600, Alan Tull wrote:
> Hi Greg,
> 
> Can you take this patch?

Yes, no need to send it 3 times :)

Re: [PATCH 0/1] One bug fix for FPGA

[Greg Kroah-Hartman]

On Wed, Nov 16, 2016 at 07:54:39PM -0600, Alan Tull wrote:
> Hi Greg,
> 
> Can you take this patch?

Yes, no need to send it 3 times :)

[PATCH v8 3/3] clocksource: Add clockevent support to NPS400 driver

[Noam Camus]

From: Noam Camus 

Till now we used clockevent from generic ARC driver.
This was enough as long as we worked with simple multicore SoC.
When we are working with multithread SoC each HW thread can be
scheduled to receive timer interrupt using timer mask register.
This patch will provide a way to control clock events per HW thread.

The design idea is that for each core there is dedicated register
(TSI) serving all 16 HW threads.
The register is a bitmask with one bit for each HW thread.
When HW thread wants that next expiration of timer interrupt will
hit it then the proper bit should be set in this dedicated register.
When timer expires all HW threads within this core which their bit
is set at the TSI register will be interrupted.

Driver can be used from device tree by:
compatible = "ezchip,nps400-timer0" <-- for clocksource
compatible = "ezchip,nps400-timer1" <-- for clockevent

Note that name convention for timer0/timer1 was taken from legacy
ARC design. This design is our base before adding HW threads.
For backward compatibility we keep "ezchip,nps400-timer" for clocksource

Signed-off-by: Noam Camus 
Acked-by: Daniel Lezcano 
Acked-by: Rob Herring 
---
 .../bindings/timer/ezchip,nps400-timer.txt |   15 --
 .../bindings/timer/ezchip,nps400-timer0.txt|   17 ++
 .../bindings/timer/ezchip,nps400-timer1.txt|   15 ++
 drivers/clocksource/timer-nps.c|  170 
 4 files changed, 202 insertions(+), 15 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt

diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt 
b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
deleted file mode 100644
index c8c03d7..000
--- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-NPS Network Processor
-
-Required properties:
-
-- compatible : should be "ezchip,nps400-timer"
-
-Clocks required for compatible = "ezchip,nps400-timer":
-- clocks : Must contain a single entry describing the clock input
-
-Example:
-
-timer {
-   compatible = "ezchip,nps400-timer";
-   clocks = <>;
-};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt 
b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
new file mode 100644
index 000..e3cfce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
@@ -0,0 +1,17 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer0"
+
+Clocks required for compatible = "ezchip,nps400-timer0":
+- interrupts : The interrupt of the first timer
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+   compatible = "ezchip,nps400-timer0";
+   interrupts = <3>;
+   clocks = <>;
+};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt 
b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
new file mode 100644
index 000..c0ab419
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
@@ -0,0 +1,15 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer1"
+
+Clocks required for compatible = "ezchip,nps400-timer1":
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+   compatible = "ezchip,nps400-timer1";
+   clocks = <>;
+};
diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
index 0c8e21f..b4c8a02 100644
--- a/drivers/clocksource/timer-nps.c
+++ b/drivers/clocksource/timer-nps.c
@@ -111,3 +111,173 @@ static int __init nps_setup_clocksource(struct 
device_node *node)
 
 CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
   nps_setup_clocksource);
+CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
+  nps_setup_clocksource);
+
+#ifdef CONFIG_EZNPS_MTM_EXT
+#include 
+
+/* Timer related Aux registers */
+#define NPS_REG_TIMER0_TSI 0xF850
+#define NPS_REG_TIMER0_LIMIT   0x23
+#define NPS_REG_TIMER0_CTRL0x22
+#define NPS_REG_TIMER0_CNT 0x21
+
+/*
+ * Interrupt Enabled (IE) - re-arm the timer
+ * Not Halted (NH) - is cleared when working with JTAG (for debug)
+ */
+#define TIMER0_CTRL_IE BIT(0)
+#define TIMER0_CTRL_NH BIT(1)
+
+static unsigned long nps_timer0_freq;
+static unsigned long nps_timer0_irq;
+
+static void nps_clkevent_rm_thread(void)
+{
+   int thread;
+   unsigned int cflags, enabled_threads;
+
+   hw_schd_save();
+
+   enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
+
+   /* remove thread 

[PATCH v8 3/3] clocksource: Add clockevent support to NPS400 driver

[Noam Camus]

From: Noam Camus 

Till now we used clockevent from generic ARC driver.
This was enough as long as we worked with simple multicore SoC.
When we are working with multithread SoC each HW thread can be
scheduled to receive timer interrupt using timer mask register.
This patch will provide a way to control clock events per HW thread.

The design idea is that for each core there is dedicated register
(TSI) serving all 16 HW threads.
The register is a bitmask with one bit for each HW thread.
When HW thread wants that next expiration of timer interrupt will
hit it then the proper bit should be set in this dedicated register.
When timer expires all HW threads within this core which their bit
is set at the TSI register will be interrupted.

Driver can be used from device tree by:
compatible = "ezchip,nps400-timer0" <-- for clocksource
compatible = "ezchip,nps400-timer1" <-- for clockevent

Note that name convention for timer0/timer1 was taken from legacy
ARC design. This design is our base before adding HW threads.
For backward compatibility we keep "ezchip,nps400-timer" for clocksource

Signed-off-by: Noam Camus 
Acked-by: Daniel Lezcano 
Acked-by: Rob Herring 
---
 .../bindings/timer/ezchip,nps400-timer.txt |   15 --
 .../bindings/timer/ezchip,nps400-timer0.txt|   17 ++
 .../bindings/timer/ezchip,nps400-timer1.txt|   15 ++
 drivers/clocksource/timer-nps.c|  170 
 4 files changed, 202 insertions(+), 15 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt

diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt 
b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
deleted file mode 100644
index c8c03d7..000
--- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-NPS Network Processor
-
-Required properties:
-
-- compatible : should be "ezchip,nps400-timer"
-
-Clocks required for compatible = "ezchip,nps400-timer":
-- clocks : Must contain a single entry describing the clock input
-
-Example:
-
-timer {
-   compatible = "ezchip,nps400-timer";
-   clocks = <>;
-};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt 
b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
new file mode 100644
index 000..e3cfce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
@@ -0,0 +1,17 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer0"
+
+Clocks required for compatible = "ezchip,nps400-timer0":
+- interrupts : The interrupt of the first timer
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+   compatible = "ezchip,nps400-timer0";
+   interrupts = <3>;
+   clocks = <>;
+};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt 
b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
new file mode 100644
index 000..c0ab419
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
@@ -0,0 +1,15 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer1"
+
+Clocks required for compatible = "ezchip,nps400-timer1":
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+   compatible = "ezchip,nps400-timer1";
+   clocks = <>;
+};
diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
index 0c8e21f..b4c8a02 100644
--- a/drivers/clocksource/timer-nps.c
+++ b/drivers/clocksource/timer-nps.c
@@ -111,3 +111,173 @@ static int __init nps_setup_clocksource(struct 
device_node *node)
 
 CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
   nps_setup_clocksource);
+CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
+  nps_setup_clocksource);
+
+#ifdef CONFIG_EZNPS_MTM_EXT
+#include 
+
+/* Timer related Aux registers */
+#define NPS_REG_TIMER0_TSI 0xF850
+#define NPS_REG_TIMER0_LIMIT   0x23
+#define NPS_REG_TIMER0_CTRL0x22
+#define NPS_REG_TIMER0_CNT 0x21
+
+/*
+ * Interrupt Enabled (IE) - re-arm the timer
+ * Not Halted (NH) - is cleared when working with JTAG (for debug)
+ */
+#define TIMER0_CTRL_IE BIT(0)
+#define TIMER0_CTRL_NH BIT(1)
+
+static unsigned long nps_timer0_freq;
+static unsigned long nps_timer0_irq;
+
+static void nps_clkevent_rm_thread(void)
+{
+   int thread;
+   unsigned int cflags, enabled_threads;
+
+   hw_schd_save();
+
+   enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
+
+   /* remove thread from TSI1 */
+   thread = read_aux_reg(CTOP_AUX_THREAD_ID);
+   enabled_threads 

RE: [PATCH v7 3/3] clocksource: Add clockevent support to NPS400 driver

[Noam Camus]

>From: Rob Herring [mailto:r...@kernel.org] 
>Sent: Wednesday, November 16, 2016 3:45 PM
...

>Please add acks when reposting.

>Acked-by: Rob Herring 

Will post [PATCH v8 3/3] with your ack

Thanks
Noam

RE: [PATCH v7 3/3] clocksource: Add clockevent support to NPS400 driver

[Noam Camus]

>From: Rob Herring [mailto:r...@kernel.org] 
>Sent: Wednesday, November 16, 2016 3:45 PM
...

>Please add acks when reposting.

>Acked-by: Rob Herring 

Will post [PATCH v8 3/3] with your ack

Thanks
Noam

Re: linux-next: manual merge of the kvm tree with the tip tree

[Thomas Gleixner]

On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

This should be

> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

tip will carry a proper resolution today.

Thanks,

tglx

Re: linux-next: manual merge of the kvm tree with the tip tree

[Thomas Gleixner]

On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

This should be

> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

tip will carry a proper resolution today.

Thanks,

tglx

[RFC] Memory hotplug support for ARM64

[Maciej Bielski]

Dear All,

We are working on a series of patches that aims for implementing memory
hotplug (also hotremove after) functionality for ARM64 CPUs. There are already
existing ARM64 platforms with SO-DIMMs RAM bricks that could use such feature
([2], for example). Except for that, we would like to use it to provide runtime 
RAM
provisioning for Linux/KVM guests.

The process how to online new range of memory addresses is described in
Documentation/memory-hotplug.txt The idea is to make available new range of
addresses at runtime, after the brick is physically plugged in and it can be
performed via sysfs interface (more detailed description in documentation).

This feature is not currently available for ARM64 processors (the
implementation of architecture specific functions like `arch_add_memory()`
is missing for that platform). Our analysis so far has identified no technical
obstacle in porting memory hotplug to arm64, but probably this feature
was not highly desirable in the past, with ARM CPUs being deployed mostly on
portable devices without SO-DIMM slots.

Nowadays, this may change with ARM64 platform trying to enter server
market [1][2], where runtime memory reconfiguration is very important.
First, typically a server contains multiple SO-DIMM slots so additional RAM can 
be
physically attached. Second, it needs to be done while the machine is
running since often reboots are not acceptable in a data center. Trying to find
existing efforts towards this direction, we have only discovered that
the lack of memory hotplug/hotremove has been already spotted and mentioned as a
nice-to-have at least [3][4] but no working implementation has been found
published.

Therefore, we have planned to undertake the task of implementing kernel
support for RAM hotplug/hotunplug on ARM64 platform and achieved first 
optimistic
results. This particular development is performed within the scope of the
dReDBox - EC project under H2020 framework [5].

Do you see value in including such work in the mainline kernel? Any
comment is more than welcome (please add me to CC).


[1] 
http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Japan_2016_ARMv4.pdf
[2] http://www.cavium.com/ThunderX_ARM_Processors.html
[3] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/382137.html
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/341865.html
[5] http://www.dredbox.eu/


BR,

-- 
Maciej Bielski

[RFC] Memory hotplug support for ARM64

[Maciej Bielski]

Dear All,

We are working on a series of patches that aims for implementing memory
hotplug (also hotremove after) functionality for ARM64 CPUs. There are already
existing ARM64 platforms with SO-DIMMs RAM bricks that could use such feature
([2], for example). Except for that, we would like to use it to provide runtime 
RAM
provisioning for Linux/KVM guests.

The process how to online new range of memory addresses is described in
Documentation/memory-hotplug.txt The idea is to make available new range of
addresses at runtime, after the brick is physically plugged in and it can be
performed via sysfs interface (more detailed description in documentation).

This feature is not currently available for ARM64 processors (the
implementation of architecture specific functions like `arch_add_memory()`
is missing for that platform). Our analysis so far has identified no technical
obstacle in porting memory hotplug to arm64, but probably this feature
was not highly desirable in the past, with ARM CPUs being deployed mostly on
portable devices without SO-DIMM slots.

Nowadays, this may change with ARM64 platform trying to enter server
market [1][2], where runtime memory reconfiguration is very important.
First, typically a server contains multiple SO-DIMM slots so additional RAM can 
be
physically attached. Second, it needs to be done while the machine is
running since often reboots are not acceptable in a data center. Trying to find
existing efforts towards this direction, we have only discovered that
the lack of memory hotplug/hotremove has been already spotted and mentioned as a
nice-to-have at least [3][4] but no working implementation has been found
published.

Therefore, we have planned to undertake the task of implementing kernel
support for RAM hotplug/hotunplug on ARM64 platform and achieved first 
optimistic
results. This particular development is performed within the scope of the
dReDBox - EC project under H2020 framework [5].

Do you see value in including such work in the mainline kernel? Any
comment is more than welcome (please add me to CC).


[1] 
http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Japan_2016_ARMv4.pdf
[2] http://www.cavium.com/ThunderX_ARM_Processors.html
[3] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/382137.html
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/341865.html
[5] http://www.dredbox.eu/


BR,

-- 
Maciej Bielski

Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

[Petko Manolov]

On 16-11-16 18:11:13, David Howells wrote:
> Allow keys to be added to the system secondary certificates keyring during 
> kernel initialisation in an unrestricted fashion.  Such keys are implicitly 
> trusted and don't have their trust chains checked on link.

Well, I for one do not explicitly trust these keys.  I may even want to 
completely remove or replace them.

> This allows keys in the UEFI database to be added in secure boot mode for the 
> purposes of module signing.

The key import should not be automatic, it should be optional.  Same applies to 
the validation process.


Petko


> Signed-off-by: David Howells 
> ---
> 
>  certs/internal.h   |   18 ++
>  certs/system_keyring.c |   33 +
>  2 files changed, 51 insertions(+)
>  create mode 100644 certs/internal.h
> 
> diff --git a/certs/internal.h b/certs/internal.h
> new file mode 100644
> index ..5dcbefb0c23a
> --- /dev/null
> +++ b/certs/internal.h
> @@ -0,0 +1,18 @@
> +/* Internal definitions
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +/*
> + * system_keyring.c
> + */
> +#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> +extern void __init add_trusted_secondary_key(const char *source,
> +  const void *data, size_t len);
> +#endif
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 50979d6dcecd..dfddcf6e6c88 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include "internal.h"
>  
>  static struct key *builtin_trusted_keys;
>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> @@ -242,3 +243,35 @@ int verify_pkcs7_signature(const void *data, size_t len,
>  EXPORT_SYMBOL_GPL(verify_pkcs7_signature);
>  
>  #endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
> +
> +#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> +/**
> + * add_trusted_secondary_key - Add to secondary keyring with no validation
> + * @source: Source of key
> + * @data: The blob holding the key
> + * @len: The length of the data blob
> + *
> + * Add a key to the secondary keyring without checking its trust chain.  This
> + * is available only during kernel initialisation.
> + */
> +void __init add_trusted_secondary_key(const char *source,
> +   const void *data, size_t len)
> +{
> + key_ref_t key;
> +
> + key = key_create_or_update(make_key_ref(secondary_trusted_keys, 1),
> +"asymmetric",
> +NULL, data, len,
> +(KEY_POS_ALL & ~KEY_POS_SETATTR) |
> +KEY_USR_VIEW,
> +KEY_ALLOC_NOT_IN_QUOTA |
> +KEY_ALLOC_BYPASS_RESTRICTION);
> +
> + if (IS_ERR(key))
> + pr_err("Problem loading %s X.509 certificate (%ld)\n",
> +source, PTR_ERR(key));
> + else
> + pr_notice("Loaded %s cert '%s' linked to secondary sys 
> keyring\n",
> +   source, key_ref_to_ptr(key)->description);
> +}
> +#endif /* CONFIG_SECONDARY_TRUSTED_KEYRING */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

[Petko Manolov]

On 16-11-16 18:11:13, David Howells wrote:
> Allow keys to be added to the system secondary certificates keyring during 
> kernel initialisation in an unrestricted fashion.  Such keys are implicitly 
> trusted and don't have their trust chains checked on link.

Well, I for one do not explicitly trust these keys.  I may even want to 
completely remove or replace them.

> This allows keys in the UEFI database to be added in secure boot mode for the 
> purposes of module signing.

The key import should not be automatic, it should be optional.  Same applies to 
the validation process.


Petko


> Signed-off-by: David Howells 
> ---
> 
>  certs/internal.h   |   18 ++
>  certs/system_keyring.c |   33 +
>  2 files changed, 51 insertions(+)
>  create mode 100644 certs/internal.h
> 
> diff --git a/certs/internal.h b/certs/internal.h
> new file mode 100644
> index ..5dcbefb0c23a
> --- /dev/null
> +++ b/certs/internal.h
> @@ -0,0 +1,18 @@
> +/* Internal definitions
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +/*
> + * system_keyring.c
> + */
> +#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> +extern void __init add_trusted_secondary_key(const char *source,
> +  const void *data, size_t len);
> +#endif
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 50979d6dcecd..dfddcf6e6c88 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include "internal.h"
>  
>  static struct key *builtin_trusted_keys;
>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> @@ -242,3 +243,35 @@ int verify_pkcs7_signature(const void *data, size_t len,
>  EXPORT_SYMBOL_GPL(verify_pkcs7_signature);
>  
>  #endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
> +
> +#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> +/**
> + * add_trusted_secondary_key - Add to secondary keyring with no validation
> + * @source: Source of key
> + * @data: The blob holding the key
> + * @len: The length of the data blob
> + *
> + * Add a key to the secondary keyring without checking its trust chain.  This
> + * is available only during kernel initialisation.
> + */
> +void __init add_trusted_secondary_key(const char *source,
> +   const void *data, size_t len)
> +{
> + key_ref_t key;
> +
> + key = key_create_or_update(make_key_ref(secondary_trusted_keys, 1),
> +"asymmetric",
> +NULL, data, len,
> +(KEY_POS_ALL & ~KEY_POS_SETATTR) |
> +KEY_USR_VIEW,
> +KEY_ALLOC_NOT_IN_QUOTA |
> +KEY_ALLOC_BYPASS_RESTRICTION);
> +
> + if (IS_ERR(key))
> + pr_err("Problem loading %s X.509 certificate (%ld)\n",
> +source, PTR_ERR(key));
> + else
> + pr_notice("Loaded %s cert '%s' linked to secondary sys 
> keyring\n",
> +   source, key_ref_to_ptr(key)->description);
> +}
> +#endif /* CONFIG_SECONDARY_TRUSTED_KEYRING */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

[Maxim Patlasov]

On 11/16/2016 11:19 AM, Nikolaus Rath wrote:


Hi Maxim,

On Nov 15 2016, Maxim Patlasov  wrote:

On 11/15/2016 08:18 AM, Nikolaus Rath wrote:

Could someone explain to me the meaning of the max_background and
congestion_threshold settings of the fuse module?

At first I assumed that max_background specifies the maximum number of
pending requests (i.e., requests that have been send to userspace but
for which no reply was received yet). But looking at fs/fuse/dev.c, it
looks as if not every request is included in this number.

fuse uses max_background for cases where the total number of
simultaneous requests of given type is not limited by some other
natural means. AFAIU, these cases are: 1) async processing of direct
IO; 2) read-ahead. As an example of "natural" limitation: when
userspace process blocks on a sync direct IO read/write, the number of
requests fuse consumed is limited by the number of such processes
(actually their threads). In contrast, if userspace requests 1GB
direct IO read/write, it would be unreasonable to issue 1GB/128K==8192
fuse requests simultaneously. That's where max_background steps in.

Ah, that makes sense. Are these two cases meant as examples, or is that
an exhaustive list? Because I would have thought that other cases should
be writing of cached data (when writeback caching is enabled), and
asynchronous I/O from userspace...?


I think that's exhaustive list, but I can miss something.

As for writing of cached data, that definitely doesn't go through 
background requests. Here we rely on flusher: fuse will allocate as many 
requests as the flusher wants to writeback.


Buffered AIO READs actually block in submit_io until fully processed. So 
it's just another example of "natural" limitation I told above. Buffered 
AIO WRITEs go through writeback mechanics anyway, so here again we rely 
on flusher behaving reasonable. And finally, direct AIO does go through 
fuse background requests as I wrote: "1) async processing of direct IO;"




Also, I am not sure what you mean with async processing of direct
I/O. Shouldn't direct I/O always go directly to the file-system? If so,
how can it be processed asynchronously?


That's a nice optimization we implemented a few years ago: having 
incoming sync direct IO request of 1MB size, kernel fuse splits it into 
eight 128K requests and starts processing them in async manner, waiting 
for the completion of all of them before completing that incoming 1MB 
requests. This boosts performance tremendously if userspace fuse daemon 
is able to efficiently process many requests "in parallel". This 
optimization is implemented using background fuse requests. Otherwise, 
having 1GB incoming request, we would obediently allocate 8K fuse 
requests in one shot -- too dangerous and not good for latency.


Thanks,
Maxim

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

[Maxim Patlasov]

On 11/16/2016 11:19 AM, Nikolaus Rath wrote:


Hi Maxim,

On Nov 15 2016, Maxim Patlasov  wrote:

On 11/15/2016 08:18 AM, Nikolaus Rath wrote:

Could someone explain to me the meaning of the max_background and
congestion_threshold settings of the fuse module?

At first I assumed that max_background specifies the maximum number of
pending requests (i.e., requests that have been send to userspace but
for which no reply was received yet). But looking at fs/fuse/dev.c, it
looks as if not every request is included in this number.

fuse uses max_background for cases where the total number of
simultaneous requests of given type is not limited by some other
natural means. AFAIU, these cases are: 1) async processing of direct
IO; 2) read-ahead. As an example of "natural" limitation: when
userspace process blocks on a sync direct IO read/write, the number of
requests fuse consumed is limited by the number of such processes
(actually their threads). In contrast, if userspace requests 1GB
direct IO read/write, it would be unreasonable to issue 1GB/128K==8192
fuse requests simultaneously. That's where max_background steps in.

Ah, that makes sense. Are these two cases meant as examples, or is that
an exhaustive list? Because I would have thought that other cases should
be writing of cached data (when writeback caching is enabled), and
asynchronous I/O from userspace...?


I think that's exhaustive list, but I can miss something.

As for writing of cached data, that definitely doesn't go through 
background requests. Here we rely on flusher: fuse will allocate as many 
requests as the flusher wants to writeback.


Buffered AIO READs actually block in submit_io until fully processed. So 
it's just another example of "natural" limitation I told above. Buffered 
AIO WRITEs go through writeback mechanics anyway, so here again we rely 
on flusher behaving reasonable. And finally, direct AIO does go through 
fuse background requests as I wrote: "1) async processing of direct IO;"




Also, I am not sure what you mean with async processing of direct
I/O. Shouldn't direct I/O always go directly to the file-system? If so,
how can it be processed asynchronously?


That's a nice optimization we implemented a few years ago: having 
incoming sync direct IO request of 1MB size, kernel fuse splits it into 
eight 128K requests and starts processing them in async manner, waiting 
for the completion of all of them before completing that incoming 1MB 
requests. This boosts performance tremendously if userspace fuse daemon 
is able to efficiently process many requests "in parallel". This 
optimization is implemented using background fuse requests. Otherwise, 
having 1GB incoming request, we would obediently allocate 8K fuse 
requests in one shot -- too dangerous and not good for latency.


Thanks,
Maxim

Re: [PATCH] x86: add UMIP support

[Ingo Molnar]

* Jan Beulich  wrote:

> This is a small aid to security, hiding in particular the kernel address
> information otherwise available through SGDT/SIDT.
> 
> Signed-off-by: Jan Beulich 
> ---
> Main question here is whether to limit this to 64-bit (or at least
> !CONFIG_VM86) for the time being, or to disable it while running VM86
> mode code: Such code isn't unlikely to use SMSW (and one of SGDT/SIDT)
> to figure out whether it's running on an i286 or i386, as the EFLAGS
> based method recommended by Intel's SDM can't be relied upon there.
> ---
>  Documentation/kernel-parameters.txt |4 
>  arch/x86/include/asm/cpufeatures.h  |1 +
>  arch/x86/include/uapi/asm/processor-flags.h |2 ++
>  arch/x86/kernel/cpu/common.c|   16 +++-
>  4 files changed, 22 insertions(+), 1 deletion(-)

Note that similar patches have been submitted a week ago:

  https://lkml.org/lkml/2016/11/8/68

Thanks,

Ingo

Re: [PATCH] x86: add UMIP support

[Ingo Molnar]

* Jan Beulich  wrote:

> This is a small aid to security, hiding in particular the kernel address
> information otherwise available through SGDT/SIDT.
> 
> Signed-off-by: Jan Beulich 
> ---
> Main question here is whether to limit this to 64-bit (or at least
> !CONFIG_VM86) for the time being, or to disable it while running VM86
> mode code: Such code isn't unlikely to use SMSW (and one of SGDT/SIDT)
> to figure out whether it's running on an i286 or i386, as the EFLAGS
> based method recommended by Intel's SDM can't be relied upon there.
> ---
>  Documentation/kernel-parameters.txt |4 
>  arch/x86/include/asm/cpufeatures.h  |1 +
>  arch/x86/include/uapi/asm/processor-flags.h |2 ++
>  arch/x86/kernel/cpu/common.c|   16 +++-
>  4 files changed, 22 insertions(+), 1 deletion(-)

Note that similar patches have been submitted a week ago:

  https://lkml.org/lkml/2016/11/8/68

Thanks,

Ingo

Re: [PATCH] Fix: disable sys_membarrier when nohz_full is enabled

[Lai Jiangshan]

On Fri, Nov 4, 2016 at 12:29 AM, Mathieu Desnoyers
 wrote:
> Userspace applications should be allowed to expect the membarrier system
> call with MEMBARRIER_CMD_SHARED command to issue memory barriers on
> nohz_full CPUs, but synchronize_sched() does not take those into
> account.
>
> Given that we do not want unrelated processes to be able to affect
> real-time sensitive nohz_full CPUs, simply return ENOSYS when membarrier
> is invoked on a kernel with enabled nohz_full CPUs.
>
> Signed-off-by: Mathieu Desnoyers 
> CC: "Paul E. McKenney" 
> CC: Josh Triplett 
> CC: Steven Rostedt 
> CC: Lai Jiangshan 
> CC: [3.10+]
> ---
>  kernel/membarrier.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/kernel/membarrier.c b/kernel/membarrier.c
> index 536c727..9f9284f 100644
> --- a/kernel/membarrier.c
> +++ b/kernel/membarrier.c
> @@ -16,6 +16,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  /*
>   * Bitmask made from a "or" of all commands within enum membarrier_cmd,
> @@ -51,6 +52,9 @@
>   */
>  SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
>  {
> +   /* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
> +   if (tick_nohz_full_enabled())
> +   return -ENOSYS;

I guess this code needs to be moved down into the branch of
"case MEMBARRIER_CMD_SHARED" to match its comment.

Acked-by: Lai Jiangshan 

But I'm afraid, in the future, tick_nohz_full will become a default y
feature. thus it makes sys_membarrier() always disabled. we might
need a new MEMBARRIER_CMD_XXX to handle it?

thanks,
Lai

Re: [PATCH] Fix: disable sys_membarrier when nohz_full is enabled

[Lai Jiangshan]

On Fri, Nov 4, 2016 at 12:29 AM, Mathieu Desnoyers
 wrote:
> Userspace applications should be allowed to expect the membarrier system
> call with MEMBARRIER_CMD_SHARED command to issue memory barriers on
> nohz_full CPUs, but synchronize_sched() does not take those into
> account.
>
> Given that we do not want unrelated processes to be able to affect
> real-time sensitive nohz_full CPUs, simply return ENOSYS when membarrier
> is invoked on a kernel with enabled nohz_full CPUs.
>
> Signed-off-by: Mathieu Desnoyers 
> CC: "Paul E. McKenney" 
> CC: Josh Triplett 
> CC: Steven Rostedt 
> CC: Lai Jiangshan 
> CC: [3.10+]
> ---
>  kernel/membarrier.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/kernel/membarrier.c b/kernel/membarrier.c
> index 536c727..9f9284f 100644
> --- a/kernel/membarrier.c
> +++ b/kernel/membarrier.c
> @@ -16,6 +16,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  /*
>   * Bitmask made from a "or" of all commands within enum membarrier_cmd,
> @@ -51,6 +52,9 @@
>   */
>  SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
>  {
> +   /* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
> +   if (tick_nohz_full_enabled())
> +   return -ENOSYS;

I guess this code needs to be moved down into the branch of
"case MEMBARRIER_CMD_SHARED" to match its comment.

Acked-by: Lai Jiangshan 

But I'm afraid, in the future, tick_nohz_full will become a default y
feature. thus it makes sys_membarrier() always disabled. we might
need a new MEMBARRIER_CMD_XXX to handle it?

thanks,
Lai

Re: [RFC][PATCH] cpufreq: intel_pstate: Support of energy performance hint using HWP

[Viresh Kumar]

Hi Srinivas,

I don't think other platforms need it for now and so it is fine to
add these to the driver itself.

On 15-11-16, 14:59, Srinivas Pandruvada wrote:
> +static ssize_t show_energy_performance_available_preferences(

Maybe a personal preference, but I would have broken the line after
ssize_t instead of where you have done it.

> + struct cpufreq_policy *policy, char *buf)
> +{
> +static struct freq_attr *hwp_cpufreq_attrs[] = {
> + _performance_preference,
> + _performance_available_preferences,
> + NULL,
> +};

What about adding these to intel_pstate_attr_group instead ?

-- 
viresh

Re: [RFC][PATCH] cpufreq: intel_pstate: Support of energy performance hint using HWP

[Viresh Kumar]

Hi Srinivas,

I don't think other platforms need it for now and so it is fine to
add these to the driver itself.

On 15-11-16, 14:59, Srinivas Pandruvada wrote:
> +static ssize_t show_energy_performance_available_preferences(

Maybe a personal preference, but I would have broken the line after
ssize_t instead of where you have done it.

> + struct cpufreq_policy *policy, char *buf)
> +{
> +static struct freq_attr *hwp_cpufreq_attrs[] = {
> + _performance_preference,
> + _performance_available_preferences,
> + NULL,
> +};

What about adding these to intel_pstate_attr_group instead ?

-- 
viresh

Re: [v2] cw1200: fix bogus maybe-uninitialized warning

[Kalle Valo]

Arnd Bergmann  wrote:
> On x86, the cw1200 driver produces a rather silly warning about the
> possible use of the 'ret' variable without an initialization
> presumably after being confused by the architecture specific definition
> of WARN_ON:
> 
> drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
> drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> We have already checked that 'count' is larger than 0 here, so
> we know that 'ret' is initialized. Changing the 'for' loop
> into do/while also makes this clear to the compiler.
> 
> Suggested-by: David Laight 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

7fc1503c906f cw1200: fix bogus maybe-uninitialized warning

-- 
https://patchwork.kernel.org/patch/9395413/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v2] cw1200: fix bogus maybe-uninitialized warning

[Kalle Valo]

Arnd Bergmann  wrote:
> On x86, the cw1200 driver produces a rather silly warning about the
> possible use of the 'ret' variable without an initialization
> presumably after being confused by the architecture specific definition
> of WARN_ON:
> 
> drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
> drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> We have already checked that 'count' is larger than 0 here, so
> we know that 'ret' is initialized. Changing the 'for' loop
> into do/while also makes this clear to the compiler.
> 
> Suggested-by: David Laight 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

7fc1503c906f cw1200: fix bogus maybe-uninitialized warning

-- 
https://patchwork.kernel.org/patch/9395413/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[NeilBrown]

On Thu, Nov 17 2016, Mark Brown wrote:

> [ Unknown signature status ]
> On Tue, Nov 15, 2016 at 08:35:13AM +1100, NeilBrown wrote:
>> On Mon, Nov 14 2016, Mark Brown wrote:
>
>> > Conflating the two seems like the whole point here.  We're looking for
>> > something that sits between the power supply code and the USB code and
>> > tells the power supply code what it's allowed to do which is the result
>> > of a combination of physical cable detection and USB protocol.  It seems
>> > reasonable that extcon drivers ought to be part of this but it doesn't
>> > seem like they are the whole story.
>
>> I don't think "between the power supply code and the USB code" is where
>> this thing sits. I think it sits inside the power-supply driver.
>> We already have extcon which sits between the phy and the power_supply
>> code, and the usb_notifier which sits between the USB code and the
>> power supply code.  We don't need another go-between.
>
> ...
>
>> correct determinations and set the current limits itself.  All this
>> could be done entirely internally, without the help of any new
>> subsystem.
>> Do you agree?
>
>> Clearly doing it that way would result in lots of code duplication and
>> would mean that each driver probably gets its own private set of bugs,
>> but it would be possible.  Just undesirable.
>
> I think this is the key here - the fact that it's technically possible
> to implement doesn't really matter if it's sufficiently fiddly and non
> obvious that nobody is actually joining everything up (bits are done
> intermittently but not as a whole as far as I can see).
>
>> So yes, it makes perfect to provide common code which handles the
>> registrations, and captures the events, and translates the different
>> events into current levels and feeds those back to the driver.  This
>> isn't some new subsystem, this is just a resource, provided by a
>> library, that power drivers can allocate and initialize if the want to.
>
> To me that's pretty much what's being done here, the code just happens
> to sit in USB instead but fundamentally it's just a blob of helper code,
> you could replace the notifier with a callback if that's the big concern
> here.

It is a lot more than "just a blob of helper code".  It duplicates
existing infrastructure instead of fixing and using the
infrastructure but I've said all this before.  Repeatedly.

NeilBrown


signature.asc
Description: PGP signature

Re: wireless: fix bogus maybe-uninitialized warning

[Kalle Valo]

Arnd Bergmann  wrote:
> The hostap_80211_rx() function is supposed to set up the mac addresses
> for four possible cases, based on two bits of input data. For
> some reason, gcc decides that it's possible that none of the these
> four cases apply and the addresses remain uninitialized:
> 
> drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function 
> ‘hostap_80211_rx’:
> arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’:
> arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)+4)’ may be 
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This warning is clearly nonsense, but changing the last case into
> 'default' makes it obvious to the compiler too, which avoids the
> warning and probably leads to better object code too.
> 
> The same code is duplicated several times in the kernel, so this
> patch uses the same workaround for all copies. The exact configuration
> was hit only very rarely in randconfig builds and I only saw it
> in three drivers, but I assume that all of them are potentially
> affected, and it's better to keep the code consistent.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

10f3366b4d89 wireless: fix bogus maybe-uninitialized warning

-- 
https://patchwork.kernel.org/patch/9392385/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] Support for perf on AMD family17h processors

[Ingo Molnar]

* Janakarajan Natarajan  wrote:

> This patch enables perf core PMU support for AMD family17h processors. In 
> family17h, there is no PMC-event constraint. All events, irrespective of the 
> type, can be measured using any of the performance counters.

BTW., that's a very nice hardware design that simplifies counter constraints 
and 
scheduling!

Does Fam17h have 6 generic counters per core, like Fam15h?

Thanks,

Ingo

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[NeilBrown]

On Thu, Nov 17 2016, Mark Brown wrote:

> [ Unknown signature status ]
> On Tue, Nov 15, 2016 at 08:35:13AM +1100, NeilBrown wrote:
>> On Mon, Nov 14 2016, Mark Brown wrote:
>
>> > Conflating the two seems like the whole point here.  We're looking for
>> > something that sits between the power supply code and the USB code and
>> > tells the power supply code what it's allowed to do which is the result
>> > of a combination of physical cable detection and USB protocol.  It seems
>> > reasonable that extcon drivers ought to be part of this but it doesn't
>> > seem like they are the whole story.
>
>> I don't think "between the power supply code and the USB code" is where
>> this thing sits. I think it sits inside the power-supply driver.
>> We already have extcon which sits between the phy and the power_supply
>> code, and the usb_notifier which sits between the USB code and the
>> power supply code.  We don't need another go-between.
>
> ...
>
>> correct determinations and set the current limits itself.  All this
>> could be done entirely internally, without the help of any new
>> subsystem.
>> Do you agree?
>
>> Clearly doing it that way would result in lots of code duplication and
>> would mean that each driver probably gets its own private set of bugs,
>> but it would be possible.  Just undesirable.
>
> I think this is the key here - the fact that it's technically possible
> to implement doesn't really matter if it's sufficiently fiddly and non
> obvious that nobody is actually joining everything up (bits are done
> intermittently but not as a whole as far as I can see).
>
>> So yes, it makes perfect to provide common code which handles the
>> registrations, and captures the events, and translates the different
>> events into current levels and feeds those back to the driver.  This
>> isn't some new subsystem, this is just a resource, provided by a
>> library, that power drivers can allocate and initialize if the want to.
>
> To me that's pretty much what's being done here, the code just happens
> to sit in USB instead but fundamentally it's just a blob of helper code,
> you could replace the notifier with a callback if that's the big concern
> here.

It is a lot more than "just a blob of helper code".  It duplicates
existing infrastructure instead of fixing and using the
infrastructure but I've said all this before.  Repeatedly.

NeilBrown


signature.asc
Description: PGP signature

Re: wireless: fix bogus maybe-uninitialized warning

[Kalle Valo]

Arnd Bergmann  wrote:
> The hostap_80211_rx() function is supposed to set up the mac addresses
> for four possible cases, based on two bits of input data. For
> some reason, gcc decides that it's possible that none of the these
> four cases apply and the addresses remain uninitialized:
> 
> drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function 
> ‘hostap_80211_rx’:
> arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’:
> arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)+4)’ may be 
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This warning is clearly nonsense, but changing the last case into
> 'default' makes it obvious to the compiler too, which avoids the
> warning and probably leads to better object code too.
> 
> The same code is duplicated several times in the kernel, so this
> patch uses the same workaround for all copies. The exact configuration
> was hit only very rarely in randconfig builds and I only saw it
> in three drivers, but I assume that all of them are potentially
> affected, and it's better to keep the code consistent.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

10f3366b4d89 wireless: fix bogus maybe-uninitialized warning

-- 
https://patchwork.kernel.org/patch/9392385/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] Support for perf on AMD family17h processors

[Ingo Molnar]

* Janakarajan Natarajan  wrote:

> This patch enables perf core PMU support for AMD family17h processors. In 
> family17h, there is no PMC-event constraint. All events, irrespective of the 
> type, can be measured using any of the performance counters.

BTW., that's a very nice hardware design that simplifies counter constraints 
and 
scheduling!

Does Fam17h have 6 generic counters per core, like Fam15h?

Thanks,

Ingo

Re: p54: memset(0) whole array

[Kalle Valo]

Jiri Slaby  wrote:
> gcc 7 complains:
> drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
> drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with 
> length equal to number of elements without multiplication by element size 
> [-Wmemset-elt-size]
> 
> Fix that by passing the correct size to memset.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Christian Lamparter 
> Cc: Kalle Valo 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Acked-by: Christian Lamparter 

Patch applied to wireless-drivers-next.git, thanks.

6f1758178820 p54: memset(0) whole array

-- 
https://patchwork.kernel.org/patch/9376333/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: p54: memset(0) whole array

[Kalle Valo]

Jiri Slaby  wrote:
> gcc 7 complains:
> drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
> drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with 
> length equal to number of elements without multiplication by element size 
> [-Wmemset-elt-size]
> 
> Fix that by passing the correct size to memset.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Christian Lamparter 
> Cc: Kalle Valo 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Acked-by: Christian Lamparter 

Patch applied to wireless-drivers-next.git, thanks.

6f1758178820 p54: memset(0) whole array

-- 
https://patchwork.kernel.org/patch/9376333/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: brcmfmac: print name of connect status event

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This simplifies debugging. Format %s (%u) comes from similar debugging
> message in brcmf_fweh_event_worker.
> 
> Signed-off-by: Rafał Miłecki 

Patch applied to wireless-drivers-next.git, thanks.

e1c122d55f9e brcmfmac: print name of connect status event

-- 
https://patchwork.kernel.org/patch/9376147/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: brcmfmac: print name of connect status event

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This simplifies debugging. Format %s (%u) comes from similar debugging
> message in brcmf_fweh_event_worker.
> 
> Signed-off-by: Rafał Miłecki 

Patch applied to wireless-drivers-next.git, thanks.

e1c122d55f9e brcmfmac: print name of connect status event

-- 
https://patchwork.kernel.org/patch/9376147/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wlcore: Allow scans when in AP mode

[Kalle Valo]

Xander Huff  wrote:
> From: James Minor 
> 
> When in AP mode, scans can be done without changing firmware to
> the multi-role firmware. Allow the interface to scan if forced
> in the scan request.
> 
> Signed-off-by: James Minor 
> Signed-off-by: Xander Huff 
> Reviewed-by: Ben Shelton 
> Reviewed-by: Jaeden Amero 

Patch applied to wireless-drivers-next.git, thanks.

87016f5eb1a3 wlcore: Allow scans when in AP mode

-- 
https://patchwork.kernel.org/patch/9366467/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wlcore: Allow scans when in AP mode

[Kalle Valo]

Xander Huff  wrote:
> From: James Minor 
> 
> When in AP mode, scans can be done without changing firmware to
> the multi-role firmware. Allow the interface to scan if forced
> in the scan request.
> 
> Signed-off-by: James Minor 
> Signed-off-by: Xander Huff 
> Reviewed-by: Ben Shelton 
> Reviewed-by: Jaeden Amero 

Patch applied to wireless-drivers-next.git, thanks.

87016f5eb1a3 wlcore: Allow scans when in AP mode

-- 
https://patchwork.kernel.org/patch/9366467/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma

[Alexey Kardashevskiy]

On 17/11/16 17:12, Alex Williamson wrote:
> On Thu, 17 Nov 2016 16:41:14 +1100
> Alexey Kardashevskiy  wrote:
> 
>> On 17/11/16 07:46, Kirti Wankhede wrote:
>>> Add task structure to vfio_dma structure. Task structure is used for:
>>> - During DMA_UNMAP, same task who mapped it or other task who shares same
>>> address space is allowed to unmap, otherwise unmap fails.
>>> QEMU maps few iova ranges initially, then fork threads and from the child
>>> thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>> address space, DMA_UNMAP is successful.
>>> - Avoid accessing struct mm while process is exiting by acquiring
>>> reference of task's mm during page accounting.
>>> - It is also used to get task mlock capability and rlimit for mlock.
>>>
>>> Signed-off-by: Kirti Wankhede 
>>> Signed-off-by: Neo Jia 
>>> Reviewed-by: Dong Jia Shi   
>>
>>
>> I keep whinging that @mm should be referenced, not @current but you keep
>> referencing @current even if you only need @mm and you are not telling why
>> - and I am wondering what I am missing here? Something else will be used
>> from @task later, besides just @mm?
> 
> Yes, we reference @current from vfio_dma_do_map() and this is stored
> on the struct vfio_dma.  A reference to current is held because the
> external page pinning in vfio_pin_page_external() needs to test the
> capabilities of the task for CAP_IPC_LOCK to know whether locked memory

Ah, that's it - capable(CAP_IPC_LOCK) is checking @current, missed that.


> limits are in effect for the task even when it's not @current (ie. an
> asynchronous call from the vendor driver regardless of what task is
> currently running).  There are also various get_task_mm() taken
> temporarily when we're working with the mm of that task.  Do you spot
> any issues with this behavior? Thanks,

No, now I am fine, thanks!


-- 
Alexey

Re: [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma

[Alexey Kardashevskiy]

On 17/11/16 17:12, Alex Williamson wrote:
> On Thu, 17 Nov 2016 16:41:14 +1100
> Alexey Kardashevskiy  wrote:
> 
>> On 17/11/16 07:46, Kirti Wankhede wrote:
>>> Add task structure to vfio_dma structure. Task structure is used for:
>>> - During DMA_UNMAP, same task who mapped it or other task who shares same
>>> address space is allowed to unmap, otherwise unmap fails.
>>> QEMU maps few iova ranges initially, then fork threads and from the child
>>> thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>> address space, DMA_UNMAP is successful.
>>> - Avoid accessing struct mm while process is exiting by acquiring
>>> reference of task's mm during page accounting.
>>> - It is also used to get task mlock capability and rlimit for mlock.
>>>
>>> Signed-off-by: Kirti Wankhede 
>>> Signed-off-by: Neo Jia 
>>> Reviewed-by: Dong Jia Shi   
>>
>>
>> I keep whinging that @mm should be referenced, not @current but you keep
>> referencing @current even if you only need @mm and you are not telling why
>> - and I am wondering what I am missing here? Something else will be used
>> from @task later, besides just @mm?
> 
> Yes, we reference @current from vfio_dma_do_map() and this is stored
> on the struct vfio_dma.  A reference to current is held because the
> external page pinning in vfio_pin_page_external() needs to test the
> capabilities of the task for CAP_IPC_LOCK to know whether locked memory

Ah, that's it - capable(CAP_IPC_LOCK) is checking @current, missed that.


> limits are in effect for the task even when it's not @current (ie. an
> asynchronous call from the vendor driver regardless of what task is
> currently running).  There are also various get_task_mm() taken
> temporarily when we're working with the mm of that task.  Do you spot
> any issues with this behavior? Thanks,

No, now I am fine, thanks!


-- 
Alexey

Re: linux-next: manual merge of the rpmsg tree with the slave-dma tree

[Bjorn Andersson]

On Sun 13 Nov 21:20 PST 2016, Stephen Rothwell wrote:

> Hi Bjorn,
> 

Hi Stephen,

> Today's linux-next merge of the rpmsg tree got a conflict in:
> 
>   drivers/remoteproc/Kconfig
> 
> between commit:
> 
>   bb6869b21478 ("remoteproc: st_slim_rproc: add a slimcore rproc driver")
> 
> from the slave-dma tree and commit:
> 
>   99d93470dcb4 ("remoteproc: qcom_wcnss: Fix circular module dependency")
> 
> from the rpmsg tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks for the fix and the report of the dependency issue of
QCOM_ADSP_PIL.

I have merged the problematic topic branch from Vinod into my tree and
fixed up the discrepancies. So you should be able to drop this
workaround and you should not see the ADSP issue.

Regards,
Bjorn

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/remoteproc/Kconfig
> index 14d5d2d43a38,5fcbefcb8636..
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@@ -100,10 -95,9 +96,9 @@@ config QCOM_WCNSS_PI
>   tristate "Qualcomm WCNSS Peripheral Image Loader"
>   depends on OF && ARCH_QCOM
>   depends on QCOM_SMEM
>  +depends on REMOTEPROC
>   select QCOM_MDT_LOADER
>   select QCOM_SCM
> - select QCOM_WCNSS_IRIS
>  -select REMOTEPROC
>   help
> Say y here to support the Peripheral Image Loader for the Qualcomm
> Wireless Connectivity Subsystem.

Re: linux-next: manual merge of the rpmsg tree with the slave-dma tree

[Bjorn Andersson]

On Sun 13 Nov 21:20 PST 2016, Stephen Rothwell wrote:

> Hi Bjorn,
> 

Hi Stephen,

> Today's linux-next merge of the rpmsg tree got a conflict in:
> 
>   drivers/remoteproc/Kconfig
> 
> between commit:
> 
>   bb6869b21478 ("remoteproc: st_slim_rproc: add a slimcore rproc driver")
> 
> from the slave-dma tree and commit:
> 
>   99d93470dcb4 ("remoteproc: qcom_wcnss: Fix circular module dependency")
> 
> from the rpmsg tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks for the fix and the report of the dependency issue of
QCOM_ADSP_PIL.

I have merged the problematic topic branch from Vinod into my tree and
fixed up the discrepancies. So you should be able to drop this
workaround and you should not see the ADSP issue.

Regards,
Bjorn

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/remoteproc/Kconfig
> index 14d5d2d43a38,5fcbefcb8636..
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@@ -100,10 -95,9 +96,9 @@@ config QCOM_WCNSS_PI
>   tristate "Qualcomm WCNSS Peripheral Image Loader"
>   depends on OF && ARCH_QCOM
>   depends on QCOM_SMEM
>  +depends on REMOTEPROC
>   select QCOM_MDT_LOADER
>   select QCOM_SCM
> - select QCOM_WCNSS_IRIS
>  -select REMOTEPROC
>   help
> Say y here to support the Peripheral Image Loader for the Qualcomm
> Wireless Connectivity Subsystem.

Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Bjorn Andersson]

On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:

> On Mon, Nov 07, 2016 at 01:57:35PM +, Peter Griffin wrote:
> > > 
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > > 
> > > So the remoteproc parts now has to go through my tree.
> > 
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that 
> > branch into
> > your respective trees.
> 
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
> 

Hi Vinod,

It looks like you reverted the wrong Kconfig fix, the one I objected to
was the change in drivers/remoteproc, not the one in drivers/dma.

The ST_FMDA depends on functions exposed by REMOTEPROC and
ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
guys made user selectable - and as such should not be selected - but I
think we should move forward and get everything merged and then we can
go back and figure out how this should be addressed (or left alone?).

I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
now broken drivers/remoteproc/Kconfig.

We do however both need to revert the revert or there will be link
errors if you build the dma driver with remoteproc=n. If you do this I
can merge the topic once more and we'll keep the set of changes in sync.

Regards,
Bjorn

Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Bjorn Andersson]

On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:

> On Mon, Nov 07, 2016 at 01:57:35PM +, Peter Griffin wrote:
> > > 
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > > 
> > > So the remoteproc parts now has to go through my tree.
> > 
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that 
> > branch into
> > your respective trees.
> 
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
> 

Hi Vinod,

It looks like you reverted the wrong Kconfig fix, the one I objected to
was the change in drivers/remoteproc, not the one in drivers/dma.

The ST_FMDA depends on functions exposed by REMOTEPROC and
ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
guys made user selectable - and as such should not be selected - but I
think we should move forward and get everything merged and then we can
go back and figure out how this should be addressed (or left alone?).

I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
now broken drivers/remoteproc/Kconfig.

We do however both need to revert the revert or there will be link
errors if you build the dma driver with remoteproc=n. If you do this I
can merge the topic once more and we'll keep the set of changes in sync.

Regards,
Bjorn

Re: [PATCH v2] cpufreq: Avoid a couple of races related to cpufreq_cpu_get()

[Viresh Kumar]

Hi Rafael,

I still have few concerns that I would like to share ..

On 16-11-16, 03:38, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The cpumask_test_cpu() check in cpufreq_cpu_get_raw() is sort of
> pointless, because it may be racy with respect to CPU online/offline
> which sets/clears the policy->cpus mask.
> 
> Some of the races resulting from that are benign (worst case, stale
> values may be returned from some sysfs attribute for a relatively
> short period), but some of them may lead to invocations of low-level
> cpufreq driver callbacks for offline CPUs which is not guaranteed to
> work in general.
> 
> For this reason, move the cpumask_test_cpu() check away from
> cpufreq_cpu_get_raw() and reserve it for the ondemand governor,
> which calls it for online CPUs only and with CPU online/offline
> locked anyway, and make the other callers of it use the per-CPU
> variable whose value is returned by it directly.
> 
> With that, add the cpumask_test_cpu() check to cpufreq_generic_get()
> to preserve its current behavior for offline CPUs and to the callers
> of cpufreq_cpu_get().  There, in the cases when the races might
> lead to invocations of driver callbacks for offline CPUs, put it
> under policy->rwsem.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> -> v2:
>  * Modify the changelog to make it better explain what's going on.
>  * Add the missing cpumask_test_cpu() check to cpufreq_offline().
> 
> ---
>  drivers/cpufreq/cpufreq.c |   52 
> --
>  1 file changed, 37 insertions(+), 15 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -65,6 +65,12 @@ static struct cpufreq_driver *cpufreq_dr
>  static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>  static DEFINE_RWLOCK(cpufreq_driver_lock);
>  
> +struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> +{
> + return per_cpu(cpufreq_cpu_data, cpu);
> +}
> +EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
> +
>  /* Flag to suspend/resume CPUFreq governors */
>  static bool cpufreq_suspended;
>  
> @@ -192,19 +198,12 @@ int cpufreq_generic_init(struct cpufreq_
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_generic_init);
>  
> -struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> -{
> - struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> -
> - return policy && cpumask_test_cpu(cpu, policy->cpus) ? policy : NULL;
> -}
> -EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
> -
>  unsigned int cpufreq_generic_get(unsigned int cpu)
>  {
> - struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
> + struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
>  
> - if (!policy || IS_ERR(policy->clk)) {
> + if (!policy || !cpumask_test_cpu(cpu, policy->cpus) ||
> + IS_ERR(policy->clk)) {
>   pr_err("%s: No %s associated to cpu: %d\n",
>  __func__, policy ? "clk" : "policy", cpu);
>   return 0;
> @@ -240,7 +239,7 @@ struct cpufreq_policy *cpufreq_cpu_get(u
>  
>   if (cpufreq_driver) {
>   /* get the CPU */
> - policy = cpufreq_cpu_get_raw(cpu);
> + policy = per_cpu(cpufreq_cpu_data, cpu);

There are many other users of cpufreq_cpu_get() outside of cpufreq
core which aren't updated in this patch.

>   if (policy)
>   kobject_get(>kobj);
>   }
> @@ -1328,13 +1327,19 @@ static int cpufreq_offline(unsigned int
>  
>   pr_debug("%s: unregistering CPU %u\n", __func__, cpu);
>  
> - policy = cpufreq_cpu_get_raw(cpu);
> + policy = per_cpu(cpufreq_cpu_data, cpu);
>   if (!policy) {
>   pr_debug("%s: No cpu_data found\n", __func__);
>   return 0;
>   }
>  
>   down_write(>rwsem);
> +
> + if (!cpumask_test_cpu(cpu, policy->cpus)) {
> + pr_debug("%s: CPU %u is offline\n", __func__, cpu);
> + goto unlock;
> + }
> +

Is it really important for this change to be present within the lock?
I am not 100% sure.

cpufreq_offline() can get called via two paths:
- CPU hot-unplug
- cpufreq driver getting unregistered

The second path calls get_online_cpus() and so these two shall never
race against each other. And so it shall not be possible that
policy->cpus is getting cleared for 'cpu' while this routine is
running.

Though I agree that this check is required for sure, but perhaps
without the lock. Which also means that cpufreq_cpu_get_raw() wasn't
required to get updated considering this case.

>   if (has_target())
>   cpufreq_stop_governor(policy);
>  
> @@ -1455,7 +1460,9 @@ unsigned int cpufreq_quick_get(unsigned
>  
>   policy = cpufreq_cpu_get(cpu);
>   if (policy) {
> - ret_freq = policy->cur;
> + 

Re: [PATCH v2] cpufreq: Avoid a couple of races related to cpufreq_cpu_get()

[Viresh Kumar]

Hi Rafael,

I still have few concerns that I would like to share ..

On 16-11-16, 03:38, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The cpumask_test_cpu() check in cpufreq_cpu_get_raw() is sort of
> pointless, because it may be racy with respect to CPU online/offline
> which sets/clears the policy->cpus mask.
> 
> Some of the races resulting from that are benign (worst case, stale
> values may be returned from some sysfs attribute for a relatively
> short period), but some of them may lead to invocations of low-level
> cpufreq driver callbacks for offline CPUs which is not guaranteed to
> work in general.
> 
> For this reason, move the cpumask_test_cpu() check away from
> cpufreq_cpu_get_raw() and reserve it for the ondemand governor,
> which calls it for online CPUs only and with CPU online/offline
> locked anyway, and make the other callers of it use the per-CPU
> variable whose value is returned by it directly.
> 
> With that, add the cpumask_test_cpu() check to cpufreq_generic_get()
> to preserve its current behavior for offline CPUs and to the callers
> of cpufreq_cpu_get().  There, in the cases when the races might
> lead to invocations of driver callbacks for offline CPUs, put it
> under policy->rwsem.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> -> v2:
>  * Modify the changelog to make it better explain what's going on.
>  * Add the missing cpumask_test_cpu() check to cpufreq_offline().
> 
> ---
>  drivers/cpufreq/cpufreq.c |   52 
> --
>  1 file changed, 37 insertions(+), 15 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -65,6 +65,12 @@ static struct cpufreq_driver *cpufreq_dr
>  static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>  static DEFINE_RWLOCK(cpufreq_driver_lock);
>  
> +struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> +{
> + return per_cpu(cpufreq_cpu_data, cpu);
> +}
> +EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
> +
>  /* Flag to suspend/resume CPUFreq governors */
>  static bool cpufreq_suspended;
>  
> @@ -192,19 +198,12 @@ int cpufreq_generic_init(struct cpufreq_
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_generic_init);
>  
> -struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
> -{
> - struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> -
> - return policy && cpumask_test_cpu(cpu, policy->cpus) ? policy : NULL;
> -}
> -EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
> -
>  unsigned int cpufreq_generic_get(unsigned int cpu)
>  {
> - struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
> + struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
>  
> - if (!policy || IS_ERR(policy->clk)) {
> + if (!policy || !cpumask_test_cpu(cpu, policy->cpus) ||
> + IS_ERR(policy->clk)) {
>   pr_err("%s: No %s associated to cpu: %d\n",
>  __func__, policy ? "clk" : "policy", cpu);
>   return 0;
> @@ -240,7 +239,7 @@ struct cpufreq_policy *cpufreq_cpu_get(u
>  
>   if (cpufreq_driver) {
>   /* get the CPU */
> - policy = cpufreq_cpu_get_raw(cpu);
> + policy = per_cpu(cpufreq_cpu_data, cpu);

There are many other users of cpufreq_cpu_get() outside of cpufreq
core which aren't updated in this patch.

>   if (policy)
>   kobject_get(>kobj);
>   }
> @@ -1328,13 +1327,19 @@ static int cpufreq_offline(unsigned int
>  
>   pr_debug("%s: unregistering CPU %u\n", __func__, cpu);
>  
> - policy = cpufreq_cpu_get_raw(cpu);
> + policy = per_cpu(cpufreq_cpu_data, cpu);
>   if (!policy) {
>   pr_debug("%s: No cpu_data found\n", __func__);
>   return 0;
>   }
>  
>   down_write(>rwsem);
> +
> + if (!cpumask_test_cpu(cpu, policy->cpus)) {
> + pr_debug("%s: CPU %u is offline\n", __func__, cpu);
> + goto unlock;
> + }
> +

Is it really important for this change to be present within the lock?
I am not 100% sure.

cpufreq_offline() can get called via two paths:
- CPU hot-unplug
- cpufreq driver getting unregistered

The second path calls get_online_cpus() and so these two shall never
race against each other. And so it shall not be possible that
policy->cpus is getting cleared for 'cpu' while this routine is
running.

Though I agree that this check is required for sure, but perhaps
without the lock. Which also means that cpufreq_cpu_get_raw() wasn't
required to get updated considering this case.

>   if (has_target())
>   cpufreq_stop_governor(policy);
>  
> @@ -1455,7 +1460,9 @@ unsigned int cpufreq_quick_get(unsigned
>  
>   policy = cpufreq_cpu_get(cpu);
>   if (policy) {
> - ret_freq = policy->cur;
> + if (cpumask_test_cpu(cpu, policy->cpus))
> + 

[patch v6 1/1] i2c: add master driver for mellanox systems

[vadimp]

From: Vadim Pasternak 

Device driver for Mellanox I2C controller logic, implemented in Lattice
CPLD device.
Device supports:
 - Master mode
 - One physical bus
 - Polling mode

The Kconfig currently controlling compilation of this code is:
drivers/i2c/busses/Kconfig:config I2C_MLXCPLD

Signed-off-by: Michael Shych 
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
Reviewed-by: Vladimir Zapolskiy 
---
v5->v6:
 Comments pointed out by Vladimir:
 - Drop the line with module path from the header;
 - In description of mlxcpld_i2c_priv remove lpc_gen_dec_reg asnd dev_id;
 - In mlxcpld_i2c_priv change type of the filed base_addr to u16 for
   the alignment with in/out and remove unused dev_id;
 - Fix misspelling in comment for mlxcpld_i2c_invalid_len;
 - Remove comment regarding EBUSY return in mlxcpld_i2c_check_busy;
 - Use sizeof of the target storage in allocation in probe routine;
v4->v5:
 Comments pointed out by Vladimir:
 - Remove "default n" from Kconfig;
 - Fix the comments for timeout and pool time;
 - Optimize error flow in mlxcpld_i2c_probe;
v3->v4:
 Comments pointed out by Vladimir:
 - Set default to no in Kconfig;
 - Make mlxcpld_i2c_plat_dev static and add empty line before the
   declaration;
 - In function mlxcpld_i2c_invalid_len remove (msg->len < 0), since len is
   unsigned;
 - Remove unused symbol mlxcpld_i2c_plat_dev;
 - Remove extra spaces in comments to mlxcpld_i2c_check_msg_params;
 - Remove unnecessary round braces in mlxcpld_i2c_set_transf_data;
 - Remove the assignment of 'i' variable in mlxcpld_i2c_wait_for_tc;
 - Add extra line in mlxcpld_i2c_xfer;
 - Move assignment of the adapter's fields retries and nr inside
   mlxcpld_i2c_adapter declaration;
v2->v3:
 Comments pointed out by Vladimir:
 - Use tab symbol as indentation in Kconfig
 - Add the Kconfig section preserving the alphabetical order - added
   within "Other I2C/SMBus bus drivers" after I2C_ELEKTOR (but after this
   sections others are not follow alphabetical);
 - Change license to dual;
 - Replace ADRR with ADDR in macros;
 - Remove unused macros: MLXCPLD_LPCI2C_LPF_DFLT,
   MLXCPLD_LPCI2C_HALF_CYC_100, MLXCPLD_LPCI2C_I2C_HOLD_100,
   MLXCPLD_LPCI2C_HALF_CYC_REG, MLXCPLD_LPCI2C_I2C_HOLD_REG;
 - Fix checkpatch warnings (**/ and the end of comment);
 - Add empty line before structures mlxcpld_i2c_regs,
   mlxcpld_i2c_curr_transf, mlxcpld_i2c_priv;
 - Remove unused structure mlxcpld_i2c_regs;
 - Remove from mlxcpld_i2c_priv the next fields:
   retr_num, poll_time, block_sz, xfer_to; use instead macros
   respectively: MLXCPLD_I2C_RETR_NUM, MLXCPLD_I2C_POLL_TIME,
   MLXCPLD_I2C_DATA_REG_SZ, MLXCPLD_I2C_XFER_TO;
 - In mlxcpld_i2c_invalid_len remove unnecessary else;
 - Optimize mlxcpld_i2c_set_transf_data;
 - mlxcpld_i2c_reset - add empty lines after/before mutex
   lock/unlock;
 - mlxcpld_i2c_wait_for_free - cover case timeout is equal
   MLXCPLD_I2C_XFER_TO;
 - mlxcpld_i2c_wait_for_tc:
   - Do not assign err in declaration (also err is removed);
   - Insert empty line before case MLXCPLD_LPCI2C_ACK_IND;
   - inside case MLXCPLD_LPCI2C_ACK_IND - avoid unnecessary
 indentation;
   - Remove case MLXCPLD_LPCI2C_ERR_IND and remove this macro;
 - Add empty lines in mlxcpld_i2c_xfer before/after mutex_lock/
   mutex_unlock;
 - In mlxcpld_i2c_probe add emtpy line after platform_set_drvdata;
 - Replace platfrom handle pdev in mlxcpld_i2c_priv with the pointer
   to the structure device;
 - Place assignment of base_addr near the others;
 - Enclose e-mail with <>;
 Fixes added by Vadim:
 - Change structure description format according to
   Documentation/kernel-documentation.rst guideline;
 - mlxcpld_i2c_wait_for_tc: return error if status reaches default case;
v1->v2
 Fixes added by Vadim:
 - Put new record in Makefile in alphabetic order;
 - Remove http://www.mellanox.com from MAINTAINERS record;
---
 Documentation/i2c/busses/i2c-mlxcpld |  47 +++
 MAINTAINERS  |   8 +
 drivers/i2c/busses/Kconfig   |  11 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-mlxcpld.c | 544 +++
 5 files changed, 611 insertions(+)
 create mode 100644 Documentation/i2c/busses/i2c-mlxcpld
 create mode 100644 drivers/i2c/busses/i2c-mlxcpld.c

diff --git a/Documentation/i2c/busses/i2c-mlxcpld 
b/Documentation/i2c/busses/i2c-mlxcpld
new file mode 100644
index 000..0f8678a
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-mlxcpld
@@ -0,0 +1,47 @@
+Driver i2c-mlxcpld
+
+Author: Michael Shych 
+
+This is a for Mellanox I2C controller logic, implemented in Lattice CPLD
+device.
+Device supports:
+ - Master mode.
+ - One physical bus.
+ - Polling mode.
+
+This controller is equipped within the next Mellanox systems:
+"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
+"msn2740", "msn2100".
+
+The next transaction 

[patch v6 1/1] i2c: add master driver for mellanox systems

[vadimp]

From: Vadim Pasternak 

Device driver for Mellanox I2C controller logic, implemented in Lattice
CPLD device.
Device supports:
 - Master mode
 - One physical bus
 - Polling mode

The Kconfig currently controlling compilation of this code is:
drivers/i2c/busses/Kconfig:config I2C_MLXCPLD

Signed-off-by: Michael Shych 
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
Reviewed-by: Vladimir Zapolskiy 
---
v5->v6:
 Comments pointed out by Vladimir:
 - Drop the line with module path from the header;
 - In description of mlxcpld_i2c_priv remove lpc_gen_dec_reg asnd dev_id;
 - In mlxcpld_i2c_priv change type of the filed base_addr to u16 for
   the alignment with in/out and remove unused dev_id;
 - Fix misspelling in comment for mlxcpld_i2c_invalid_len;
 - Remove comment regarding EBUSY return in mlxcpld_i2c_check_busy;
 - Use sizeof of the target storage in allocation in probe routine;
v4->v5:
 Comments pointed out by Vladimir:
 - Remove "default n" from Kconfig;
 - Fix the comments for timeout and pool time;
 - Optimize error flow in mlxcpld_i2c_probe;
v3->v4:
 Comments pointed out by Vladimir:
 - Set default to no in Kconfig;
 - Make mlxcpld_i2c_plat_dev static and add empty line before the
   declaration;
 - In function mlxcpld_i2c_invalid_len remove (msg->len < 0), since len is
   unsigned;
 - Remove unused symbol mlxcpld_i2c_plat_dev;
 - Remove extra spaces in comments to mlxcpld_i2c_check_msg_params;
 - Remove unnecessary round braces in mlxcpld_i2c_set_transf_data;
 - Remove the assignment of 'i' variable in mlxcpld_i2c_wait_for_tc;
 - Add extra line in mlxcpld_i2c_xfer;
 - Move assignment of the adapter's fields retries and nr inside
   mlxcpld_i2c_adapter declaration;
v2->v3:
 Comments pointed out by Vladimir:
 - Use tab symbol as indentation in Kconfig
 - Add the Kconfig section preserving the alphabetical order - added
   within "Other I2C/SMBus bus drivers" after I2C_ELEKTOR (but after this
   sections others are not follow alphabetical);
 - Change license to dual;
 - Replace ADRR with ADDR in macros;
 - Remove unused macros: MLXCPLD_LPCI2C_LPF_DFLT,
   MLXCPLD_LPCI2C_HALF_CYC_100, MLXCPLD_LPCI2C_I2C_HOLD_100,
   MLXCPLD_LPCI2C_HALF_CYC_REG, MLXCPLD_LPCI2C_I2C_HOLD_REG;
 - Fix checkpatch warnings (**/ and the end of comment);
 - Add empty line before structures mlxcpld_i2c_regs,
   mlxcpld_i2c_curr_transf, mlxcpld_i2c_priv;
 - Remove unused structure mlxcpld_i2c_regs;
 - Remove from mlxcpld_i2c_priv the next fields:
   retr_num, poll_time, block_sz, xfer_to; use instead macros
   respectively: MLXCPLD_I2C_RETR_NUM, MLXCPLD_I2C_POLL_TIME,
   MLXCPLD_I2C_DATA_REG_SZ, MLXCPLD_I2C_XFER_TO;
 - In mlxcpld_i2c_invalid_len remove unnecessary else;
 - Optimize mlxcpld_i2c_set_transf_data;
 - mlxcpld_i2c_reset - add empty lines after/before mutex
   lock/unlock;
 - mlxcpld_i2c_wait_for_free - cover case timeout is equal
   MLXCPLD_I2C_XFER_TO;
 - mlxcpld_i2c_wait_for_tc:
   - Do not assign err in declaration (also err is removed);
   - Insert empty line before case MLXCPLD_LPCI2C_ACK_IND;
   - inside case MLXCPLD_LPCI2C_ACK_IND - avoid unnecessary
 indentation;
   - Remove case MLXCPLD_LPCI2C_ERR_IND and remove this macro;
 - Add empty lines in mlxcpld_i2c_xfer before/after mutex_lock/
   mutex_unlock;
 - In mlxcpld_i2c_probe add emtpy line after platform_set_drvdata;
 - Replace platfrom handle pdev in mlxcpld_i2c_priv with the pointer
   to the structure device;
 - Place assignment of base_addr near the others;
 - Enclose e-mail with <>;
 Fixes added by Vadim:
 - Change structure description format according to
   Documentation/kernel-documentation.rst guideline;
 - mlxcpld_i2c_wait_for_tc: return error if status reaches default case;
v1->v2
 Fixes added by Vadim:
 - Put new record in Makefile in alphabetic order;
 - Remove http://www.mellanox.com from MAINTAINERS record;
---
 Documentation/i2c/busses/i2c-mlxcpld |  47 +++
 MAINTAINERS  |   8 +
 drivers/i2c/busses/Kconfig   |  11 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-mlxcpld.c | 544 +++
 5 files changed, 611 insertions(+)
 create mode 100644 Documentation/i2c/busses/i2c-mlxcpld
 create mode 100644 drivers/i2c/busses/i2c-mlxcpld.c

diff --git a/Documentation/i2c/busses/i2c-mlxcpld 
b/Documentation/i2c/busses/i2c-mlxcpld
new file mode 100644
index 000..0f8678a
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-mlxcpld
@@ -0,0 +1,47 @@
+Driver i2c-mlxcpld
+
+Author: Michael Shych 
+
+This is a for Mellanox I2C controller logic, implemented in Lattice CPLD
+device.
+Device supports:
+ - Master mode.
+ - One physical bus.
+ - Polling mode.
+
+This controller is equipped within the next Mellanox systems:
+"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
+"msn2740", "msn2100".
+
+The next transaction types are supported:
+ - Receive Byte/Block.
+ - Send Byte/Block.
+ - Read Byte/Block.
+ - Write Byte/Block.
+
+Registers:

Re: [PATCH v2 0/7] mtd: nand: Abstract away the NAND interface type

[Peter Pan]

Hi Boris,

On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
 wrote:
> Hi,
>
> This series is aiming at providing a generic NAND layer to share code
> between different NAND based devices.
>
> We currently have 3 different interfaces to interact with NANDs:
> - Raw NANDs
> - OneNANDs
> - SPI NANDs
>
> Apart from the way these NAND devices are accessed they have a lot
> in common, like the way the memory is organized, or their constraints.
> This is usually a good sign that some work should be done to factorize
> the code.
>
> This work has been started by Peter who wanted to re-use the BBT
> code for its SPI-NAND driver. But I think we can push it further
> other stuff (the software ECC implementation, or the way offsets are
> converted to block/page number).
>
> Peter, can you please review/test this version, and if possible, post
> the code you've done to support SPI NANDs.
>

I already finished review and test work. The BBT works well after I applied
my modification which I already sent to your by email. I tried to build a new
BBT on a new NAND and then mark one block to bad. Both works well.
My test platform is Xilinx Zed board.

I will try to rebase my SPI NAND patch on your patch and send it out.
It will take me some time because I'm quite busy with other company affairs.


Thanks,
Peter Pan

Re: [PATCH v2 0/7] mtd: nand: Abstract away the NAND interface type

[Peter Pan]

Hi Boris,

On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
 wrote:
> Hi,
>
> This series is aiming at providing a generic NAND layer to share code
> between different NAND based devices.
>
> We currently have 3 different interfaces to interact with NANDs:
> - Raw NANDs
> - OneNANDs
> - SPI NANDs
>
> Apart from the way these NAND devices are accessed they have a lot
> in common, like the way the memory is organized, or their constraints.
> This is usually a good sign that some work should be done to factorize
> the code.
>
> This work has been started by Peter who wanted to re-use the BBT
> code for its SPI-NAND driver. But I think we can push it further
> other stuff (the software ECC implementation, or the way offsets are
> converted to block/page number).
>
> Peter, can you please review/test this version, and if possible, post
> the code you've done to support SPI NANDs.
>

I already finished review and test work. The BBT works well after I applied
my modification which I already sent to your by email. I tried to build a new
BBT on a new NAND and then mark one block to bad. Both works well.
My test platform is Xilinx Zed board.

I will try to rebase my SPI NAND patch on your patch and send it out.
It will take me some time because I'm quite busy with other company affairs.


Thanks,
Peter Pan

Re: [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma

[Kirti Wankhede]

On 11/17/2016 11:11 AM, Alexey Kardashevskiy wrote:
> On 17/11/16 07:46, Kirti Wankhede wrote:
>> Add task structure to vfio_dma structure. Task structure is used for:
>> - During DMA_UNMAP, same task who mapped it or other task who shares same
>> address space is allowed to unmap, otherwise unmap fails.
>> QEMU maps few iova ranges initially, then fork threads and from the child
>> thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>> address space, DMA_UNMAP is successful.
>> - Avoid accessing struct mm while process is exiting by acquiring
>> reference of task's mm during page accounting.
>> - It is also used to get task mlock capability and rlimit for mlock.
>>
>> Signed-off-by: Kirti Wankhede 
>> Signed-off-by: Neo Jia 
>> Reviewed-by: Dong Jia Shi 
> 
> 
> I keep whinging that @mm should be referenced, not @current but you keep
> referencing @current even if you only need @mm and you are not telling why
> - and I am wondering what I am missing here? Something else will be used
> from @task later, besides just @mm?
> 
> 

Hey Alexey,

I updated briefly in commit description. Let me try to explain it again
in detail.

Its true we need mm, but we also need task structure for 2 reasons:
- Avoid accessing struct mm while process is exiting by acquiring
 reference of task's mm during page accounting.
If you see vfio_lock_acct(), where reference to mm is taken from task
structure, get_task_mm(task), to make sure that mm of this task is still
valid and task not in exiting process. If process is exiting, mm would
be NULL and we don't have to do page accounting.
This patch is to re-org and prepare the code for next patch, 10/22.
vfio_pin_pages()/ vfio_unpin_pages() for mediated devices would get
called from vendor driver. Those could be initiated by other process,
but for pin/unpin, these APIs should use the mm of the task who mapped
it. So in these calls we should check that we get the valid reference of
mm, that we would get from task structure.

- It is also used to get task mlock capability and rlimit for mlock.
These are again used for page accounting and page accounting should be
done with reference to the task who mapped the iova range. We get these
from task structure.

Thanks,
Kirti

Re: [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma

[Kirti Wankhede]

On 11/17/2016 11:11 AM, Alexey Kardashevskiy wrote:
> On 17/11/16 07:46, Kirti Wankhede wrote:
>> Add task structure to vfio_dma structure. Task structure is used for:
>> - During DMA_UNMAP, same task who mapped it or other task who shares same
>> address space is allowed to unmap, otherwise unmap fails.
>> QEMU maps few iova ranges initially, then fork threads and from the child
>> thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>> address space, DMA_UNMAP is successful.
>> - Avoid accessing struct mm while process is exiting by acquiring
>> reference of task's mm during page accounting.
>> - It is also used to get task mlock capability and rlimit for mlock.
>>
>> Signed-off-by: Kirti Wankhede 
>> Signed-off-by: Neo Jia 
>> Reviewed-by: Dong Jia Shi 
> 
> 
> I keep whinging that @mm should be referenced, not @current but you keep
> referencing @current even if you only need @mm and you are not telling why
> - and I am wondering what I am missing here? Something else will be used
> from @task later, besides just @mm?
> 
> 

Hey Alexey,

I updated briefly in commit description. Let me try to explain it again
in detail.

Its true we need mm, but we also need task structure for 2 reasons:
- Avoid accessing struct mm while process is exiting by acquiring
 reference of task's mm during page accounting.
If you see vfio_lock_acct(), where reference to mm is taken from task
structure, get_task_mm(task), to make sure that mm of this task is still
valid and task not in exiting process. If process is exiting, mm would
be NULL and we don't have to do page accounting.
This patch is to re-org and prepare the code for next patch, 10/22.
vfio_pin_pages()/ vfio_unpin_pages() for mediated devices would get
called from vendor driver. Those could be initiated by other process,
but for pin/unpin, these APIs should use the mm of the task who mapped
it. So in these calls we should check that we get the valid reference of
mm, that we would get from task structure.

- It is also used to get task mlock capability and rlimit for mlock.
These are again used for page accounting and page accounting should be
done with reference to the task who mapped the iova range. We get these
from task structure.

Thanks,
Kirti

[RFC PATCH 5/7] iio: multiplexer: new iio category and iio-mux driver

[Peter Rosin]

When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
create one virtual iio channel for each multiplexer state.

Depends on the generic multiplexer driver.
---
 drivers/iio/Kconfig   |   1 +
 drivers/iio/Makefile  |   1 +
 drivers/iio/multiplexer/Kconfig   |  17 +++
 drivers/iio/multiplexer/Makefile  |   6 +
 drivers/iio/multiplexer/iio-mux.c | 313 ++
 5 files changed, 338 insertions(+)
 create mode 100644 drivers/iio/multiplexer/Kconfig
 create mode 100644 drivers/iio/multiplexer/Makefile
 create mode 100644 drivers/iio/multiplexer/iio-mux.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18194fb..dcb541d0d70e 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -82,6 +82,7 @@ source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
+source "drivers/iio/multiplexer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
 if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c4369e2f..f9879c29cf6f 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -27,6 +27,7 @@ obj-y += humidity/
 obj-y += imu/
 obj-y += light/
 obj-y += magnetometer/
+obj-y += multiplexer/
 obj-y += orientation/
 obj-y += potentiometer/
 obj-y += pressure/
diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/multiplexer/Kconfig
new file mode 100644
index ..31cbe4509366
--- /dev/null
+++ b/drivers/iio/multiplexer/Kconfig
@@ -0,0 +1,17 @@
+#
+# Multiplexer drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Multiplexers"
+
+config IIO_MUX
+   tristate "IIO multiplexer driver"
+   depends on OF && MUX_GPIO
+   help
+ Say yes here to build support for the IIO multiplexer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-mux.
+
+endmenu
diff --git a/drivers/iio/multiplexer/Makefile b/drivers/iio/multiplexer/Makefile
new file mode 100644
index ..68be3c4abd07
--- /dev/null
+++ b/drivers/iio/multiplexer/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for industrial I/O multiplexer drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_MUX) += iio-mux.o
diff --git a/drivers/iio/multiplexer/iio-mux.c 
b/drivers/iio/multiplexer/iio-mux.c
new file mode 100644
index ..6f6644fb9342
--- /dev/null
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -0,0 +1,313 @@
+/*
+ * IIO multiplexer driver
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux_child {
+   u32 reg;
+
+   const char **ext_info;
+   int num_ext_info;
+};
+
+struct mux {
+   u32 cache;
+   struct mux_control *control;
+   struct iio_channel *parent;
+   struct iio_dev *indio_dev;
+   struct iio_chan_spec *c;
+   struct mux_child *child;
+};
+
+static int iio_mux_select(struct mux *mux, int idx)
+{
+   struct mux_child *child = >child[idx];
+   int ret;
+   int i;
+
+   ret = mux_control_select(mux->control, child->reg);
+   if (ret < 0)
+   return ret;
+
+   if (mux->cache == child->reg)
+   return 0;
+
+   for (i = 0; i < child->num_ext_info - 1; i += 2) {
+   const char *value = child->ext_info[i + 1];
+
+   ret = iio_write_channel_ext_info(mux->parent,
+child->ext_info[i],
+value, strlen(value));
+   if (ret < 0) {
+   mux_control_deselect(mux->control);
+   return ret;
+   }
+   }
+   mux->cache = child->reg;
+
+   return 0;
+}
+
+static void iio_mux_deselect(struct mux *mux)
+{
+   mux_control_deselect(mux->control);
+}
+
+static int mux_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   int *val, int *val2, long mask)
+{
+   struct mux *mux = iio_priv(indio_dev);
+   int idx = chan - mux->c;
+   int ret;
+
+   ret = iio_mux_select(mux, idx);
+   if (ret < 0)
+   return ret;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   ret = iio_read_channel_raw(mux->parent, val);
+   break;
+
+   case IIO_CHAN_INFO_SCALE:
+   ret = iio_read_channel_scale(mux->parent, val, val2);
+   break;
+
+   default:
+  

[RFC PATCH 5/7] iio: multiplexer: new iio category and iio-mux driver

[Peter Rosin]

When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
create one virtual iio channel for each multiplexer state.

Depends on the generic multiplexer driver.
---
 drivers/iio/Kconfig   |   1 +
 drivers/iio/Makefile  |   1 +
 drivers/iio/multiplexer/Kconfig   |  17 +++
 drivers/iio/multiplexer/Makefile  |   6 +
 drivers/iio/multiplexer/iio-mux.c | 313 ++
 5 files changed, 338 insertions(+)
 create mode 100644 drivers/iio/multiplexer/Kconfig
 create mode 100644 drivers/iio/multiplexer/Makefile
 create mode 100644 drivers/iio/multiplexer/iio-mux.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18194fb..dcb541d0d70e 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -82,6 +82,7 @@ source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
+source "drivers/iio/multiplexer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
 if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c4369e2f..f9879c29cf6f 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -27,6 +27,7 @@ obj-y += humidity/
 obj-y += imu/
 obj-y += light/
 obj-y += magnetometer/
+obj-y += multiplexer/
 obj-y += orientation/
 obj-y += potentiometer/
 obj-y += pressure/
diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/multiplexer/Kconfig
new file mode 100644
index ..31cbe4509366
--- /dev/null
+++ b/drivers/iio/multiplexer/Kconfig
@@ -0,0 +1,17 @@
+#
+# Multiplexer drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Multiplexers"
+
+config IIO_MUX
+   tristate "IIO multiplexer driver"
+   depends on OF && MUX_GPIO
+   help
+ Say yes here to build support for the IIO multiplexer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-mux.
+
+endmenu
diff --git a/drivers/iio/multiplexer/Makefile b/drivers/iio/multiplexer/Makefile
new file mode 100644
index ..68be3c4abd07
--- /dev/null
+++ b/drivers/iio/multiplexer/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for industrial I/O multiplexer drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_MUX) += iio-mux.o
diff --git a/drivers/iio/multiplexer/iio-mux.c 
b/drivers/iio/multiplexer/iio-mux.c
new file mode 100644
index ..6f6644fb9342
--- /dev/null
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -0,0 +1,313 @@
+/*
+ * IIO multiplexer driver
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux_child {
+   u32 reg;
+
+   const char **ext_info;
+   int num_ext_info;
+};
+
+struct mux {
+   u32 cache;
+   struct mux_control *control;
+   struct iio_channel *parent;
+   struct iio_dev *indio_dev;
+   struct iio_chan_spec *c;
+   struct mux_child *child;
+};
+
+static int iio_mux_select(struct mux *mux, int idx)
+{
+   struct mux_child *child = >child[idx];
+   int ret;
+   int i;
+
+   ret = mux_control_select(mux->control, child->reg);
+   if (ret < 0)
+   return ret;
+
+   if (mux->cache == child->reg)
+   return 0;
+
+   for (i = 0; i < child->num_ext_info - 1; i += 2) {
+   const char *value = child->ext_info[i + 1];
+
+   ret = iio_write_channel_ext_info(mux->parent,
+child->ext_info[i],
+value, strlen(value));
+   if (ret < 0) {
+   mux_control_deselect(mux->control);
+   return ret;
+   }
+   }
+   mux->cache = child->reg;
+
+   return 0;
+}
+
+static void iio_mux_deselect(struct mux *mux)
+{
+   mux_control_deselect(mux->control);
+}
+
+static int mux_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   int *val, int *val2, long mask)
+{
+   struct mux *mux = iio_priv(indio_dev);
+   int idx = chan - mux->c;
+   int ret;
+
+   ret = iio_mux_select(mux, idx);
+   if (ret < 0)
+   return ret;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   ret = iio_read_channel_raw(mux->parent, val);
+   break;
+
+   case IIO_CHAN_INFO_SCALE:
+   ret = iio_read_channel_scale(mux->parent, val, val2);
+   break;
+
+   default:
+   ret = 

Re: [PATCH v2 6/7] mtd: nand: raw: make BBT code more generic

[Peter Pan]

Hi Boris,

On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
 wrote:
> BBT support is currently tightly tied to raw NAND, though this is the kind
> of code we could share across all NAND based devices, no matter what
> physical interface is to communicate with the NAND chip.
>
> Make BBT code interface agnostic by replacing all occurrence of
> struct nand_chip by struct nand_device, and move functions that are
> specific to raw NANDs to drivers/mtd/nand/rawnand/nand_base.c.
>
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/nand/raw/nand_base.c |  78 -
>  drivers/mtd/nand/raw/nand_bbt.c  | 609 
> ++-
>  include/linux/mtd/nand.h |   8 +
>  include/linux/mtd/rawnand.h  |   4 -
>  4 files changed, 361 insertions(+), 338 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c 
> b/drivers/mtd/nand/raw/nand_base.c
> index b86f4a1bfbe1..4930b3569de9 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -471,7 +471,7 @@ static int nand_block_markbad_lowlevel(struct mtd_info 
> *mtd, loff_t ofs)
>
> /* Mark block bad in BBT */
> if (chip->bbt) {

Should be "if (!nand->bbt.bbt)".

> -   res = nand_markbad_bbt(mtd, ofs);
> +   res = nand_markbad_bbt(mtd_to_nand(mtd), ofs);
> if (!ret)
> ret = res;
> }

Re: [PATCH v2 6/7] mtd: nand: raw: make BBT code more generic

[Peter Pan]

Hi Boris,

On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
 wrote:
> BBT support is currently tightly tied to raw NAND, though this is the kind
> of code we could share across all NAND based devices, no matter what
> physical interface is to communicate with the NAND chip.
>
> Make BBT code interface agnostic by replacing all occurrence of
> struct nand_chip by struct nand_device, and move functions that are
> specific to raw NANDs to drivers/mtd/nand/rawnand/nand_base.c.
>
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/nand/raw/nand_base.c |  78 -
>  drivers/mtd/nand/raw/nand_bbt.c  | 609 
> ++-
>  include/linux/mtd/nand.h |   8 +
>  include/linux/mtd/rawnand.h  |   4 -
>  4 files changed, 361 insertions(+), 338 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c 
> b/drivers/mtd/nand/raw/nand_base.c
> index b86f4a1bfbe1..4930b3569de9 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -471,7 +471,7 @@ static int nand_block_markbad_lowlevel(struct mtd_info 
> *mtd, loff_t ofs)
>
> /* Mark block bad in BBT */
> if (chip->bbt) {

Should be "if (!nand->bbt.bbt)".

> -   res = nand_markbad_bbt(mtd, ofs);
> +   res = nand_markbad_bbt(mtd_to_nand(mtd), ofs);
> if (!ret)
> ret = res;
> }

Re: [PATCH v2 3/7] mtd: nand: add a nand.h file to expose basic NAND stuff

[Peter Pan]

Hi Boris,

On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
 wrote:
> Now that raw NAND header has been moved to rawnand.h, we can add a new
> nand.h file and define the common nand stuff in there.
>
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 480 
> +++
>  1 file changed, 480 insertions(+)
>  create mode 100644 include/linux/mtd/nand.h
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> new file mode 100644
> index ..b9b5d3c1bdf9
> --- /dev/null
> +++ b/include/linux/mtd/nand.h
[...]
> +
> +/**
> + * nand_offs_to_die - Convert an absolute offset to a die number
> + * @nand: NAND device
> + * @offs: absolute offset
> + *
> + * Returns the die number containing @offs.
> + */
> +static inline int nand_offs_to_die(struct nand_device *nand, loff_t offs)
> +{
> +   u64 die = offs;
> +
> +   do_div(die, nand->memorg.diesize);
> +
> +   return die;

Is it proper to use do_div here?. If I'm right, the divisor of do_div is 32bit.
It may cause division 0 exception when die size is larger than 4GB.
div64_u64 may be better.

Thanks,
Peter Pan

Re: [PATCH v2 3/7] mtd: nand: add a nand.h file to expose basic NAND stuff

[Peter Pan]

Hi Boris,

On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
 wrote:
> Now that raw NAND header has been moved to rawnand.h, we can add a new
> nand.h file and define the common nand stuff in there.
>
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 480 
> +++
>  1 file changed, 480 insertions(+)
>  create mode 100644 include/linux/mtd/nand.h
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> new file mode 100644
> index ..b9b5d3c1bdf9
> --- /dev/null
> +++ b/include/linux/mtd/nand.h
[...]
> +
> +/**
> + * nand_offs_to_die - Convert an absolute offset to a die number
> + * @nand: NAND device
> + * @offs: absolute offset
> + *
> + * Returns the die number containing @offs.
> + */
> +static inline int nand_offs_to_die(struct nand_device *nand, loff_t offs)
> +{
> +   u64 die = offs;
> +
> +   do_div(die, nand->memorg.diesize);
> +
> +   return die;

Is it proper to use do_div here?. If I'm right, the divisor of do_div is 32bit.
It may cause division 0 exception when die size is larger than 4GB.
div64_u64 may be better.

Thanks,
Peter Pan

Re: [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma

[Alex Williamson]

On Thu, 17 Nov 2016 16:41:14 +1100
Alexey Kardashevskiy  wrote:

> On 17/11/16 07:46, Kirti Wankhede wrote:
> > Add task structure to vfio_dma structure. Task structure is used for:
> > - During DMA_UNMAP, same task who mapped it or other task who shares same
> > address space is allowed to unmap, otherwise unmap fails.
> > QEMU maps few iova ranges initially, then fork threads and from the child
> > thread calls DMA_UNMAP on previously mapped iova. Since child shares same
> > address space, DMA_UNMAP is successful.
> > - Avoid accessing struct mm while process is exiting by acquiring
> > reference of task's mm during page accounting.
> > - It is also used to get task mlock capability and rlimit for mlock.
> > 
> > Signed-off-by: Kirti Wankhede 
> > Signed-off-by: Neo Jia 
> > Reviewed-by: Dong Jia Shi   
> 
> 
> I keep whinging that @mm should be referenced, not @current but you keep
> referencing @current even if you only need @mm and you are not telling why
> - and I am wondering what I am missing here? Something else will be used
> from @task later, besides just @mm?

Yes, we reference @current from vfio_dma_do_map() and this is stored
on the struct vfio_dma.  A reference to current is held because the
external page pinning in vfio_pin_page_external() needs to test the
capabilities of the task for CAP_IPC_LOCK to know whether locked memory
limits are in effect for the task even when it's not @current (ie. an
asynchronous call from the vendor driver regardless of what task is
currently running).  There are also various get_task_mm() taken
temporarily when we're working with the mm of that task.  Do you spot
any issues with this behavior? Thanks,

Alex

Re: [PATCH v14 09/22] vfio iommu type1: Add task structure to vfio_dma

[Alex Williamson]

On Thu, 17 Nov 2016 16:41:14 +1100
Alexey Kardashevskiy  wrote:

> On 17/11/16 07:46, Kirti Wankhede wrote:
> > Add task structure to vfio_dma structure. Task structure is used for:
> > - During DMA_UNMAP, same task who mapped it or other task who shares same
> > address space is allowed to unmap, otherwise unmap fails.
> > QEMU maps few iova ranges initially, then fork threads and from the child
> > thread calls DMA_UNMAP on previously mapped iova. Since child shares same
> > address space, DMA_UNMAP is successful.
> > - Avoid accessing struct mm while process is exiting by acquiring
> > reference of task's mm during page accounting.
> > - It is also used to get task mlock capability and rlimit for mlock.
> > 
> > Signed-off-by: Kirti Wankhede 
> > Signed-off-by: Neo Jia 
> > Reviewed-by: Dong Jia Shi   
> 
> 
> I keep whinging that @mm should be referenced, not @current but you keep
> referencing @current even if you only need @mm and you are not telling why
> - and I am wondering what I am missing here? Something else will be used
> from @task later, besides just @mm?

Yes, we reference @current from vfio_dma_do_map() and this is stored
on the struct vfio_dma.  A reference to current is held because the
external page pinning in vfio_pin_page_external() needs to test the
capabilities of the task for CAP_IPC_LOCK to know whether locked memory
limits are in effect for the task even when it's not @current (ie. an
asynchronous call from the vendor driver regardless of what task is
currently running).  There are also various get_task_mm() taken
temporarily when we're working with the mm of that task.  Do you spot
any issues with this behavior? Thanks,

Alex

linux-next: Tree for Nov 17

[Stephen Rothwell]

Hi all,

There will be no linux-next releases on Friday (tomorrow) or Monday.

Changes since 20161116:

The net-next tree gained conflicts against the net tree.

The drm tree gained a conflict against the arm tree.

The block tree gained conflicts against the btrfs-kdave tree.

The tip tree gained conflicts against the drm and net-next trees and a
build failure for which I applied a merge fix patch.

The kvm tree gained a conflict against the tip tree.

Non-merge commits (relative to Linus' tree): 6305
 6661 files changed, 401169 insertions(+), 146155 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 244 trees (counting Linus' and 34 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (81bcfe5e48f9 Merge tag 'trace-v4.9-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c6a385539175 kbuild: Steal gcc's pie from the 
very beginning)
Merging arc-current/for-curr (a25f0944ba9b Linux 4.9-rc5)
Merging arm-current/fixes (256ff1cf6b44 ARM: 8628/1: dma-mapping: preallocate 
DMA-debug hash tables in core_initcall)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (c0a36013639b powerpc/64: Fix setting of AIL in 
hypervisor mode)
Merging sparc/master (87a349f9cc09 sparc64: fix compile warning section 
mismatch in find_node())
Merging net/master (963abe5c8a02 virtio-net: add a missing synchronize_net())
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if 
it is L3 master)
Merging ipvs/master (9b6c14d51bd2 net: tcp response should set oif only if it 
is L3 master)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid 
maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (4fb7f8af1f4c mac80211_hwsim: fix beacon delta 
calculation)
Merging sound-current/for-linus (6ff1a25318eb ALSA: usb-audio: Fix 
use-after-free of usb_device at disconnect)
Merging pci-current/for-linus (bc79c9851a76 PCI: VMD: Update filename to 
reflect move)
Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (a5d906bb261c usb: chipidea: move the lock 
initialization to core file)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove 
interrupt throttling)
Merging usb-serial-fixes/usb-linus (2ab13292d7a3 USB: serial: cp210x: add ID 
for the Zone DPMX)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5)
Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 
Focaltech code)
Merging crypto-current/master (83d2c9a9c17b crypto: caam - do not register 
AES-XTS mode on LP units

linux-next: Tree for Nov 17

[Stephen Rothwell]

Hi all,

There will be no linux-next releases on Friday (tomorrow) or Monday.

Changes since 20161116:

The net-next tree gained conflicts against the net tree.

The drm tree gained a conflict against the arm tree.

The block tree gained conflicts against the btrfs-kdave tree.

The tip tree gained conflicts against the drm and net-next trees and a
build failure for which I applied a merge fix patch.

The kvm tree gained a conflict against the tip tree.

Non-merge commits (relative to Linus' tree): 6305
 6661 files changed, 401169 insertions(+), 146155 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 244 trees (counting Linus' and 34 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (81bcfe5e48f9 Merge tag 'trace-v4.9-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c6a385539175 kbuild: Steal gcc's pie from the 
very beginning)
Merging arc-current/for-curr (a25f0944ba9b Linux 4.9-rc5)
Merging arm-current/fixes (256ff1cf6b44 ARM: 8628/1: dma-mapping: preallocate 
DMA-debug hash tables in core_initcall)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (c0a36013639b powerpc/64: Fix setting of AIL in 
hypervisor mode)
Merging sparc/master (87a349f9cc09 sparc64: fix compile warning section 
mismatch in find_node())
Merging net/master (963abe5c8a02 virtio-net: add a missing synchronize_net())
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if 
it is L3 master)
Merging ipvs/master (9b6c14d51bd2 net: tcp response should set oif only if it 
is L3 master)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid 
maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (4fb7f8af1f4c mac80211_hwsim: fix beacon delta 
calculation)
Merging sound-current/for-linus (6ff1a25318eb ALSA: usb-audio: Fix 
use-after-free of usb_device at disconnect)
Merging pci-current/for-linus (bc79c9851a76 PCI: VMD: Update filename to 
reflect move)
Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (a5d906bb261c usb: chipidea: move the lock 
initialization to core file)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove 
interrupt throttling)
Merging usb-serial-fixes/usb-linus (2ab13292d7a3 USB: serial: cp210x: add ID 
for the Zone DPMX)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5)
Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 
Focaltech code)
Merging crypto-current/master (83d2c9a9c17b crypto: caam - do not register 
AES-XTS mode on LP units

[RFC PATCH] mfd: dt: Add Aspeed LPC binding

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---

I'd like to start a discussion about how to handle the LPC register space in
the Aspeed SoC. There are a number of issues, largely concerned with the layout
of the registers but also with the fact that LPC register state is used by the
pinmux to determine some pin functionality.

So the register layout is problematic. Registers for what I think are coherent
pieces of functionality functionality are littered through the layout: Post
Code Control registers (PCCR) are interleaved with LPC Host Controller
registers (LHCR) which are interleaved with Host Interface Controller registers
(HICR) which are segmented by LPC Snoop registers. It seems appropriate that
the whole thing is represented as an MFD syscon, with the alternative being
writing several distinct drivers that map some number of resources to access
all of their registers.

The disadvantage of not representing the LPC space as a syscon is the LPC Host
Controller driver will need to provide accessor functions for the pinmux
driver. Pinmux also depends on bits in the Display Controller, and would need
similar accessors provided there. The idea of using syscon regmaps removes the
need to write these accessors. If the changes between the AST2400 and AST2500
are anything to go by, the pinmux complexity of the SoCs will only increase
which will likely lead to the spread of these accessor functions.

Yet another option would be to only expose the LPC Host Controller as a syscon
instead of the whole LPC register space. I feel this is a little distasteful
as the LHCRs are not in contiguous memory space; as mentioned above they are
separated (seemingly randomly) by a PCCR. We could specify the LPC Host
Controller as a syscon and provide multiple resources: The syscon
implementation consumes the first resource which is what we desire here for use
with pinmux, but the driver would be left to map any subsequent resources. That
feels odd to me, but I'm interested in arguments for it.

We could also map the LPC Host Controller syscon across the offending PCCR, but
then any driver developed for the Post Code Controller would have to take a
reference to the LPC Host Controller regmap. I feel like we might wind up with
a syscon phandle spaghetti across the LPC controller if we use that approach.

Finally, the LPC registers can be divided in two: one set for H8S/2168
compatible LPC functionality, and the rest for Aspeed-specific registers.
Division in two is required if we are going to throw a regmap over the LPC
space as the H8S/2168 registers are 1-byte wide, whilst the Aspeed LPC
registers are 4-bytes. As far as I can tell we can treat them as separate
functionality without any loss; if there is a cross-over in configuration we
can have each phandle the other in the devicetree.

The final complication is the iBT device sits in the Aspeed-specific part of
the LPC controller and has an upstream driver that isn't regmap-capable.
Describing the LPC controller as a syscon will require some changes there, but
I think we can make it work without too much trouble.

What is the recommended approach to managing such hardware?

Cheers,

Andrew

PS: I sent a devicetree binding document out for the LPC Host Controller as
part of a recent pinmux series[1]. As it stands the example in the document
doesn't cover the all the registers relevant to the LPC Host Controller, which
was a motivation for trying to sort the problem out properly.

[1] https://www.spinics.net/lists/arm-kernel/msg540084.html

 .../devicetree/bindings/mfd/aspeed-lpc.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
new file mode 100644
index ..36c8a9e08dc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -0,0 +1,28 @@
+* Device tree bindings for the Aspeed LPC Controller
+
+The Aspeed LPC controller contains registers for a variety of functions. Not
+all registers for a function are contiguous, and some registers are referenced
+by functions outside the LPC controller.
+
+Note that this is separate from the H8S/2168 compatible register set occupying
+the start of the LPC controller address space.
+
+Some significant functions in the LPC controller:
+
+* LPC Host Controller
+* Host Interface Controller
+* iBT Controller
+* SuperIO Scratch registers
+
+Required properties:
+- compatible:  "aspeed,ast2500-lpc", "syscon"
+- reg: contains offset/length value of the Aspeed-specific LPC
+   memory region.
+
+Example:
+
+lpc: lpc@1e7890a0 {
+   compatible = "aspeed,ast2500-lpc", "syscon";
+   reg = <0x1e789080 0x1e0>;
+};
+
-- 
2.9.3

[RFC PATCH] mfd: dt: Add Aspeed LPC binding

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
---

I'd like to start a discussion about how to handle the LPC register space in
the Aspeed SoC. There are a number of issues, largely concerned with the layout
of the registers but also with the fact that LPC register state is used by the
pinmux to determine some pin functionality.

So the register layout is problematic. Registers for what I think are coherent
pieces of functionality functionality are littered through the layout: Post
Code Control registers (PCCR) are interleaved with LPC Host Controller
registers (LHCR) which are interleaved with Host Interface Controller registers
(HICR) which are segmented by LPC Snoop registers. It seems appropriate that
the whole thing is represented as an MFD syscon, with the alternative being
writing several distinct drivers that map some number of resources to access
all of their registers.

The disadvantage of not representing the LPC space as a syscon is the LPC Host
Controller driver will need to provide accessor functions for the pinmux
driver. Pinmux also depends on bits in the Display Controller, and would need
similar accessors provided there. The idea of using syscon regmaps removes the
need to write these accessors. If the changes between the AST2400 and AST2500
are anything to go by, the pinmux complexity of the SoCs will only increase
which will likely lead to the spread of these accessor functions.

Yet another option would be to only expose the LPC Host Controller as a syscon
instead of the whole LPC register space. I feel this is a little distasteful
as the LHCRs are not in contiguous memory space; as mentioned above they are
separated (seemingly randomly) by a PCCR. We could specify the LPC Host
Controller as a syscon and provide multiple resources: The syscon
implementation consumes the first resource which is what we desire here for use
with pinmux, but the driver would be left to map any subsequent resources. That
feels odd to me, but I'm interested in arguments for it.

We could also map the LPC Host Controller syscon across the offending PCCR, but
then any driver developed for the Post Code Controller would have to take a
reference to the LPC Host Controller regmap. I feel like we might wind up with
a syscon phandle spaghetti across the LPC controller if we use that approach.

Finally, the LPC registers can be divided in two: one set for H8S/2168
compatible LPC functionality, and the rest for Aspeed-specific registers.
Division in two is required if we are going to throw a regmap over the LPC
space as the H8S/2168 registers are 1-byte wide, whilst the Aspeed LPC
registers are 4-bytes. As far as I can tell we can treat them as separate
functionality without any loss; if there is a cross-over in configuration we
can have each phandle the other in the devicetree.

The final complication is the iBT device sits in the Aspeed-specific part of
the LPC controller and has an upstream driver that isn't regmap-capable.
Describing the LPC controller as a syscon will require some changes there, but
I think we can make it work without too much trouble.

What is the recommended approach to managing such hardware?

Cheers,

Andrew

PS: I sent a devicetree binding document out for the LPC Host Controller as
part of a recent pinmux series[1]. As it stands the example in the document
doesn't cover the all the registers relevant to the LPC Host Controller, which
was a motivation for trying to sort the problem out properly.

[1] https://www.spinics.net/lists/arm-kernel/msg540084.html

 .../devicetree/bindings/mfd/aspeed-lpc.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
new file mode 100644
index ..36c8a9e08dc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -0,0 +1,28 @@
+* Device tree bindings for the Aspeed LPC Controller
+
+The Aspeed LPC controller contains registers for a variety of functions. Not
+all registers for a function are contiguous, and some registers are referenced
+by functions outside the LPC controller.
+
+Note that this is separate from the H8S/2168 compatible register set occupying
+the start of the LPC controller address space.
+
+Some significant functions in the LPC controller:
+
+* LPC Host Controller
+* Host Interface Controller
+* iBT Controller
+* SuperIO Scratch registers
+
+Required properties:
+- compatible:  "aspeed,ast2500-lpc", "syscon"
+- reg: contains offset/length value of the Aspeed-specific LPC
+   memory region.
+
+Example:
+
+lpc: lpc@1e7890a0 {
+   compatible = "aspeed,ast2500-lpc", "syscon";
+   reg = <0x1e789080 0x1e0>;
+};
+
-- 
2.9.3

[PATCH] dumpstack: handle NULL stack pointer in show_trace_log_lvl()

[Josh Poimboeuf]

When show_trace_log_lvl() is called from show_regs(), it completely
fails to dump the stack.  This bug was introduced when
show_stack_log_lvl() was removed with the following commit:

  0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")

Previous callers of that function now call show_trace_log_lvl()
directly.  That resulted in a subtle change, in that the 'stack'
argument can now be NULL in certain cases.

A NULL 'stack' pointer means that the stack dump should start from the
topmost stack frame unless 'regs' is valid, in which case it should
start from 'regs->sp'.

Fixes: 0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/dumpstack.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 499aa6f..1e057b0 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -59,6 +59,7 @@ void show_trace_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
printk("%sCall Trace:\n", log_lvl);
 
unwind_start(, task, regs, stack);
+   stack = stack ? : get_stack_pointer(task, regs);
 
/*
 * Iterate through the stacks, starting with the current stack pointer.
-- 
2.7.4

[PATCH] dumpstack: handle NULL stack pointer in show_trace_log_lvl()

[Josh Poimboeuf]

When show_trace_log_lvl() is called from show_regs(), it completely
fails to dump the stack.  This bug was introduced when
show_stack_log_lvl() was removed with the following commit:

  0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")

Previous callers of that function now call show_trace_log_lvl()
directly.  That resulted in a subtle change, in that the 'stack'
argument can now be NULL in certain cases.

A NULL 'stack' pointer means that the stack dump should start from the
topmost stack frame unless 'regs' is valid, in which case it should
start from 'regs->sp'.

Fixes: 0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump")
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/dumpstack.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 499aa6f..1e057b0 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -59,6 +59,7 @@ void show_trace_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
printk("%sCall Trace:\n", log_lvl);
 
unwind_start(, task, regs, stack);
+   stack = stack ? : get_stack_pointer(task, regs);
 
/*
 * Iterate through the stacks, starting with the current stack pointer.
-- 
2.7.4

[PATCH] list_debug: show address of prev and next when list_del corruption is detected.

[Masayoshi Mizuma]

When list_del corruption is detected, the corruption may happen
because of the region of prev or next is destroyed. So, the
address of prev/next is useful to find the destroyer.

Signed-off-by: Masayoshi Mizuma 
---
 lib/list_debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/list_debug.c b/lib/list_debug.c
index 3859bf6..a9cbcdb 100644
--- a/lib/list_debug.c
+++ b/lib/list_debug.c
@@ -55,11 +55,11 @@ void __list_del_entry(struct list_head *entry)
"list_del corruption, %p->prev is LIST_POISON2 (%p)\n",
entry, LIST_POISON2) ||
WARN(prev->next != entry,
-   "list_del corruption. prev->next should be %p, "
-   "but was %p\n", entry, prev->next) ||
+   "list_del corruption. prev->next should be %p, but was %p 
(prev=%p)\n",
+   entry, prev->next, prev) ||
WARN(next->prev != entry,
-   "list_del corruption. next->prev should be %p, "
-   "but was %p\n", entry, next->prev))
+   "list_del corruption. next->prev should be %p, but was %p 
(next=%p)\n",
+   entry, next->prev, next))
return;
 
__list_del(prev, next);
-- 
1.8.3.1

[PATCH] list_debug: show address of prev and next when list_del corruption is detected.

[Masayoshi Mizuma]

When list_del corruption is detected, the corruption may happen
because of the region of prev or next is destroyed. So, the
address of prev/next is useful to find the destroyer.

Signed-off-by: Masayoshi Mizuma 
---
 lib/list_debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/list_debug.c b/lib/list_debug.c
index 3859bf6..a9cbcdb 100644
--- a/lib/list_debug.c
+++ b/lib/list_debug.c
@@ -55,11 +55,11 @@ void __list_del_entry(struct list_head *entry)
"list_del corruption, %p->prev is LIST_POISON2 (%p)\n",
entry, LIST_POISON2) ||
WARN(prev->next != entry,
-   "list_del corruption. prev->next should be %p, "
-   "but was %p\n", entry, prev->next) ||
+   "list_del corruption. prev->next should be %p, but was %p 
(prev=%p)\n",
+   entry, prev->next, prev) ||
WARN(next->prev != entry,
-   "list_del corruption. next->prev should be %p, "
-   "but was %p\n", entry, next->prev))
+   "list_del corruption. next->prev should be %p, but was %p 
(next=%p)\n",
+   entry, next->prev, next))
return;
 
__list_del(prev, next);
-- 
1.8.3.1