Re: [PATCH] exit: move exit_task_namespaces() after exit_task_work()

[Dmitry Vyukov]

On Sat, Dec 16, 2017 at 1:00 AM, Cong Wang  wrote:
> syzbot reported we have a use-after-free when mqueue_evict_inode()
> is called on __cleanup_mnt() path, where the ipc ns is already
> freed by the previous exit_task_namespaces(). We can just move
> it after after exit_task_work() to avoid this use-after-free.

 How does that possibly work. (I haven't seen this syzbot report).

 Looking at the code we have get_ns_from_inode.  Which takes the mq_lock,
 sees if the pointer is NULL and takes a reference if it is non-NULL.

 Meanwhile put_ipc_ns calls mq_clear_sbinfo(ns) with the mq_lock held
 when the count drops to zero.

 Where is the race in that?

 The rest of mqueue_evict_inode uses the returned pointer and
 tests that the pointer is non-NULL before user it.

 So either szbot is giving you a bad report or there is a subtle race
 there I am not seeing.  The change below is not at all the proper way to
 fix a subtle race.

 Eric
>>>
>>> Cong, what was that report? Searching by
>>> "exit_task_work|exit_task_namespaces" there are too many of them:
>>> https://groups.google.com/forum/#!searchin/syzkaller-bugs/%22exit_task_work$7Cexit_task_namespaces%22%7Csort:date
>>>
>>> I can only say that syzbot does not make up reports. That's something
>>> that actually happened and was provoked by userspace.
>>
>>
>> Ah, found that bug:
>> https://groups.google.com/d/msg/syzkaller-bugs/1XBaqnPSXzs/VF-eCSPuCQAJ
>
> Yeah, and it is introduced by:
>
> http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/commit/?id=9c583773d036336176e9e50441890659bc4eeae8


If it's going to be discussed here, note that it was reported by
syzbot and requires "#syz fix" tag after fixing here:
https://groups.google.com/d/msg/syzkaller-bugs/1XBaqnPSXzs/jGDCMoz_AQAJ

Re: [PATCH] exit: move exit_task_namespaces() after exit_task_work()

[Dmitry Vyukov]

On Sat, Dec 16, 2017 at 1:00 AM, Cong Wang  wrote:
> syzbot reported we have a use-after-free when mqueue_evict_inode()
> is called on __cleanup_mnt() path, where the ipc ns is already
> freed by the previous exit_task_namespaces(). We can just move
> it after after exit_task_work() to avoid this use-after-free.

 How does that possibly work. (I haven't seen this syzbot report).

 Looking at the code we have get_ns_from_inode.  Which takes the mq_lock,
 sees if the pointer is NULL and takes a reference if it is non-NULL.

 Meanwhile put_ipc_ns calls mq_clear_sbinfo(ns) with the mq_lock held
 when the count drops to zero.

 Where is the race in that?

 The rest of mqueue_evict_inode uses the returned pointer and
 tests that the pointer is non-NULL before user it.

 So either szbot is giving you a bad report or there is a subtle race
 there I am not seeing.  The change below is not at all the proper way to
 fix a subtle race.

 Eric
>>>
>>> Cong, what was that report? Searching by
>>> "exit_task_work|exit_task_namespaces" there are too many of them:
>>> https://groups.google.com/forum/#!searchin/syzkaller-bugs/%22exit_task_work$7Cexit_task_namespaces%22%7Csort:date
>>>
>>> I can only say that syzbot does not make up reports. That's something
>>> that actually happened and was provoked by userspace.
>>
>>
>> Ah, found that bug:
>> https://groups.google.com/d/msg/syzkaller-bugs/1XBaqnPSXzs/VF-eCSPuCQAJ
>
> Yeah, and it is introduced by:
>
> http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/commit/?id=9c583773d036336176e9e50441890659bc4eeae8


If it's going to be discussed here, note that it was reported by
syzbot and requires "#syz fix" tag after fixing here:
https://groups.google.com/d/msg/syzkaller-bugs/1XBaqnPSXzs/jGDCMoz_AQAJ

Re: [PATCH] mm: Reduce memory bloat with THP

[Nitin Gupta]

On 12/15/17 2:01 AM, Kirill A. Shutemov wrote:
> On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 751e97a..b2ec07b 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -508,6 +508,7 @@ static long madvise_dontneed_single_vma(struct 
>> vm_area_struct *vma,
>>  unsigned long start, unsigned long end)
>>  {
>>  zap_page_range(vma, start, end - start);
>> +vma->space_efficient = true;
>>  return 0;
>>  }
>>  
> 
> And this modifies vma without down_write(mmap_sem).
> 

I thought this function was always called with mmmap_sem write locked.
I will check again.

- Nitin

Re: [PATCH] mm: Reduce memory bloat with THP

[Nitin Gupta]

On 12/15/17 2:01 AM, Kirill A. Shutemov wrote:
> On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 751e97a..b2ec07b 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -508,6 +508,7 @@ static long madvise_dontneed_single_vma(struct 
>> vm_area_struct *vma,
>>  unsigned long start, unsigned long end)
>>  {
>>  zap_page_range(vma, start, end - start);
>> +vma->space_efficient = true;
>>  return 0;
>>  }
>>  
> 
> And this modifies vma without down_write(mmap_sem).
> 

I thought this function was always called with mmmap_sem write locked.
I will check again.

- Nitin

Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

[Tetsuo Handa]

On 2017/12/16 8:04, Andrew Morton wrote:
>> The implementation is steered toward an expensive slowpath, such as after
>> the oom reaper has grabbed mm->mmap_sem of a still alive oom victim.
> 
> some tweakage, please review.
> 
> From: Andrew Morton 
> Subject: 
> mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks-fix
> 
> make mm_has_blockable_invalidate_notifiers() return bool, use 
> rwsem_is_locked()
> 

> @@ -240,13 +240,13 @@ EXPORT_SYMBOL_GPL(__mmu_notifier_invalid
>   * Must be called while holding mm->mmap_sem for either read or write.
>   * The result is guaranteed to be valid until mm->mmap_sem is dropped.
>   */
> -int mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
> +bool mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
>  {
>   struct mmu_notifier *mn;
>   int id;
> - int ret = 0;
> + bool ret = false;
>  
> - WARN_ON_ONCE(down_write_trylock(>mmap_sem));
> + WARN_ON_ONCE(!rwsem_is_locked(>mmap_sem));
>  
>   if (!mm_has_notifiers(mm))
>   return ret;

rwsem_is_locked() test isn't equivalent with __mutex_owner() == current test, 
is it?
If rwsem_is_locked() returns true because somebody else has locked it, there is
no guarantee that current thread has locked it before calling this function.

down_write_trylock() test isn't equivalent with __mutex_owner() == current 
test, is it?
What if somebody else held it for read or write (the worst case is registration 
path),
down_write_trylock() will return false even if current thread has not locked it 
for
read or write.

I think this WARN_ON_ONCE() can not detect incorrect call to this function.

Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

[Tetsuo Handa]

On 2017/12/16 8:04, Andrew Morton wrote:
>> The implementation is steered toward an expensive slowpath, such as after
>> the oom reaper has grabbed mm->mmap_sem of a still alive oom victim.
> 
> some tweakage, please review.
> 
> From: Andrew Morton 
> Subject: 
> mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks-fix
> 
> make mm_has_blockable_invalidate_notifiers() return bool, use 
> rwsem_is_locked()
> 

> @@ -240,13 +240,13 @@ EXPORT_SYMBOL_GPL(__mmu_notifier_invalid
>   * Must be called while holding mm->mmap_sem for either read or write.
>   * The result is guaranteed to be valid until mm->mmap_sem is dropped.
>   */
> -int mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
> +bool mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
>  {
>   struct mmu_notifier *mn;
>   int id;
> - int ret = 0;
> + bool ret = false;
>  
> - WARN_ON_ONCE(down_write_trylock(>mmap_sem));
> + WARN_ON_ONCE(!rwsem_is_locked(>mmap_sem));
>  
>   if (!mm_has_notifiers(mm))
>   return ret;

rwsem_is_locked() test isn't equivalent with __mutex_owner() == current test, 
is it?
If rwsem_is_locked() returns true because somebody else has locked it, there is
no guarantee that current thread has locked it before calling this function.

down_write_trylock() test isn't equivalent with __mutex_owner() == current 
test, is it?
What if somebody else held it for read or write (the worst case is registration 
path),
down_write_trylock() will return false even if current thread has not locked it 
for
read or write.

I think this WARN_ON_ONCE() can not detect incorrect call to this function.

Re: [Question ]: Avoid kernel panic when killing an application if happen RAS page table error

[gengdongjiu]

On 2017/12/16 3:35, Matthew Wilcox wrote:
>> It's going to be complicated to do, I don't think its worth the effort.
> We can find a bit in struct page that we guarantee will only be set if
> this is allocated as a pagetable.  Bit 1 of the third union is currently
> available (compound_head is a pointer if bit 0 is set, so nothing is
> using bit 1).  We can put a pointer to the mm_struct in the same word.
> 
> Finding all the allocated pages will be the tricky bit.  We could put a
> list_head into struct page; perhaps in the same spot as page_deferred_list
> for tail pages.  Then we can link all the pagetables belonging to
> this mm together and tear them all down if any of them get an error.
> They'll repopulate on demand.  It won't be quick or scalable, but when
> the alternative is death, it looks relatively attractive.
Thanks for the comments, I will check it in detailed and investigate whether it 
is worth to do for it.
Thanks!

> 
> .
> 

Re: [Question ]: Avoid kernel panic when killing an application if happen RAS page table error

[gengdongjiu]

On 2017/12/16 3:35, Matthew Wilcox wrote:
>> It's going to be complicated to do, I don't think its worth the effort.
> We can find a bit in struct page that we guarantee will only be set if
> this is allocated as a pagetable.  Bit 1 of the third union is currently
> available (compound_head is a pointer if bit 0 is set, so nothing is
> using bit 1).  We can put a pointer to the mm_struct in the same word.
> 
> Finding all the allocated pages will be the tricky bit.  We could put a
> list_head into struct page; perhaps in the same spot as page_deferred_list
> for tail pages.  Then we can link all the pagetables belonging to
> this mm together and tear them all down if any of them get an error.
> They'll repopulate on demand.  It won't be quick or scalable, but when
> the alternative is death, it looks relatively attractive.
Thanks for the comments, I will check it in detailed and investigate whether it 
is worth to do for it.
Thanks!

> 
> .
> 

Re: [PATCH] mm: Reduce memory bloat with THP

[Nitin Gupta]

On 12/15/17 2:00 AM, Kirill A. Shutemov wrote:
> On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
>> Currently, if the THP enabled policy is "always", or the mode
>> is "madvise" and a region is marked as MADV_HUGEPAGE, a hugepage
>> is allocated on a page fault if the pud or pmd is empty.  This
>> yields the best VA translation performance, but increases memory
>> consumption if some small page ranges within the huge page are
>> never accessed.
>>
>> An alternate behavior for such page faults is to install a
>> hugepage only when a region is actually found to be (almost)
>> fully mapped and active.  This is a compromise between
>> translation performance and memory consumption.  Currently there
>> is no way for an application to choose this compromise for the
>> page fault conditions above.
>>
>> With this change, when an application issues MADV_DONTNEED on a
>> memory region, the region is marked as "space-efficient". For
>> such regions, a hugepage is not immediately allocated on first
>> write.  Instead, it is left to the khugepaged thread to do
>> delayed hugepage promotion depending on whether the region is
>> actually mapped and active. When application issues
>> MADV_HUGEPAGE, the region is marked again as non-space-efficient
>> wherein hugepage is allocated on first touch.
> 
> I think this would be NAK. At least in this form.
> 
> What performance testing have you done? Any numbers?
> 

I wrote a throw-away code which mmaps 128G area and writes to a random
address in a loop. Together with writes, madvise(MADV_DONTNEED) are
issued at another random addresses. Writes are issued with 70%
probability and DONTNEED with 30%. With this test, I'm trying to emulate
workload of a large in-memory hash-table.

With the patch, I see that memory bloat is much less severe.
I've uploaded the test program with the memory usage plot here:

https://gist.github.com/nitingupta910/42ddf969e17556d74a14fbd84640ddb3

THP was set to 'always' mode in both cases but the result would be the
same if madvise mode was used instead.

> Making whole vma "space_efficient" just because somebody freed one page
> from it is just wrong. And there's no way back after this.
>

I'm using MADV_DONTNEED as a hint that although user wants to
transparently use hugepages but at the same time wants to be more
conservative with respect to memory usage. If a MADV_HUGEPAGE is issued
for a VMA range after any DONTNEEDs then the space_efficient bit is
again cleared, so we revert back to allocating hugepage on fault on
empty pud/pmd.

>>
>> Orabug: 26910556
> 
> Wat?
> 

It's oracle internal identifier used to track this work.

Thanks,
Nitin

Re: [PATCH] mm: Reduce memory bloat with THP

[Nitin Gupta]

On 12/15/17 2:00 AM, Kirill A. Shutemov wrote:
> On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
>> Currently, if the THP enabled policy is "always", or the mode
>> is "madvise" and a region is marked as MADV_HUGEPAGE, a hugepage
>> is allocated on a page fault if the pud or pmd is empty.  This
>> yields the best VA translation performance, but increases memory
>> consumption if some small page ranges within the huge page are
>> never accessed.
>>
>> An alternate behavior for such page faults is to install a
>> hugepage only when a region is actually found to be (almost)
>> fully mapped and active.  This is a compromise between
>> translation performance and memory consumption.  Currently there
>> is no way for an application to choose this compromise for the
>> page fault conditions above.
>>
>> With this change, when an application issues MADV_DONTNEED on a
>> memory region, the region is marked as "space-efficient". For
>> such regions, a hugepage is not immediately allocated on first
>> write.  Instead, it is left to the khugepaged thread to do
>> delayed hugepage promotion depending on whether the region is
>> actually mapped and active. When application issues
>> MADV_HUGEPAGE, the region is marked again as non-space-efficient
>> wherein hugepage is allocated on first touch.
> 
> I think this would be NAK. At least in this form.
> 
> What performance testing have you done? Any numbers?
> 

I wrote a throw-away code which mmaps 128G area and writes to a random
address in a loop. Together with writes, madvise(MADV_DONTNEED) are
issued at another random addresses. Writes are issued with 70%
probability and DONTNEED with 30%. With this test, I'm trying to emulate
workload of a large in-memory hash-table.

With the patch, I see that memory bloat is much less severe.
I've uploaded the test program with the memory usage plot here:

https://gist.github.com/nitingupta910/42ddf969e17556d74a14fbd84640ddb3

THP was set to 'always' mode in both cases but the result would be the
same if madvise mode was used instead.

> Making whole vma "space_efficient" just because somebody freed one page
> from it is just wrong. And there's no way back after this.
>

I'm using MADV_DONTNEED as a hint that although user wants to
transparently use hugepages but at the same time wants to be more
conservative with respect to memory usage. If a MADV_HUGEPAGE is issued
for a VMA range after any DONTNEEDs then the space_efficient bit is
again cleared, so we revert back to allocating hugepage on fault on
empty pud/pmd.

>>
>> Orabug: 26910556
> 
> Wat?
> 

It's oracle internal identifier used to track this work.

Thanks,
Nitin

Re: [PATCH 5/8] drm/sun4i: Add a driver for the display frontend

[kbuild test robot]

Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on ]

url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the 
linux-review/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
 HEAD c38c4ce4b14c4c68a9fde0cc35ead5b1c894776b builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_bind':
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:22: error: implicit declaration of 
>> function 'sun4i_backend_find_frontend'; did you mean 'sun4i_backend_bind'? 
>> [-Werror=implicit-function-declaration]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
 ^~~
 sun4i_backend_bind
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:20: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
   ^
   cc1: some warnings being treated as errors

vim +370 drivers/gpu/drm/sun4i/sun4i_backend.c

   346  
   347  static int sun4i_backend_bind(struct device *dev, struct device *master,
   348void *data)
   349  {
   350  struct platform_device *pdev = to_platform_device(dev);
   351  struct drm_device *drm = data;
   352  struct sun4i_drv *drv = drm->dev_private;
   353  struct sun4i_backend *backend;
   354  const struct sun4i_backend_quirks *quirks;
   355  struct resource *res;
   356  void __iomem *regs;
   357  int i, ret;
   358  
   359  backend = devm_kzalloc(dev, sizeof(*backend), GFP_KERNEL);
   360  if (!backend)
   361  return -ENOMEM;
   362  dev_set_drvdata(dev, backend);
   363  
   364  backend->engine.node = dev->of_node;
   365  backend->engine.ops = _backend_engine_ops;
   366  backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
   367  if (backend->engine.id < 0)
   368  return backend->engine.id;
   369  
 > 370  backend->frontend = sun4i_backend_find_frontend(drv, 
 > dev->of_node);
   371  if (IS_ERR(backend->frontend)) {
   372  dev_err(dev, "Couldn't find matching frontend, frontend 
features disabled\n");
   373  }
   374  
   375  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   376  regs = devm_ioremap_resource(dev, res);
   377  if (IS_ERR(regs))
   378  return PTR_ERR(regs);
   379  
   380  backend->reset = devm_reset_control_get(dev, NULL);
   381  if (IS_ERR(backend->reset)) {
   382  dev_err(dev, "Couldn't get our reset line\n");
   383  return PTR_ERR(backend->reset);
   384  }
   385  
   386  ret = reset_control_deassert(backend->reset);
   387  if (ret) {
   388  dev_err(dev, "Couldn't deassert our reset line\n");
   389  return ret;
   390  }
   391  
   392  backend->bus_clk = devm_clk_get(dev, "ahb");
   393  if (IS_ERR(backend->bus_clk)) {
   394  dev_err(dev, "Couldn't get the backend bus clock\n");
   395  ret = PTR_ERR(backend->bus_clk);
   396  goto err_assert_reset;
   397  }
   398  clk_prepare_enable(backend->bus_clk);
   399  
   400  backend->mod_clk = devm_clk_get(dev, "mod");
   401  if (IS_ERR(backend->mod_clk)) {
   402  dev_err(dev, "Couldn't get the backend module clock\n");
   403  ret = PTR_ERR(backend->mod_clk);
   404  goto err_disable_bus_clk;
   405  }
   406  clk_prepare_enable(backend->mod_clk);
   407  
   408  backend->ram_clk = devm_clk_get(dev, "ram");
   409  if (IS_ERR(backend->ram_clk)) {
   410  dev_err(dev, "Couldn't get the backend RAM clock\n");
   411  ret = PTR_ERR(backend->ram_clk);
   412  goto err_disable_mod_clk;
   413  }
   414  clk_prepare_enable(backend->ram_clk);
   415  
   416  if (of_device_is_compatible(dev->of_node,
   417  
"allwinner,sun8i-a33-display-backend")) {
   418  ret = sun4i_backend_init_sat(dev);
   419  if (ret) {
   420  

Re: [PATCH 5/8] drm/sun4i: Add a driver for the display frontend

[kbuild test robot]

Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on ]

url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the 
linux-review/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
 HEAD c38c4ce4b14c4c68a9fde0cc35ead5b1c894776b builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_bind':
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:22: error: implicit declaration of 
>> function 'sun4i_backend_find_frontend'; did you mean 'sun4i_backend_bind'? 
>> [-Werror=implicit-function-declaration]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
 ^~~
 sun4i_backend_bind
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:20: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
   ^
   cc1: some warnings being treated as errors

vim +370 drivers/gpu/drm/sun4i/sun4i_backend.c

   346  
   347  static int sun4i_backend_bind(struct device *dev, struct device *master,
   348void *data)
   349  {
   350  struct platform_device *pdev = to_platform_device(dev);
   351  struct drm_device *drm = data;
   352  struct sun4i_drv *drv = drm->dev_private;
   353  struct sun4i_backend *backend;
   354  const struct sun4i_backend_quirks *quirks;
   355  struct resource *res;
   356  void __iomem *regs;
   357  int i, ret;
   358  
   359  backend = devm_kzalloc(dev, sizeof(*backend), GFP_KERNEL);
   360  if (!backend)
   361  return -ENOMEM;
   362  dev_set_drvdata(dev, backend);
   363  
   364  backend->engine.node = dev->of_node;
   365  backend->engine.ops = _backend_engine_ops;
   366  backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
   367  if (backend->engine.id < 0)
   368  return backend->engine.id;
   369  
 > 370  backend->frontend = sun4i_backend_find_frontend(drv, 
 > dev->of_node);
   371  if (IS_ERR(backend->frontend)) {
   372  dev_err(dev, "Couldn't find matching frontend, frontend 
features disabled\n");
   373  }
   374  
   375  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   376  regs = devm_ioremap_resource(dev, res);
   377  if (IS_ERR(regs))
   378  return PTR_ERR(regs);
   379  
   380  backend->reset = devm_reset_control_get(dev, NULL);
   381  if (IS_ERR(backend->reset)) {
   382  dev_err(dev, "Couldn't get our reset line\n");
   383  return PTR_ERR(backend->reset);
   384  }
   385  
   386  ret = reset_control_deassert(backend->reset);
   387  if (ret) {
   388  dev_err(dev, "Couldn't deassert our reset line\n");
   389  return ret;
   390  }
   391  
   392  backend->bus_clk = devm_clk_get(dev, "ahb");
   393  if (IS_ERR(backend->bus_clk)) {
   394  dev_err(dev, "Couldn't get the backend bus clock\n");
   395  ret = PTR_ERR(backend->bus_clk);
   396  goto err_assert_reset;
   397  }
   398  clk_prepare_enable(backend->bus_clk);
   399  
   400  backend->mod_clk = devm_clk_get(dev, "mod");
   401  if (IS_ERR(backend->mod_clk)) {
   402  dev_err(dev, "Couldn't get the backend module clock\n");
   403  ret = PTR_ERR(backend->mod_clk);
   404  goto err_disable_bus_clk;
   405  }
   406  clk_prepare_enable(backend->mod_clk);
   407  
   408  backend->ram_clk = devm_clk_get(dev, "ram");
   409  if (IS_ERR(backend->ram_clk)) {
   410  dev_err(dev, "Couldn't get the backend RAM clock\n");
   411  ret = PTR_ERR(backend->ram_clk);
   412  goto err_disable_mod_clk;
   413  }
   414  clk_prepare_enable(backend->ram_clk);
   415  
   416  if (of_device_is_compatible(dev->of_node,
   417  
"allwinner,sun8i-a33-display-backend")) {
   418  ret = sun4i_backend_init_sat(dev);
   419  if (ret) {
   420  

[PATCH 1/1] usb: xhci: dbc: Fix lockdep warning

[Lu Baolu]

The xHCI DbC implementation might enter a deadlock situation because
there is no sufficient protection against the shared data between
process and softirq contexts. This can lead to the following lockdep
warnings. This patch changes to use spin_{,un}lock_irq{save,restore}
to avoid potential deadlock.

[ 528.248084] 
[ 528.252914] WARNING: inconsistent lock state
[ 528.257756] 4.15.0-rc1+ #1630 Not tainted
[ 528.262305] 
[ 528.267145] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 528.273953] ksoftirqd/1/17 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 528.280075] (&(>port_lock)->rlock){+.?.}, at: [] 
dbc_rx_push+0x38/0x1c0
[ 528.290043] {SOFTIRQ-ON-W} state was registered at:
[ 528.295570] _raw_spin_lock+0x2f/0x40
[ 528.299818] dbc_write_complete+0x27/0xa0
[ 528.304458] xhci_dbc_giveback+0xd1/0x200
[ 528.309098] xhci_dbc_flush_endpoint_requests+0x50/0x70
[ 528.315116] xhci_dbc_handle_events+0x696/0x7b0
[ 528.320349] process_one_work+0x1ee/0x6e0
[ 528.324988] worker_thread+0x4a/0x430
[ 528.329236] kthread+0x13e/0x170
[ 528.332992] ret_from_fork+0x24/0x30
[ 528.337141] irq event stamp: 2861
[ 528.340897] hardirqs last enabled at (2860): [] 
tasklet_action+0x6a/0x250
[ 528.350460] hardirqs last disabled at (2861): [] 
_raw_spin_lock_irq+0xf/0x40
[ 528.360219] softirqs last enabled at (2852): [] 
__do_softirq+0x3dc/0x4f9
[ 528.369683] softirqs last disabled at (2857): [] 
run_ksoftirqd+0x1b/0x60
[ 528.379048]
[ 528.379048] other info that might help us debug this:
[ 528.386443] Possible unsafe locking scenario:
[ 528.386443]
[ 528.393150] CPU0
[ 528.395917] 
[ 528.398687] lock(&(>port_lock)->rlock);
[ 528.403821] 
[ 528.406786] lock(&(>port_lock)->rlock);
[ 528.412116]
[ 528.412116] *** DEADLOCK ***
[ 528.412116]
[ 528.418825] no locks held by ksoftirqd/1/17.
[ 528.423662]
[ 528.423662] stack backtrace:
[ 528.428598] CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.15.0-rc1+ #1630
[ 528.436387] Call Trace:
[ 528.439158] dump_stack+0x5e/0x8e
[ 528.442914] print_usage_bug+0x1fc/0x220
[ 528.447357] mark_lock+0x4db/0x5a0
[ 528.451210] __lock_acquire+0x726/0x1130
[ 528.455655] ? __lock_acquire+0x557/0x1130
[ 528.460296] lock_acquire+0xa2/0x200
[ 528.464347] ? dbc_rx_push+0x38/0x1c0
[ 528.468496] _raw_spin_lock_irq+0x35/0x40
[ 528.473038] ? dbc_rx_push+0x38/0x1c0
[ 528.477186] dbc_rx_push+0x38/0x1c0
[ 528.481139] tasklet_action+0x1d2/0x250
[ 528.485483] __do_softirq+0x1dc/0x4f9
[ 528.489630] run_ksoftirqd+0x1b/0x60
[ 528.493682] smpboot_thread_fn+0x179/0x270
[ 528.498324] kthread+0x13e/0x170
[ 528.501981] ? sort_range+0x20/0x20
[ 528.505933] ? kthread_delayed_work_timer_fn+0x80/0x80
[ 528.511755] ret_from_fork+0x24/0x30

Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-dbgcap.c | 20 
 drivers/usb/host/xhci-dbgtty.c | 20 
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
index 452df0f..c048d2a 100644
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -328,13 +328,14 @@ dbc_ep_do_queue(struct dbc_ep *dep, struct dbc_request 
*req)
 int dbc_ep_queue(struct dbc_ep *dep, struct dbc_request *req,
 gfp_t gfp_flags)
 {
+   unsigned long   flags;
struct xhci_dbc *dbc = dep->dbc;
int ret = -ESHUTDOWN;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (dbc->state == DS_CONFIGURED)
ret = dbc_ep_do_queue(dep, req);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
mod_delayed_work(system_wq, >event_work, 0);
 
@@ -521,15 +522,16 @@ static void xhci_do_dbc_stop(struct xhci_hcd *xhci)
 static int xhci_dbc_start(struct xhci_hcd *xhci)
 {
int ret;
+   unsigned long   flags;
struct xhci_dbc *dbc = xhci->dbc;
 
WARN_ON(!dbc);
 
pm_runtime_get_sync(xhci_to_hcd(xhci)->self.controller);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ret = xhci_do_dbc_start(xhci);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
if (ret) {
pm_runtime_put(xhci_to_hcd(xhci)->self.controller);
@@ -541,6 +543,7 @@ static int xhci_dbc_start(struct xhci_hcd *xhci)
 
 static void xhci_dbc_stop(struct xhci_hcd *xhci)
 {
+   unsigned long   flags;
struct xhci_dbc *dbc = xhci->dbc;
struct dbc_port *port = >port;
 
@@ -551,9 +554,9 @@ static void xhci_dbc_stop(struct xhci_hcd *xhci)
if (port->registered)
xhci_dbc_tty_unregister_device(xhci);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
xhci_do_dbc_stop(xhci);
-   spin_unlock(>lock);
+   

[PATCH 1/1] usb: xhci: dbc: Fix lockdep warning

[Lu Baolu]

The xHCI DbC implementation might enter a deadlock situation because
there is no sufficient protection against the shared data between
process and softirq contexts. This can lead to the following lockdep
warnings. This patch changes to use spin_{,un}lock_irq{save,restore}
to avoid potential deadlock.

[ 528.248084] 
[ 528.252914] WARNING: inconsistent lock state
[ 528.257756] 4.15.0-rc1+ #1630 Not tainted
[ 528.262305] 
[ 528.267145] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 528.273953] ksoftirqd/1/17 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 528.280075] (&(>port_lock)->rlock){+.?.}, at: [] 
dbc_rx_push+0x38/0x1c0
[ 528.290043] {SOFTIRQ-ON-W} state was registered at:
[ 528.295570] _raw_spin_lock+0x2f/0x40
[ 528.299818] dbc_write_complete+0x27/0xa0
[ 528.304458] xhci_dbc_giveback+0xd1/0x200
[ 528.309098] xhci_dbc_flush_endpoint_requests+0x50/0x70
[ 528.315116] xhci_dbc_handle_events+0x696/0x7b0
[ 528.320349] process_one_work+0x1ee/0x6e0
[ 528.324988] worker_thread+0x4a/0x430
[ 528.329236] kthread+0x13e/0x170
[ 528.332992] ret_from_fork+0x24/0x30
[ 528.337141] irq event stamp: 2861
[ 528.340897] hardirqs last enabled at (2860): [] 
tasklet_action+0x6a/0x250
[ 528.350460] hardirqs last disabled at (2861): [] 
_raw_spin_lock_irq+0xf/0x40
[ 528.360219] softirqs last enabled at (2852): [] 
__do_softirq+0x3dc/0x4f9
[ 528.369683] softirqs last disabled at (2857): [] 
run_ksoftirqd+0x1b/0x60
[ 528.379048]
[ 528.379048] other info that might help us debug this:
[ 528.386443] Possible unsafe locking scenario:
[ 528.386443]
[ 528.393150] CPU0
[ 528.395917] 
[ 528.398687] lock(&(>port_lock)->rlock);
[ 528.403821] 
[ 528.406786] lock(&(>port_lock)->rlock);
[ 528.412116]
[ 528.412116] *** DEADLOCK ***
[ 528.412116]
[ 528.418825] no locks held by ksoftirqd/1/17.
[ 528.423662]
[ 528.423662] stack backtrace:
[ 528.428598] CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.15.0-rc1+ #1630
[ 528.436387] Call Trace:
[ 528.439158] dump_stack+0x5e/0x8e
[ 528.442914] print_usage_bug+0x1fc/0x220
[ 528.447357] mark_lock+0x4db/0x5a0
[ 528.451210] __lock_acquire+0x726/0x1130
[ 528.455655] ? __lock_acquire+0x557/0x1130
[ 528.460296] lock_acquire+0xa2/0x200
[ 528.464347] ? dbc_rx_push+0x38/0x1c0
[ 528.468496] _raw_spin_lock_irq+0x35/0x40
[ 528.473038] ? dbc_rx_push+0x38/0x1c0
[ 528.477186] dbc_rx_push+0x38/0x1c0
[ 528.481139] tasklet_action+0x1d2/0x250
[ 528.485483] __do_softirq+0x1dc/0x4f9
[ 528.489630] run_ksoftirqd+0x1b/0x60
[ 528.493682] smpboot_thread_fn+0x179/0x270
[ 528.498324] kthread+0x13e/0x170
[ 528.501981] ? sort_range+0x20/0x20
[ 528.505933] ? kthread_delayed_work_timer_fn+0x80/0x80
[ 528.511755] ret_from_fork+0x24/0x30

Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-dbgcap.c | 20 
 drivers/usb/host/xhci-dbgtty.c | 20 
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
index 452df0f..c048d2a 100644
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -328,13 +328,14 @@ dbc_ep_do_queue(struct dbc_ep *dep, struct dbc_request 
*req)
 int dbc_ep_queue(struct dbc_ep *dep, struct dbc_request *req,
 gfp_t gfp_flags)
 {
+   unsigned long   flags;
struct xhci_dbc *dbc = dep->dbc;
int ret = -ESHUTDOWN;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (dbc->state == DS_CONFIGURED)
ret = dbc_ep_do_queue(dep, req);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
mod_delayed_work(system_wq, >event_work, 0);
 
@@ -521,15 +522,16 @@ static void xhci_do_dbc_stop(struct xhci_hcd *xhci)
 static int xhci_dbc_start(struct xhci_hcd *xhci)
 {
int ret;
+   unsigned long   flags;
struct xhci_dbc *dbc = xhci->dbc;
 
WARN_ON(!dbc);
 
pm_runtime_get_sync(xhci_to_hcd(xhci)->self.controller);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ret = xhci_do_dbc_start(xhci);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
if (ret) {
pm_runtime_put(xhci_to_hcd(xhci)->self.controller);
@@ -541,6 +543,7 @@ static int xhci_dbc_start(struct xhci_hcd *xhci)
 
 static void xhci_dbc_stop(struct xhci_hcd *xhci)
 {
+   unsigned long   flags;
struct xhci_dbc *dbc = xhci->dbc;
struct dbc_port *port = >port;
 
@@ -551,9 +554,9 @@ static void xhci_dbc_stop(struct xhci_hcd *xhci)
if (port->registered)
xhci_dbc_tty_unregister_device(xhci);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
xhci_do_dbc_stop(xhci);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 

Re: [PATCH PTI v3 10/10] x86/pti: Put the LDT in its own PGD if PTI is on

[Andy Lutomirski]

On Fri, Dec 15, 2017 at 2:54 PM, Thomas Gleixner  wrote:
> On Tue, 12 Dec 2017, Andy Lutomirski wrote:
>> +/* This is a multiple of PAGE_SIZE. */
>> +#define LDT_SLOT_STRIDE (LDT_ENTRIES * LDT_ENTRY_SIZE)
>> +
>> +static void *ldt_slot_va(int slot)
>
> How is that supposed to compile w/o warnings? Want's to be inline 

Good question.  But it does compile for me and apparently for the 0day
bot without warnings.  Fixed in my tree.

On Fri, Dec 15, 2017 at 4:39 PM, Thomas Gleixner  wrote:
> On Tue, 12 Dec 2017, Andy Lutomirski wrote:
>> +
>> + return 0;
>> +#else
>> + return -EINVAL;
>
> Errm. What's the point of that? Breaking non PTI?

That's embarrassing.

>
>>   new_ldt = alloc_ldt_struct(old_mm->context.ldt->nr_entries);
>>   if (!new_ldt) {
>> @@ -155,8 +266,17 @@ int init_new_context_ldt(struct task_struct *tsk, 
>> struct mm_struct *mm)
>>   memcpy(new_ldt->entries, old_mm->context.ldt->entries,
>>  new_ldt->nr_entries * LDT_ENTRY_SIZE);
>>   finalize_ldt_struct(new_ldt);
>> + retval = map_ldt_struct(mm, new_ldt, 0);
>> + if (retval)
>> + goto out_free;
>>
>>   mm->context.ldt = new_ldt;
>> + goto out_unlock;
>> +
>> +out_free:
>> + free_ldt_pgtables(mm);
>> + free_ldt_struct(new_ldt);
>> + return retval;
>
> Leaks old_mm->context_lock;
>

Indeed.

I'm going to go test the failure paths better tomorrow.  Meanwhile,
all three issues should be fixed in my tree.

Re: [PATCH PTI v3 10/10] x86/pti: Put the LDT in its own PGD if PTI is on

[Andy Lutomirski]

On Fri, Dec 15, 2017 at 2:54 PM, Thomas Gleixner  wrote:
> On Tue, 12 Dec 2017, Andy Lutomirski wrote:
>> +/* This is a multiple of PAGE_SIZE. */
>> +#define LDT_SLOT_STRIDE (LDT_ENTRIES * LDT_ENTRY_SIZE)
>> +
>> +static void *ldt_slot_va(int slot)
>
> How is that supposed to compile w/o warnings? Want's to be inline 

Good question.  But it does compile for me and apparently for the 0day
bot without warnings.  Fixed in my tree.

On Fri, Dec 15, 2017 at 4:39 PM, Thomas Gleixner  wrote:
> On Tue, 12 Dec 2017, Andy Lutomirski wrote:
>> +
>> + return 0;
>> +#else
>> + return -EINVAL;
>
> Errm. What's the point of that? Breaking non PTI?

That's embarrassing.

>
>>   new_ldt = alloc_ldt_struct(old_mm->context.ldt->nr_entries);
>>   if (!new_ldt) {
>> @@ -155,8 +266,17 @@ int init_new_context_ldt(struct task_struct *tsk, 
>> struct mm_struct *mm)
>>   memcpy(new_ldt->entries, old_mm->context.ldt->entries,
>>  new_ldt->nr_entries * LDT_ENTRY_SIZE);
>>   finalize_ldt_struct(new_ldt);
>> + retval = map_ldt_struct(mm, new_ldt, 0);
>> + if (retval)
>> + goto out_free;
>>
>>   mm->context.ldt = new_ldt;
>> + goto out_unlock;
>> +
>> +out_free:
>> + free_ldt_pgtables(mm);
>> + free_ldt_struct(new_ldt);
>> + return retval;
>
> Leaks old_mm->context_lock;
>

Indeed.

I'm going to go test the failure paths better tomorrow.  Meanwhile,
all three issues should be fixed in my tree.

Re: [PATCH v2 0/4] Utilization estimation (util_est) for FAIR tasks

[Mike Galbraith]

On Fri, 2017-12-15 at 21:23 +0100, Mike Galbraith wrote:
> 
> Point: if you think it's OK to serialize these firefox threads, would
> you still think so if those were kernel threads instead?  Serializing
> your kernel is a clear fail, but unpinned kthreads can be stacked up
> just as effectively as those browser threads are, eat needless wakeup
> latency and pass it on.

FWIW, somewhat cheezy example of that below.

(later, /me returns to [apparently endless] squabble w. PELT/SIS;)

bonnie in nfs mount of own box competing with 7 hogs:
 

  Task  |   Runtime ms  | Switches | Average delay ms | Maximum 
delay ms | Sum delay ms | Maximum delay at  |
 

  kworker/3:0:29|630.078 ms |89669 | avg:0.011 ms | max:  
102.340 ms | sum:  962.919 ms | max at:310.501277 |
  kworker/3:1H:464  |   1179.868 ms |   101944 | avg:0.005 ms | max:  
102.232 ms | sum:  480.915 ms | max at:310.501273 |
  kswapd0:78|   2662.230 ms | 1661 | avg:0.128 ms | max:   
93.935 ms | sum:  213.258 ms | max at:310.503419 |
  nfsd:2039 |   3257.143 ms |78448 | avg:0.112 ms | max:   
86.039 ms | sum: 8795.767 ms | max at:258.847140 |
  nfsd:2038 |   3185.730 ms |76253 | avg:0.113 ms | max:   
78.348 ms | sum: 8580.676 ms | max at:258.831370 |
  nfsd:2042 |   3256.554 ms |81423 | avg:0.110 ms | max:   
74.941 ms | sum: 8929.015 ms | max at:288.397203 |
  nfsd:2040 |   3314.826 ms |80396 | avg:0.105 ms | max:   
51.039 ms | sum: 8471.816 ms | max at:363.870078 |
  nfsd:2036 |   3058.867 ms |70460 | avg:0.115 ms | max:   
44.629 ms | sum: 8092.319 ms | max at:250.074253 |
  nfsd:2037 |   3113.592 ms |74276 | avg:0.115 ms | max:   
43.294 ms | sum: 8556.110 ms | max at:310.443722 |
  konsole:4013  |402.509 ms |  894 | avg:0.148 ms | max:   
38.129 ms | sum:  132.050 ms | max at:332.156495 |
  haveged:497   | 11.831 ms | 1224 | avg:0.104 ms | max:   
37.575 ms | sum:  127.706 ms | max at:350.669645 |
  nfsd:2043 |   3316.033 ms |78303 | avg:0.115 ms | max:   
36.511 ms | sum: 8995.138 ms | max at:248.576108 |
  nfsd:2035 |   3064.108 ms |67413 | avg:0.115 ms | max:   
28.221 ms | sum: 7746.306 ms | max at:313.785682 |
  bash:7022 |  0.342 ms |1 | avg:   22.959 ms | max:   
22.959 ms | sum:   22.959 ms | max at:262.258960 |
  kworker/u16:4:354 |   2073.383 ms | 1550 | avg:0.050 ms | max:   
21.203 ms | sum:   77.185 ms | max at:332.220678 |
  kworker/4:3:6975  |   1189.868 ms |   115776 | avg:0.018 ms | max:   
20.856 ms | sum: 2071.894 ms | max at:348.142757 |
  kworker/2:4:6981  |335.895 ms |26617 | avg:0.023 ms | max:   
20.726 ms | sum:  625.102 ms | max at:248.522083 |
  bash:7021 |  0.517 ms |2 | avg:   10.363 ms | max:   
20.726 ms | sum:   20.727 ms | max at:262.235708 |
  ksoftirqd/2:22| 65.718 ms |  998 | avg:0.138 ms | max:   
19.072 ms | sum:  137.827 ms | max at:332.221676 |
  kworker/7:3:6969  |625.724 ms |84153 | avg:0.010 ms | max:   
18.838 ms | sum:  876.603 ms | max at:264.188983 |
  bonnie:6965   |  79637.998 ms |35434 | avg:0.007 ms | max:   
18.719 ms | sum:  256.748 ms | max at:331.299867 | 

Re: [PATCH v2 0/4] Utilization estimation (util_est) for FAIR tasks

[Mike Galbraith]

On Fri, 2017-12-15 at 21:23 +0100, Mike Galbraith wrote:
> 
> Point: if you think it's OK to serialize these firefox threads, would
> you still think so if those were kernel threads instead?  Serializing
> your kernel is a clear fail, but unpinned kthreads can be stacked up
> just as effectively as those browser threads are, eat needless wakeup
> latency and pass it on.

FWIW, somewhat cheezy example of that below.

(later, /me returns to [apparently endless] squabble w. PELT/SIS;)

bonnie in nfs mount of own box competing with 7 hogs:
 

  Task  |   Runtime ms  | Switches | Average delay ms | Maximum 
delay ms | Sum delay ms | Maximum delay at  |
 

  kworker/3:0:29|630.078 ms |89669 | avg:0.011 ms | max:  
102.340 ms | sum:  962.919 ms | max at:310.501277 |
  kworker/3:1H:464  |   1179.868 ms |   101944 | avg:0.005 ms | max:  
102.232 ms | sum:  480.915 ms | max at:310.501273 |
  kswapd0:78|   2662.230 ms | 1661 | avg:0.128 ms | max:   
93.935 ms | sum:  213.258 ms | max at:310.503419 |
  nfsd:2039 |   3257.143 ms |78448 | avg:0.112 ms | max:   
86.039 ms | sum: 8795.767 ms | max at:258.847140 |
  nfsd:2038 |   3185.730 ms |76253 | avg:0.113 ms | max:   
78.348 ms | sum: 8580.676 ms | max at:258.831370 |
  nfsd:2042 |   3256.554 ms |81423 | avg:0.110 ms | max:   
74.941 ms | sum: 8929.015 ms | max at:288.397203 |
  nfsd:2040 |   3314.826 ms |80396 | avg:0.105 ms | max:   
51.039 ms | sum: 8471.816 ms | max at:363.870078 |
  nfsd:2036 |   3058.867 ms |70460 | avg:0.115 ms | max:   
44.629 ms | sum: 8092.319 ms | max at:250.074253 |
  nfsd:2037 |   3113.592 ms |74276 | avg:0.115 ms | max:   
43.294 ms | sum: 8556.110 ms | max at:310.443722 |
  konsole:4013  |402.509 ms |  894 | avg:0.148 ms | max:   
38.129 ms | sum:  132.050 ms | max at:332.156495 |
  haveged:497   | 11.831 ms | 1224 | avg:0.104 ms | max:   
37.575 ms | sum:  127.706 ms | max at:350.669645 |
  nfsd:2043 |   3316.033 ms |78303 | avg:0.115 ms | max:   
36.511 ms | sum: 8995.138 ms | max at:248.576108 |
  nfsd:2035 |   3064.108 ms |67413 | avg:0.115 ms | max:   
28.221 ms | sum: 7746.306 ms | max at:313.785682 |
  bash:7022 |  0.342 ms |1 | avg:   22.959 ms | max:   
22.959 ms | sum:   22.959 ms | max at:262.258960 |
  kworker/u16:4:354 |   2073.383 ms | 1550 | avg:0.050 ms | max:   
21.203 ms | sum:   77.185 ms | max at:332.220678 |
  kworker/4:3:6975  |   1189.868 ms |   115776 | avg:0.018 ms | max:   
20.856 ms | sum: 2071.894 ms | max at:348.142757 |
  kworker/2:4:6981  |335.895 ms |26617 | avg:0.023 ms | max:   
20.726 ms | sum:  625.102 ms | max at:248.522083 |
  bash:7021 |  0.517 ms |2 | avg:   10.363 ms | max:   
20.726 ms | sum:   20.727 ms | max at:262.235708 |
  ksoftirqd/2:22| 65.718 ms |  998 | avg:0.138 ms | max:   
19.072 ms | sum:  137.827 ms | max at:332.221676 |
  kworker/7:3:6969  |625.724 ms |84153 | avg:0.010 ms | max:   
18.838 ms | sum:  876.603 ms | max at:264.188983 |
  bonnie:6965   |  79637.998 ms |35434 | avg:0.007 ms | max:   
18.719 ms | sum:  256.748 ms | max at:331.299867 | 

Re: [PATCH v2 net-next 2/4] net: tracepoint: replace tcp_set_state tracepoint with sock_set_state tracepoint

[Yafang Shao]

2017-12-16 6:47 GMT+08:00 Song Liu :
>
>> On Dec 15, 2017, at 9:56 AM, Yafang Shao  wrote:
>>
>> As sk_state is a common field for struct sock, so the state
>> transition should not be a TCP specific feature.
>> So I rename tcp_set_state tracepoint to sock_set_state tracepoint with
>> some minor changes and move it into file trace/events/sock.h.
>>
>> Two helpers are introduced to trace sk_state transition
>>- void sk_state_store(struct sock *sk, int state);
>>- void sk_set_state(struct sock *sk, int state);
>> As trace header should not be included in other header files,
>> so they are defined in sock.c.
>>
>> The protocol such as SCTP maybe compiled as a ko, hence export
>> sk_set_state().
>>
>> Signed-off-by: Yafang Shao 
>> ---
>> include/net/sock.h  |  15 +-
>> include/trace/events/sock.h | 106 
>> 
>> include/trace/events/tcp.h  |  91 --
>> net/core/sock.c |  13 +
>> net/ipv4/inet_connection_sock.c |   4 +-
>> net/ipv4/inet_hashtables.c  |   2 +-
>> net/ipv4/tcp.c  |   4 --
>> 7 files changed, 124 insertions(+), 111 deletions(-)
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 9a90472..988ce82 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -2344,19 +2344,8 @@ static inline int sk_state_load(const struct sock *sk)
>>   return smp_load_acquire(>sk_state);
>> }
>>
>> -/**
>> - * sk_state_store - update sk->sk_state
>> - * @sk: socket pointer
>> - * @newstate: new state
>> - *
>> - * Paired with sk_state_load(). Should be used in contexts where
>> - * state change might impact lockless readers.
>> - */
>> -static inline void sk_state_store(struct sock *sk, int newstate)
>> -{
>> - smp_store_release(>sk_state, newstate);
>> -}
>> -
>> +void sk_state_store(struct sock *sk, int newstate);
>> +void sk_set_state(struct sock *sk, int state);
>> void sock_enable_timestamp(struct sock *sk, int flag);
>> int sock_get_timestamp(struct sock *, struct timeval __user *);
>> int sock_get_timestampns(struct sock *, struct timespec __user *);
>> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
>> index ec4dade..61977e5 100644
>> --- a/include/trace/events/sock.h
>> +++ b/include/trace/events/sock.h
>> @@ -6,7 +6,49 @@
>> #define _TRACE_SOCK_H
>>
>> #include 
>> +#include 
>> #include 
>> +#include 
>> +#include 
>> +
>> +#define inet_protocol_names  \
>> + EM(IPPROTO_TCP) \
>> + EM(IPPROTO_DCCP)\
>> + EMe(IPPROTO_SCTP)
>> +
>> +#define tcp_state_names  \
>> + EM(TCP_ESTABLISHED) \
>> + EM(TCP_SYN_SENT)\
>> + EM(TCP_SYN_RECV)\
>> + EM(TCP_FIN_WAIT1)  \
>> + EM(TCP_FIN_WAIT2)  \
>> + EM(TCP_TIME_WAIT)  \
>> + EM(TCP_CLOSE)  \
>> + EM(TCP_CLOSE_WAIT)\
>> + EM(TCP_LAST_ACK)\
>> + EM(TCP_LISTEN)\
>> + EM(TCP_CLOSING)  \
>> + EMe(TCP_NEW_SYN_RECV)
>
> Please keep these backslashes aligned.
>

OK
This is because  I made it aligned with TAB in my original code.


>> +/* enums need to be exported to user space */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a)   TRACE_DEFINE_ENUM(a);
>> +#define EMe(a)  TRACE_DEFINE_ENUM(a);
>> +
>> +inet_protocol_names
>> +tcp_state_names
>> +
>> +#undef EM
>> +#undef EMe
>> +#define EM(a)   { a, #a },
>> +#define EMe(a)  { a, #a }
>> +
>> +#define show_inet_protocol_name(val) \
>> + __print_symbolic(val, inet_protocol_names)
>> +
>> +#define show_tcp_state_name(val) \
>> + __print_symbolic(val, tcp_state_names)
>>
>> TRACE_EVENT(sock_rcvqueue_full,
>>
>> @@ -63,6 +105,70 @@
>>   __entry->rmem_alloc)
>> );
>>
>> +TRACE_EVENT(sock_set_state,
>> +
>> + TP_PROTO(const struct sock *sk, const int oldstate, const int 
>> newstate),
>> +
>> + TP_ARGS(sk, oldstate, newstate),
>> +
>> + TP_STRUCT__entry(
>> + __field(const void *, skaddr)
>> + __field(int, oldstate)
>> + __field(int, newstate)
>> + __field(__u16, sport)
>> + __field(__u16, dport)
>> + __field(__u8, protocol)
>> + __array(__u8, saddr, 4)
>> + __array(__u8, daddr, 4)
>> + __array(__u8, saddr_v6, 16)
>> + __array(__u8, daddr_v6, 16)
>> + ),
>> +
>> + TP_fast_assign(
>> + struct inet_sock *inet = inet_sk(sk);
>> + struct in6_addr *pin6;
>> + __be32 *p32;
>> +
>> + __entry->skaddr = sk;
>> + __entry->oldstate = oldstate;
>> + __entry->newstate = 

Re: [PATCH v2 net-next 2/4] net: tracepoint: replace tcp_set_state tracepoint with sock_set_state tracepoint

[Yafang Shao]

2017-12-16 6:47 GMT+08:00 Song Liu :
>
>> On Dec 15, 2017, at 9:56 AM, Yafang Shao  wrote:
>>
>> As sk_state is a common field for struct sock, so the state
>> transition should not be a TCP specific feature.
>> So I rename tcp_set_state tracepoint to sock_set_state tracepoint with
>> some minor changes and move it into file trace/events/sock.h.
>>
>> Two helpers are introduced to trace sk_state transition
>>- void sk_state_store(struct sock *sk, int state);
>>- void sk_set_state(struct sock *sk, int state);
>> As trace header should not be included in other header files,
>> so they are defined in sock.c.
>>
>> The protocol such as SCTP maybe compiled as a ko, hence export
>> sk_set_state().
>>
>> Signed-off-by: Yafang Shao 
>> ---
>> include/net/sock.h  |  15 +-
>> include/trace/events/sock.h | 106 
>> 
>> include/trace/events/tcp.h  |  91 --
>> net/core/sock.c |  13 +
>> net/ipv4/inet_connection_sock.c |   4 +-
>> net/ipv4/inet_hashtables.c  |   2 +-
>> net/ipv4/tcp.c  |   4 --
>> 7 files changed, 124 insertions(+), 111 deletions(-)
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 9a90472..988ce82 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -2344,19 +2344,8 @@ static inline int sk_state_load(const struct sock *sk)
>>   return smp_load_acquire(>sk_state);
>> }
>>
>> -/**
>> - * sk_state_store - update sk->sk_state
>> - * @sk: socket pointer
>> - * @newstate: new state
>> - *
>> - * Paired with sk_state_load(). Should be used in contexts where
>> - * state change might impact lockless readers.
>> - */
>> -static inline void sk_state_store(struct sock *sk, int newstate)
>> -{
>> - smp_store_release(>sk_state, newstate);
>> -}
>> -
>> +void sk_state_store(struct sock *sk, int newstate);
>> +void sk_set_state(struct sock *sk, int state);
>> void sock_enable_timestamp(struct sock *sk, int flag);
>> int sock_get_timestamp(struct sock *, struct timeval __user *);
>> int sock_get_timestampns(struct sock *, struct timespec __user *);
>> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
>> index ec4dade..61977e5 100644
>> --- a/include/trace/events/sock.h
>> +++ b/include/trace/events/sock.h
>> @@ -6,7 +6,49 @@
>> #define _TRACE_SOCK_H
>>
>> #include 
>> +#include 
>> #include 
>> +#include 
>> +#include 
>> +
>> +#define inet_protocol_names  \
>> + EM(IPPROTO_TCP) \
>> + EM(IPPROTO_DCCP)\
>> + EMe(IPPROTO_SCTP)
>> +
>> +#define tcp_state_names  \
>> + EM(TCP_ESTABLISHED) \
>> + EM(TCP_SYN_SENT)\
>> + EM(TCP_SYN_RECV)\
>> + EM(TCP_FIN_WAIT1)  \
>> + EM(TCP_FIN_WAIT2)  \
>> + EM(TCP_TIME_WAIT)  \
>> + EM(TCP_CLOSE)  \
>> + EM(TCP_CLOSE_WAIT)\
>> + EM(TCP_LAST_ACK)\
>> + EM(TCP_LISTEN)\
>> + EM(TCP_CLOSING)  \
>> + EMe(TCP_NEW_SYN_RECV)
>
> Please keep these backslashes aligned.
>

OK
This is because  I made it aligned with TAB in my original code.


>> +/* enums need to be exported to user space */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a)   TRACE_DEFINE_ENUM(a);
>> +#define EMe(a)  TRACE_DEFINE_ENUM(a);
>> +
>> +inet_protocol_names
>> +tcp_state_names
>> +
>> +#undef EM
>> +#undef EMe
>> +#define EM(a)   { a, #a },
>> +#define EMe(a)  { a, #a }
>> +
>> +#define show_inet_protocol_name(val) \
>> + __print_symbolic(val, inet_protocol_names)
>> +
>> +#define show_tcp_state_name(val) \
>> + __print_symbolic(val, tcp_state_names)
>>
>> TRACE_EVENT(sock_rcvqueue_full,
>>
>> @@ -63,6 +105,70 @@
>>   __entry->rmem_alloc)
>> );
>>
>> +TRACE_EVENT(sock_set_state,
>> +
>> + TP_PROTO(const struct sock *sk, const int oldstate, const int 
>> newstate),
>> +
>> + TP_ARGS(sk, oldstate, newstate),
>> +
>> + TP_STRUCT__entry(
>> + __field(const void *, skaddr)
>> + __field(int, oldstate)
>> + __field(int, newstate)
>> + __field(__u16, sport)
>> + __field(__u16, dport)
>> + __field(__u8, protocol)
>> + __array(__u8, saddr, 4)
>> + __array(__u8, daddr, 4)
>> + __array(__u8, saddr_v6, 16)
>> + __array(__u8, daddr_v6, 16)
>> + ),
>> +
>> + TP_fast_assign(
>> + struct inet_sock *inet = inet_sk(sk);
>> + struct in6_addr *pin6;
>> + __be32 *p32;
>> +
>> + __entry->skaddr = sk;
>> + __entry->oldstate = oldstate;
>> + __entry->newstate = newstate;
>> +
>> + __entry->protocol = sk->sk_protocol;
>> +  

Re: jsm_tty: Deletion of a null pointer check in two functions?

[SF Markus Elfring]

> Thanks for the fix.

Thanks for your positive feedback.


> I was on vacation - but now seeing all the analysis made here,

I assume that special communication settings could trigger
corresponding consequences for the discussed source code adjustment.


> if "ch" can't be NULL then please go ahead and remove the check =)

Would you dare to convert this request into a concrete patch?

Regards,
Markus

Re: jsm_tty: Deletion of a null pointer check in two functions?

[SF Markus Elfring]

> Thanks for the fix.

Thanks for your positive feedback.


> I was on vacation - but now seeing all the analysis made here,

I assume that special communication settings could trigger
corresponding consequences for the discussed source code adjustment.


> if "ch" can't be NULL then please go ahead and remove the check =)

Would you dare to convert this request into a concrete patch?

Regards,
Markus

Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

[Tetsuo Handa]

On 2017/12/16 1:25, Michal Hocko wrote:
>>  struct mmu_notifier_ops {
>> +/*
>> + * Flags to specify behavior of callbacks for this MMU notifier.
>> + * Used to determine which context an operation may be called.
>> + *
>> + * MMU_INVALIDATE_DOES_NOT_BLOCK: invalidate_{start,end} does not
>> + *block
>> + */
>> +int flags;
> 
> This should be more specific IMHO. What do you think about the following
> wording?
> 
> invalidate_{start,end,range} doesn't block on any locks which depend
> directly or indirectly (via lock chain or resources e.g. worker context)
> on a memory allocation.

I disagree. It needlessly complicates validating the correctness.

What if the invalidate_{start,end} calls schedule_timeout_idle(10 * HZ) ?
schedule_timeout_idle() will not block on any locks which depend directly or
indirectly on a memory allocation, but we are already blocking other memory
allocating threads at mutex_trylock(_lock) in __alloc_pages_may_oom().

This is essentially same with "sleeping forever due to 
schedule_timeout_killable(1) by
SCHED_IDLE thread with oom_lock held" versus "looping due to 
mutex_trylock(_lock)
by all other allocating threads" lockup problem. The OOM reaper does not want 
to get
blocked for so long.

Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

[Tetsuo Handa]

On 2017/12/16 1:25, Michal Hocko wrote:
>>  struct mmu_notifier_ops {
>> +/*
>> + * Flags to specify behavior of callbacks for this MMU notifier.
>> + * Used to determine which context an operation may be called.
>> + *
>> + * MMU_INVALIDATE_DOES_NOT_BLOCK: invalidate_{start,end} does not
>> + *block
>> + */
>> +int flags;
> 
> This should be more specific IMHO. What do you think about the following
> wording?
> 
> invalidate_{start,end,range} doesn't block on any locks which depend
> directly or indirectly (via lock chain or resources e.g. worker context)
> on a memory allocation.

I disagree. It needlessly complicates validating the correctness.

What if the invalidate_{start,end} calls schedule_timeout_idle(10 * HZ) ?
schedule_timeout_idle() will not block on any locks which depend directly or
indirectly on a memory allocation, but we are already blocking other memory
allocating threads at mutex_trylock(_lock) in __alloc_pages_may_oom().

This is essentially same with "sleeping forever due to 
schedule_timeout_killable(1) by
SCHED_IDLE thread with oom_lock held" versus "looping due to 
mutex_trylock(_lock)
by all other allocating threads" lockup problem. The OOM reaper does not want 
to get
blocked for so long.

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

[Benson Leung]

On Fri, Dec 01, 2017 at 11:49:54AM -0800, Gwendal Grignou wrote:
> Checked against 7412f0a0d90ee6ddbad4cde794f88f1489422f3a (CHROMIUM:
> platform/chrome: Support MKBP protocol over ACPI)
> Reviewed-by: Gwendal Grignou 
> 

Thanks Gwendal.

(ps, don't top post.)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

[Benson Leung]

On Fri, Dec 01, 2017 at 11:49:54AM -0800, Gwendal Grignou wrote:
> Checked against 7412f0a0d90ee6ddbad4cde794f88f1489422f3a (CHROMIUM:
> platform/chrome: Support MKBP protocol over ACPI)
> Reviewed-by: Gwendal Grignou 
> 

Thanks Gwendal.

(ps, don't top post.)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 2/3] platform/chrome: cros_ec_lpc: Add support for Google Glimmer

[Benson Leung]

Hi Thierry,

On Fri, Dec 01, 2017 at 02:42:22PM +0100, Thierry Escande wrote:
> This patch adds device information to the DMI table of the cros_ec_lpc
> driver for Google Glimmer devices. Since Google BIOS does not enumerate
> devices in the LPC bus, the cros_ec_lpc driver checks for system
> compatibility and registers the cros_ec device itself.
> 
> Signed-off-by: Thierry Escande 

Applied. Thanks.

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 0b26a09..4a2fc55 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -365,6 +365,13 @@ static const struct dmi_system_id 
> cros_ec_lpc_dmi_table[] __initconst = {
>   DMI_MATCH(DMI_PRODUCT_NAME, "Peppy"),
>   },
>   },
> + {
> + /* x86-glimmer, the Lenovo Thinkpad Yoga 11e. */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Glimmer"),
> + },
> + },
>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(dmi, cros_ec_lpc_dmi_table);
> -- 
> 2.7.4
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 2/3] platform/chrome: cros_ec_lpc: Add support for Google Glimmer

[Benson Leung]

Hi Thierry,

On Fri, Dec 01, 2017 at 02:42:22PM +0100, Thierry Escande wrote:
> This patch adds device information to the DMI table of the cros_ec_lpc
> driver for Google Glimmer devices. Since Google BIOS does not enumerate
> devices in the LPC bus, the cros_ec_lpc driver checks for system
> compatibility and registers the cros_ec device itself.
> 
> Signed-off-by: Thierry Escande 

Applied. Thanks.

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 0b26a09..4a2fc55 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -365,6 +365,13 @@ static const struct dmi_system_id 
> cros_ec_lpc_dmi_table[] __initconst = {
>   DMI_MATCH(DMI_PRODUCT_NAME, "Peppy"),
>   },
>   },
> + {
> + /* x86-glimmer, the Lenovo Thinkpad Yoga 11e. */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Glimmer"),
> + },
> + },
>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(dmi, cros_ec_lpc_dmi_table);
> -- 
> 2.7.4
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

[Benson Leung]

Hi Thierry,

On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote:
> From: Enric Balletbo i Serra 
> 
> Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for
> GOOG004 ACPI device") added support when the firmware reports the ACPI
> device, there are some firmwares though that doesn't report this device
> but have it. In such cases we need to instantiate the driver explicitly
> if it is not instantiated through ACPI.
> 
> Fixes: 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 
> ACPI device")
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Thierry Escande 

Applied for v4.16.

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 1baf720..0b26a09 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -35,6 +35,9 @@
>  #define DRV_NAME "cros_ec_lpcs"
>  #define ACPI_DRV_NAME "GOOG0004"
>  
> +/* True if ACPI device is present */
> +static bool cros_ec_lpc_acpi_device_found;
> +
>  static int ec_response_timed_out(void)
>  {
>   unsigned long one_second = jiffies + HZ;
> @@ -396,9 +399,21 @@ static struct platform_driver cros_ec_lpc_driver = {
>   .remove = cros_ec_lpc_remove,
>  };
>  
> +static struct platform_device cros_ec_lpc_device = {
> + .name = DRV_NAME
> +};
> +
> +static acpi_status cros_ec_lpc_parse_device(acpi_handle handle, u32 level,
> + void *context, void **retval)
> +{
> + *(bool *)context = true;
> + return AE_CTRL_TERMINATE;
> +}
> +
>  static int __init cros_ec_lpc_init(void)
>  {
>   int ret;
> + acpi_status status;
>  
>   if (!dmi_check_system(cros_ec_lpc_dmi_table)) {
>   pr_err(DRV_NAME ": unsupported system.\n");
> @@ -415,11 +430,28 @@ static int __init cros_ec_lpc_init(void)
>   return ret;
>   }
>  
> - return 0;
> + status = acpi_get_devices(ACPI_DRV_NAME, cros_ec_lpc_parse_device,
> +   _ec_lpc_acpi_device_found, NULL);
> + if (ACPI_FAILURE(status))
> + pr_warn(DRV_NAME ": Looking for %s failed\n", ACPI_DRV_NAME);
> +
> + if (!cros_ec_lpc_acpi_device_found) {
> + /* Register the device, and it'll get hooked up automatically */
> + ret = platform_device_register(_ec_lpc_device);
> + if (ret) {
> + pr_err(DRV_NAME ": can't register device: %d\n", ret);
> + platform_driver_unregister(_ec_lpc_driver);
> + cros_ec_lpc_reg_destroy();
> + }
> + }
> +
> + return ret;
>  }
>  
>  static void __exit cros_ec_lpc_exit(void)
>  {
> + if (!cros_ec_lpc_acpi_device_found)
> + platform_device_unregister(_ec_lpc_device);
>   platform_driver_unregister(_ec_lpc_driver);
>   cros_ec_lpc_reg_destroy();
>  }
> -- 
> 2.7.4
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

[Benson Leung]

Hi Thierry,

On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote:
> From: Enric Balletbo i Serra 
> 
> Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for
> GOOG004 ACPI device") added support when the firmware reports the ACPI
> device, there are some firmwares though that doesn't report this device
> but have it. In such cases we need to instantiate the driver explicitly
> if it is not instantiated through ACPI.
> 
> Fixes: 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 
> ACPI device")
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Thierry Escande 

Applied for v4.16.

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 1baf720..0b26a09 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -35,6 +35,9 @@
>  #define DRV_NAME "cros_ec_lpcs"
>  #define ACPI_DRV_NAME "GOOG0004"
>  
> +/* True if ACPI device is present */
> +static bool cros_ec_lpc_acpi_device_found;
> +
>  static int ec_response_timed_out(void)
>  {
>   unsigned long one_second = jiffies + HZ;
> @@ -396,9 +399,21 @@ static struct platform_driver cros_ec_lpc_driver = {
>   .remove = cros_ec_lpc_remove,
>  };
>  
> +static struct platform_device cros_ec_lpc_device = {
> + .name = DRV_NAME
> +};
> +
> +static acpi_status cros_ec_lpc_parse_device(acpi_handle handle, u32 level,
> + void *context, void **retval)
> +{
> + *(bool *)context = true;
> + return AE_CTRL_TERMINATE;
> +}
> +
>  static int __init cros_ec_lpc_init(void)
>  {
>   int ret;
> + acpi_status status;
>  
>   if (!dmi_check_system(cros_ec_lpc_dmi_table)) {
>   pr_err(DRV_NAME ": unsupported system.\n");
> @@ -415,11 +430,28 @@ static int __init cros_ec_lpc_init(void)
>   return ret;
>   }
>  
> - return 0;
> + status = acpi_get_devices(ACPI_DRV_NAME, cros_ec_lpc_parse_device,
> +   _ec_lpc_acpi_device_found, NULL);
> + if (ACPI_FAILURE(status))
> + pr_warn(DRV_NAME ": Looking for %s failed\n", ACPI_DRV_NAME);
> +
> + if (!cros_ec_lpc_acpi_device_found) {
> + /* Register the device, and it'll get hooked up automatically */
> + ret = platform_device_register(_ec_lpc_device);
> + if (ret) {
> + pr_err(DRV_NAME ": can't register device: %d\n", ret);
> + platform_driver_unregister(_ec_lpc_driver);
> + cros_ec_lpc_reg_destroy();
> + }
> + }
> +
> + return ret;
>  }
>  
>  static void __exit cros_ec_lpc_exit(void)
>  {
> + if (!cros_ec_lpc_acpi_device_found)
> + platform_device_unregister(_ec_lpc_device);
>   platform_driver_unregister(_ec_lpc_driver);
>   cros_ec_lpc_reg_destroy();
>  }
> -- 
> 2.7.4
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

[Benson Leung]

Hi Thierry,

Sorry for the delay in processing these.

On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote:
> From: Enric Balletbo i Serra 
> 
> Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for
> GOOG004 ACPI device") added support when the firmware reports the ACPI
> device, there are some firmwares though that doesn't report this device
> but have it. In such cases we need to instantiate the driver explicitly
> if it is not instantiated through ACPI.
> 
> Fixes: 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 
> ACPI device")
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Thierry Escande 

Applied for v4.16.

Thanks,
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

[Benson Leung]

Hi Thierry,

Sorry for the delay in processing these.

On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote:
> From: Enric Balletbo i Serra 
> 
> Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for
> GOOG004 ACPI device") added support when the firmware reports the ACPI
> device, there are some firmwares though that doesn't report this device
> but have it. In such cases we need to instantiate the driver explicitly
> if it is not instantiated through ACPI.
> 
> Fixes: 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 
> ACPI device")
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Thierry Escande 

Applied for v4.16.

Thanks,
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v19 3/7] xbitmap: add more operations

[Tetsuo Handa]

Matthew Wilcox wrote:
> On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote:
> > Michael S. Tsirkin wrote:
> > > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > > > My understanding is that virtio-balloon wants to handle sparsely 
> > > > spreaded
> > > > unsigned long values (which is PATCH 4/7) and wants to find all chunks 
> > > > of
> > > > consecutive "1" bits efficiently. Therefore, I guess that holding the 
> > > > values
> > > > in ascending order at store time is faster than sorting the values at 
> > > > read
> > > > time.
> 
> What makes you think that the radix tree (also xbitmap, also idr) doesn't
> sort the values at store time?

I don't care whether the radix tree sorts the values at store time.
What I care is how to read stored values in ascending order with less overhead.

Existing users are too much optimized and difficult to understand for new
comers. I appreciate if there are simple sample codes which explain how to
use library functions and which can be compiled/tested in userspace.
Your "- look at ->head, see it is NULL, return false." answer did not
give me any useful information.

> 
> > I'm asking whether we really need to invent a new library module (i.e.
> > PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.
> > 
> > What virtio-balloon needs is ability to
> > 
> >   (1) record any integer value in [0, ULONG_MAX] range
> > 
> >   (2) fetch all recorded values, with consecutive values combined in
> >   min,max (or start,count) form for efficiently
> > 
> > and I wonder whether we need to invent complete API set which
> > Matthew Wilcox and Wei Wang are planning for generic purpose.
> 
> The xbitmap absolutely has that ability.

Current patches are too tricky to review.
When will all corner cases be closed?

>   And making it generic code
> means more people see it, use it, debug it, optimise it.

I'm not objecting against generic code. But trying to optimize it can
enbug it, like using exception path keeps me difficult to review whether
the implementation is correct. I'm suggesting to start xbitmap without
exception path, and I haven't seen a version without exception path.

>   I originally
> wrote the implementation for bcache, when Kent was complaining we didn't
> have such a thing.  His needs weren't as complex as Wei's, which is why
> I hadn't implemented everything that Wei needed.
> 

Unless current xbitmap patches become clear, virtio-balloon changes won't
be able to be get merged. We are repeating this series without closing
many bugs. We can start virtio-balloon changes with a stub code which
provides (1) and (2), and that's my version.

Re: [PATCH v19 3/7] xbitmap: add more operations

[Tetsuo Handa]

Matthew Wilcox wrote:
> On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote:
> > Michael S. Tsirkin wrote:
> > > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > > > My understanding is that virtio-balloon wants to handle sparsely 
> > > > spreaded
> > > > unsigned long values (which is PATCH 4/7) and wants to find all chunks 
> > > > of
> > > > consecutive "1" bits efficiently. Therefore, I guess that holding the 
> > > > values
> > > > in ascending order at store time is faster than sorting the values at 
> > > > read
> > > > time.
> 
> What makes you think that the radix tree (also xbitmap, also idr) doesn't
> sort the values at store time?

I don't care whether the radix tree sorts the values at store time.
What I care is how to read stored values in ascending order with less overhead.

Existing users are too much optimized and difficult to understand for new
comers. I appreciate if there are simple sample codes which explain how to
use library functions and which can be compiled/tested in userspace.
Your "- look at ->head, see it is NULL, return false." answer did not
give me any useful information.

> 
> > I'm asking whether we really need to invent a new library module (i.e.
> > PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.
> > 
> > What virtio-balloon needs is ability to
> > 
> >   (1) record any integer value in [0, ULONG_MAX] range
> > 
> >   (2) fetch all recorded values, with consecutive values combined in
> >   min,max (or start,count) form for efficiently
> > 
> > and I wonder whether we need to invent complete API set which
> > Matthew Wilcox and Wei Wang are planning for generic purpose.
> 
> The xbitmap absolutely has that ability.

Current patches are too tricky to review.
When will all corner cases be closed?

>   And making it generic code
> means more people see it, use it, debug it, optimise it.

I'm not objecting against generic code. But trying to optimize it can
enbug it, like using exception path keeps me difficult to review whether
the implementation is correct. I'm suggesting to start xbitmap without
exception path, and I haven't seen a version without exception path.

>   I originally
> wrote the implementation for bcache, when Kent was complaining we didn't
> have such a thing.  His needs weren't as complex as Wei's, which is why
> I hadn't implemented everything that Wei needed.
> 

Unless current xbitmap patches become clear, virtio-balloon changes won't
be able to be get merged. We are repeating this series without closing
many bugs. We can start virtio-balloon changes with a stub code which
provides (1) and (2), and that's my version.

Re: [PATCH 4.9 00/27] 4.9.70-stable review

[Naresh Kamboju]

On 15 December 2017 at 15:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.70 release.
> There are 27 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 Sun Dec 17 09:22:42 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.70-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 and x86_64.

Note:
We do not have arm64 hikey board results due to the changes required
from the firmware update. Hikey board is under maintenance.

Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64
and beagle board x15 and the independent test execution resulted as PASS.
For the internal investigation bug reported.
https://bugs.linaro.org/show_bug.cgi?id=3502#c4

Summary


kernel: 4.9.70-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: cc35c65be8bb29a0282724447bc694353125a35d
git describe: v4.9.69-28-gcc35c65be8bb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.69-28-gcc35c65be8bb

No regressions (compared to build v4.9.69-22-g9ba613a08872)

Boards, architectures and test suites:
-
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 40, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 121
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - fail: 1, pass: 36, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - fail: 1, pass: 54, skip: 23
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 1,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 10,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.9 00/27] 4.9.70-stable review

[Naresh Kamboju]

On 15 December 2017 at 15:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.70 release.
> There are 27 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 Sun Dec 17 09:22:42 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.70-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 and x86_64.

Note:
We do not have arm64 hikey board results due to the changes required
from the firmware update. Hikey board is under maintenance.

Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64
and beagle board x15 and the independent test execution resulted as PASS.
For the internal investigation bug reported.
https://bugs.linaro.org/show_bug.cgi?id=3502#c4

Summary


kernel: 4.9.70-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: cc35c65be8bb29a0282724447bc694353125a35d
git describe: v4.9.69-28-gcc35c65be8bb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.69-28-gcc35c65be8bb

No regressions (compared to build v4.9.69-22-g9ba613a08872)

Boards, architectures and test suites:
-
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 40, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 121
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - fail: 1, pass: 36, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - fail: 1, pass: 54, skip: 23
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 1,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 10,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH] dt-bindings: chosen: Document linux,initrd-{start,end}

[Jonathan Neuschäfer]

On Fri, Dec 15, 2017 at 03:01:47PM -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:33:02PM +0100, Jonathan Neuschäfer wrote:
> > These properties have been in use for a very long time (at least since
> > 2005), but were never documented in chosen.txt.
> > 
> > Signed-off-by: Jonathan Neuschäfer 
> > ---
> >  Documentation/devicetree/bindings/chosen.txt | 15 +++
> >  1 file changed, 15 insertions(+)
> 
> Applied.

Thanks.

> I'm inclined to say to document these in the DT spec, but I'm assuming 
> there was some reason why they weren't put into the spec (ePAPR at the 
> time) originally.

I don't know about the history of this, but I think if and when these
properties were specified in DTSpec, they should get a non-linux-specific
name, such as initrd-start/initrd-end, and a compatibility fallback to
linux,initrd-* (similar to stdout-path and phandle).


Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH] dt-bindings: chosen: Document linux,initrd-{start,end}

[Jonathan Neuschäfer]

On Fri, Dec 15, 2017 at 03:01:47PM -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:33:02PM +0100, Jonathan Neuschäfer wrote:
> > These properties have been in use for a very long time (at least since
> > 2005), but were never documented in chosen.txt.
> > 
> > Signed-off-by: Jonathan Neuschäfer 
> > ---
> >  Documentation/devicetree/bindings/chosen.txt | 15 +++
> >  1 file changed, 15 insertions(+)
> 
> Applied.

Thanks.

> I'm inclined to say to document these in the DT spec, but I'm assuming 
> there was some reason why they weren't put into the spec (ePAPR at the 
> time) originally.

I don't know about the history of this, but I think if and when these
properties were specified in DTSpec, they should get a non-linux-specific
name, such as initrd-start/initrd-end, and a compatibility fallback to
linux,initrd-* (similar to stdout-path and phandle).


Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH 4.4 000/105] 4.4.106-stable review

[Naresh Kamboju]

On 15 December 2017 at 15:13, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.106 release.
> There are 105 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 Sun Dec 17 09:22:39 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.4.106-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.4.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:
We do not have arm64 hikey board results due to the changes required
from the firmware update. Hikey board is under maintenance.

readahead02 failed once in 3 iterations of full syscall run which is
intermittently failure on ARM64 juno running 4.4.106-rc1.
Resubmitted test looped for 20 Iterations out of which 7 times TCONF
and 13 times PASS.

Test log failed instance:
  readahead020  TINFO  :  read_testfile(0) used cache: 65468 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 32592 kB
  readahead020  TWARN  :  readahead02.c:351: using less cache than expected

Test pass log:
  readahead020  TINFO  :  read_testfile(0) used cache: 65568 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 65268 kB
  readahead023  TPASS  :  using cache as expected

Test CONF log:
  readahead020  TINFO  :  read_testfile(0) used cache: 65376 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 65564 kB
  readahead023  TCONF  :  readahead02.c:354: Page cache on your
system is too small to hold whole testfile.

Bug reported for the investigation.
https://bugs.linaro.org/show_bug.cgi?id=3539

Summary


kernel: 4.4.106-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 67065bd41780929c2b8406ac3dd5356e83cd2d19
git describe: v4.4.105-106-g67065bd41780
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.105-106-g67065bd41780

No regressions (compared to build v4.4.105-108-g894d367e5d93)


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - fail: 2, pass: 980, skip: 124
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 29
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 44, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.4 000/105] 4.4.106-stable review

[Naresh Kamboju]

On 15 December 2017 at 15:13, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.106 release.
> There are 105 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 Sun Dec 17 09:22:39 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.4.106-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.4.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:
We do not have arm64 hikey board results due to the changes required
from the firmware update. Hikey board is under maintenance.

readahead02 failed once in 3 iterations of full syscall run which is
intermittently failure on ARM64 juno running 4.4.106-rc1.
Resubmitted test looped for 20 Iterations out of which 7 times TCONF
and 13 times PASS.

Test log failed instance:
  readahead020  TINFO  :  read_testfile(0) used cache: 65468 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 32592 kB
  readahead020  TWARN  :  readahead02.c:351: using less cache than expected

Test pass log:
  readahead020  TINFO  :  read_testfile(0) used cache: 65568 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 65268 kB
  readahead023  TPASS  :  using cache as expected

Test CONF log:
  readahead020  TINFO  :  read_testfile(0) used cache: 65376 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 65564 kB
  readahead023  TCONF  :  readahead02.c:354: Page cache on your
system is too small to hold whole testfile.

Bug reported for the investigation.
https://bugs.linaro.org/show_bug.cgi?id=3539

Summary


kernel: 4.4.106-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 67065bd41780929c2b8406ac3dd5356e83cd2d19
git describe: v4.4.105-106-g67065bd41780
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.105-106-g67065bd41780

No regressions (compared to build v4.4.105-108-g894d367e5d93)


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - fail: 2, pass: 980, skip: 124
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 29
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 44, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.14 00/52] 4.14.7-stable review

[Naresh Kamboju]

On 15 December 2017 at 15:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.7 release.
> There are 52 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 Sun Dec 17 09:22:47 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.14.7-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.14.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:
We do not have arm64 hikey board results due to the changes required
from the firmware update.
Hikey board is under maintenance.

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

Summary

kernel: 4.14.7-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: a89be024745d1205f14c2a598b32d26a1224361f
git describe: v4.14.6-53-ga89be024745d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.6-53-ga89be024745d

No regressions (compared to build v4.14.6-39-g190d0d404c61)

Boards, architectures and test suites:
-
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 45, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 121
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 41, skip: 20
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - fail: 1, pass: 60, skip: 16
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 1,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 1,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 1,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 11,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.14 00/52] 4.14.7-stable review

[Naresh Kamboju]

On 15 December 2017 at 15:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.7 release.
> There are 52 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 Sun Dec 17 09:22:47 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.14.7-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.14.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:
We do not have arm64 hikey board results due to the changes required
from the firmware update.
Hikey board is under maintenance.

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

Summary

kernel: 4.14.7-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: a89be024745d1205f14c2a598b32d26a1224361f
git describe: v4.14.6-53-ga89be024745d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.6-53-ga89be024745d

No regressions (compared to build v4.14.6-39-g190d0d404c61)

Boards, architectures and test suites:
-
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 45, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 121
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 41, skip: 20
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - fail: 1, pass: 60, skip: 16
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 1,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 1,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 1,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 11,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH v2 10/10] arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Signed-off-by: Damien Riegel 

Please move pinconf settings into the structure in
apq8016-sbc-soc-pins.dtsi (didn't see this when commenting on the
previous patch).

Apart from this, the patch looks good.

Regards,
Bjorn

> ---
> Changes in v2:
>  - Reworded commit title
>  - Changed size to 0x500
> 
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 48 
> ++
>  arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 42 ++
>  arch/arm64/boot/dts/qcom/msm8916.dtsi  | 45 
>  3 files changed, 135 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 53c1ddd281a4..11305015ba0b 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -630,6 +630,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio6", "gpio7";
> @@ -646,6 +662,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio14", "gpio15";
> @@ -662,6 +694,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio22", "gpio23";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> index 7704ddecb6c4..44e68860fc8c 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> @@ -152,6 +152,20 @@
>   };
>   };
>  
> + i2c1_default: i2c1_default {
> + pinmux {
> + function = "blsp_i2c1";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
> + i2c1_sleep: i2c1_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
>   i2c2_default: i2c2_default {
>   pinmux {
>   function = "blsp_i2c2";
> @@ -166,6 +180,20 @@
>   };
>   };
>  
> + i2c3_default: i2c3_default {
> + pinmux {
> + function = "blsp_i2c3";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
> + i2c3_sleep: i2c3_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
>   i2c4_default: i2c4_default {
>   pinmux {
>   function = "blsp_i2c4";
> @@ -180,6 +208,20 @@
>   };
>   };
>  
> + i2c5_default: i2c5_default {
> + pinmux {
> + function = "blsp_i2c5";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
> + i2c5_sleep: i2c5_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
>   i2c6_default: i2c6_default {
>   pinmux {
>   function = "blsp_i2c6";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index ac440f287633..7478c7337995 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -455,6 +455,21 @@
>   status = "disabled";
>   };
>  
> + blsp_i2c1: i2c@78b5000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b5000 0x500>;
> + interrupts = ;
> + clocks = < GCC_BLSP1_AHB_CLK>,
> +  < GCC_BLSP1_QUP1_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_default>;
> + pinctrl-1 = <_sleep>;
> +

Re: [PATCH v2 10/10] arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Signed-off-by: Damien Riegel 

Please move pinconf settings into the structure in
apq8016-sbc-soc-pins.dtsi (didn't see this when commenting on the
previous patch).

Apart from this, the patch looks good.

Regards,
Bjorn

> ---
> Changes in v2:
>  - Reworded commit title
>  - Changed size to 0x500
> 
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 48 
> ++
>  arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 42 ++
>  arch/arm64/boot/dts/qcom/msm8916.dtsi  | 45 
>  3 files changed, 135 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 53c1ddd281a4..11305015ba0b 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -630,6 +630,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio6", "gpio7";
> @@ -646,6 +662,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio14", "gpio15";
> @@ -662,6 +694,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio22", "gpio23";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> index 7704ddecb6c4..44e68860fc8c 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> @@ -152,6 +152,20 @@
>   };
>   };
>  
> + i2c1_default: i2c1_default {
> + pinmux {
> + function = "blsp_i2c1";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
> + i2c1_sleep: i2c1_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
>   i2c2_default: i2c2_default {
>   pinmux {
>   function = "blsp_i2c2";
> @@ -166,6 +180,20 @@
>   };
>   };
>  
> + i2c3_default: i2c3_default {
> + pinmux {
> + function = "blsp_i2c3";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
> + i2c3_sleep: i2c3_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
>   i2c4_default: i2c4_default {
>   pinmux {
>   function = "blsp_i2c4";
> @@ -180,6 +208,20 @@
>   };
>   };
>  
> + i2c5_default: i2c5_default {
> + pinmux {
> + function = "blsp_i2c5";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
> + i2c5_sleep: i2c5_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
>   i2c6_default: i2c6_default {
>   pinmux {
>   function = "blsp_i2c6";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index ac440f287633..7478c7337995 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -455,6 +455,21 @@
>   status = "disabled";
>   };
>  
> + blsp_i2c1: i2c@78b5000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b5000 0x500>;
> + interrupts = ;
> + clocks = < GCC_BLSP1_AHB_CLK>,
> +  < GCC_BLSP1_QUP1_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_default>;
> + pinctrl-1 = <_sleep>;
> + #address-cells = <1>;
> +  

Re: [PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> The QUP core can be used either for I2C or SPI, so the same IP is mapped
> by a driver or the other. SPI bindings use a leading 0 for the start
> address and a size of 0x600, I2C bindings don't have the leading 0 and
> have a size 0x1000.
> 
> To make them more similar, add the leading 0 to I2C bindings and changes
> the size to 0x500 for all of them, as this is the actual size of these
> blocks. Also align the second entry of the clocks array.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> The QUP core can be used either for I2C or SPI, so the same IP is mapped
> by a driver or the other. SPI bindings use a leading 0 for the start
> address and a size of 0x600, I2C bindings don't have the leading 0 and
> have a size 0x1000.
> 
> To make them more similar, add the leading 0 to I2C bindings and changes
> the size to 0x500 for all of them, as this is the actual size of these
> blocks. Also align the second entry of the clocks array.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> This commit drops pin configs that cannot be moved to board files as
> no boards use them.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Nodes relative to the first sdhc node were interlaced with node of the
> second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also
> rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as
> "pmx_sdc" is the prefix used by other nodes.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Nodes relative to the first sdhc node were interlaced with node of the
> second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also
> rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as
> "pmx_sdc" is the prefix used by other nodes.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> This commit drops pin configs that cannot be moved to board files as
> no boards use them.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Following a suggestion from Bjorn Andersson [1], this commit moves
> electrical specifications which were defined in mms8916-pins.dtsi to
> board files, where they actually belong.
> 
> Pinmuxing is kept in the platform file because there are no alternative
> pins on which all these functions could be routed, so this part is
> indeed common to all boards using this SoC.
> 
> [1] https://www.spinics.net/lists/devicetree/msg201764.html
> 
> Signed-off-by: Damien Riegel 
> Suggested-by: Bjorn Andersson 

I like the move, but I would prefer that you mimic the base structure,
rather than just appending properties based on labels.

Regards,
Bjorn

Re: [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Following a suggestion from Bjorn Andersson [1], this commit moves
> electrical specifications which were defined in mms8916-pins.dtsi to
> board files, where they actually belong.
> 
> Pinmuxing is kept in the platform file because there are no alternative
> pins on which all these functions could be routed, so this part is
> indeed common to all boards using this SoC.
> 
> [1] https://www.spinics.net/lists/devicetree/msg201764.html
> 
> Signed-off-by: Damien Riegel 
> Suggested-by: Bjorn Andersson 

I like the move, but I would prefer that you mimic the base structure,
rather than just appending properties based on labels.

Regards,
Bjorn

Re: [PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Also, it was using whitespaces for indentation on some lines, fix that
> while moving it.
> 
> Signed-off-by: Damien Riegel 

Rather than extending single nodes like this I would prefer that we
bring in the associated pmic node, by this we avoid just having a huge
flat list of nodes. I.e. that we make this:

_1 {
codec@f000 {
status = "okay";
clocks = < GCC_CODEC_DIGCODEC_CLK>;
clock-names = "mclk";
qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
};

Regards,
Bjorn

Re: [PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Also, it was using whitespaces for indentation on some lines, fix that
> while moving it.
> 
> Signed-off-by: Damien Riegel 

Rather than extending single nodes like this I would prefer that we
bring in the associated pmic node, by this we avoid just having a huge
flat list of nodes. I.e. that we make this:

_1 {
codec@f000 {
status = "okay";
clocks = < GCC_CODEC_DIGCODEC_CLK>;
clock-names = "mclk";
qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
};

Regards,
Bjorn

Re: [PATCH] platform/chrome: cros_ec_lpc: remove redundant pointer request

[Benson Leung]

Hi Colin,

On Tue, Oct 31, 2017 at 10:27:47AM +, Colin King wrote:
> From: Colin Ian King 
> 
> Pointer request is being assigned but never used, so remove it. Cleans
> up the clang warning:
> 
> drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to
> 'request' is never read
> 
> Signed-off-by: Colin Ian King 

Thanks for the patch. Sorry for the delay. Applied for v4.16.

Thanks,
Benson

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 1baf720faf69..87e9747d229a 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -54,7 +54,6 @@ static int ec_response_timed_out(void)
>  static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   struct cros_ec_command *msg)
>  {
> - struct ec_host_request *request;
>   struct ec_host_response response;
>   u8 sum;
>   int ret = 0;
> @@ -65,8 +64,6 @@ static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   /* Write buffer */
>   cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_PACKET, ret, ec->dout);
>  
> - request = (struct ec_host_request *)ec->dout;
> -
>   /* Here we go */
>   sum = EC_COMMAND_PROTOCOL_3;
>   cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_CMD, 1, );
> -- 
> 2.14.1
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH] platform/chrome: cros_ec_lpc: remove redundant pointer request

[Benson Leung]

Hi Colin,

On Tue, Oct 31, 2017 at 10:27:47AM +, Colin King wrote:
> From: Colin Ian King 
> 
> Pointer request is being assigned but never used, so remove it. Cleans
> up the clang warning:
> 
> drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to
> 'request' is never read
> 
> Signed-off-by: Colin Ian King 

Thanks for the patch. Sorry for the delay. Applied for v4.16.

Thanks,
Benson

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 1baf720faf69..87e9747d229a 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -54,7 +54,6 @@ static int ec_response_timed_out(void)
>  static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   struct cros_ec_command *msg)
>  {
> - struct ec_host_request *request;
>   struct ec_host_response response;
>   u8 sum;
>   int ret = 0;
> @@ -65,8 +64,6 @@ static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   /* Write buffer */
>   cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_PACKET, ret, ec->dout);
>  
> - request = (struct ec_host_request *)ec->dout;
> -
>   /* Here we go */
>   sum = EC_COMMAND_PROTOCOL_3;
>   cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_CMD, 1, );
> -- 
> 2.14.1
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> These nodes reserve and configure some pins as GPIOs. They are not
> generic pinctrls, they actually belong to board files but they are not
> used by any other node, so just drop them altogether.
> 
> Signed-off-by: Damien Riegel 

Reviewed-by: Bjorn Andersson 

Let's introduce them back into the db410c when we define a client.

Regards,
Bjorn

Re: [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes

[Bjorn Andersson]

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> These nodes reserve and configure some pins as GPIOs. They are not
> generic pinctrls, they actually belong to board files but they are not
> used by any other node, so just drop them altogether.
> 
> Signed-off-by: Damien Riegel 

Reviewed-by: Bjorn Andersson 

Let's introduce them back into the db410c when we define a client.

Regards,
Bjorn

Re: [PATCH] cros_ec: fix nul-termination for firmware build info

[Benson Leung]

Hi Arnd,

On Mon, Dec 04, 2017 at 03:49:48PM +0100, Arnd Bergmann wrote:
> As gcc-8 reports, we zero out the wrong byte:
> 
> drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
> drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 
> 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
> 
> This changes the code back to what it did before changing to a
> zero-length array structure.
> 
> Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
> Signed-off-by: Arnd Bergmann 

Applied. Thanks!

Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH] cros_ec: fix nul-termination for firmware build info

[Benson Leung]

Hi Arnd,

On Mon, Dec 04, 2017 at 03:49:48PM +0100, Arnd Bergmann wrote:
> As gcc-8 reports, we zero out the wrong byte:
> 
> drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
> drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 
> 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
> 
> This changes the code back to what it did before changing to a
> zero-length array structure.
> 
> Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
> Signed-off-by: Arnd Bergmann 

Applied. Thanks!

Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v19 3/7] xbitmap: add more operations

[Matthew Wilcox]

On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote:
> Michael S. Tsirkin wrote:
> > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > > My understanding is that virtio-balloon wants to handle sparsely spreaded
> > > unsigned long values (which is PATCH 4/7) and wants to find all chunks of
> > > consecutive "1" bits efficiently. Therefore, I guess that holding the 
> > > values
> > > in ascending order at store time is faster than sorting the values at read
> > > time.

What makes you think that the radix tree (also xbitmap, also idr) doesn't
sort the values at store time?

> I'm asking whether we really need to invent a new library module (i.e.
> PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.
> 
> What virtio-balloon needs is ability to
> 
>   (1) record any integer value in [0, ULONG_MAX] range
> 
>   (2) fetch all recorded values, with consecutive values combined in
>   min,max (or start,count) form for efficiently
> 
> and I wonder whether we need to invent complete API set which
> Matthew Wilcox and Wei Wang are planning for generic purpose.

The xbitmap absolutely has that ability.  And making it generic code
means more people see it, use it, debug it, optimise it.  I originally
wrote the implementation for bcache, when Kent was complaining we didn't
have such a thing.  His needs weren't as complex as Wei's, which is why
I hadn't implemented everything that Wei needed.

Re: [PATCH v19 3/7] xbitmap: add more operations

[Matthew Wilcox]

On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote:
> Michael S. Tsirkin wrote:
> > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > > My understanding is that virtio-balloon wants to handle sparsely spreaded
> > > unsigned long values (which is PATCH 4/7) and wants to find all chunks of
> > > consecutive "1" bits efficiently. Therefore, I guess that holding the 
> > > values
> > > in ascending order at store time is faster than sorting the values at read
> > > time.

What makes you think that the radix tree (also xbitmap, also idr) doesn't
sort the values at store time?

> I'm asking whether we really need to invent a new library module (i.e.
> PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.
> 
> What virtio-balloon needs is ability to
> 
>   (1) record any integer value in [0, ULONG_MAX] range
> 
>   (2) fetch all recorded values, with consecutive values combined in
>   min,max (or start,count) form for efficiently
> 
> and I wonder whether we need to invent complete API set which
> Matthew Wilcox and Wei Wang are planning for generic purpose.

The xbitmap absolutely has that ability.  And making it generic code
means more people see it, use it, debug it, optimise it.  I originally
wrote the implementation for bcache, when Kent was complaining we didn't
have such a thing.  His needs weren't as complex as Wei's, which is why
I hadn't implemented everything that Wei needed.

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

[Brian Norris]

+ RTC maintainers

On Fri, Dec 15, 2017 at 08:57:50PM -0800, Brian Norris wrote:
> On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote:
> > From: Stephen Barber 
> > 
> > On platforms with a Chrome OS EC, the EC can function as a simple RTC.
> > Add a basic driver with this functionality.
> > 
> > Signed-off-by: Stephen Barber 
> > Signed-off-by: Enric Balletbo i Serra 
> > Acked-by: Alexandre Belloni 
> > Acked-by: Benson Leung 
> > ---
> >  drivers/rtc/Kconfig   |  10 ++
> >  drivers/rtc/Makefile  |   1 +
> >  drivers/rtc/rtc-cros-ec.c | 413 
> > ++
> >  3 files changed, 424 insertions(+)
> >  create mode 100644 drivers/rtc/rtc-cros-ec.c
> 
> This isn't quite super-helpful without the CrOS-EC / MFD additions to
> actually create the device, but it's a good start, and I don't see any
> problems with it. Any reason this isn't merged? Are the RTC maintainers
> intendending to merge this, or should Lee (for the MFD header)? I
> thought normally Lee deferred to other subsystem maintainers when the
> only "MFD" stuff was a simple header change (such as in patch 1).
> 
> Anyway, FWIW:
> 
> Reviewed-by: Brian Norris 
> Tested-by: Brian Norris 

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

[Brian Norris]

+ RTC maintainers

On Fri, Dec 15, 2017 at 08:57:50PM -0800, Brian Norris wrote:
> On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote:
> > From: Stephen Barber 
> > 
> > On platforms with a Chrome OS EC, the EC can function as a simple RTC.
> > Add a basic driver with this functionality.
> > 
> > Signed-off-by: Stephen Barber 
> > Signed-off-by: Enric Balletbo i Serra 
> > Acked-by: Alexandre Belloni 
> > Acked-by: Benson Leung 
> > ---
> >  drivers/rtc/Kconfig   |  10 ++
> >  drivers/rtc/Makefile  |   1 +
> >  drivers/rtc/rtc-cros-ec.c | 413 
> > ++
> >  3 files changed, 424 insertions(+)
> >  create mode 100644 drivers/rtc/rtc-cros-ec.c
> 
> This isn't quite super-helpful without the CrOS-EC / MFD additions to
> actually create the device, but it's a good start, and I don't see any
> problems with it. Any reason this isn't merged? Are the RTC maintainers
> intendending to merge this, or should Lee (for the MFD header)? I
> thought normally Lee deferred to other subsystem maintainers when the
> only "MFD" stuff was a simple header change (such as in patch 1).
> 
> Anyway, FWIW:
> 
> Reviewed-by: Brian Norris 
> Tested-by: Brian Norris 

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

[Brian Norris]

On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote:
> From: Stephen Barber 
> 
> On platforms with a Chrome OS EC, the EC can function as a simple RTC.
> Add a basic driver with this functionality.
> 
> Signed-off-by: Stephen Barber 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Alexandre Belloni 
> Acked-by: Benson Leung 
> ---
>  drivers/rtc/Kconfig   |  10 ++
>  drivers/rtc/Makefile  |   1 +
>  drivers/rtc/rtc-cros-ec.c | 413 
> ++
>  3 files changed, 424 insertions(+)
>  create mode 100644 drivers/rtc/rtc-cros-ec.c

This isn't quite super-helpful without the CrOS-EC / MFD additions to
actually create the device, but it's a good start, and I don't see any
problems with it. Any reason this isn't merged? Are the RTC maintainers
intendending to merge this, or should Lee (for the MFD header)? I
thought normally Lee deferred to other subsystem maintainers when the
only "MFD" stuff was a simple header change (such as in patch 1).

Anyway, FWIW:

Reviewed-by: Brian Norris 
Tested-by: Brian Norris 

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

[Brian Norris]

On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote:
> From: Stephen Barber 
> 
> On platforms with a Chrome OS EC, the EC can function as a simple RTC.
> Add a basic driver with this functionality.
> 
> Signed-off-by: Stephen Barber 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Alexandre Belloni 
> Acked-by: Benson Leung 
> ---
>  drivers/rtc/Kconfig   |  10 ++
>  drivers/rtc/Makefile  |   1 +
>  drivers/rtc/rtc-cros-ec.c | 413 
> ++
>  3 files changed, 424 insertions(+)
>  create mode 100644 drivers/rtc/rtc-cros-ec.c

This isn't quite super-helpful without the CrOS-EC / MFD additions to
actually create the device, but it's a good start, and I don't see any
problems with it. Any reason this isn't merged? Are the RTC maintainers
intendending to merge this, or should Lee (for the MFD header)? I
thought normally Lee deferred to other subsystem maintainers when the
only "MFD" stuff was a simple header change (such as in patch 1).

Anyway, FWIW:

Reviewed-by: Brian Norris 
Tested-by: Brian Norris 

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

[Brian Norris]

Hi,

On Fri, Nov 10, 2017 at 10:55:52PM +0100, Enric Balletbo i Serra wrote:
> From: Stephen Barber 
> 
> The EC can function as a simple RT, this patch adds the RTC related
> definitions needed by the rtc-cros-ec driver.
> 
> Signed-off-by: Stephen Barber 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Lee Jones 
> Acked-by: Benson Leung 

Reviewed-by: Brian Norris 

I guess this is waiting to get merged by an RTC maintainer, since it's a
dependency for the RTC driver in patch 2? Alessandro or Alexandre, any
thoughts?

Brian

> ---
>  include/linux/mfd/cros_ec_commands.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index 2b16e95..c6046a2 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -291,6 +291,9 @@ enum host_event_code {
>   /* EC desires to change state of host-controlled USB mux */
>   EC_HOST_EVENT_USB_MUX = 28,
>  
> + /* EC RTC event occurred */
> + EC_HOST_EVENT_RTC = 26,
> +
>   /*
>* The high bit of the event mask is not used as a host event code.  If
>* it reads back as set, then the entire event mask should be
> @@ -799,6 +802,8 @@ enum ec_feature_code {
>   EC_FEATURE_USB_MUX = 23,
>   /* Motion Sensor code has an internal software FIFO */
>   EC_FEATURE_MOTION_SENSE_FIFO = 24,
> + /* EC has RTC feature that can be controlled by host commands */
> + EC_FEATURE_RTC = 27,
>  };
>  
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -1709,6 +1714,9 @@ struct ec_response_rtc {
>  #define EC_CMD_RTC_SET_VALUE 0x46
>  #define EC_CMD_RTC_SET_ALARM 0x47
>  
> +/* Pass as param to SET_ALARM to clear the current alarm */
> +#define EC_RTC_ALARM_CLEAR 0
> +
>  
> /*/
>  /* Port80 log access */
>  

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

[Brian Norris]

Hi,

On Fri, Nov 10, 2017 at 10:55:52PM +0100, Enric Balletbo i Serra wrote:
> From: Stephen Barber 
> 
> The EC can function as a simple RT, this patch adds the RTC related
> definitions needed by the rtc-cros-ec driver.
> 
> Signed-off-by: Stephen Barber 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Lee Jones 
> Acked-by: Benson Leung 

Reviewed-by: Brian Norris 

I guess this is waiting to get merged by an RTC maintainer, since it's a
dependency for the RTC driver in patch 2? Alessandro or Alexandre, any
thoughts?

Brian

> ---
>  include/linux/mfd/cros_ec_commands.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index 2b16e95..c6046a2 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -291,6 +291,9 @@ enum host_event_code {
>   /* EC desires to change state of host-controlled USB mux */
>   EC_HOST_EVENT_USB_MUX = 28,
>  
> + /* EC RTC event occurred */
> + EC_HOST_EVENT_RTC = 26,
> +
>   /*
>* The high bit of the event mask is not used as a host event code.  If
>* it reads back as set, then the entire event mask should be
> @@ -799,6 +802,8 @@ enum ec_feature_code {
>   EC_FEATURE_USB_MUX = 23,
>   /* Motion Sensor code has an internal software FIFO */
>   EC_FEATURE_MOTION_SENSE_FIFO = 24,
> + /* EC has RTC feature that can be controlled by host commands */
> + EC_FEATURE_RTC = 27,
>  };
>  
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -1709,6 +1714,9 @@ struct ec_response_rtc {
>  #define EC_CMD_RTC_SET_VALUE 0x46
>  #define EC_CMD_RTC_SET_ALARM 0x47
>  
> +/* Pass as param to SET_ALARM to clear the current alarm */
> +#define EC_RTC_ALARM_CLEAR 0
> +
>  
> /*/
>  /* Port80 log access */
>  

Re: [PATCH v3 00/11] ASoC: fsl_ssi: Clean up - coding style level

[Timur Tabi]

On 12/13/17 5:18 PM, Nicolin Chen wrote:

Additionally, in order to fix/work-around hardware bugs and design
flaws, the driver made a lot of compromise so now its program flow
looks very complicated and it's getting hard to maintain or update.

So I am going to clean up the driver on both coding style level and
program flow level.


I'm okay with everything except patch #3.

Re: [PATCH v3 00/11] ASoC: fsl_ssi: Clean up - coding style level

[Timur Tabi]

On 12/13/17 5:18 PM, Nicolin Chen wrote:

Additionally, in order to fix/work-around hardware bugs and design
flaws, the driver made a lot of compromise so now its program flow
looks very complicated and it's getting hard to maintain or update.

So I am going to clean up the driver on both coding style level and
program flow level.


I'm okay with everything except patch #3.

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

[Tianyu Lan]

I reproduced the issue. Will have a look.

-- 
Best regards
Tianyu Lan

2017-12-15 18:14 GMT+08:00 syzbot
:
> syzkaller has found reproducer for the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> ==
> BUG: KASAN: use-after-free in __list_add include/linux/list.h:64 [inline]
> BUG: KASAN: use-after-free in list_add include/linux/list.h:79 [inline]
> BUG: KASAN: use-after-free in irq_bypass_register_consumer+0x4b4/0x500
> virt/lib/irqbypass.c:217
> Write of size 8 at addr 8801cdf51180 by task syzkaller436086/15031
>
> CPU: 1 PID: 15031 Comm: syzkaller436086 Not tainted 4.15.0-rc2-mm1+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:435
>  __list_add include/linux/list.h:64 [inline]
>  list_add include/linux/list.h:79 [inline]
>  irq_bypass_register_consumer+0x4b4/0x500 virt/lib/irqbypass.c:217
>  kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:417 [inline]
>  kvm_irqfd+0x137f/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
>  kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x44d379
> RSP: 002b:7fc5ff9a9d08 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7fc5ff9aa700 RCX: 0044d379
> RDX: 20080fe0 RSI: 4020ae76 RDI: 0005
> RBP: 007ff900 R08: 7fc5ff9aa700 R09: 7fc5ff9aa700
> R10: 7fc5ff9aa700 R11: 0246 R12: 
> R13: 007ff8ff R14: 7fc5ff9aa9c0 R15: 
>
> Allocated by task 15031:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
>  kmalloc include/linux/slab.h:516 [inline]
>  kzalloc include/linux/slab.h:705 [inline]
>  kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:296 [inline]
>  kvm_irqfd+0x16c/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
>  kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Freed by task 1402:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3492 [inline]
>  kfree+0xca/0x250 mm/slab.c:3807
>  irqfd_shutdown+0x13c/0x1a0 arch/x86/kvm/../../../virt/kvm/eventfd.c:148
>  process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>
> The buggy address belongs to the object at 8801cdf51000
>  which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 384 bytes inside of
>  512-byte region [8801cdf51000, 8801cdf51200)
> The buggy address belongs to the page:
> page:d08a0d63 count:1 mapcount:0 mapping:d54c7be6 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801cdf51000  00010006
> raw: ea00073a7660 ea000737f3a0 8801dac00940 
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  8801cdf51080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8801cdf51100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> 8801cdf51180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
>^
>  8801cdf51200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  8801cdf51280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
>

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

[Tianyu Lan]

I reproduced the issue. Will have a look.

-- 
Best regards
Tianyu Lan

2017-12-15 18:14 GMT+08:00 syzbot
:
> syzkaller has found reproducer for the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> ==
> BUG: KASAN: use-after-free in __list_add include/linux/list.h:64 [inline]
> BUG: KASAN: use-after-free in list_add include/linux/list.h:79 [inline]
> BUG: KASAN: use-after-free in irq_bypass_register_consumer+0x4b4/0x500
> virt/lib/irqbypass.c:217
> Write of size 8 at addr 8801cdf51180 by task syzkaller436086/15031
>
> CPU: 1 PID: 15031 Comm: syzkaller436086 Not tainted 4.15.0-rc2-mm1+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:435
>  __list_add include/linux/list.h:64 [inline]
>  list_add include/linux/list.h:79 [inline]
>  irq_bypass_register_consumer+0x4b4/0x500 virt/lib/irqbypass.c:217
>  kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:417 [inline]
>  kvm_irqfd+0x137f/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
>  kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x44d379
> RSP: 002b:7fc5ff9a9d08 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7fc5ff9aa700 RCX: 0044d379
> RDX: 20080fe0 RSI: 4020ae76 RDI: 0005
> RBP: 007ff900 R08: 7fc5ff9aa700 R09: 7fc5ff9aa700
> R10: 7fc5ff9aa700 R11: 0246 R12: 
> R13: 007ff8ff R14: 7fc5ff9aa9c0 R15: 
>
> Allocated by task 15031:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
>  kmalloc include/linux/slab.h:516 [inline]
>  kzalloc include/linux/slab.h:705 [inline]
>  kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:296 [inline]
>  kvm_irqfd+0x16c/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
>  kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Freed by task 1402:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3492 [inline]
>  kfree+0xca/0x250 mm/slab.c:3807
>  irqfd_shutdown+0x13c/0x1a0 arch/x86/kvm/../../../virt/kvm/eventfd.c:148
>  process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>
> The buggy address belongs to the object at 8801cdf51000
>  which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 384 bytes inside of
>  512-byte region [8801cdf51000, 8801cdf51200)
> The buggy address belongs to the page:
> page:d08a0d63 count:1 mapcount:0 mapping:d54c7be6 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801cdf51000  00010006
> raw: ea00073a7660 ea000737f3a0 8801dac00940 
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  8801cdf51080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8801cdf51100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> 8801cdf51180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
>^
>  8801cdf51200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  8801cdf51280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
>

Re: [GIT PULL] Immutable branch between MFD and Platform due for the v4.16 merge window

[Benson Leung]

Hi Lee,

On Fri, Dec 15, 2017 at 10:48:20AM +, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-platform-v4.16
> 
> for you to fetch changes up to 5e0115581bbc367c7958bf5ab8c511b808558533:
> 
>   cros_ec: Move cros_ec_dev module to drivers/mfd (2017-12-15 10:46:06 +)
> 
> 
> Immutable branch between MFD and Platform due for the v4.16 merge window
> 
> 
> Thierry Escande (2):
>   cros_ec: Split cros_ec_devs module
>   cros_ec: Move cros_ec_dev module to drivers/mfd
> 
>  drivers/mfd/Kconfig| 10 ++
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/cros_ec.c  |  4 ++--
>  drivers/{platform/chrome => mfd}/cros_ec_dev.c |  8 +---
>  drivers/{platform/chrome => mfd}/cros_ec_dev.h |  0
>  drivers/platform/chrome/Kconfig| 10 ++
>  drivers/platform/chrome/Makefile   |  7 +++
>  drivers/platform/chrome/cros_ec_debugfs.c  |  5 ++---
>  drivers/platform/chrome/cros_ec_debugfs.h  | 27 
> --
>  drivers/platform/chrome/cros_ec_lightbar.c |  6 --
>  drivers/platform/chrome/cros_ec_sysfs.c|  5 +++--
>  drivers/platform/chrome/cros_ec_vbc.c  |  1 +
>  include/linux/mfd/cros_ec.h|  4 
>  13 files changed, 37 insertions(+), 51 deletions(-)
>  rename drivers/{platform/chrome => mfd}/cros_ec_dev.c (99%)
>  rename drivers/{platform/chrome => mfd}/cros_ec_dev.h (100%)
>  delete mode 100644 drivers/platform/chrome/cros_ec_debugfs.h
>  
> -- 
> Lee Jones
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


Excellent. Pulled. Thank you so much!

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [GIT PULL] Immutable branch between MFD and Platform due for the v4.16 merge window

[Benson Leung]

Hi Lee,

On Fri, Dec 15, 2017 at 10:48:20AM +, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-platform-v4.16
> 
> for you to fetch changes up to 5e0115581bbc367c7958bf5ab8c511b808558533:
> 
>   cros_ec: Move cros_ec_dev module to drivers/mfd (2017-12-15 10:46:06 +)
> 
> 
> Immutable branch between MFD and Platform due for the v4.16 merge window
> 
> 
> Thierry Escande (2):
>   cros_ec: Split cros_ec_devs module
>   cros_ec: Move cros_ec_dev module to drivers/mfd
> 
>  drivers/mfd/Kconfig| 10 ++
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/cros_ec.c  |  4 ++--
>  drivers/{platform/chrome => mfd}/cros_ec_dev.c |  8 +---
>  drivers/{platform/chrome => mfd}/cros_ec_dev.h |  0
>  drivers/platform/chrome/Kconfig| 10 ++
>  drivers/platform/chrome/Makefile   |  7 +++
>  drivers/platform/chrome/cros_ec_debugfs.c  |  5 ++---
>  drivers/platform/chrome/cros_ec_debugfs.h  | 27 
> --
>  drivers/platform/chrome/cros_ec_lightbar.c |  6 --
>  drivers/platform/chrome/cros_ec_sysfs.c|  5 +++--
>  drivers/platform/chrome/cros_ec_vbc.c  |  1 +
>  include/linux/mfd/cros_ec.h|  4 
>  13 files changed, 37 insertions(+), 51 deletions(-)
>  rename drivers/{platform/chrome => mfd}/cros_ec_dev.c (99%)
>  rename drivers/{platform/chrome => mfd}/cros_ec_dev.h (100%)
>  delete mode 100644 drivers/platform/chrome/cros_ec_debugfs.h
>  
> -- 
> Lee Jones
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


Excellent. Pulled. Thank you so much!

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

[...]
>
>> + case ESR_ELx_AET_UER:   /* The error has not been propagated */
>> + /*
>> +  * Userspace only handle the guest SError Interrupt(SEI) if the
>> +  * error has not been propagated
>> +  */
>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>> + run->ex.exception = ESR_ELx_EC_SERROR;
>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> + return 0;
>
> We should not pass RAS notifications to user space. The kernel either handles
> them, or it panics(). User space shouldn't even know if the kernel supports 
> RAS

For the  ESR_ELx_AET_UER(Recoverable error), let us see its definition
below, which get from [0]

The state of the PE is Recoverable if all of the following are true:
— The error has not been silently propagated.
— The error has not been architecturally consumed by the PE. (The PE
architectural state is not infected.)
— The exception is precise and PE can recover execution from the
preferred return address of the exception, if software locates and
repairs the error.
The PE cannot make correct progress without either consuming the error
or otherwise making the error unrecoverable. The error remains latent
in the system.
If software cannot locate and repair the error, either the application
or the VM, or both, must be isolated by software.

so we can see the  exception is precise and PE can recover execution
from the preferred return address of the exception, so let guest
handling it is
better, for example, if it is guest application RAS error, we can kill
the guest application instead of panic whole OS; if it is guest kernel
RAS error, guest will panic.
Host does not know which application of guest has error, so host can
not handle it, panic OS is not a good choice for the Recoverable
error.

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf


> until it gets an MCEERR signal.

user space will detect whether kernel support RAS before handing it.

>
> You're making your firmware-first notification an EL3->EL0 signal, bypassing 
> the OS.
>
> If we get a RAS SError and there are no CPER records or values in the ERR 
> nodes,
> we should panic as it looks like the CPU/firmware is broken. (spurious RAS 
> errors)


>
>
>> + default:
>> + /*
>> +  * Until now, the CPU supports RAS and SEI is fatal, or host
>> +  * does not support to handle the SError.
>> +  */
>> + panic("This Asynchronous SError interrupt is dangerous, 
>> panic");
>> + }
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>>   * proper exit to userspace.
>
>
>
> James
> ___
> kvmarm mailing list
> kvm...@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

[...]
>
>> + case ESR_ELx_AET_UER:   /* The error has not been propagated */
>> + /*
>> +  * Userspace only handle the guest SError Interrupt(SEI) if the
>> +  * error has not been propagated
>> +  */
>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>> + run->ex.exception = ESR_ELx_EC_SERROR;
>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> + return 0;
>
> We should not pass RAS notifications to user space. The kernel either handles
> them, or it panics(). User space shouldn't even know if the kernel supports 
> RAS

For the  ESR_ELx_AET_UER(Recoverable error), let us see its definition
below, which get from [0]

The state of the PE is Recoverable if all of the following are true:
— The error has not been silently propagated.
— The error has not been architecturally consumed by the PE. (The PE
architectural state is not infected.)
— The exception is precise and PE can recover execution from the
preferred return address of the exception, if software locates and
repairs the error.
The PE cannot make correct progress without either consuming the error
or otherwise making the error unrecoverable. The error remains latent
in the system.
If software cannot locate and repair the error, either the application
or the VM, or both, must be isolated by software.

so we can see the  exception is precise and PE can recover execution
from the preferred return address of the exception, so let guest
handling it is
better, for example, if it is guest application RAS error, we can kill
the guest application instead of panic whole OS; if it is guest kernel
RAS error, guest will panic.
Host does not know which application of guest has error, so host can
not handle it, panic OS is not a good choice for the Recoverable
error.

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf


> until it gets an MCEERR signal.

user space will detect whether kernel support RAS before handing it.

>
> You're making your firmware-first notification an EL3->EL0 signal, bypassing 
> the OS.
>
> If we get a RAS SError and there are no CPER records or values in the ERR 
> nodes,
> we should panic as it looks like the CPU/firmware is broken. (spurious RAS 
> errors)


>
>
>> + default:
>> + /*
>> +  * Until now, the CPU supports RAS and SEI is fatal, or host
>> +  * does not support to handle the SError.
>> +  */
>> + panic("This Asynchronous SError interrupt is dangerous, 
>> panic");
>> + }
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>>   * proper exit to userspace.
>
>
>
> James
> ___
> kvmarm mailing list
> kvm...@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

[Timur Tabi]

On 12/13/17 5:18 PM, Nicolin Chen wrote:

-* We are running on a SoC which does not support online SSI
-* reconfiguration, so we have to enable all necessary flags at once
-* even if we do not use them later (capture and playback configuration)
+* Online configuration is not supported
+* Enable or Disable all necessary bits at once


This is an example of a bad change, IMHO.  The original was written in 
elegant prose.  The new version is just two short sentences.

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

[Timur Tabi]

On 12/13/17 5:18 PM, Nicolin Chen wrote:

-* We are running on a SoC which does not support online SSI
-* reconfiguration, so we have to enable all necessary flags at once
-* even if we do not use them later (capture and playback configuration)
+* Online configuration is not supported
+* Enable or Disable all necessary bits at once


This is an example of a bad change, IMHO.  The original was written in 
elegant prose.  The new version is just two short sentences.

[PATCH] ext4: delayed inode update for the consistency of file size after a crash

[Seongbae Son]

> > 1. Current file offset of fileA is 14 KB. An application appends 2 KB data 
> > to
> > fileA by executing a write() system call. At this time, the file size in
> > the ext4_inode of fileA is updated to 16 KB by ext4_da_write_end().
> > 2. Current file offset of fileB is 14 KB. An application appends 2 KB data 
> > to
> > fileB by executing a write() system call. At this time, the file size in
> > the ext4_inode of fileB is updated to 16 KB by ext4_da_write_end().
> > 3. A fsync(fileB) is called before the kworker thread runs. At this time,
> > the application thread transfers the data block of fileB to storage and
> > wakes up the JBD2. Then, JBD2 writes the ext4_inodes of fileA and fileB in
> > the running transaction to the journal area. The ext4_inode of fileA in
> > the journal area has the file size, 16 KB, even though the data block of
> > fileA has not been written to storage.
> > 4. Assume that a system crash occurs. The EXT4 recovery module recovers
> > the inodes of fileA and fileB. The recovered inode of fileA has the updated
> > file size, 16 KB, even though the data of fileA has not been made durable.
> > The data block of fileA between 14 KB and 16 KB is seen as zeros.

> There's nothing wrong with this.  The user space application called
> fsync on fileB, and *not* on fileA.  Therefore, there is absolutely no
> guarantee that fileA's data contents are valid.
> 
> Consider the exact same thing will happen if the application had
> written data to fileA at offsets 6k to 8k.  If those offsets were
> previously zero, then after the crash, those offsets *might* still be
> zero after the crash, *unless* the application had first called
> fsync() or fdatasync() first.

> > Details can be found as follows.
> >
> > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 Filesystem”,
> > In Proc. of APSYS 2017, Mumbai, India

> This is behind a paywall, so I can't access it.  I am sorry I wasn't
> on the program committee, or I would have pointed this out while the
> paper was being reviewed.

Hello Ted,

Thanks for your quick answer.
I am sorry about that. I could not think about the paywall.

> The problem with providing more guarantees than what is strictly
> provided for by POSIX is that it degrades the performance of the file
> system.  It can also promote application writes to depend on semantics
> which are non-portable, which can cause problems when they try to run
> that progam on other operating systems or other file systems.

I have performed the above scenario to xfs, btrfs, f2fs, and zfs.
As the test result, all of the four file systems does not have the problem
that fileA in which fsync() was not executed has the wrong file size
after a system crash. So, I think, the portability of applications might be
okay even though EXT4 guarantees the consistency between the file size and
the data blocks of the file that fsync() is not executed after a system crash.

Many thanks,

Seongbae Son.

[PATCH] ext4: delayed inode update for the consistency of file size after a crash

[Seongbae Son]

> > 1. Current file offset of fileA is 14 KB. An application appends 2 KB data 
> > to
> > fileA by executing a write() system call. At this time, the file size in
> > the ext4_inode of fileA is updated to 16 KB by ext4_da_write_end().
> > 2. Current file offset of fileB is 14 KB. An application appends 2 KB data 
> > to
> > fileB by executing a write() system call. At this time, the file size in
> > the ext4_inode of fileB is updated to 16 KB by ext4_da_write_end().
> > 3. A fsync(fileB) is called before the kworker thread runs. At this time,
> > the application thread transfers the data block of fileB to storage and
> > wakes up the JBD2. Then, JBD2 writes the ext4_inodes of fileA and fileB in
> > the running transaction to the journal area. The ext4_inode of fileA in
> > the journal area has the file size, 16 KB, even though the data block of
> > fileA has not been written to storage.
> > 4. Assume that a system crash occurs. The EXT4 recovery module recovers
> > the inodes of fileA and fileB. The recovered inode of fileA has the updated
> > file size, 16 KB, even though the data of fileA has not been made durable.
> > The data block of fileA between 14 KB and 16 KB is seen as zeros.

> There's nothing wrong with this.  The user space application called
> fsync on fileB, and *not* on fileA.  Therefore, there is absolutely no
> guarantee that fileA's data contents are valid.
> 
> Consider the exact same thing will happen if the application had
> written data to fileA at offsets 6k to 8k.  If those offsets were
> previously zero, then after the crash, those offsets *might* still be
> zero after the crash, *unless* the application had first called
> fsync() or fdatasync() first.

> > Details can be found as follows.
> >
> > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 Filesystem”,
> > In Proc. of APSYS 2017, Mumbai, India

> This is behind a paywall, so I can't access it.  I am sorry I wasn't
> on the program committee, or I would have pointed this out while the
> paper was being reviewed.

Hello Ted,

Thanks for your quick answer.
I am sorry about that. I could not think about the paywall.

> The problem with providing more guarantees than what is strictly
> provided for by POSIX is that it degrades the performance of the file
> system.  It can also promote application writes to depend on semantics
> which are non-portable, which can cause problems when they try to run
> that progam on other operating systems or other file systems.

I have performed the above scenario to xfs, btrfs, f2fs, and zfs.
As the test result, all of the four file systems does not have the problem
that fileA in which fsync() was not executed has the wrong file size
after a system crash. So, I think, the portability of applications might be
okay even though EXT4 guarantees the consistency between the file size and
the data blocks of the file that fsync() is not executed after a system crash.

Many thanks,

Seongbae Son.

Re: [PATCH v19 3/7] xbitmap: add more operations

[Tetsuo Handa]

Michael S. Tsirkin wrote:
> On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > My understanding is that virtio-balloon wants to handle sparsely spreaded
> > unsigned long values (which is PATCH 4/7) and wants to find all chunks of
> > consecutive "1" bits efficiently. Therefore, I guess that holding the values
> > in ascending order at store time is faster than sorting the values at read
> > time.
> 
> Are you asking why is a bitmap used here, as opposed to a tree?

No. I'm OK with "segments using trees" + "offsets using bitmaps".

>  It's
> not just store versus read. There's also the issue that memory can get
> highly fragmented, if it is, the number of 1s is potentially very high.
> A bitmap can use as little as 1 bit per value, it is hard to beat in
> this respect.
> 

I'm asking whether we really need to invent a new library module (i.e.
PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.

What virtio-balloon needs is ability to

  (1) record any integer value in [0, ULONG_MAX] range

  (2) fetch all recorded values, with consecutive values combined in
  min,max (or start,count) form for efficiently

and I wonder whether we need to invent complete API set which
Matthew Wilcox and Wei Wang are planning for generic purpose.

Re: [PATCH v19 3/7] xbitmap: add more operations

[Tetsuo Handa]

Michael S. Tsirkin wrote:
> On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > My understanding is that virtio-balloon wants to handle sparsely spreaded
> > unsigned long values (which is PATCH 4/7) and wants to find all chunks of
> > consecutive "1" bits efficiently. Therefore, I guess that holding the values
> > in ascending order at store time is faster than sorting the values at read
> > time.
> 
> Are you asking why is a bitmap used here, as opposed to a tree?

No. I'm OK with "segments using trees" + "offsets using bitmaps".

>  It's
> not just store versus read. There's also the issue that memory can get
> highly fragmented, if it is, the number of 1s is potentially very high.
> A bitmap can use as little as 1 bit per value, it is hard to beat in
> this respect.
> 

I'm asking whether we really need to invent a new library module (i.e.
PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.

What virtio-balloon needs is ability to

  (1) record any integer value in [0, ULONG_MAX] range

  (2) fetch all recorded values, with consecutive values combined in
  min,max (or start,count) form for efficiently

and I wonder whether we need to invent complete API set which
Matthew Wilcox and Wei Wang are planning for generic purpose.

[PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

[Dave Young]

'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
chance to run because the code path is before parse_early_param().
I believe it worked when the param was introduced but probably later
some other changes caused the wrong order and nobody noticed it.

Move efi_memblock_x86_reserve_range() after parse_early_param()
to fix it.

Signed-off-by: Dave Young 
---
 arch/x86/kernel/setup.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -906,9 +906,6 @@ void __init setup_arch(char **cmdline_p)
set_bit(EFI_BOOT, );
set_bit(EFI_64BIT, );
}
-
-   if (efi_enabled(EFI_BOOT))
-   efi_memblock_x86_reserve_range();
 #endif
 
x86_init.oem.arch_setup();
@@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p)
 
parse_early_param();
 
+   if (efi_enabled(EFI_BOOT))
+   efi_memblock_x86_reserve_range();
 #ifdef CONFIG_MEMORY_HOTPLUG
/*
 * Memory used by the kernel cannot be hot-removed because Linux

[PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

[Dave Young]

'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
chance to run because the code path is before parse_early_param().
I believe it worked when the param was introduced but probably later
some other changes caused the wrong order and nobody noticed it.

Move efi_memblock_x86_reserve_range() after parse_early_param()
to fix it.

Signed-off-by: Dave Young 
---
 arch/x86/kernel/setup.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -906,9 +906,6 @@ void __init setup_arch(char **cmdline_p)
set_bit(EFI_BOOT, );
set_bit(EFI_64BIT, );
}
-
-   if (efi_enabled(EFI_BOOT))
-   efi_memblock_x86_reserve_range();
 #endif
 
x86_init.oem.arch_setup();
@@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p)
 
parse_early_param();
 
+   if (efi_enabled(EFI_BOOT))
+   efi_memblock_x86_reserve_range();
 #ifdef CONFIG_MEMORY_HOTPLUG
/*
 * Memory used by the kernel cannot be hot-removed because Linux

Re: [PATCH 01/19] fs: new API for handling inode->i_version

[NeilBrown]

On Wed, Dec 13 2017, Jeff Layton wrote:

> On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
>> On Wed, Dec 13 2017, Jeff Layton wrote:
>> 
>> > +/*
>> > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for
>> > + * knfsd, but is also used for other purposes (e.g. IMA). The i_version 
>> > must
>> > + * appear different to observers if there was a change to the inode's 
>> > data or
>> > + * metadata since it was last queried.
>> > + *
>> > + * It should be considered an opaque value by observers. If it remains 
>> > the same
>> > + * since it was last checked, then nothing has changed in the inode. If 
>> > it's
>> > + * different then something has changed. Observers cannot infer anything 
>> > about
>> > + * the nature or magnitude of the changes from the value, only that the 
>> > inode
>> > + * has changed in some fashion.
>> 
>> I agree that it "should be" considered opaque, but I have a suspicion
>> that NFSv4 doesn't consider it opaque.
>> There is something about write delegations and the server performing a
>> GETATTR callback to the delegated client so that it can answer GETATTR
>> from other clients without recalling the delegation.
>> 
>> Specifically section "10.4.3 Handling of CB_GETATTR" of RFC5661 contains
>> the text:
>> 
>>o  The client will create a value greater than c that will be used
>>   for communicating that modified data is held at the client.  Let
>>   this value be represented by d.
>> 
>> "c" here is a 'change' attribute.
>> 
>> Then:
>> 
>>While the change attribute is opaque to the client in the sense that
>>it has no idea what units of time, if any, the server is counting
>>change with, it is not opaque in that the client has to treat it as
>>an unsigned integer, and the server has to be able to see the results
>>of the client's changes to that integer.  Therefore, the server MUST
>>encode the change attribute in network order when sending it to the
>>client.  The client MUST decode it from network order to its native
>>order when receiving it, and the client MUST encode it in network
>>order when sending it to the server.  For this reason, change is
>>defined as an unsigned integer rather than an opaque array of bytes.
>> 
>> This all suggests that nfsd needs to be certain that "incrementing" the
>> change id will produce a new changeid, which has not been used before,
>> and also suggests that nfsd needs to be able to control the changeid
>> stored after writes that result from a delegation being returned.
>> 
>> I'd just like to say that this is one of the most annoying dumb features
>> of NFSv4, because it is trivial to fix and I suggested a fix before
>> NFSv4.0 was finalized.  Grumble.
>> 
>> Otherwise the patch set looks good.  I haven't gone over the code
>> closely, the but approach is spot-on.
>
> I don't think we have to do that. There are really only two states with
> a client holding a write delegation, as far as the server is concerned.
> Either:
>
> a) the client has done no writes to the file, in which case it'll return
> the same i_version that the server has when issued a CB_GETATTR
>
> ...or...
>
> b) it has written to the file while holding the delegation, in which
> case it'll return a different CB_GETATTR to the server
>
> The simplest thing for the server to do is to just increment the change
> attribute _once_ when it gets back a CB_GETATTR with a different change
> attr than it has.
>
> That's sufficient to tell another client issuing a a GETATTR that the
> file has changed without needing to recall the delegation.
>
> Prior to the delegation being returned, the client will send at least
> one WRITE RPC, and that's enough to ensure that the the next stat will
> see the thing increase.

"increment" and "increase" are not words that mean anything for an
"opaque value".
NFSd is, presumably, an "observer" of i_version (as it isn't the
filesytem that controls it), so your text says it must treat i_version as
opaque.  That means it cannot detect an "increase" (only a change), and
it certainly cannot "increment" the value.

I think you need to allow observers to treat i_version as a 64 bit number
which will monotonically increase.  Any change to the file will result
in an increment of at least '1'.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 01/19] fs: new API for handling inode->i_version

[NeilBrown]

On Wed, Dec 13 2017, Jeff Layton wrote:

> On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
>> On Wed, Dec 13 2017, Jeff Layton wrote:
>> 
>> > +/*
>> > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for
>> > + * knfsd, but is also used for other purposes (e.g. IMA). The i_version 
>> > must
>> > + * appear different to observers if there was a change to the inode's 
>> > data or
>> > + * metadata since it was last queried.
>> > + *
>> > + * It should be considered an opaque value by observers. If it remains 
>> > the same
>> > + * since it was last checked, then nothing has changed in the inode. If 
>> > it's
>> > + * different then something has changed. Observers cannot infer anything 
>> > about
>> > + * the nature or magnitude of the changes from the value, only that the 
>> > inode
>> > + * has changed in some fashion.
>> 
>> I agree that it "should be" considered opaque, but I have a suspicion
>> that NFSv4 doesn't consider it opaque.
>> There is something about write delegations and the server performing a
>> GETATTR callback to the delegated client so that it can answer GETATTR
>> from other clients without recalling the delegation.
>> 
>> Specifically section "10.4.3 Handling of CB_GETATTR" of RFC5661 contains
>> the text:
>> 
>>o  The client will create a value greater than c that will be used
>>   for communicating that modified data is held at the client.  Let
>>   this value be represented by d.
>> 
>> "c" here is a 'change' attribute.
>> 
>> Then:
>> 
>>While the change attribute is opaque to the client in the sense that
>>it has no idea what units of time, if any, the server is counting
>>change with, it is not opaque in that the client has to treat it as
>>an unsigned integer, and the server has to be able to see the results
>>of the client's changes to that integer.  Therefore, the server MUST
>>encode the change attribute in network order when sending it to the
>>client.  The client MUST decode it from network order to its native
>>order when receiving it, and the client MUST encode it in network
>>order when sending it to the server.  For this reason, change is
>>defined as an unsigned integer rather than an opaque array of bytes.
>> 
>> This all suggests that nfsd needs to be certain that "incrementing" the
>> change id will produce a new changeid, which has not been used before,
>> and also suggests that nfsd needs to be able to control the changeid
>> stored after writes that result from a delegation being returned.
>> 
>> I'd just like to say that this is one of the most annoying dumb features
>> of NFSv4, because it is trivial to fix and I suggested a fix before
>> NFSv4.0 was finalized.  Grumble.
>> 
>> Otherwise the patch set looks good.  I haven't gone over the code
>> closely, the but approach is spot-on.
>
> I don't think we have to do that. There are really only two states with
> a client holding a write delegation, as far as the server is concerned.
> Either:
>
> a) the client has done no writes to the file, in which case it'll return
> the same i_version that the server has when issued a CB_GETATTR
>
> ...or...
>
> b) it has written to the file while holding the delegation, in which
> case it'll return a different CB_GETATTR to the server
>
> The simplest thing for the server to do is to just increment the change
> attribute _once_ when it gets back a CB_GETATTR with a different change
> attr than it has.
>
> That's sufficient to tell another client issuing a a GETATTR that the
> file has changed without needing to recall the delegation.
>
> Prior to the delegation being returned, the client will send at least
> one WRITE RPC, and that's enough to ensure that the the next stat will
> see the thing increase.

"increment" and "increase" are not words that mean anything for an
"opaque value".
NFSd is, presumably, an "observer" of i_version (as it isn't the
filesytem that controls it), so your text says it must treat i_version as
opaque.  That means it cannot detect an "increase" (only a change), and
it certainly cannot "increment" the value.

I think you need to allow observers to treat i_version as a 64 bit number
which will monotonically increase.  Any change to the file will result
in an increment of at least '1'.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

[PATCH for-4.15] ASoC: rt5514-spi: only enable wakeup when fully initialized

[Brian Norris]

If an rt5514-spi device is probed but the platform hasn't linked it in,
we might never fully request the SPI IRQ, nor configure the rt5514 DSP,
but we still might try to enable the SPI IRQ (enable_irq_wake()). This
is bad, and among other things, can cause the interrupt to trigger every
time we try to suspend the system (e.g., because the interrupt trigger
setting was never set properly).

Instead of setting our wakeup capabilities in the SPI driver probe
routine, let's wait until we've actually requested the IRQ.

Fixes issues seen on the "kevin" Chromebook (Samsung Chromebook Plus).

Fixes: 58f1c07d23cd ("ASoC: rt5514: Voice wakeup support.")
Signed-off-by: Brian Norris 
---
The patch that introduced the wakeup was in 4.15-rc1. I think this qualifies as
a bugfix, and should probably go into 4.15.

Other relevant patches that are useful, and fix similar (or the same) issues:

https://patchwork.kernel.org/patch/10067725/
[PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

https://patchwork.kernel.org/patch/10116761/
[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

 sound/soc/codecs/rt5514-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 9255afcf2c3a..48e4b9002caf 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -289,6 +289,8 @@ static int rt5514_spi_pcm_probe(struct snd_soc_platform 
*platform)
dev_err(_spi->dev,
"%s Failed to reguest IRQ: %d\n", __func__,
ret);
+   else
+   device_init_wakeup(rt5514_dsp->dev, true);
}
 
return 0;
@@ -456,8 +458,6 @@ static int rt5514_spi_probe(struct spi_device *spi)
return ret;
}
 
-   device_init_wakeup(>dev, true);
-
return 0;
 }
 
-- 
2.15.1.504.g5279b80103-goog

[PATCH for-4.15] ASoC: rt5514-spi: only enable wakeup when fully initialized

[Brian Norris]

If an rt5514-spi device is probed but the platform hasn't linked it in,
we might never fully request the SPI IRQ, nor configure the rt5514 DSP,
but we still might try to enable the SPI IRQ (enable_irq_wake()). This
is bad, and among other things, can cause the interrupt to trigger every
time we try to suspend the system (e.g., because the interrupt trigger
setting was never set properly).

Instead of setting our wakeup capabilities in the SPI driver probe
routine, let's wait until we've actually requested the IRQ.

Fixes issues seen on the "kevin" Chromebook (Samsung Chromebook Plus).

Fixes: 58f1c07d23cd ("ASoC: rt5514: Voice wakeup support.")
Signed-off-by: Brian Norris 
---
The patch that introduced the wakeup was in 4.15-rc1. I think this qualifies as
a bugfix, and should probably go into 4.15.

Other relevant patches that are useful, and fix similar (or the same) issues:

https://patchwork.kernel.org/patch/10067725/
[PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

https://patchwork.kernel.org/patch/10116761/
[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

 sound/soc/codecs/rt5514-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 9255afcf2c3a..48e4b9002caf 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -289,6 +289,8 @@ static int rt5514_spi_pcm_probe(struct snd_soc_platform 
*platform)
dev_err(_spi->dev,
"%s Failed to reguest IRQ: %d\n", __func__,
ret);
+   else
+   device_init_wakeup(rt5514_dsp->dev, true);
}
 
return 0;
@@ -456,8 +458,6 @@ static int rt5514_spi_probe(struct spi_device *spi)
return ret;
}
 
-   device_init_wakeup(>dev, true);
-
return 0;
 }
 
-- 
2.15.1.504.g5279b80103-goog

[PATCH v3] staging: ion: Fix ion_cma_heap allocations

[John Stultz]

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
v3: Make CMA heap depend on DMA_CMA instead of just CMA to address
the undefined CONFIG_CMA_ALIGNMENT issue.

 drivers/staging/android/ion/Kconfig|  2 +-
 drivers/staging/android/ion/ion_cma_heap.c | 15 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index a517b2d..8f64941 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -37,7 +37,7 @@ config ION_CHUNK_HEAP
 
 config ION_CMA_HEAP
bool "Ion CMA heap support"
-   depends on ION && CMA
+   depends on ION && DMA_CMA
help
  Choose this option to enable CMA heaps with Ion. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index dd5545d..86196ff 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,9 +39,15 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
struct sg_table *table;
struct page *pages;
+   unsigned long size = PAGE_ALIGN(len);
+   unsigned long nr_pages = size >> PAGE_SHIFT;
+   unsigned long align = get_order(size);
int ret;
 
-   pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+   if (align > CONFIG_CMA_ALIGNMENT)
+   align = CONFIG_CMA_ALIGNMENT;
+
+   pages = cma_alloc(cma_heap->cma, nr_pages, align, GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -53,7 +59,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (ret)
goto free_mem;
 
-   sg_set_page(table->sgl, pages, len, 0);
+   sg_set_page(table->sgl, pages, size, 0);
 
buffer->priv_virt = pages;
buffer->sg_table = table;
@@ -62,7 +68,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
 free_mem:
kfree(table);
 err:
-   cma_release(cma_heap->cma, pages, buffer->size);
+   cma_release(cma_heap->cma, pages, nr_pages);
return -ENOMEM;
 }
 
@@ -70,9 +76,10 @@ static void ion_cma_free(struct ion_buffer *buffer)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
struct page *pages = buffer->priv_virt;
+   unsigned long nr_pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
 
/* release memory */
-   cma_release(cma_heap->cma, pages, buffer->size);
+   cma_release(cma_heap->cma, pages, nr_pages);
/* release sg table */
sg_free_table(buffer->sg_table);
kfree(buffer->sg_table);
-- 
2.7.4

[PATCH v3] staging: ion: Fix ion_cma_heap allocations

[John Stultz]

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
v3: Make CMA heap depend on DMA_CMA instead of just CMA to address
the undefined CONFIG_CMA_ALIGNMENT issue.

 drivers/staging/android/ion/Kconfig|  2 +-
 drivers/staging/android/ion/ion_cma_heap.c | 15 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index a517b2d..8f64941 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -37,7 +37,7 @@ config ION_CHUNK_HEAP
 
 config ION_CMA_HEAP
bool "Ion CMA heap support"
-   depends on ION && CMA
+   depends on ION && DMA_CMA
help
  Choose this option to enable CMA heaps with Ion. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index dd5545d..86196ff 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,9 +39,15 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
struct sg_table *table;
struct page *pages;
+   unsigned long size = PAGE_ALIGN(len);
+   unsigned long nr_pages = size >> PAGE_SHIFT;
+   unsigned long align = get_order(size);
int ret;
 
-   pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+   if (align > CONFIG_CMA_ALIGNMENT)
+   align = CONFIG_CMA_ALIGNMENT;
+
+   pages = cma_alloc(cma_heap->cma, nr_pages, align, GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -53,7 +59,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (ret)
goto free_mem;
 
-   sg_set_page(table->sgl, pages, len, 0);
+   sg_set_page(table->sgl, pages, size, 0);
 
buffer->priv_virt = pages;
buffer->sg_table = table;
@@ -62,7 +68,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
 free_mem:
kfree(table);
 err:
-   cma_release(cma_heap->cma, pages, buffer->size);
+   cma_release(cma_heap->cma, pages, nr_pages);
return -ENOMEM;
 }
 
@@ -70,9 +76,10 @@ static void ion_cma_free(struct ion_buffer *buffer)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
struct page *pages = buffer->priv_virt;
+   unsigned long nr_pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
 
/* release memory */
-   cma_release(cma_heap->cma, pages, buffer->size);
+   cma_release(cma_heap->cma, pages, nr_pages);
/* release sg table */
sg_free_table(buffer->sg_table);
kfree(buffer->sg_table);
-- 
2.7.4

[PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller

[Yixun Lan]

Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.

Reviewed-by: Neil Armstrong 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d288d4724ae3..dea1bc31b4de 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "amlogic,meson-axg";
@@ -155,6 +156,19 @@
};
};
 
+   ethmac: ethernet@ff3f {
+   compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+   reg = <0x0 0xff3f 0x0 0x1
+   0x0 0xff634540 0x0 0x8>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < CLKID_ETH>,
+< CLKID_FCLK_DIV2>,
+< CLKID_MPLL2>;
+   clock-names = "stmmaceth", "clkin0", "clkin1";
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
reg = <0x0 0xffc01000 0 0x1000>,
@@ -215,6 +229,46 @@
gpio-ranges = <_periphs 0 0 86>;
};
 
+   eth_rgmii_x_pins: eth-x-rgmii {
+   mux {
+   groups = "eth_mdio_x",
+  "eth_mdc_x",
+  "eth_rgmii_rx_clk_x",
+  "eth_rx_dv_x",
+  "eth_rxd0_x",
+  "eth_rxd1_x",
+  "eth_rxd2_rgmii",
+  "eth_rxd3_rgmii",
+  "eth_rgmii_tx_clk",
+  "eth_txen_x",
+  "eth_txd0_x",
+  "eth_txd1_x",
+  "eth_txd2_rgmii",
+  "eth_txd3_rgmii";
+   function = "eth";
+   };
+   };
+
+   eth_rgmii_y_pins: eth-y-rgmii {
+   mux {
+   groups = "eth_mdio_y",
+  "eth_mdc_y",
+  "eth_rgmii_rx_clk_y",
+  "eth_rx_dv_y",
+  "eth_rxd0_y",
+  "eth_rxd1_y",
+  "eth_rxd2_rgmii",
+  "eth_rxd3_rgmii",
+  "eth_rgmii_tx_clk",
+  "eth_txen_y",
+  "eth_txd0_y",
+  "eth_txd1_y",
+  "eth_txd2_rgmii",
+  "eth_txd3_rgmii";
+   function = "eth";
+   };
+   };
+
pwm_a_a_pins: pwm_a_a {
mux {
groups = "pwm_a_a";
-- 
2.15.1

[PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller

[Yixun Lan]

Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.

Reviewed-by: Neil Armstrong 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d288d4724ae3..dea1bc31b4de 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "amlogic,meson-axg";
@@ -155,6 +156,19 @@
};
};
 
+   ethmac: ethernet@ff3f {
+   compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+   reg = <0x0 0xff3f 0x0 0x1
+   0x0 0xff634540 0x0 0x8>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < CLKID_ETH>,
+< CLKID_FCLK_DIV2>,
+< CLKID_MPLL2>;
+   clock-names = "stmmaceth", "clkin0", "clkin1";
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
reg = <0x0 0xffc01000 0 0x1000>,
@@ -215,6 +229,46 @@
gpio-ranges = <_periphs 0 0 86>;
};
 
+   eth_rgmii_x_pins: eth-x-rgmii {
+   mux {
+   groups = "eth_mdio_x",
+  "eth_mdc_x",
+  "eth_rgmii_rx_clk_x",
+  "eth_rx_dv_x",
+  "eth_rxd0_x",
+  "eth_rxd1_x",
+  "eth_rxd2_rgmii",
+  "eth_rxd3_rgmii",
+  "eth_rgmii_tx_clk",
+  "eth_txen_x",
+  "eth_txd0_x",
+  "eth_txd1_x",
+  "eth_txd2_rgmii",
+  "eth_txd3_rgmii";
+   function = "eth";
+   };
+   };
+
+   eth_rgmii_y_pins: eth-y-rgmii {
+   mux {
+   groups = "eth_mdio_y",
+  "eth_mdc_y",
+  "eth_rgmii_rx_clk_y",
+  "eth_rx_dv_y",
+  "eth_rxd0_y",
+  "eth_rxd1_y",
+  "eth_rxd2_rgmii",
+  "eth_rxd3_rgmii",
+  "eth_rgmii_tx_clk",
+  "eth_txen_y",
+  "eth_txd0_y",
+  "eth_txd1_y",
+  "eth_txd2_rgmii",
+  "eth_txd3_rgmii";
+   function = "eth";
+   };
+   };
+
pwm_a_a_pins: pwm_a_a {
mux {
groups = "pwm_a_a";
-- 
2.15.1

[PATCH v4 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board

[Yixun Lan]

This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.

Reviewed-by: Neil Armstrong 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..8932654f5090 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -17,6 +17,13 @@
};
 };
 
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+   pinctrl-0 = <_rgmii_y_pins>;
+   pinctrl-names = "default";
+};
+
 _AO {
status = "okay";
 };
-- 
2.15.1

[PATCH v4 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board

[Yixun Lan]

This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.

Reviewed-by: Neil Armstrong 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..8932654f5090 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -17,6 +17,13 @@
};
 };
 
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+   pinctrl-0 = <_rgmii_y_pins>;
+   pinctrl-names = "default";
+};
+
 _AO {
status = "okay";
 };
-- 
2.15.1

[PATCH v4 0/2] Add ethernet support for Meson-AXG SoC

[Yixun Lan]

This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.

Hi Kevin:
  You still need to at least merge the clock patch[3] in order to
compile the DTS, or just merge the tag from meson-clock's tree[6]
- the tag is 'meson-clk-for-v4.16-2', since the clock part already
taken there.


Changes in v4 since [5]:
 - rebase to kevin's v4.16/dt64
 - fix order

Changes in v3 since [4]:
 - put clock DT info in soc.dtsi
 - separate DT for 'add support for the controller' vs 'enable in board'

Changes in v2 since [1]:
 - rebase to kevin's v4.16/dt64 branch
 - add Neil's Reviewed-by
 - move clock info to board.dts instead of in soc.dtsi
 - drop "meson-axg-dwmac" compatible string, since we didn't use this
   we could re-add it later when we really need.
 - note: to make ethernet work properly,it depend on clock & pinctrl[2],
   to compile the DTS, the patch [3] is required.
   the code part will be taken via clock & pinctrl subsystem tree.

[5]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005783.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005784.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005785.html

[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html

[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html

[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html

[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html

[6] git://github.com/BayLibre/clk-meson.git

Yixun Lan (2):
  ARM64: dts: meson-axg: add ethernet mac controller
  ARM64: dts: meson-axg: enable ethernet for A113D S400 board

 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts |  7 
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++
 2 files changed, 61 insertions(+)

-- 
2.15.1

[PATCH v4 0/2] Add ethernet support for Meson-AXG SoC

[Yixun Lan]

This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.

Hi Kevin:
  You still need to at least merge the clock patch[3] in order to
compile the DTS, or just merge the tag from meson-clock's tree[6]
- the tag is 'meson-clk-for-v4.16-2', since the clock part already
taken there.


Changes in v4 since [5]:
 - rebase to kevin's v4.16/dt64
 - fix order

Changes in v3 since [4]:
 - put clock DT info in soc.dtsi
 - separate DT for 'add support for the controller' vs 'enable in board'

Changes in v2 since [1]:
 - rebase to kevin's v4.16/dt64 branch
 - add Neil's Reviewed-by
 - move clock info to board.dts instead of in soc.dtsi
 - drop "meson-axg-dwmac" compatible string, since we didn't use this
   we could re-add it later when we really need.
 - note: to make ethernet work properly,it depend on clock & pinctrl[2],
   to compile the DTS, the patch [3] is required.
   the code part will be taken via clock & pinctrl subsystem tree.

[5]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005783.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005784.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005785.html

[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html

[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html

[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html

[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html

[6] git://github.com/BayLibre/clk-meson.git

Yixun Lan (2):
  ARM64: dts: meson-axg: add ethernet mac controller
  ARM64: dts: meson-axg: enable ethernet for A113D S400 board

 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts |  7 
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++
 2 files changed, 61 insertions(+)

-- 
2.15.1

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

Hi James,

On 2017/12/16 2:52, James Morse wrote:
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown 
>> below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify 
>> trigger method, which all
>>
>> not involve _trigger_ an SError.
> It's a policy choice. How does your virtual CPU notify RAS errors to its 
> virtual
> software? You could use SError for SIGBUS_MCEERR_AR, it depends on what type 
> of
> CPU you are trying to emulate.
> 
> I'd suggest using NOTIFY_SEA for SIGBUS_MCEERR_AR as it avoids problems where
> the guest doesn't take the SError immediately, instead tries to re-execute the
I agree it is better to use NOTIFY_SEA for SIGBUS_MCEERR_AR in this case.

> code KVM has unmapped from stage2 because its corrupt. (You could detect this
> happening in Qemu and try something else)For something else, using NOTIFY_SEI 
> for SIGBUS_MCEERR_AR? At current implementation,
It seems only have this case that "KVM has unmapped from stage2", do you thing 
we still have something else?

> 
> 
> Synchronous/asynchronous external abort matters to the CPU, but once the error
> has been notified to software the reasons for this distinction disappear. Once
> the error has been handled, all trace of this distinction is gone.
> 
> CPER records only describe component failures. You are trying to re-create 
> some
> state that disappeared with one of the firmware-first abstractions. Trying to
> re-create this information isn't worth the effort as the distinction doesn't
> matter to linux, only to the CPU.
> 
> 
>> so there is no chance for Qemu to trigger the SError when gets the 
>> SIGBUS_MCEERR_A{O,R}.
> You mean there is no reason for Qemu to trigger an SError when it gets a 
> signal
> from the kernel.
> 
> The reasons the CPU might have to generate an SError don't apply to linux and
> KVM user space. User-space will never get a signal for an uncontained error, 
> we
> will always panic(). We can't give user-space a signal for imprecise 
> exceptions,
> as it can't return from the signal. The classes of error that are left are
> covered by polled/irq and NOTIFY_SEA.
> 
> Qemu can decide to generate RAS SErrors for SIGBUS_MCEERR_AR if it really 
> wants
> to, (but I don't think you should, the kernel may have unmapped the page at PC
> from stage2 due to corruption).
yes, you also said you do not want to generate RAS SErrors for SIGBUS_MCEERR_AR,
so Qemu does not know in which condition to generate RAS SErrors.

> 
> I think the problem here is you're applying the CPU->software behaviour and
> choices to software->software. By the time user-space gets the error, the
> behaviour is different.
In the KVM, as a policy choice to reserve this API to specify guest ESR and 
drive to trigger SError is OK,
At least for Qemu it does not know in which condition to trigger it.

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

Hi James,

On 2017/12/16 2:52, James Morse wrote:
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown 
>> below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify 
>> trigger method, which all
>>
>> not involve _trigger_ an SError.
> It's a policy choice. How does your virtual CPU notify RAS errors to its 
> virtual
> software? You could use SError for SIGBUS_MCEERR_AR, it depends on what type 
> of
> CPU you are trying to emulate.
> 
> I'd suggest using NOTIFY_SEA for SIGBUS_MCEERR_AR as it avoids problems where
> the guest doesn't take the SError immediately, instead tries to re-execute the
I agree it is better to use NOTIFY_SEA for SIGBUS_MCEERR_AR in this case.

> code KVM has unmapped from stage2 because its corrupt. (You could detect this
> happening in Qemu and try something else)For something else, using NOTIFY_SEI 
> for SIGBUS_MCEERR_AR? At current implementation,
It seems only have this case that "KVM has unmapped from stage2", do you thing 
we still have something else?

> 
> 
> Synchronous/asynchronous external abort matters to the CPU, but once the error
> has been notified to software the reasons for this distinction disappear. Once
> the error has been handled, all trace of this distinction is gone.
> 
> CPER records only describe component failures. You are trying to re-create 
> some
> state that disappeared with one of the firmware-first abstractions. Trying to
> re-create this information isn't worth the effort as the distinction doesn't
> matter to linux, only to the CPU.
> 
> 
>> so there is no chance for Qemu to trigger the SError when gets the 
>> SIGBUS_MCEERR_A{O,R}.
> You mean there is no reason for Qemu to trigger an SError when it gets a 
> signal
> from the kernel.
> 
> The reasons the CPU might have to generate an SError don't apply to linux and
> KVM user space. User-space will never get a signal for an uncontained error, 
> we
> will always panic(). We can't give user-space a signal for imprecise 
> exceptions,
> as it can't return from the signal. The classes of error that are left are
> covered by polled/irq and NOTIFY_SEA.
> 
> Qemu can decide to generate RAS SErrors for SIGBUS_MCEERR_AR if it really 
> wants
> to, (but I don't think you should, the kernel may have unmapped the page at PC
> from stage2 due to corruption).
yes, you also said you do not want to generate RAS SErrors for SIGBUS_MCEERR_AR,
so Qemu does not know in which condition to generate RAS SErrors.

> 
> I think the problem here is you're applying the CPU->software behaviour and
> choices to software->software. By the time user-space gets the error, the
> behaviour is different.
In the KVM, as a policy choice to reserve this API to specify guest ESR and 
drive to trigger SError is OK,
At least for Qemu it does not know in which condition to trigger it.

[PATCH v1 1/1] usb: xhci: do not create and register shared_hcd when USB3.0 is disabled

[Thang Q. Nguyen]

From: Tung Nguyen 

Currently, hcd->shared_hcd always creates and registers to the usb-core.
If, for some reasons, USB3 downstream port is disabled, no roothub port for
USB3.0 is found. This causes kernel to display an error:
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
This patch checks, creates and registers shared_hcd if USB3.0 downstream
port is available.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
 drivers/usb/host/xhci-mem.c  |  2 +-
 drivers/usb/host/xhci-plat.c | 26 +++--
 drivers/usb/host/xhci.c  | 54 
 3 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 554a8a5..157d1e7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1067,7 +1067,7 @@ static u32 xhci_find_real_port_number(struct xhci_hcd 
*xhci,
struct usb_device *top_dev;
struct usb_hcd *hcd;
 
-   if (udev->speed >= USB_SPEED_SUPER)
+   if (udev->speed >= USB_SPEED_SUPER && xhci->shared_hcd)
hcd = xhci->shared_hcd;
else
hcd = xhci->main_hcd;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6f03830..e812e3d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -253,12 +253,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
xhci->clk = clk;
xhci->main_hcd = hcd;
-   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
-   dev_name(>dev), hcd);
-   if (!xhci->shared_hcd) {
-   ret = -ENOMEM;
-   goto disable_clk;
-   }
 
if (device_property_read_bool(sysdev, "usb2-lpm-disable"))
xhci->quirks |= XHCI_HW_LPM_DISABLE;
@@ -290,12 +284,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto disable_usb_phy;
 
-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
-   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
-   if (ret)
-   goto dealloc_usb2_hcd;
+   if (xhci->num_usb3_ports > 0) {
+   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
+   dev_name(>dev), hcd);
+   if (!xhci->shared_hcd) {
+   ret = -ENOMEM;
+   goto disable_clk;
+   }
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
+   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+   if (ret)
+   goto dealloc_usb2_hcd;
+   }
 
device_enable_async_suspend(>dev);
pm_runtime_put_noidle(>dev);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 05104bd..4824bf6 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -417,12 +417,14 @@ static void compliance_mode_recovery(struct timer_list *t)
i + 1);
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
"Attempting compliance mode recovery");
-   hcd = xhci->shared_hcd;
+   if (xhci->shared_hcd) {
+   hcd = xhci->shared_hcd;
 
-   if (hcd->state == HC_STATE_SUSPENDED)
-   usb_hcd_resume_root_hub(hcd);
+   if (hcd->state == HC_STATE_SUSPENDED)
+   usb_hcd_resume_root_hub(hcd);
 
-   usb_hcd_poll_rh_status(hcd);
+   usb_hcd_poll_rh_status(hcd);
+   }
}
}
 
@@ -611,6 +613,18 @@ int xhci_run(struct usb_hcd *hcd)
if (ret)
xhci_free_command(xhci, command);
}
+   /*
+* Execute xhci_start() in case xhci->shared_hcd is not registered.
+* If the xhci->shared_hcd doesn't exist, no one triggers to start
+* the xhci which should be done before exitting run function
+*/
+   if (!xhci->shared_hcd) {
+   if (xhci_start(xhci)) {
+   xhci_halt(xhci);
+   return -ENODEV;
+   }
+   xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+   }
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB2 roothub");
 
@@ -861,8 +875,8 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
if (!hcd->state)
return 0;
 
-   if (hcd->state != HC_STATE_SUSPENDED ||
-   xhci->shared_hcd->state != HC_STATE_SUSPENDED)
+   if (hcd->state != HC_STATE_SUSPENDED || 

[PATCH v1 1/1] usb: xhci: do not create and register shared_hcd when USB3.0 is disabled

[Thang Q. Nguyen]

From: Tung Nguyen 

Currently, hcd->shared_hcd always creates and registers to the usb-core.
If, for some reasons, USB3 downstream port is disabled, no roothub port for
USB3.0 is found. This causes kernel to display an error:
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
This patch checks, creates and registers shared_hcd if USB3.0 downstream
port is available.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
 drivers/usb/host/xhci-mem.c  |  2 +-
 drivers/usb/host/xhci-plat.c | 26 +++--
 drivers/usb/host/xhci.c  | 54 
 3 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 554a8a5..157d1e7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1067,7 +1067,7 @@ static u32 xhci_find_real_port_number(struct xhci_hcd 
*xhci,
struct usb_device *top_dev;
struct usb_hcd *hcd;
 
-   if (udev->speed >= USB_SPEED_SUPER)
+   if (udev->speed >= USB_SPEED_SUPER && xhci->shared_hcd)
hcd = xhci->shared_hcd;
else
hcd = xhci->main_hcd;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6f03830..e812e3d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -253,12 +253,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
xhci->clk = clk;
xhci->main_hcd = hcd;
-   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
-   dev_name(>dev), hcd);
-   if (!xhci->shared_hcd) {
-   ret = -ENOMEM;
-   goto disable_clk;
-   }
 
if (device_property_read_bool(sysdev, "usb2-lpm-disable"))
xhci->quirks |= XHCI_HW_LPM_DISABLE;
@@ -290,12 +284,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto disable_usb_phy;
 
-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
-   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
-   if (ret)
-   goto dealloc_usb2_hcd;
+   if (xhci->num_usb3_ports > 0) {
+   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
+   dev_name(>dev), hcd);
+   if (!xhci->shared_hcd) {
+   ret = -ENOMEM;
+   goto disable_clk;
+   }
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
+   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+   if (ret)
+   goto dealloc_usb2_hcd;
+   }
 
device_enable_async_suspend(>dev);
pm_runtime_put_noidle(>dev);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 05104bd..4824bf6 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -417,12 +417,14 @@ static void compliance_mode_recovery(struct timer_list *t)
i + 1);
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
"Attempting compliance mode recovery");
-   hcd = xhci->shared_hcd;
+   if (xhci->shared_hcd) {
+   hcd = xhci->shared_hcd;
 
-   if (hcd->state == HC_STATE_SUSPENDED)
-   usb_hcd_resume_root_hub(hcd);
+   if (hcd->state == HC_STATE_SUSPENDED)
+   usb_hcd_resume_root_hub(hcd);
 
-   usb_hcd_poll_rh_status(hcd);
+   usb_hcd_poll_rh_status(hcd);
+   }
}
}
 
@@ -611,6 +613,18 @@ int xhci_run(struct usb_hcd *hcd)
if (ret)
xhci_free_command(xhci, command);
}
+   /*
+* Execute xhci_start() in case xhci->shared_hcd is not registered.
+* If the xhci->shared_hcd doesn't exist, no one triggers to start
+* the xhci which should be done before exitting run function
+*/
+   if (!xhci->shared_hcd) {
+   if (xhci_start(xhci)) {
+   xhci_halt(xhci);
+   return -ENODEV;
+   }
+   xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+   }
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB2 roothub");
 
@@ -861,8 +875,8 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
if (!hcd->state)
return 0;
 
-   if (hcd->state != HC_STATE_SUSPENDED ||
-   xhci->shared_hcd->state != HC_STATE_SUSPENDED)
+   if (hcd->state != HC_STATE_SUSPENDED || (xhci->shared_hcd &&
+