date:20180921

Re: [PATCH] staging: wilc1000: Remove unnecessary pointer check

2018-09-21 Thread Dan Carpenter

On Fri, Sep 21, 2018 at 01:25:32AM -0400, valdis.kletni...@vt.edu wrote:
> On Thu, 20 Sep 2018 14:26:49 -0700, Nathan Chancellor said:
> > Clang warns that the address of a pointer will always evaluated as true
> > in a boolean context:
> >
> > drivers/staging/wilc1000/linux_wlan.c:267:20: warning: address of
> > 'vif->ndev->dev' will always evaluate to 'true'
> > [-Wpointer-bool-conversion]
> > if (!(&vif->ndev->dev))
> > ~  ~~~^~~
> > 1 warning generated.
> >
> > Since this statement always evaluates to false due to the logical not,
> > remove it.
> 
> Often, "just nuke it because it's now dead code" isn't the best answer...
> 
> At one time, that was likely intended to be checking whether ->dev was a null
> pointer, to make sure we don't pass request_firmware() a null pointer and oops
> the kernel, or other things that go pear-shaped
> 
> So the question becomes:   Is it safe to just remove it, or was it intended to
> test for something that could  legitimately be null if we've hit an error 
> along
> the way (which means we should fix the condition to be proper and acceptable
> to both gcc and clang)?
> 

Obviously, we hope that Nathan considered that.  This driver has new
competent maintainers so they would think about that too.  I also review
staging patches and I reviewed it a few minutes after it was sent.  So
it's not like anyone was going to just merge the patch without thinking
about whether a different test was intended.

I am on the kernel-janitors and we've had one or two of these recently
where the warning indicate a bug so perhaps we do need to think about it
from a "process perspective".  The Fixes tag isn't appropiate because
it's not a bug fix, but we could just say in the comments:

"This unused variable was added in commit 123456789012 ("blah blah")
 so far as I can see it has never been useful."

That would help reviewing because now I know that you thought about it
and I also can just look at the original commit.  For this patch I did
git log -p and the scrolled to the original commit, and the function
name had changed so I had to scroll back and forth a bit to see what
the function was called originally.  It wasn't a huge deal but having
the original commit would be nice.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

2018-09-21 Thread Marek Szyprowski

Hi Janusz,

On 2018-09-20 18:21, Janusz Krzysztofik wrote:
> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
>>> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
 Certain GPIO descriptor arrays returned by gpio_get_array() may contain
 information on direct mapping of array members to pins of a single GPIO
 chip in hardware order.  In such cases, bitmaps of values can be passed
 directly from/to the chip's .get/set_multiple() callbacks without
 wasting time on iterations.

 Add respective code to gpiod_get/set_array_bitmap_complex() functions.
 Pins not applicable for fast path are processed as before, skipping
 over the 'fast' ones.

 Cc: Jonathan Corbet 
 Signed-off-by: Janusz Krzysztofik 
>>> I've just noticed that this patch landed in today's linux-next. Sadly it
>>> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
>>> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>>>
>>> Booting hangs after detecting MMC cards. Reverting this patch fixes the
>>> boot. I will try later to add some debugs and investigate it further what
>>> really happens when booting hangs.
>> Hi Marek,
>>
>> Thanks for reporting. Could you please try the following fix?
> Hi again,
>
> I realized the patch was not correct, j, not i, should be updated in second
> hunk. Please try the following one.
>
> Thanks,
> Janusz
>
> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
> From: Janusz Krzysztofik 
> Date: Thu, 20 Sep 2018 17:37:21 +0200
> Subject: [PATCH] gpiolib: Fix bitmap index not updated
> While skipping fast path bits, bitmap index is not updated with next
> found zero bit position. Fix it.
>
> Signed-off-by: Janusz Krzysztofik 

This one also doesn't help. A quick compare of logs with this version and
a working system shows, that with your patch (and fix) there are no calls to
gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
you need any more information (what kind of logs will help?), let me know.

> ---
>   drivers/gpio/gpiolib.c | 7 ---
>   1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a53d17745d21..369bdd358fcc 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool 
> can_sleep,
>   __set_bit(hwgpio, mask);
>   
>   if (array_info)
> - find_next_zero_bit(array_info->get_mask,
> + i = find_next_zero_bit(array_info->get_mask,
>  array_size, i);
>   else
>   i++;
> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool 
> can_sleep,
>   trace_gpio_value(desc_to_gpio(desc), 1, value);
>   
>   if (array_info)
> - find_next_zero_bit(array_info->get_mask, i, j);
> + j = find_next_zero_bit(array_info->get_mask, i,
> +j);
>   else
>   j++;
>   }
> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool 
> can_sleep,
>   }
>   
>   if (array_info)
> - find_next_zero_bit(array_info->set_mask,
> + i = find_next_zero_bit(array_info->set_mask,
>  array_size, i);
>   else
>   i++;

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: most: fix label names

2018-09-21 Thread Christian Gromm

This patch makes use of label names that say what the goto
actually does, as recommended in the kernel documentation.

Signed-off-by: Christian Gromm 
---
 drivers/staging/most/cdev/cdev.c | 12 +--
 drivers/staging/most/core.c  | 24 ++---
 drivers/staging/most/usb/usb.c   | 46 
 3 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/most/cdev/cdev.c b/drivers/staging/most/cdev/cdev.c
index 4569838..ea64aab 100644
--- a/drivers/staging/most/cdev/cdev.c
+++ b/drivers/staging/most/cdev/cdev.c
@@ -447,7 +447,7 @@ static int comp_probe(struct most_interface *iface, int 
channel_id,
c = kzalloc(sizeof(*c), GFP_KERNEL);
if (!c) {
retval = -ENOMEM;
-   goto error_alloc_channel;
+   goto err_remove_ida;
}
 
c->devno = MKDEV(comp.major, current_minor);
@@ -463,7 +463,7 @@ static int comp_probe(struct most_interface *iface, int 
channel_id,
retval = kfifo_alloc(&c->fifo, cfg->num_buffers, GFP_KERNEL);
if (retval) {
pr_info("failed to alloc channel kfifo");
-   goto error_alloc_kfifo;
+   goto err_del_cdev_and_free_channel;
}
init_waitqueue_head(&c->wq);
mutex_init(&c->io_mutex);
@@ -475,18 +475,18 @@ static int comp_probe(struct most_interface *iface, int 
channel_id,
if (IS_ERR(c->dev)) {
retval = PTR_ERR(c->dev);
pr_info("failed to create new device node %s\n", name);
-   goto error_create_device;
+   goto err_free_kfifo_and_del_list;
}
kobject_uevent(&c->dev->kobj, KOBJ_ADD);
return 0;
 
-error_create_device:
+err_free_kfifo_and_del_list:
kfifo_free(&c->fifo);
list_del(&c->list);
-error_alloc_kfifo:
+err_del_cdev_and_free_channel:
cdev_del(&c->cdev);
kfree(c);
-error_alloc_channel:
+err_remove_ida:
ida_simple_remove(&comp.minor_id, current_minor);
return retval;
 }
diff --git a/drivers/staging/most/core.c b/drivers/staging/most/core.c
index dabe180..6a18cf7 100644
--- a/drivers/staging/most/core.c
+++ b/drivers/staging/most/core.c
@@ -1235,7 +1235,7 @@ int most_start_channel(struct most_interface *iface, int 
id,
if (c->iface->configure(c->iface, c->channel_id, &c->cfg)) {
pr_info("channel configuration failed. Go check settings...\n");
ret = -EINVAL;
-   goto error;
+   goto err_put_module;
}
 
init_waitqueue_head(&c->hdm_fifo_wq);
@@ -1248,12 +1248,12 @@ int most_start_channel(struct most_interface *iface, 
int id,
   most_write_completion);
if (unlikely(!num_buffer)) {
ret = -ENOMEM;
-   goto error;
+   goto err_put_module;
}
 
ret = run_enqueue_thread(c, id);
if (ret)
-   goto error;
+   goto err_put_module;
 
c->is_starving = 0;
c->pipe0.num_buffers = c->cfg.num_buffers / 2;
@@ -1268,7 +1268,7 @@ int most_start_channel(struct most_interface *iface, int 
id,
mutex_unlock(&c->start_mutex);
return 0;
 
-error:
+err_put_module:
module_put(iface->mod);
mutex_unlock(&c->start_mutex);
return ret;
@@ -1449,7 +1449,7 @@ int most_register_interface(struct most_interface *iface)
 
c = kzalloc(sizeof(*c), GFP_KERNEL);
if (!c)
-   goto free_instance;
+   goto err_free_resources;
if (!name_suffix)
snprintf(c->name, STRING_SIZE, "ch%d", i);
else
@@ -1482,17 +1482,17 @@ int most_register_interface(struct most_interface 
*iface)
list_add_tail(&c->list, &iface->p->channel_list);
if (device_register(&c->dev)) {
pr_err("registering c->dev failed\n");
-   goto free_instance_nodev;
+   goto err_free_most_channel;
}
}
pr_info("registered new device mdev%d (%s)\n",
id, iface->description);
return 0;
 
-free_instance_nodev:
+err_free_most_channel:
kfree(c);
 
-free_instance:
+err_free_resources:
while (i > 0) {
c = iface->p->channel[--i];
device_unregister(&c->dev);
@@ -1613,20 +1613,20 @@ static int __init most_init(void)
err = driver_register(&mc.drv);
if (err) {
pr_info("Cannot register core driver\n");
-   goto exit_bus;
+   goto err_unregister_bus;
}
mc.dev.init_name = "most_bus";
mc.dev.release = release_most_sub;
if (device_register(&mc.dev)) {
err = -ENOMEM;
-   goto exit_driver;
+   goto err_unregister_driver;
}
 
return

[PATCH] memory_hotplug: Free pages as higher order

2018-09-21 Thread Arun KS

When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%.

Modify external providers of online callback to align with
the change.

Signed-off-by: Arun KS 

---

Changes since RFC:
- Rebase.
- As suggested by Michal Hocko remove pages_per_block.
- Modifed external providers of online_page_callback.

RFC:
https://lore.kernel.org/patchwork/patch/984754/
---
 drivers/hv/hv_balloon.c|  6 +++--
 drivers/xen/balloon.c  | 18 +++---
 include/linux/memory_hotplug.h |  2 +-
 mm/memory_hotplug.c| 55 +-
 4 files changed, 63 insertions(+), 18 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b1b7880..c5bc0b5 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -771,7 +771,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
}
 }
 
-static void hv_online_page(struct page *pg)
+static int hv_online_page(struct page *pg, unsigned int order)
 {
struct hv_hotadd_state *has;
unsigned long flags;
@@ -783,10 +783,12 @@ static void hv_online_page(struct page *pg)
if ((pfn < has->start_pfn) || (pfn >= has->end_pfn))
continue;
 
-   hv_page_online_one(has, pg);
+   hv_bring_pgs_online(has, pfn, (1UL << order));
break;
}
spin_unlock_irqrestore(&dm_device.ha_lock, flags);
+
+   return 0;
 }
 
 static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e12bb25..010cf4d 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -390,8 +390,8 @@ static enum bp_state reserve_additional_memory(void)
 
/*
 * add_memory_resource() will call online_pages() which in its turn
-* will call xen_online_page() callback causing deadlock if we don't
-* release balloon_mutex here. Unlocking here is safe because the
+* will call xen_bring_pgs_online() callback causing deadlock if we
+* don't release balloon_mutex here. Unlocking here is safe because the
 * callers drop the mutex before trying again.
 */
mutex_unlock(&balloon_mutex);
@@ -422,6 +422,18 @@ static void xen_online_page(struct page *page)
mutex_unlock(&balloon_mutex);
 }
 
+static int xen_bring_pgs_online(struct page *pg, unsigned int order)
+{
+   unsigned long i, size = (1 << order);
+   unsigned long start_pfn = page_to_pfn(pg);
+
+   pr_debug("Online %lu pages starting at pfn 0x%lx\n", size, start_pfn);
+   for (i = 0; i < size; i++)
+   xen_online_page(pfn_to_page(start_pfn + i));
+
+   return 0;
+}
+
 static int xen_memory_notifier(struct notifier_block *nb, unsigned long val, 
void *v)
 {
if (val == MEM_ONLINE)
@@ -744,7 +756,7 @@ static int __init balloon_init(void)
balloon_stats.max_retry_count = RETRY_UNLIMITED;
 
 #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
-   set_online_page_callback(&xen_online_page);
+   set_online_page_callback(&xen_bring_pgs_online);
register_memory_notifier(&xen_memory_nb);
register_sysctl_table(xen_root);
 
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 34a2822..7b04c1d 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -87,7 +87,7 @@ extern int test_pages_in_a_zone(unsigned long start_pfn, 
unsigned long end_pfn,
unsigned long *valid_start, unsigned long *valid_end);
 extern void __offline_isolated_pages(unsigned long, unsigned long);
 
-typedef void (*online_page_callback_t)(struct page *page);
+typedef int (*online_page_callback_t)(struct page *page, unsigned int order);
 
 extern int set_online_page_callback(online_page_callback_t callback);
 extern int restore_online_page_callback(online_page_callback_t callback);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 38d94b7..24c2b8e 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -47,7 +47,7 @@
  * and restore_online_page_callback() for generic callback restore.
  */
 
-static void generic_online_page(struct page *page);
+static int generic_online_page(struct page *page, unsigned int order);
 
 static online_page_callback_t online_page_callback = generic_online_page;
 static DEFINE_MUTEX(online_page_callback_lock);
@@ -655,26 +655,57 @@ void __online_page_free(struct page *page)
 }
 EXPORT_SYMBOL_GPL(__online_page_free);
 
-static void generic_online_page(struct page *page)
+static int generic_online_page(struct page *page, unsigned int order)
 {
-   __online_page_set_limits(page);
-   __online_page_increment_counters(page);
-   __online_page_free(page);
+   unsigned long nr_pages = 1

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

2018-09-21 Thread Janusz Krzysztofik

Hi Marek,

2018-09-21 10:18 GMT+02:00, Marek Szyprowski :
> Hi Janusz,
>
> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
 On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> Certain GPIO descriptor arrays returned by gpio_get_array() may
> contain
> information on direct mapping of array members to pins of a single
> GPIO
> chip in hardware order.  In such cases, bitmaps of values can be
> passed
> directly from/to the chip's .get/set_multiple() callbacks without
> wasting time on iterations.
>
> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> Pins not applicable for fast path are processed as before, skipping
> over the 'fast' ones.
>
> Cc: Jonathan Corbet 
> Signed-off-by: Janusz Krzysztofik 
 I've just noticed that this patch landed in today's linux-next. Sadly
 it
 breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
 device-tree source arch/arm/boot/dts/exynos5250-snow.dts).

 Booting hangs after detecting MMC cards. Reverting this patch fixes the
 boot. I will try later to add some debugs and investigate it further
 what
 really happens when booting hangs.
>>> Hi Marek,
>>>
>>> Thanks for reporting. Could you please try the following fix?
>> Hi again,
>>
>> I realized the patch was not correct, j, not i, should be updated in
>> second
>> hunk. Please try the following one.
>>
>> Thanks,
>> Janusz
>>
>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>> From: Janusz Krzysztofik 
>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>> While skipping fast path bits, bitmap index is not updated with next
>> found zero bit position. Fix it.
>>
>> Signed-off-by: Janusz Krzysztofik 
>
> This one also doesn't help. A quick compare of logs with this version and
> a working system shows, that with your patch (and fix) there are no calls
> to
> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
> you need any more information (what kind of logs will help?), let me know.

There is a debug message on array_info content available at the end of
gpiod_get_array(), could you please activate it and post the message so
we can understand better what is going on?

On the other hand, I've had a look your device-tree configuration and
it looks like that specific setup won't benefit from the fast bitmap path.
You have pin 2 at position 0 and pin 1 at position 1 of the array.
Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
by the old path with apparently buggy code for skipping over fast pins.

As a temporary workaround, you could try to revert the order of pins in
your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
should work for you again by taking the original old path, not skipping
over fast pins.  Results of such check may also help us to better
understand and resolve the issue.

Thanks,
Janusz

>
>> ---
>>   drivers/gpio/gpiolib.c | 7 ---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index a53d17745d21..369bdd358fcc 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool
>> can_sleep,
>>  __set_bit(hwgpio, mask);
>>
>>  if (array_info)
>> -find_next_zero_bit(array_info->get_mask,
>> +i = find_next_zero_bit(array_info->get_mask,
>> array_size, i);
>>  else
>>  i++;
>> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool
>> can_sleep,
>>  trace_gpio_value(desc_to_gpio(desc), 1, value);
>>
>>  if (array_info)
>> -find_next_zero_bit(array_info->get_mask, i, j);
>> +j = find_next_zero_bit(array_info->get_mask, i,
>> +   j);
>>  else
>>  j++;
>>  }
>> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool
>> can_sleep,
>>  }
>>
>>  if (array_info)
>> -find_next_zero_bit(array_info->set_mask,
>> +i = find_next_zero_bit(array_info->set_mask,
>> array_size, i);
>>  else
>>  i++;
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
___
devel mailing list
de...

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

2018-09-21 Thread Janusz Krzysztofik

Hi Marek,

2018-09-21 12:51 GMT+02:00, Janusz Krzysztofik :
> Hi Marek,
>
> 2018-09-21 10:18 GMT+02:00, Marek Szyprowski :
>> Hi Janusz,
>>
>> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik
>>> wrote:
 On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski
 wrote:
> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>> contain
>> information on direct mapping of array members to pins of a single
>> GPIO
>> chip in hardware order.  In such cases, bitmaps of values can be
>> passed
>> directly from/to the chip's .get/set_multiple() callbacks without
>> wasting time on iterations.
>>
>> Add respective code to gpiod_get/set_array_bitmap_complex()
>> functions.
>> Pins not applicable for fast path are processed as before, skipping
>> over the 'fast' ones.
>>
>> Cc: Jonathan Corbet 
>> Signed-off-by: Janusz Krzysztofik 
> I've just noticed that this patch landed in today's linux-next. Sadly
> it
> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>
> Booting hangs after detecting MMC cards. Reverting this patch fixes
> the
> boot. I will try later to add some debugs and investigate it further
> what
> really happens when booting hangs.
 Hi Marek,

 Thanks for reporting. Could you please try the following fix?
>>> Hi again,
>>>
>>> I realized the patch was not correct, j, not i, should be updated in
>>> second
>>> hunk. Please try the following one.
>>>
>>> Thanks,
>>> Janusz
>>>
>>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>>> From: Janusz Krzysztofik 
>>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>>> While skipping fast path bits, bitmap index is not updated with next
>>> found zero bit position. Fix it.
>>>
>>> Signed-off-by: Janusz Krzysztofik 
>>
>> This one also doesn't help. A quick compare of logs with this version and
>> a working system shows, that with your patch (and fix) there are no calls
>> to
>> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
>> you need any more information (what kind of logs will help?), let me
>> know.

One more question. You said before that booting hanged after detecting MMC
cards.  Without the fix, I could imagine it keeps iterating with index not
updated and simply never returns from gpiod_get/set_array_bitmap_complex().
Is the behaviour you observe the same with the fix applied?

Thanks,
Janusz

> There is a debug message on array_info content available at the end of
> gpiod_get_array(), could you please activate it and post the message so
> we can understand better what is going on?
>
> On the other hand, I've had a look your device-tree configuration and
> it looks like that specific setup won't benefit from the fast bitmap path.
> You have pin 2 at position 0 and pin 1 at position 1 of the array.
> Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
> by the old path with apparently buggy code for skipping over fast pins.
>
> As a temporary workaround, you could try to revert the order of pins in
> your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
> should work for you again by taking the original old path, not skipping
> over fast pins.  Results of such check may also help us to better
> understand and resolve the issue.
>
> Thanks,
> Janusz
>
>>
>>> ---
>>>   drivers/gpio/gpiolib.c | 7 ---
>>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>>> index a53d17745d21..369bdd358fcc 100644
>>> --- a/drivers/gpio/gpiolib.c
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool
>>> can_sleep,
>>> __set_bit(hwgpio, mask);
>>>
>>> if (array_info)
>>> -   find_next_zero_bit(array_info->get_mask,
>>> +   i = find_next_zero_bit(array_info->get_mask,
>>>array_size, i);
>>> else
>>> i++;
>>> @@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool
>>> can_sleep,
>>> trace_gpio_value(desc_to_gpio(desc), 1, value);
>>>
>>> if (array_info)
>>> -   find_next_zero_bit(array_info->get_mask, i, j);
>>> +   j = find_next_zero_bit(array_info->get_mask, i,
>>> +  j);
>>> else
>>> j++;
>>> }
>>> @@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool
>>> can_sleep,
>>>

Re: [PATCH 04/13] staging: comedi: ni_routing: Add NI signal routing info

2018-09-21 Thread Ian Abbott


On 19/09/18 17:38, Spencer E. Olson wrote:

See README for a thorough discussion of this content.

Adds tables of all register values for routing various signals to various
terminals on National Instruments hardware.  This information is directly
compared to and taken from register-level programming documentation and/or
register-level programming examples as provided by National Instruments.

Furthermore, this information was mostly compared (favorably) to the
register values already used in the comedi drivers for NI hardware.

Adds tables of valid routes for many devices.  This information is not
consistent from device to device, nor entirely consistent within device
families.  One additional major challenge is that this information does not
seem to be obtainable in any programmatic fashion, neither through the
proprietary NIDAQmx(-base) c-libraries, nor with register level
programming, _nor_ through any documentation.  In fact, the only consistent
source of this information is through the proprietary NI-MAX software,
which currently only runs on Windows platforms.  A further challenge is
that this information cannot be exported from NI-MAX, except by screenshot.

The collection and maintenance of this information is somewhat tedious and
requires frequent re-examination and comparison of NI-MAX and/or the
NI-MHDDK documentation (register programming information) and NI-MHDDK
examples.  Tools are added with this patch to facilitate generating CSV
files from the data tables.  These CSV files can be used with a spreadsheet
program to provide better visual comparision with screenshots gathered from
NI-MAX.  Tools are also added to regenerate the data tables from CSV
content--this greatly enhances updating data tables with large changes
(such as when adding devices).

Signed-off-by: Spencer E. Olson 
---
  .../staging/comedi/drivers/ni_routing/README  |  240 ++
  .../drivers/ni_routing/ni_device_routes.c |   66 +
  .../ni_routing/ni_device_routes/pci-6070e.c   |  637 
  .../ni_routing/ni_device_routes/pci-6220.c| 1416 +++
  .../ni_routing/ni_device_routes/pci-6221.c| 1600 
  .../ni_routing/ni_device_routes/pci-6229.c| 1600 
  .../ni_routing/ni_device_routes/pci-6251.c| 1650 
  .../ni_routing/ni_device_routes/pci-6254.c| 1462 +++
  .../ni_routing/ni_device_routes/pci-6259.c| 1650 
  .../ni_routing/ni_device_routes/pci-6534.c|  288 ++
  .../ni_routing/ni_device_routes/pci-6602.c| 3376 +
  .../ni_routing/ni_device_routes/pci-6713.c|  398 ++
  .../ni_routing/ni_device_routes/pci-6723.c|  398 ++
  .../ni_routing/ni_device_routes/pci-6733.c|  426 +++
  .../ni_routing/ni_device_routes/pxi-6030e.c   |  606 +++
  .../ni_routing/ni_device_routes/pxi-6224.c| 1430 +++
  .../ni_routing/ni_device_routes/pxi-6225.c| 1611 
  .../ni_routing/ni_device_routes/pxi-6251.c| 1653 
  .../ni_routing/ni_device_routes/pxi-6733.c|  426 +++
  .../ni_routing/ni_device_routes/pxie-6251.c   | 1654 
  .../drivers/ni_routing/ni_route_values.c  |   96 +
  .../ni_routing/ni_route_values/ni_660x.c  |  641 
  .../ni_routing/ni_route_values/ni_eseries.c   |  593 +++
  .../ni_routing/ni_route_values/ni_mseries.c   | 1743 +
  .../drivers/ni_routing/tools/.gitignore   |4 +
  .../comedi/drivers/ni_routing/tools/Makefile  |   67 +
  .../ni_routing/tools/convert_c_to_py.c|  161 +
  .../ni_routing/tools/convert_csv_to_c.py  |  409 ++
  .../ni_routing/tools/convert_py_to_csv.py |   67 +
  .../ni_routing/tools/csv_collection.py|   40 +
  .../ni_routing/tools/make_blank_csv.py|   32 +
  .../drivers/ni_routing/tools/ni_names.py  |   55 +
  32 files changed, 26495 insertions(+)
  create mode 100644 drivers/staging/comedi/drivers/ni_routing/README
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6070e.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6220.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6221.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6229.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6251.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6254.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6259.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6534.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6602.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6713.c
  create mode 100644 
drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6723.c
  create mode 100644 
driv

Re: [PATCH] staging: comedi: ni_mio_common: protect register write overflow

2018-09-21 Thread Ian Abbott


On 19/09/18 17:17, Spencer E. Olson wrote:

Fixes two problems introduced as early as
commit 03aef4b6dc12  ("Staging: comedi: add ni_mio_common code"):
(1) Ensures that the last four bits of NISTC_RTSI_TRIGB_OUT_REG register is
 not unduly overwritten on e-series devices.  On e-series devices, the
 first three of the last four bits are reserved.  The last bit defines
 the output selection of the RGOUT0 pin, otherwise known as
 RTSI_Sub_Selection.  For m-series devices, these last four bits are
 indeed used as the output selection of the RTSI7 pin (and the
 RTSI_Sub_Selection bit for the RGOUT0 pin is moved to the
 RTSI_Trig_Direction register.
(2) Allows all 4 RTSI_BRD lines to be treated as valid sources for RTSI
 lines.

This patch also cleans up the ni_get_rtsi_routing command for readability.

Fixes: 03aef4b6dc12  ("Staging: comedi: add ni_mio_common code")
Signed-off-by: Spencer E. Olson 
---
I thought I had already submitted this patch a while ago...  Whoops.
  .../staging/comedi/drivers/ni_mio_common.c| 24 +--
  1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 4dee2fc37aed..4d0d0621780e 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4980,7 +4980,10 @@ static int ni_valid_rtsi_output_source(struct 
comedi_device *dev,
case NI_RTSI_OUTPUT_G_SRC0:
case NI_RTSI_OUTPUT_G_GATE0:
case NI_RTSI_OUTPUT_RGOUT0:
-   case NI_RTSI_OUTPUT_RTSI_BRD_0:
+   case NI_RTSI_OUTPUT_RTSI_BRD(0):
+   case NI_RTSI_OUTPUT_RTSI_BRD(1):
+   case NI_RTSI_OUTPUT_RTSI_BRD(2):
+   case NI_RTSI_OUTPUT_RTSI_BRD(3):
return 1;
case NI_RTSI_OUTPUT_RTSI_OSC:
return (devpriv->is_m_series) ? 1 : 0;
@@ -5001,11 +5004,18 @@ static int ni_set_rtsi_routing(struct comedi_device 
*dev,
devpriv->rtsi_trig_a_output_reg |= NISTC_RTSI_TRIG(chan, src);
ni_stc_writew(dev, devpriv->rtsi_trig_a_output_reg,
  NISTC_RTSI_TRIGA_OUT_REG);
-   } else if (chan < 8) {
+   } else if (chan < NISTC_RTSI_TRIG_NUM_CHAN(devpriv->is_m_series)) {
devpriv->rtsi_trig_b_output_reg &= ~NISTC_RTSI_TRIG_MASK(chan);
devpriv->rtsi_trig_b_output_reg |= NISTC_RTSI_TRIG(chan, src);
ni_stc_writew(dev, devpriv->rtsi_trig_b_output_reg,
  NISTC_RTSI_TRIGB_OUT_REG);
+   } else if (chan != NISTC_RTSI_TRIG_OLD_CLK_CHAN) {
+   /* probably should never reach this, since the
+* ni_valid_rtsi_output_source above errors out if chan is too
+* high
+*/
+   dev_err(dev->class_dev, "%s: unknown rtsi channel\n", __func__);
+   return -EINVAL;
}
return 2;
  }
@@ -5021,12 +5031,12 @@ static unsigned int ni_get_rtsi_routing(struct 
comedi_device *dev,
} else if (chan < NISTC_RTSI_TRIG_NUM_CHAN(devpriv->is_m_series)) {
return NISTC_RTSI_TRIG_TO_SRC(chan,
  devpriv->rtsi_trig_b_output_reg);
-   } else {
-   if (chan == NISTC_RTSI_TRIG_OLD_CLK_CHAN)
-   return NI_RTSI_OUTPUT_RTSI_OSC;
-   dev_err(dev->class_dev, "bug! should never get here?\n");
-   return 0;
+   } else if (chan == NISTC_RTSI_TRIG_OLD_CLK_CHAN)
+   return NI_RTSI_OUTPUT_RTSI_OSC;
}
+
+   dev_err(dev->class_dev, "%s: unknown rtsi channel\n", __func__);
+   return -EINVAL;
  }
  
  static int ni_rtsi_insn_config(struct comedi_device *dev,




Looks good, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott  || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268.  Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/13] device-global identifiers and routes introduced

2018-09-21 Thread Ian Abbott


On 19/09/18 17:38, Spencer E. Olson wrote:

Because this patchset has come so far after my last version, I am submitting it
without reference to the older patch set.

--

This patchset introduces a new framework for providing and maintaining a
consistent namespace to define terminal/signal names for a set of comedi
devices.  This effort was primarily focused on supporting NI hardware, but the
interfaces introduced here can be implemented by all other hardware drivers, if
desired.  Otherwise, these new interfaces do not effect any interfaces
previously defined or prior use cases (i.e. backwards compatibility).

Some background:
   There have been significant confusions over the past many years for users
   when trying to understand how to connect to/from signals and terminals on
   NI hardware using comedi.  The major reason for this is that the actual
   register values were exposed and required to be used by end users.  Several
   major reasons exist why this caused major confusion for users:

   1) The register values are _NOT_ in user documentation, but rather in
 arcane locations, such as a few register programming manuals that are
 increasingly hard to find.  Some information is found in the register level
 programming libraries provided by National Instruments (NI-MHDDK), but
 many items are only vaguely found/mentioned in the comments of the NI-MHDDK
 example code.  There is no one place to find the various valid values of 
the
 registers.

   2) The register values are _NOT_ completely consistent.  There is no way to
 gain any sense of intuition of which values, or even enums one should use
 for various registers.  There was some attempt in prior use of comedi to
 name enums such that a user might know which enums should be used for
 varying purposes, but the end-user had to gain a knowledge of register
 values to correctly wield this approach.

   3) The names for signals and registers found in the various register level
 programming manuals and vendor-provided documentation are _not_ even
 close to the same names that are in the end-user documentation.

   4) The sets of routes that are valid are not consistent from device to 
device.
 One additional major challenge is that this information is not documented
 and does not seem to be obtainable in any programmatic fashion, neither
 through the proprietary NIDAQmx(-base) c-libraries, nor with register level
 programming.  In fact, the only consistent source of this information is
 through the proprietary NI-MAX software, which currently only runs on
 Windows platforms.  A further challenge is that this information cannot be
 exported from NI-MAX, except by screenshot.

Similar confusion, albeit less, plagued NI's previous version of their own
proprietary drivers.  Earlier than 2003, NI greatly simplified the situation for
users by releasing a new API that abstracted the names of signals/terminals to a
common and intuitive set of names.  In addition, this new API provided a much
more common interface to use for most of NI hardware.

Comedi already provides such a common interface for data-acquisition and control
hardware.  This effort complements comedi's abstraction layers by further
abstracting much more of the use cases for NI hardware, but allowing users _and_
developers to directly refer to NI documentation (user-level, register-level,
and the register-level examples of the NI-MHDDK).

The goal of these patches are:
   0) Allow current code to function as is, providing backwards compatibility to
 the current interface, following a suggestion by Eric Piel.
   1) Provide an interface to connect routes or identify signal sources and
 destinations using a consistent naming scheme, global to a driver family.
   2) For NI devices, use terminal/signal naming that is consistent with (a) the
 NI's user level documentation, (b) NI's user-level code, (c) the 
information
 as provided by the proprietary NI-MAX software, and (d) the user interface
 code provided by the user-land comedilib library.
   3) Make for easy maintenance of register level values that are to be used for
 any particular NI device of any particular NI device family.
   4) Provide a means whereby the user can query the set of signal routes that 
is
 valid for a particular device.
   5) Provide an interface whereby the user can query the status and capability
 of any signal route.  The driver can provide information on whether the
 route is valid for the device and whether the route is already connected.

This patch set implements various changes that keep the goals set forth here.
This patch set is in nowise complete with respect to the various NI hardware
options supported by comedi, though a large selection should be supported--all
e/m-series (ni_mio_common.c hardware) boards and 660x boards are the target of
this patch set, including the tio devices (counter/timers) us

Re: [PATCH 0/4] Add facility to directly query subdevice timing

2018-09-21 Thread Ian Abbott


On 19/09/18 17:51, Spencer E. Olson wrote:

This patchset adds a facility to directly query hardware speed limits of
subdevices, in particular for scan_begin and convert signals.  This information
is generally already stored for many devices, such as analog input devices for
NI hardware.  This patchset makes this information available.  This patchset
also adds similar information for several digital devices.

Spencer E. Olson (4):
   staging: comedi: add facility to directly query subdevice timing
 constraints
   staging: comedi: ni_mio_common: implement
 INSN_CONFIG_GET_CMD_TIMING_CONSTRAINTS
   staging: comedi: ni_pcidio: implement
 INSN_CONFIG_GET_CMD_TIMING_CONSTRAINTS
   staging: comedi: comedi_test: implement
 INSN_CONFIG_GET_CMD_TIMING_CONSTRAINTS

  drivers/staging/comedi/comedi.h   |  5 ++-
  drivers/staging/comedi/comedi_fops.c  |  4 ++
  drivers/staging/comedi/drivers/comedi_test.c  | 44 +++
  .../staging/comedi/drivers/ni_mio_common.c| 24 ++
  drivers/staging/comedi/drivers/ni_pcidio.c| 13 ++
  drivers/staging/comedi/drivers/ni_pcimio.c| 21 +
  drivers/staging/comedi/drivers/ni_stc.h   |  1 +
  7 files changed, 111 insertions(+), 1 deletion(-)



Those all look great, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott  || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268.  Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

2018-09-21 Thread Marek Szyprowski

Hi Janusz,


On 2018-09-21 12:51, Janusz Krzysztofik wrote:
> 2018-09-21 10:18 GMT+02:00, Marek Szyprowski :
>> On 2018-09-20 18:21, Janusz Krzysztofik wrote:
>>> On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
 On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
>> Certain GPIO descriptor arrays returned by gpio_get_array() may
>> contain
>> information on direct mapping of array members to pins of a single
>> GPIO
>> chip in hardware order.  In such cases, bitmaps of values can be
>> passed
>> directly from/to the chip's .get/set_multiple() callbacks without
>> wasting time on iterations.
>>
>> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
>> Pins not applicable for fast path are processed as before, skipping
>> over the 'fast' ones.
>>
>> Cc: Jonathan Corbet 
>> Signed-off-by: Janusz Krzysztofik 
> I've just noticed that this patch landed in today's linux-next. Sadly
> it
> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>
> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> boot. I will try later to add some debugs and investigate it further
> what
> really happens when booting hangs.
 Hi Marek,

 Thanks for reporting. Could you please try the following fix?
>>> Hi again,
>>>
>>> I realized the patch was not correct, j, not i, should be updated in
>>> second
>>> hunk. Please try the following one.
>>>
>>> Thanks,
>>> Janusz
>>>
>>> >From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
>>> From: Janusz Krzysztofik 
>>> Date: Thu, 20 Sep 2018 17:37:21 +0200
>>> Subject: [PATCH] gpiolib: Fix bitmap index not updated
>>> While skipping fast path bits, bitmap index is not updated with next
>>> found zero bit position. Fix it.
>>>
>>> Signed-off-by: Janusz Krzysztofik 
>> This one also doesn't help. A quick compare of logs with this version and
>> a working system shows, that with your patch (and fix) there are no calls
>> to
>> gpx0-2 pin (which are a part of mmc pwrseq), what causes mmc failure. If
>> you need any more information (what kind of logs will help?), let me know.
> There is a debug message on array_info content available at the end of
> gpiod_get_array(), could you please activate it and post the message so
> we can understand better what is going on?

With debug enabled on next-20180919:
[    2.499153] pwrseq_simple mmc3_pwrseq: GPIO array info: chip=gpx0, 
size=2, get_mask=2, set_mask=2, invert_mask=2

On next-20180920 I get no this message and booting hangs.

Same with next-20180920 + your second fix from this thread.

I will try to debug this more on Monday.

> On the other hand, I've had a look your device-tree configuration and
> it looks like that specific setup won't benefit from the fast bitmap path.
> You have pin 2 at position 0 and pin 1 at position 1 of the array.
> Hence, the fast bitmap path covers only pin 1, and pin 2 is processed
> by the old path with apparently buggy code for skipping over fast pins.
>
> As a temporary workaround, you could try to revert the order of pins in
> your dts file (pin 1 at position 0, pin 2 at 1) and the mmc pwrseq code
> should work for you again by taking the original old path, not skipping
> over fast pins.  Results of such check may also help us to better
> understand and resolve the issue.

Changing the order of mmc pwrseq gpio pins fixes boot hang.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] staging: android: ion: Add per-heap counters

2018-09-21 Thread Laura Abbott


On 09/11/2018 04:29 AM, Alexey Skidanov wrote:

Heap statistics have been removed and currently even basics statistics
are missing.

This patch creates per heap debugfs directory /sys/kernel/debug/
and adds the following counters:
- the number of allocated buffers;
- the number of allocated bytes;
- the number of allocated bytes watermark.

Signed-off-by: Alexey Skidanov 
---

  v3:
Removed debugfs_create_dir() return value checking

  drivers/staging/android/ion/ion.c | 46 ---
  drivers/staging/android/ion/ion.h |  6 ++---
  2 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 9907332..ba4c6e6 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -95,6 +95,11 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
goto err1;
}
  
+	heap->num_of_buffers++;

+   heap->num_of_alloc_bytes += len;
+   if (heap->num_of_alloc_bytes > heap->alloc_bytes_wm)
+   heap->alloc_bytes_wm = heap->num_of_alloc_bytes;
+
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
mutex_lock(&dev->buffer_lock);
@@ -117,6 +122,9 @@ void ion_buffer_destroy(struct ion_buffer *buffer)
buffer->heap->ops->unmap_kernel(buffer->heap, buffer);
}
buffer->heap->ops->free(buffer);
+   buffer->heap->num_of_buffers--;
+   buffer->heap->num_of_alloc_bytes -= buffer->size;
+
kfree(buffer);
  }
  
@@ -528,6 +536,8 @@ void ion_device_add_heap(struct ion_heap *heap)

  {
struct ion_device *dev = internal_dev;
int ret;
+   struct dentry *heap_root;
+   char debug_name[64];
  
  	if (!heap->ops->allocate || !heap->ops->free)

pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -546,6 +556,34 @@ void ion_device_add_heap(struct ion_heap *heap)
}
  
  	heap->dev = dev;

+   heap->num_of_buffers = 0;
+   heap->num_of_alloc_bytes = 0;
+   heap->alloc_bytes_wm = 0;
+
+   /* Create heap root directory */
+   heap_root = debugfs_create_dir(heap->name, dev->debug_root);
+   debugfs_create_u64("num_of_buffers",
+  0444, heap_root,
+  &heap->num_of_buffers);
+   debugfs_create_u64("num_of_alloc_bytes",
+  0444,
+  heap_root,
+  &heap->num_of_alloc_bytes);
+   debugfs_create_u64("alloc_bytes_wm",
+  0444,
+  heap_root,
+  &heap->alloc_bytes_wm);
+
+   if (heap->shrinker.count_objects &&
+   heap->shrinker.scan_objects) {
+   snprintf(debug_name, 64, "%s_shrink", heap->name);
+   debugfs_create_file(debug_name,
+   0644,
+   heap_root,
+   heap,
+   &debug_shrink_fops);
+   }
+
down_write(&dev->lock);
heap->id = heap_id++;
/*
@@ -555,14 +593,6 @@ void ion_device_add_heap(struct ion_heap *heap)
plist_node_init(&heap->node, -heap->id);
plist_add(&heap->node, &dev->heaps);
  
-	if (heap->shrinker.count_objects && heap->shrinker.scan_objects) {

-   char debug_name[64];
-
-   snprintf(debug_name, 64, "%s_shrink", heap->name);
-   debugfs_create_file(debug_name, 0644, dev->debug_root,
-   heap, &debug_shrink_fops);
-   }
-
dev->heap_cnt++;
up_write(&dev->lock);
  }
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 16cbd38..bea84b6 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -179,9 +179,9 @@ struct ion_heap {
spinlock_t free_lock;
wait_queue_head_t waitqueue;
struct task_struct *task;
-
-   int (*debug_show)(struct ion_heap *heap, struct seq_file *s,
- void *unused);
+   u64 num_of_buffers;
+   u64 num_of_alloc_bytes;
+   u64 alloc_bytes_wm;


What lock is protecting these?


  };
  
  /**




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] memory_hotplug: Free pages as higher order

2018-09-21 Thread Dan Williams

On Fri, Sep 21, 2018 at 2:40 AM Arun KS  wrote:
>
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add latency by 60%.
>
> Modify external providers of online callback to align with
> the change.
>
> Signed-off-by: Arun KS 
>
> ---
>
> Changes since RFC:
> - Rebase.
> - As suggested by Michal Hocko remove pages_per_block.
> - Modifed external providers of online_page_callback.
>
> RFC:
> https://lore.kernel.org/patchwork/patch/984754/
> ---
>  drivers/hv/hv_balloon.c|  6 +++--
>  drivers/xen/balloon.c  | 18 +++---
>  include/linux/memory_hotplug.h |  2 +-
>  mm/memory_hotplug.c| 55 
> +-
>  4 files changed, 63 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index b1b7880..c5bc0b5 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -771,7 +771,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
> long size,
> }
>  }
>
> -static void hv_online_page(struct page *pg)
> +static int hv_online_page(struct page *pg, unsigned int order)
>  {
> struct hv_hotadd_state *has;
> unsigned long flags;
> @@ -783,10 +783,12 @@ static void hv_online_page(struct page *pg)
> if ((pfn < has->start_pfn) || (pfn >= has->end_pfn))
> continue;
>
> -   hv_page_online_one(has, pg);
> +   hv_bring_pgs_online(has, pfn, (1UL << order));
> break;
> }
> spin_unlock_irqrestore(&dm_device.ha_lock, flags);
> +
> +   return 0;
>  }
>
>  static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index e12bb25..010cf4d 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -390,8 +390,8 @@ static enum bp_state reserve_additional_memory(void)
>
> /*
>  * add_memory_resource() will call online_pages() which in its turn
> -* will call xen_online_page() callback causing deadlock if we don't
> -* release balloon_mutex here. Unlocking here is safe because the
> +* will call xen_bring_pgs_online() callback causing deadlock if we
> +* don't release balloon_mutex here. Unlocking here is safe because 
> the
>  * callers drop the mutex before trying again.
>  */
> mutex_unlock(&balloon_mutex);
> @@ -422,6 +422,18 @@ static void xen_online_page(struct page *page)
> mutex_unlock(&balloon_mutex);
>  }
>
> +static int xen_bring_pgs_online(struct page *pg, unsigned int order)
> +{
> +   unsigned long i, size = (1 << order);
> +   unsigned long start_pfn = page_to_pfn(pg);
> +
> +   pr_debug("Online %lu pages starting at pfn 0x%lx\n", size, start_pfn);
> +   for (i = 0; i < size; i++)
> +   xen_online_page(pfn_to_page(start_pfn + i));
> +
> +   return 0;
> +}
> +
>  static int xen_memory_notifier(struct notifier_block *nb, unsigned long val, 
> void *v)
>  {
> if (val == MEM_ONLINE)
> @@ -744,7 +756,7 @@ static int __init balloon_init(void)
> balloon_stats.max_retry_count = RETRY_UNLIMITED;
>
>  #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
> -   set_online_page_callback(&xen_online_page);
> +   set_online_page_callback(&xen_bring_pgs_online);
> register_memory_notifier(&xen_memory_nb);
> register_sysctl_table(xen_root);
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 34a2822..7b04c1d 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -87,7 +87,7 @@ extern int test_pages_in_a_zone(unsigned long start_pfn, 
> unsigned long end_pfn,
> unsigned long *valid_start, unsigned long *valid_end);
>  extern void __offline_isolated_pages(unsigned long, unsigned long);
>
> -typedef void (*online_page_callback_t)(struct page *page);
> +typedef int (*online_page_callback_t)(struct page *page, unsigned int order);
>
>  extern int set_online_page_callback(online_page_callback_t callback);
>  extern int restore_online_page_callback(online_page_callback_t callback);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 38d94b7..24c2b8e 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -47,7 +47,7 @@
>   * and restore_online_page_callback() for generic callback restore.
>   */
>
> -static void generic_online_page(struct page *page);
> +static int generic_online_page(struct page *page, unsigned int order);
>
>  static online_page_callback_t online_page_callback = generic_online_page;
>  static DEFINE_MUTEX(online_page_callback_lock);
> @@ -655,26 +655,57 @@ void __online_page_free(struct page *page)
>  }
>  EXPORT_SYMBOL_GPL(__online_page_free);

[PATCH] staging: rtl8188eu: Remove unnecessary parentheses

2018-09-21 Thread Nathan Chancellor

Clang warns when multiple pairs of parentheses are used for a single
conditional statement.

