Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

[Jason Yan]

On 2017/12/14 15:42, Greg KH wrote:

On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:

Some driviers may have the chance to increase a reference count that
has dropped to zero when using get_device() because of their design.

Then those drivers are broken :)


We have met such a issue with scsi:
https://www.spinics.net/lists/linux-scsi/msg115295.html

The scsi core will keep the scsi device object in the host list after
it has been deleted and the iterator can still find it. All of the
places where need iterating have to check the state of the scsi device
and this makes a lot of code redundancy and complexity.

Provide a safe mechanism in get_device() by using
kobject_get_unless_zero().

Suggested-by: Bart Van Assche 
Signed-off-by: Jason Yan 
CC: Greg Kroah-Hartman 
CC: Bart Van Assche 
CC: Ewan D. Milne 
CC: James E.J. Bottomley 
CC: Christoph Hellwig 
---
  drivers/base/core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 12ebd05..cc74810 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
   */
  struct device *get_device(struct device *dev)
  {
-   return dev ? kobj_to_dev(kobject_get(>kobj)) : NULL;
+   return dev && kobject_get_unless_zero(>kobj) ? dev : NULL;

I really don't want to do this, the bus the device is on should prevent
this from happening.

Also, once that reference count drops to zero, the memory should be
freed, so you really have a stale pointer here, and this code would fail
if you had slab debugging enabled anyway.


Actually I don't want this either. But the design of scsi core will 
leave the scsi device on the
host list after it is deleted, and it can  be found later and the 
refcount have a very big chance
to increase from zero again. And after a lot of discussion it seems that 
the scsi layer is difficult

to change the situation in the near future.


So I don't even think this fixes the issue you think it fixes :)


This issue is very easy to reproduce on my machine and I have tested the 
patch and it really

fixes the issue.


thanks,

greg k-h

.

Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

[Jason Yan]

On 2017/12/14 15:42, Greg KH wrote:

On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:

Some driviers may have the chance to increase a reference count that
has dropped to zero when using get_device() because of their design.

Then those drivers are broken :)


We have met such a issue with scsi:
https://www.spinics.net/lists/linux-scsi/msg115295.html

The scsi core will keep the scsi device object in the host list after
it has been deleted and the iterator can still find it. All of the
places where need iterating have to check the state of the scsi device
and this makes a lot of code redundancy and complexity.

Provide a safe mechanism in get_device() by using
kobject_get_unless_zero().

