Re: [PATCH] staging: erofs: adds a space around '*'

2018-10-09 Thread DaeSeok Youn
2018년 10월 8일 (월) 오후 9:37, Gustavo A. R. Silva 님이 작성:
>
> Hi,
>
> On 10/8/18 1:45 PM, Daeseok Youn wrote:
> > fix checkpatch.pl error:
> > ERROR: need consistent spacing around '*' (ctx:WxV)
> > +   memcpy(vin + PAGE_SIZE *i, t, PAGE_SIZE);
> >
> > Signed-off-by: Daeseok Youn 
> > ---
> >  drivers/staging/erofs/unzip_vle_lz4.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/erofs/unzip_vle_lz4.c 
> > b/drivers/staging/erofs/unzip_vle_lz4.c
> > index f5b665f..501cfe0 100644
> > --- a/drivers/staging/erofs/unzip_vle_lz4.c
> > +++ b/drivers/staging/erofs/unzip_vle_lz4.c
> > @@ -181,7 +181,7 @@ int z_erofs_vle_unzip_vmap(struct page 
> > **compressed_pages,
> >   for (i = 0; i < clusterpages; ++i) {
> >   void *t = kmap_atomic(compressed_pages[i]);
> >
> > - memcpy(vin + PAGE_SIZE *i, t, PAGE_SIZE);
> > + memcpy(vin + PAGE_SIZE * i, t, PAGE_SIZE);
> >   kunmap_atomic(t);
> >   }
> >   } else if (clusterpages == 1)
> >
>
Hi Gustavo,

Thanks for letting me know the patch.
> This exact fix was applied to linux-next some days ago:
>
> commit ea0b2d429bd82ec152d286a0c026ebcaa4154ccc
yes, you're right.
>
> Make sure you are working from linux-next rather than from mainline.
I got the linux kernel source from the staging-next tree than
linux-next. I knew that the patches related to staging should be
merged into staging-tree first. But I didn't update the source tree to
get latest.
>
> See this link: https://www.kernel.org/doc/man-pages/linux-next.html
>
Thanks.
Regards,
Daeseok Youn.
> Thanks
> --
> Gustavo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

2018-10-09 Thread Quentin Schulz
Hi Frieder,

On Mon, Oct 08, 2018 at 11:53:21AM +0200, Frieder Schrempf wrote:
> Hi,
> 
> On 27.09.2018 10:14, Maxime Ripard wrote:
> > On Wed, Sep 26, 2018 at 10:19:22PM +0200, Hans de Goede wrote:
> > > On 26-09-18 16:44, Frieder Schrempf wrote:
> > > > Hi,
> > > > 
> > > > On Fri, Feb 09, 2018 at 03:01:00PM +0100, Ulf Hansson wrote:
> > > > > [...]
> > > > > 
> > > > > > > > I'd like to know if any progress has been made on that problem
> > > > (I may
> > > > > > > > have missed patches).
> > > > > > > > Had you had the time to look at the issue?
> > > > > > > 
> > > > > > > I have looked at the issue, but not manage to cook some patches
> > > > for it.
> > > > > > > 
> > > > > > > However, it's on my top of my TODO list for mmc. No promises, but
> > > > > > > perhaps and hopefully I manage to get something posted during the
> > > > > > > coming release cycle.
> > > > 
> > > > I would be interested in a ESP8089 driver in mainline and that's why I 
> > > > want to pick up this discussion.
> > > > 
> > > > What is the current status of the "mmc_reprobe_device" implementation, 
> > > > that Hans was explaining and Ulf wanted to provide some months ago?
> > > 
> > > Ulf did eventually write a new way to deal with this and then Quentin
> > > did manage to get the esp8089 driver to work with it, the new function
> > > to use for this is added by this commit:
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=1433269c4d2461be1f36db5dbb453976b38996ff
> > > 
> > > I'm not sure what the status of upstreaming the ep8089 driver is now
> > > that we've this in place.
> > > 
> > > Quentin, do you have a version of the esp8089 driver somewhere
> > > which will work correctly with the new mmc_sw_reset() function?
> > > 
> > > Also what is the status of adding this driver to say staging?
> > 
> > IIRC, we tried to get it into staging, and we got told that it was too
> > nice for staging at this point. So we're basically stuck somewhere
> > between staging and !staging, with the driver being too nice for the
> > former, and not nice enough for the latter :)
> 
> Ok, and is there someone willing to continue upstreaming the driver? Maybe
> someone can rebase and resend the latest approach?
> 
> After all it looks like a lot of work has already been done.
> 

There's clean up to do. It's time consuming but shouldn't be too hard to
do.

Then, we stressed the driver with an iperf test and it crashes very
often so we first need to identify if it happened with the "original"
driver before Icenowy's, Hans's and my clean-up. If it happened, since
we don't have a datasheet, it might be not that easy to fix. If it
didn't happen, then we have to find out where I cleaned up too much :D

I'm not currently working on this topic so anyone willing to take over
the work is free to do so.

Thanks,
Quentin


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


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-09 Thread Michal Hocko
On Fri 05-10-18 13:40:05, 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.

Acked-by: Michal Hocko 

Thanks for your patience with all the resubmission.
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 2/2] mm/page_alloc: remove software prefetching in __free_pages_core