drivers/staging/rtl8188eu/core/rtw_pwrctrl.c:295:21: warning: equality
comparison with extraneous parentheses [-Wparentheses-equality]
if ((pwrpriv->rpwm == pslv)) {
 ~~^~~
drivers/staging/rtl8188eu/core/rtw_pwrctrl.c:295:21: note: remove
extraneous parentheses around the comparison to silence this warning
if ((pwrpriv->rpwm == pslv)) {
~  ^  ~
drivers/staging/rtl8188eu/core/rtw_pwrctrl.c:295:21: note: use '=' to
turn this equality comparison into an assignment
if ((pwrpriv->rpwm == pslv)) {
   ^~
   =
drivers/staging/rtl8188eu/hal/odm.c:1062:27: warning: equality
comparison with extraneous parentheses [-Wparentheses-equality]
if ((pregpriv->wifi_spec == 1))/*  (pmlmeinfo->HT_enable == 0))
*/
 ^~~~
drivers/staging/rtl8188eu/hal/odm.c:1062:27: note: remove extraneous
parentheses around the comparison to silence this warning
if ((pregpriv->wifi_spec == 1))/*  (pmlmeinfo->HT_enable == 0))
*/
~^   ~
drivers/staging/rtl8188eu/hal/odm.c:1062:27: note: use '=' to turn this
equality comparison into an assignment
if ((pregpriv->wifi_spec == 1))/*  (pmlmeinfo->HT_enable == 0))
*/
 ^~
 =

Link: https://github.com/ClangBuiltLinux/linux/issues/163
Signed-off-by: Nathan Chancellor 
---
 drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 2 +-
 drivers/staging/rtl8188eu/hal/odm.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_pwrctrl.c 
b/drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
index 5ab6fc22a156..a3d3e9eb133c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
+++ b/drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
@@ -292,7 +292,7 @@ void rtw_set_rpwm(struct adapter *padapter, u8 pslv)
pslv = PS_STATE_S3;
}
 
-   if ((pwrpriv->rpwm == pslv)) {
+   if (pwrpriv->rpwm == pslv) {
RT_TRACE(_module_rtl871x_pwrctrl_c_, _drv_err_,
 ("%s: Already set rpwm[0x%02X], new=0x%02X!\n", 
__func__, pwrpriv->rpwm, pslv));
return;
diff --git a/drivers/staging/rtl8188eu/hal/odm.c 
b/drivers/staging/rtl8188eu/hal/odm.c
index 48738f94cf88..5a0c38ecb15e 100644
--- a/drivers/staging/rtl8188eu/hal/odm.c
+++ b/drivers/staging/rtl8188eu/hal/odm.c
@@ -1059,7 +1059,7 @@ void odm_EdcaTurboCheckCE(struct odm_dm_struct *pDM_Odm)
struct mlme_ext_priv*pmlmeext = &(Adapter->mlmeextpriv);
struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
 
-   if ((pregpriv->wifi_spec == 1))/*  (pmlmeinfo->HT_enable == 0)) */
+   if (pregpriv->wifi_spec == 1) /*  (pmlmeinfo->HT_enable == 0)) */
goto dm_CheckEdcaTurbo_EXIT;
 
if (pmlmeinfo->assoc_AP_vendor >=  HT_IOT_PEER_MAX)
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next,v2,0/3] hv_netvsc: Support LRO/RSC in the vSwitch

2018-09-21 Thread Haiyang Zhang

From: Haiyang Zhang 

The patch adds support for LRO/RSC in the vSwitch feature. It reduces
the per packet processing overhead by coalescing multiple TCP segments
when possible. The feature is enabled by default on VMs running on
Windows Server 2019 and later.

The patch set also adds ethtool command handler and documents.

Haiyang Zhang (3):
  hv_netvsc: Add support for LRO/RSC in the vSwitch
  hv_netvsc: Add handler for LRO setting change
  hv_netvsc: Update document for LRO/RSC support

 Documentation/networking/netvsc.txt |  9 +++
 drivers/net/hyperv/hyperv_net.h | 51 ---
 drivers/net/hyperv/netvsc.c | 18 --
 drivers/net/hyperv/netvsc_drv.c | 58 -
 drivers/net/hyperv/rndis_filter.c   | 97 +
 5 files changed, 194 insertions(+), 39 deletions(-)

-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next, v2, 2/3] hv_netvsc: Add handler for LRO setting change

2018-09-21 Thread Haiyang Zhang

From: Haiyang Zhang 

This patch adds the handler for LRO setting change, so that a user
can use ethtool command to enable / disable LRO feature.

Signed-off-by: Haiyang Zhang 
---
 drivers/net/hyperv/hyperv_net.h   |  4 
 drivers/net/hyperv/netvsc_drv.c   | 30 ++
 drivers/net/hyperv/rndis_filter.c | 11 ---
 3 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 7f1603dc8128..ef6f766f6389 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -185,6 +185,7 @@ struct rndis_device {
 
 /* Interface */
 struct rndis_message;
+struct ndis_offload_params;
 struct netvsc_device;
 struct netvsc_channel;
 struct net_device_context;
@@ -218,6 +219,9 @@ void rndis_filter_device_remove(struct hv_device *dev,
struct netvsc_device *nvdev);
 int rndis_filter_set_rss_param(struct rndis_device *rdev,
   const u8 *key);
+int rndis_filter_set_offload_params(struct net_device *ndev,
+   struct netvsc_device *nvdev,
+   struct ndis_offload_params *req_offloads);
 int rndis_filter_receive(struct net_device *ndev,
 struct netvsc_device *net_dev,
 struct netvsc_channel *nvchan,
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index f8c18370d9d1..ec699741170b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1006,6 +1006,8 @@ static void netvsc_init_settings(struct net_device *dev)
 
ndc->speed = SPEED_UNKNOWN;
ndc->duplex = DUPLEX_FULL;
+
+   dev->features = NETIF_F_LRO;
 }
 
 static int netvsc_get_link_ksettings(struct net_device *dev,
@@ -1733,6 +1735,33 @@ static int netvsc_set_ringparam(struct net_device *ndev,
return ret;
 }
 
+static int netvsc_set_features(struct net_device *ndev,
+  netdev_features_t features)
+{
+   netdev_features_t change = features ^ ndev->features;
+   struct net_device_context *ndevctx = netdev_priv(ndev);
+   struct netvsc_device *nvdev = rtnl_dereference(ndevctx->nvdev);
+   struct ndis_offload_params offloads;
+
+   if (!nvdev || nvdev->destroy)
+   return -ENODEV;
+
+   if (!(change & NETIF_F_LRO))
+   return 0;
+
+   memset(&offloads, 0, sizeof(struct ndis_offload_params));
+
+   if (features & NETIF_F_LRO) {
+   offloads.rsc_ip_v4 = NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED;
+   offloads.rsc_ip_v6 = NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED;
+   } else {
+   offloads.rsc_ip_v4 = NDIS_OFFLOAD_PARAMETERS_RSC_DISABLED;
+   offloads.rsc_ip_v6 = NDIS_OFFLOAD_PARAMETERS_RSC_DISABLED;
+   }
+
+   return rndis_filter_set_offload_params(ndev, nvdev, &offloads);
+}
+
 static u32 netvsc_get_msglevel(struct net_device *ndev)
 {
struct net_device_context *ndev_ctx = netdev_priv(ndev);
@@ -1776,6 +1805,7 @@ static const struct net_device_ops device_ops = {
.ndo_start_xmit =   netvsc_start_xmit,
.ndo_change_rx_flags =  netvsc_change_rx_flags,
.ndo_set_rx_mode =  netvsc_set_rx_mode,
+   .ndo_set_features = netvsc_set_features,
.ndo_change_mtu =   netvsc_change_mtu,
.ndo_validate_addr =eth_validate_addr,
.ndo_set_mac_address =  netvsc_set_mac_addr,
diff --git a/drivers/net/hyperv/rndis_filter.c 
b/drivers/net/hyperv/rndis_filter.c
index f3ac66386297..8b537a049c1e 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -716,7 +716,7 @@ int rndis_filter_set_device_mac(struct netvsc_device *nvdev,
return ret;
 }
 
-static int
+int
 rndis_filter_set_offload_params(struct net_device *ndev,
struct netvsc_device *nvdev,
struct ndis_offload_params *req_offloads)
@@ -1246,8 +1246,13 @@ static int rndis_netdev_set_hwcaps(struct rndis_device 
*rndis_device,
if (hwcaps.rsc.ip4 && hwcaps.rsc.ip6) {
net->hw_features |= NETIF_F_LRO;
 
-   offloads.rsc_ip_v4 = NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED;
-   offloads.rsc_ip_v6 = NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED;
+   if (net->features & NETIF_F_LRO) {
+   offloads.rsc_ip_v4 = 
NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED;
+   offloads.rsc_ip_v6 = 
NDIS_OFFLOAD_PARAMETERS_RSC_ENABLED;
+   } else {
+   offloads.rsc_ip_v4 = 
NDIS_OFFLOAD_PARAMETERS_RSC_DISABLED;
+   offloads.rsc_ip_v6 = 
NDIS_OFFLOAD_PARAMETERS_RSC_DISABLED;
+   }
}
 
/* In case some hw_features disappeared we need to remove them from
-- 
2.18.0

_

[PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

2018-09-21 Thread Haiyang Zhang

From: Haiyang Zhang 

LRO/RSC in the vSwitch is a feature available in Windows Server 2019
hosts and later. It reduces the per packet processing overhead by
coalescing multiple TCP segments when possible. This patch adds netvsc
driver support for this feature.

Signed-off-by: Haiyang Zhang 
---
 drivers/net/hyperv/hyperv_net.h   | 47 +---
 drivers/net/hyperv/netvsc.c   | 18 +--
 drivers/net/hyperv/netvsc_drv.c   | 28 +-
 drivers/net/hyperv/rndis_filter.c | 90 ++-
 4 files changed, 145 insertions(+), 38 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index a32ded5b4f41..7f1603dc8128 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -186,6 +186,7 @@ struct rndis_device {
 /* Interface */
 struct rndis_message;
 struct netvsc_device;
+struct netvsc_channel;
 struct net_device_context;
 
 extern u32 netvsc_ring_bytes;
@@ -203,10 +204,7 @@ void netvsc_linkstatus_callback(struct net_device *net,
struct rndis_message *resp);
 int netvsc_recv_callback(struct net_device *net,
 struct netvsc_device *nvdev,
-struct vmbus_channel *channel,
-void  *data, u32 len,
-const struct ndis_tcp_ip_checksum_info *csum_info,
-const struct ndis_pkt_8021q_info *vlan);
+struct netvsc_channel *nvchan);
 void netvsc_channel_cb(void *context);
 int netvsc_poll(struct napi_struct *napi, int budget);
 
@@ -222,7 +220,7 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
   const u8 *key);
 int rndis_filter_receive(struct net_device *ndev,
 struct netvsc_device *net_dev,
-struct vmbus_channel *channel,
+struct netvsc_channel *nvchan,
 void *data, u32 buflen);
 
 int rndis_filter_set_device_mac(struct netvsc_device *ndev,
@@ -524,6 +522,8 @@ struct nvsp_2_vsc_capability {
u64 ieee8021q:1;
u64 correlation_id:1;
u64 teaming:1;
+   u64 vsubnetid:1;
+   u64 rsc:1;
};
};
 } __packed;
@@ -826,7 +826,7 @@ struct nvsp_message {
 
 #define NETVSC_SUPPORTED_HW_FEATURES (NETIF_F_RXCSUM | NETIF_F_IP_CSUM | \
  NETIF_F_TSO | NETIF_F_IPV6_CSUM | \
- NETIF_F_TSO6)
+ NETIF_F_TSO6 | NETIF_F_LRO)
 
 #define VRSS_SEND_TAB_SIZE 16  /* must be power of 2 */
 #define VRSS_CHANNEL_MAX 64
@@ -852,6 +852,18 @@ struct multi_recv_comp {
u32 next;   /* next entry for writing */
 };
 
+#define NVSP_RSC_MAX 562 /* Max #RSC frags in a vmbus xfer page pkt */
+
+struct nvsc_rsc {
+   const struct ndis_pkt_8021q_info *vlan;
+   const struct ndis_tcp_ip_checksum_info *csum_info;
+   u8 is_last; /* last RNDIS msg in a vmtransfer_page */
+   u32 cnt; /* #fragments in an RSC packet */
+   u32 pktlen; /* Full packet length */
+   void *data[NVSP_RSC_MAX];
+   u32 len[NVSP_RSC_MAX];
+};
+
 struct netvsc_stats {
u64 packets;
u64 bytes;
@@ -955,6 +967,7 @@ struct netvsc_channel {
struct multi_send_data msd;
struct multi_recv_comp mrc;
atomic_t queue_sends;
+   struct nvsc_rsc rsc;
 
struct netvsc_stats tx_stats;
struct netvsc_stats rx_stats;
@@ -1136,7 +1149,8 @@ struct rndis_oobd {
 /* Packet extension field contents associated with a Data message. */
 struct rndis_per_packet_info {
u32 size;
-   u32 type;
+   u32 type:31;
+   u32 internal:1;
u32 ppi_offset;
 };
 
@@ -1157,6 +1171,25 @@ enum ndis_per_pkt_info_type {
MAX_PER_PKT_INFO
 };
 
+enum rndis_per_pkt_info_interal_type {
+   RNDIS_PKTINFO_ID = 1,
+   /* Add more memebers here */
+
+   RNDIS_PKTINFO_MAX
+};
+
+#define RNDIS_PKTINFO_SUBALLOC BIT(0)
+#define RNDIS_PKTINFO_1ST_FRAG BIT(1)
+#define RNDIS_PKTINFO_LAST_FRAG BIT(2)
+
+#define RNDIS_PKTINFO_ID_V1 1
+
+struct rndis_pktinfo_id {
+   u8 ver;
+   u8 flag;
+   u16 pkt_id;
+};
+
 struct ndis_pkt_8021q_info {
union {
struct {
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index fe01e141c8f8..922054c1d544 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -542,6 +542,9 @@ static int negotiate_nvsp_ver(struct hv_device *device,
init_packet->msg.v2_msg.send_ndis_config.capability.teaming = 1;
}
 
+   if (nvsp_ver >= NVSP_PROTOCOL_VERSION_61)
+   init_packet->msg.v2_msg.send_ndis_config.capability.rsc = 1;
+
trace_nvsp_send(ndev, init_packet);
 
ret = vmbus_sendpacket(device->channel, init_packet,
@@ -,11 +111

[PATCH net-next, v2, 3/3] hv_netvsc: Update document for LRO/RSC support

2018-09-21 Thread Haiyang Zhang

From: Haiyang Zhang 

Update document for LRO/RSC support, and the command line info to
change the setting.

Signed-off-by: Haiyang Zhang 
---
 Documentation/networking/netvsc.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/networking/netvsc.txt 
b/Documentation/networking/netvsc.txt
index 92f5b31392fa..3bfa635bbbd5 100644
--- a/Documentation/networking/netvsc.txt
+++ b/Documentation/networking/netvsc.txt
@@ -45,6 +45,15 @@ Features
   like packets and significantly reduces CPU usage under heavy Rx
   load.
 
+  Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
+  -
+  The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet
+  processing overhead by coalescing multiple TCP segments when possible. The
+  feature is enabled by default on VMs running on Windows Server 2019 and
+  later. It may be changed by ethtool command:
+   ethtool -K eth0 lro on
+   ethtool -K eth0 lro off
+
   SR-IOV support
   --
   Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

2018-09-21 Thread Stephen Hemminger

On Fri, 21 Sep 2018 18:20:35 +
Haiyang Zhang  wrote:

Overall, this looks good. Some minor suggestions.

> +struct nvsc_rsc {
> + const struct ndis_pkt_8021q_info *vlan;
> + const struct ndis_tcp_ip_checksum_info *csum_info;
> + u8 is_last; /* last RNDIS msg in a vmtransfer_page */
> + u32 cnt; /* #fragments in an RSC packet */
> + u32 pktlen; /* Full packet length */
> + void *data[NVSP_RSC_MAX];
> + u32 len[NVSP_RSC_MAX];
> +};
> +

This new state structure is state on a per-channel basis.
Do you really need this to be persistent across packets?

Could this be on stack or do you need it to handle split packets
arriving in different polls? Or is the stack space a problem?

Also, maybe data and length could be in one structure since they
are related.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

2018-09-21 Thread Haiyang Zhang




> -Original Message-
> From: Stephen Hemminger 
> Sent: Friday, September 21, 2018 2:37 PM
> To: Haiyang Zhang 
> Cc: Haiyang Zhang ; da...@davemloft.net;
> net...@vger.kernel.org; o...@aepfle.de; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; vkuznets 
> Subject: Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in
> the vSwitch
> 
> On Fri, 21 Sep 2018 18:20:35 +
> Haiyang Zhang  wrote:
> 
> Overall, this looks good. Some minor suggestions.
> 
> > +struct nvsc_rsc {
> > +   const struct ndis_pkt_8021q_info *vlan;
> > +   const struct ndis_tcp_ip_checksum_info *csum_info;
> > +   u8 is_last; /* last RNDIS msg in a vmtransfer_page */
> > +   u32 cnt; /* #fragments in an RSC packet */
> > +   u32 pktlen; /* Full packet length */
> > +   void *data[NVSP_RSC_MAX];
> > +   u32 len[NVSP_RSC_MAX];
> > +};
> > +
> 
> This new state structure is state on a per-channel basis.
> Do you really need this to be persistent across packets?
> 
> Could this be on stack or do you need it to handle split packets arriving in
> different polls? Or is the stack space a problem?
> 
> Also, maybe data and length could be in one structure since they are related.

The stack space is a problem. NVSP_RSC_MAX is 562, which is defined by host.
It will be too large for limited stack space. 

struct nvsc_rsc includes the data, len, cnt, chksum, vlan for one RSC packet. 
They
are all related to construction of one SKB and its meta data. So I put them in
one structure.

Thanks,
- Haiyang

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Fix clang warning -Wpointer-bool-conversion by removing unnecessary check in regd.c

2018-09-21 Thread Karthik Nishanth

The member regd of the struct rtl_priv is true in a boolean context.

drivers/staging/rtlwifi/regd.c:413:27: warning: address of 'rtlpriv->regd' will 
always
  evaluate to 'true' [-Wpointer-bool-conversion]
if (!wiphy || !&rtlpriv->regd)
  ~ ~^~~~
1 warning generated.

Link: https://github.com/ClangBuiltLinux/linux/issues/170

Signed-off-by: Karthik Nishanth 
---
 drivers/staging/rtlwifi/regd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtlwifi/regd.c b/drivers/staging/rtlwifi/regd.c
index 3afd206ce4b1..5213ca771175 100644
--- a/drivers/staging/rtlwifi/regd.c
+++ b/drivers/staging/rtlwifi/regd.c
@@ -410,7 +410,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
struct wiphy *wiphy = hw->wiphy;
struct country_code_to_enum_rd *country = NULL;
 
-   if (!wiphy || !&rtlpriv->regd)
+   if (!wiphy)
return -EINVAL;
 
/* init country_code from efuse channel plan */
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: vc04_services: Remove unused vchiq_genversion script

2018-09-21 Thread Tuomas Tynkkynen

As far as I can tell, this has never been used.

Signed-off-by: Tuomas Tynkkynen 
---
 .../interface/vchiq_arm/vchiq_genversion   | 88 --
 1 file changed, 88 deletions(-)
 delete mode 100644 
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_genversion

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_genversion 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_genversion
deleted file mode 100644
index dd1f324a8654..
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_genversion
+++ /dev/null
@@ -1,88 +0,0 @@
-#!/usr/bin/perl -w
-# SPDX-License-Identifier: GPL-2.0
-
-use strict;
-
-#
-# Generate a version from available information
-#
-
-my $prefix = shift @ARGV;
-my $root = shift @ARGV;
-
-
-if ( not defined $root ) {
-   die "usage: $0 prefix root-dir\n";
-}
-
-if ( ! -d $root ) {
-   die "root directory $root not found\n";
-}
-
-my $version = "unknown";
-my $tainted = "";
-
-if ( -d "$root/.git" ) {
-   # attempt to work out git version. only do so
-   # on a linux build host, as cygwin builds are
-   # already slow enough
-
-   if ( -f "/usr/bin/git" || -f "/usr/local/bin/git" ) {
-   if (not open(F, "git --git-dir $root/.git rev-parse --verify 
HEAD|")) {
-   $version = "no git version";
-   }
-   else {
-   $version = ;
-   $version =~ s/[ \r\n]*$//; # chomp may not be 
enough (cygwin).
-   $version =~ s/^[ \r\n]*//; # chomp may not be 
enough (cygwin).
-   }
-
-   if (open(G, "git --git-dir $root/.git status --porcelain|")) {
-   $tainted = ;
-   $tainted =~ s/[ \r\n]*$//; # chomp may not be 
enough (cygwin).
-   $tainted =~ s/^[ \r\n]*//; # chomp may not be 
enough (cygwin).
-   if (length $tainted) {
-   $version = join ' ', $version, "(tainted)";
-   }
-   else {
-   $version = join ' ', $version, "(clean)";
- }
-   }
-   }
-}
-
-my $hostname = `hostname`;
-$hostname =~ s/[ \r\n]*$//; # chomp may not be enough (cygwin).
-$hostname =~ s/^[ \r\n]*//; # chomp may not be enough (cygwin).
-
-
-print STDERR "Version $version\n";
-print <
-
-VC_DEBUG_DECLARE_STRING_VAR( ${prefix}_build_hostname, "$hostname" );
-VC_DEBUG_DECLARE_STRING_VAR( ${prefix}_build_version, "$version" );
-VC_DEBUG_DECLARE_STRING_VAR( ${prefix}_build_time,__TIME__ );
-VC_DEBUG_DECLARE_STRING_VAR( ${prefix}_build_date,__DATE__ );
-
-const char *vchiq_get_build_hostname( void )
-{
-   return vchiq_build_hostname;
-}
-
-const char *vchiq_get_build_version( void )
-{
-   return vchiq_build_version;
-}
-
-const char *vchiq_get_build_date( void )
-{
-   return vchiq_build_date;
-}
-
-const char *vchiq_get_build_time( void )
-{
-   return vchiq_build_time;
-}
-EOF
-- 
2.16.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

2018-09-21 Thread Stephen Hemminger

On Fri, 21 Sep 2018 18:51:54 +
Haiyang Zhang  wrote:

> > -Original Message-
> > From: Stephen Hemminger 
> > Sent: Friday, September 21, 2018 2:37 PM
> > To: Haiyang Zhang 
> > Cc: Haiyang Zhang ; da...@davemloft.net;
> > net...@vger.kernel.org; o...@aepfle.de; linux-ker...@vger.kernel.org;
> > de...@linuxdriverproject.org; vkuznets 
> > Subject: Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in
> > the vSwitch
> > 
> > On Fri, 21 Sep 2018 18:20:35 +
> > Haiyang Zhang  wrote:
> > 
> > Overall, this looks good. Some minor suggestions.
> >   
> > > +struct nvsc_rsc {
> > > + const struct ndis_pkt_8021q_info *vlan;
> > > + const struct ndis_tcp_ip_checksum_info *csum_info;
> > > + u8 is_last; /* last RNDIS msg in a vmtransfer_page */
> > > + u32 cnt; /* #fragments in an RSC packet */
> > > + u32 pktlen; /* Full packet length */
> > > + void *data[NVSP_RSC_MAX];
> > > + u32 len[NVSP_RSC_MAX];
> > > +};
> > > +  
> > 
> > This new state structure is state on a per-channel basis.
> > Do you really need this to be persistent across packets?
> > 
> > Could this be on stack or do you need it to handle split packets arriving in
> > different polls? Or is the stack space a problem?
> > 
> > Also, maybe data and length could be in one structure since they are 
> > related.  
> 
> The stack space is a problem. NVSP_RSC_MAX is 562, which is defined by host.
> It will be too large for limited stack space. 
> 
> struct nvsc_rsc includes the data, len, cnt, chksum, vlan for one RSC packet. 
> They
> are all related to construction of one SKB and its meta data. So I put them in
> one structure.
> 
> Thanks,
> - Haiyang
> 

That makes sense. How big is sizeof(struct net_device) + netdev_priv now?
Need to make sure it doesn't become an order 2 (ie keep it less than 4K).
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

2018-09-21 Thread Haiyang Zhang




> -Original Message-
> From: Stephen Hemminger 
> Sent: Friday, September 21, 2018 4:22 PM
> To: Haiyang Zhang 
> Cc: da...@davemloft.net; net...@vger.kernel.org; o...@aepfle.de; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; vkuznets
> 
> Subject: Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in
> the vSwitch
> 
> On Fri, 21 Sep 2018 18:51:54 +
> Haiyang Zhang  wrote:
> 
> > > -Original Message-
> > > From: Stephen Hemminger 
> > > Sent: Friday, September 21, 2018 2:37 PM
> > > To: Haiyang Zhang 
> > > Cc: Haiyang Zhang ; da...@davemloft.net;
> > > net...@vger.kernel.org; o...@aepfle.de;
> > > linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; vkuznets
> > > 
> > > Subject: Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for
> > > LRO/RSC in the vSwitch
> > >
> > > On Fri, 21 Sep 2018 18:20:35 +
> > > Haiyang Zhang  wrote:
> > >
> > > Overall, this looks good. Some minor suggestions.
> > >
> > > > +struct nvsc_rsc {
> > > > +   const struct ndis_pkt_8021q_info *vlan;
> > > > +   const struct ndis_tcp_ip_checksum_info *csum_info;
> > > > +   u8 is_last; /* last RNDIS msg in a vmtransfer_page */
> > > > +   u32 cnt; /* #fragments in an RSC packet */
> > > > +   u32 pktlen; /* Full packet length */
> > > > +   void *data[NVSP_RSC_MAX];
> > > > +   u32 len[NVSP_RSC_MAX];
> > > > +};
> > > > +
> > >
> > > This new state structure is state on a per-channel basis.
> > > Do you really need this to be persistent across packets?
> > >
> > > Could this be on stack or do you need it to handle split packets
> > > arriving in different polls? Or is the stack space a problem?
> > >
> > > Also, maybe data and length could be in one structure since they are
> related.
> >
> > The stack space is a problem. NVSP_RSC_MAX is 562, which is defined by host.
> > It will be too large for limited stack space.
> >
> > struct nvsc_rsc includes the data, len, cnt, chksum, vlan for one RSC
> > packet. They are all related to construction of one SKB and its meta
> > data. So I put them in one structure.
> >
> > Thanks,
> > - Haiyang
> >
> 
> That makes sense. How big is sizeof(struct net_device) + netdev_priv now?
> Need to make sure it doesn't become an order 2 (ie keep it less than 4K).

This patch does not change struct net_device or netdev_priv, so their size
stays the same. Thanks.

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtlwifi: Use proper enumerated types for Wi-Fi only interface

2018-09-21 Thread Nathan Chancellor

Clang warns when one enumerated type is implicitly converted to another.

drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c:1264:34: warning:
implicit conversion from enumeration type 'enum btc_chip_interface' to
different enumeration type 'enum wifionly_chip_interface'
[-Wenum-conversion]
wifionly_cfg->chip_interface = BTC_INTF_PCI;
 ~ ^~~~
drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c:1267:34: warning:
implicit conversion from enumeration type 'enum btc_chip_interface' to
different enumeration type 'enum wifionly_chip_interface'
[-Wenum-conversion]
wifionly_cfg->chip_interface = BTC_INTF_USB;
 ~ ^~~~
drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c:1270:34: warning:
implicit conversion from enumeration type 'enum btc_chip_interface' to
different enumeration type 'enum wifionly_chip_interface'
[-Wenum-conversion]
wifionly_cfg->chip_interface = BTC_INTF_UNKNOWN;
 ~ ^~~~
3 warnings generated.

Use the values from the correct enumerated type, wifionly_chip_interface.

BTC_INTF_UNKNOWN = WIFIONLY_INTF_UNKNOWN = 0
BTC_INTF_PCI = WIFIONLY_INTF_PCI = 0
BTC_INTF_USB = WIFIONLY_INTF_USB = 0

Link: https://github.com/ClangBuiltLinux/linux/issues/171
Signed-off-by: Nathan Chancellor 
---
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
index 4d1f9bf53c53..85a7490e6bbd 100644
--- a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1261,13 +1261,13 @@ bool exhalbtc_initlize_variables_wifi_only(struct 
rtl_priv *rtlpriv)
 
switch (rtlpriv->rtlhal.interface) {
case INTF_PCI:
-   wifionly_cfg->chip_interface = BTC_INTF_PCI;
+   wifionly_cfg->chip_interface = WIFIONLY_INTF_PCI;
break;
case INTF_USB:
-   wifionly_cfg->chip_interface = BTC_INTF_USB;
+   wifionly_cfg->chip_interface = WIFIONLY_INTF_USB;
break;
default:
-   wifionly_cfg->chip_interface = BTC_INTF_UNKNOWN;
+   wifionly_cfg->chip_interface = WIFIONLY_INTF_UNKNOWN;
break;
}
 
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wilc1000: Remove unnecessary pointer check

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

[PATCH] staging: most: fix label names

[PATCH] memory_hotplug: Free pages as higher order

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

Re: [PATCH 04/13] staging: comedi: ni_routing: Add NI signal routing info

Re: [PATCH] staging: comedi: ni_mio_common: protect register write overflow

Re: [PATCH 00/13] device-global identifiers and routes introduced

Re: [PATCH 0/4] Add facility to directly query subdevice timing

Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array

Re: [PATCH v3] staging: android: ion: Add per-heap counters

Re: [PATCH] memory_hotplug: Free pages as higher order

[PATCH] staging: rtl8188eu: Remove unnecessary parentheses

[PATCH net-next,v2,0/3] hv_netvsc: Support LRO/RSC in the vSwitch

[PATCH net-next, v2, 2/3] hv_netvsc: Add handler for LRO setting change

[PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

[PATCH net-next, v2, 3/3] hv_netvsc: Update document for LRO/RSC support

Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

RE: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

[PATCH] Fix clang warning -Wpointer-bool-conversion by removing unnecessary check in regd.c

[PATCH] staging: vc04_services: Remove unused vchiq_genversion script

Re: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

RE: [PATCH net-next, v2, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch

[PATCH] staging: rtlwifi: Use proper enumerated types for Wi-Fi only interface

25 matches

Site Navigation

Mail list logo

Footer information