Suggested-by: Bart Van Assche 
Signed-off-by: Jason Yan 
CC: Greg Kroah-Hartman 
CC: Bart Van Assche 
CC: Ewan D. Milne 
CC: James E.J. Bottomley 
CC: Christoph Hellwig 
---
  drivers/base/core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 12ebd05..cc74810 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
   */
  struct device *get_device(struct device *dev)
  {
-   return dev ? kobj_to_dev(kobject_get(>kobj)) : NULL;
+   return dev && kobject_get_unless_zero(>kobj) ? dev : NULL;

I really don't want to do this, the bus the device is on should prevent
this from happening.

Also, once that reference count drops to zero, the memory should be
freed, so you really have a stale pointer here, and this code would fail
if you had slab debugging enabled anyway.


Actually I don't want this either. But the design of scsi core will 
leave the scsi device on the
host list after it is deleted, and it can  be found later and the 
refcount have a very big chance
to increase from zero again. And after a lot of discussion it seems that 
the scsi layer is difficult

to change the situation in the near future.


So I don't even think this fixes the issue you think it fixes :)


This issue is very easy to reproduce on my machine and I have tested the 
patch and it really

fixes the issue.


thanks,

greg k-h

.

Re: [PATCH 4.14 000/164] 4.14.6-stable review

[Greg Kroah-Hartman]

On Tue, Dec 12, 2017 at 06:47:33PM -0800, Guenter Roeck wrote:
> On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.6 release.
> > There are 164 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Dec 14 12:34:08 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 124 pass: 124 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing these and letting me know.

greg k-h

Re: [PATCH 4.14 000/164] 4.14.6-stable review

[Greg Kroah-Hartman]

On Tue, Dec 12, 2017 at 06:47:33PM -0800, Guenter Roeck wrote:
> On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.6 release.
> > There are 164 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Dec 14 12:34:08 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 124 pass: 124 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing these and letting me know.

greg k-h

Re: [PATCH 4.9 000/148] 4.9.69-stable review

[Greg Kroah-Hartman]

On Tue, Dec 12, 2017 at 05:30:42PM -0700, Nathan Chancellor wrote:
> On Tue, Dec 12, 2017 at 04:22:36PM -0800, Guenter Roeck wrote:
> > On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.9.69 release.
> > > There are 148 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Thu Dec 14 12:43:58 UTC 2017.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > total: 145 pass: 140 fail: 5
> > Failed builds:
> > powerpc:defconfig
> > powerpc:allmodconfig
> > powerpc:ppc64e_defconfig
> > powerpc:cell_defconfig
> > powerpc:maple_defconfig
> > Qemu test results:
> > total: 124 pass: 119 fail: 5
> > Failed tests:
> > powerpc:mac99:ppc64_book3s_defconfig:nosmp
> > powerpc:mac99:ppc64_book3s_defconfig:smp4
> > powerpc:pseries:pseries_defconfig
> > powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
> > powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
> > 
> > Failures:
> > 
> > arch/powerpc/include/asm/checksum.h:103:2: error: implicit declaration of 
> > function 'from64to32'
> > 
> > Details are available at http://kerneltests.org/builders.
> > 
> > Guenter
> 
> Commit 7a06adf7b37f ("powerpc/64: Fix checksum folding in csum_add()") in
> the stable-rc tree needs commit b492f7e4e07a ("powerpc/64: Fix checksum
> folding in csum_tcpudp_nofold and ip_fast_csum_nofold") from upstream as a
> prerequisite. It applies cleanly on 4.9.68 (can't say if it is appropriate
> or not).

I've taken this patch now, thanks.

greg k-h

Re: [PATCH 4.9 000/148] 4.9.69-stable review

[Greg Kroah-Hartman]

On Tue, Dec 12, 2017 at 05:30:42PM -0700, Nathan Chancellor wrote:
> On Tue, Dec 12, 2017 at 04:22:36PM -0800, Guenter Roeck wrote:
> > On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.9.69 release.
> > > There are 148 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Thu Dec 14 12:43:58 UTC 2017.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > total: 145 pass: 140 fail: 5
> > Failed builds:
> > powerpc:defconfig
> > powerpc:allmodconfig
> > powerpc:ppc64e_defconfig
> > powerpc:cell_defconfig
> > powerpc:maple_defconfig
> > Qemu test results:
> > total: 124 pass: 119 fail: 5
> > Failed tests:
> > powerpc:mac99:ppc64_book3s_defconfig:nosmp
> > powerpc:mac99:ppc64_book3s_defconfig:smp4
> > powerpc:pseries:pseries_defconfig
> > powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
> > powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
> > 
> > Failures:
> > 
> > arch/powerpc/include/asm/checksum.h:103:2: error: implicit declaration of 
> > function 'from64to32'
> > 
> > Details are available at http://kerneltests.org/builders.
> > 
> > Guenter
> 
> Commit 7a06adf7b37f ("powerpc/64: Fix checksum folding in csum_add()") in
> the stable-rc tree needs commit b492f7e4e07a ("powerpc/64: Fix checksum
> folding in csum_tcpudp_nofold and ip_fast_csum_nofold") from upstream as a
> prerequisite. It applies cleanly on 4.9.68 (can't say if it is appropriate
> or not).

I've taken this patch now, thanks.

greg k-h

Re: [PATCH 4.9 000/148] 4.9.69-stable review

[Greg Kroah-Hartman]

On Wed, Dec 13, 2017 at 05:28:44PM +0530, Naresh Kamboju wrote:
> On 12 December 2017 at 18:13, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.9.69 release.
> > There are 148 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Dec 14 12:43:58 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.69-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
> 
> Note:
> Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64 and
> the independent test execution resulted as PASS.
> For the internal investigation bug reported.
> https://bugs.linaro.org/show_bug.cgi?id=3502#c4

Thanks for testing and letting me know.

greg k-h

Re: [PATCH 4.9 000/148] 4.9.69-stable review

[Greg Kroah-Hartman]

On Wed, Dec 13, 2017 at 05:28:44PM +0530, Naresh Kamboju wrote:
> On 12 December 2017 at 18:13, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.9.69 release.
> > There are 148 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Dec 14 12:43:58 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.69-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
> 
> Note:
> Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64 and
> the independent test execution resulted as PASS.
> For the internal investigation bug reported.
> https://bugs.linaro.org/show_bug.cgi?id=3502#c4

Thanks for testing and letting me know.

greg k-h

Re: [PATCH] hyperv: make HYPERV a menuconfig to ease disabling it all

[Greg KH]

On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Dec 2017 09:54:19 +0100
> Vincent Legoll  wrote:
> 
> > Hello,
> > 
> > On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
> >  wrote:
> > > Will this break existing configs?  
> > 
> > I don't think so. Last time I did some similar changes, the kbuild
> > test robot found some warnings on some configurations, I hope
> > it will find problems (if any) for that series too (this one is not alone,
> > I've got a bunch of other similar patches in-flight)
> > 
> > Thanks
> 
> NAK
> 
> Let me give a concrete example of how this will break users.
> 
> 1. Assume user has a working .config file in their kernel build directory
> which builds a kernel that works on Hyper-V.
> 
> 2. Add your patch (or assume it makes into a later version).
> 
> 3. User then does
> 
> $ make oldconfig
> scripts/kconfig/conf  --oldconfig Kconfig
> *
> * Restart config...
> *
> *
> * Microsoft Hyper-V guest support
> *
> Microsoft Hyper-V guest support (HYPERV_MENU) [N/y] (NEW) 
> 
> If they hit return, the default value is not enabling HyperV and they
> will then go on to build a kernel that will not boot on your system.
> 
> The default MUST be set to Yes.

Or you can just not take these types of odd and silly changes to the
Kconfig files, and leave it as-is.  I have yet to see the good reason
why these are needed at all.

thanks,

greg k-h

Re: [PATCH] hyperv: make HYPERV a menuconfig to ease disabling it all

[Greg KH]

On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Dec 2017 09:54:19 +0100
> Vincent Legoll  wrote:
> 
> > Hello,
> > 
> > On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger
> >  wrote:
> > > Will this break existing configs?  
> > 
> > I don't think so. Last time I did some similar changes, the kbuild
> > test robot found some warnings on some configurations, I hope
> > it will find problems (if any) for that series too (this one is not alone,
> > I've got a bunch of other similar patches in-flight)
> > 
> > Thanks
> 
> NAK
> 
> Let me give a concrete example of how this will break users.
> 
> 1. Assume user has a working .config file in their kernel build directory
> which builds a kernel that works on Hyper-V.
> 
> 2. Add your patch (or assume it makes into a later version).
> 
> 3. User then does
> 
> $ make oldconfig
> scripts/kconfig/conf  --oldconfig Kconfig
> *
> * Restart config...
> *
> *
> * Microsoft Hyper-V guest support
> *
> Microsoft Hyper-V guest support (HYPERV_MENU) [N/y] (NEW) 
> 
> If they hit return, the default value is not enabling HyperV and they
> will then go on to build a kernel that will not boot on your system.
> 
> The default MUST be set to Yes.

Or you can just not take these types of odd and silly changes to the
Kconfig files, and leave it as-is.  I have yet to see the good reason
why these are needed at all.

thanks,

greg k-h

Re: [RFC PATCH 4/5] mm, hugetlb: get rid of surplus page accounting tricks

[Michal Hocko]

On Wed 13-12-17 16:45:55, Mike Kravetz wrote:
> On 12/04/2017 06:01 AM, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > alloc_surplus_huge_page increases the pool size and the number of
> > surplus pages opportunistically to prevent from races with the pool size
> > change. See d1c3fb1f8f29 ("hugetlb: introduce nr_overcommit_hugepages
> > sysctl") for more details.
> > 
> > The resulting code is unnecessarily hairy, cause code duplication and
> > doesn't allow to share the allocation paths. Moreover pool size changes
> > tend to be very seldom so optimizing for them is not really reasonable.
> > Simplify the code and allow to allocate a fresh surplus page as long as
> > we are under the overcommit limit and then recheck the condition after
> > the allocation and drop the new page if the situation has changed. This
> > should provide a reasonable guarantee that an abrupt allocation requests
> > will not go way off the limit.
> > 
> > If we consider races with the pool shrinking and enlarging then we
> > should be reasonably safe as well. In the first case we are off by one
> > in the worst case and the second case should work OK because the page is
> > not yet visible. We can waste CPU cycles for the allocation but that
> > should be acceptable for a relatively rare condition.
> > 
> > Signed-off-by: Michal Hocko 
> > ---
> >  mm/hugetlb.c | 60 
> > +---
> >  1 file changed, 21 insertions(+), 39 deletions(-)
> > 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index a1b8b2888ec9..0c7dc269b6c0 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1538,62 +1538,44 @@ int dissolve_free_huge_pages(unsigned long 
> > start_pfn, unsigned long end_pfn)
> >  static struct page *__alloc_surplus_huge_page(struct hstate *h, gfp_t 
> > gfp_mask,
> > int nid, nodemask_t *nmask)
> >  {
> > -   struct page *page;
> > -   unsigned int r_nid;
> > +   struct page *page = NULL;
> >  
> > if (hstate_is_gigantic(h))
> > return NULL;
> >  
> > -   /*
> > -* Assume we will successfully allocate the surplus page to
> > -* prevent racing processes from causing the surplus to exceed
> > -* overcommit
> > -*
> > -* This however introduces a different race, where a process B
> > -* tries to grow the static hugepage pool while alloc_pages() is
> > -* called by process A. B will only examine the per-node
> > -* counters in determining if surplus huge pages can be
> > -* converted to normal huge pages in adjust_pool_surplus(). A
> > -* won't be able to increment the per-node counter, until the
> > -* lock is dropped by B, but B doesn't drop hugetlb_lock until
> > -* no more huge pages can be converted from surplus to normal
> > -* state (and doesn't try to convert again). Thus, we have a
> > -* case where a surplus huge page exists, the pool is grown, and
> > -* the surplus huge page still exists after, even though it
> > -* should just have been converted to a normal huge page. This
> > -* does not leak memory, though, as the hugepage will be freed
> > -* once it is out of use. It also does not allow the counters to
> > -* go out of whack in adjust_pool_surplus() as we don't modify
> > -* the node values until we've gotten the hugepage and only the
> > -* per-node value is checked there.
> > -*/
> > spin_lock(_lock);
> > -   if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> > -   spin_unlock(_lock);
> > -   return NULL;
> > -   } else {
> > -   h->nr_huge_pages++;
> > -   h->surplus_huge_pages++;
> > -   }
> > +   if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages)
> > +   goto out_unlock;
> > spin_unlock(_lock);
> >  
> > page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask, nid, nmask);
> > +   if (!page)
> > +   goto out_unlock;
> >  
> > spin_lock(_lock);
> > -   if (page) {
> > +   /*
> > +* We could have raced with the pool size change.
> > +* Double check that and simply deallocate the new page
> > +* if we would end up overcommiting the surpluses. Abuse
> > +* temporary page to workaround the nasty free_huge_page
> > +* codeflow
> > +*/
> > +   if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> > +   SetPageHugeTemporary(page);
> > +   put_page(page);
> > +   page = NULL;
> > +   } else {
> > +   h->surplus_huge_pages_node[page_to_nid(page)]++;
> > +   h->surplus_huge_pages++;
> > INIT_LIST_HEAD(>lru);
> > r_nid = page_to_nid(page);
> > set_compound_page_dtor(page, HUGETLB_PAGE_DTOR);
> > set_hugetlb_cgroup(page, NULL);
> > -   /*
> > -* We incremented the global counters already
> > -*/
> > h->nr_huge_pages_node[r_nid]++;
> > 

Re: [RFC PATCH 4/5] mm, hugetlb: get rid of surplus page accounting tricks

[Michal Hocko]

On Wed 13-12-17 16:45:55, Mike Kravetz wrote:
> On 12/04/2017 06:01 AM, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > alloc_surplus_huge_page increases the pool size and the number of
> > surplus pages opportunistically to prevent from races with the pool size
> > change. See d1c3fb1f8f29 ("hugetlb: introduce nr_overcommit_hugepages
> > sysctl") for more details.
> > 
> > The resulting code is unnecessarily hairy, cause code duplication and
> > doesn't allow to share the allocation paths. Moreover pool size changes
> > tend to be very seldom so optimizing for them is not really reasonable.
> > Simplify the code and allow to allocate a fresh surplus page as long as
> > we are under the overcommit limit and then recheck the condition after
> > the allocation and drop the new page if the situation has changed. This
> > should provide a reasonable guarantee that an abrupt allocation requests
> > will not go way off the limit.
> > 
> > If we consider races with the pool shrinking and enlarging then we
> > should be reasonably safe as well. In the first case we are off by one
> > in the worst case and the second case should work OK because the page is
> > not yet visible. We can waste CPU cycles for the allocation but that
> > should be acceptable for a relatively rare condition.
> > 
> > Signed-off-by: Michal Hocko 
> > ---
> >  mm/hugetlb.c | 60 
> > +---
> >  1 file changed, 21 insertions(+), 39 deletions(-)
> > 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index a1b8b2888ec9..0c7dc269b6c0 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1538,62 +1538,44 @@ int dissolve_free_huge_pages(unsigned long 
> > start_pfn, unsigned long end_pfn)
> >  static struct page *__alloc_surplus_huge_page(struct hstate *h, gfp_t 
> > gfp_mask,
> > int nid, nodemask_t *nmask)
> >  {
> > -   struct page *page;
> > -   unsigned int r_nid;
> > +   struct page *page = NULL;
> >  
> > if (hstate_is_gigantic(h))
> > return NULL;
> >  
> > -   /*
> > -* Assume we will successfully allocate the surplus page to
> > -* prevent racing processes from causing the surplus to exceed
> > -* overcommit
> > -*
> > -* This however introduces a different race, where a process B
> > -* tries to grow the static hugepage pool while alloc_pages() is
> > -* called by process A. B will only examine the per-node
> > -* counters in determining if surplus huge pages can be
> > -* converted to normal huge pages in adjust_pool_surplus(). A
> > -* won't be able to increment the per-node counter, until the
> > -* lock is dropped by B, but B doesn't drop hugetlb_lock until
> > -* no more huge pages can be converted from surplus to normal
> > -* state (and doesn't try to convert again). Thus, we have a
> > -* case where a surplus huge page exists, the pool is grown, and
> > -* the surplus huge page still exists after, even though it
> > -* should just have been converted to a normal huge page. This
> > -* does not leak memory, though, as the hugepage will be freed
> > -* once it is out of use. It also does not allow the counters to
> > -* go out of whack in adjust_pool_surplus() as we don't modify
> > -* the node values until we've gotten the hugepage and only the
> > -* per-node value is checked there.
> > -*/
> > spin_lock(_lock);
> > -   if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> > -   spin_unlock(_lock);
> > -   return NULL;
> > -   } else {
> > -   h->nr_huge_pages++;
> > -   h->surplus_huge_pages++;
> > -   }
> > +   if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages)
> > +   goto out_unlock;
> > spin_unlock(_lock);
> >  
> > page = __hugetlb_alloc_buddy_huge_page(h, gfp_mask, nid, nmask);
> > +   if (!page)
> > +   goto out_unlock;
> >  
> > spin_lock(_lock);
> > -   if (page) {
> > +   /*
> > +* We could have raced with the pool size change.
> > +* Double check that and simply deallocate the new page
> > +* if we would end up overcommiting the surpluses. Abuse
> > +* temporary page to workaround the nasty free_huge_page
> > +* codeflow
> > +*/
> > +   if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> > +   SetPageHugeTemporary(page);
> > +   put_page(page);
> > +   page = NULL;
> > +   } else {
> > +   h->surplus_huge_pages_node[page_to_nid(page)]++;
> > +   h->surplus_huge_pages++;
> > INIT_LIST_HEAD(>lru);
> > r_nid = page_to_nid(page);
> > set_compound_page_dtor(page, HUGETLB_PAGE_DTOR);
> > set_hugetlb_cgroup(page, NULL);
> > -   /*
> > -* We incremented the global counters already
> > -*/
> > h->nr_huge_pages_node[r_nid]++;
> > h->surplus_huge_pages_node[r_nid]++;
> > -   } else {
> > -

[PATCH v8 2/2] mtd: nand: Add support for Arasan NAND Flash Controller

[Naga Sureshkumar Relli]

Added the basic driver for Arasan NAND Flash Controller used in
Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit
correction.

Signed-off-by: Naga Sureshkumar Relli 
Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v8:
 - Implemented setup_data_interface hook
 - fixed checkpatch --strict warnings
 - Added anfc_config_ecc in read_page_hwecc
 - Fixed returning status value by reading flash status in read_byte()
   instead of reading previous value.
Changes in v7:
- Implemented Marek suggestions and comments
- Corrected the acronyms those should be in caps
- Modified kconfig/Make file to keep arasan entry in sorted order
- Added is_vmlloc_addr check
- Used ioread/write32_rep variants to avoid compilation error for intel
  platforms
- separated PIO and DMA mode read/write functions
- Minor cleanup
Chnages in v6:
- Addressed most of the Brian and Boris comments
- Separated the nandchip from the nand controller
- Removed the ecc lookup table from driver
- Now use framework nand waitfunction and readoob
- Fixed the compiler warning
- Adapted the new frameowrk changes related to ecc and ooblayout
- Disabled the clocks after the nand_reelase
- Now using only one completion object
- Boris suggessions like adapting cmd_ctrl and rework on read/write byte
  are not implemented and i will patch them later
- Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will
  implement later once the basic driver is mainlined.
Changes in v5:
- Renamed the driver filei as arasan_nand.c
- Fixed all comments relaqted coding style
- Fixed comments related to propagating the errors
- Modified the anfc_write_page_hwecc as per the write_page
  prototype
Changes in v4:
- Added support for onfi timing mode configuration
- Added clock suort
- Added support for multiple chipselects
Changes in v3:
- Removed unused variables
- Avoided busy loop and used jifies based implementation
- Fixed compiler warnings "right shift count >= width of type"
- Removed unneeded codei and improved error reporting
- Added onfi version check to ensure reading the valid address cycles
Changes in v2:
- Added missing of.h to avoid kbuild system report erro
---
 drivers/mtd/nand/Kconfig   |8 +
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/arasan_nand.c | 1020 
 3 files changed, 1029 insertions(+)
 create mode 100644 drivers/mtd/nand/arasan_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3f2036f31da4..bdc97510f758 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -40,6 +40,14 @@ config MTD_SM_COMMON
tristate
default n
 
+config MTD_NAND_ARASAN
+   tristate "Support for Arasan Nand Flash controller"
+   depends on HAS_IOMEM
+   depends on HAS_DMA
+   help
+ Enables the driver for the Arasan NAND Flash controller on
+ Zynq UltraScale+ MPSoC.
+
 config MTD_NAND_DENALI
tristate
 
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 6e2db700d923..b96965a95daf 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MTD_NAND_ECC)  += nand_ecc.o
 obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o
 obj-$(CONFIG_MTD_SM_COMMON)+= sm_common.o
 
+obj-$(CONFIG_MTD_NAND_ARASAN)  += arasan_nand.o
 obj-$(CONFIG_MTD_NAND_CAFE)+= cafe_nand.o
 obj-$(CONFIG_MTD_NAND_AMS_DELTA)   += ams-delta.o
 obj-$(CONFIG_MTD_NAND_DENALI)  += denali.o
diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c
new file mode 100644
index ..a9ed1dbb09de
--- /dev/null
+++ b/drivers/mtd/nand/arasan_nand.c
@@ -0,0 +1,1020 @@
+/*
+ * Arasan NAND Flash Controller Driver
+ *
+ * Copyright (C) 2014 - 2017 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"arasan_nand"
+#define EVNT_TIMEOUT_MSEC  1000
+
+#define PKT_OFST   0x00
+#define MEM_ADDR1_OFST 0x04
+#define MEM_ADDR2_OFST 0x08
+#define CMD_OFST   0x0C
+#define PROG_OFST  0x10
+#define INTR_STS_EN_OFST   0x14
+#define INTR_SIG_EN_OFST   0x18
+#define INTR_STS_OFST  0x1C
+#define READY_STS_OFST 0x20
+#define DMA_ADDR1_OFST 0x24
+#define FLASH_STS_OFST 0x28
+#define DATA_PORT_OFST 0x30
+#define ECC_OFST   0x34
+#define ECC_ERR_CNT_OFST  

[PATCH v8 2/2] mtd: nand: Add support for Arasan NAND Flash Controller

[Naga Sureshkumar Relli]

Added the basic driver for Arasan NAND Flash Controller used in
Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit
correction.

Signed-off-by: Naga Sureshkumar Relli 
Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v8:
 - Implemented setup_data_interface hook
 - fixed checkpatch --strict warnings
 - Added anfc_config_ecc in read_page_hwecc
 - Fixed returning status value by reading flash status in read_byte()
   instead of reading previous value.
Changes in v7:
- Implemented Marek suggestions and comments
- Corrected the acronyms those should be in caps
- Modified kconfig/Make file to keep arasan entry in sorted order
- Added is_vmlloc_addr check
- Used ioread/write32_rep variants to avoid compilation error for intel
  platforms
- separated PIO and DMA mode read/write functions
- Minor cleanup
Chnages in v6:
- Addressed most of the Brian and Boris comments
- Separated the nandchip from the nand controller
- Removed the ecc lookup table from driver
- Now use framework nand waitfunction and readoob
- Fixed the compiler warning
- Adapted the new frameowrk changes related to ecc and ooblayout
- Disabled the clocks after the nand_reelase
- Now using only one completion object
- Boris suggessions like adapting cmd_ctrl and rework on read/write byte
  are not implemented and i will patch them later
- Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will
  implement later once the basic driver is mainlined.
Changes in v5:
- Renamed the driver filei as arasan_nand.c
- Fixed all comments relaqted coding style
- Fixed comments related to propagating the errors
- Modified the anfc_write_page_hwecc as per the write_page
  prototype
Changes in v4:
- Added support for onfi timing mode configuration
- Added clock suort
- Added support for multiple chipselects
Changes in v3:
- Removed unused variables
- Avoided busy loop and used jifies based implementation
- Fixed compiler warnings "right shift count >= width of type"
- Removed unneeded codei and improved error reporting
- Added onfi version check to ensure reading the valid address cycles
Changes in v2:
- Added missing of.h to avoid kbuild system report erro
---
 drivers/mtd/nand/Kconfig   |8 +
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/arasan_nand.c | 1020 
 3 files changed, 1029 insertions(+)
 create mode 100644 drivers/mtd/nand/arasan_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3f2036f31da4..bdc97510f758 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -40,6 +40,14 @@ config MTD_SM_COMMON
tristate
default n
 
+config MTD_NAND_ARASAN
+   tristate "Support for Arasan Nand Flash controller"
+   depends on HAS_IOMEM
+   depends on HAS_DMA
+   help
+ Enables the driver for the Arasan NAND Flash controller on
+ Zynq UltraScale+ MPSoC.
+
 config MTD_NAND_DENALI
tristate
 
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 6e2db700d923..b96965a95daf 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MTD_NAND_ECC)  += nand_ecc.o
 obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o
 obj-$(CONFIG_MTD_SM_COMMON)+= sm_common.o
 
+obj-$(CONFIG_MTD_NAND_ARASAN)  += arasan_nand.o
 obj-$(CONFIG_MTD_NAND_CAFE)+= cafe_nand.o
 obj-$(CONFIG_MTD_NAND_AMS_DELTA)   += ams-delta.o
 obj-$(CONFIG_MTD_NAND_DENALI)  += denali.o
diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c
new file mode 100644
index ..a9ed1dbb09de
--- /dev/null
+++ b/drivers/mtd/nand/arasan_nand.c
@@ -0,0 +1,1020 @@
+/*
+ * Arasan NAND Flash Controller Driver
+ *
+ * Copyright (C) 2014 - 2017 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"arasan_nand"
+#define EVNT_TIMEOUT_MSEC  1000
+
+#define PKT_OFST   0x00
+#define MEM_ADDR1_OFST 0x04
+#define MEM_ADDR2_OFST 0x08
+#define CMD_OFST   0x0C
+#define PROG_OFST  0x10
+#define INTR_STS_EN_OFST   0x14
+#define INTR_SIG_EN_OFST   0x18
+#define INTR_STS_OFST  0x1C
+#define READY_STS_OFST 0x20
+#define DMA_ADDR1_OFST 0x24
+#define FLASH_STS_OFST 0x28
+#define DATA_PORT_OFST 0x30
+#define ECC_OFST   0x34
+#define ECC_ERR_CNT_OFST   0x38
+#define ECC_SPR_CMD_OFST  

[PATCH v8 0/2] Add support for Arasan NAND Flash controller

[Naga Sureshkumar Relli]

This patch series adds the basic driver support for Arasan NAND Flash
controller.
We are reinitiating the patch series by fixing the comments given by
Boris and Rob.

Previous Patch reference:
https://lkml.org/lkml/2017/1/8/245

Naga Sureshkumar Relli (2):
  mtd: arasan: Add device tree binding documentation
  mtd: nand: Add support for Arasan NAND Flash Controller

 .../devicetree/bindings/mtd/arasan_nand.txt|   38 +
 drivers/mtd/nand/Kconfig   |8 +
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/arasan_nand.c | 1020 
 4 files changed, 1067 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nand.txt
 create mode 100644 drivers/mtd/nand/arasan_nand.c

-- 
2.13.0

[PATCH v8 0/2] Add support for Arasan NAND Flash controller

[Naga Sureshkumar Relli]

This patch series adds the basic driver support for Arasan NAND Flash
controller.
We are reinitiating the patch series by fixing the comments given by
Boris and Rob.

Previous Patch reference:
https://lkml.org/lkml/2017/1/8/245

Naga Sureshkumar Relli (2):
  mtd: arasan: Add device tree binding documentation
  mtd: nand: Add support for Arasan NAND Flash Controller

 .../devicetree/bindings/mtd/arasan_nand.txt|   38 +
 drivers/mtd/nand/Kconfig   |8 +
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/arasan_nand.c | 1020 
 4 files changed, 1067 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nand.txt
 create mode 100644 drivers/mtd/nand/arasan_nand.c

-- 
2.13.0

[PATCH v8 1/2] mtd: arasan: Add device tree binding documentation

[Naga Sureshkumar Relli]

This patch adds the dts binding document for arasan nand flash
controller.

Signed-off-by: Naga Sureshkumar Relli 
Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v8:
- Updated compatible and clock-names as per Boris comments
Changes in v7:
- Corrected the acronyms those should be in caps 
changes in v6:
- Removed num-cs property
- Separated nandchip from nand controller
changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
 .../devicetree/bindings/mtd/arasan_nand.txt| 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nand.txt

diff --git a/Documentation/devicetree/bindings/mtd/arasan_nand.txt 
b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
new file mode 100644
index ..1a870153a909
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
@@ -0,0 +1,38 @@
+Arasan NAND Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "xlnx,zynqmp-nand" or "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "sys", "flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables DMA support
+
+For NAND partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+   nand0: nand@ff10 {
+   compatible = "xlnx,zynqmp-nand", "arasan,nfc-v3p10"
+   reg = <0x0 0xff10 0x1000>;
+   clock-name = "sys", "flash"
+   clocks = <_clk _clk>;
+   interrupt-parent = <>;
+   interrupts = <0 14 4>;
+   arasan,has-mdma;
+   #address-cells = <1>;
+   #size-cells = <0>
+
+   nand@0 {
+   reg = <0>
+   partition@0 {
+   label = "filesystem";
+   reg = <0x0 0x0 0x100>;
+   };
+   (...)
+   };
+   };
-- 
2.13.0

[PATCH v8 1/2] mtd: arasan: Add device tree binding documentation

[Naga Sureshkumar Relli]

This patch adds the dts binding document for arasan nand flash
controller.

Signed-off-by: Naga Sureshkumar Relli 
Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v8:
- Updated compatible and clock-names as per Boris comments
Changes in v7:
- Corrected the acronyms those should be in caps 
changes in v6:
- Removed num-cs property
- Separated nandchip from nand controller
changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
 .../devicetree/bindings/mtd/arasan_nand.txt| 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nand.txt

diff --git a/Documentation/devicetree/bindings/mtd/arasan_nand.txt 
b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
new file mode 100644
index ..1a870153a909
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
@@ -0,0 +1,38 @@
+Arasan NAND Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "xlnx,zynqmp-nand" or "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "sys", "flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables DMA support
+
+For NAND partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+   nand0: nand@ff10 {
+   compatible = "xlnx,zynqmp-nand", "arasan,nfc-v3p10"
+   reg = <0x0 0xff10 0x1000>;
+   clock-name = "sys", "flash"
+   clocks = <_clk _clk>;
+   interrupt-parent = <>;
+   interrupts = <0 14 4>;
+   arasan,has-mdma;
+   #address-cells = <1>;
+   #size-cells = <0>
+
+   nand@0 {
+   reg = <0>
+   partition@0 {
+   label = "filesystem";
+   reg = <0x0 0x0 0x100>;
+   };
+   (...)
+   };
+   };
-- 
2.13.0

Re: [PATCH] staging: comedi: ni_*

[Aniruddha Shastri]

On Wed, Dec 13, 2017 at 6:07 AM, Greg Kroah-Hartman
 wrote:
> On Wed, Dec 13, 2017 at 05:16:13PM +0530, Aniruddha Shastri wrote:
>> On Wed, Dec 13, 2017 at 4:20 PM, Greg Kroah-Hartman
>>  wrote:
>> >
>> > On Wed, Dec 13, 2017 at 04:01:04AM -0600, Aniruddha Shastri wrote:
>> > > Fix checkpatch warnings by shortening lines and reorganizing code where 
>> > > needed..
>> > > Re-phrase the assert messages in ni_mio_common.c. This was done to meet 
>> > > the character limit for the message.
>> >
>> > And yet this line is over the character length :)
>> Aniruddha: Thanks for pointing this out, I'll amend the commit message. :)
>
> Why put your name in the response?  Of course I know it's you who is
> writing this :)
I thought it might be clearer for others to read our exchange, but that only
works if everyone does the same. Otherwise, it's just clutter. I'm used to
seeing a name and timestamp next to comments in other code review
systems (like TFS), but this doesn't appear to be the Linux way :)
>
>> > >   range_table_list = kmalloc_array(32,
>> > > -  sizeof(struct 
>> > > comedi_lrange *),
>> > > +  range_size,
>> >
>> > Not worth changing.
>>
>> Aniruddha: The original checkpatch.pl warning instructed to use
>> const struct comedi_lrange instead of struct. Adding the 'const' put this
>> line over the limit, so that's why I pulled it out into a local variable.
>
> Checkpatch is a "hint", don't always follow it, it can cause some code
> to look really bad.  It's not a hard-rule.
That's a relief :). I've sent updated patches that only clean-up where
needed.
>
> thanks,
>
> greg k-h

Re: [PATCH] staging: comedi: ni_*

[Aniruddha Shastri]

On Wed, Dec 13, 2017 at 6:07 AM, Greg Kroah-Hartman
 wrote:
> On Wed, Dec 13, 2017 at 05:16:13PM +0530, Aniruddha Shastri wrote:
>> On Wed, Dec 13, 2017 at 4:20 PM, Greg Kroah-Hartman
>>  wrote:
>> >
>> > On Wed, Dec 13, 2017 at 04:01:04AM -0600, Aniruddha Shastri wrote:
>> > > Fix checkpatch warnings by shortening lines and reorganizing code where 
>> > > needed..
>> > > Re-phrase the assert messages in ni_mio_common.c. This was done to meet 
>> > > the character limit for the message.
>> >
>> > And yet this line is over the character length :)
>> Aniruddha: Thanks for pointing this out, I'll amend the commit message. :)
>
> Why put your name in the response?  Of course I know it's you who is
> writing this :)
I thought it might be clearer for others to read our exchange, but that only
works if everyone does the same. Otherwise, it's just clutter. I'm used to
seeing a name and timestamp next to comments in other code review
systems (like TFS), but this doesn't appear to be the Linux way :)
>
>> > >   range_table_list = kmalloc_array(32,
>> > > -  sizeof(struct 
>> > > comedi_lrange *),
>> > > +  range_size,
>> >
>> > Not worth changing.
>>
>> Aniruddha: The original checkpatch.pl warning instructed to use
>> const struct comedi_lrange instead of struct. Adding the 'const' put this
>> line over the limit, so that's why I pulled it out into a local variable.
>
> Checkpatch is a "hint", don't always follow it, it can cause some code
> to look really bad.  It's not a hard-rule.
That's a relief :). I've sent updated patches that only clean-up where
needed.
>
> thanks,
>
> greg k-h

Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

[Greg KH]

On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:
> Some driviers may have the chance to increase a reference count that
> has dropped to zero when using get_device() because of their design.

Then those drivers are broken :)

> We have met such a issue with scsi:
> https://www.spinics.net/lists/linux-scsi/msg115295.html
> 
> The scsi core will keep the scsi device object in the host list after
> it has been deleted and the iterator can still find it. All of the
> places where need iterating have to check the state of the scsi device
> and this makes a lot of code redundancy and complexity.
> 
> Provide a safe mechanism in get_device() by using
> kobject_get_unless_zero().
> 
> Suggested-by: Bart Van Assche 
> Signed-off-by: Jason Yan 
> CC: Greg Kroah-Hartman 
> CC: Bart Van Assche 
> CC: Ewan D. Milne 
> CC: James E.J. Bottomley 
> CC: Christoph Hellwig 
> ---
>  drivers/base/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 12ebd05..cc74810 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
>   */
>  struct device *get_device(struct device *dev)
>  {
> - return dev ? kobj_to_dev(kobject_get(>kobj)) : NULL;
> + return dev && kobject_get_unless_zero(>kobj) ? dev : NULL;

I really don't want to do this, the bus the device is on should prevent
this from happening.

Also, once that reference count drops to zero, the memory should be
freed, so you really have a stale pointer here, and this code would fail
if you had slab debugging enabled anyway.

So I don't even think this fixes the issue you think it fixes :)

thanks,

greg k-h

Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

[Greg KH]

On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:
> Some driviers may have the chance to increase a reference count that
> has dropped to zero when using get_device() because of their design.

Then those drivers are broken :)

> We have met such a issue with scsi:
> https://www.spinics.net/lists/linux-scsi/msg115295.html
> 
> The scsi core will keep the scsi device object in the host list after
> it has been deleted and the iterator can still find it. All of the
> places where need iterating have to check the state of the scsi device
> and this makes a lot of code redundancy and complexity.
> 
> Provide a safe mechanism in get_device() by using
> kobject_get_unless_zero().
> 
> Suggested-by: Bart Van Assche 
> Signed-off-by: Jason Yan 
> CC: Greg Kroah-Hartman 
> CC: Bart Van Assche 
> CC: Ewan D. Milne 
> CC: James E.J. Bottomley 
> CC: Christoph Hellwig 
> ---
>  drivers/base/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 12ebd05..cc74810 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
>   */
>  struct device *get_device(struct device *dev)
>  {
> - return dev ? kobj_to_dev(kobject_get(>kobj)) : NULL;
> + return dev && kobject_get_unless_zero(>kobj) ? dev : NULL;

I really don't want to do this, the bus the device is on should prevent
this from happening.

Also, once that reference count drops to zero, the memory should be
freed, so you really have a stale pointer here, and this code would fail
if you had slab debugging enabled anyway.

So I don't even think this fixes the issue you think it fixes :)

thanks,

greg k-h

Re: [PATCH 4/4] scsi: arcmsr: simplify all arcmsr_hbaX_get_config routine by call a new get_adapter_config function

[Ching Huang]

On Thu, 2017-12-14 at 13:13 +0800, kbuild test robot wrote:
> Hi Ching,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on scsi/for-next]
> [also build test WARNING on next-20171213]
> [cannot apply to v4.15-rc3]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
As what I have said in [PATCH 0/4], this serial patches are apply to
Martin's 4.16/scsi-queue only. Now scsi/for-next and next-20171213 are
synchronized to Martin's 4.16/scsi-queue, so these patches can apply to
them. But v4.15-rc3 has to do some patches like 4.16/scsi-queue done
before, or this patch can not apply.
> 
> url:
> https://github.com/0day-ci/linux/commits/Ching-Huang/scsi-arcmsr-simplify-hba_get_config-routine/20171213-224803
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
> 
> 
> sparse warnings: (new ones prefixed by >>)
> 
> 
> vim +2971 drivers/scsi/arcmsr/arcmsr_hba.c
> 
>   2958
>   2959static void arcmsr_get_adapter_config(struct 
> AdapterControlBlock *pACB, uint32_t *rwbuffer)
>   2960{
>   2961int count;
>   2962uint32_t *acb_firm_model = (uint32_t *)pACB->firm_model;
>   2963uint32_t *acb_firm_version = (uint32_t 
> *)pACB->firm_version;
>   2964uint32_t *acb_device_map = (uint32_t *)pACB->device_map;
>   2965uint32_t *firm_model = [15];
>   2966uint32_t *firm_version = [17];
>   2967uint32_t *device_map = [21];
>   2968
>   2969count = 2;
>   2970while (count) {
> > 2971*acb_firm_model = readl(firm_model);
>   2972acb_firm_model++;
>   2973firm_model++;
>   2974count--;
>   2975}
>   2976count = 4;
>   2977while (count) {
>   2978*acb_firm_version = readl(firm_version);
>   2979acb_firm_version++;
>   2980firm_version++;
>   2981count--;
>   2982}
>   2983count = 4;
>   2984while (count) {
>   2985*acb_device_map = readl(device_map);
>   2986acb_device_map++;
>   2987device_map++;
>   2988count--;
>   2989}
>   2990pACB->signature = readl([0]);
>   2991pACB->firm_request_len = readl([1]);
>   2992pACB->firm_numbers_queue = readl([2]);
> > 2993pACB->firm_sdram_size = readl([3]);
> > 2994pACB->firm_hd_channels = readl([4]);
>   2995pACB->firm_cfg_version = readl([25]);
>   2996pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
>   2997pACB->host->host_no,
>   2998pACB->firm_model,
>   2999pACB->firm_version);
>   3000}
>   3001
>   3002static bool arcmsr_hbaA_get_config(struct AdapterControlBlock 
> *acb)
>   3003{
>   3004struct MessageUnit_A __iomem *reg = acb->pmuA;
>   3005
>   3006arcmsr_wait_firmware_ready(acb);
>   3007writel(ARCMSR_INBOUND_MESG0_GET_CONFIG, 
> >inbound_msgaddr0);
>   3008if (!arcmsr_hbaA_wait_msgint_ready(acb)) {
>   3009printk(KERN_NOTICE "arcmsr%d: wait 'get adapter 
> firmware \
>   3010miscellaneous data' timeout \n", 
> acb->host->host_no);
>   3011return false;
>   3012}
> > 3013arcmsr_get_adapter_config(acb, reg->message_rwbuffer);
>   3014return true;
>   3015}
>   3016static bool arcmsr_hbaB_get_config(struct AdapterControlBlock 
> *acb)
>   3017{
>   3018struct MessageUnit_B *reg = acb->pmuB;
>   3019
>   3020arcmsr_wait_firmware_ready(acb);
>   3021writel(ARCMSR_MESSAGE_START_DRIVER_MODE, 
> reg->drv2iop_doorbell);
>   3022if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
>   3023printk(KERN_ERR "arcmsr%d: can't set driver 
> mode.\n", acb-

Re: [PATCH 4/4] scsi: arcmsr: simplify all arcmsr_hbaX_get_config routine by call a new get_adapter_config function

[Ching Huang]

On Thu, 2017-12-14 at 13:13 +0800, kbuild test robot wrote:
> Hi Ching,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on scsi/for-next]
> [also build test WARNING on next-20171213]
> [cannot apply to v4.15-rc3]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
As what I have said in [PATCH 0/4], this serial patches are apply to
Martin's 4.16/scsi-queue only. Now scsi/for-next and next-20171213 are
synchronized to Martin's 4.16/scsi-queue, so these patches can apply to
them. But v4.15-rc3 has to do some patches like 4.16/scsi-queue done
before, or this patch can not apply.
> 
> url:
> https://github.com/0day-ci/linux/commits/Ching-Huang/scsi-arcmsr-simplify-hba_get_config-routine/20171213-224803
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
> 
> 
> sparse warnings: (new ones prefixed by >>)
> 
> 
> vim +2971 drivers/scsi/arcmsr/arcmsr_hba.c
> 
>   2958
>   2959static void arcmsr_get_adapter_config(struct 
> AdapterControlBlock *pACB, uint32_t *rwbuffer)
>   2960{
>   2961int count;
>   2962uint32_t *acb_firm_model = (uint32_t *)pACB->firm_model;
>   2963uint32_t *acb_firm_version = (uint32_t 
> *)pACB->firm_version;
>   2964uint32_t *acb_device_map = (uint32_t *)pACB->device_map;
>   2965uint32_t *firm_model = [15];
>   2966uint32_t *firm_version = [17];
>   2967uint32_t *device_map = [21];
>   2968
>   2969count = 2;
>   2970while (count) {
> > 2971*acb_firm_model = readl(firm_model);
>   2972acb_firm_model++;
>   2973firm_model++;
>   2974count--;
>   2975}
>   2976count = 4;
>   2977while (count) {
>   2978*acb_firm_version = readl(firm_version);
>   2979acb_firm_version++;
>   2980firm_version++;
>   2981count--;
>   2982}
>   2983count = 4;
>   2984while (count) {
>   2985*acb_device_map = readl(device_map);
>   2986acb_device_map++;
>   2987device_map++;
>   2988count--;
>   2989}
>   2990pACB->signature = readl([0]);
>   2991pACB->firm_request_len = readl([1]);
>   2992pACB->firm_numbers_queue = readl([2]);
> > 2993pACB->firm_sdram_size = readl([3]);
> > 2994pACB->firm_hd_channels = readl([4]);
>   2995pACB->firm_cfg_version = readl([25]);
>   2996pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
>   2997pACB->host->host_no,
>   2998pACB->firm_model,
>   2999pACB->firm_version);
>   3000}
>   3001
>   3002static bool arcmsr_hbaA_get_config(struct AdapterControlBlock 
> *acb)
>   3003{
>   3004struct MessageUnit_A __iomem *reg = acb->pmuA;
>   3005
>   3006arcmsr_wait_firmware_ready(acb);
>   3007writel(ARCMSR_INBOUND_MESG0_GET_CONFIG, 
> >inbound_msgaddr0);
>   3008if (!arcmsr_hbaA_wait_msgint_ready(acb)) {
>   3009printk(KERN_NOTICE "arcmsr%d: wait 'get adapter 
> firmware \
>   3010miscellaneous data' timeout \n", 
> acb->host->host_no);
>   3011return false;
>   3012}
> > 3013arcmsr_get_adapter_config(acb, reg->message_rwbuffer);
>   3014return true;
>   3015}
>   3016static bool arcmsr_hbaB_get_config(struct AdapterControlBlock 
> *acb)
>   3017{
>   3018struct MessageUnit_B *reg = acb->pmuB;
>   3019
>   3020arcmsr_wait_firmware_ready(acb);
>   3021writel(ARCMSR_MESSAGE_START_DRIVER_MODE, 
> reg->drv2iop_doorbell);
>   3022if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
>   3023printk(KERN_ERR "arcmsr%d: can't set driver 
> mode.\n", acb-

Re: [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration

[Michal Hocko]

On Wed 13-12-17 15:35:33, Mike Kravetz wrote:
> On 12/04/2017 06:01 AM, Michal Hocko wrote:
[...]
> > Before migration
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0
> > 
> > After
> > 
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:0
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:1
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0
> > 
> > with the previous implementation, both nodes would have nr_hugepages:1
> > until the page is freed.
> 
> With the previous implementation, the migration would have failed unless
> nr_overcommit_hugepages was explicitly set.  Correct?

yes

[...]

> In the previous version of this patch, I asked about handling of 'free' huge
> pages.  I did a little digging and IIUC, we do not attempt migration of
> free huge pages.  The routine isolate_huge_page() has this check:
> 
> if (!page_huge_active(page) || !get_page_unless_zero(page)) {
> ret = false;
> goto unlock;
> }
> 
> I believe one of your motivations for this effort was memory offlining.
> So, this implies that a memory area can not be offlined if it contains
> a free (not in use) huge page?

do_migrate_range will ignore this free huge page and then we will free
it up in dissolve_free_huge_pages

> Just FYI and may be something we want to address later.

Maybe yes. The free pool might be reserved which would make
dissolve_free_huge_pages to fail. Maybe we can be more clever and
allocate a new huge page in that case.
 
> My other issues were addressed.
> 
> Reviewed-by: Mike Kravetz 

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration

[Michal Hocko]

On Wed 13-12-17 15:35:33, Mike Kravetz wrote:
> On 12/04/2017 06:01 AM, Michal Hocko wrote:
[...]
> > Before migration
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0
> > 
> > After
> > 
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:0
> > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:0
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages:1
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/surplus_hugepages:0
> > 
> > with the previous implementation, both nodes would have nr_hugepages:1
> > until the page is freed.
> 
> With the previous implementation, the migration would have failed unless
> nr_overcommit_hugepages was explicitly set.  Correct?

yes

[...]

> In the previous version of this patch, I asked about handling of 'free' huge
> pages.  I did a little digging and IIUC, we do not attempt migration of
> free huge pages.  The routine isolate_huge_page() has this check:
> 
> if (!page_huge_active(page) || !get_page_unless_zero(page)) {
> ret = false;
> goto unlock;
> }
> 
> I believe one of your motivations for this effort was memory offlining.
> So, this implies that a memory area can not be offlined if it contains
> a free (not in use) huge page?

do_migrate_range will ignore this free huge page and then we will free
it up in dissolve_free_huge_pages

> Just FYI and may be something we want to address later.

Maybe yes. The free pool might be reserved which would make
dissolve_free_huge_pages to fail. Maybe we can be more clever and
allocate a new huge page in that case.
 
> My other issues were addressed.
> 
> Reviewed-by: Mike Kravetz 

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem

[Greg Kroah-Hartman]

On Thu, Dec 14, 2017 at 11:19:31AM +0530, Vinod Koul wrote:
> Changes in v6:
>   - Add reviewed/acked tags from Philippe, Pierre, Takashi and Greg
>   - Fix nitpicks from Takashi
>   - Drop the sysfs patch for now

Wait, why drop the sysfs patch entirely?  You need those attributes,
right?  You also need to document the existing sysfs files in
Documentation/ABI/ for the class/device files you create in this patch
series, so that needs to be done before this patch series can be
accepted.

thanks,

greg k-h

Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem

[Greg Kroah-Hartman]

On Thu, Dec 14, 2017 at 11:19:31AM +0530, Vinod Koul wrote:
> Changes in v6:
>   - Add reviewed/acked tags from Philippe, Pierre, Takashi and Greg
>   - Fix nitpicks from Takashi
>   - Drop the sysfs patch for now

Wait, why drop the sysfs patch entirely?  You need those attributes,
right?  You also need to document the existing sysfs files in
Documentation/ABI/ for the class/device files you create in this patch
series, so that needs to be done before this patch series can be
accepted.

thanks,

greg k-h

Re: [PATCH] Staging: vc04_services: fix brace coding style issues in vchiq_shim.c

[Stefan Wahren]

Am 13.12.2017 um 21:51 schrieb Tomas Marek:

This patch fix brace on next line coding style errors reported by
checkpatch.

Signed-off-by: Tomas Marek 


Acked-by: Stefan Wahren 

Thanks

Re: [PATCH] Staging: vc04_services: fix brace coding style issues in vchiq_shim.c

[Stefan Wahren]

Am 13.12.2017 um 21:51 schrieb Tomas Marek:

This patch fix brace on next line coding style errors reported by
checkpatch.

Signed-off-by: Tomas Marek 


Acked-by: Stefan Wahren 

Thanks

[PATCH v3] staging: comedi: ni_*: Fix style warnings.

[Aniruddha Shastri]

Two of these warnings are now line-too-long warnings. I think these 
warnings are preferable to the ones listed below. The longest line is
only 85 chars wide, which is reasonable.

Warnings fixed:
ni_atmio.c:239: WARNING: Avoid multiple line dereference
- prefer 'ni_boards[i].isapnp_id'
ni_labpc_common.c:573: WARNING: Avoid multiple line dereference
- prefer 'cmd->scan_begin_arg'
ni_mio_common.c:736: WARNING: Avoid multiple line dereference
- prefer 'devpriv->counter_dev->counters[gpct_index]'
ni_mio_common.c:1977: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:1990: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int *' should also have an identifier name
ni_mio_common.c:4699: WARNING: Prefer using '"%s...", __func__'
to using 'cs5529_do_conversion', this function's name, in a string
ni_stc.h:21: WARNING: Block comments should align the * on each line

Signed-off-by: Aniruddha Shastri 
---
Changes in v3:
No longer add 'const' to sizeof(struct comedi_lrange) in ni_670x.c:212

 drivers/staging/comedi/drivers/ni_atmio.c|  6 +++---
 drivers/staging/comedi/drivers/ni_labpc_common.c |  3 +--
 drivers/staging/comedi/drivers/ni_mio_common.c   | 14 --
 drivers/staging/comedi/drivers/ni_stc.h  |  2 +-
 4 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index ae6ed96..f9a8638 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -234,9 +234,9 @@ static int ni_isapnp_find_board(struct pnp_dev **dev)
 
for (i = 0; i < ARRAY_SIZE(ni_boards); i++) {
isapnp_dev = pnp_find_dev(NULL,
- ISAPNP_VENDOR('N', 'I', 'C'),
- ISAPNP_FUNCTION(ni_boards[i].
- isapnp_id), NULL);
+   ISAPNP_VENDOR('N', 'I', 'C'),
+   ISAPNP_FUNCTION(ni_boards[i].isapnp_id),
+   NULL);
 
if (!isapnp_dev || !isapnp_dev->card)
continue;
diff --git a/drivers/staging/comedi/drivers/ni_labpc_common.c 
b/drivers/staging/comedi/drivers/ni_labpc_common.c
index b0dfb8e..a38910e 100644
--- a/drivers/staging/comedi/drivers/ni_labpc_common.c
+++ b/drivers/staging/comedi/drivers/ni_labpc_common.c
@@ -569,8 +569,7 @@ static int labpc_ai_cmdtest(struct comedi_device *dev,
/* make sure scan timing is not too fast */
if (cmd->scan_begin_src == TRIG_TIMER) {
if (cmd->convert_src == TRIG_TIMER) {
-   err |= comedi_check_trigger_arg_min(>
-   scan_begin_arg,
+   err |= 
comedi_check_trigger_arg_min(>scan_begin_arg,
cmd->convert_arg *
cmd->chanlist_len);
}
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 398347f..c4a4f5c 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -732,8 +732,7 @@ static void ni_release_gpct_mite_channel(struct 
comedi_device *dev,
 
ni_set_bitfield(dev, NI_E_DMA_G0_G1_SEL_REG,
NI_E_DMA_G0_G1_SEL_MASK(gpct_index), 0);
-   ni_tio_set_mite_channel(>
-   counter_dev->counters[gpct_index],
+   
ni_tio_set_mite_channel(>counter_dev->counters[gpct_index],
NULL);
mite_release_channel(mite_chan);
}
@@ -1974,7 +1973,8 @@ static void ni_cmd_set_mite_transfer(struct mite_ring 
*ring,
if (nbytes > sdev->async->prealloc_bufsz) {
if (cmd->stop_arg > 0)
dev_err(sdev->device->class_dev,
-   "ni_cmd_set_mite_transfer: tried exact data 
transfer limits greater than buffer size\n");
+   "%s: tried exact data transfer limits greater 
than buffer size\n",
+   __func__);
 
/*
 * we can only transfer up to the size of the buffer.  In this
@@ -1987,7 +1987,8 @@ static void 

[PATCH v3] staging: comedi: ni_*: Fix style warnings.

[Aniruddha Shastri]

Two of these warnings are now line-too-long warnings. I think these 
warnings are preferable to the ones listed below. The longest line is
only 85 chars wide, which is reasonable.

Warnings fixed:
ni_atmio.c:239: WARNING: Avoid multiple line dereference
- prefer 'ni_boards[i].isapnp_id'
ni_labpc_common.c:573: WARNING: Avoid multiple line dereference
- prefer 'cmd->scan_begin_arg'
ni_mio_common.c:736: WARNING: Avoid multiple line dereference
- prefer 'devpriv->counter_dev->counters[gpct_index]'
ni_mio_common.c:1977: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:1990: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int *' should also have an identifier name
ni_mio_common.c:4699: WARNING: Prefer using '"%s...", __func__'
to using 'cs5529_do_conversion', this function's name, in a string
ni_stc.h:21: WARNING: Block comments should align the * on each line

Signed-off-by: Aniruddha Shastri 
---
Changes in v3:
No longer add 'const' to sizeof(struct comedi_lrange) in ni_670x.c:212

 drivers/staging/comedi/drivers/ni_atmio.c|  6 +++---
 drivers/staging/comedi/drivers/ni_labpc_common.c |  3 +--
 drivers/staging/comedi/drivers/ni_mio_common.c   | 14 --
 drivers/staging/comedi/drivers/ni_stc.h  |  2 +-
 4 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index ae6ed96..f9a8638 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -234,9 +234,9 @@ static int ni_isapnp_find_board(struct pnp_dev **dev)
 
for (i = 0; i < ARRAY_SIZE(ni_boards); i++) {
isapnp_dev = pnp_find_dev(NULL,
- ISAPNP_VENDOR('N', 'I', 'C'),
- ISAPNP_FUNCTION(ni_boards[i].
- isapnp_id), NULL);
+   ISAPNP_VENDOR('N', 'I', 'C'),
+   ISAPNP_FUNCTION(ni_boards[i].isapnp_id),
+   NULL);
 
if (!isapnp_dev || !isapnp_dev->card)
continue;
diff --git a/drivers/staging/comedi/drivers/ni_labpc_common.c 
b/drivers/staging/comedi/drivers/ni_labpc_common.c
index b0dfb8e..a38910e 100644
--- a/drivers/staging/comedi/drivers/ni_labpc_common.c
+++ b/drivers/staging/comedi/drivers/ni_labpc_common.c
@@ -569,8 +569,7 @@ static int labpc_ai_cmdtest(struct comedi_device *dev,
/* make sure scan timing is not too fast */
if (cmd->scan_begin_src == TRIG_TIMER) {
if (cmd->convert_src == TRIG_TIMER) {
-   err |= comedi_check_trigger_arg_min(>
-   scan_begin_arg,
+   err |= 
comedi_check_trigger_arg_min(>scan_begin_arg,
cmd->convert_arg *
cmd->chanlist_len);
}
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 398347f..c4a4f5c 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -732,8 +732,7 @@ static void ni_release_gpct_mite_channel(struct 
comedi_device *dev,
 
ni_set_bitfield(dev, NI_E_DMA_G0_G1_SEL_REG,
NI_E_DMA_G0_G1_SEL_MASK(gpct_index), 0);
-   ni_tio_set_mite_channel(>
-   counter_dev->counters[gpct_index],
+   
ni_tio_set_mite_channel(>counter_dev->counters[gpct_index],
NULL);
mite_release_channel(mite_chan);
}
@@ -1974,7 +1973,8 @@ static void ni_cmd_set_mite_transfer(struct mite_ring 
*ring,
if (nbytes > sdev->async->prealloc_bufsz) {
if (cmd->stop_arg > 0)
dev_err(sdev->device->class_dev,
-   "ni_cmd_set_mite_transfer: tried exact data 
transfer limits greater than buffer size\n");
+   "%s: tried exact data transfer limits greater 
than buffer size\n",
+   __func__);
 
/*
 * we can only transfer up to the size of the buffer.  In this
@@ -1987,7 +1987,8 @@ static void 

Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

[Viresh Kumar]

On 30-11-17, 12:29, Viresh Kumar wrote:
> On 29-11-17, 16:50, Stephen Boyd wrote:
> > Sorry it still makes zero sense to me. It seems that we're trying
> > to make the OPP table parsing generic just for the sake of code
> > brevity.
> 
> Not just the code but bindings as well to make sure we don't add a new
> property (similar to earlier ones) for every platform that wants to
> use performance states.

@Stephen: Do you have any feedback on my previous email? If no, then I
would like to refresh this version with the feedback received from
Rob.

-- 
viresh

Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

[Viresh Kumar]

On 30-11-17, 12:29, Viresh Kumar wrote:
> On 29-11-17, 16:50, Stephen Boyd wrote:
> > Sorry it still makes zero sense to me. It seems that we're trying
> > to make the OPP table parsing generic just for the sake of code
> > brevity.
> 
> Not just the code but bindings as well to make sure we don't add a new
> property (similar to earlier ones) for every platform that wants to
> use performance states.

@Stephen: Do you have any feedback on my previous email? If no, then I
would like to refresh this version with the feedback received from
Rob.

-- 
viresh

Re: [PATCH v3] Staging: pi433: fix brace coding style issues in pi433_if.c

[Greg KH]

On Wed, Dec 13, 2017 at 11:31:15AM -0800, Tomas Marek wrote:
> On 12/13/2017 03:55 AM, Greg KH wrote:
> 
> > On Sat, Dec 09, 2017 at 12:41:11PM -0800, Tomas Marek wrote:
> >> This patch fix several brace on next line, braces not necessary, space
> >> around =/<, and space before/after open/close parenthesis coding style
> >> errors find by checkpatch in pi433_if.c.
> >>
> >> Signed-off-by: Tomas Marek 
> >> ---
> >> Changes in v3:
> >>   - DIO0_irq_handler update reverted - will be submitted in separate
> >> patch for the sake of clarity.
> >> Changes in v2:
> >>   - DIO0_irq_handler updated - 'if/else if' replaced by 'switch' and
> >> 'dev_dbg_ratelimited' used instead of 'dev_dbg' according to Joe
> >> Perches suggestion.
> >>   - The removal of braces around SET_CHECKED() reverted - caused syntax
> >> error and is addressed by another patch
> >> "[PATCHv2] staging: pi433: pi433_if.c remove SET_CHECKED macro".
> > This doesn't apply to my tree at all :(
> >
> > Please rebase it against the staging-next branch of staging.git (or the
> > staging-testing branch to be sure), and then resend.
> >
> > thanks,
> >
> > greg k-h
> I am sorry for complications. I did it against linux-next. I'll rebase it
> against stating and cross-check against staging-testing, hopefully it will
> be fine then.

Normally linux-next is fine to do your work against.  But as you can see
on the mailing list, there are a lot of people sending a lot of patches
for this one driver.  So things end up changing quickly, usually the
merge issue is that I took a patch that was sent a few hours before
yours, and you did it all right.

Sorry, rebasing and resending patches are just a normal mode for working
on a high-traffic area in the kernel, thanks for your patience.

greg k-h

Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement

[Michal Hocko]

On Thu 14-12-17 09:40:32, kemi wrote:
> 
> 
> On 2017年12月12日 16:11, Michal Hocko wrote:
> > On Tue 12-12-17 10:05:26, kemi wrote:
> >>
> >>
> >> On 2017年12月08日 16:47, Michal Hocko wrote:
> >>> On Fri 08-12-17 16:38:46, kemi wrote:
> 
> 
>  On 2017年11月30日 17:45, Michal Hocko wrote:
> > On Thu 30-11-17 17:32:08, kemi wrote:
> 
>  After thinking about how to optimize our per-node stats more gracefully, 
>  we may add u64 vm_numa_stat_diff[] in struct per_cpu_nodestat, thus,
>  we can keep everything in per cpu counter and sum them up when read /proc
>  or /sys for numa stats. 
>  What's your idea for that? thanks
> >>>
> >>> I would like to see a strong argument why we cannot make it a _standard_
> >>> node counter.
> >>>
> >>
> >> all right. 
> >> This issue is first reported and discussed in 2017 MM summit, referred to
> >> the topic "Provoking and fixing memory bottlenecks -Focused on the page 
> >> allocator presentation" presented by Jesper.
> >>
> >> http://people.netfilter.org/hawk/presentations/MM-summit2017/MM-summit
> >> 2017-JesperBrouer.pdf (slide 15/16)
> >>
> >> As you know, page allocator is too slow and has becomes a bottleneck
> >> in high-speed network.
> >> Jesper also showed some data in that presentation: with micro benchmark 
> >> stresses order-0 fast path(per CPU pages), *32%* extra CPU cycles cost 
> >> (143->97) comes from CONFIG_NUMA. 
> >>
> >> When I took a look at this issue, I reproduced this issue and got a
> >> similar result to Jesper's. Furthermore, with the help from Jesper, 
> >> the overhead is root caused and the real cause of this overhead comes
> >> from an extra level of function calls such as zone_statistics() (*10%*,
> >> nearly 1/3, including __inc_numa_state), policy_zonelist, 
> >> get_task_policy(),
> >> policy_nodemask and etc (perf profiling cpu cycles).  zone_statistics() 
> >> is the biggest one introduced by CONFIG_NUMA in fast path that we can 
> >> do something for optimizing page allocator. Plus, the overhead of 
> >> zone_statistics() significantly increase with more and more cpu 
> >> cores and nodes due to cache bouncing.
> >>
> >> Therefore, we submitted a patch before to mitigate the overhead of 
> >> zone_statistics() by reducing global NUMA counter update frequency 
> >> (enlarge threshold size, as suggested by Dave Hansen). I also would
> >> like to have an implementation of a "_standard_node counter" for NUMA
> >> stats, but I wonder how we can keep the performance gain at the
> >> same time.
> > 
> > I understand all that. But we do have a way to put all that overhead
> > away by disabling the stats altogether. I presume that CPU cycle
> > sensitive workloads would simply use that option because the stats are
> > quite limited in their usefulness anyway IMHO. So we are back to: Do
> > normal workloads care all that much to have 3rd way to account for
> > events? I haven't heard a sound argument for that.
> > 
> 
> I'm not a fan of adding code that nobody(or 0.001%) cares.
> We can't depend on that tunable interface too much, because our customers 
> or even kernel hacker may not know that new added interface,

Come on. If somebody want's to tune the system to squeeze every single
cycle then there is tuning required and those people can figure out.

> or sometimes 
> NUMA stats can't be disabled in their environments.

why?

> That's the reason
> why we spent time to do that optimization other than simply adding a runtime
> configuration interface.
> 
> Furthermore, the code we optimized for is the core area of kernel that can
> benefit most of kernel actions, more or less I think.
> 
> All right, let's think about it in another way, does a u64 percpu array 
> per-node
> for NUMA stats really make code too much complicated and hard to maintain?
> I'm afraid not IMHO.

I disagree. The whole numa stat things has turned out to be nasty to
maintain. For a very limited gain. Now you are just shifting that
elsewhere. Look, there are other counters taken in the allocator, we do
not want to treat them specially. We have a nice per-cpu infrastructure
here so I really fail to see why we should code-around it. If that can
be improved then by all means let's do it.

So unless you have a strong usecase I would vote for a simpler code.

-- 
Michal Hocko
SUSE Labs

[PATCH] ASoC: sun4i-i2s: Show detailed error when DAI configuration callbacks fail

[Chen-Yu Tsai]

When any of the DAI hardware configuration callbacks (.hw_param,
.set_fmt, .set_sysclk) fails, there is no explanation about why it
failed. This is particularly confusing for .hw_param, which covers
many parameters of the DAI. Telling the users what parameter isn't
supported, and what the requested value was goes a long way for
developers trying to combine sun4i-i2s with external codecs.

This patch adds dev_err calls explaining what isn't supported or
failed, and what the value was. sun4i_i2s_set_clk_rate()'s first
parameter was changed to a struct snd_soc_dai *dai, so we can
get the underlying device.

Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/sunxi/sun4i-i2s.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 13d7ecabe1b6..dca1143c1150 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -269,10 +269,11 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int 
oversample)
return false;
 }
 
-static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
+static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
  unsigned int rate,
  unsigned int word_size)
 {
+   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int oversample_rate, clk_rate;
int bclk_div, mclk_div;
int ret;
@@ -300,6 +301,7 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
break;
 
default:
+   dev_err(dai->dev, "Unsupported sample rate: %u\n", rate);
return -EINVAL;
}
 
@@ -308,18 +310,25 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
return ret;
 
oversample_rate = i2s->mclk_freq / rate;
-   if (!sun4i_i2s_oversample_is_valid(oversample_rate))
+   if (!sun4i_i2s_oversample_is_valid(oversample_rate)) {
+   dev_err(dai->dev, "Unsupported oversample rate: %d\n",
+   oversample_rate);
return -EINVAL;
+   }
 
bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
  word_size);
-   if (bclk_div < 0)
+   if (bclk_div < 0) {
+   dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
+   }
 
mclk_div = sun4i_i2s_get_mclk_div(i2s, oversample_rate,
  clk_rate, rate);
-   if (mclk_div < 0)
+   if (mclk_div < 0) {
+   dev_err(dai->dev, "Unsupported MCLK divider: %d\n", mclk_div);
return -EINVAL;
+   }
 
/* Adjust the clock division values if needed */
bclk_div += i2s->variant->bclk_offset;
@@ -349,8 +358,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
u32 width;
 
channels = params_channels(params);
-   if (channels != 2)
+   if (channels != 2) {
+   dev_err(dai->dev, "Unsupported number of channels: %d\n",
+   channels);
return -EINVAL;
+   }
 
if (i2s->variant->has_chcfg) {
regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
@@ -382,6 +394,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
width = DMA_SLAVE_BUSWIDTH_2_BYTES;
break;
default:
+   dev_err(dai->dev, "Unsupported physical sample width: %d\n",
+   params_physical_width(params));
return -EINVAL;
}
i2s->playback_dma_data.addr_width = width;
@@ -393,6 +407,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
break;
 
default:
+   dev_err(dai->dev, "Unsupported sample width: %d\n",
+   params_width(params));
return -EINVAL;
}
 
@@ -401,7 +417,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
regmap_field_write(i2s->field_fmt_sr,
   sr + i2s->variant->fmt_offset);
 
-   return sun4i_i2s_set_clk_rate(i2s, params_rate(params),
+   return sun4i_i2s_set_clk_rate(dai, params_rate(params),
  params_width(params));
 }
 
@@ -426,6 +442,8 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
val = SUN4I_I2S_FMT0_FMT_RIGHT_J;
break;
default:
+   dev_err(dai->dev, "Unsupported format: %d\n",
+   fmt & SND_SOC_DAIFMT_FORMAT_MASK);
return -EINVAL;
}
 
@@ -464,6 +482,8 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
case SND_SOC_DAIFMT_NB_NF:
break;
default:
+   dev_err(dai->dev, "Unsupported clock polarity: %d\n",
+  

Re: [PATCH v3] Staging: pi433: fix brace coding style issues in pi433_if.c

[Greg KH]

On Wed, Dec 13, 2017 at 11:31:15AM -0800, Tomas Marek wrote:
> On 12/13/2017 03:55 AM, Greg KH wrote:
> 
> > On Sat, Dec 09, 2017 at 12:41:11PM -0800, Tomas Marek wrote:
> >> This patch fix several brace on next line, braces not necessary, space
> >> around =/<, and space before/after open/close parenthesis coding style
> >> errors find by checkpatch in pi433_if.c.
> >>
> >> Signed-off-by: Tomas Marek 
> >> ---
> >> Changes in v3:
> >>   - DIO0_irq_handler update reverted - will be submitted in separate
> >> patch for the sake of clarity.
> >> Changes in v2:
> >>   - DIO0_irq_handler updated - 'if/else if' replaced by 'switch' and
> >> 'dev_dbg_ratelimited' used instead of 'dev_dbg' according to Joe
> >> Perches suggestion.
> >>   - The removal of braces around SET_CHECKED() reverted - caused syntax
> >> error and is addressed by another patch
> >> "[PATCHv2] staging: pi433: pi433_if.c remove SET_CHECKED macro".
> > This doesn't apply to my tree at all :(
> >
> > Please rebase it against the staging-next branch of staging.git (or the
> > staging-testing branch to be sure), and then resend.
> >
> > thanks,
> >
> > greg k-h
> I am sorry for complications. I did it against linux-next. I'll rebase it
> against stating and cross-check against staging-testing, hopefully it will
> be fine then.

Normally linux-next is fine to do your work against.  But as you can see
on the mailing list, there are a lot of people sending a lot of patches
for this one driver.  So things end up changing quickly, usually the
merge issue is that I took a patch that was sent a few hours before
yours, and you did it all right.

Sorry, rebasing and resending patches are just a normal mode for working
on a high-traffic area in the kernel, thanks for your patience.

greg k-h

Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement

[Michal Hocko]

On Thu 14-12-17 09:40:32, kemi wrote:
> 
> 
> On 2017年12月12日 16:11, Michal Hocko wrote:
> > On Tue 12-12-17 10:05:26, kemi wrote:
> >>
> >>
> >> On 2017年12月08日 16:47, Michal Hocko wrote:
> >>> On Fri 08-12-17 16:38:46, kemi wrote:
> 
> 
>  On 2017年11月30日 17:45, Michal Hocko wrote:
> > On Thu 30-11-17 17:32:08, kemi wrote:
> 
>  After thinking about how to optimize our per-node stats more gracefully, 
>  we may add u64 vm_numa_stat_diff[] in struct per_cpu_nodestat, thus,
>  we can keep everything in per cpu counter and sum them up when read /proc
>  or /sys for numa stats. 
>  What's your idea for that? thanks
> >>>
> >>> I would like to see a strong argument why we cannot make it a _standard_
> >>> node counter.
> >>>
> >>
> >> all right. 
> >> This issue is first reported and discussed in 2017 MM summit, referred to
> >> the topic "Provoking and fixing memory bottlenecks -Focused on the page 
> >> allocator presentation" presented by Jesper.
> >>
> >> http://people.netfilter.org/hawk/presentations/MM-summit2017/MM-summit
> >> 2017-JesperBrouer.pdf (slide 15/16)
> >>
> >> As you know, page allocator is too slow and has becomes a bottleneck
> >> in high-speed network.
> >> Jesper also showed some data in that presentation: with micro benchmark 
> >> stresses order-0 fast path(per CPU pages), *32%* extra CPU cycles cost 
> >> (143->97) comes from CONFIG_NUMA. 
> >>
> >> When I took a look at this issue, I reproduced this issue and got a
> >> similar result to Jesper's. Furthermore, with the help from Jesper, 
> >> the overhead is root caused and the real cause of this overhead comes
> >> from an extra level of function calls such as zone_statistics() (*10%*,
> >> nearly 1/3, including __inc_numa_state), policy_zonelist, 
> >> get_task_policy(),
> >> policy_nodemask and etc (perf profiling cpu cycles).  zone_statistics() 
> >> is the biggest one introduced by CONFIG_NUMA in fast path that we can 
> >> do something for optimizing page allocator. Plus, the overhead of 
> >> zone_statistics() significantly increase with more and more cpu 
> >> cores and nodes due to cache bouncing.
> >>
> >> Therefore, we submitted a patch before to mitigate the overhead of 
> >> zone_statistics() by reducing global NUMA counter update frequency 
> >> (enlarge threshold size, as suggested by Dave Hansen). I also would
> >> like to have an implementation of a "_standard_node counter" for NUMA
> >> stats, but I wonder how we can keep the performance gain at the
> >> same time.
> > 
> > I understand all that. But we do have a way to put all that overhead
> > away by disabling the stats altogether. I presume that CPU cycle
> > sensitive workloads would simply use that option because the stats are
> > quite limited in their usefulness anyway IMHO. So we are back to: Do
> > normal workloads care all that much to have 3rd way to account for
> > events? I haven't heard a sound argument for that.
> > 
> 
> I'm not a fan of adding code that nobody(or 0.001%) cares.
> We can't depend on that tunable interface too much, because our customers 
> or even kernel hacker may not know that new added interface,

Come on. If somebody want's to tune the system to squeeze every single
cycle then there is tuning required and those people can figure out.

> or sometimes 
> NUMA stats can't be disabled in their environments.

why?

> That's the reason
> why we spent time to do that optimization other than simply adding a runtime
> configuration interface.
> 
> Furthermore, the code we optimized for is the core area of kernel that can
> benefit most of kernel actions, more or less I think.
> 
> All right, let's think about it in another way, does a u64 percpu array 
> per-node
> for NUMA stats really make code too much complicated and hard to maintain?
> I'm afraid not IMHO.

I disagree. The whole numa stat things has turned out to be nasty to
maintain. For a very limited gain. Now you are just shifting that
elsewhere. Look, there are other counters taken in the allocator, we do
not want to treat them specially. We have a nice per-cpu infrastructure
here so I really fail to see why we should code-around it. If that can
be improved then by all means let's do it.

So unless you have a strong usecase I would vote for a simpler code.

-- 
Michal Hocko
SUSE Labs

[PATCH] ASoC: sun4i-i2s: Show detailed error when DAI configuration callbacks fail

[Chen-Yu Tsai]

When any of the DAI hardware configuration callbacks (.hw_param,
.set_fmt, .set_sysclk) fails, there is no explanation about why it
failed. This is particularly confusing for .hw_param, which covers
many parameters of the DAI. Telling the users what parameter isn't
supported, and what the requested value was goes a long way for
developers trying to combine sun4i-i2s with external codecs.

This patch adds dev_err calls explaining what isn't supported or
failed, and what the value was. sun4i_i2s_set_clk_rate()'s first
parameter was changed to a struct snd_soc_dai *dai, so we can
get the underlying device.

Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/sunxi/sun4i-i2s.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 13d7ecabe1b6..dca1143c1150 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -269,10 +269,11 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int 
oversample)
return false;
 }
 
-static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
+static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
  unsigned int rate,
  unsigned int word_size)
 {
+   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int oversample_rate, clk_rate;
int bclk_div, mclk_div;
int ret;
@@ -300,6 +301,7 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
break;
 
default:
+   dev_err(dai->dev, "Unsupported sample rate: %u\n", rate);
return -EINVAL;
}
 
@@ -308,18 +310,25 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
return ret;
 
oversample_rate = i2s->mclk_freq / rate;
-   if (!sun4i_i2s_oversample_is_valid(oversample_rate))
+   if (!sun4i_i2s_oversample_is_valid(oversample_rate)) {
+   dev_err(dai->dev, "Unsupported oversample rate: %d\n",
+   oversample_rate);
return -EINVAL;
+   }
 
bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
  word_size);
-   if (bclk_div < 0)
+   if (bclk_div < 0) {
+   dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
+   }
 
mclk_div = sun4i_i2s_get_mclk_div(i2s, oversample_rate,
  clk_rate, rate);
-   if (mclk_div < 0)
+   if (mclk_div < 0) {
+   dev_err(dai->dev, "Unsupported MCLK divider: %d\n", mclk_div);
return -EINVAL;
+   }
 
/* Adjust the clock division values if needed */
bclk_div += i2s->variant->bclk_offset;
@@ -349,8 +358,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
u32 width;
 
channels = params_channels(params);
-   if (channels != 2)
+   if (channels != 2) {
+   dev_err(dai->dev, "Unsupported number of channels: %d\n",
+   channels);
return -EINVAL;
+   }
 
if (i2s->variant->has_chcfg) {
regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
@@ -382,6 +394,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
width = DMA_SLAVE_BUSWIDTH_2_BYTES;
break;
default:
+   dev_err(dai->dev, "Unsupported physical sample width: %d\n",
+   params_physical_width(params));
return -EINVAL;
}
i2s->playback_dma_data.addr_width = width;
@@ -393,6 +407,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
break;
 
default:
+   dev_err(dai->dev, "Unsupported sample width: %d\n",
+   params_width(params));
return -EINVAL;
}
 
@@ -401,7 +417,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
*substream,
regmap_field_write(i2s->field_fmt_sr,
   sr + i2s->variant->fmt_offset);
 
-   return sun4i_i2s_set_clk_rate(i2s, params_rate(params),
+   return sun4i_i2s_set_clk_rate(dai, params_rate(params),
  params_width(params));
 }
 
@@ -426,6 +442,8 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
val = SUN4I_I2S_FMT0_FMT_RIGHT_J;
break;
default:
+   dev_err(dai->dev, "Unsupported format: %d\n",
+   fmt & SND_SOC_DAIFMT_FORMAT_MASK);
return -EINVAL;
}
 
@@ -464,6 +482,8 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
case SND_SOC_DAIFMT_NB_NF:
break;
default:
+   dev_err(dai->dev, "Unsupported clock polarity: %d\n",
+ 

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

[Greg Kroah-Hartman]

On Thu, Dec 14, 2017 at 11:51:17AM +0530, Aishwarya Pant wrote:
> On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote:
> > > This is a clean-up patch which replaces the uses of raw __ATTR(...)
> > > macro with the more conventional DEVICE_ATTR(...) for defining device
> > > attributes.
> > > 
> > > Done using coccinelle-
> > > 
> > > @r@
> > > identifier foo, n;
> > > @@
> > > 
> > > struct device_attribute foo =  __ATTR(n, ...);
> > > 
> > > @script:python p@
> > > id;
> > > foo << r.foo;
> > > n << r.n;
> > > @@
> > > 
> > > // standardise the variable name to dev_attr_{name}
> > > coccinelle.id = "dev_attr_" + n
> > > 
> > > @@
> > > identifier r.foo;
> > > declarer name DEVICE_ATTR;
> > > @@
> > > 
> > > //change definition
> > > - struct device_attribute foo = __ATTR
> > > + DEVICE_ATTR
> > >   (...);
> > > 
> > > @depends on r@
> > > identifier r.foo, p.id;
> > > @@
> > > 
> > > // replace usages everywhere
> > > - foo
> > > + id
> > > 
> > > Signed-off-by: Aishwarya Pant 
> > > ---
> > >  drivers/staging/fbtft/fbtft-sysfs.c | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
> > > b/drivers/staging/fbtft/fbtft-sysfs.c
> > > index 712096659aa0..506d604d01bb 100644
> > > --- a/drivers/staging/fbtft/fbtft-sysfs.c
> > > +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> > > @@ -197,19 +197,18 @@ static ssize_t show_debug(struct device *device,
> > >   return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
> > >  }
> > >  
> > > -static struct device_attribute debug_device_attr =
> > > - __ATTR(debug, 0660, show_debug, store_debug);
> > > +static DEVICE_ATTR(debug, 0660, show_debug, store_debug);
> > 
> > This should be DEVICE_ATTR_RW(), right?  0660 makes no sense...
> 
> If it doesn't make sense here, I can replace it with DEVICE_ATTR_RW.
> Though, 0660 has more open permissions than 0644.

Unless there is a really good reason for keeping an "odd" sysfs file
mode, use the default permissions.  As this is just a debug flag, 0644
makes a lot more sense, don't you think?

Actually, just drop this whole attribute.  Random "turn on debugging"
config files do not even belong in sysfs.  We have a kernel-wide
infrastructure for all of that already, no single driver, or tiny
subsystem, should have their own custom way of doing this.

thanks,

greg k-h

Re: linux-next: build failure after merge of the staging.current tree

[Greg KH]

On Thu, Dec 14, 2017 at 05:00:33PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging.current tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate':
> drivers/staging/android/ion/ion_cma_heap.c:38:14: error: 
> 'CONFIG_CMA_ALIGNMENT' undeclared (first use in this function)
>   if (align > CONFIG_CMA_ALIGNMENT)
>   ^
> 
> Caused by commit
> 
>   d98e6dbf42f7 ("staging: ion: Fix ion_cma_heap allocations")
> 
> CONFIG_CMA_ALIGNMENT (and CONFIG_DMA_CMA) is not set for this build.
> 
> I have reverted that commit for today.

Thanks, and sorry about that.  John is working on a fix...

greg k-h

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

[Greg Kroah-Hartman]

On Thu, Dec 14, 2017 at 11:51:17AM +0530, Aishwarya Pant wrote:
> On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote:
> > > This is a clean-up patch which replaces the uses of raw __ATTR(...)
> > > macro with the more conventional DEVICE_ATTR(...) for defining device
> > > attributes.
> > > 
> > > Done using coccinelle-
> > > 
> > > @r@
> > > identifier foo, n;
> > > @@
> > > 
> > > struct device_attribute foo =  __ATTR(n, ...);
> > > 
> > > @script:python p@
> > > id;
> > > foo << r.foo;
> > > n << r.n;
> > > @@
> > > 
> > > // standardise the variable name to dev_attr_{name}
> > > coccinelle.id = "dev_attr_" + n
> > > 
> > > @@
> > > identifier r.foo;
> > > declarer name DEVICE_ATTR;
> > > @@
> > > 
> > > //change definition
> > > - struct device_attribute foo = __ATTR
> > > + DEVICE_ATTR
> > >   (...);
> > > 
> > > @depends on r@
> > > identifier r.foo, p.id;
> > > @@
> > > 
> > > // replace usages everywhere
> > > - foo
> > > + id
> > > 
> > > Signed-off-by: Aishwarya Pant 
> > > ---
> > >  drivers/staging/fbtft/fbtft-sysfs.c | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
> > > b/drivers/staging/fbtft/fbtft-sysfs.c
> > > index 712096659aa0..506d604d01bb 100644
> > > --- a/drivers/staging/fbtft/fbtft-sysfs.c
> > > +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> > > @@ -197,19 +197,18 @@ static ssize_t show_debug(struct device *device,
> > >   return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
> > >  }
> > >  
> > > -static struct device_attribute debug_device_attr =
> > > - __ATTR(debug, 0660, show_debug, store_debug);
> > > +static DEVICE_ATTR(debug, 0660, show_debug, store_debug);
> > 
> > This should be DEVICE_ATTR_RW(), right?  0660 makes no sense...
> 
> If it doesn't make sense here, I can replace it with DEVICE_ATTR_RW.
> Though, 0660 has more open permissions than 0644.

Unless there is a really good reason for keeping an "odd" sysfs file
mode, use the default permissions.  As this is just a debug flag, 0644
makes a lot more sense, don't you think?

Actually, just drop this whole attribute.  Random "turn on debugging"
config files do not even belong in sysfs.  We have a kernel-wide
infrastructure for all of that already, no single driver, or tiny
subsystem, should have their own custom way of doing this.

thanks,

greg k-h

Re: linux-next: build failure after merge of the staging.current tree

[Greg KH]

On Thu, Dec 14, 2017 at 05:00:33PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging.current tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate':
> drivers/staging/android/ion/ion_cma_heap.c:38:14: error: 
> 'CONFIG_CMA_ALIGNMENT' undeclared (first use in this function)
>   if (align > CONFIG_CMA_ALIGNMENT)
>   ^
> 
> Caused by commit
> 
>   d98e6dbf42f7 ("staging: ion: Fix ion_cma_heap allocations")
> 
> CONFIG_CMA_ALIGNMENT (and CONFIG_DMA_CMA) is not set for this build.
> 
> I have reverted that commit for today.

Thanks, and sorry about that.  John is working on a fix...

greg k-h

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

[Greg KH]

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote:
> In trying to add support for drm_hwcomposer to HiKey,
> I've needed to utilize the ION CMA heap, and I've noticed
> problems with allocations on newer kernels failing.
> 
> It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
> the ion_cma_heap code was modified to use the CMA API, but
> kept the arguments as buffer lengths rather then number of pages.
> 
> This results in errors as we don't have enough pages in CMA to
> satisfy the exaggerated requests.
> 
> This patch converts the ion_cma_heap CMA API usage to properly
> request pages.
> 
> It also fixes a minor issue in the allocation where in the error
> path, the cma_release is called with the buffer->size value which
> hasn't yet been set.
> 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: Benjamin Gaignard 
> Cc: Archit Taneja 
> Cc: Greg KH 
> Cc: Daniel Vetter 
> Cc: Dmitry Shmidt 
> Cc: Todd Kjos 
> Cc: Amit Pundir 
> Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> Acked-by: Laura Abbott 
> Signed-off-by: John Stultz 
> ---
> v2: Fix build errors when CONFIG_CMA_ALIGNMENT isn't defined

Wait, why would CONFIG_CMA_ALIGNMENT not be defined if we are using the
cma code?  Is that a Kconfig issue somehow?

thanks,

greg k-h

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

[Greg KH]

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote:
> In trying to add support for drm_hwcomposer to HiKey,
> I've needed to utilize the ION CMA heap, and I've noticed
> problems with allocations on newer kernels failing.
> 
> It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
> the ion_cma_heap code was modified to use the CMA API, but
> kept the arguments as buffer lengths rather then number of pages.
> 
> This results in errors as we don't have enough pages in CMA to
> satisfy the exaggerated requests.
> 
> This patch converts the ion_cma_heap CMA API usage to properly
> request pages.
> 
> It also fixes a minor issue in the allocation where in the error
> path, the cma_release is called with the buffer->size value which
> hasn't yet been set.
> 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: Benjamin Gaignard 
> Cc: Archit Taneja 
> Cc: Greg KH 
> Cc: Daniel Vetter 
> Cc: Dmitry Shmidt 
> Cc: Todd Kjos 
> Cc: Amit Pundir 
> Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> Acked-by: Laura Abbott 
> Signed-off-by: John Stultz 
> ---
> v2: Fix build errors when CONFIG_CMA_ALIGNMENT isn't defined

Wait, why would CONFIG_CMA_ALIGNMENT not be defined if we are using the
cma code?  Is that a Kconfig issue somehow?

thanks,

greg k-h

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

[Greg KH]

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote:
> In trying to add support for drm_hwcomposer to HiKey,
> I've needed to utilize the ION CMA heap, and I've noticed
> problems with allocations on newer kernels failing.
> 
> It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
> the ion_cma_heap code was modified to use the CMA API, but
> kept the arguments as buffer lengths rather then number of pages.
> 
> This results in errors as we don't have enough pages in CMA to
> satisfy the exaggerated requests.
> 
> This patch converts the ion_cma_heap CMA API usage to properly
> request pages.
> 
> It also fixes a minor issue in the allocation where in the error
> path, the cma_release is called with the buffer->size value which
> hasn't yet been set.
> 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: Benjamin Gaignard 
> Cc: Archit Taneja 
> Cc: Greg KH 
> Cc: Daniel Vetter 
> Cc: Dmitry Shmidt 
> Cc: Todd Kjos 
> Cc: Amit Pundir 
> Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> Acked-by: Laura Abbott 
> Signed-off-by: John Stultz 
> ---
> v2: Fix build errors when CONFIG_CMA_ALIGNMENT isn't defined

As v1 is already in my tree, can you send me the diff so I can just
apply that instead of me having to revert the original and then add this
one?

thanks,

greg k-h

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

[Greg KH]

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote:
> In trying to add support for drm_hwcomposer to HiKey,
> I've needed to utilize the ION CMA heap, and I've noticed
> problems with allocations on newer kernels failing.
> 
> It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
> the ion_cma_heap code was modified to use the CMA API, but
> kept the arguments as buffer lengths rather then number of pages.
> 
> This results in errors as we don't have enough pages in CMA to
> satisfy the exaggerated requests.
> 
> This patch converts the ion_cma_heap CMA API usage to properly
> request pages.
> 
> It also fixes a minor issue in the allocation where in the error
> path, the cma_release is called with the buffer->size value which
> hasn't yet been set.
> 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: Benjamin Gaignard 
> Cc: Archit Taneja 
> Cc: Greg KH 
> Cc: Daniel Vetter 
> Cc: Dmitry Shmidt 
> Cc: Todd Kjos 
> Cc: Amit Pundir 
> Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> Acked-by: Laura Abbott 
> Signed-off-by: John Stultz 
> ---
> v2: Fix build errors when CONFIG_CMA_ALIGNMENT isn't defined

As v1 is already in my tree, can you send me the diff so I can just
apply that instead of me having to revert the original and then add this
one?

thanks,

greg k-h

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

[Zhouyi Zhou]

Hi,
In function __ext4_grp_locked_error,   __save_error_info(sb, function, line)
is called to save error info in super block block, but does not sync
that information
to disk to info the subsequence fsck after reboot. The reason, I guess
maybe it is
in locked state.
My question is why not make a call ext4_commit_super(sb, 1) after
ext4_unlock_group(sb, grp) and  ext4_handle_error(sb), so that subsequence fsck
after reboot is sure to be well informed.
   Forgive my naiveness.
Thanks a lot

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

[Zhouyi Zhou]

Hi,
In function __ext4_grp_locked_error,   __save_error_info(sb, function, line)
is called to save error info in super block block, but does not sync
that information
to disk to info the subsequence fsck after reboot. The reason, I guess
maybe it is
in locked state.
My question is why not make a call ext4_commit_super(sb, 1) after
ext4_unlock_group(sb, grp) and  ext4_handle_error(sb), so that subsequence fsck
after reboot is sure to be well informed.
   Forgive my naiveness.
Thanks a lot

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Wed 13-12-17 15:19:00, Kees Cook wrote:
> On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis  wrote:
> > Hi!
> >> You selected stupid name for a flag. Everyone and their dog agrees
> >> with that. There's even consensus on better name (and everyone agrees
> >> it is better than .._SAFE). Of course, we could have debate if it is
> >> NOREPLACE or NOREMOVE or ... and that would be bikeshed. This was just
> >> poor naming on your part.
> >
> > Well while everybody agrees that the name is so bad that basically
> > anything else would be better, there does not seem to be consensus on
> > which one to pick. I do understand that this frustrating and fruitless.
> 
> Based on the earlier threads where I tried to end the bikeshedding, it
> seemed like MAP_FIXED_NOREPLACE was the least bad option.
> 
> > So what do we do now, roll a dice to choose new name?
> >
> > Or do we ask BFDL[1] to choose the name?
> 
> I'd like to hear feedback from Michael Kerrisk, as he's had to deal
> with these kinds of choices in the past. I'm fine to ask Linus too. I
> just want to get past the name since the feature is quite valuable.
> 
> And if Michal doesn't want to touch this patch any more, I'm happy to
> do the search/replace/resend. :P

I think Andrew can do the s@MAP_FIXED_SAFE@MAP_$FOO@ when adding the
patch to the mmotm tree. The reason why I refuse to repost is that a)
functionality doesn't really need a further rework (at least not based
on the review feedback) and b) I do not really see any large consensus
here. People claim to like this or that more but nobody (except of you
Kees) was willing to put their name under their preference in a form of
Acked-by. And that worries me, because generating "better" names sounds
too easy to allow a forward progress.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Wed 13-12-17 15:19:00, Kees Cook wrote:
> On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis  wrote:
> > Hi!
> >> You selected stupid name for a flag. Everyone and their dog agrees
> >> with that. There's even consensus on better name (and everyone agrees
> >> it is better than .._SAFE). Of course, we could have debate if it is
> >> NOREPLACE or NOREMOVE or ... and that would be bikeshed. This was just
> >> poor naming on your part.
> >
> > Well while everybody agrees that the name is so bad that basically
> > anything else would be better, there does not seem to be consensus on
> > which one to pick. I do understand that this frustrating and fruitless.
> 
> Based on the earlier threads where I tried to end the bikeshedding, it
> seemed like MAP_FIXED_NOREPLACE was the least bad option.
> 
> > So what do we do now, roll a dice to choose new name?
> >
> > Or do we ask BFDL[1] to choose the name?
> 
> I'd like to hear feedback from Michael Kerrisk, as he's had to deal
> with these kinds of choices in the past. I'm fine to ask Linus too. I
> just want to get past the name since the feature is quite valuable.
> 
> And if Michal doesn't want to touch this patch any more, I'm happy to
> do the search/replace/resend. :P

I think Andrew can do the s@MAP_FIXED_SAFE@MAP_$FOO@ when adding the
patch to the mmotm tree. The reason why I refuse to repost is that a)
functionality doesn't really need a further rework (at least not based
on the review feedback) and b) I do not really see any large consensus
here. People claim to like this or that more but nobody (except of you
Kees) was willing to put their name under their preference in a form of
Acked-by. And that worries me, because generating "better" names sounds
too easy to allow a forward progress.
-- 
Michal Hocko
SUSE Labs

linux-next: Tree for Dec 14

[Stephen Rothwell]

Hi all,

Changes since 20171213:

The staging.current tree gained a build failure for which I reverted
a commit.

The clk tree lost its build failures.

The bpf-next tree lost its build failure.

The drm tree gained a conflict against the drm-misc-fixes tree.

Non-merge commits (relative to Linus' tree): 4332
 4784 files changed, 149624 insertions(+), 140886 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d39a01eff9af Merge tag 'platform-drivers-x86-v4.15-3' of 
git://git.infradead.org/linux-platform-drivers-x86)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (cfe17c9bbe6a kbuild: move cc-option and 
cc-disable-warning after incl. arch Makefile)
Merging arc-current/for-curr (799ab4a2c85b arc: do not use __print_symbol())
Merging arm-current/fixes (3aaf33bebda8 ARM: avoid faulting on qemu)
Merging m68k-current/for-linus (5e387199c17c m68k/defconfig: Update defconfigs 
for v4.14-rc7)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d81041820873 powerpc/xmon: Don't print hashed 
pointers in xmon)
Merging sparc/master (a0908a1b7d68 Merge branch 'akpm' (patches from Andrew))
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c009cb842fcc skge: remove redundunt free_irq under spinlock)
Merging bpf/master (9147efcbe0b7 bpf: add schedule points to map alloc/free)
Merging ipsec/master (d2950278d2d0 xfrm: put policies when reusing pcpu xdst 
entry)
Merging netfilter/master (d6da83813fb3 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (a41886f56b7b Merge tag 
'iwlwifi-for-kalle-2017-12-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (4564b187c163 nl80211: fix nl80211_send_iface() error 
paths)
Merging sound-current/for-linus (2b4584d00a6b ALSA: hda - Add vendor id for 
Cannonlake HDMI codec)
Merging pci-current/for-linus (0c31f1d7be1b PCI: rcar: Fix use-after-free in 
probe error path)
Merging driver-core.current/driver-core-linus (50c4c4e268a2 Linux 4.15-rc3)
Merging tty.current/tty-linus (50c4c4e268a2 Linux 4.15-rc3)
Merging usb.current/usb-linus (48a4ff1c7bb5 USB: core: prevent malicious 
bNumInterfaces overflow)
Merging usb-gadget-fixes/fixes (9dbe416b656b Revert "usb: gadget: allow to 
enable legacy drivers without USB_ETH")
Merging usb-serial-fixes/usb-linus (762ff4678e89 USB: serial: usb_debug: add 
new USB device id)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (521e84ab2507 phy: rcar-gen3-usb2: select USB_COMMON)
Merging staging.current/staging-linus (d98e6dbf42f7 staging: ion: Fix 
ion_cma_heap allocations)
Merging char-misc.current/char-misc-linus (50c4c4e268a2 Linux 4.15-rc3)
Merging input-current/for-linus (4c83c071b784 Input: elants_i2c - do not 
clobber interrupt trigger on x86)

linux-next: Tree for Dec 14

[Stephen Rothwell]

Hi all,

Changes since 20171213:

The staging.current tree gained a build failure for which I reverted
a commit.

The clk tree lost its build failures.

The bpf-next tree lost its build failure.

The drm tree gained a conflict against the drm-misc-fixes tree.

Non-merge commits (relative to Linus' tree): 4332
 4784 files changed, 149624 insertions(+), 140886 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d39a01eff9af Merge tag 'platform-drivers-x86-v4.15-3' of 
git://git.infradead.org/linux-platform-drivers-x86)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (cfe17c9bbe6a kbuild: move cc-option and 
cc-disable-warning after incl. arch Makefile)
Merging arc-current/for-curr (799ab4a2c85b arc: do not use __print_symbol())
Merging arm-current/fixes (3aaf33bebda8 ARM: avoid faulting on qemu)
Merging m68k-current/for-linus (5e387199c17c m68k/defconfig: Update defconfigs 
for v4.14-rc7)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d81041820873 powerpc/xmon: Don't print hashed 
pointers in xmon)
Merging sparc/master (a0908a1b7d68 Merge branch 'akpm' (patches from Andrew))
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c009cb842fcc skge: remove redundunt free_irq under spinlock)
Merging bpf/master (9147efcbe0b7 bpf: add schedule points to map alloc/free)
Merging ipsec/master (d2950278d2d0 xfrm: put policies when reusing pcpu xdst 
entry)
Merging netfilter/master (d6da83813fb3 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (a41886f56b7b Merge tag 
'iwlwifi-for-kalle-2017-12-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (4564b187c163 nl80211: fix nl80211_send_iface() error 
paths)
Merging sound-current/for-linus (2b4584d00a6b ALSA: hda - Add vendor id for 
Cannonlake HDMI codec)
Merging pci-current/for-linus (0c31f1d7be1b PCI: rcar: Fix use-after-free in 
probe error path)
Merging driver-core.current/driver-core-linus (50c4c4e268a2 Linux 4.15-rc3)
Merging tty.current/tty-linus (50c4c4e268a2 Linux 4.15-rc3)
Merging usb.current/usb-linus (48a4ff1c7bb5 USB: core: prevent malicious 
bNumInterfaces overflow)
Merging usb-gadget-fixes/fixes (9dbe416b656b Revert "usb: gadget: allow to 
enable legacy drivers without USB_ETH")
Merging usb-serial-fixes/usb-linus (762ff4678e89 USB: serial: usb_debug: add 
new USB device id)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (521e84ab2507 phy: rcar-gen3-usb2: select USB_COMMON)
Merging staging.current/staging-linus (d98e6dbf42f7 staging: ion: Fix 
ion_cma_heap allocations)
Merging char-misc.current/char-misc-linus (50c4c4e268a2 Linux 4.15-rc3)
Merging input-current/for-linus (4c83c071b784 Input: elants_i2c - do not 
clobber interrupt trigger on x86)

Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support

[Priit Laes]

On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here is an attempt at supporting the LVDS output in our DRM driver. This
> has been tested on the A83T (with DE2), but since everything is basically
> in the TCON, it should also be usable on the older SoCs with minor
> modifications.

I managed to get the single-channel LVDS working on an A10 tablet after
doing those minor modifications (although, the colours are off a bit).
So in general this series looks good :)

> 
> This was the occasion to refactor a bunch of things. The most notable ones
> would be the documentation, and split of the UI layers in the mixer code,
> and the switch to kfifo for our endpoint parsing code in the driver that
> fixes an issue introduced by the switch to BFS.
> 
> Let me know what you think,
> Maxime
> 
> Changes from v3:
>   - Collect the tags
>   - Use SPDX headers when possible
>   - Added the new mixer configuration options
>   - Changed the LVDS clock for lvds-alt instead of lvds-pll
>   - Removed the MIPI PLL from the A31s
>   - Changed the LVDS_ANA0 macros name to reflect the generation they were
> introduced in, and added a comment to mention the changes needed to
> support the older SoCs
> 
> Changes from v2:
>   - Move the module clock rate to the mixer structure
>   - Adjusted the simple-panel documentation for power-supply
>   - Changed the compatible for the first A83t mixer to mixer 0
>   - Rebased on top of current drm-misc
>   - Split out the A83t bindings in its separate patch
> 
> Changes from v1:
>   - Added a fix for the error path handling in the TCON
>   - Enable the TCON by default
>   - Removed the patch that changes the channels offset but kept most of the
> modifications as a cleanup
>   - Deal with the LVDS clock being able to have another PLL parent on some
> SoCs
>   - Renamed the TCON compatible to TCON-TV, following the convention used
> on newer SoCs
>   - Removed the hardcoded timings
>   - Moved LVDS enable quirks to a separate function
>   - Used clock indices define in the DT
>   - Removed the hardcoded clock rate in the DT and moved it to the driver
>   - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent
>   - Added the various tags collected
>   - Rebased on top of 4.15
> 
> Maxime Ripard (15):
>   dt-bindings: panel: lvds: Document power-supply property
>   drm/panel: lvds: Add support for the power-supply property
>   dt-bindings: display: sun4i-drm: Add LVDS properties
>   dt-bindings: display: sun4i-drm: Add A83T pipeline
>   drm/sun4i: Fix error path handling
>   drm/sun4i: Force the mixer rate at 150MHz
>   drm/sun4i: Create minimal multipliers and dividers
>   drm/sun4i: Add LVDS support
>   drm/sun4i: Add A83T support
>   ARM: dts: sun8i: a83t: Add display pipeline
>   ARM: dts: sun8i: a83t: Enable the PWM
>   ARM: dts: sun8i: a83t: Add LVDS pins group
>   ARM: dts: sun8i: a83t: Add the PWM pin group
>   ARM: dts: sun8i: a711: Reinstate the PMIC compatible
>   ARM: dts: sun8i: a711: Enable the LCD
> 
>  Documentation/devicetree/bindings/display/panel/panel-common.txt |   6 ++-
>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   |   1 +-
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt |   2 +-
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt|  12 +++-
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts|  62 
> ++-
>  arch/arm/boot/dts/sun8i-a83t.dtsi|  99 
> -
>  drivers/gpu/drm/panel/panel-lvds.c   |  23 
> +++-
>  drivers/gpu/drm/sun4i/Makefile   |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_dotclock.c   |  10 ++-
>  drivers/gpu/drm/sun4i/sun4i_drv.c|   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c   | 177 
> +++-
>  drivers/gpu/drm/sun4i/sun4i_lvds.h   |  18 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 251 
> +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h   |  31 
> +-
>  drivers/gpu/drm/sun4i/sun8i_mixer.c  |  20 
> ++-
>  drivers/gpu/drm/sun4i/sun8i_mixer.h  |   3 +-
>  16 files changed, 710 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
> 
> base-commit: 3b71239181e5429702387666f1ac70a9e6856cce
> -- 
> git-series 0.9.1

Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support

[Priit Laes]

On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here is an attempt at supporting the LVDS output in our DRM driver. This
> has been tested on the A83T (with DE2), but since everything is basically
> in the TCON, it should also be usable on the older SoCs with minor
> modifications.

I managed to get the single-channel LVDS working on an A10 tablet after
doing those minor modifications (although, the colours are off a bit).
So in general this series looks good :)

> 
> This was the occasion to refactor a bunch of things. The most notable ones
> would be the documentation, and split of the UI layers in the mixer code,
> and the switch to kfifo for our endpoint parsing code in the driver that
> fixes an issue introduced by the switch to BFS.
> 
> Let me know what you think,
> Maxime
> 
> Changes from v3:
>   - Collect the tags
>   - Use SPDX headers when possible
>   - Added the new mixer configuration options
>   - Changed the LVDS clock for lvds-alt instead of lvds-pll
>   - Removed the MIPI PLL from the A31s
>   - Changed the LVDS_ANA0 macros name to reflect the generation they were
> introduced in, and added a comment to mention the changes needed to
> support the older SoCs
> 
> Changes from v2:
>   - Move the module clock rate to the mixer structure
>   - Adjusted the simple-panel documentation for power-supply
>   - Changed the compatible for the first A83t mixer to mixer 0
>   - Rebased on top of current drm-misc
>   - Split out the A83t bindings in its separate patch
> 
> Changes from v1:
>   - Added a fix for the error path handling in the TCON
>   - Enable the TCON by default
>   - Removed the patch that changes the channels offset but kept most of the
> modifications as a cleanup
>   - Deal with the LVDS clock being able to have another PLL parent on some
> SoCs
>   - Renamed the TCON compatible to TCON-TV, following the convention used
> on newer SoCs
>   - Removed the hardcoded timings
>   - Moved LVDS enable quirks to a separate function
>   - Used clock indices define in the DT
>   - Removed the hardcoded clock rate in the DT and moved it to the driver
>   - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent
>   - Added the various tags collected
>   - Rebased on top of 4.15
> 
> Maxime Ripard (15):
>   dt-bindings: panel: lvds: Document power-supply property
>   drm/panel: lvds: Add support for the power-supply property
>   dt-bindings: display: sun4i-drm: Add LVDS properties
>   dt-bindings: display: sun4i-drm: Add A83T pipeline
>   drm/sun4i: Fix error path handling
>   drm/sun4i: Force the mixer rate at 150MHz
>   drm/sun4i: Create minimal multipliers and dividers
>   drm/sun4i: Add LVDS support
>   drm/sun4i: Add A83T support
>   ARM: dts: sun8i: a83t: Add display pipeline
>   ARM: dts: sun8i: a83t: Enable the PWM
>   ARM: dts: sun8i: a83t: Add LVDS pins group
>   ARM: dts: sun8i: a83t: Add the PWM pin group
>   ARM: dts: sun8i: a711: Reinstate the PMIC compatible
>   ARM: dts: sun8i: a711: Enable the LCD
> 
>  Documentation/devicetree/bindings/display/panel/panel-common.txt |   6 ++-
>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   |   1 +-
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt |   2 +-
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt|  12 +++-
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts|  62 
> ++-
>  arch/arm/boot/dts/sun8i-a83t.dtsi|  99 
> -
>  drivers/gpu/drm/panel/panel-lvds.c   |  23 
> +++-
>  drivers/gpu/drm/sun4i/Makefile   |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_dotclock.c   |  10 ++-
>  drivers/gpu/drm/sun4i/sun4i_drv.c|   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c   | 177 
> +++-
>  drivers/gpu/drm/sun4i/sun4i_lvds.h   |  18 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 251 
> +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h   |  31 
> +-
>  drivers/gpu/drm/sun4i/sun8i_mixer.c  |  20 
> ++-
>  drivers/gpu/drm/sun4i/sun8i_mixer.h  |   3 +-
>  16 files changed, 710 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
> 
> base-commit: 3b71239181e5429702387666f1ac70a9e6856cce
> -- 
> git-series 0.9.1

Re: [PATCH v2] staging: comedi: ni_*: Fix style warnings.

[Joe Perches]

On Thu, 2017-12-14 at 00:27 -0600, Aniruddha Shastri wrote:
> Three of these warnings are now line-too-long warnings. I think these 
> warnings are preferable to the ones listed below. The longest line 
> is only 87 chars wide, which is reasonable.
[]
> diff --git a/drivers/staging/comedi/drivers/ni_670x.c 
> b/drivers/staging/comedi/drivers/ni_670x.c
[]
> @@ -209,7 +209,7 @@ static int ni_670x_auto_attach(struct comedi_device *dev,
>   const struct comedi_lrange **range_table_list;
>  
>   range_table_list = kmalloc_array(32,
> -  sizeof(struct comedi_lrange *),
> +  sizeof(const struct 
> comedi_lrange *),

Adding const to a sizeof is unnecessary

Re: [PATCH v2] staging: comedi: ni_*: Fix style warnings.

[Joe Perches]

On Thu, 2017-12-14 at 00:27 -0600, Aniruddha Shastri wrote:
> Three of these warnings are now line-too-long warnings. I think these 
> warnings are preferable to the ones listed below. The longest line 
> is only 87 chars wide, which is reasonable.
[]
> diff --git a/drivers/staging/comedi/drivers/ni_670x.c 
> b/drivers/staging/comedi/drivers/ni_670x.c
[]
> @@ -209,7 +209,7 @@ static int ni_670x_auto_attach(struct comedi_device *dev,
>   const struct comedi_lrange **range_table_list;
>  
>   range_table_list = kmalloc_array(32,
> -  sizeof(struct comedi_lrange *),
> +  sizeof(const struct 
> comedi_lrange *),

Adding const to a sizeof is unnecessary

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

[Masami Hiramatsu]

On Wed, 13 Dec 2017 13:57:45 -0500
Josef Bacik  wrote:

> On Wed, Dec 13, 2017 at 10:07:32AM -0800, Darrick J. Wong wrote:
> > On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote:
> > > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote:
> > > > On Mon, Dec 11, 2017 at 11:36:45AM -0500, Josef Bacik wrote:
> > > > > This is the same as v8, just rebased onto the bpf tree.
> > > > > 
> > > > > v8->v9:
> > > > > - rebased onto the bpf tree.
> > > > > 
> > > > > v7->v8:
> > > > > - removed the _ASM_KPROBE_ERROR_INJECT since it was not needed.
> > > > > 
> > > > > v6->v7:
> > > > > - moved the opt-in macro to bpf.h out of kprobes.h.
> > > > > 
> > > > > v5->v6:
> > > > > - add BPF_ALLOW_ERROR_INJECTION() tagging for functions that will 
> > > > > support this
> > > > >   feature.  This way only functions that opt-in will be allowed to be
> > > > >   overridden.
> > > > > - added a btrfs patch to allow error injection for open_ctree() so 
> > > > > that the bpf
> > > > >   sample actually works.
> > > > > 
> > > > > v4->v5:
> > > > > - disallow kprobe_override programs from being put in the prog map 
> > > > > array so we
> > > > >   don't tail call into something we didn't check.  This allows us to 
> > > > > make the
> > > > >   normal path still fast without a bunch of percpu operations.
> > > > > 
> > > > > v3->v4:
> > > > > - fix a build error found by kbuild test bot (I didn't wait long 
> > > > > enough
> > > > >   apparently.)
> > > > > - Added a warning message as per Daniels suggestion.
> > > > > 
> > > > > v2->v3:
> > > > > - added a ->kprobe_override flag to bpf_prog.
> > > > > - added some sanity checks to disallow attaching bpf progs that have
> > > > >   ->kprobe_override set that aren't for ftrace kprobes.
> > > > > - added the trace_kprobe_ftrace helper to check if the 
> > > > > trace_event_call is a
> > > > >   ftrace kprobe.
> > > > > - renamed bpf_kprobe_state to bpf_kprobe_override, fixed it so we 
> > > > > only read this
> > > > >   value in the kprobe path, and thus only write to it if we're 
> > > > > overriding or
> > > > >   clearing the override.
> > > > > 
> > > > > v1->v2:
> > > > > - moved things around to make sure that bpf_override_return could 
> > > > > really only be
> > > > >   used for an ftrace kprobe.
> > > > > - killed the special return values from trace_call_bpf.
> > > > > - renamed pc_modified to bpf_kprobe_state so bpf_override_return 
> > > > > could tell if
> > > > >   it was being called from an ftrace kprobe context.
> > > > > - reworked the logic in kprobe_perf_func to take advantage of 
> > > > > bpf_kprobe_state.
> > > > > - updated the test as per Alexei's review.
> > > > > 
> > > > > - Original message -
> > > > > 
> > > > > A lot of our error paths are not well tested because we have no good 
> > > > > way of
> > > > > injecting errors generically.  Some subystems (block, memory) have 
> > > > > ways to
> > > > > inject errors, but they are random so it's hard to get reproduceable 
> > > > > results.
> > > > > 
> > > > > With BPF we can add determinism to our error injection.  We can use 
> > > > > kprobes and
> > > > > other things to verify we are injecting errors at the exact case we 
> > > > > are trying
> > > > > to test.  This patch gives us the tool to actual do the error 
> > > > > injection part.
> > > > > It is very simple, we just set the return value of the pt_regs we're 
> > > > > given to
> > > > > whatever we provide, and then override the PC with a dummy function 
> > > > > that simply
> > > > > returns.
> > > > 
> > > > Heh, this looks cool.  I decided to try it to see what happens, and saw
> > > > a bunch of dmesg pasted in below.  Is that supposed to happen?  Or am I
> > > > the only fs developer still running with lockdep enabled? :)
> > > > 
> > > > It looks like bpf_override_return has some sort of side effect such that
> > > > we get the splat, since commenting it out makes the symptom go away.
> > > > 
> > > > 
> > > > 
> > > > --D
> > > > 
> > > > [ 1847.769183] BTRFS error (device (null)): open_ctree failed
> > > > [ 1847.770130] BUG: sleeping function called from invalid context at 
> > > > /storage/home/djwong/cdev/work/linux-xfs/kernel/locking/rwsem.c:69
> > > > [ 1847.771976] in_atomic(): 1, irqs_disabled(): 0, pid: 1524, name: 
> > > > mount
> > > > [ 1847.773016] 1 lock held by mount/1524:
> > > > [ 1847.773530]  #0:  (>s_umount_key#34/1){+.+.}, at: 
> > > > [<653a9bb4>] sget_userns+0x302/0x4f0
> > > > [ 1847.774731] Preemption disabled at:
> > > > [ 1847.774735] [<  (null)>]   (null)
> > > > [ 1847.777009] CPU: 2 PID: 1524 Comm: mount Tainted: GW
> > > > 4.15.0-rc3-xfsx #3
> > > > [ 1847.778800] Call Trace:
> > > > [ 1847.779047]  dump_stack+0x7c/0xbe
> > > > [ 1847.779361]  ___might_sleep+0x1f7/0x260
> > > > [ 1847.779720]  down_write+0x29/0xb0
> > > > [ 1847.780046]  unregister_shrinker+0x15/0x70
> > > > [ 1847.780427]  

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

[Masami Hiramatsu]

On Wed, 13 Dec 2017 13:57:45 -0500
Josef Bacik  wrote:

> On Wed, Dec 13, 2017 at 10:07:32AM -0800, Darrick J. Wong wrote:
> > On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote:
> > > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote:
> > > > On Mon, Dec 11, 2017 at 11:36:45AM -0500, Josef Bacik wrote:
> > > > > This is the same as v8, just rebased onto the bpf tree.
> > > > > 
> > > > > v8->v9:
> > > > > - rebased onto the bpf tree.
> > > > > 
> > > > > v7->v8:
> > > > > - removed the _ASM_KPROBE_ERROR_INJECT since it was not needed.
> > > > > 
> > > > > v6->v7:
> > > > > - moved the opt-in macro to bpf.h out of kprobes.h.
> > > > > 
> > > > > v5->v6:
> > > > > - add BPF_ALLOW_ERROR_INJECTION() tagging for functions that will 
> > > > > support this
> > > > >   feature.  This way only functions that opt-in will be allowed to be
> > > > >   overridden.
> > > > > - added a btrfs patch to allow error injection for open_ctree() so 
> > > > > that the bpf
> > > > >   sample actually works.
> > > > > 
> > > > > v4->v5:
> > > > > - disallow kprobe_override programs from being put in the prog map 
> > > > > array so we
> > > > >   don't tail call into something we didn't check.  This allows us to 
> > > > > make the
> > > > >   normal path still fast without a bunch of percpu operations.
> > > > > 
> > > > > v3->v4:
> > > > > - fix a build error found by kbuild test bot (I didn't wait long 
> > > > > enough
> > > > >   apparently.)
> > > > > - Added a warning message as per Daniels suggestion.
> > > > > 
> > > > > v2->v3:
> > > > > - added a ->kprobe_override flag to bpf_prog.
> > > > > - added some sanity checks to disallow attaching bpf progs that have
> > > > >   ->kprobe_override set that aren't for ftrace kprobes.
> > > > > - added the trace_kprobe_ftrace helper to check if the 
> > > > > trace_event_call is a
> > > > >   ftrace kprobe.
> > > > > - renamed bpf_kprobe_state to bpf_kprobe_override, fixed it so we 
> > > > > only read this
> > > > >   value in the kprobe path, and thus only write to it if we're 
> > > > > overriding or
> > > > >   clearing the override.
> > > > > 
> > > > > v1->v2:
> > > > > - moved things around to make sure that bpf_override_return could 
> > > > > really only be
> > > > >   used for an ftrace kprobe.
> > > > > - killed the special return values from trace_call_bpf.
> > > > > - renamed pc_modified to bpf_kprobe_state so bpf_override_return 
> > > > > could tell if
> > > > >   it was being called from an ftrace kprobe context.
> > > > > - reworked the logic in kprobe_perf_func to take advantage of 
> > > > > bpf_kprobe_state.
> > > > > - updated the test as per Alexei's review.
> > > > > 
> > > > > - Original message -
> > > > > 
> > > > > A lot of our error paths are not well tested because we have no good 
> > > > > way of
> > > > > injecting errors generically.  Some subystems (block, memory) have 
> > > > > ways to
> > > > > inject errors, but they are random so it's hard to get reproduceable 
> > > > > results.
> > > > > 
> > > > > With BPF we can add determinism to our error injection.  We can use 
> > > > > kprobes and
> > > > > other things to verify we are injecting errors at the exact case we 
> > > > > are trying
> > > > > to test.  This patch gives us the tool to actual do the error 
> > > > > injection part.
> > > > > It is very simple, we just set the return value of the pt_regs we're 
> > > > > given to
> > > > > whatever we provide, and then override the PC with a dummy function 
> > > > > that simply
> > > > > returns.
> > > > 
> > > > Heh, this looks cool.  I decided to try it to see what happens, and saw
> > > > a bunch of dmesg pasted in below.  Is that supposed to happen?  Or am I
> > > > the only fs developer still running with lockdep enabled? :)
> > > > 
> > > > It looks like bpf_override_return has some sort of side effect such that
> > > > we get the splat, since commenting it out makes the symptom go away.
> > > > 
> > > > 
> > > > 
> > > > --D
> > > > 
> > > > [ 1847.769183] BTRFS error (device (null)): open_ctree failed
> > > > [ 1847.770130] BUG: sleeping function called from invalid context at 
> > > > /storage/home/djwong/cdev/work/linux-xfs/kernel/locking/rwsem.c:69
> > > > [ 1847.771976] in_atomic(): 1, irqs_disabled(): 0, pid: 1524, name: 
> > > > mount
> > > > [ 1847.773016] 1 lock held by mount/1524:
> > > > [ 1847.773530]  #0:  (>s_umount_key#34/1){+.+.}, at: 
> > > > [<653a9bb4>] sget_userns+0x302/0x4f0
> > > > [ 1847.774731] Preemption disabled at:
> > > > [ 1847.774735] [<  (null)>]   (null)
> > > > [ 1847.777009] CPU: 2 PID: 1524 Comm: mount Tainted: GW
> > > > 4.15.0-rc3-xfsx #3
> > > > [ 1847.778800] Call Trace:
> > > > [ 1847.779047]  dump_stack+0x7c/0xbe
> > > > [ 1847.779361]  ___might_sleep+0x1f7/0x260
> > > > [ 1847.779720]  down_write+0x29/0xb0
> > > > [ 1847.780046]  unregister_shrinker+0x15/0x70
> > > > [ 1847.780427]  deactivate_locked_super+0x2e/0x60
> > > > [ 

Re: [PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

[Lan Tianyu]

On 2017年12月13日 20:20, Paolo Bonzini wrote:
> On 13/12/2017 05:17, Lan Tianyu wrote:
>> Reported by syzkaller:
>> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 
>> x86_emulate_insn+0x557/0x15f0 [kvm]
>> Modules linked in: kvm_intel kvm [last unloaded: kvm]
>> CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB   W
>> 4.15.0-rc2-next-20171208+ #32
>> Hardware name: Intel Corporation S1200SP/S1200SP, BIOS 
>> S1200SP.86B.01.03.0006.040720161253 04/07/2016
>> RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
>> RSP: 0018:8807234476d0 EFLAGS: 00010282
>> RAX:  RBX: 88072d0237a0 RCX: a0065c4d
>> RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
>> RBP: 880723447728 R08: 88072d02 R09: a008d240
>> R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
>> R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
>> FS:  7f8a68666700() GS:88080220() 
>> knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
>> Call Trace:
>>  x86_emulate_instruction+0x3bc/0xb70 [kvm]
>>  ? reexecute_instruction.part.162+0x130/0x130 [kvm]
>>  vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
>>  ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
>>  ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
>>  ? wait_lapic_expire+0x25/0x270 [kvm]
>>  vcpu_enter_guest+0x720/0x1ef0 [kvm]
>>  ...
>>
>> When cs.l is set, vcpu should run in the 64 bit paging mode.
>> Current kvm set_sregs function doesn't have such check when userspace
>> inputs sreg values. This will lead unexpected behavior. This patch
>> is to add such check.
>>
>> Suggested-by: Paolo Bonzini 
>> Reported-by: Dmitry Vyukov 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Dmitry Vyukov 
>> Cc: Jim Mattson 
>> Signed-off-by: Tianyu Lan 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/x86.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 1e1e617..07d6d6c 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -7485,6 +7485,18 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16 
>> tss_selector, int idt_index,
>>  }
>>  EXPORT_SYMBOL_GPL(kvm_task_switch);
>>  
>> +int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
>> +{
>> +/* When cs.l is set, vcpu should run in 64-bit mode */
>> +if (sregs->cs.l)
>> +if (!((sregs->cr0 & X86_CR0_PG_BIT) &&
>> +  (sregs->cr4 & X86_CR4_PAE_BIT) &&
>> +  (sregs->efer & EFER_LME)))
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>>  int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>>struct kvm_sregs *sregs)
>>  {
>> @@ -7497,6 +7509,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu 
>> *vcpu,
>>  (sregs->cr4 & X86_CR4_OSXSAVE))
>>  return -EINVAL;
>>  
>> +if (kvm_valid_sregs(vcpu, sregs))
>> +return -EINVAL;
>> +
>>  apic_base_msr.data = sregs->apic_base;
>>  apic_base_msr.host_initiated = true;
>>  if (kvm_set_apic_base(vcpu, _base_msr))
>>
> 
> Thanks, this is the right direction.  However, there are many more
> checks that are missing and can trigger more unexpected behavior.

Yes, we may add these checks step by step.

>  In
> particular:
> 
> - if EFER.LME=1 and CR0.PG=1, EFER.LMA and CR4.PAE must be 1
> 
> - otherwise, EFER.LMA and CS.L must be 0

I will add these in the new version. Thanks.

-- 
Best regards
Tianyu Lan

Re: [PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

[Lan Tianyu]

On 2017年12月13日 20:20, Paolo Bonzini wrote:
> On 13/12/2017 05:17, Lan Tianyu wrote:
>> Reported by syzkaller:
>> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 
>> x86_emulate_insn+0x557/0x15f0 [kvm]
>> Modules linked in: kvm_intel kvm [last unloaded: kvm]
>> CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB   W
>> 4.15.0-rc2-next-20171208+ #32
>> Hardware name: Intel Corporation S1200SP/S1200SP, BIOS 
>> S1200SP.86B.01.03.0006.040720161253 04/07/2016
>> RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
>> RSP: 0018:8807234476d0 EFLAGS: 00010282
>> RAX:  RBX: 88072d0237a0 RCX: a0065c4d
>> RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
>> RBP: 880723447728 R08: 88072d02 R09: a008d240
>> R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
>> R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
>> FS:  7f8a68666700() GS:88080220() 
>> knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
>> Call Trace:
>>  x86_emulate_instruction+0x3bc/0xb70 [kvm]
>>  ? reexecute_instruction.part.162+0x130/0x130 [kvm]
>>  vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
>>  ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
>>  ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
>>  ? wait_lapic_expire+0x25/0x270 [kvm]
>>  vcpu_enter_guest+0x720/0x1ef0 [kvm]
>>  ...
>>
>> When cs.l is set, vcpu should run in the 64 bit paging mode.
>> Current kvm set_sregs function doesn't have such check when userspace
>> inputs sreg values. This will lead unexpected behavior. This patch
>> is to add such check.
>>
>> Suggested-by: Paolo Bonzini 
>> Reported-by: Dmitry Vyukov 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Dmitry Vyukov 
>> Cc: Jim Mattson 
>> Signed-off-by: Tianyu Lan 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/x86.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 1e1e617..07d6d6c 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -7485,6 +7485,18 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16 
>> tss_selector, int idt_index,
>>  }
>>  EXPORT_SYMBOL_GPL(kvm_task_switch);
>>  
>> +int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
>> +{
>> +/* When cs.l is set, vcpu should run in 64-bit mode */
>> +if (sregs->cs.l)
>> +if (!((sregs->cr0 & X86_CR0_PG_BIT) &&
>> +  (sregs->cr4 & X86_CR4_PAE_BIT) &&
>> +  (sregs->efer & EFER_LME)))
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>>  int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>>struct kvm_sregs *sregs)
>>  {
>> @@ -7497,6 +7509,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu 
>> *vcpu,
>>  (sregs->cr4 & X86_CR4_OSXSAVE))
>>  return -EINVAL;
>>  
>> +if (kvm_valid_sregs(vcpu, sregs))
>> +return -EINVAL;
>> +
>>  apic_base_msr.data = sregs->apic_base;
>>  apic_base_msr.host_initiated = true;
>>  if (kvm_set_apic_base(vcpu, _base_msr))
>>
> 
> Thanks, this is the right direction.  However, there are many more
> checks that are missing and can trigger more unexpected behavior.

Yes, we may add these checks step by step.

>  In
> particular:
> 
> - if EFER.LME=1 and CR0.PG=1, EFER.LMA and CR4.PAE must be 1
> 
> - otherwise, EFER.LMA and CS.L must be 0

I will add these in the new version. Thanks.

-- 
Best regards
Tianyu Lan

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

[Huang, Ying]

Hi, Dave,

Dave Hansen  writes:

> On 12/13/2017 07:38 PM, Lu Baolu wrote:
>> 2. When vmalloc/vfree interfaces are called, the page mappings
>> for kernel memory might get changed. And current code calls
>> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or
>> DevTLB will be stale compared to that on the cpu for kernel
>> mappings.
>
> What's the plan to deal with all of the ways other than vmalloc() that
> the kernel changes the page tables?

The kernel MMU notifier is called in flush_tlb_kernel_range().  So IOMMU
will be notified for TLB flushing caused by all ways that the kernel
changes the page tables including vmalloc, kmap, etc.

Best Regards,
Huang, Ying

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

[Huang, Ying]

Hi, Dave,

Dave Hansen  writes:

> On 12/13/2017 07:38 PM, Lu Baolu wrote:
>> 2. When vmalloc/vfree interfaces are called, the page mappings
>> for kernel memory might get changed. And current code calls
>> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or
>> DevTLB will be stale compared to that on the cpu for kernel
>> mappings.
>
> What's the plan to deal with all of the ways other than vmalloc() that
> the kernel changes the page tables?

The kernel MMU notifier is called in flush_tlb_kernel_range().  So IOMMU
will be notified for TLB flushing caused by all ways that the kernel
changes the page tables including vmalloc, kmap, etc.

Best Regards,
Huang, Ying

[PATCH v2] staging: comedi: ni_*: Fix style warnings.

[Aniruddha Shastri]

Three of these warnings are now line-too-long warnings. I think these 
warnings are preferable to the ones listed below. The longest line 
is only 87 chars wide, which is reasonable.

Warnings fixed:
ni_670x.c:212: WARNING: struct comedi_lrange should normally be const
ni_atmio.c:239: WARNING: Avoid multiple line dereference
- prefer 'ni_boards[i].isapnp_id'
ni_labpc_common.c:573: WARNING: Avoid multiple line dereference
- prefer 'cmd->scan_begin_arg'
ni_mio_common.c:736: WARNING: Avoid multiple line dereference
- prefer 'devpriv->counter_dev->counters[gpct_index]'
ni_mio_common.c:1977: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:1990: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int *' should also have an identifier name
ni_mio_common.c:4699: WARNING: Prefer using '"%s...", __func__'
to using 'cs5529_do_conversion', this function's name, in a string
ni_stc.h:21: WARNING: Block comments should align the * on each line

Signed-off-by: Aniruddha Shastri 
---
Changes in v2:
No longer go out of our way to fix minor line-length violations at the expense 
of code quality.

 drivers/staging/comedi/drivers/ni_670x.c |  2 +-
 drivers/staging/comedi/drivers/ni_atmio.c|  6 +++---
 drivers/staging/comedi/drivers/ni_labpc_common.c |  3 +--
 drivers/staging/comedi/drivers/ni_mio_common.c   | 14 --
 drivers/staging/comedi/drivers/ni_stc.h  |  2 +-
 5 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_670x.c 
b/drivers/staging/comedi/drivers/ni_670x.c
index 1d3ff60..ecf663355 100644
--- a/drivers/staging/comedi/drivers/ni_670x.c
+++ b/drivers/staging/comedi/drivers/ni_670x.c
@@ -209,7 +209,7 @@ static int ni_670x_auto_attach(struct comedi_device *dev,
const struct comedi_lrange **range_table_list;
 
range_table_list = kmalloc_array(32,
-sizeof(struct comedi_lrange *),
+sizeof(const struct 
comedi_lrange *),
 GFP_KERNEL);
if (!range_table_list)
return -ENOMEM;
diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index ae6ed96..f9a8638 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -234,9 +234,9 @@ static int ni_isapnp_find_board(struct pnp_dev **dev)
 
for (i = 0; i < ARRAY_SIZE(ni_boards); i++) {
isapnp_dev = pnp_find_dev(NULL,
- ISAPNP_VENDOR('N', 'I', 'C'),
- ISAPNP_FUNCTION(ni_boards[i].
- isapnp_id), NULL);
+   ISAPNP_VENDOR('N', 'I', 'C'),
+   ISAPNP_FUNCTION(ni_boards[i].isapnp_id),
+   NULL);
 
if (!isapnp_dev || !isapnp_dev->card)
continue;
diff --git a/drivers/staging/comedi/drivers/ni_labpc_common.c 
b/drivers/staging/comedi/drivers/ni_labpc_common.c
index b0dfb8e..a38910e 100644
--- a/drivers/staging/comedi/drivers/ni_labpc_common.c
+++ b/drivers/staging/comedi/drivers/ni_labpc_common.c
@@ -569,8 +569,7 @@ static int labpc_ai_cmdtest(struct comedi_device *dev,
/* make sure scan timing is not too fast */
if (cmd->scan_begin_src == TRIG_TIMER) {
if (cmd->convert_src == TRIG_TIMER) {
-   err |= comedi_check_trigger_arg_min(>
-   scan_begin_arg,
+   err |= 
comedi_check_trigger_arg_min(>scan_begin_arg,
cmd->convert_arg *
cmd->chanlist_len);
}
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 398347f..c4a4f5c 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -732,8 +732,7 @@ static void ni_release_gpct_mite_channel(struct 
comedi_device *dev,
 
ni_set_bitfield(dev, NI_E_DMA_G0_G1_SEL_REG,
NI_E_DMA_G0_G1_SEL_MASK(gpct_index), 0);
-   ni_tio_set_mite_channel(>
-  

[PATCH v3] spi: s3c64xx: add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Signed-off-by: Andi Shyti 
Reviewed-by: Krzysztof Kozlowski 
---
Hi,

v2 to v3:
 - move the SPDX identifier on top as a separate comment as per
   documentation
 - add Krzysztof's review

v1 to v2:
 - keep the original license

Andi

 drivers/spi/spi-s3c64xx.c | 18 --
 include/linux/platform_data/spi-s3c64xx.h |  6 ++
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index de7df20f8712..baa3a9fa2638 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1,17 +1,7 @@
-/*
- * Copyright (C) 2009 Samsung Electronics Ltd.
- * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright (c) 2009 Samsung Electronics Co., Ltd.
+//  Jaswinder Singh 
 
 #include 
 #include 
diff --git a/include/linux/platform_data/spi-s3c64xx.h 
b/include/linux/platform_data/spi-s3c64xx.h
index da79774078a7..773daf7915a3 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -1,10 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
 /*
  * Copyright (C) 2009 Samsung Electronics Ltd.
  * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #ifndef __SPI_S3C64XX_H
-- 
2.15.1

[PATCH v2] staging: comedi: ni_*: Fix style warnings.

[Aniruddha Shastri]

Three of these warnings are now line-too-long warnings. I think these 
warnings are preferable to the ones listed below. The longest line 
is only 87 chars wide, which is reasonable.

Warnings fixed:
ni_670x.c:212: WARNING: struct comedi_lrange should normally be const
ni_atmio.c:239: WARNING: Avoid multiple line dereference
- prefer 'ni_boards[i].isapnp_id'
ni_labpc_common.c:573: WARNING: Avoid multiple line dereference
- prefer 'cmd->scan_begin_arg'
ni_mio_common.c:736: WARNING: Avoid multiple line dereference
- prefer 'devpriv->counter_dev->counters[gpct_index]'
ni_mio_common.c:1977: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:1990: WARNING: Prefer using '"%s...", __func__'
to using 'ni_cmd_set_mite_transfer', this function's name, in a string
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int' should also have an identifier name
ni_mio_common.c:4302: WARNING: function definition argument
'int *' should also have an identifier name
ni_mio_common.c:4699: WARNING: Prefer using '"%s...", __func__'
to using 'cs5529_do_conversion', this function's name, in a string
ni_stc.h:21: WARNING: Block comments should align the * on each line

Signed-off-by: Aniruddha Shastri 
---
Changes in v2:
No longer go out of our way to fix minor line-length violations at the expense 
of code quality.

 drivers/staging/comedi/drivers/ni_670x.c |  2 +-
 drivers/staging/comedi/drivers/ni_atmio.c|  6 +++---
 drivers/staging/comedi/drivers/ni_labpc_common.c |  3 +--
 drivers/staging/comedi/drivers/ni_mio_common.c   | 14 --
 drivers/staging/comedi/drivers/ni_stc.h  |  2 +-
 5 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_670x.c 
b/drivers/staging/comedi/drivers/ni_670x.c
index 1d3ff60..ecf663355 100644
--- a/drivers/staging/comedi/drivers/ni_670x.c
+++ b/drivers/staging/comedi/drivers/ni_670x.c
@@ -209,7 +209,7 @@ static int ni_670x_auto_attach(struct comedi_device *dev,
const struct comedi_lrange **range_table_list;
 
range_table_list = kmalloc_array(32,
-sizeof(struct comedi_lrange *),
+sizeof(const struct 
comedi_lrange *),
 GFP_KERNEL);
if (!range_table_list)
return -ENOMEM;
diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index ae6ed96..f9a8638 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -234,9 +234,9 @@ static int ni_isapnp_find_board(struct pnp_dev **dev)
 
for (i = 0; i < ARRAY_SIZE(ni_boards); i++) {
isapnp_dev = pnp_find_dev(NULL,
- ISAPNP_VENDOR('N', 'I', 'C'),
- ISAPNP_FUNCTION(ni_boards[i].
- isapnp_id), NULL);
+   ISAPNP_VENDOR('N', 'I', 'C'),
+   ISAPNP_FUNCTION(ni_boards[i].isapnp_id),
+   NULL);
 
if (!isapnp_dev || !isapnp_dev->card)
continue;
diff --git a/drivers/staging/comedi/drivers/ni_labpc_common.c 
b/drivers/staging/comedi/drivers/ni_labpc_common.c
index b0dfb8e..a38910e 100644
--- a/drivers/staging/comedi/drivers/ni_labpc_common.c
+++ b/drivers/staging/comedi/drivers/ni_labpc_common.c
@@ -569,8 +569,7 @@ static int labpc_ai_cmdtest(struct comedi_device *dev,
/* make sure scan timing is not too fast */
if (cmd->scan_begin_src == TRIG_TIMER) {
if (cmd->convert_src == TRIG_TIMER) {
-   err |= comedi_check_trigger_arg_min(>
-   scan_begin_arg,
+   err |= 
comedi_check_trigger_arg_min(>scan_begin_arg,
cmd->convert_arg *
cmd->chanlist_len);
}
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 398347f..c4a4f5c 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -732,8 +732,7 @@ static void ni_release_gpct_mite_channel(struct 
comedi_device *dev,
 
ni_set_bitfield(dev, NI_E_DMA_G0_G1_SEL_REG,
NI_E_DMA_G0_G1_SEL_MASK(gpct_index), 0);
-   ni_tio_set_mite_channel(>
-   

[PATCH v3] spi: s3c64xx: add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Signed-off-by: Andi Shyti 
Reviewed-by: Krzysztof Kozlowski 
---
Hi,

v2 to v3:
 - move the SPDX identifier on top as a separate comment as per
   documentation
 - add Krzysztof's review

v1 to v2:
 - keep the original license

Andi

 drivers/spi/spi-s3c64xx.c | 18 --
 include/linux/platform_data/spi-s3c64xx.h |  6 ++
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index de7df20f8712..baa3a9fa2638 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1,17 +1,7 @@
-/*
- * Copyright (C) 2009 Samsung Electronics Ltd.
- * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright (c) 2009 Samsung Electronics Co., Ltd.
+//  Jaswinder Singh 
 
 #include 
 #include 
diff --git a/include/linux/platform_data/spi-s3c64xx.h 
b/include/linux/platform_data/spi-s3c64xx.h
index da79774078a7..773daf7915a3 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -1,10 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
 /*
  * Copyright (C) 2009 Samsung Electronics Ltd.
  * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #ifndef __SPI_S3C64XX_H
-- 
2.15.1

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

[Dave Hansen]

On 12/13/2017 07:38 PM, Lu Baolu wrote:
> 2. When vmalloc/vfree interfaces are called, the page mappings
> for kernel memory might get changed. And current code calls
> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or
> DevTLB will be stale compared to that on the cpu for kernel
> mappings.

What's the plan to deal with all of the ways other than vmalloc() that
the kernel changes the page tables?

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

[Dave Hansen]

On 12/13/2017 07:38 PM, Lu Baolu wrote:
> 2. When vmalloc/vfree interfaces are called, the page mappings
> for kernel memory might get changed. And current code calls
> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or
> DevTLB will be stale compared to that on the cpu for kernel
> mappings.

What's the plan to deal with all of the ways other than vmalloc() that
the kernel changes the page tables?

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

[Aishwarya Pant]

On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote:
> > This is a clean-up patch which replaces the uses of raw __ATTR(...)
> > macro with the more conventional DEVICE_ATTR(...) for defining device
> > attributes.
> > 
> > Done using coccinelle-
> > 
> > @r@
> > identifier foo, n;
> > @@
> > 
> > struct device_attribute foo =  __ATTR(n, ...);
> > 
> > @script:python p@
> > id;
> > foo << r.foo;
> > n << r.n;
> > @@
> > 
> > // standardise the variable name to dev_attr_{name}
> > coccinelle.id = "dev_attr_" + n
> > 
> > @@
> > identifier r.foo;
> > declarer name DEVICE_ATTR;
> > @@
> > 
> > //change definition
> > - struct device_attribute foo = __ATTR
> > + DEVICE_ATTR
> > (...);
> > 
> > @depends on r@
> > identifier r.foo, p.id;
> > @@
> > 
> > // replace usages everywhere
> > - foo
> > + id
> > 
> > Signed-off-by: Aishwarya Pant 
> > ---
> >  drivers/staging/fbtft/fbtft-sysfs.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
> > b/drivers/staging/fbtft/fbtft-sysfs.c
> > index 712096659aa0..506d604d01bb 100644
> > --- a/drivers/staging/fbtft/fbtft-sysfs.c
> > +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> > @@ -197,19 +197,18 @@ static ssize_t show_debug(struct device *device,
> > return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
> >  }
> >  
> > -static struct device_attribute debug_device_attr =
> > -   __ATTR(debug, 0660, show_debug, store_debug);
> > +static DEVICE_ATTR(debug, 0660, show_debug, store_debug);
> 
> This should be DEVICE_ATTR_RW(), right?  0660 makes no sense...

If it doesn't make sense here, I can replace it with DEVICE_ATTR_RW.
Though, 0660 has more open permissions than 0644.

> 
> thanks,
> 
> greg k-h

Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0

[Stefan Mavrodiev]

On 12/13/2017 05:40 PM, Maxime Ripard wrote:

Hi,

On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:

Allwinner A10/A13/A20 SoCs have pinmux for spi0
on port C. The patch adds these pins in the respective
dts includes.

Signed-off-by: Stefan Mavrodiev 

Do you have any boards that are using these?

We won't merge that patch if there's no users for it.

Maxime


A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
For A13 we still doesn't have that option.

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

[Aishwarya Pant]

On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote:
> > This is a clean-up patch which replaces the uses of raw __ATTR(...)
> > macro with the more conventional DEVICE_ATTR(...) for defining device
> > attributes.
> > 
> > Done using coccinelle-
> > 
> > @r@
> > identifier foo, n;
> > @@
> > 
> > struct device_attribute foo =  __ATTR(n, ...);
> > 
> > @script:python p@
> > id;
> > foo << r.foo;
> > n << r.n;
> > @@
> > 
> > // standardise the variable name to dev_attr_{name}
> > coccinelle.id = "dev_attr_" + n
> > 
> > @@
> > identifier r.foo;
> > declarer name DEVICE_ATTR;
> > @@
> > 
> > //change definition
> > - struct device_attribute foo = __ATTR
> > + DEVICE_ATTR
> > (...);
> > 
> > @depends on r@
> > identifier r.foo, p.id;
> > @@
> > 
> > // replace usages everywhere
> > - foo
> > + id
> > 
> > Signed-off-by: Aishwarya Pant 
> > ---
> >  drivers/staging/fbtft/fbtft-sysfs.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
> > b/drivers/staging/fbtft/fbtft-sysfs.c
> > index 712096659aa0..506d604d01bb 100644
> > --- a/drivers/staging/fbtft/fbtft-sysfs.c
> > +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> > @@ -197,19 +197,18 @@ static ssize_t show_debug(struct device *device,
> > return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
> >  }
> >  
> > -static struct device_attribute debug_device_attr =
> > -   __ATTR(debug, 0660, show_debug, store_debug);
> > +static DEVICE_ATTR(debug, 0660, show_debug, store_debug);
> 
> This should be DEVICE_ATTR_RW(), right?  0660 makes no sense...

If it doesn't make sense here, I can replace it with DEVICE_ATTR_RW.
Though, 0660 has more open permissions than 0644.

> 
> thanks,
> 
> greg k-h

Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0

[Stefan Mavrodiev]

On 12/13/2017 05:40 PM, Maxime Ripard wrote:

Hi,

On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:

Allwinner A10/A13/A20 SoCs have pinmux for spi0
on port C. The patch adds these pins in the respective
dts includes.

Signed-off-by: Stefan Mavrodiev 

Do you have any boards that are using these?

We won't merge that patch if there's no users for it.

Maxime


A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
For A13 we still doesn't have that option.

Re: [PATCH v2] spi: s3c64xx: add SPDX identifier

[Philippe Ombredanne]

Andi,

On Thu, Dec 14, 2017 at 2:31 AM, Andi Shyti  wrote:
> Hi Philippe,
>
>> > diff --git a/include/linux/platform_data/spi-s3c64xx.h 
>> > b/include/linux/platform_data/spi-s3c64xx.h
>> > index da79774078a7..8917f38c97c5 100644
>> > --- a/include/linux/platform_data/spi-s3c64xx.h
>> > +++ b/include/linux/platform_data/spi-s3c64xx.h
>> > @@ -2,9 +2,7 @@
>> >   * Copyright (C) 2009 Samsung Electronics Ltd.
>> >   * Jaswinder Singh 
>> >   *
>> > - * This program is free software; you can redistribute it and/or modify
>> > - * it under the terms of the GNU General Public License version 2 as
>> > - * published by the Free Software Foundation.
>> > + * SPDX-License-Identifier: GPL-2.0
>> >   */
>> >
>> >  #ifndef __SPI_S3C64XX_H
>> > --
>> > 2.15.1
>> >
>>
>>
>> You still need to put this line at the very top of the file, first
>> line. That's the convention for the SPDX tags as documented by Thomas
>> Gleixner.
>
> I had some doubts on this one, indeed. How should it be done in
> this case:
>
> 1. Strictly by Thomas documentation:
>
>   /* SPDX-License-Identifier: GPL-2.0 */
>
>   /*
>* Copyright (C) 2009 Samsung Electronics Ltd.
>* Jaswinder Singh 
>*/
>
> or
>
> 2. with a little interpretation
>
>   /*
>* SPDX-License-Identifier: GPL-2.0
>*
>* Copyright (C) 2009 Samsung Electronics Ltd.
>* Jaswinder Singh 
>*/
>
> (I opted for the one with the least number of changes)

You should go strictly by Thomas' doc. This is one area where
consistency is the thing that brings benefits. Interpretation is not
needed.
So please, consider going with 1.
-- 
Cordially
Philippe Ombredanne

Re: [PATCH v2] spi: s3c64xx: add SPDX identifier

[Philippe Ombredanne]

Andi,

On Thu, Dec 14, 2017 at 2:31 AM, Andi Shyti  wrote:
> Hi Philippe,
>
>> > diff --git a/include/linux/platform_data/spi-s3c64xx.h 
>> > b/include/linux/platform_data/spi-s3c64xx.h
>> > index da79774078a7..8917f38c97c5 100644
>> > --- a/include/linux/platform_data/spi-s3c64xx.h
>> > +++ b/include/linux/platform_data/spi-s3c64xx.h
>> > @@ -2,9 +2,7 @@
>> >   * Copyright (C) 2009 Samsung Electronics Ltd.
>> >   * Jaswinder Singh 
>> >   *
>> > - * This program is free software; you can redistribute it and/or modify
>> > - * it under the terms of the GNU General Public License version 2 as
>> > - * published by the Free Software Foundation.
>> > + * SPDX-License-Identifier: GPL-2.0
>> >   */
>> >
>> >  #ifndef __SPI_S3C64XX_H
>> > --
>> > 2.15.1
>> >
>>
>>
>> You still need to put this line at the very top of the file, first
>> line. That's the convention for the SPDX tags as documented by Thomas
>> Gleixner.
>
> I had some doubts on this one, indeed. How should it be done in
> this case:
>
> 1. Strictly by Thomas documentation:
>
>   /* SPDX-License-Identifier: GPL-2.0 */
>
>   /*
>* Copyright (C) 2009 Samsung Electronics Ltd.
>* Jaswinder Singh 
>*/
>
> or
>
> 2. with a little interpretation
>
>   /*
>* SPDX-License-Identifier: GPL-2.0
>*
>* Copyright (C) 2009 Samsung Electronics Ltd.
>* Jaswinder Singh 
>*/
>
> (I opted for the one with the least number of changes)

You should go strictly by Thomas' doc. This is one area where
consistency is the thing that brings benefits. Interpretation is not
needed.
So please, consider going with 1.
-- 
Cordially
Philippe Ombredanne

[PATCH 2/4 v3] mtd: onenand: samsung: return an error if 'mtd_device_parse_register()' fails

[Christophe JAILLET]

If 'mtd_device_parse_register()' fails, we still return 0 which mean
success.
Return the error code instead, as done in all the other error handling
paths.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v2: call 'onenand_release()' to undo 'onenand_scan()'
v3: no change
---
 drivers/mtd/onenand/samsung.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index b650290611d2..b5497c5a35f1 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -936,6 +936,11 @@ static int s3c_onenand_probe(struct platform_device *pdev)
err = mtd_device_parse_register(mtd, NULL, NULL,
pdata ? pdata->parts : NULL,
pdata ? pdata->nr_parts : 0);
+   if (err) {
+   dev_err(>dev, "failed to parse partitions and register 
the MTD device\n");
+   onenand_release(mtd);
+   return err;
+   }
 
platform_set_drvdata(pdev, mtd);
 
-- 
2.14.1

[PATCH 2/4 v3] mtd: onenand: samsung: return an error if 'mtd_device_parse_register()' fails

[Christophe JAILLET]

If 'mtd_device_parse_register()' fails, we still return 0 which mean
success.
Return the error code instead, as done in all the other error handling
paths.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v2: call 'onenand_release()' to undo 'onenand_scan()'
v3: no change
---
 drivers/mtd/onenand/samsung.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index b650290611d2..b5497c5a35f1 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -936,6 +936,11 @@ static int s3c_onenand_probe(struct platform_device *pdev)
err = mtd_device_parse_register(mtd, NULL, NULL,
pdata ? pdata->parts : NULL,
pdata ? pdata->nr_parts : 0);
+   if (err) {
+   dev_err(>dev, "failed to parse partitions and register 
the MTD device\n");
+   onenand_release(mtd);
+   return err;
+   }
 
platform_set_drvdata(pdev, mtd);
 
-- 
2.14.1

[PATCH 3/4 v3] mtd: onenand: samsung: Remove a useless include

[Christophe JAILLET]

This include is not needed, so remove it.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v3: new patch in the serie
---
 drivers/mtd/onenand/samsung.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 206aa90140c9..c21d025fee87 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -25,8 +25,6 @@
 #include 
 #include 
 
-#include 
-
 #include "samsung.h"
 
 enum soc_type {
-- 
2.14.1

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

[Bob Liu]

On 2017/12/14 11:38, Lu Baolu wrote:
> Hi,
> 
> On 12/14/2017 11:10 AM, Bob Liu wrote:
>> On 2017/12/14 9:02, Lu Baolu wrote:
 From: Huang Ying 

 Shared Virtual Memory (SVM) allows a kernel memory mapping to be
 shared between CPU and and a device which requested a supervisor
 PASID. Both devices and IOMMU units have TLBs that cache entries
 from CPU's page tables. We need to get a chance to flush them at
 the same time when we flush the CPU TLBs.

 We already have an existing MMU notifiers for userspace updates,
 however we lack the same thing for kernel page table updates. To
>> Sorry, I didn't get which situation need this notification.
>> Could you please describe the full scenario?
> 
> Okay.
> 
> 1. When an SVM capable driver calls intel_svm_bind_mm() with
> SVM_FLAG_SUPERVISOR_MODE set in the @flags, the kernel
> memory page mappings will be shared between CPUs and
> the DMA remapping agent (a.k.a. IOMMU). The page table
> entries will also be cached in both IOTLB (located in IOMMU)
> and the DEVTLB (located in device).
> 

But who/what kind of real device has the requirement to access a kernel VA?
Looks like SVM_FLAG_SUPERVISOR_MODE is used by nobody?

Cheers,
Liubo

> 2. When vmalloc/vfree interfaces are called, the page mappings
> for kernel memory might get changed. And current code calls
> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or
> DevTLB will be stale compared to that on the cpu for kernel
> mappings.
> 
> We need a kernel mmu notification to flush TLBs in IOMMU and
> devices as well.
> 
> Best regards,
> Lu Baolu
> 

[PATCH 3/4 v3] mtd: onenand: samsung: Remove a useless include

[Christophe JAILLET]

This include is not needed, so remove it.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v3: new patch in the serie
---
 drivers/mtd/onenand/samsung.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 206aa90140c9..c21d025fee87 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -25,8 +25,6 @@
 #include 
 #include 
 
-#include 
-
 #include "samsung.h"
 
 enum soc_type {
-- 
2.14.1

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

[Bob Liu]

On 2017/12/14 11:38, Lu Baolu wrote:
> Hi,
> 
> On 12/14/2017 11:10 AM, Bob Liu wrote:
>> On 2017/12/14 9:02, Lu Baolu wrote:
 From: Huang Ying 

 Shared Virtual Memory (SVM) allows a kernel memory mapping to be
 shared between CPU and and a device which requested a supervisor
 PASID. Both devices and IOMMU units have TLBs that cache entries
 from CPU's page tables. We need to get a chance to flush them at
 the same time when we flush the CPU TLBs.

 We already have an existing MMU notifiers for userspace updates,
 however we lack the same thing for kernel page table updates. To
>> Sorry, I didn't get which situation need this notification.
>> Could you please describe the full scenario?
> 
> Okay.
> 
> 1. When an SVM capable driver calls intel_svm_bind_mm() with
> SVM_FLAG_SUPERVISOR_MODE set in the @flags, the kernel
> memory page mappings will be shared between CPUs and
> the DMA remapping agent (a.k.a. IOMMU). The page table
> entries will also be cached in both IOTLB (located in IOMMU)
> and the DEVTLB (located in device).
> 

But who/what kind of real device has the requirement to access a kernel VA?
Looks like SVM_FLAG_SUPERVISOR_MODE is used by nobody?

Cheers,
Liubo

> 2. When vmalloc/vfree interfaces are called, the page mappings
> for kernel memory might get changed. And current code calls
> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or
> DevTLB will be stale compared to that on the cpu for kernel
> mappings.
> 
> We need a kernel mmu notification to flush TLBs in IOMMU and
> devices as well.
> 
> Best regards,
> Lu Baolu
> 

[PATCH 3/4 v3] mtd: onenand: samsung: Propagate the error returned by 'onenand_scan()'

[Christophe JAILLET]

Propagate the error code returned by 'onenand_scan()' instead of a
hard-coded -EFAULT.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v3: new patch in the serie
---
 drivers/mtd/onenand/samsung.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index b5497c5a35f1..206aa90140c9 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -921,8 +921,9 @@ static int s3c_onenand_probe(struct platform_device *pdev)
}
}
 
-   if (onenand_scan(mtd, 1))
-   return -EFAULT;
+   err = onenand_scan(mtd, 1);
+   if (err)
+   return err;
 
if (onenand->type != TYPE_S5PC110) {
/* S3C doesn't handle subpage write */
-- 
2.14.1

Re: [PATCH V2] block, bfq: remove batches of confusing ifdefs

[Paolo Valente]

Hi Jens,
do you think this version could be ok?

Thanks,
Paolo

> Il giorno 04 dic 2017, alle ore 11:42, Paolo Valente 
>  ha scritto:
> 
> Commit a33801e8b473 ("block, bfq: move debug blkio stats behind
> CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs:
> one reported in [1], plus a similar one in another function. This
> commit removes both batches, in the way suggested in [1].
> 
> [1] https://www.spinics.net/lists/linux-block/msg20043.html
> 
> Fixes: a33801e8b473 ("block, bfq: move debug blkio stats behind 
> CONFIG_DEBUG_BLK_CGROUP")
> Reported-by: Linus Torvalds 
> Tested-by: Luca Miccio 
> Signed-off-by: Paolo Valente 
> ---
> block/bfq-iosched.c | 127 +---
> 1 file changed, 72 insertions(+), 55 deletions(-)
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index bcb6d21..3feed64 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -3689,35 +3689,16 @@ static struct request *__bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>   return rq;
> }
> 
> -static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> -{
> - struct bfq_data *bfqd = hctx->queue->elevator->elevator_data;
> - struct request *rq;
> #if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - struct bfq_queue *in_serv_queue, *bfqq;
> - bool waiting_rq, idle_timer_disabled;
> -#endif
> -
> - spin_lock_irq(>lock);
> -
> -#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - in_serv_queue = bfqd->in_service_queue;
> - waiting_rq = in_serv_queue && bfq_bfqq_wait_request(in_serv_queue);
> -
> - rq = __bfq_dispatch_request(hctx);
> -
> - idle_timer_disabled =
> - waiting_rq && !bfq_bfqq_wait_request(in_serv_queue);
> -
> -#else
> - rq = __bfq_dispatch_request(hctx);
> -#endif
> - spin_unlock_irq(>lock);
> +static void bfq_update_dispatch_stats(struct request_queue *q,
> +   struct request *rq,
> +   struct bfq_queue *in_serv_queue,
> +   bool idle_timer_disabled)
> +{
> + struct bfq_queue *bfqq = rq ? RQ_BFQQ(rq) : NULL;
> 
> -#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - bfqq = rq ? RQ_BFQQ(rq) : NULL;
>   if (!idle_timer_disabled && !bfqq)
> - return rq;
> + return;
> 
>   /*
>* rq and bfqq are guaranteed to exist until this function
> @@ -3732,7 +3713,7 @@ static struct request *bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>* In addition, the following queue lock guarantees that
>* bfqq_group(bfqq) exists as well.
>*/
> - spin_lock_irq(hctx->queue->queue_lock);
> + spin_lock_irq(q->queue_lock);
>   if (idle_timer_disabled)
>   /*
>* Since the idle timer has been disabled,
> @@ -3751,9 +3732,37 @@ static struct request *bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>   bfqg_stats_set_start_empty_time(bfqg);
>   bfqg_stats_update_io_remove(bfqg, rq->cmd_flags);
>   }
> - spin_unlock_irq(hctx->queue->queue_lock);
> + spin_unlock_irq(q->queue_lock);
> +}
> +#else
> +static inline void bfq_update_dispatch_stats(struct request_queue *q,
> +  struct request *rq,
> +  struct bfq_queue *in_serv_queue,
> +  bool idle_timer_disabled) {}
> #endif
> 
> +static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> +{
> + struct bfq_data *bfqd = hctx->queue->elevator->elevator_data;
> + struct request *rq;
> + struct bfq_queue *in_serv_queue;
> + bool waiting_rq, idle_timer_disabled;
> +
> + spin_lock_irq(>lock);
> +
> + in_serv_queue = bfqd->in_service_queue;
> + waiting_rq = in_serv_queue && bfq_bfqq_wait_request(in_serv_queue);
> +
> + rq = __bfq_dispatch_request(hctx);
> +
> + idle_timer_disabled =
> + waiting_rq && !bfq_bfqq_wait_request(in_serv_queue);
> +
> + spin_unlock_irq(>lock);
> +
> + bfq_update_dispatch_stats(hctx->queue, rq, in_serv_queue,
> +   idle_timer_disabled);
> +
>   return rq;
> }
> 
> @@ -4276,16 +4285,46 @@ static bool __bfq_insert_request(struct bfq_data 
> *bfqd, struct request *rq)
>   return idle_timer_disabled;
> }
> 
> +#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> +static void bfq_update_insert_stats(struct request_queue *q,
> + struct bfq_queue *bfqq,
> + bool idle_timer_disabled,
> + unsigned int cmd_flags)
> +{
> + if (!bfqq)
> + return;
> +
> + /*
> + 

Re: [PATCH V2] block, bfq: remove batches of confusing ifdefs

[Paolo Valente]

Hi Jens,
do you think this version could be ok?

Thanks,
Paolo

> Il giorno 04 dic 2017, alle ore 11:42, Paolo Valente 
>  ha scritto:
> 
> Commit a33801e8b473 ("block, bfq: move debug blkio stats behind
> CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs:
> one reported in [1], plus a similar one in another function. This
> commit removes both batches, in the way suggested in [1].
> 
> [1] https://www.spinics.net/lists/linux-block/msg20043.html
> 
> Fixes: a33801e8b473 ("block, bfq: move debug blkio stats behind 
> CONFIG_DEBUG_BLK_CGROUP")
> Reported-by: Linus Torvalds 
> Tested-by: Luca Miccio 
> Signed-off-by: Paolo Valente 
> ---
> block/bfq-iosched.c | 127 +---
> 1 file changed, 72 insertions(+), 55 deletions(-)
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index bcb6d21..3feed64 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -3689,35 +3689,16 @@ static struct request *__bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>   return rq;
> }
> 
> -static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> -{
> - struct bfq_data *bfqd = hctx->queue->elevator->elevator_data;
> - struct request *rq;
> #if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - struct bfq_queue *in_serv_queue, *bfqq;
> - bool waiting_rq, idle_timer_disabled;
> -#endif
> -
> - spin_lock_irq(>lock);
> -
> -#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - in_serv_queue = bfqd->in_service_queue;
> - waiting_rq = in_serv_queue && bfq_bfqq_wait_request(in_serv_queue);
> -
> - rq = __bfq_dispatch_request(hctx);
> -
> - idle_timer_disabled =
> - waiting_rq && !bfq_bfqq_wait_request(in_serv_queue);
> -
> -#else
> - rq = __bfq_dispatch_request(hctx);
> -#endif
> - spin_unlock_irq(>lock);
> +static void bfq_update_dispatch_stats(struct request_queue *q,
> +   struct request *rq,
> +   struct bfq_queue *in_serv_queue,
> +   bool idle_timer_disabled)
> +{
> + struct bfq_queue *bfqq = rq ? RQ_BFQQ(rq) : NULL;
> 
> -#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - bfqq = rq ? RQ_BFQQ(rq) : NULL;
>   if (!idle_timer_disabled && !bfqq)
> - return rq;
> + return;
> 
>   /*
>* rq and bfqq are guaranteed to exist until this function
> @@ -3732,7 +3713,7 @@ static struct request *bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>* In addition, the following queue lock guarantees that
>* bfqq_group(bfqq) exists as well.
>*/
> - spin_lock_irq(hctx->queue->queue_lock);
> + spin_lock_irq(q->queue_lock);
>   if (idle_timer_disabled)
>   /*
>* Since the idle timer has been disabled,
> @@ -3751,9 +3732,37 @@ static struct request *bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>   bfqg_stats_set_start_empty_time(bfqg);
>   bfqg_stats_update_io_remove(bfqg, rq->cmd_flags);
>   }
> - spin_unlock_irq(hctx->queue->queue_lock);
> + spin_unlock_irq(q->queue_lock);
> +}
> +#else
> +static inline void bfq_update_dispatch_stats(struct request_queue *q,
> +  struct request *rq,
> +  struct bfq_queue *in_serv_queue,
> +  bool idle_timer_disabled) {}
> #endif
> 
> +static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> +{
> + struct bfq_data *bfqd = hctx->queue->elevator->elevator_data;
> + struct request *rq;
> + struct bfq_queue *in_serv_queue;
> + bool waiting_rq, idle_timer_disabled;
> +
> + spin_lock_irq(>lock);
> +
> + in_serv_queue = bfqd->in_service_queue;
> + waiting_rq = in_serv_queue && bfq_bfqq_wait_request(in_serv_queue);
> +
> + rq = __bfq_dispatch_request(hctx);
> +
> + idle_timer_disabled =
> + waiting_rq && !bfq_bfqq_wait_request(in_serv_queue);
> +
> + spin_unlock_irq(>lock);
> +
> + bfq_update_dispatch_stats(hctx->queue, rq, in_serv_queue,
> +   idle_timer_disabled);
> +
>   return rq;
> }
> 
> @@ -4276,16 +4285,46 @@ static bool __bfq_insert_request(struct bfq_data 
> *bfqd, struct request *rq)
>   return idle_timer_disabled;
> }
> 
> +#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> +static void bfq_update_insert_stats(struct request_queue *q,
> + struct bfq_queue *bfqq,
> + bool idle_timer_disabled,
> + unsigned int cmd_flags)
> +{
> + if (!bfqq)
> + return;
> +
> + /*
> +  * bfqq still exists, because it can disappear only after
> +  * either it is merged with 

[PATCH 3/4 v3] mtd: onenand: samsung: Propagate the error returned by 'onenand_scan()'

[Christophe JAILLET]

Propagate the error code returned by 'onenand_scan()' instead of a
hard-coded -EFAULT.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v3: new patch in the serie
---
 drivers/mtd/onenand/samsung.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index b5497c5a35f1..206aa90140c9 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -921,8 +921,9 @@ static int s3c_onenand_probe(struct platform_device *pdev)
}
}
 
-   if (onenand_scan(mtd, 1))
-   return -EFAULT;
+   err = onenand_scan(mtd, 1);
+   if (err)
+   return err;
 
if (onenand->type != TYPE_S5PC110) {
/* S3C doesn't handle subpage write */
-- 
2.14.1

[PATCH 1/4 v3] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks

[Christophe JAILLET]

Convert all error handling code in 's3c_onenand_probe()' to
resource-managed alternatives in order to simplify code.

This fixes a resource leak if 'platform_get_resource()' fails at line 872.

The 'request_irq()' at line 971 was also un-balanced. It is now
resource-managed.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v2: use devm_ioremap_resource()
v3: fix a bug introduced in v2
---
 drivers/mtd/onenand/samsung.c | 164 --
 1 file changed, 29 insertions(+), 135 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index af0ac1a7bf8f..b650290611d2 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -129,16 +129,13 @@ struct s3c_onenand {
struct platform_device  *pdev;
enum soc_type   type;
void __iomem*base;
-   struct resource *base_res;
void __iomem*ahb_addr;
-   struct resource *ahb_res;
int bootram_command;
void __iomem*page_buf;
void __iomem*oob_buf;
unsigned int(*mem_addr)(int fba, int fpa, int fsa);
unsigned int(*cmd_map)(unsigned int type, unsigned int val);
void __iomem*dma_addr;
-   struct resource *dma_res;
unsigned long   phys_base;
struct completion   complete;
 };
@@ -851,15 +848,13 @@ static int s3c_onenand_probe(struct platform_device *pdev)
/* No need to check pdata. the platform data is optional */
 
size = sizeof(struct mtd_info) + sizeof(struct onenand_chip);
-   mtd = kzalloc(size, GFP_KERNEL);
+   mtd = devm_kzalloc(>dev, size, GFP_KERNEL);
if (!mtd)
return -ENOMEM;
 
-   onenand = kzalloc(sizeof(struct s3c_onenand), GFP_KERNEL);
-   if (!onenand) {
-   err = -ENOMEM;
-   goto onenand_fail;
-   }
+   onenand = devm_kzalloc(>dev, sizeof(struct s3c_onenand), 
GFP_KERNEL);
+   if (!onenand)
+   return -ENOMEM;
 
this = (struct onenand_chip *) [1];
mtd->priv = this;
@@ -870,26 +865,12 @@ static int s3c_onenand_probe(struct platform_device *pdev)
s3c_onenand_setup(mtd);
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!r) {
-   dev_err(>dev, "no memory resource defined\n");
-   return -ENOENT;
-   goto ahb_resource_failed;
-   }
+   onenand->base = devm_ioremap_resource(>dev, r);
+   if (IS_ERR(onenand->base))
+   return PTR_ERR(onenand->base);
 
-   onenand->base_res = request_mem_region(r->start, resource_size(r),
-  pdev->name);
-   if (!onenand->base_res) {
-   dev_err(>dev, "failed to request memory resource\n");
-   err = -EBUSY;
-   goto resource_failed;
-   }
+   onenand->phys_base = r->start;
 
-   onenand->base = ioremap(r->start, resource_size(r));
-   if (!onenand->base) {
-   dev_err(>dev, "failed to map memory resource\n");
-   err = -EFAULT;
-   goto ioremap_failed;
-   }
/* Set onenand_chip also */
this->base = onenand->base;
 
@@ -898,40 +879,20 @@ static int s3c_onenand_probe(struct platform_device *pdev)
 
if (onenand->type != TYPE_S5PC110) {
r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (!r) {
-   dev_err(>dev, "no buffer memory resource 
defined\n");
-   err = -ENOENT;
-   goto ahb_resource_failed;
-   }
-
-   onenand->ahb_res = request_mem_region(r->start, 
resource_size(r),
- pdev->name);
-   if (!onenand->ahb_res) {
-   dev_err(>dev, "failed to request buffer memory 
resource\n");
-   err = -EBUSY;
-   goto ahb_resource_failed;
-   }
-
-   onenand->ahb_addr = ioremap(r->start, resource_size(r));
-   if (!onenand->ahb_addr) {
-   dev_err(>dev, "failed to map buffer memory 
resource\n");
-   err = -EINVAL;
-   goto ahb_ioremap_failed;
-   }
+   onenand->ahb_addr = devm_ioremap_resource(>dev, r);
+   if (IS_ERR(onenand->ahb_addr))
+   return PTR_ERR(onenand->ahb_addr);
 
/* Allocate 4KiB BufferRAM */
-   onenand->page_buf = kzalloc(SZ_4K, GFP_KERNEL);
-   if (!onenand->page_buf) {
-   err = -ENOMEM;
-   goto page_buf_fail;
-   }
+   onenand->page_buf = devm_kzalloc(>dev, SZ_4K,
+GFP_KERNEL);
+   if (!onenand->page_buf)
+

[PATCH 1/4 v3] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks

[Christophe JAILLET]

Convert all error handling code in 's3c_onenand_probe()' to
resource-managed alternatives in order to simplify code.

This fixes a resource leak if 'platform_get_resource()' fails at line 872.

The 'request_irq()' at line 971 was also un-balanced. It is now
resource-managed.

Signed-off-by: Christophe JAILLET 
---
Cross-compiled tested-only

v2: use devm_ioremap_resource()
v3: fix a bug introduced in v2
---
 drivers/mtd/onenand/samsung.c | 164 --
 1 file changed, 29 insertions(+), 135 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index af0ac1a7bf8f..b650290611d2 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -129,16 +129,13 @@ struct s3c_onenand {
struct platform_device  *pdev;
enum soc_type   type;
void __iomem*base;
-   struct resource *base_res;
void __iomem*ahb_addr;
-   struct resource *ahb_res;
int bootram_command;
void __iomem*page_buf;
void __iomem*oob_buf;
unsigned int(*mem_addr)(int fba, int fpa, int fsa);
unsigned int(*cmd_map)(unsigned int type, unsigned int val);
void __iomem*dma_addr;
-   struct resource *dma_res;
unsigned long   phys_base;
struct completion   complete;
 };
@@ -851,15 +848,13 @@ static int s3c_onenand_probe(struct platform_device *pdev)
/* No need to check pdata. the platform data is optional */
 
size = sizeof(struct mtd_info) + sizeof(struct onenand_chip);
-   mtd = kzalloc(size, GFP_KERNEL);
+   mtd = devm_kzalloc(>dev, size, GFP_KERNEL);
if (!mtd)
return -ENOMEM;
 
-   onenand = kzalloc(sizeof(struct s3c_onenand), GFP_KERNEL);
-   if (!onenand) {
-   err = -ENOMEM;
-   goto onenand_fail;
-   }
+   onenand = devm_kzalloc(>dev, sizeof(struct s3c_onenand), 
GFP_KERNEL);
+   if (!onenand)
+   return -ENOMEM;
 
this = (struct onenand_chip *) [1];
mtd->priv = this;
@@ -870,26 +865,12 @@ static int s3c_onenand_probe(struct platform_device *pdev)
s3c_onenand_setup(mtd);
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!r) {
-   dev_err(>dev, "no memory resource defined\n");
-   return -ENOENT;
-   goto ahb_resource_failed;
-   }
+   onenand->base = devm_ioremap_resource(>dev, r);
+   if (IS_ERR(onenand->base))
+   return PTR_ERR(onenand->base);
 
-   onenand->base_res = request_mem_region(r->start, resource_size(r),
-  pdev->name);
-   if (!onenand->base_res) {
-   dev_err(>dev, "failed to request memory resource\n");
-   err = -EBUSY;
-   goto resource_failed;
-   }
+   onenand->phys_base = r->start;
 
-   onenand->base = ioremap(r->start, resource_size(r));
-   if (!onenand->base) {
-   dev_err(>dev, "failed to map memory resource\n");
-   err = -EFAULT;
-   goto ioremap_failed;
-   }
/* Set onenand_chip also */
this->base = onenand->base;
 
@@ -898,40 +879,20 @@ static int s3c_onenand_probe(struct platform_device *pdev)
 
if (onenand->type != TYPE_S5PC110) {
r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (!r) {
-   dev_err(>dev, "no buffer memory resource 
defined\n");
-   err = -ENOENT;
-   goto ahb_resource_failed;
-   }
-
-   onenand->ahb_res = request_mem_region(r->start, 
resource_size(r),
- pdev->name);
-   if (!onenand->ahb_res) {
-   dev_err(>dev, "failed to request buffer memory 
resource\n");
-   err = -EBUSY;
-   goto ahb_resource_failed;
-   }
-
-   onenand->ahb_addr = ioremap(r->start, resource_size(r));
-   if (!onenand->ahb_addr) {
-   dev_err(>dev, "failed to map buffer memory 
resource\n");
-   err = -EINVAL;
-   goto ahb_ioremap_failed;
-   }
+   onenand->ahb_addr = devm_ioremap_resource(>dev, r);
+   if (IS_ERR(onenand->ahb_addr))
+   return PTR_ERR(onenand->ahb_addr);
 
/* Allocate 4KiB BufferRAM */
-   onenand->page_buf = kzalloc(SZ_4K, GFP_KERNEL);
-   if (!onenand->page_buf) {
-   err = -ENOMEM;
-   goto page_buf_fail;
-   }
+   onenand->page_buf = devm_kzalloc(>dev, SZ_4K,
+GFP_KERNEL);
+   if (!onenand->page_buf)
+   return -ENOMEM;
 
  

[PATCH 0/4 v3] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths

[Christophe JAILLET]

The first patch converts 's3c_onenand_probe()' to devm_ functions.
This fixes a leak in one path (line 872).
This also free_irq which was not handled at all. ( I hope I'm correct :) )

The 2nd patch is about an un-handled error code which looks spurious.
Not sure if I'm right.

The 3rd patch propagates an error code instead of returning a hard-coded
value.

The last one removes a useless include spotted while compile-testing.


v3: patch 1/4 updated to fix a bug introduced in v2
patch 2/4 unchanged
patch 3/4 and 4/4 added
now the patch are cross-compile tested :)

Theses patches have been cross compile-tested-only.

Christophe JAILLET (4):
  mtd: onenand: samsung: use devm_ function to simplify
code and fix some leaks
  mtd: onenand: samsung: return an error if 
'mtd_device_parse_register()' fails
  mtd: onenand: samsung: Propagate the error returned
by 'onenand_scan()'
  mtd: onenand: samsung: Remove a useless include

 drivers/mtd/onenand/samsung.c | 172 +-
 1 file changed, 35 insertions(+), 137 deletions(-)

-- 
2.14.1

[PATCH 0/4 v3] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths

[Christophe JAILLET]

The first patch converts 's3c_onenand_probe()' to devm_ functions.
This fixes a leak in one path (line 872).
This also free_irq which was not handled at all. ( I hope I'm correct :) )

The 2nd patch is about an un-handled error code which looks spurious.
Not sure if I'm right.

The 3rd patch propagates an error code instead of returning a hard-coded
value.

The last one removes a useless include spotted while compile-testing.


v3: patch 1/4 updated to fix a bug introduced in v2
patch 2/4 unchanged
patch 3/4 and 4/4 added
now the patch are cross-compile tested :)

Theses patches have been cross compile-tested-only.

Christophe JAILLET (4):
  mtd: onenand: samsung: use devm_ function to simplify
code and fix some leaks
  mtd: onenand: samsung: return an error if 
'mtd_device_parse_register()' fails
  mtd: onenand: samsung: Propagate the error returned
by 'onenand_scan()'
  mtd: onenand: samsung: Remove a useless include

 drivers/mtd/onenand/samsung.c | 172 +-
 1 file changed, 35 insertions(+), 137 deletions(-)

-- 
2.14.1

linux-next: build failure after merge of the staging.current tree

[Stephen Rothwell]

Hi Greg,

After merging the staging.current tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate':
drivers/staging/android/ion/ion_cma_heap.c:38:14: error: 'CONFIG_CMA_ALIGNMENT' 
undeclared (first use in this function)
  if (align > CONFIG_CMA_ALIGNMENT)
  ^

Caused by commit

  d98e6dbf42f7 ("staging: ion: Fix ion_cma_heap allocations")

CONFIG_CMA_ALIGNMENT (and CONFIG_DMA_CMA) is not set for this build.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the staging.current tree

[Stephen Rothwell]

Hi Greg,

After merging the staging.current tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate':
drivers/staging/android/ion/ion_cma_heap.c:38:14: error: 'CONFIG_CMA_ALIGNMENT' 
undeclared (first use in this function)
  if (align > CONFIG_CMA_ALIGNMENT)
  ^

Caused by commit

  d98e6dbf42f7 ("staging: ion: Fix ion_cma_heap allocations")

CONFIG_CMA_ALIGNMENT (and CONFIG_DMA_CMA) is not set for this build.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

Re: About the try to remove cross-release feature entirely by Ingo

[Byungchul Park]

On Thu, Dec 14, 2017 at 12:07 PM, Theodore Ts'o  wrote:
> On Wed, Dec 13, 2017 at 04:13:07PM +0900, Byungchul Park wrote:
>>
>> Therefore, I want to say the fundamental problem
>> comes from classification, not cross-release
>> specific.
>
> You keep saying that it is "just" a matter of classificaion.

But, it's a fact.

> However, it is not obvious how to do the classification in a sane
> manner.  And this is why I keep pointing out that there is no
> documentation on how to do this, and somehow you never respond to this
> point

I can write a document explaining what lock class is but.. I
cannot explain how to assign it perfectly since there's no right
answer. It's something we need to improve more and more.

> In the case where you have multiple unrelated subsystems that can be
> stacked in different ways, with potentially multiple instances stacked
> on top of each other, it is not at all clear to me how this problem
> should be solved.

I cannot give you a perfect solution immediately. I know, and
as you know, it's a very difficult problem to solve.

> It was said on one of these threads (perhaps by you, perhaps by
> someone else), that we can't expect the lockdep maintainers to
> understand all of the subsystems in the kernels, and so therefore it
> must be up to the subsystem maintainers to classify the locks.  I
> interpreted this as the lockdep maintainers saying, "hey, not my
> fault, it's the subsystem maintainer's fault for not properly
> classifying the locks" --- and thus dumping the responsibility in the
> subsystem maintainers' laps.

Sorry to say, making you feel like that.

Precisely speaking, the responsibility for something caused by
cross-release is on me, and the responsibility for something caused
by lockdep itselt is on lockdep.

I meant, in the current way to assign lock class automatically, it's
inevitable for someone to annotate places manually, and it can be
done best by each expert. But, anyway fundamentally I think the
responsibility is on lockdep.

> I don't know if the situation is just that lockdep is insufficiently
> documented, and with the proper tutorial, it would be obvious how to
> solve the classification problem.
>
> Or, if perhaps, there *is* no way to solve the classification problem,
> at least not in a general form.

Agree. It's a very difficult one to solve.

> For example --- suppose we have a network block device on which there
> is an btrfs file system, which is then exported via NFS.  Now all of
> the TCP locks will be used twice for two different instances, once for
> the TCP connection for the network block device, and then for the NFS
> export.
>
> How exactly are we supposed to classify the locks to make it all work?
>
> Or the loop device built on top of an ext4 file system which on a
> LVM/device mapper device.  And suppose the loop device is then layered
> with a dm-error device for regression testing, and with another ext4
> file system on top of that?

Ditto.

> How exactly are we supposed to classify the locks in that situation?
> Where's the documentation and tutorials which explain how to make this
> work, if the responsibility is going to be dumped on the subsystem
> maintainers' laps?  Or if the lockdep maintainers are expected to fix
> and classify all of these locks, are you volunteering to do this?

I have the will. I will.

> How hard is it exactly to do all of this classification work, no
> matter whose responsibility it will ultimately be?
>
> And if the answer is that it is too hard, then let me gently suggest
> to you that perhaps, if this is a case, that maybe this is a
> fundamental and fatal flaw with the cross-release and completion
> lockdep feature?

I don't understand this.

> Best regards,
>
> - Ted



-- 
Thanks,
Byungchul

Re: About the try to remove cross-release feature entirely by Ingo

[Byungchul Park]

On Thu, Dec 14, 2017 at 12:07 PM, Theodore Ts'o  wrote:
> On Wed, Dec 13, 2017 at 04:13:07PM +0900, Byungchul Park wrote:
>>
>> Therefore, I want to say the fundamental problem
>> comes from classification, not cross-release
>> specific.
>
> You keep saying that it is "just" a matter of classificaion.

But, it's a fact.

> However, it is not obvious how to do the classification in a sane
> manner.  And this is why I keep pointing out that there is no
> documentation on how to do this, and somehow you never respond to this
> point

I can write a document explaining what lock class is but.. I
cannot explain how to assign it perfectly since there's no right
answer. It's something we need to improve more and more.

> In the case where you have multiple unrelated subsystems that can be
> stacked in different ways, with potentially multiple instances stacked
> on top of each other, it is not at all clear to me how this problem
> should be solved.

I cannot give you a perfect solution immediately. I know, and
as you know, it's a very difficult problem to solve.

> It was said on one of these threads (perhaps by you, perhaps by
> someone else), that we can't expect the lockdep maintainers to
> understand all of the subsystems in the kernels, and so therefore it
> must be up to the subsystem maintainers to classify the locks.  I
> interpreted this as the lockdep maintainers saying, "hey, not my
> fault, it's the subsystem maintainer's fault for not properly
> classifying the locks" --- and thus dumping the responsibility in the
> subsystem maintainers' laps.

Sorry to say, making you feel like that.

Precisely speaking, the responsibility for something caused by
cross-release is on me, and the responsibility for something caused
by lockdep itselt is on lockdep.

I meant, in the current way to assign lock class automatically, it's
inevitable for someone to annotate places manually, and it can be
done best by each expert. But, anyway fundamentally I think the
responsibility is on lockdep.

> I don't know if the situation is just that lockdep is insufficiently
> documented, and with the proper tutorial, it would be obvious how to
> solve the classification problem.
>
> Or, if perhaps, there *is* no way to solve the classification problem,
> at least not in a general form.

Agree. It's a very difficult one to solve.

> For example --- suppose we have a network block device on which there
> is an btrfs file system, which is then exported via NFS.  Now all of
> the TCP locks will be used twice for two different instances, once for
> the TCP connection for the network block device, and then for the NFS
> export.
>
> How exactly are we supposed to classify the locks to make it all work?
>
> Or the loop device built on top of an ext4 file system which on a
> LVM/device mapper device.  And suppose the loop device is then layered
> with a dm-error device for regression testing, and with another ext4
> file system on top of that?

Ditto.

> How exactly are we supposed to classify the locks in that situation?
> Where's the documentation and tutorials which explain how to make this
> work, if the responsibility is going to be dumped on the subsystem
> maintainers' laps?  Or if the lockdep maintainers are expected to fix
> and classify all of these locks, are you volunteering to do this?

I have the will. I will.

> How hard is it exactly to do all of this classification work, no
> matter whose responsibility it will ultimately be?
>
> And if the answer is that it is too hard, then let me gently suggest
> to you that perhaps, if this is a case, that maybe this is a
> fundamental and fatal flaw with the cross-release and completion
> lockdep feature?

I don't understand this.

> Best regards,
>
> - Ted



-- 
Thanks,
Byungchul

[PATCH v3 2/2] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

[Dhaval Shah]

Xilinx ZYNQMP logicoreIP Init driver is based on the new
LogiCoreIP design created. This driver provides the processing system
and programmable logic isolation. Set the frequency based on the clock
information get from the logicoreIP register set.

It is put in drivers/misc as there is no subsystem for this logicoreIP.

Signed-off-by: Dhaval Shah 
---
Changes since v3:
 No Changes.
Changes since v2:
 * Removed the "default n" from the Kconfig
 * More help text added to explain more about the logicoreIP driver
 * SPDX id is relocated at top of the file with // style comment
 * Removed the export API and header file and make it a single driver
   which provides logocoreIP init.
 * Provide the information in commit message as well for the why driver
   in drivers/misc.

 drivers/misc/Kconfig|  15 ++
 drivers/misc/Makefile   |   1 +
 drivers/misc/xlnx_vcu.c | 629 
 3 files changed, 645 insertions(+)
 create mode 100644 drivers/misc/xlnx_vcu.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c23..24ea516 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -496,6 +496,21 @@ config PCI_ENDPOINT_TEST
Enable this configuration option to enable the host side test driver
for PCI Endpoint.
 
+config XILINX_VCU
+   tristate "Xilinx VCU logicoreIP Init"
+   help
+ Provides the driver to enable and disable the isolation between the
+ processing system and programmable logic part by using the logicoreIP
+ register set. This driver also configure the frequency based on the
+ clock information get from the logicoreIP register set.
+
+ If you say yes here you get support for the logcoreIP.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called xlnx_vcu.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64..a6bd0b1 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)+= cxl/
 obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o
 obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
 obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
+obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
 
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_bugs.o
diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c
new file mode 100644
index 000..41819f0
--- /dev/null
+++ b/drivers/misc/xlnx_vcu.c
@@ -0,0 +1,629 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx VCU Init
+ *
+ * Copyright (C) 2016 - 2017 Xilinx, Inc.
+ *
+ * Contacts   Dhaval Shah 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Address map for different registers implemented in the VCU LogiCORE IP. */
+#define VCU_ECODER_ENABLE  0x00
+#define VCU_DECODER_ENABLE 0x04
+#define VCU_MEMORY_DEPTH   0x08
+#define VCU_ENC_COLOR_DEPTH0x0c
+#define VCU_ENC_VERTICAL_RANGE 0x10
+#define VCU_ENC_FRAME_SIZE_X   0x14
+#define VCU_ENC_FRAME_SIZE_Y   0x18
+#define VCU_ENC_COLOR_FORMAT   0x1c
+#define VCU_ENC_FPS0x20
+#define VCU_MCU_CLK0x24
+#define VCU_CORE_CLK   0x28
+#define VCU_PLL_BYPASS 0x2c
+#define VCU_ENC_CLK0x30
+#define VCU_PLL_CLK0x34
+#define VCU_ENC_VIDEO_STANDARD 0x38
+#define VCU_STATUS 0x3c
+#define VCU_AXI_ENC_CLK0x40
+#define VCU_AXI_DEC_CLK0x44
+#define VCU_AXI_MCU_CLK0x48
+#define VCU_DEC_VIDEO_STANDARD 0x4c
+#define VCU_DEC_FRAME_SIZE_X   0x50
+#define VCU_DEC_FRAME_SIZE_Y   0x54
+#define VCU_DEC_FPS0x58
+#define VCU_BUFFER_B_FRAME 0x5c
+#define VCU_WPP_EN 0x60
+#define VCU_PLL_CLK_DEC0x64
+#define VCU_GASKET_INIT0x74
+#define VCU_GASKET_VALUE   0x03
+
+/* vcu slcr registers, bitmask and shift */
+#define VCU_PLL_CTRL   0x24
+#define VCU_PLL_CTRL_RESET_MASK0x01
+#define VCU_PLL_CTRL_RESET_SHIFT   0
+#define VCU_PLL_CTRL_BYPASS_MASK   0x01
+#define VCU_PLL_CTRL_BYPASS_SHIFT  3
+#define VCU_PLL_CTRL_FBDIV_MASK0x7f
+#define VCU_PLL_CTRL_FBDIV_SHIFT   8
+#define VCU_PLL_CTRL_POR_IN_MASK   0x01
+#define VCU_PLL_CTRL_POR_IN_SHIFT  1
+#define VCU_PLL_CTRL_PWR_POR_MASK  0x01
+#define VCU_PLL_CTRL_PWR_POR_SHIFT 2
+#define VCU_PLL_CTRL_CLKOUTDIV_MASK0x03
+#define VCU_PLL_CTRL_CLKOUTDIV_SHIFT   16
+#define VCU_PLL_CTRL_DEFAULT 

[PATCH v3 1/2] dt-bindings: misc: Add DT bindings to xlnx_vcu driver

[Dhaval Shah]

Add Device Tree binding document for logicoreIP. This logicoreIP
provides the isolation between the processing system and
programmable logic. Also provides the clock related information.

Signed-off-by: Dhaval Shah 
---
Chnages since v3:
 * Use "dt-bindings: misc: ..." for the subject.
Changes since v2:
 * Describe the h/w
 * compatible string is updated to make it more specific
   based on the logicoreIP version.
 * Removed that encoder and decoder child nodes and relatd properties as that
   will be a separate driver and dts nodes. other team is working on that.
 * Updated to use as a single driver.

 .../devicetree/bindings/misc/xlnx,vcu.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt

diff --git a/Documentation/devicetree/bindings/misc/xlnx,vcu.txt 
b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
new file mode 100644
index 000..6786d67
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
@@ -0,0 +1,31 @@
+LogicoreIP designed compatible with Xilinx ZYNQ family.
+---
+
+General concept
+---
+
+LogicoreIP design to provide the isolation between processing system
+and programmable logic. Also provides the list of register set to configure
+the frequency.
+
+Required properties:
+- compatible: shall be one of:
+   "xlnx,vcu"
+   "xlnx,vcu-logicoreip-1.0"
+- reg, reg-names: There are two sets of registers need to provide.
+   1. vcu slcr
+   2. Logicore
+   reg-names should contain name for the each register sequence.
+- clocks: phandle for aclk and pll_ref clocksource
+- clock-names: The identification string, "aclk", is always required for
+   the axi clock. "pll_ref" is required for pll.
+Example:
+
+   xlnx_vcu: vcu@a004 {
+   compatible = "xlnx,vcu-logicoreip-1.0";
+   reg = <0x0 0xa004 0x0 0x1000>,
+<0x0 0xa0041000 0x0 0x1000>;
+   reg-names = "vcu_slcr", "logicore";
+   clocks = <_1>, < 71>;
+   clock-names = "pll_ref", "aclk";
+   };
-- 
2.7.4

[PATCH v3 2/2] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

[Dhaval Shah]

Xilinx ZYNQMP logicoreIP Init driver is based on the new
LogiCoreIP design created. This driver provides the processing system
and programmable logic isolation. Set the frequency based on the clock
information get from the logicoreIP register set.

It is put in drivers/misc as there is no subsystem for this logicoreIP.

Signed-off-by: Dhaval Shah 
---
Changes since v3:
 No Changes.
Changes since v2:
 * Removed the "default n" from the Kconfig
 * More help text added to explain more about the logicoreIP driver
 * SPDX id is relocated at top of the file with // style comment
 * Removed the export API and header file and make it a single driver
   which provides logocoreIP init.
 * Provide the information in commit message as well for the why driver
   in drivers/misc.

 drivers/misc/Kconfig|  15 ++
 drivers/misc/Makefile   |   1 +
 drivers/misc/xlnx_vcu.c | 629 
 3 files changed, 645 insertions(+)
 create mode 100644 drivers/misc/xlnx_vcu.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c23..24ea516 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -496,6 +496,21 @@ config PCI_ENDPOINT_TEST
Enable this configuration option to enable the host side test driver
for PCI Endpoint.
 
+config XILINX_VCU
+   tristate "Xilinx VCU logicoreIP Init"
+   help
+ Provides the driver to enable and disable the isolation between the
+ processing system and programmable logic part by using the logicoreIP
+ register set. This driver also configure the frequency based on the
+ clock information get from the logicoreIP register set.
+
+ If you say yes here you get support for the logcoreIP.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called xlnx_vcu.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64..a6bd0b1 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)+= cxl/
 obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o
 obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
 obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
+obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
 
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_bugs.o
diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c
new file mode 100644
index 000..41819f0
--- /dev/null
+++ b/drivers/misc/xlnx_vcu.c
@@ -0,0 +1,629 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx VCU Init
+ *
+ * Copyright (C) 2016 - 2017 Xilinx, Inc.
+ *
+ * Contacts   Dhaval Shah 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Address map for different registers implemented in the VCU LogiCORE IP. */
+#define VCU_ECODER_ENABLE  0x00
+#define VCU_DECODER_ENABLE 0x04
+#define VCU_MEMORY_DEPTH   0x08
+#define VCU_ENC_COLOR_DEPTH0x0c
+#define VCU_ENC_VERTICAL_RANGE 0x10
+#define VCU_ENC_FRAME_SIZE_X   0x14
+#define VCU_ENC_FRAME_SIZE_Y   0x18
+#define VCU_ENC_COLOR_FORMAT   0x1c
+#define VCU_ENC_FPS0x20
+#define VCU_MCU_CLK0x24
+#define VCU_CORE_CLK   0x28
+#define VCU_PLL_BYPASS 0x2c
+#define VCU_ENC_CLK0x30
+#define VCU_PLL_CLK0x34
+#define VCU_ENC_VIDEO_STANDARD 0x38
+#define VCU_STATUS 0x3c
+#define VCU_AXI_ENC_CLK0x40
+#define VCU_AXI_DEC_CLK0x44
+#define VCU_AXI_MCU_CLK0x48
+#define VCU_DEC_VIDEO_STANDARD 0x4c
+#define VCU_DEC_FRAME_SIZE_X   0x50
+#define VCU_DEC_FRAME_SIZE_Y   0x54
+#define VCU_DEC_FPS0x58
+#define VCU_BUFFER_B_FRAME 0x5c
+#define VCU_WPP_EN 0x60
+#define VCU_PLL_CLK_DEC0x64
+#define VCU_GASKET_INIT0x74
+#define VCU_GASKET_VALUE   0x03
+
+/* vcu slcr registers, bitmask and shift */
+#define VCU_PLL_CTRL   0x24
+#define VCU_PLL_CTRL_RESET_MASK0x01
+#define VCU_PLL_CTRL_RESET_SHIFT   0
+#define VCU_PLL_CTRL_BYPASS_MASK   0x01
+#define VCU_PLL_CTRL_BYPASS_SHIFT  3
+#define VCU_PLL_CTRL_FBDIV_MASK0x7f
+#define VCU_PLL_CTRL_FBDIV_SHIFT   8
+#define VCU_PLL_CTRL_POR_IN_MASK   0x01
+#define VCU_PLL_CTRL_POR_IN_SHIFT  1
+#define VCU_PLL_CTRL_PWR_POR_MASK  0x01
+#define VCU_PLL_CTRL_PWR_POR_SHIFT 2
+#define VCU_PLL_CTRL_CLKOUTDIV_MASK0x03
+#define VCU_PLL_CTRL_CLKOUTDIV_SHIFT   16
+#define VCU_PLL_CTRL_DEFAULT   0
+#define VCU_PLL_DIV2   

[PATCH v3 1/2] dt-bindings: misc: Add DT bindings to xlnx_vcu driver

[Dhaval Shah]

Add Device Tree binding document for logicoreIP. This logicoreIP
provides the isolation between the processing system and
programmable logic. Also provides the clock related information.

Signed-off-by: Dhaval Shah 
---
Chnages since v3:
 * Use "dt-bindings: misc: ..." for the subject.
Changes since v2:
 * Describe the h/w
 * compatible string is updated to make it more specific
   based on the logicoreIP version.
 * Removed that encoder and decoder child nodes and relatd properties as that
   will be a separate driver and dts nodes. other team is working on that.
 * Updated to use as a single driver.

 .../devicetree/bindings/misc/xlnx,vcu.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt

diff --git a/Documentation/devicetree/bindings/misc/xlnx,vcu.txt 
b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
new file mode 100644
index 000..6786d67
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
@@ -0,0 +1,31 @@
+LogicoreIP designed compatible with Xilinx ZYNQ family.
+---
+
+General concept
+---
+
+LogicoreIP design to provide the isolation between processing system
+and programmable logic. Also provides the list of register set to configure
+the frequency.
+
+Required properties:
+- compatible: shall be one of:
+   "xlnx,vcu"
+   "xlnx,vcu-logicoreip-1.0"
+- reg, reg-names: There are two sets of registers need to provide.
+   1. vcu slcr
+   2. Logicore
+   reg-names should contain name for the each register sequence.
+- clocks: phandle for aclk and pll_ref clocksource
+- clock-names: The identification string, "aclk", is always required for
+   the axi clock. "pll_ref" is required for pll.
+Example:
+
+   xlnx_vcu: vcu@a004 {
+   compatible = "xlnx,vcu-logicoreip-1.0";
+   reg = <0x0 0xa004 0x0 0x1000>,
+<0x0 0xa0041000 0x0 0x1000>;
+   reg-names = "vcu_slcr", "logicore";
+   clocks = <_1>, < 71>;
+   clock-names = "pll_ref", "aclk";
+   };
-- 
2.7.4

[PATCH v3 0/2] Documentation and driver of logicoreIP

[Dhaval Shah]

1st patch provide Device Tree binding document for logicoreIP
2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes
and Makefile changes for the driver.

Dhaval Shah (2):
  Documentation: devicetree: Add DT bindings to xlnx_vcu driver
  misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

 .../devicetree/bindings/misc/xlnx,vcu.txt  |  31 +
 drivers/misc/Kconfig   |  15 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/xlnx_vcu.c| 629 +
 4 files changed, 676 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt
 create mode 100644 drivers/misc/xlnx_vcu.c

-- 
2.7.4

[PATCH v3 0/2] Documentation and driver of logicoreIP

[Dhaval Shah]

1st patch provide Device Tree binding document for logicoreIP
2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes
and Makefile changes for the driver.

Dhaval Shah (2):
  Documentation: devicetree: Add DT bindings to xlnx_vcu driver
  misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

 .../devicetree/bindings/misc/xlnx,vcu.txt  |  31 +
 drivers/misc/Kconfig   |  15 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/xlnx_vcu.c| 629 +
 4 files changed, 676 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt
 create mode 100644 drivers/misc/xlnx_vcu.c

-- 
2.7.4