2018-10-09 Thread Michal Hocko
On Fri 05-10-18 13:40:06, Arun KS wrote:
> They not only increase the code footprint, they actually make things
> slower rather than faster. Remove them as contemporary hardware doesn't
> need any hint.

I agree with the change but it is much better to add some numbers
whenever arguing about performance impact.

> 
> Suggested-by: Dan Williams 
> Signed-off-by: Arun KS 
> ---
>  mm/page_alloc.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7ab5274..90db431 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1258,14 +1258,10 @@ void __free_pages_core(struct page *page, unsigned 
> int order)
>   struct page *p = page;
>   unsigned int loop;
>  
> - prefetchw(p);
> - for (loop = 0; loop < (nr_pages - 1); loop++, p++) {
> - prefetchw(p + 1);
> + for (loop = 0; loop < nr_pages ; loop++, p++) {
>   __ClearPageReserved(p);
>   set_page_count(p, 0);
>   }
> - __ClearPageReserved(p);
> - set_page_count(p, 0);
>  
>   page_zone(page)->managed_pages += nr_pages;
>   set_page_refcounted(page);
> -- 
> 1.9.1
> 

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


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-09 Thread Arun KS

On 2018-10-09 14:59, Michal Hocko wrote:

On Fri 05-10-18 13:40:05, 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.


Acked-by: Michal Hocko 

Thanks for your patience with all the resubmission.


Hello Michal,

I got the below email few days back. Do I still need to resubmit the 
patch? or is it already on the way to merge?


Regards,
Arun

The patch titled
 Subject: mm/page_alloc.c: memory hotplug: free pages as higher 
order

has been added to the -mm tree.  Its filename is
 memory_hotplug-free-pages-as-higher-order.patch

This patch should soon appear at

http://ozlabs.org/~akpm/mmots/broken-out/memory_hotplug-free-pages-as-higher-order.patch

and later at

http://ozlabs.org/~akpm/mmotm/broken-out/memory_hotplug-free-pages-as-higher-order.patch


Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
  reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when 
testing your code ***


The -mm tree is included into linux-next and is updated
there every 3-4 working days

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


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-09 Thread Michal Hocko
On Tue 09-10-18 15:24:13, Arun KS wrote:
> On 2018-10-09 14:59, Michal Hocko wrote:
> > On Fri 05-10-18 13:40:05, 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.
> > 
> > Acked-by: Michal Hocko 
> > 
> > Thanks for your patience with all the resubmission.
> 
> Hello Michal,
> 
> I got the below email few days back. Do I still need to resubmit the patch?
> or is it already on the way to merge?

It is sitting in the queue for now. Andrew collects acks and
reviewed-bys and add them to the patch.
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: emxx_udc: Remove unused device_desc declaration

2018-10-09 Thread Greg KH
On Fri, Oct 05, 2018 at 02:05:45PM -0700, Nick Desaulniers wrote:
> On Wed, Oct 3, 2018 at 10:56 PM Nathan Chancellor
>  wrote:
> >
> > Clang warns:
> >
> > drivers/staging/emxx_udc/emxx_udc.c:1373:37: warning: variable
> > 'device_desc' is not needed and will not be emitted
> > [-Wunneeded-internal-declaration]
> > static struct usb_device_descriptor device_desc = {
> > ^
> > 1 warning generated.
> >
> > This definition hasn't been attached to anything since the driver was
> > introduced in commit 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile
> > USB Gadget driver") and neither GCC nor Clang emit any reference to the
> > variable in the final assembly. The only reason GCC doesn't warn about
> > this variable being unused is the sizeof function.
> >
> > Reported-by: Nick Desaulniers 
> > Signed-off-by: Nathan Chancellor 
> > ---
> >
> > This seems kind of wrong given this is a USB driver but there isn't an
> > instance of a platform_driver in the kernel tree having a usb device
> > descriptor declaration so I'm unsure of how to handle this warning aside
> > from just removing the definition but I'm certainly open to suggestions.
> 
> In drivers under drivers/usb/gadget/legacy/{ether|mass_storage|hid}.c,
> it seems that addresses of instances of `struct usb_device_descriptor`
> are stored in instances of `struct usb_composite_driver eth_driver`
> that are passed to module_usb_composite_driver().
> 
> drivers/staging/emxx_udc/emxx_udc.c doesn't mention anything about
> being a composite driver, and I don't know if there are multiple
> devices to warrant a composite driver?  Composite seems to imply "more
> than one gadget" while the path to drivers using this interface under
> drivers/usb/gadget/legacy/ seem to imply there's a modern (non-legacy)
> usb gadget interface that could potentially be used instead.
> 
> If this was never intended to be a composite usb driver, or there's
> some reason why it doesn't make sense for it to be one, then this code
> is likely dead and your fix is correct.  If it's not, maybe folks who
> know more about the USB interfaces have another solution to make this
> a composite usb driver?

I'll take the patch, the code looks wrong, it should not be needed here.

thanks,

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


Re: [PATCH] STAGING/EMXX_UDC: Fixed all meaningful sparse errors.

2018-10-09 Thread Greg KH
On Sat, Oct 06, 2018 at 03:13:39AM -0400, Carmeli Tamir wrote:
> Fixed all meaningful sparse errors: 
> 1. Added static to udc_controller 
> 2. Added mising __iomem modifier to handle p_regs 
> 3. Added missing le16_to_cpu
> 
> Signed-off-by: Tamir Carmeli 
> ---
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: gasket: Fix sparse "incorrect type in assignment" warnings.

2018-10-09 Thread Greg Kroah-Hartman
On Thu, Oct 04, 2018 at 06:52:25PM +0100, Laurence Rochfort wrote:
> Silence the below sparse warnings by casting betwen u8 __iomem *, and
> void *.
> 
> warning: incorrect type in assignment (different address spaces)
>expected unsigned char [noderef] [usertype] *virt_base
>got void *[assigned] mem
> warning: incorrect type in argument 3 (different address spaces)
>expected void *cpu_addr
>got unsigned char [noderef] [usertype] *virt_base
> 
> Signed-off-by: Laurence Rochfort 
> ---
>  drivers/staging/gasket/gasket_page_table.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/gasket/gasket_page_table.c 
> b/drivers/staging/gasket/gasket_page_table.c
> index d4c5f8a..7f5e5b3 100644
> --- a/drivers/staging/gasket/gasket_page_table.c
> +++ b/drivers/staging/gasket/gasket_page_table.c
> @@ -1278,7 +1278,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> *gasket_dev, u64 size,
>dma_addr_t *dma_address, u64 index)
>  {
>   dma_addr_t handle;
> - void *mem;
> + u8 __iomem *mem;
>   int j;
>   unsigned int num_pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
>   const struct gasket_driver_desc *driver_desc =
> @@ -1290,7 +1290,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> *gasket_dev, u64 size,
>   if (num_pages == 0)
>   return -EINVAL;
>  
> - mem = dma_alloc_coherent(gasket_get_device(gasket_dev),
> + mem = (u8 __iomem *)dma_alloc_coherent(gasket_get_device(gasket_dev),
>num_pages * PAGE_SIZE, &handle, 0);
>   if (!mem)
>   goto nomem;
> @@ -1325,7 +1325,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> *gasket_dev, u64 size,
>  nomem:
>   if (mem) {
>   dma_free_coherent(gasket_get_device(gasket_dev),
> -   num_pages * PAGE_SIZE, mem, handle);
> +   num_pages * PAGE_SIZE, (void __force *)mem, 
> handle);
>   }
>  
>   if (gasket_dev->page_table[index]->coherent_pages) {
> @@ -1353,7 +1353,7 @@ int gasket_free_coherent_memory(struct gasket_dev 
> *gasket_dev, u64 size,
>   if (gasket_dev->coherent_buffer.length_bytes) {
>   dma_free_coherent(gasket_get_device(gasket_dev),
> gasket_dev->coherent_buffer.length_bytes,
> -   gasket_dev->coherent_buffer.virt_base,
> +   (void __force 
> *)gasket_dev->coherent_buffer.virt_base,

We should not have to "force" anything here.  Something feels wrong in
the definition of these variable types...

thanks,

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


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

2018-10-09 Thread Greg KH
On Sun, Sep 30, 2018 at 06:24:52PM +0300, 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 
> Acked-by: Laura Abbott 
> ---
> 
> v3: 
>   Removed debugfs_create_dir() return value checking
> v4:
>   Added spinlock to protect heap statistics
> 
>  drivers/staging/android/ion/ion.c | 50 
> ---
>  drivers/staging/android/ion/ion.h | 10 +++-
>  2 files changed, 51 insertions(+), 9 deletions(-)

This patch fails to apply to my staging-next branch :(

Please fix up and resend.

thanks,

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


Re: [PATCH 02/11] staging:rtl8192u: Removed commented out include - Style

2018-10-09 Thread Greg KH
On Sun, Oct 07, 2018 at 10:40:16PM +0100, John Whitmore wrote:
> Remove commented out #include directive.
> 
> Additionally shorted a block comment to clear the checkpatch issue
> with line length.

You really should only do one type of thing per patch, but I'll let this
one go...

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


Re: [PATCH 06/11] staging:rtl8192u: Rewrite test for null - Style

2018-10-09 Thread Greg KH
On Sun, Oct 07, 2018 at 10:40:20PM +0100, John Whitmore wrote:
> Rewrite a test for NULL to comply with the coding style and clear the
> checkpatch issue.
> 
> This is a coding style change which should not impact runtime
> code execution.
> 
> Signed-off-by: John Whitmore 
> ---
>  drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This patch did not apply :(

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


[PATCH] staging: erofs: add the missing __init tags

2018-10-09 Thread Gao Xiang
Append __init to `erofs_init_inode_cache',
`z_erofs_init_zip_subsystem' and move these
declarations to internal.h.

Signed-off-by: Gao Xiang 
---
 drivers/staging/erofs/internal.h  |  6 ++
 drivers/staging/erofs/super.c | 13 +
 drivers/staging/erofs/unzip_vle.c |  2 +-
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index c2cc4a016d9e..5096b27bcf0d 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -284,6 +284,12 @@ static inline bool 
__should_decompress_synchronously(struct erofs_sb_info *sbi,
return nr <= sbi->max_sync_decompress_pages;
 }
 
+int __init z_erofs_init_zip_subsystem(void);
+void z_erofs_exit_zip_subsystem(void);
+#else
+/* dummy initializer/finalizer for the decompression subsystem */
+static inline int z_erofs_init_zip_subsystem(void) { return 0; }
+static inline void z_erofs_exit_zip_subsystem(void) {}
 #endif
 
 /* we strictly follow PAGE_SIZE and no buffer head yet */
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 51b076255988..f69e619807a1 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -29,7 +29,7 @@ static void init_once(void *ptr)
inode_init_once(&vi->vfs_inode);
 }
 
-static int erofs_init_inode_cache(void)
+static int __init erofs_init_inode_cache(void)
 {
erofs_inode_cachep = kmem_cache_create("erofs_inode",
sizeof(struct erofs_vnode), 0,
@@ -559,11 +559,6 @@ static struct file_system_type erofs_fs_type = {
 };
 MODULE_ALIAS_FS("erofs");
 
-#ifdef CONFIG_EROFS_FS_ZIP
-extern int z_erofs_init_zip_subsystem(void);
-extern void z_erofs_exit_zip_subsystem(void);
-#endif
-
 static int __init erofs_module_init(void)
 {
int err;
@@ -579,11 +574,9 @@ static int __init erofs_module_init(void)
if (err)
goto shrinker_err;
 
-#ifdef CONFIG_EROFS_FS_ZIP
err = z_erofs_init_zip_subsystem();
if (err)
goto zip_err;
-#endif
 
err = register_filesystem(&erofs_fs_type);
if (err)
@@ -593,10 +586,8 @@ static int __init erofs_module_init(void)
return 0;
 
 fs_err:
-#ifdef CONFIG_EROFS_FS_ZIP
z_erofs_exit_zip_subsystem();
 zip_err:
-#endif
unregister_shrinker(&erofs_shrinker_info);
 shrinker_err:
erofs_exit_inode_cache();
@@ -607,9 +598,7 @@ static int __init erofs_module_init(void)
 static void __exit erofs_module_exit(void)
 {
unregister_filesystem(&erofs_fs_type);
-#ifdef CONFIG_EROFS_FS_ZIP
z_erofs_exit_zip_subsystem();
-#endif
unregister_shrinker(&erofs_shrinker_info);
erofs_exit_inode_cache();
infoln("successfully finalize erofs");
diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index 337a82dafa1d..79d3ba62b298 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -42,7 +42,7 @@ static inline int init_unzip_workqueue(void)
return z_erofs_workqueue != NULL ? 0 : -ENOMEM;
 }
 
-int z_erofs_init_zip_subsystem(void)
+int __init z_erofs_init_zip_subsystem(void)
 {
z_erofs_workgroup_cachep =
kmem_cache_create("erofs_compress",
-- 
2.14.4

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


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

2018-10-09 Thread Greg Kroah-Hartman
On Wed, Oct 03, 2018 at 02:55:59PM -0600, Spencer E. Olson wrote:
> This patch set is the second revision of a recent patch set of the same name.

Thanks for sticking with this, all now applied.

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


[PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-09 Thread Gao Xiang
This patch introduces inode hash function, test and set callbacks,
and iget5_locked to find the right inode for 32-bit platforms.

Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
---

The patch has been previewed in the linux-erofs mailing list, submit to
the staging mailing list for linux-4.20.

Thanks,
Gao Xiang

 drivers/staging/erofs/inode.c| 37 -
 drivers/staging/erofs/internal.h |  9 +
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/erofs/inode.c b/drivers/staging/erofs/inode.c
index da8693a7c3d3..04c61a9d7b76 100644
--- a/drivers/staging/erofs/inode.c
+++ b/drivers/staging/erofs/inode.c
@@ -232,10 +232,45 @@ static int fill_inode(struct inode *inode, int isdir)
return err;
 }
 
+/*
+ * erofs nid is 64bits, but i_ino is 'unsigned long', therefore
+ * we should do more for 32-bit platform to find the right inode.
+ */
+#if BITS_PER_LONG == 32
+static int erofs_ilookup_test_actor(struct inode *inode, void *opaque)
+{
+   const erofs_nid_t nid = *(erofs_nid_t *)opaque;
+
+   return EROFS_V(inode)->nid == nid;
+}
+
+static int erofs_iget_set_actor(struct inode *inode, void *opaque)
+{
+   const erofs_nid_t nid = *(erofs_nid_t *)opaque;
+
+   inode->i_ino = erofs_inode_hash(nid);
+   return 0;
+}
+#endif
+
+static inline struct inode *erofs_iget_locked(struct super_block *sb,
+ erofs_nid_t nid)
+{
+   const unsigned long hashval = erofs_inode_hash(nid);
+
+#if BITS_PER_LONG >= 64
+   /* it is safe to use iget_locked for >= 64-bit platform */
+   return iget_locked(sb, hashval);
+#else
+   return iget5_locked(sb, hashval, erofs_ilookup_test_actor,
+   erofs_iget_set_actor, &nid);
+#endif
+}
+
 struct inode *erofs_iget(struct super_block *sb,
erofs_nid_t nid, bool isdir)
 {
-   struct inode *inode = iget_locked(sb, nid);
+   struct inode *inode = erofs_iget_locked(sb, nid);
 
if (unlikely(inode == NULL))
return ERR_PTR(-ENOMEM);
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 5096b27bcf0d..57575c7f5635 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -517,6 +517,15 @@ erofs_get_inline_page(struct inode *inode,
 }
 
 /* inode.c */
+static inline unsigned long erofs_inode_hash(erofs_nid_t nid)
+{
+#if BITS_PER_LONG == 32
+   return (nid >> 32) ^ (nid & 0x);
+#else
+   return nid;
+#endif
+}
+
 extern struct inode *erofs_iget(struct super_block *sb,
erofs_nid_t nid, bool dir);
 
-- 
2.14.4

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


Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

2018-10-09 Thread Frieder Schrempf

Hi Quentin,

On 09.10.2018 09:52, Quentin Schulz wrote:

Hi Frieder,

On Mon, Oct 08, 2018 at 11:53:21AM +0200, Frieder Schrempf wrote:

Hi,

On 27.09.2018 10:14, Maxime Ripard wrote:

On Wed, Sep 26, 2018 at 10:19:22PM +0200, Hans de Goede wrote:

On 26-09-18 16:44, Frieder Schrempf wrote:

Hi,

On Fri, Feb 09, 2018 at 03:01:00PM +0100, Ulf Hansson wrote:

[...]


I'd like to know if any progress has been made on that problem

(I may

have missed patches).
Had you had the time to look at the issue?


I have looked at the issue, but not manage to cook some patches

for it.


However, it's on my top of my TODO list for mmc. No promises, but
perhaps and hopefully I manage to get something posted during the
coming release cycle.


I would be interested in a ESP8089 driver in mainline and that's why I want to 
pick up this discussion.

What is the current status of the "mmc_reprobe_device" implementation, that 
Hans was explaining and Ulf wanted to provide some months ago?


Ulf did eventually write a new way to deal with this and then Quentin
did manage to get the esp8089 driver to work with it, the new function
to use for this is added by this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=1433269c4d2461be1f36db5dbb453976b38996ff

I'm not sure what the status of upstreaming the ep8089 driver is now
that we've this in place.

Quentin, do you have a version of the esp8089 driver somewhere
which will work correctly with the new mmc_sw_reset() function?

Also what is the status of adding this driver to say staging?


IIRC, we tried to get it into staging, and we got told that it was too
nice for staging at this point. So we're basically stuck somewhere
between staging and !staging, with the driver being too nice for the
former, and not nice enough for the latter :)


Ok, and is there someone willing to continue upstreaming the driver? Maybe
someone can rebase and resend the latest approach?

After all it looks like a lot of work has already been done.



There's clean up to do. It's time consuming but shouldn't be too hard to
do.

Then, we stressed the driver with an iperf test and it crashes very
often so we first need to identify if it happened with the "original"
driver before Icenowy's, Hans's and my clean-up. If it happened, since
we don't have a datasheet, it might be not that easy to fix. If it
didn't happen, then we have to find out where I cleaned up too much :D

I'm not currently working on this topic so anyone willing to take over
the work is free to do so.


Thanks a lot for providing the details. It is currently not clear on our 
side, if the project with the ESP8089 will happen, but if that's the 
case we might pick up the work.


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


Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-09 Thread Marcelo Tosatti
On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti  wrote:
> >
> > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti  
> > > wrote:
> > > >
> > > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > > > For better or for worse, I'm trying to understand this code.  So far,
> > > > > I've come up with this patch:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
> > > > >
> > > > > Is it correct, or am I missing some subtlety?
> > > >
> > > > The master clock, when initialized, has a pair
> > > >
> > > > masterclockvalues=(TSC value, time-of-day data).
> > > >
> > > > When updating the guest clock, we only update relative to (TSC value)
> > > > that was read on masterclock initialization.
> > >
> > > I don't see the problem.  The masterclock data is updated here:
> > >
> > > host_tsc_clocksource = kvm_get_time_and_clockread(
> > > &ka->master_kernel_ns,
> > > &ka->master_cycle_now);
> > >
> > > kvm_get_time_and_clockread() gets those values from
> > > do_monotonic_boot(), which, barring bugs, should cause
> > > get_kvmclock_ns() to return exactly the same thing as
> > > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
> > > roundabout manner.
> > >
> > > So what am I missing?  Is there actually something wrong with my patch?
> >
> > For the bug mentioned in the comment not to happen, you must only read
> > TSC and add it as offset to (TSC value, time-of-day data).
> >
> > Its more than "a roundabout manner".
> >
> > Read the comment again.
> >
> 
> I read the comment three more times and even dug through the git
> history.  It seems like what you're saying is that, under certain
> conditions (which arguably would be bugs in the core Linux timing
> code), 

I don't see that as a bug. Its just a side effect of reading two
different clocks (one is CLOCK_MONOTONIC and the other is TSC),
and using those two clocks to as a "base + offset".

As the comment explains, if you do that, can't guarantee monotonicity.

> actually calling ktime_get_boot_ns() could be non-monotonic
> with respect to the kvmclock timing.  But get_kvmclock_ns() isn't used
> for VM timing as such -- it's used for the IOCTL interfaces for
> updating the time offset.  So can you explain how my patch is
> incorrect?

ktime_get_boot_ns() has frequency correction applied, while 
reading masterclock + TSC offset does not.

So the clock reads differ.

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


[PATCH 3/4] staging: rtl8188eu: cleanup lines over 80 characters - style

2018-10-09 Thread Michael Straube
Clear 'line over 80 characters' checkpatch warnings by adding
appropriate line breaks and moving a comment.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c 
b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
index 8de0fc53103c..f5041e642bd2 100644
--- a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
@@ -14,7 +14,8 @@
 #include 
 #include 
 
-int rtw_os_xmit_resource_alloc(struct adapter *padapter, struct xmit_buf 
*pxmitbuf, u32 alloc_sz)
+int rtw_os_xmit_resource_alloc(struct adapter *padapter,
+  struct xmit_buf *pxmitbuf, u32 alloc_sz)
 {
int i;
 
@@ -89,7 +90,8 @@ void rtw_os_xmit_schedule(struct adapter *padapter)
spin_unlock_bh(&pxmitpriv->lock);
 }
 
-static void rtw_check_xmit_resource(struct adapter *padapter, struct sk_buff 
*pkt)
+static void rtw_check_xmit_resource(struct adapter *padapter,
+   struct sk_buff *pkt)
 {
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
u16 queue;
@@ -136,18 +138,24 @@ static int rtw_mlcst2unicst(struct adapter *padapter, 
struct sk_buff *skb)
memcpy(newskb->data, psta->hwaddr, 6);
res = rtw_xmit(padapter, &newskb);
if (res < 0) {
-   DBG_88E("%s()-%d: rtw_xmit() return error!\n", 
__func__, __LINE__);
+   DBG_88E("%s()-%d: rtw_xmit() return error!\n",
+   __func__, __LINE__);
pxmitpriv->tx_drop++;
dev_kfree_skb_any(newskb);
} else {
pxmitpriv->tx_pkts++;
}
} else {
-   DBG_88E("%s-%d: skb_copy() failed!\n", __func__, 
__LINE__);
+   DBG_88E("%s-%d: skb_copy() failed!\n",
+   __func__, __LINE__);
pxmitpriv->tx_drop++;
 
spin_unlock_bh(&pstapriv->asoc_list_lock);
-   return false;   /*  Caller shall tx this multicast 
frame via normal way. */
+
+   /* Caller shall tx this multicast frame
+* via normal way.
+*/
+   return false;
}
}
 
-- 
2.19.1

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


[PATCH 1/4] staging: rtl8188eu: use __func__ instead of hardcoded name - style

2018-10-09 Thread Michael Straube
Use __func__ instead of hardcoded function name in rtw_xmit_entry().
Reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c 
b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
index d8ef9b5d81a8..8e250f2bf39b 100644
--- a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
@@ -166,7 +166,8 @@ int rtw_xmit_entry(struct sk_buff *pkt, struct  net_device 
*pnetdev)
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("+xmit_enry\n"));
 
if (rtw_if_up(padapter) == false) {
-   RT_TRACE(_module_xmit_osdep_c_, _drv_err_, ("rtw_xmit_entry: 
rtw_if_up fail\n"));
+   RT_TRACE(_module_xmit_osdep_c_, _drv_err_,
+("%s: rtw_if_up fail\n", __func__));
goto drop_packet;
}
 
@@ -187,13 +188,15 @@ int rtw_xmit_entry(struct sk_buff *pkt, struct  
net_device *pnetdev)
goto drop_packet;
 
pxmitpriv->tx_pkts++;
-   RT_TRACE(_module_xmit_osdep_c_, _drv_info_, ("rtw_xmit_entry: 
tx_pkts=%d\n", (u32)pxmitpriv->tx_pkts));
+   RT_TRACE(_module_xmit_osdep_c_, _drv_info_,
+("%s: tx_pkts=%d\n", __func__, (u32)pxmitpriv->tx_pkts));
goto exit;
 
 drop_packet:
pxmitpriv->tx_drop++;
dev_kfree_skb_any(pkt);
-   RT_TRACE(_module_xmit_osdep_c_, _drv_notice_, ("rtw_xmit_entry: drop, 
tx_drop=%d\n", (u32)pxmitpriv->tx_drop));
+   RT_TRACE(_module_xmit_osdep_c_, _drv_notice_,
+("%s: drop, tx_drop=%d\n", __func__, (u32)pxmitpriv->tx_drop));
 
 exit:
return 0;
-- 
2.19.1

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


[PATCH 4/4] staging: rtl8188eu: remove whitespace - style

2018-10-09 Thread Michael Straube
Replace tabs with spaces and/or remove extra spaces where
appropriate.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c 
b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
index f5041e642bd2..d93be3ca2960 100644
--- a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
@@ -50,7 +50,7 @@ void rtw_os_xmit_resource_free(struct xmit_buf *pxmitbuf)
 
 void rtw_os_pkt_complete(struct adapter *padapter, struct sk_buff *pkt)
 {
-   u16 queue;
+   u16 queue;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
 
queue = skb_get_queue_mapping(pkt);
@@ -94,7 +94,7 @@ static void rtw_check_xmit_resource(struct adapter *padapter,
struct sk_buff *pkt)
 {
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
-   u16 queue;
+   u16 queue;
 
queue = skb_get_queue_mapping(pkt);
if (padapter->registrypriv.wifi_spec) {
@@ -111,12 +111,12 @@ static void rtw_check_xmit_resource(struct adapter 
*padapter,
 
 static int rtw_mlcst2unicst(struct adapter *padapter, struct sk_buff *skb)
 {
-   struct  sta_priv *pstapriv = &padapter->stapriv;
+   struct sta_priv *pstapriv = &padapter->stapriv;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
struct list_head *phead, *plist;
struct sk_buff *newskb;
struct sta_info *psta = NULL;
-   s32 res;
+   s32 res;
 
spin_lock_bh(&pstapriv->asoc_list_lock);
phead = &pstapriv->asoc_list;
@@ -128,7 +128,7 @@ static int rtw_mlcst2unicst(struct adapter *padapter, 
struct sk_buff *skb)
 
plist = plist->next;
 
-   /* avoid   come from STA1 and send back STA1 */
+   /* avoid come from STA1 and send back STA1 */
if (!memcmp(psta->hwaddr, &skb->data[6], 6))
continue;
 
@@ -164,11 +164,11 @@ static int rtw_mlcst2unicst(struct adapter *padapter, 
struct sk_buff *skb)
return true;
 }
 
-int rtw_xmit_entry(struct sk_buff *pkt, struct  net_device *pnetdev)
+int rtw_xmit_entry(struct sk_buff *pkt, struct net_device *pnetdev)
 {
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(pnetdev);
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
-   struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
+   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
s32 res = 0;
 
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("+xmit_enry\n"));
-- 
2.19.1

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


[PATCH 2/4] staging: rtl8188eu: add spaces around operators - style

2018-10-09 Thread Michael Straube
Add spaces around '*' and '/' to follow kernel coding style.
Reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c 
b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
index 8e250f2bf39b..8de0fc53103c 100644
--- a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
@@ -45,7 +45,7 @@ void rtw_os_xmit_resource_free(struct xmit_buf *pxmitbuf)
kfree(pxmitbuf->pallocated_buf);
 }
 
-#define WMM_XMIT_THRESHOLD (NR_XMITFRAME*2/5)
+#define WMM_XMIT_THRESHOLD (NR_XMITFRAME * 2 / 5)
 
 void rtw_os_pkt_complete(struct adapter *padapter, struct sk_buff *pkt)
 {
@@ -176,7 +176,7 @@ int rtw_xmit_entry(struct sk_buff *pkt, struct  net_device 
*pnetdev)
if (!rtw_mc2u_disable && check_fwstate(pmlmepriv, WIFI_AP_STATE) &&
(IP_MCAST_MAC(pkt->data) || ICMPV6_MCAST_MAC(pkt->data)) &&
(padapter->registrypriv.wifi_spec == 0)) {
-   if (pxmitpriv->free_xmitframe_cnt > (NR_XMITFRAME/4)) {
+   if (pxmitpriv->free_xmitframe_cnt > NR_XMITFRAME / 4) {
res = rtw_mlcst2unicst(padapter, pkt);
if (res)
goto exit;
-- 
2.19.1

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


[PATCH 0/4] staging: rtl8188eu: cleanup style issues in xmit_linux.c

2018-10-09 Thread Michael Straube
This series clears most of the remaining style/checkpatch issues
in the file os_dep/xmit_linux.c.

Michael Straube (4):
  staging: rtl8188eu: use __func__ instead of hardcoded name - style
  staging: rtl8188eu: add spaces around operators - style
  staging: rtl8188eu: cleanup lines over 80 characters - style
  staging: rtl8188eu: remove whitespace - style

 drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 45 ---
 1 file changed, 28 insertions(+), 17 deletions(-)

-- 
2.19.1

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


[RESEND PATCH] staging: mt7621-pci: dt-bindings: add dt bindings for mt7621 pcie controller

2018-10-09 Thread Sergio Paracuellos
This commit adds pci device tree bindings for the Mt7621 pci controller.
This is a temporal file included in staging driver directory and will be
moved to its correct location when this driver gets out of staging.

Cc: Rob Herring 
Signed-off-by: Sergio Paracuellos 
---
I resend this because I don't get any feedback in more than two weeks.
Rob, I was told by Greg that for getting this added into the staging tree
your Ack is needed to in order to get bindings correct from the beginning.

Thanks in advance for your time.

Best regards,
Sergio Paracuellos 

 drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt | 100 +
 1 file changed, 100 insertions(+)
 create mode 100644 drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt

diff --git a/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt 
b/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
new file mode 100644
index 000..4f3b082
--- /dev/null
+++ b/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
@@ -0,0 +1,100 @@
+MediaTek MT7621 PCIe controller
+
+Required properties:
+- compatible: "mediatek,mt7621-pci"
+- device_type: Must be "pci"
+- reg: Base addresses and lengths of the PCIe subsys and root ports.
+- bus-range: Range of bus numbers associated with this controller.
+- #address-cells: Address representation for root ports (must be 3)
+- pinctrl-names : The pin control state names.
+- pinctrl-0: The "default" pinctrl state.
+- #size-cells: Size representation for root ports (must be 2)
+- ranges: Ranges for the PCI memory and I/O regions.
+- #interrupt-cells: Must be 1
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties.
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- status: either "disabled" or "okay".
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must be "pcie0", "pcie1", "pcieN"... based on the number of
+  root ports.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must be "pcie0", "pcie1", "pcieN"... based on the number of
+  root ports.
+
+In addition, the device tree node must have sub-nodes describing each PCIe port
+interface, having the following mandatory properties:
+
+Required properties:
+- reg: Only the first four bytes are used to refer to the correct bus number
+  and device number.
+- #address-cells: Must be 3
+- #size-cells: Must be 2
+- ranges: Sub-ranges distributed from the PCIe controller node. An empty
+  property is sufficient.
+- bus-range: Range of bus numbers associated with this port.
+
+Example for MT7621:
+
+   pcie: pcie@1e14 {
+   compatible = "mediatek,mt7621-pci";
+reg = <0x1e14 0x100/* host-pci bridge registers */
+   0x1e142000 0x100/* pcie port 0 RC control registers */
+   0x1e143000 0x100/* pcie port 1 RC control registers */
+   0x1e144000 0x100/* pcie port 2 RC control registers */
+   0x1e00 0x100>;  /* sysctl */
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pcie_pins>;
+
+   device_type = "pci";
+
+   bus-range = <0 255>;
+   ranges = <
+   0x0200 0 0x 0x6000 0 0x1000 /* pci 
memory */
+   0x0100 0 0x 0x1e16 0 0x0001 /* io 
space */
+   >;
+
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0xF 0 0 1>;
+   interrupt-map = <0x1 0 0 1 &gic GIC_SHARED 4 
IRQ_TYPE_LEVEL_HIGH>,
+   <0x2 0 0 1 &gic GIC_SHARED 24 
IRQ_TYPE_LEVEL_HIGH>,
+   <0x3 0 0 1 &gic GIC_SHARED 25 
IRQ_TYPE_LEVEL_HIGH>;
+
+   status = "disabled";
+
+   resets = <&rstctrl 24 &rstctrl 25 &rstctrl 26>;
+   reset-names = "pcie0", "pcie1", "pcie2";
+   clocks = <&clkctrl 24 &clkctrl 25 &clkctrl 26>;
+   clock-names = "pcie0", "pcie1", "pcie2";
+
+   pcie@0,0 {
+   reg = <0x 0 0 0 0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges;
+   bus-range = <0x00 0xff>;
+   };
+
+   pcie@1,0 {
+   reg = <0x0800 0 0 0 0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges;
+   bus-range = <0x00 0xff>;
+   };
+
+   pcie@2,0 {
+   reg = <0x1000 0 0 0 0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges;
+   bus-range = <0x00 0xf

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

2018-10-09 Thread Alexey Skidanov
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
v4:
Added spinlock to protect heap statistics
v5:
Rebased on staging-next

 drivers/staging/android/ion/ion.c | 50 ---
 drivers/staging/android/ion/ion.h |  9 +++
 2 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 9907332..6fd8979 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -95,6 +95,13 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
goto err1;
}
 
+   spin_lock(&heap->stat_lock);
+   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;
+   spin_unlock(&heap->stat_lock);
+
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
mutex_lock(&dev->buffer_lock);
@@ -117,6 +124,11 @@ void ion_buffer_destroy(struct ion_buffer *buffer)
buffer->heap->ops->unmap_kernel(buffer->heap, buffer);
}
buffer->heap->ops->free(buffer);
+   spin_lock(&buffer->heap->stat_lock);
+   buffer->heap->num_of_buffers--;
+   buffer->heap->num_of_alloc_bytes -= buffer->size;
+   spin_unlock(&buffer->heap->stat_lock);
+
kfree(buffer);
 }
 
@@ -528,12 +540,15 @@ 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",
   __func__);
 
spin_lock_init(&heap->free_lock);
+   spin_lock_init(&heap->stat_lock);
heap->free_list_size = 0;
 
if (heap->flags & ION_HEAP_FLAG_DEFER_FREE)
@@ -546,6 +561,33 @@ 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;
+
+   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 +597,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 c006fc1..47b594c 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -157,6 +157,9 @@ struct ion_heap_ops {
  * @lock:  protects the free list
  * @waitqueue: queue to wait on from deferred free thread
  * @task:  task struct of deferred free thread
+ * @num_of_buffers the number of currently allocated buffers
+ * @num_of_alloc_bytes the number of allocated bytes
+ * @alloc_bytes_wm the number of allocated bytes watermark
  *
  * Represents a pool of memory from which buffers can be made.  In some
  * systems the only heap is regular system memory allocated via vmalloc.
@@ -177,6 +180,12 @@ struct ion_heap {
spinlock_t free_lock;
wait_queue_head_t waitqueue;
struct task_

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-09 Thread Andy Lutomirski
On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti  wrote:
>
> On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti  wrote:

> > I read the comment three more times and even dug through the git
> > history.  It seems like what you're saying is that, under certain
> > conditions (which arguably would be bugs in the core Linux timing
> > code),
>
> I don't see that as a bug. Its just a side effect of reading two
> different clocks (one is CLOCK_MONOTONIC and the other is TSC),
> and using those two clocks to as a "base + offset".
>
> As the comment explains, if you do that, can't guarantee monotonicity.
>
> > actually calling ktime_get_boot_ns() could be non-monotonic
> > with respect to the kvmclock timing.  But get_kvmclock_ns() isn't used
> > for VM timing as such -- it's used for the IOCTL interfaces for
> > updating the time offset.  So can you explain how my patch is
> > incorrect?
>
> ktime_get_boot_ns() has frequency correction applied, while
> reading masterclock + TSC offset does not.
>
> So the clock reads differ.
>

Ah, okay, I finally think I see what's going on.  In the kvmclock data
exposed to the guest, tsc_shift and tsc_to_system_mul come from
tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from
CLOCK_BOOTTIME.  So the kvmclock and kernel clock drift apart at a
rate given by the frequency shift and then suddenly agree again every
time the pvclock data is updated.

Is there a reason to do it this way?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel