[PATCH 1/7] drivers: qcom: rpmh-rsc: fix the loop index check in get_req_from_tcs

2018-07-19 Thread Raju P L S S S N
From: "Raju P.L.S.S.S.N" 

get_req_from_tcs introduced in patch[1] returns tcs_request from
tcs_group. The size of tcs (of type - tcs_group) array in rsc_drv is
TCS_TYPE_NR. So the loop index needs to be iterated up to TCS_TYPE_NR only.

[1] https://patchwork.kernel.org/patch/10477547/

Signed-off-by: Raju P.L.S.S.S.N 
---
 drivers/soc/qcom/rpmh-rsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index fefda0f..33fe9f9 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -190,7 +190,7 @@ static const struct tcs_request *get_req_from_tcs(struct 
rsc_drv *drv,
struct tcs_group *tcs;
int i;
 
-   for (i = 0; i < drv->num_tcs; i++) {
+   for (i = 0; i < TCS_TYPE_NR; i++) {
tcs = &drv->tcs[i];
if (tcs->mask & BIT(tcs_id))
return tcs->req[tcs_id - tcs->offset];
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project



Re: [PATCH v2 1/2] mm: fix race on soft-offlining free huge pages

2018-07-19 Thread Michal Hocko
On Thu 19-07-18 06:19:45, Naoya Horiguchi wrote:
> On Wed, Jul 18, 2018 at 10:50:32AM +0200, Michal Hocko wrote:
> > On Wed 18-07-18 00:55:29, Naoya Horiguchi wrote:
> > > On Tue, Jul 17, 2018 at 04:27:43PM +0200, Michal Hocko wrote:
> > > > On Tue 17-07-18 14:32:31, Naoya Horiguchi wrote:
> > > > > There's a race condition between soft offline and hugetlb_fault which
> > > > > causes unexpected process killing and/or hugetlb allocation failure.
> > > > >
> > > > > The process killing is caused by the following flow:
> > > > >
> > > > >   CPU 0   CPU 1  CPU 2
> > > > >
> > > > >   soft offline
> > > > > get_any_page
> > > > > // find the hugetlb is free
> > > > >   mmap a hugetlb file
> > > > >   page fault
> > > > > ...
> > > > >   hugetlb_fault
> > > > > hugetlb_no_page
> > > > >   alloc_huge_page
> > > > >   // succeed
> > > > >   soft_offline_free_page
> > > > >   // set hwpoison flag
> > > > >  mmap the hugetlb file
> > > > >  page fault
> > > > >...
> > > > >  hugetlb_fault
> > > > >hugetlb_no_page
> > > > >  find_lock_page
> > > > >return 
> > > > > VM_FAULT_HWPOISON
> > > > >mm_fault_error
> > > > >  do_sigbus
> > > > >  // kill the process
> > > > >
> > > > >
> > > > > The hugetlb allocation failure comes from the following flow:
> > > > >
> > > > >   CPU 0  CPU 1
> > > > >
> > > > >  mmap a hugetlb file
> > > > >  // reserve all free page but don't 
> > > > > fault-in
> > > > >   soft offline
> > > > > get_any_page
> > > > > // find the hugetlb is free
> > > > >   soft_offline_free_page
> > > > >   // set hwpoison flag
> > > > > dissolve_free_huge_page
> > > > > // fail because all free hugepages are reserved
> > > > >  page fault
> > > > >...
> > > > >  hugetlb_fault
> > > > >hugetlb_no_page
> > > > >  alloc_huge_page
> > > > >...
> > > > >  
> > > > > dequeue_huge_page_node_exact
> > > > >  // ignore hwpoisoned 
> > > > > hugepage
> > > > >  // and finally fail due 
> > > > > to no-mem
> > > > >
> > > > > The root cause of this is that current soft-offline code is written
> > > > > based on an assumption that PageHWPoison flag should beset at first to
> > > > > avoid accessing the corrupted data.  This makes sense for 
> > > > > memory_failure()
> > > > > or hard offline, but does not for soft offline because soft offline is
> > > > > about corrected (not uncorrected) error and is safe from data lost.
> > > > > This patch changes soft offline semantics where it sets PageHWPoison 
> > > > > flag
> > > > > only after containment of the error page completes successfully.
> > > >
> > > > Could you please expand on the worklow here please? The code is really
> > > > hard to grasp. I must be missing something because the thing shouldn't
> > > > be really complicated. Either the page is in the free pool and you just
> > > > remove it from the allocator (with hugetlb asking for a new hugeltb page
> > > > to guaratee reserves) or it is used and you just migrate the content to
> > > > a new page (again with the hugetlb reserves consideration). Why should
> > > > PageHWPoison flag ordering make any relevance?
> > >
> > > (Considering soft offlining free hugepage,)
> > > PageHWPoison is set at first before this patch, which is racy with
> > > hugetlb fault code because it's not protected by hugetlb_lock.
> > >
> > > Originally this was written in the similar manner as hard-offline, where
> > > the race is accepted and a PageHWPoison flag is set as soon as possible.
> > > But actually that's found not necessary/correct because soft offline is
> > > supposed to be less aggressive and failure is OK.
> >
> > OK
> >
> > > So this patch is suggesting to make soft-offline less aggressive by
> > > moving SetPageHWPoison into the lock.
> >
> > I guess I still do not understand why we should even care about the
> > ordering of the HWPoison flag setting. Why cannot we simply have the
> > following c

[V9fs-developer] [PATCH v3] Fix a hard lockup case in the virtio transport

2018-07-19 Thread jiangyiwen
When client has multiple threads that issue io requests
all the time, and the server has a very good performance,
it may cause cpu is running in the irq context for a long
time because it can check virtqueue has buf in the *while*
loop.

So we should keep chan->lock in the whole loop.

Signed-off-by: Yiwen Jiang 
---
 net/9p/trans_virtio.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 05006cb..3589864 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -144,24 +144,25 @@ static void req_done(struct virtqueue *vq)
struct virtio_chan *chan = vq->vdev->priv;
unsigned int len;
struct p9_req_t *req;
+   bool need_wakeup = false;
unsigned long flags;

p9_debug(P9_DEBUG_TRANS, ": request done\n");

-   while (1) {
-   spin_lock_irqsave(&chan->lock, flags);
-   req = virtqueue_get_buf(chan->vq, &len);
-   if (req == NULL) {
-   spin_unlock_irqrestore(&chan->lock, flags);
-   break;
+   spin_lock_irqsave(&chan->lock, flags);
+   while ((req = virtqueue_get_buf(chan->vq, &len)) != NULL) {
+   if (!chan->ring_bufs_avail) {
+   chan->ring_bufs_avail = 1;
+   need_wakeup = true;
}
-   chan->ring_bufs_avail = 1;
-   spin_unlock_irqrestore(&chan->lock, flags);
-   /* Wakeup if anyone waiting for VirtIO ring space. */
-   wake_up(chan->vc_wq);
+
if (len)
p9_client_cb(chan->client, req, REQ_STATUS_RCVD);
}
+   spin_unlock_irqrestore(&chan->lock, flags);
+   /* Wakeup if anyone waiting for VirtIO ring space. */
+   if (need_wakeup)
+   wake_up(chan->vc_wq);
 }

 /**
-- 
1.8.3.1



Re: [PATCHv5 02/19] mm: Do not use zero page in encrypted pages

2018-07-19 Thread Kirill A. Shutemov
On Wed, Jul 18, 2018 at 10:36:24AM -0700, Dave Hansen wrote:
> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> > Zero page is not encrypted and putting it into encrypted VMA produces
> > garbage.
> > 
> > We can map zero page with KeyID-0 into an encrypted VMA, but this would
> > be violation security boundary between encryption domains.
> 
> Why?  How is it a violation?
> 
> It only matters if they write secrets.  They can't write secrets to the
> zero page.

I believe usage of zero page is wrong here. It would indirectly reveal
content of supposedly encrypted memory region.

I can see argument why it should be okay and I don't have very strong
opinion on this.

If folks see it's okay to use zero page in encrypted VMAs I can certainly
make it work.

> Is this only because you accidentally inherited ->vm_page_prot on the
> zero page PTE?

Yes, in previous patchset I mapped zero page with wrong KeyID. This is one
of possible fixes for this.

-- 
 Kirill A. Shutemov


Re: [PATCH] pinctrl: uniphier: add spi pin-mux settings

2018-07-19 Thread kbuild test robot
Hi Kunihiko,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on pinctrl/devel]
[also build test ERROR on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Keiji-Hayashibara/pinctrl-uniphier-add-spi-pin-mux-settings/20180719-144943
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.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
GCC_VERSION=8.1.0 make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   In file included from drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:21:
>> drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:629:27: error: 
>> 'spi0_groups' undeclared here (not in a function); did you mean 'spi_groups'?
 UNIPHIER_PINMUX_FUNCTION(spi0),
  ^~~~
   drivers/pinctrl/uniphier/pinctrl-uniphier.h:188:13: note: in definition of 
macro 'UNIPHIER_PINMUX_FUNCTION'
  .groups = func##_groups,\
^~~~
   In file included from include/linux/kernel.h:15,
from drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:16:
   include/linux/build_bug.h:29:45: error: bit-field '' width not an 
integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
   include/linux/compiler-gcc.h:65:28: note: in expansion of macro 
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
   ^
   include/linux/kernel.h:72:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^~~
   drivers/pinctrl/uniphier/pinctrl-uniphier.h:189:17: note: in expansion of 
macro 'ARRAY_SIZE'
  .num_groups = ARRAY_SIZE(func##_groups),  \
^~
   drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:629:2: note: in expansion 
of macro 'UNIPHIER_PINMUX_FUNCTION'
 UNIPHIER_PINMUX_FUNCTION(spi0),
 ^~~~

vim +629 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c

   618  
   619  static const struct uniphier_pinmux_function uniphier_sld8_functions[] 
= {
   620  UNIPHIER_PINMUX_FUNCTION(emmc),
   621  UNIPHIER_PINMUX_FUNCTION(ether_mii),
   622  UNIPHIER_PINMUX_FUNCTION(ether_rmii),
   623  UNIPHIER_PINMUX_FUNCTION(i2c0),
   624  UNIPHIER_PINMUX_FUNCTION(i2c1),
   625  UNIPHIER_PINMUX_FUNCTION(i2c2),
   626  UNIPHIER_PINMUX_FUNCTION(i2c3),
   627  UNIPHIER_PINMUX_FUNCTION(nand),
   628  UNIPHIER_PINMUX_FUNCTION(sd),
 > 629  UNIPHIER_PINMUX_FUNCTION(spi0),
   630  UNIPHIER_PINMUX_FUNCTION(system_bus),
   631  UNIPHIER_PINMUX_FUNCTION(uart0),
   632  UNIPHIER_PINMUX_FUNCTION(uart1),
   633  UNIPHIER_PINMUX_FUNCTION(uart2),
   634  UNIPHIER_PINMUX_FUNCTION(uart3),
   635  UNIPHIER_PINMUX_FUNCTION(usb0),
   636  UNIPHIER_PINMUX_FUNCTION(usb1),
   637  UNIPHIER_PINMUX_FUNCTION(usb2),
   638  };
   639  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCHv5 03/19] mm/ksm: Do not merge pages with different KeyIDs

2018-07-19 Thread Kirill A. Shutemov
On Wed, Jul 18, 2018 at 10:38:27AM -0700, Dave Hansen wrote:
> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> > Pages encrypted with different encryption keys are not allowed to be
> > merged by KSM. Otherwise it would cross security boundary.
> 
> Let's say I'm using plain AES (not AES-XTS).  I use the same key in two
> keyid slots.  I map a page with the first keyid and another with the
> other keyid.
> 
> Won't they have the same cipertext?  Why shouldn't we KSM them?

We compare plain text, not ciphertext. And for good reason.

Comparing ciphertext would only make KSM successful for AES-ECB that
doesn't dependent on physical address of the page.

MKTME only supports AES-XTS (no plans to support AES-ECB). It effectively
disables KSM if we go with comparing ciphertext.

-- 
 Kirill A. Shutemov


[tip:x86/mm 3/8] mm/memory.c:339:2: error: implicit declaration of function 'tlb_flush_remove_tables_local'; did you mean 'tlb_remove_table'?

2018-07-19 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
head:   e9d8c61557687b7126101e9550bdf243223f0d8f
commit: 2ff6ddf19c0ec40633bd14d8fe28a289816bd98d [3/8] x86/mm/tlb: Leave lazy 
TLB mode at page table free time
config: arm-axm55xx_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
git checkout 2ff6ddf19c0ec40633bd14d8fe28a289816bd98d
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   mm/memory.c: In function 'tlb_remove_table_smp_sync':
>> mm/memory.c:339:2: error: implicit declaration of function 
>> 'tlb_flush_remove_tables_local'; did you mean 'tlb_remove_table'? 
>> [-Werror=implicit-function-declaration]
 tlb_flush_remove_tables_local(mm);
 ^
 tlb_remove_table
   mm/memory.c: In function 'tlb_table_flush':
>> mm/memory.c:372:2: error: implicit declaration of function 
>> 'tlb_flush_remove_tables'; did you mean 'tlb_remove_table'? 
>> [-Werror=implicit-function-declaration]
 tlb_flush_remove_tables(tlb->mm);
 ^~~
 tlb_remove_table
   cc1: some warnings being treated as errors

vim +339 mm/memory.c

   328  
   329  static void tlb_remove_table_smp_sync(void *arg)
   330  {
   331  struct mm_struct __maybe_unused *mm = arg;
   332  /*
   333   * On most architectures this does nothing. Simply delivering 
the
   334   * interrupt is enough to prevent races with software page table
   335   * walking like that done in get_user_pages_fast.
   336   *
   337   * See the comment near struct mmu_table_batch.
   338   */
 > 339  tlb_flush_remove_tables_local(mm);
   340  }
   341  
   342  static void tlb_remove_table_one(void *table, struct mmu_gather *tlb)
   343  {
   344  /*
   345   * This isn't an RCU grace period and hence the page-tables 
cannot be
   346   * assumed to be actually RCU-freed.
   347   *
   348   * It is however sufficient for software page-table walkers 
that rely on
   349   * IRQ disabling. See the comment near struct mmu_table_batch.
   350   */
   351  smp_call_function(tlb_remove_table_smp_sync, tlb->mm, 1);
   352  __tlb_remove_table(table);
   353  }
   354  
   355  static void tlb_remove_table_rcu(struct rcu_head *head)
   356  {
   357  struct mmu_table_batch *batch;
   358  int i;
   359  
   360  batch = container_of(head, struct mmu_table_batch, rcu);
   361  
   362  for (i = 0; i < batch->nr; i++)
   363  __tlb_remove_table(batch->tables[i]);
   364  
   365  free_page((unsigned long)batch);
   366  }
   367  
   368  void tlb_table_flush(struct mmu_gather *tlb)
   369  {
   370  struct mmu_table_batch **batch = &tlb->batch;
   371  
 > 372  tlb_flush_remove_tables(tlb->mm);
   373  
   374  if (*batch) {
   375  call_rcu_sched(&(*batch)->rcu, tlb_remove_table_rcu);
   376  *batch = NULL;
   377  }
   378  }
   379  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH 3/3] mm/page_alloc: Split context in free_area_init_node

2018-07-19 Thread Oscar Salvador
On Wed, Jul 18, 2018 at 10:34:19AM -0400, Pavel Tatashin wrote:
> On Wed, Jul 18, 2018 at 8:47 AM  wrote:
> >
> > From: Oscar Salvador 
> >
> > If free_area_init_node gets called from memhotplug code,
> > we do not need to call calculate_node_totalpages(),
> > as the node has no pages.
> 
> I am not positive this is safe. Some pgdat fields in
> calculate_node_totalpages() are set. Even if those fields are always
> set to zeros, pgdat may be reused (i.e. node went offline and later
> came back online), so we might still need to set those fields to
> zeroes.
> 

You are right, I do not know why, but I thought that we were zeroing pgdat 
struct
before getting in the function.

I will leave that part out.
Since we only should care about deferred pfns during the boot, maybe we can 
change 
it to something like:

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 70fe4c80643f..89fc8f4240ca 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6381,6 +6381,21 @@ static void __ref alloc_node_mem_map(struct pglist_data 
*pgdat)
 static void __ref alloc_node_mem_map(struct pglist_data *pgdat) { }
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 
+#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
+static void pgdat_set_deferred_range(pg_data_t *pgdat)
+{
+   /*
+* We start only with one section of pages, more pages are added as
+* needed until the rest of deferred pages are initialized.
+*/
+   pgdat->static_init_pgcnt = min_t(unsigned long, PAGES_PER_SECTION,
+   pgdat->node_spanned_pages);
+   pgdat->first_deferred_pfn = ULONG_MAX;
+}
+#else
+static void pgdat_set_deferred_range(pg_data_t *pgdat) {}
+#endif
+
 void __paginginit free_area_init_node(int nid, unsigned long *zones_size,
unsigned long node_start_pfn, unsigned long *zholes_size)
 {
@@ -6402,20 +6417,14 @@ void __paginginit free_area_init_node(int nid, unsigned 
long *zones_size,
 #else
start_pfn = node_start_pfn;
 #endif
-   calculate_node_totalpages(pgdat, start_pfn, end_pfn,
- zones_size, zholes_size);
 
+   calculate_node_totalpages(pgdat, start_pfn, end_pfn,
+   zones_size, zholes_size);
alloc_node_mem_map(pgdat);
 
-#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
-   /*
-* We start only with one section of pages, more pages are added as
-* needed until the rest of deferred pages are initialized.
-*/
-   pgdat->static_init_pgcnt = min_t(unsigned long, PAGES_PER_SECTION,
-pgdat->node_spanned_pages);
-   pgdat->first_deferred_pfn = ULONG_MAX;
-#endif
+   if (system_state == SYSTEM_BOOTING)
+   pgdat_set_deferred_range(pgdat);
+
free_area_init_core(pgdat);
 }

Thanks
-- 
Oscar Salvador
SUSE L3


Re: [PATCH 1/6] drivers/md/raid5: Use irqsave variant of atomic_dec_and_lock()

2018-07-19 Thread Sebastian Andrzej Siewior
On 2018-07-18 19:44:05 [-0700], Shaohua Li wrote:
> Since you sent a series, I suppose you want someone else to take it. But I can
> take it for sure, will do soon.

I'm sorry for the miss understanding. I tried to explain this in the
cover letter. The prerequisites are already merged so then the actual
changes can be merged via the individual maintainer.
Thank you Shaohua.

> Thanks,
> Shaohua

Sebastian


Re: [RFC] Make need_resched() return true when rcu_urgent_qs requested

2018-07-19 Thread David Woodhouse
On Thu, 2018-07-19 at 08:45 +0200, Christian Borntraeger wrote:
> 
> > My thought would be something like this:
> > 
> >   if (context_tracking_cpu_is_enabled())
> >   rcu_kvm_enter();
> >   else
> >   rcu_virt_note_context_switch(smp_processor_id());
> 
> In the past we needed that (when we introduced that). At least with every
> host interrupt we called this making an rcu event at least every HZ.
> Will the changes in need_resched make this part unnecessary?

Yes, the change in need_resched() should make this part unnecessary.
Unless your architecture's version of the vcpu_run() loop just loops
forever even when TIF_NEED_RESCHED is set? :)

I'm not sure about the context tracking condition in the code snippet
cited above, though. I think that's what caused my problem in the first
place — I have CONTEXT_TRACKING_FORCE && !NO_HZ_FULL. So in 4.15, that
means rcu_user_enter() did nothing and rcu_virt_note_context_switch()
wasn't called. Hence the observed stalls.

Should rcu_user_enter() itself be conditional on CONTEXT_TRACKING not
NO_HZ_FULL? 

smime.p7s
Description: S/MIME cryptographic signature


Re: [RFC] Make need_resched() return true when rcu_urgent_qs requested

2018-07-19 Thread David Woodhouse


On Wed, 2018-07-18 at 20:11 -0700, Paul E. McKenney wrote:
> 
> > That is interesting. As I replied to Paul, we are already calling
> > rcu_user_enter/exit() on guest_enter/exit_irqsoff(). So I'm wondering why
> > you're seeing such an optimization by repeating those calls.
> > 
> > Perhaps the rcu_user_* somehow aren't actually called from
> > __context_tracking_enter()...? Some bug in context tracking?
> > Otherwise it's a curious side effect.
> 
> David is working with v4.15.  Is this maybe something that has changed
> since then?

To clarify: in 4.15 without CONFIG_PREEMPT and without NO_HZ_FULL I was
seeing RCU stalls because a thread in vcpu_run() was *never* seen to go
through a quiescent state. Hence the change to need_resched() in the
first patch in this thread, which fixed the problem at hand and seemed
to address the general case.

It then seemed by *inspection* that the NO_HZ_FULL case was probably
broken, because we'd failed to spot the rcu_user_* calls. But
rcu_user_enter() does nothing in the !NO_HZ_FULL case, so wouldn't have
helped in the testing that we were doing anyway.



smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH V2 1/2] mux: adgs1408: new driver for Analog Devices ADGS1408/1409 mux …

2018-07-19 Thread Caprioru, Mircea
On Wed, 2018-07-18 at 14:49 +0200, Peter Rosin wrote:
> On 2018-07-17 15:42, Mircea Caprioru wrote:
> > This patch adds basic support for Analog Device ADGS1408/09 SPI mux
> > controller.
> > 
> > The device is probed and set to a disabled state. It uses the new
> > mux
> > controller framework.
> > 
> > Signed-off-by: Mircea Caprioru 
> > ---
> > Changelog V1 -> V2
> > - removed adgs140x wildcard
> > - removed cells verification since only 0 configuration supported
> 
> Ahhh, the two muxes in 1409 cannot be operated independently, as this
> is a
> "differential" mux. That simplifies things quite a bit, and good
> thing you
> caught this early!

Yeah, I understood the mux framework a bit better the second time I
looked at it (after your first review).
> 
> > - added id enum for ADGS1408 and ADGS1409
> > - sorted includes
> > 
> >  MAINTAINERS|   5 ++
> >  drivers/mux/Kconfig|  12 +
> >  drivers/mux/Makefile   |   2 +
> >  drivers/mux/adgs1408.c | 120
> > +
> >  4 files changed, 139 insertions(+)
> >  create mode 100644 drivers/mux/adgs1408.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 192d7f73fd01..458d42d6f4f3 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -810,6 +810,11 @@ L: linux-me...@vger.kernel.org
> >  S: Maintained
> >  F: drivers/media/i2c/ad9389b*
> >  
> > +ANALOG DEVICES INC ADGS1408 DRIVER
> > +M: Mircea Caprioru 
> > +S: Supported
> > +F: drivers/mux/adgs1408.c
> > +
> >  ANALOG DEVICES INC ADV7180 DRIVER
> >  M: Lars-Peter Clausen 
> >  L: linux-me...@vger.kernel.org
> > diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> > index 6241678e99af..cf825e9f47ef 100644
> > --- a/drivers/mux/Kconfig
> > +++ b/drivers/mux/Kconfig
> > @@ -21,6 +21,18 @@ config MUX_ADG792A
> >   To compile the driver as a module, choose M here: the
> > module will
> >   be called mux-adg792a.
> >  
> > +config MUX_ADGS1408
> > +   tristate "Analog Devices ADGS1408/ADGS1409 Multiplexers"
> > +   depends on SPI
> > +   help
> > + ADGS1408 8:1 multiplexer and ADGS1409 double 4:1
> > multiplexer
> > + switches.
> > +
> > + The driver supports driving each switch independently.
> 
> Remove this line. It is confusing since 1408 only have one mux and
> the two muxes in the dual 1409 cannot be operated independently.

Ack.
> 
> > +
> > + To compile the driver as a module, choose M here: the
> > module will
> > + be called mux-adgs1408.
> > +
> >  config MUX_GPIO
> > tristate "GPIO-controlled Multiplexer"
> > depends on GPIOLIB || COMPILE_TEST
> > diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
> > index c3d883955fd5..6e9fa47daf56 100644
> > --- a/drivers/mux/Makefile
> > +++ b/drivers/mux/Makefile
> > @@ -5,10 +5,12 @@
> >  
> >  mux-core-objs  := core.o
> >  mux-adg792a-objs   := adg792a.o
> > +mux-adgs1408-objs  := adgs1408.o
> >  mux-gpio-objs  := gpio.o
> >  mux-mmio-objs  := mmio.o
> >  
> >  obj-$(CONFIG_MULTIPLEXER)  += mux-core.o
> >  obj-$(CONFIG_MUX_ADG792A)  += mux-adg792a.o
> > +obj-$(CONFIG_MUX_ADGS1408) += mux-adgs1408.o
> >  obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
> >  obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
> > diff --git a/drivers/mux/adgs1408.c b/drivers/mux/adgs1408.c
> > new file mode 100644
> > index ..a5192c5e484b
> > --- /dev/null
> > +++ b/drivers/mux/adgs1408.c
> > @@ -0,0 +1,120 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> 
> The preferred spelling is GPL-2.0-or-later

Hmmm... 
This seems to be new. There are quite a few places where GPL-2.0+ is
used.
Will use GPL-2.0-or-later here.
> 
> > +/*
> > + * ADG1408 SPI MUX driver
> 
> ADGS1408; you are missing the S.
> 
> And I think you could/should mention ADGS1409 here.

Ack.
> 
> > + *
> > + * Copyright 2018 Analog Devices Inc.
> > + */
> > +
> > +#include 
> > +#include 
> 
> This #include sorts after linux/property.h.
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define ADGS1408_SW_DATA   (0x01)
> > +#define ADGS1408_REG_READ(reg) ((reg) | 0x80)
> > +#define ADGS1408_DISABLE   (0x00)
> > +#define ADGS1408_MUX(state)(((state) << 1) | 1)
> > +
> > +enum {
> > +   ADGS1408,
> > +   ADGS1409
> 
> Add a trailing comma here, to make future changes less intrusive.

Ack.
> 
> > +};
> > +
> > +static int adgs1408_spi_reg_write(struct spi_device *spi,
> > + u8 reg_addr, u8 reg_data)
> > +{
> > +   u8 tx_buf[2];
> > +
> > +   tx_buf[0] = reg_addr;
> > +   tx_buf[1] = reg_data;
> > +
> > +   return spi_write_then_read(spi, tx_buf, sizeof(tx_buf),
> > NULL, 0);
> > +}
> > +
> > +static int adgs1408_set(struct mux_control *mux, int state)
> > +{
> > +   struct spi_device *spi = to_spi_device(mux->chip-
> > >dev.parent);
> > +   u8 reg;
> > +
> > +   if (state == MUX_IDLE_DISCONNECT)
> > +   reg = ADGS1408_DISABLE;
> > +   else
> > +   re

potential deadlock in cpufreq-dt

2018-07-19 Thread Jiada Wang

Hello all

After enable lockdep, by poking /sys/kernel/debug/sched_features,
I triggered the following lockdep report:

[   34.410559] ==
[   34.416766] WARNING: possible circular locking dependency detected
[   34.422987] 4.14.50-03493-g65adcd3b74c9-dirty #203 Tainted: G 
C

[   34.450785] --
[   34.457001] systemd-udevd/1490 is trying to acquire lock:
[   34.462432]  (
[   34.464102] opp_table_lock
[   34.466814] ){+.+.}
[   34.468932] , at: [] 
dev_pm_opp_get_opp_table+0x2c/0x140

[   34.475819]
   but task is already holding lock:
[   34.481689]  (
[   34.483359] subsys mutex
[   34.485914] #6
[   34.487587] ){+.+.}
[   34.489701] , at: [] 
subsys_interface_register+0x68/0x118

[   34.496677]
   which lock already depends on the new lock.

[   34.504890]
   the existing dependency chain (in reverse order) is:
[   34.512406]
   -> #3
[   34.515836]  (
[   34.517505] subsys mutex
[   34.520045] #6
[   34.521715] ){+.+.}linux-kernel@vger.kernel.org
[   34.523819] :
[   34.525412]__mutex_lock+0x94/0x840
[   34.529543]mutex_lock_nested+0x1c/0x24
[   34.534022]subsys_interface_register+0x68/0x118
[   34.539284]cpufreq_register_driver+0x10c/0x1d8
[   34.544464]dt_cpufreq_probe+0xcc/0x108 [cpufreq_dt]
[   34.550074]platform_drv_probe+0x58/0xa8
[   34.554637]driver_probe_device+0x200/0x2b4
[   34.559463]__driver_attach+0x7c/0xac
[   34.563768]bus_for_each_dev+0xa0/0xb8
[   34.568169]driver_attach+0x20/0x28
[   34.568173]bus_add_driver+0x19c/0x1d8
[   34.568177]driver_register+0x98/0xd0
[   34.568187]__platform_driver_register+0x48/0x50
[   34.568198]dt_cpufreq_platdrv_init+0x18/0x1000 [cpufreq_dt]
[   34.568205]do_one_initcall+0x120/0x13c
[   34.568212]do_init_module+0x5c/0x1c8
[   34.568215]load_module+0x20f0/0x2150
[   34.568218]SyS_finit_module+0xd4/0xe8
[   34.568220]el0_svc_naked+0x34/0x38
[   34.568224]
   -> #2
[   34.568225]  (
[   34.568228] cpu_hotplug_lock.rw_sem
[   34.568229] ){}
[   34.568230] :
[   34.568236]cpus_read_lock+0x54/0xcc
[   34.568241]static_key_enable+0x14/0x2c
[   34.568247]sched_feat_write+0xd0/0x1c4
[   34.568252]full_proxy_write+0x6c/0xac
[   34.568257]__vfs_write+0x34/0x138
[   34.568260]vfs_write+0xc0/0x17c
[   34.568262]SyS_write+0x60/0xb8
[   34.568265]el0_svc_naked+0x34/0x38
[   34.568266]
   -> #1
[   34.568267]  (
[   34.568269] &sb->s_type->i_mutex_key
[   34.568271] #3
[   34.568272] ){+.+.}
[   34.568273] :
[   34.568279]down_write+0x48/0x84
[   34.568282]start_creating+0x7c/0xd0
[   34.568284]debugfs_create_dir+0x14/0xbc
[   34.568289]opp_debug_register+0x68/0xa8
[   34.568293]_add_opp_dev+0x78/0xb4
[   34.568296]dev_pm_opp_get_opp_table+0x7c/0x140
[   34.568300]dev_pm_opp_of_add_table+0x1e0/0x4a4
[   34.568306]InitDVFS+0x7c/0x37c
[   34.568314]PVRSRVDeviceCreate+0x324/0x610
[   34.568317]pvr_drm_load+0x64/0x128
[   34.568322]pvr_probe+0x70/0xa0
[   34.568325]platform_drv_probe+0x58/0xa8
[   34.568328]driver_probe_device+0x200/0x2b4
[   34.568331]__driver_attach+0x7c/0xac
[   34.568334]bus_for_each_dev+0xa0/0xb8
[   34.568337]driver_attach+0x20/0x28
[   34.568340]bus_add_driver+0x19c/0x1d8
[   34.568343]driver_register+0x98/0xd0
[   34.568346]__platform_driver_register+0x48/0x50
[   34.568352]pvr_init+0x50/0x58
[   34.568355]do_one_initcall+0x120/0x13c
[   34.568360]kernel_init_freeable+0x26c/0x270
[   34.568366]kernel_init+0x10/0xfc
[   34.568369]ret_from_fork+0x10/0x18
[   34.568370]
   -> #0
[   34.568372]  (
[   34.568373] opp_table_lock
[   34.568375] ){+.+.}
[   34.568376] :
[   34.568381]lock_acquire+0x224/0x250
[   34.568384]__mutex_lock+0x94/0x840
[   34.568387]mutex_lock_nested+0x1c/0x24
[   34.568391]dev_pm_opp_get_opp_table+0x2c/0x140
[   34.568394]dev_pm_opp_set_regulators+0x30/0x190
[   34.568400]cpufreq_init+0xe4/0x304 [cpufreq_dt]
[   34.568405]cpufreq_online+0x174/0x5d8
[   34.568408]cpufreq_add_dev+0x60/0x78linux-ker...@vger.kernel.org
[   34.568411]subsys_interface_register+0x100/0x118
[   34.568414]cpufreq_register_driver+0x10c/0x1d8
[   34.568419]dt_cpufreq_probe+0xcc/0x108 [cpufreq_dt]
[   34.568422]platform_drv_probe+0x58/0xa8
[   34.568425]driver_probe_device+0x200/0x2b4
[   34.568428]__driver_attach+0x7c/0xac
[   34.568431]bus_for_each_dev+0xa0/0xb8
[   34.568433]driver_attach+0x20/0x28
[   34.568436]bus_add_driver+0x19c/

Re: [PATCH] net/9p/trans_virtio.c: replace mutex_lock with spin_lock to protect 'virtio_chan_list'

2018-07-19 Thread piaojun



On 2018/7/19 11:36, Dominique Martinet wrote:
> piaojun wrote on Thu, Jul 19, 2018:
>>> piaojun wrote on Wed, Jul 18, 2018:
>>> That's not a fast path operation, I don't mind changing things but I'd
>>> like to understand why - these functions are only ever called at unmount
>>> time or when something happens on the virtio bus (probe will happen on
>>> probing on the pci bus and I'm not too sure on remove but probably pci
>>> removal i.e. basically never?)
>>>
>>> I don't see why this wouldn't work, but I won't take this without a
>>> (good?) reason.
>>>
>> virtio_9p_lock is responsable for protecting virtio_chan_list which has 3
>> operation:
>>
>> 1. Add a virtio chan to virtio_chan_list. This will happen when we insmod
>> 9pnet_virtio.ko:
>> p9_virtio_probe
>> --list_add_tail(&chan->chan_list, &virtio_chan_list);
>>
>> 2. Remove a virtio chan. This will happen when remnod 9pnet_virtio.ko:
>> p9_virtio_remove
>> --list_del(&chan->chan_list);
>>
>> 3. Find a unused virtio chan when mount 9p:
>> mount
>> --p9_virtio_create
>> --list_for_each_entry(chan, &virtio_chan_list, chan_list)
>>
>> Multi mount process will compete for virtio_9p_lock when finding unused
>> virtio chan, in which case mutex lock will cause process sleep and wake
>> up. I think this a waste of CPU time. So we could use spin lock to avoid
>> this.
> 
> Well, sure, that's theory; but how is that in practice?
> I actually took the time to run some tests, setting up 20 virtio mount
> points in qemu, and running this command with and without your patch:
> # time sh -c 'for i in {1..20}; do
>   sh -c "for j in {1..100}; do
> mount -t 9p d$i d.$i;
> umount d.$i;
>   done" &
>   done;
>   wait'
> 
> This is quick & dirty but basically, mounts and unmounts 100 times in a
> loop all 20 mount points in parallel to stress that lock.
> I get these times 5 times (one run per column),
> without patch:
> real  0m19.357s   0m19.626s   0m19.904s   0m19.926s   
> 0m21.321s
> user  0m6.795s0m6.874s0m6.807s0m6.768s0m6.892s
> sys   0m29.936s   0m31.196s   0m31.702s   0m31.914s   
> 0m30.791s
> 
> With patch:
> real  0m19.439s   0m19.849s   0m19.683s   0m19.600s   
> 0m20.689s
> user  0m6.948s0m6.582s0m6.706s0m6.598s0m6.876s
> sys   0m29.364s   0m30.898s   0m30.695s   0m31.311s   
> 0m33.391s
> 
> I honestly can't say I'm convinced with a difference either way, the
> variations look more like noise than anything to me.
> 
> 
> More to the point, while these tests ran my dmesg buffer was filled with
> errors like:
> FS-Cache: Duplicate cookie detected
> FS-Cache: O-cookie c=00368cdb [p=548b03c2 fl=222 nc=0 na=1]
> FS-Cache: O-cookie d=4cebd15f n=029a0b83
> FS-Cache: O-key=[10] '34323935303838343536'
> FS-Cache: N-cookie c=d4089478 [p=548b03c2 fl=2 nc=0 na=1]
> FS-Cache: N-cookie d=4cebd15f n=959d4d37
> FS-Cache: N-key=[10] '34323935303838343536'
> 
> or
> (output mangled a bit)
> 
> ==
> BUG: KASAN: use-after-free in p9_client_cb+0x14d/0x160 [9pnet]
> Read of size 8 at addr 88003522a088 by task systemd-udevd/492
> 
> CPU: 1 PID: 492 Comm: systemd-udevd Tainted: G   O  4.18.0-rc5+ #9
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 0>
> Call Trace:
>  
>  dump_stack+0x7b/0xad
>  print_address_description+0x6a/0x209
>  ? p9_client_cb+0x14d/0x160 [9pnet]
>  kasan_report.cold.7+0x242/0x2fe
>  __asan_report_load8_noabort+0x19/0x20
>  p9_client_cb+0x14d/0x160 [9pnet]
>  req_done+0x22f/0x280 [9pnet_virtio]
>  ? p9_mount_tag_show+0x120/0x120 [9pnet_virtio]
>  vring_interrupt+0x108/0x1b0 [virtio_ring]
>  ? vring_map_single.constprop.23+0x350/0x350 [virtio_ring]
>  __handle_irq_event_percpu+0xec/0x460
>  handle_irq_event_percpu+0x71/0x140
>  ? __handle_irq_event_percpu+0x460/0x460
>  ? apic_ack_irq+0xa3/0xe0
>  handle_irq_event+0xb9/0x14a
>  handle_edge_irq+0x1ea/0x7a0
>  ? kasan_check_read+0x11/0x20
>  handle_irq+0x48/0x60
>  do_IRQ+0x67/0x140
>  common_interrupt+0xf/0xf
>  
> RIP: 0010:finish_task_switch+0x10e/0x630
> Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 6d 04 00 00 41 c7 45 38 00 00 00 
> 00 4c 89 e7 ff 14 25 28 f5 66 8e fb 66 0f >
> RSP: 0018:8800633e7a60 EFLAGS: 0246 ORIG_RAX: ffd4
> RAX: 0001 RBX: 880036632000 RCX: 
> RDX:  RSI:  RDI: 88006caaac00
> RBP: 8800633e7aa0 R08: ed000cea15cd R09: ed000cea15cc
> R10: ed000cea15cc R11: 88006750ae63 R12: 88006caaac00
> R13: 88006558b000 R14:  R15: 880036632000
>  ? __switch_to_asm+0x34/0x70
>  ? __switch_to_asm+0x40/0x70
>  __schedule+0x733/0x1c10
>  ? __bpf_prog_run64+0xd0/0xd0
>  ? firmware_map_remove+0x174/0x174

Re: [V9fs-developer] [PATCH v3] Fix a hard lockup case in the virtio transport

2018-07-19 Thread piaojun
LGTM

On 2018/7/19 15:17, jiangyiwen wrote:
> When client has multiple threads that issue io requests
> all the time, and the server has a very good performance,
> it may cause cpu is running in the irq context for a long
> time because it can check virtqueue has buf in the *while*
> loop.
> 
> So we should keep chan->lock in the whole loop.
> 
> Signed-off-by: Yiwen Jiang 
Reviewed-by: Jun Piao 
> ---
>  net/9p/trans_virtio.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 05006cb..3589864 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -144,24 +144,25 @@ static void req_done(struct virtqueue *vq)
>   struct virtio_chan *chan = vq->vdev->priv;
>   unsigned int len;
>   struct p9_req_t *req;
> + bool need_wakeup = false;
>   unsigned long flags;
> 
>   p9_debug(P9_DEBUG_TRANS, ": request done\n");
> 
> - while (1) {
> - spin_lock_irqsave(&chan->lock, flags);
> - req = virtqueue_get_buf(chan->vq, &len);
> - if (req == NULL) {
> - spin_unlock_irqrestore(&chan->lock, flags);
> - break;
> + spin_lock_irqsave(&chan->lock, flags);
> + while ((req = virtqueue_get_buf(chan->vq, &len)) != NULL) {
> + if (!chan->ring_bufs_avail) {
> + chan->ring_bufs_avail = 1;
> + need_wakeup = true;
>   }
> - chan->ring_bufs_avail = 1;
> - spin_unlock_irqrestore(&chan->lock, flags);
> - /* Wakeup if anyone waiting for VirtIO ring space. */
> - wake_up(chan->vc_wq);
> +
>   if (len)
>   p9_client_cb(chan->client, req, REQ_STATUS_RCVD);
>   }
> + spin_unlock_irqrestore(&chan->lock, flags);
> + /* Wakeup if anyone waiting for VirtIO ring space. */
> + if (need_wakeup)
> + wake_up(chan->vc_wq);
>  }
> 
>  /**
> 


Re: [PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm()

2018-07-19 Thread Lukas Wunner
On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote:
> When DP MST hubs get confused, they can occasionally stop responding for
> a good bit of time up until the point where the DRM driver manages to
> do the right DPCD accesses to get it to start responding again. In a
> worst case scenario however, this process can take upwards of 10+
> seconds.
> 
> Currently we use the default output_poll_changed handler
> drm_fb_helper_output_poll_changed() to handle output polling, which
> doesn't happen to grab any power references on the device when polling.
> If we're unlucky enough to have a hub (such as Lenovo's infamous laptop
> docks for the P5x/P7x series) that's easily startled and confused, this
> can lead to a pretty nasty deadlock situation that looks like this:
> 
> - Hotplug event from hub happens, we enter
>   drm_fb_helper_output_poll_changed() and start communicating with the
>   hub
> - While we're in drm_fb_helper_output_poll_changed() and attempting to
>   communicate with the hub, we end up confusing it and cause it to stop
>   responding for at least 10 seconds
> - After 5 seconds of being in drm_fb_helper_output_poll_changed(), the
>   pm core attempts to put the GPU into autosuspend, which ends up
>   calling drm_kms_helper_poll_disable()
> - While the runtime PM core is waiting in drm_kms_helper_poll_disable()
>   for the output poll to finish, we end up finally detecting an MST
>   display
> - We notice the new display and tries to enable it, which triggers
>   an atomic commit which triggers a call to pm_runtime_get_sync()
> - the output poll thread deadlocks the pm core waiting for the pm core
>   to finish the autosuspend request while the pm core waits for the
>   output poll thread to finish

This will still deadlock if ->runtime_suspend commences before the
hotplug event and the hotplug event occurs before polling has been
disabled by ->runtime_suspend.

The correct fix is to call pm_runtime_get_sync() *conditionally* in
the atomic commit which enables the display, using the same conditional
as d61a5c106351, i.e. if (!drm_kms_helper_is_poll_worker()).

Now I realize I sent you down the wrong path when I suggested to
introduce a DRM helper here.  My apologies, I didn't fully appreciate
what is going awry here!

Anything that happens in nouveau's poll worker never needs to acquire
a runtime PM ref because polling is only enabled while runtime active,
and ->runtime_suspend waits for an ongoing poll to finish.

Thinking a bit more about this, our mistake is to acquire runtime PM
refs too far down in the call stack.  As a fix that can be backported
to stable, adding if (!drm_kms_helper_is_poll_worker()) conditionals
seems fine to me, but the long term fix is to push acquisition of refs
further up in the call stack.

E.g., if the user forces connector probing via sysfs, a runtime PM ref
should be acquired in status_store() in drm_sysfs.c before invoking
connector->funcs->fill_modes().  That way, if the user forces connector
probing while the GPU is powering down, rpm_resume() will correctly wait
for rpm_suspend() to finish before resuming the card.  So if we architect
it like this, we're actually using the functionality provided by the
PM core in the way that it's supposed to be used.

The problem is that adding pm_runtime_get_sync() to status_store()
conflicts with the desire to have a library of generic DRM functions:
Some GPUs may be able to probe connectors without resuming to runtime
active state, others don't use runtime PM at all.  One solution that
comes to mind is a driver_features flag which tells the DRM core whether
to acquire a runtime PM ref in various places.

In your original patches 4 and 5, what exactly was the call stack which
led to i2c being accessed while runtime suspended?  Was it sysfs access
via /sys/class/i2c-adapter/* ?  If so, acquisition of the runtime PM ref
needs to likewise happen in that sysfs entry point, rather than deep down
in the call stack upon accessing the i2c bus.

Thanks,

Lukas

> 
> Sample:
> [  246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds.
> [  246.673398]   Not tainted 4.18.0-rc5Lyude-Test+ #2
> [  246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  246.676527] kworker/4:0 D037  2 0x8000
> [  246.677580] Workqueue: events output_poll_execute [drm_kms_helper]
> [  246.678704] Call Trace:
> [  246.679753]  __schedule+0x322/0xaf0
> [  246.680916]  schedule+0x33/0x90
> [  246.681924]  schedule_preempt_disabled+0x15/0x20
> [  246.683023]  __mutex_lock+0x569/0x9a0
> [  246.684035]  ? kobject_uevent_env+0x117/0x7b0
> [  246.685132]  ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 
> [drm_kms_helper]
> [  246.686179]  mutex_lock_nested+0x1b/0x20
> [  246.687278]  ? mutex_lock_nested+0x1b/0x20
> [  246.688307]  drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
> [  246.689420]  drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper]
> [  

Re: UBSAN: Undefined behaviour in ./include/net/xfrm.h

2018-07-19 Thread Steffen Klassert
On Fri, Jun 22, 2018 at 11:46:44PM +0800, air icy wrote:
> Hi,
> 
> static inline bool addr4_match(__be32 a1, __be32 a2, u8 prefixlen)
> {
> /* C99 6.5.7 (3): u32 << 32 is undefined behaviour */
> if (sizeof(long) == 4 && prefixlen == 0)
> return true;
> return !((a1 ^ a2) & htonl(~0UL << (32 - prefixlen)));
> }
> 
> 
> $ cat report0
> 
> UBSAN: Undefined behaviour in ./include/net/xfrm.h:894:23
> shift exponent -128 is negative

Looks like we don't validate the prefixlen of the address family
in the xfrm_selector.

> This bug can be repro, if you need the repro file, please tell me.

Can you send me your reproducer?


Private Investment Debt/Loan Funding.

2018-07-19 Thread Erik
Dear Sir,

I appreciate your contact. I represent an Investment Consortium in Hong Kong 
who will be interested in funding your Company's Project on a Debt Funding 
Basis/ Loan Application and The Investment Group requires serious minded 
companies in any area of Business Specialization, In view of this I want you to 
forward your Project Business Plan to the Investor's Vetting Team for review 
and Funding Recommendation.

Regards,
Erik Su.
Email:eriksuinvenstme...@gmail.com



Re: [alsa-devel] [PATCH RESEND 02/15] ASoC: meson: add axg fifo base driver

2018-07-19 Thread Jerome Brunet
On Wed, 2018-07-18 at 17:39 +0200, Takashi Iwai wrote:
> On Wed, 18 Jul 2018 13:50:54 +0200,
> Mark Brown wrote:
> > 
> > On Tue, Jul 17, 2018 at 05:42:51PM +0200, Jerome Brunet wrote:
> > 
> > > + return !status ? IRQ_NONE : IRQ_HANDLED;
> > 
> > Please just write normal conditional statements, it makes things a lot
> > easier to read (the ! isn't helping either here).

Indeed. I'll correct this in a follow up patch

> 
> ... and there is the standard IRQ_RETVAL() macro for this purpose.

I was not aware of it. Thanks for the tip Takashi

> 
> 
> Takashi



[PATCH] mm, oom: remove oom_lock from oom_reaper

2018-07-19 Thread Michal Hocko
From: Michal Hocko 

oom_reaper used to rely on the oom_lock since e2fe14564d33 ("oom_reaper:
close race with exiting task"). We do not really need the lock anymore
though. 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run
concurrently") has removed serialization with the exit path based on the
mm reference count and so we do not really rely on the oom_lock anymore.

Tetsuo was arguing that at least MMF_OOM_SKIP should be set under the
lock to prevent from races when the page allocator didn't manage to get
the freed (reaped) memory in __alloc_pages_may_oom but it sees the flag
later on and move on to another victim. Although this is possible in
principle let's wait for it to actually happen in real life before we
make the locking more complex again.

Therefore remove the oom_lock for oom_reaper paths (both exit_mmap and
oom_reap_task_mm). The reaper serializes with exit_mmap by mmap_sem +
MMF_OOM_SKIP flag. There is no synchronization with out_of_memory path
now.

Suggested-by: David Rientjes 
Signed-off-by: Michal Hocko 
---
 mm/mmap.c |  2 --
 mm/oom_kill.c | 29 -
 2 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index fc41c0543d7f..4642964f7741 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3073,9 +3073,7 @@ void exit_mmap(struct mm_struct *mm)
 * which clears VM_LOCKED, otherwise the oom reaper cannot
 * reliably test it.
 */
-   mutex_lock(&oom_lock);
__oom_reap_task_mm(mm);
-   mutex_unlock(&oom_lock);
 
set_bit(MMF_OOM_SKIP, &mm->flags);
down_write(&mm->mmap_sem);
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 32e6f7becb40..c74bf0bd8010 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -529,28 +529,9 @@ void __oom_reap_task_mm(struct mm_struct *mm)
 
 static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
 {
-   bool ret = true;
-
-   /*
-* We have to make sure to not race with the victim exit path
-* and cause premature new oom victim selection:
-* oom_reap_task_mm exit_mm
-*   mmget_not_zero
-*mmput
-*  atomic_dec_and_test
-*exit_oom_victim
-*  [...]
-*  out_of_memory
-*select_bad_process
-*  # no TIF_MEMDIE task selects new 
victim
-*  unmap_page_range # frees some memory
-*/
-   mutex_lock(&oom_lock);
-
if (!down_read_trylock(&mm->mmap_sem)) {
-   ret = false;
trace_skip_task_reaping(tsk->pid);
-   goto unlock_oom;
+   return false;
}
 
/*
@@ -562,7 +543,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
if (mm_has_blockable_invalidate_notifiers(mm)) {
up_read(&mm->mmap_sem);
schedule_timeout_idle(HZ);
-   goto unlock_oom;
+   return true;
}
 
/*
@@ -574,7 +555,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
if (test_bit(MMF_OOM_SKIP, &mm->flags)) {
up_read(&mm->mmap_sem);
trace_skip_task_reaping(tsk->pid);
-   goto unlock_oom;
+   return true;
}
 
trace_start_task_reaping(tsk->pid);
@@ -589,9 +570,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
up_read(&mm->mmap_sem);
 
trace_finish_task_reaping(tsk->pid);
-unlock_oom:
-   mutex_unlock(&oom_lock);
-   return ret;
+   return true;
 }
 
 #define MAX_OOM_REAP_RETRIES 10
-- 
2.18.0



Re: [PATCH] pinctrl: uniphier: add spi pin-mux settings

2018-07-19 Thread kbuild test robot
Hi Kunihiko,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pinctrl/devel]
[also build test WARNING on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Keiji-Hayashibara/pinctrl-uniphier-add-spi-pin-mux-settings/20180719-144943
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-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
GCC_VERSION=7.2.0 make.cross ARCH=mips 

All warnings (new ones prefixed by >>):

   In file included from drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:21:0:
   drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:629:27: error: 
'spi0_groups' undeclared here (not in a function); did you mean 'spi_groups'?
 UNIPHIER_PINMUX_FUNCTION(spi0),
  ^
   drivers/pinctrl/uniphier/pinctrl-uniphier.h:188:13: note: in definition of 
macro 'UNIPHIER_PINMUX_FUNCTION'
  .groups = func##_groups,\
^~~~
   In file included from include/linux/kernel.h:15:0,
from drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:16:
   include/linux/build_bug.h:29:45: error: bit-field '' width not an 
integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
   include/linux/compiler-gcc.h:65:28: note: in expansion of macro 
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
   ^
   include/linux/kernel.h:72:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^~~
>> drivers/pinctrl/uniphier/pinctrl-uniphier.h:189:17: note: in expansion of 
>> macro 'ARRAY_SIZE'
  .num_groups = ARRAY_SIZE(func##_groups),  \
^~
>> drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:629:2: note: in expansion 
>> of macro 'UNIPHIER_PINMUX_FUNCTION'
 UNIPHIER_PINMUX_FUNCTION(spi0),
 ^~~~

vim +/UNIPHIER_PINMUX_FUNCTION +629 
drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c

   618  
   619  static const struct uniphier_pinmux_function uniphier_sld8_functions[] 
= {
   620  UNIPHIER_PINMUX_FUNCTION(emmc),
   621  UNIPHIER_PINMUX_FUNCTION(ether_mii),
   622  UNIPHIER_PINMUX_FUNCTION(ether_rmii),
   623  UNIPHIER_PINMUX_FUNCTION(i2c0),
   624  UNIPHIER_PINMUX_FUNCTION(i2c1),
   625  UNIPHIER_PINMUX_FUNCTION(i2c2),
   626  UNIPHIER_PINMUX_FUNCTION(i2c3),
   627  UNIPHIER_PINMUX_FUNCTION(nand),
   628  UNIPHIER_PINMUX_FUNCTION(sd),
 > 629  UNIPHIER_PINMUX_FUNCTION(spi0),
   630  UNIPHIER_PINMUX_FUNCTION(system_bus),
   631  UNIPHIER_PINMUX_FUNCTION(uart0),
   632  UNIPHIER_PINMUX_FUNCTION(uart1),
   633  UNIPHIER_PINMUX_FUNCTION(uart2),
   634  UNIPHIER_PINMUX_FUNCTION(uart3),
   635  UNIPHIER_PINMUX_FUNCTION(usb0),
   636  UNIPHIER_PINMUX_FUNCTION(usb1),
   637  UNIPHIER_PINMUX_FUNCTION(usb2),
   638  };
   639  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH v2 17/17] MIPS: JZ4740: DTS: Add DMA nodes

2018-07-19 Thread Sergei Shtylyov

On 7/18/2018 9:20 PM, Paul Cercueil wrote:


Add the devicetree nodes for the DMA core of the JZ4740 SoC, disabled
by default, as currently there are no clients for the DMA driver
(until the MMC driver and/or others get a devicetree node).

Signed-off-by: Paul Cercueil 
Tested-by: Mathieu Malaterre 
---
  arch/mips/boot/dts/ingenic/jz4740.dtsi | 15 +++
  1 file changed, 15 insertions(+)

  v2: New patch in this series

diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi 
b/arch/mips/boot/dts/ingenic/jz4740.dtsi
index 26c6b561d6f7..47d93f2597af 100644
--- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
@@ -154,6 +154,21 @@
clock-names = "baud", "module";
};
  
+	dmac: dma@1302 {


   The node must be named "dma-controller@1302" according to the DT spec.

[...]

MBR, Sergei


Re: [PATCH v5] mtd: nand: toshiba: Add support for Toshiba Memory BENAND (Built-in ECC NAND)

2018-07-19 Thread Boris Brezillon
On Thu, 19 Jul 2018 16:53:33 +0900
KOBAYASHI Yoshitake  wrote:

> From: yoshitake.kobaya...@toshiba.co.jp
> 
> This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND
> memory devices.  Check the status of the built-in ECC with the Read
> Status command without using the vendor specific command.  The Read
> Status command only knows whether there was bitflips above the
> threshold and can not get accurate bitflips.  For now, I set
> max_bitflips mtd->bitflip_threshold.
> 
> Signed-off-by: KOBAYASHI Yoshitake 
> ---
>  drivers/mtd/nand/raw/nand_toshiba.c | 84 
> +
>  1 file changed, 84 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/nand_toshiba.c 
> b/drivers/mtd/nand/raw/nand_toshiba.c
> index ab43f02..6cec923 100644
> --- a/drivers/mtd/nand/raw/nand_toshiba.c
> +++ b/drivers/mtd/nand/raw/nand_toshiba.c
> @@ -17,6 +17,86 @@
>  
>  #include 
>  
> +/* Recommended to rewrite for BENAND */
> +#define TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED  BIT(3)
> +
> +static int toshiba_nand_benand_eccstatus(struct mtd_info *mtd,
> +  struct nand_chip *chip)
> +{
> + int ret;
> + unsigned int max_bitflips = 0;
> + u8 status;
> +
> + /* Check Status */
> + ret = nand_status_op(chip, &status);
> + if (ret)
> + return ret;
> +
> + if (status & NAND_STATUS_FAIL) {
> + /* uncorrected */
> + mtd->ecc_stats.failed++;
> + } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
> + /* corrected */
> + max_bitflips = mtd->bitflip_threshold;
> + mtd->ecc_stats.corrected += max_bitflips;
> + }
> +
> + return max_bitflips;
> +}
> +
> +static int
> +toshiba_nand_read_page_benand(struct mtd_info *mtd,
> +   struct nand_chip *chip, uint8_t *buf,
> +   int oob_required, int page)
> +{
> + int ret;
> +
> + ret = nand_read_page_raw(mtd, chip, buf, oob_required, page);
> + if (ret)
> + return ret;
> +
> + return toshiba_nand_benand_eccstatus(mtd, chip);
> +}
> +
> +static int
> +toshiba_nand_read_subpage_benand(struct mtd_info *mtd,
> +  struct nand_chip *chip, uint32_t data_offs,
> +  uint32_t readlen, uint8_t *bufpoi, int page)
> +{
> + int ret;
> +
> + ret = nand_read_page_op(chip, page, data_offs,
> + bufpoi + data_offs, readlen);
> + if (ret)
> + return ret;
> +
> + return toshiba_nand_benand_eccstatus(mtd, chip);
> +}
> +
> +static void toshiba_nand_benand_init(struct nand_chip *chip)
> +{
> + struct mtd_info *mtd = nand_to_mtd(chip);
> +
> + /*
> +  * On BENAND, the entire OOB region can be used by the MTD user.
> +  * The calculated ECC bytes are stored into other isolated
> +  * area which is not accessible to users.
> +  * This is why chip->ecc.bytes = 0.
> +  */
> + chip->ecc.bytes = 0;
> + chip->ecc.size = 512;
> + chip->ecc.strength = 8;
> + chip->ecc.read_page = toshiba_nand_read_page_benand;
> + chip->ecc.read_subpage = toshiba_nand_read_subpage_benand;
> + chip->ecc.write_page = nand_write_page_raw;
> + chip->ecc.read_page_raw = nand_read_page_raw;
> + chip->ecc.write_page_raw = nand_write_page_raw;

Well, in this case raw accesses are not supported since you can't
disabled ECC. I just introduced nand_{read,write}_page_raw_notsupp(),
so you should probably use them.

> +
> + chip->options |= NAND_SUBPAGE_READ;
> +
> + mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> +}
> +
>  static void toshiba_nand_decode_id(struct nand_chip *chip)
>  {
>   struct mtd_info *mtd = nand_to_mtd(chip);
> @@ -68,6 +148,10 @@ static int toshiba_nand_init(struct nand_chip *chip)
>   if (nand_is_slc(chip))
>   chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
>  
> + if (nand_is_slc(chip) && (chip->id.data[4] & 0x80) /* BENAND */ &&

Please put the /* BENAND */ comment above the if () block.
Maybe you should have a macro for the 0x80 value

#define TOSHIBA_NAND_ID4_IS_BENAND  BIT(7)

and then test

chip->id.data[4] & TOSHIBA_NAND_ID4_IS_BENAND

> + (chip->ecc.mode == NAND_ECC_ON_DIE))

Unneeded parens around chip->ecc.mode == NAND_ECC_ON_DIE and
chip->id.data[4] & 0x80 tests.

> + toshiba_nand_benand_init(chip);
> +
>   return 0;
>  }
>  



Re: [PATCH v2 16/17] MIPS: JZ4770: DTS: Add DMA nodes

2018-07-19 Thread Sergei Shtylyov

On 7/18/2018 9:20 PM, Paul Cercueil wrote:


Add the two devicetree nodes for the two DMA cores of the JZ4770 SoC,
disabled by default, as currently there are no clients for the DMA
driver (until the MMC driver and/or others get a devicetree node).

Signed-off-by: Paul Cercueil 
Tested-by: Mathieu Malaterre 
---
  arch/mips/boot/dts/ingenic/jz4770.dtsi | 30 ++
  1 file changed, 30 insertions(+)

  v2: No change

diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi 
b/arch/mips/boot/dts/ingenic/jz4770.dtsi
index 7c2804f3f5f1..fda17beeb08b 100644
--- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
@@ -196,6 +196,36 @@
status = "disabled";
};
  
+	dmac0: jz4770-dma@1342 {


dmac0: dma-controller@1342 {

[...]


+   dmac1: jz4770-dma@13420100 {


dmac1: dma-controller@13420100 {

[...]

MBR, Sergei


Re: [RFC PATCH v6 0/4] powerpc/fadump: Improvements and fixes for firmware-assisted dump.

2018-07-19 Thread Michal Hocko
On Wed 18-07-18 21:52:17, Mahesh Jagannath Salgaonkar wrote:
> On 07/17/2018 05:22 PM, Michal Hocko wrote:
> > On Tue 17-07-18 16:58:10, Mahesh Jagannath Salgaonkar wrote:
> >> On 07/16/2018 01:56 PM, Michal Hocko wrote:
> >>> On Mon 16-07-18 11:32:56, Mahesh J Salgaonkar wrote:
>  One of the primary issues with Firmware Assisted Dump (fadump) on Power
>  is that it needs a large amount of memory to be reserved. This reserved
>  memory is used for saving the contents of old crashed kernel's memory 
>  before
>  fadump capture kernel uses old kernel's memory area to boot. However, 
>  This
>  reserved memory area stays unused until system crash and isn't available
>  for production kernel to use.
> >>>
> >>> How much memory are we talking about. Regular kernel dump process needs
> >>> some reserved memory as well. Why that is not a big problem?
> >>
> >> We reserve around 5% of total system RAM. On large systems with
> >> TeraBytes of memory, this reservation can be quite significant.
> >>
> >> The regular kernel dump uses the kexec method to boot into capture
> >> kernel and it can control the parameters that are being passed to
> >> capture kernel. This allows a capability to strip down the parameters
> >> that can help lowering down the memory requirement for capture kernel to
> >> boot. This allows regular kdump to reserve less memory to start with.
> >>
> >> Where as fadump depends on power firmware (pHyp) to load the capture
> >> kernel after full reset and boots like a regular kernel. It needs same
> >> amount of memory to boot as the production kernel. On large systems
> >> production kernel needs significant amount of memory to boot. Hence
> >> fadump needs to reserve enough memory for capture kernel to boot
> >> successfully and execute dump capturing operations. By default fadump
> >> reserves 5% of total system RAM and in most cases this has worked
> >> flawlessly on variety of system configurations. Optionally,
> >> 'crashkernel=X' can also be used to specify more fine-tuned memory size
> >> for reservation.
> > 
> > So why do we even care about fadump when regular kexec provides
> > (presumably) same functionality with a smaller memory footprint? Or is
> > there any reason why kexec doesn't work well on ppc?
> 
> Kexec based kdump is loaded by crashing kernel. When OS crashes, the
> system is in an inconsistent state, especially the devices. In some
> cases, a rogue DMA or ill-behaving device drivers can cause the kdump
> capture to fail.
> 
> On power platform, fadump solves these issues by taking help from power
> firmware, to fully-reset the system, load the fresh copy of same kernel
> to capture the dump with PCI and I/O devices reinitialized, making it
> more reliable.

Thanks for the clarification.

> Fadump does full system reset, booting system through the regular boot
> options i.e the dump capture kernel is booted in the same fashion and
> doesn't have specialized kernel command line option. This implies, we
> need to give more memory for the system boot. Since the new kernel boots
> from the same memory location as crashed kernel, we reserve 5% of memory
> where power firmware moves the crashed kernel's memory content. This
> reserved memory is completely removed from the available memory. For
> large memory systems like 64TB systems, this account to ~ 3TB, which is
> a significant chunk of memory production kernel is deprived of. Hence,
> this patch adds an improvement to exiting fadump feature to make the
> reserved memory available to system for use, using zone movable.

Is the 5% a reasonable estimate or more a ballpark number? I find it a
bit strange to require 3TB of memory to boot a kernel just to dump the
crashed kernel image. Shouldn't you rather look into this estimate than
spreading ZONE_MOVABLE abuse? Larger systems need more memory to dump
even with the regular kexec kdump but I have never seen any to use more
than 1G or something like that.
-- 
Michal Hocko
SUSE Labs


Re: [PATCH 2/2] drm/probe_helper: Add drm_helper_probe_single_connector_modes_with_rpm()

2018-07-19 Thread Lukas Wunner
On Wed, Jul 18, 2018 at 04:56:40PM -0400, Lyude Paul wrote:
> For nouveau, while the GPU is guaranteed to be on when a hotplug has
> been received, the same assertion does not hold true if a connector
> probe has been started by userspace without having had received a sysfs
> event.
> 
> So ensure that any connector probing keeps the GPU alive for the
> duration of the probe by introducing
> drm_helper_probe_single_connector_modes_with_rpm(). It's the same as
> drm_helper_probe_single_connector_modes, but it handles holding a power
> reference to the device for the duration of the connector probe.

Hm, a runtime PM ref is already acquired in nouveau_connector_detect().
I'm wondering why that's not sufficient?

Thanks,

Lukas

> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Karol Herbst 
> Cc: Lukas Wunner 
> Cc: sta...@vger.kernel.org
> ---
> Changes since v1:
>  - Add a generic helper to DRM to handle this
> 
>  drivers/gpu/drm/drm_probe_helper.c  | 31 +
>  drivers/gpu/drm/nouveau/dispnv50/disp.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_connector.c |  4 +--
>  include/drm/drm_crtc_helper.h   |  7 +++--
>  4 files changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 527743394150..0a9d6748b854 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -31,6 +31,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -541,6 +542,36 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
>  
> +/**
> + * drm_helper_probe_single_connector_modes_with_rpm - get complete set of
> + *display modes
> + * @connector: connector to probe
> + * @maxX: max width for modes
> + * @maxY: max height for modes
> + *
> + * Same as drm_helper_probe_single_connector_modes, except that it makes sure
> + * that the device is active by synchronously grabbing a runtime power
> + * reference while probing.
> + *
> + * Returns:
> + * The number of modes found on @connector.
> + */
> +int drm_helper_probe_single_connector_modes_with_rpm(struct drm_connector 
> *connector,
> +  uint32_t maxX, uint32_t 
> maxY)
> +{
> + int ret;
> +
> + ret = pm_runtime_get_sync(connector->dev->dev);
> + if (ret < 0 && ret != -EACCES)
> + return ret;
> +
> + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> +
> + pm_runtime_put(connector->dev->dev);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_helper_probe_single_connector_modes_with_rpm);
> +
>  /**
>   * drm_kms_helper_hotplug_event - fire off KMS hotplug events
>   * @dev: drm_device whose connector state changed
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index fa3ab618a0f9..c54767b50fd8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -858,7 +858,7 @@ static const struct drm_connector_funcs
>  nv50_mstc = {
>   .reset = nouveau_conn_reset,
>   .detect = nv50_mstc_detect,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = drm_helper_probe_single_connector_modes_with_rpm,
>   .destroy = nv50_mstc_destroy,
>   .atomic_duplicate_state = nouveau_conn_atomic_duplicate_state,
>   .atomic_destroy_state = nouveau_conn_atomic_destroy_state,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 2a45b4c2ceb0..8d9070779261 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -1088,7 +1088,7 @@ nouveau_connector_funcs = {
>   .reset = nouveau_conn_reset,
>   .detect = nouveau_connector_detect,
>   .force = nouveau_connector_force,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = drm_helper_probe_single_connector_modes_with_rpm,
>   .set_property = nouveau_connector_set_property,
>   .destroy = nouveau_connector_destroy,
>   .atomic_duplicate_state = nouveau_conn_atomic_duplicate_state,
> @@ -1103,7 +1103,7 @@ nouveau_connector_funcs_lvds = {
>   .reset = nouveau_conn_reset,
>   .detect = nouveau_connector_detect_lvds,
>   .force = nouveau_connector_force,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = drm_helper_probe_single_connector_modes_with_rpm,
>   .set_property = nouveau_connector_set_property,
>   .destroy = nouveau_connector_destroy,
>   .atomic_duplicate_state = nouveau_conn_atomic_duplicate_state,
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 6914633037a5..8f3f6d6fcc8c 100644
> --- a/include/drm/drm_crtc_helper.h
>

Re: [PATCH] drivers/base: stop new probing during shutdown

2018-07-19 Thread Rafael J. Wysocki
On Thursday, July 19, 2018 7:14:58 AM CEST Pingfan Liu wrote:
> There is a race window in device_shutdown(), which may cause
> -1. parent device shut down before child or
> -2. no shutdown on a new probing device.
> 
> For 1st, taking the following scenario:
>  device_shutdownnew plugin device
>   list_del_init(parent_dev);
>   spin_unlock(list_lock);
>   device_add(child)
>   probe child
>   shutdown parent_dev
>--> now child is on the tail of devices_kset
> 
> For 2nd, taking the following scenario:
>  device_shutdownnew plugin device
>   device_add(dev)
>   device_lock(dev);
>   ...
>   device_unlock(dev);
>   probe dev
>--> now, the new occurred dev has no opportunity to shutdown
> 
> To fix this race issue, just prevent the new probing request. With this
> logic, device_shutdown() is more similar to dpm_prepare().

Right.

This still doesn't prevent new children of a device from being added during
shutdown (something like the PM ->prepare callback would be needed for that),
but at least it prevents drivers from binding to the new devices.

Reviewed-by: Rafael J. Wysocki 

> Cc: Rafael J. Wysocki 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Pingfan Liu 
> ---
>  drivers/base/core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index df3e1a4..3aba4ad 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2809,6 +2809,9 @@ void device_shutdown(void)
>  {
>   struct device *dev, *parent;
>  
> + wait_for_device_probe();
> + device_block_probing();
> +
>   spin_lock(&devices_kset->list_lock);
>   /*
>* Walk the devices list backward, shutting down each in turn.
> 




Re: [PATCH] vfs: make open_with_fake_path() not contribute to nr_files

2018-07-19 Thread David Howells
Miklos Szeredi  wrote:

> Stacking file operations in overlay will store an extra open file for each
> overlay file opened.
> 
> The overhead is just that of "struct file" which is about 256bytes, because
> overlay already pins an extra dentry and inode when the file is open, which
> add up to a much larger overhead.
> 
> For fear of breaking working setups, don't start accounting the extra file.

Sounds useful for cachefiles too, though Christoph Hellwig objected strongly
last time I tried this, so you might want to check with him directly.

David


[PATCH RESEND v2 2/2] drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support

2018-07-19 Thread Paul Kocialkowski
Not all sunxi platforms with the first version of the Display Engine
support an alpha component on the plane with the lowest z position
(as in: lowest z-pos), that gets blended with the background color.

In particular, the A13 is known to have this limitation. However, it was
recently discovered that the A20 and A33 are capable of having alpha on
their lowest plane.

Thus, this introduces a specific quirk to indicate such support,
per-platform. Since this was not tested on sun4i and sun6i platforms, a
conservative approach is kept and this feature is not supported.

Signed-off-by: Paul Kocialkowski 
---

Changes since v1:
* reordered backend declaration;
* updated comment to reflect that not all platforms are affected;
* used num_alpha_planes_max variable instead of define, since it is now
  dynamic;
* reordered check to have quirk first in associated conditional.

 drivers/gpu/drm/sun4i/sun4i_backend.c | 40 +--
 drivers/gpu/drm/sun4i/sun4i_backend.h |  1 -
 2 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 075cb0ff56ca..685fc3840c6d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -34,6 +34,8 @@
 struct sun4i_backend_quirks {
/* backend <-> TCON muxing selection done in backend */
bool needs_output_muxing;
+   /* alpha at the lowest z position is not always supported */
+   bool supports_lowest_plane_alpha;
 };
 
 static const u32 sunxi_rgb2yuv_coef[12] = {
@@ -463,12 +465,14 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
  struct drm_crtc_state *crtc_state)
 {
struct drm_plane_state *plane_states[SUN4I_BACKEND_NUM_LAYERS] = { 0 };
+   struct sun4i_backend *backend = engine_to_sun4i_backend(engine);
struct drm_atomic_state *state = crtc_state->state;
struct drm_device *drm = state->dev;
struct drm_plane *plane;
unsigned int num_planes = 0;
unsigned int num_alpha_planes = 0;
unsigned int num_frontend_planes = 0;
+   unsigned int num_alpha_planes_max = 1;
unsigned int num_yuv_planes = 0;
unsigned int current_pipe = 0;
unsigned int i;
@@ -532,33 +536,39 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
 * the layer with the highest priority.
 *
 * The second step is the actual alpha blending, that takes
-* the two pipes as input, and uses the eventual alpha
+* the two pipes as input, and uses the potential alpha
 * component to do the transparency between the two.
 *
-* This two steps scenario makes us unable to guarantee a
+* This two-step scenario makes us unable to guarantee a
 * robust alpha blending between the 4 layers in all
 * situations, since this means that we need to have one layer
 * with alpha at the lowest position of our two pipes.
 *
-* However, we cannot even do that, since the hardware has a
-* bug where the lowest plane of the lowest pipe (pipe 0,
-* priority 0), if it has any alpha, will discard the pixel
-* entirely and just display the pixels in the background
-* color (black by default).
+* However, we cannot even do that on every platform, since the
+* hardware has a bug where the lowest plane of the lowest pipe
+* (pipe 0, priority 0), if it has any alpha, will discard the
+* pixel data entirely and just display the pixels in the
+* background color (black by default).
 *
-* This means that we effectively have only three valid
-* configurations with alpha, all of them with the alpha being
-* on pipe1 with the lowest position, which can be 1, 2 or 3
-* depending on the number of planes and their zpos.
+* This means that on the affected platforms, we effectively
+* have only three valid configurations with alpha, all of them
+* with the alpha being on pipe1 with the lowest position, which
+* can be 1, 2 or 3 depending on the number of planes and their zpos.
 */
-   if (num_alpha_planes > SUN4I_BACKEND_NUM_ALPHA_LAYERS) {
+
+   /* For platforms that are not affected by the issue described above. */
+   if (backend->quirks->supports_lowest_plane_alpha)
+   num_alpha_planes_max++;
+
+   if (num_alpha_planes > num_alpha_planes_max) {
DRM_DEBUG_DRIVER("Too many planes with alpha, rejecting...\n");
return -EINVAL;
}
 
/* We can't have an alpha plane at the lowest position */
-   if (plane_states[0]->fb->format->has_alpha ||
-   (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE))
+   if (!backend->quirks->supports_lowest_plane_alpha &&
+   (plane_states[0]->fb->format->has_a

Re: [PATCH v3 1/7] mm, slab: combine kmalloc_caches and kmalloc_dma_caches

2018-07-19 Thread Mel Gorman
On Wed, Jul 18, 2018 at 03:36:14PM +0200, Vlastimil Babka wrote:
> The kmalloc caches currently mainain separate (optional) array
> kmalloc_dma_caches for __GFP_DMA allocations. There are tests for __GFP_DMA in
> the allocation hotpaths. We can avoid the branches by combining kmalloc_caches
> and kmalloc_dma_caches into a single two-dimensional array where the outer
> dimension is cache "type". This will also allow to add kmalloc-reclaimable
> caches as a third type.
> 
> Signed-off-by: Vlastimil Babka 

I'm surprised there are so many kmalloc users that require the DMA zone.
Some of them are certainly bogus such as in drivers for archs that only
have one zone and is probably a reflection of the confusing naming. The
audit would be a mess and unrelated to the patch so for this patch;

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs


Re: [PATCH v2 1/2] mm: fix race on soft-offlining free huge pages

2018-07-19 Thread Naoya Horiguchi
On Thu, Jul 19, 2018 at 09:15:16AM +0200, Michal Hocko wrote:
> On Thu 19-07-18 06:19:45, Naoya Horiguchi wrote:
> > On Wed, Jul 18, 2018 at 10:50:32AM +0200, Michal Hocko wrote:
> > > On Wed 18-07-18 00:55:29, Naoya Horiguchi wrote:
> > > > On Tue, Jul 17, 2018 at 04:27:43PM +0200, Michal Hocko wrote:
> > > > > On Tue 17-07-18 14:32:31, Naoya Horiguchi wrote:
> > > > > > There's a race condition between soft offline and hugetlb_fault 
> > > > > > which
> > > > > > causes unexpected process killing and/or hugetlb allocation failure.
> > > > > >
> > > > > > The process killing is caused by the following flow:
> > > > > >
> > > > > >   CPU 0   CPU 1  CPU 2
> > > > > >
> > > > > >   soft offline
> > > > > > get_any_page
> > > > > > // find the hugetlb is free
> > > > > >   mmap a hugetlb file
> > > > > >   page fault
> > > > > > ...
> > > > > >   hugetlb_fault
> > > > > > hugetlb_no_page
> > > > > >   alloc_huge_page
> > > > > >   // succeed
> > > > > >   soft_offline_free_page
> > > > > >   // set hwpoison flag
> > > > > >  mmap the hugetlb file
> > > > > >  page fault
> > > > > >...
> > > > > >  hugetlb_fault
> > > > > >hugetlb_no_page
> > > > > >  find_lock_page
> > > > > >return 
> > > > > > VM_FAULT_HWPOISON
> > > > > >mm_fault_error
> > > > > >  do_sigbus
> > > > > >  // kill the process
> > > > > >
> > > > > >
> > > > > > The hugetlb allocation failure comes from the following flow:
> > > > > >
> > > > > >   CPU 0  CPU 1
> > > > > >
> > > > > >  mmap a hugetlb file
> > > > > >  // reserve all free page but don't 
> > > > > > fault-in
> > > > > >   soft offline
> > > > > > get_any_page
> > > > > > // find the hugetlb is free
> > > > > >   soft_offline_free_page
> > > > > >   // set hwpoison flag
> > > > > > dissolve_free_huge_page
> > > > > > // fail because all free hugepages are reserved
> > > > > >  page fault
> > > > > >...
> > > > > >  hugetlb_fault
> > > > > >hugetlb_no_page
> > > > > >  alloc_huge_page
> > > > > >...
> > > > > >  
> > > > > > dequeue_huge_page_node_exact
> > > > > >  // ignore hwpoisoned 
> > > > > > hugepage
> > > > > >  // and finally fail 
> > > > > > due to no-mem
> > > > > >
> > > > > > The root cause of this is that current soft-offline code is written
> > > > > > based on an assumption that PageHWPoison flag should beset at first 
> > > > > > to
> > > > > > avoid accessing the corrupted data.  This makes sense for 
> > > > > > memory_failure()
> > > > > > or hard offline, but does not for soft offline because soft offline 
> > > > > > is
> > > > > > about corrected (not uncorrected) error and is safe from data lost.
> > > > > > This patch changes soft offline semantics where it sets 
> > > > > > PageHWPoison flag
> > > > > > only after containment of the error page completes successfully.
> > > > >
> > > > > Could you please expand on the worklow here please? The code is really
> > > > > hard to grasp. I must be missing something because the thing shouldn't
> > > > > be really complicated. Either the page is in the free pool and you 
> > > > > just
> > > > > remove it from the allocator (with hugetlb asking for a new hugeltb 
> > > > > page
> > > > > to guaratee reserves) or it is used and you just migrate the content 
> > > > > to
> > > > > a new page (again with the hugetlb reserves consideration). Why should
> > > > > PageHWPoison flag ordering make any relevance?
> > > >
> > > > (Considering soft offlining free hugepage,)
> > > > PageHWPoison is set at first before this patch, which is racy with
> > > > hugetlb fault code because it's not protected by hugetlb_lock.
> > > >
> > > > Originally this was written in the similar manner as hard-offline, where
> > > > the race is accepted and a PageHWPoison flag is set as soon as possible.
> > > > But actually that's found not necessary/correct because soft offline is
> > > > supposed to be less aggressive an

Re: [PATCH] reset: uniphier: add reset control support for SPI

2018-07-19 Thread Masahiro Yamada
2018-07-19 15:18 GMT+09:00 Keiji Hayashibara :
> From: Kunihiko Hayashi 
>
> Add reset control for SPI controller on UniPhier SoCs.
>
> Signed-off-by: Kunihiko Hayashi 
> ---


Acked-by: Masahiro Yamada 


>  drivers/reset/reset-uniphier.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index e9030ff..5605745 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -202,6 +202,12 @@ static const struct uniphier_reset_data 
> uniphier_pro5_sd_reset_data[] = {
>  #define UNIPHIER_PERI_RESET_FI2C(id, ch)   \
> UNIPHIER_RESETX((id), 0x114, 24 + (ch))
>
> +#define UNIPHIER_PERI_RESET_SCSSI(id)  \
> +   UNIPHIER_RESETX((id), 0x110, 17)
> +
> +#define UNIPHIER_PERI_RESET_MCSSI(id)  \
> +   UNIPHIER_RESETX((id), 0x114, 14)
> +
>  static const struct uniphier_reset_data uniphier_ld4_peri_reset_data[] = {
> UNIPHIER_PERI_RESET_UART(0, 0),
> UNIPHIER_PERI_RESET_UART(1, 1),
> @@ -212,6 +218,7 @@ static const struct uniphier_reset_data 
> uniphier_ld4_peri_reset_data[] = {
> UNIPHIER_PERI_RESET_I2C(6, 2),
> UNIPHIER_PERI_RESET_I2C(7, 3),
> UNIPHIER_PERI_RESET_I2C(8, 4),
> +   UNIPHIER_PERI_RESET_SCSSI(11),
> UNIPHIER_RESET_END,
>  };
>
> @@ -227,6 +234,8 @@ static const struct uniphier_reset_data 
> uniphier_pro4_peri_reset_data[] = {
> UNIPHIER_PERI_RESET_FI2C(8, 4),
> UNIPHIER_PERI_RESET_FI2C(9, 5),
> UNIPHIER_PERI_RESET_FI2C(10, 6),
> +   UNIPHIER_PERI_RESET_SCSSI(11),
> +   UNIPHIER_PERI_RESET_MCSSI(12),
> UNIPHIER_RESET_END,
>  };
>
> --
> 2.7.4
>



-- 
Best Regards
Masahiro Yamada


Re: [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

2018-07-19 Thread Yixun Lan
HI Boris:

thanks for the quick response.

On 07/19/18 03:08, Boris Brezillon wrote:
> Hi Yixun,
> 
> On Wed, 18 Jul 2018 17:38:56 +0800
> Yixun Lan  wrote:
> 
 +
 +#define NFC_REG_CMD   0x00
 +#define NFC_REG_CFG   0x04
 +#define NFC_REG_DADR  0x08
 +#define NFC_REG_IADR  0x0c
 +#define NFC_REG_BUF   0x10
 +#define NFC_REG_INFO  0x14
 +#define NFC_REG_DC0x18
 +#define NFC_REG_ADR   0x1c
 +#define NFC_REG_DL0x20
 +#define NFC_REG_DH0x24
 +#define NFC_REG_CADR  0x28
 +#define NFC_REG_SADR  0x2c
 +#define NFC_REG_PINS  0x30
 +#define NFC_REG_VER   0x38
 +  
>>>
>>> Can you put the reg offsets next to their field definitions?
>>>   
>> actually, we would prefer to put all the CMD definition below the reg
>> offset, so it will better reflect what's it belong to.
> 
> Just to be clear, I meant something like:
> 
> #define NFC_CMD   0x00
> #define NFC_CMD_DRD   (0x8 << 14)
> #define NFC_CMD_IDLE  (0xc << 14)
> ...
> 
> #define NFC_CFG   0x04
> #define NFC_CFG_XXX   xxx
> ...
> 
> I find it easier to guess which register the fields are attached to when
> it's defined like that, but I won't block the driver for such a tiny
> detail. 
> 
yes, this is exactly what I mean

 +static void meson_nfc_cmd_ctrl(struct mtd_info *mtd,
 +  int cmd, unsigned int ctrl)  
>>>   
>>> ->cmd_ctrl() has recently been deprecated in favor of ->exec_op(). You  
>>> can have a look at the marvell, v610 or fsmc drivers if you want to
>>> have an idea of how ->exec_op() should be implemented. Miquel and I are
>>> also here to help if you have any questions.
>>>   
>>
>> follow your suggestion, we have implemented the exec_op() interface,
>> we'd really appreciate if you can help to review this ..
> 
> Sure, just send a v2 and we'll review it.
> 
> 
 +
 +static void meson_nfc_cmd_m2n(struct meson_nfc *nfc, int raw)  
>>>
>>> n2m -> nand2mem ?
>>>   
>> yes, it is
> 
> Then please use nand2mem, it's clearer.
we end at dropping the n2m function. by converting them into

static void
meson_nfc_cmd_access(
struct meson_nfc *nfc,
struct mtd_info *mtd, int raw, bool dir)


> 
 +static int meson_nfc_wait_dma_finish(struct meson_nfc *nfc)
 +{
 +  meson_nfc_cmd_idle(nfc, 0);
 +  meson_nfc_cmd_idle(nfc, 0);  
>>>
>>> Two calls to cmd_idle(), is this expected or a copy&paste error? If
>>> that's expected it definitely deserves a comment explaining why?
>>>   
>>
>> yes, it is intentional
>>
>> we will put these comments into the function.
>>  /*
>>  * The Nand flash controller is designed as two stages pipleline -
>>  *  a) fetch and b) excute.
>>  * So, there might be cases when the driver see command queue is
>> empty,
>>  * but the Nand flash controller still has two commands buffered,
>>  * one is fetched into NFC request queue (ready to run), and another
>>  * is actively executing.
>>  */
>>
> 
> So pushing 2 "IDLE" commands guarantees that the pipeline is emptied,
> right? The comment looks incomplete, you should explain what those
> meson_nfc_cmd_idle() are for.
> 
thanks

the meson_nfc_cmd_idle() function itself is quite straightforward, and
we feel explain that inserting 2 "IDLE" commands to drain out the
pipeline is enough.

 +static int meson_nfc_ecc_init(struct device *dev, struct mtd_info *mtd)
 +{
 +  struct nand_chip *nand = mtd_to_nand(mtd);
 +  struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
 +  struct meson_nfc *nfc = nand_get_controller_data(nand);
 +  struct meson_nand_ecc *meson_ecc = nfc->data->ecc;
 +  int num = nfc->data->ecc_num;
 +  int nsectors, i, bytes;
 +
 +  /* support only ecc hw mode */
 +  if (nand->ecc.mode != NAND_ECC_HW) {  
>>>
>>> Given that you support raw accesses, I'm pretty sure you can support
>>> ECC_NONE, ECC_SOFT and ECC_ON_DIE with zero effort.
>>>   
>>
>> is this a block for this driver to be accepted by upstream?
> 
> Nope.
> 
>> otherwise we'd like to implement this feature later in separate patch.
>>
> 
> That's fine.
> 
 +  nsectors = mtd->writesize / nand->ecc.size;
 +  bytes =(meson_chip->user_mode == NFC_USER2_OOB_BYTES) ? nsectors * 2 : 
 16;
 +  if (mtd->oobsize < (nand->ecc.bytes * nsectors + bytes))
 +  return -EINVAL;  
>>>
>>> It's probably worth looking at what is being proposed here [2] for the
>>> ECC config selection logic.
>>>   
>>
>> sure, we'd happy to adopt the ECC config helper function, and seems it
>> is possible ;-)
>>
>> sounds the proposed ECC config patch is still under review, and we
>> would like to adjust our code once it'

Re: [PATCH 1/7] drivers: qcom: rpmh-rsc: fix the loop index check in get_req_from_tcs

2018-07-19 Thread Raju P L S S S N

Hi all,

This is an independent patch and not part of patch set. There was some 
issue while sending the patch using git send-email. Please ignore 1/7 in 
the mail subject. Sorry for multiple mails.


Thanks,
Raju.

On 7/19/2018 12:43 PM, Raju P L S S S N wrote:

From: "Raju P.L.S.S.S.N" 

get_req_from_tcs introduced in patch[1] returns tcs_request from
tcs_group. The size of tcs (of type - tcs_group) array in rsc_drv is
TCS_TYPE_NR. So the loop index needs to be iterated up to TCS_TYPE_NR only.

[1] https://patchwork.kernel.org/patch/10477547/

Signed-off-by: Raju P.L.S.S.S.N 
---
  drivers/soc/qcom/rpmh-rsc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index fefda0f..33fe9f9 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -190,7 +190,7 @@ static const struct tcs_request *get_req_from_tcs(struct 
rsc_drv *drv,
struct tcs_group *tcs;
int i;
  
-	for (i = 0; i < drv->num_tcs; i++) {

+   for (i = 0; i < TCS_TYPE_NR; i++) {
tcs = &drv->tcs[i];
if (tcs->mask & BIT(tcs_id))
return tcs->req[tcs_id - tcs->offset];



[PATCH] mm: adjust max read count in generic_file_buffered_read()

2018-07-19 Thread Chengguang Xu
When we try to truncate read count in generic_file_buffered_read(),
should deliver (sb->s_maxbytes - offset) as maximum count not
sb->s_maxbytes itself.

Signed-off-by: Chengguang Xu 
---
 mm/filemap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 52517f28e6f4..5c2d481d21cf 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2064,7 +2064,7 @@ static ssize_t generic_file_buffered_read(struct kiocb 
*iocb,
 
if (unlikely(*ppos >= inode->i_sb->s_maxbytes))
return 0;
-   iov_iter_truncate(iter, inode->i_sb->s_maxbytes);
+   iov_iter_truncate(iter, inode->i_sb->s_maxbytes - *ppos);
 
index = *ppos >> PAGE_SHIFT;
prev_index = ra->prev_pos >> PAGE_SHIFT;
-- 
2.17.1



[PATCH v5] mtd: nand: toshiba: Add support for Toshiba Memory BENAND (Built-in ECC NAND)

2018-07-19 Thread KOBAYASHI Yoshitake
From: yoshitake.kobaya...@toshiba.co.jp

This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND
memory devices.  Check the status of the built-in ECC with the Read
Status command without using the vendor specific command.  The Read
Status command only knows whether there was bitflips above the
threshold and can not get accurate bitflips.  For now, I set
max_bitflips mtd->bitflip_threshold.

Signed-off-by: KOBAYASHI Yoshitake 
---
 drivers/mtd/nand/raw/nand_toshiba.c | 84 +
 1 file changed, 84 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_toshiba.c 
b/drivers/mtd/nand/raw/nand_toshiba.c
index ab43f02..6cec923 100644
--- a/drivers/mtd/nand/raw/nand_toshiba.c
+++ b/drivers/mtd/nand/raw/nand_toshiba.c
@@ -17,6 +17,86 @@
 
 #include 
 
+/* Recommended to rewrite for BENAND */
+#define TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDEDBIT(3)
+
+static int toshiba_nand_benand_eccstatus(struct mtd_info *mtd,
+struct nand_chip *chip)
+{
+   int ret;
+   unsigned int max_bitflips = 0;
+   u8 status;
+
+   /* Check Status */
+   ret = nand_status_op(chip, &status);
+   if (ret)
+   return ret;
+
+   if (status & NAND_STATUS_FAIL) {
+   /* uncorrected */
+   mtd->ecc_stats.failed++;
+   } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
+   /* corrected */
+   max_bitflips = mtd->bitflip_threshold;
+   mtd->ecc_stats.corrected += max_bitflips;
+   }
+
+   return max_bitflips;
+}
+
+static int
+toshiba_nand_read_page_benand(struct mtd_info *mtd,
+ struct nand_chip *chip, uint8_t *buf,
+ int oob_required, int page)
+{
+   int ret;
+
+   ret = nand_read_page_raw(mtd, chip, buf, oob_required, page);
+   if (ret)
+   return ret;
+
+   return toshiba_nand_benand_eccstatus(mtd, chip);
+}
+
+static int
+toshiba_nand_read_subpage_benand(struct mtd_info *mtd,
+struct nand_chip *chip, uint32_t data_offs,
+uint32_t readlen, uint8_t *bufpoi, int page)
+{
+   int ret;
+
+   ret = nand_read_page_op(chip, page, data_offs,
+   bufpoi + data_offs, readlen);
+   if (ret)
+   return ret;
+
+   return toshiba_nand_benand_eccstatus(mtd, chip);
+}
+
+static void toshiba_nand_benand_init(struct nand_chip *chip)
+{
+   struct mtd_info *mtd = nand_to_mtd(chip);
+
+   /*
+* On BENAND, the entire OOB region can be used by the MTD user.
+* The calculated ECC bytes are stored into other isolated
+* area which is not accessible to users.
+* This is why chip->ecc.bytes = 0.
+*/
+   chip->ecc.bytes = 0;
+   chip->ecc.size = 512;
+   chip->ecc.strength = 8;
+   chip->ecc.read_page = toshiba_nand_read_page_benand;
+   chip->ecc.read_subpage = toshiba_nand_read_subpage_benand;
+   chip->ecc.write_page = nand_write_page_raw;
+   chip->ecc.read_page_raw = nand_read_page_raw;
+   chip->ecc.write_page_raw = nand_write_page_raw;
+
+   chip->options |= NAND_SUBPAGE_READ;
+
+   mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+}
+
 static void toshiba_nand_decode_id(struct nand_chip *chip)
 {
struct mtd_info *mtd = nand_to_mtd(chip);
@@ -68,6 +148,10 @@ static int toshiba_nand_init(struct nand_chip *chip)
if (nand_is_slc(chip))
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
 
+   if (nand_is_slc(chip) && (chip->id.data[4] & 0x80) /* BENAND */ &&
+   (chip->ecc.mode == NAND_ECC_ON_DIE))
+   toshiba_nand_benand_init(chip);
+
return 0;
 }
 
-- 
2.7.4




Re: [PATCH 1/4] iio: adc: xilinx: Rename 'channels' variable name to 'iio_xadc_channels'

2018-07-19 Thread Michal Simek
On 18.7.2018 13:18, Lars-Peter Clausen wrote:
> On 07/18/2018 01:12 PM, Manish Narani wrote:
>> This patch fix the following checkpatch warning in xadc driver.
>> - Reusing the krealloc arg is almost always a bug.
>>
>> Renamed the 'channels' variable as 'iio_xadc_channels' to fix the above
>> warning.
>>
> 
> This is a bug in checkpatch and should be fixed in checkpatch. The code is
> not actually re-using the parameter. channels and xadc_channels are
> independent variables, just checkpatch somehow does not realize this.

I think it should be fine to have this patch in tree. Change in commit
message to reflect this should be enough. But that's just view.

Thanks,
Michal


Re: [PATCH v3 2/7] mm, slab/slub: introduce kmalloc-reclaimable caches

2018-07-19 Thread Mel Gorman
On Wed, Jul 18, 2018 at 03:36:15PM +0200, Vlastimil Babka wrote:
> Kmem caches can be created with a SLAB_RECLAIM_ACCOUNT flag, which indicates
> they contain objects which can be reclaimed under memory pressure (typically
> through a shrinker). This makes the slab pages accounted as 
> NR_SLAB_RECLAIMABLE
> in vmstat, which is reflected also the MemAvailable meminfo counter and in
> overcommit decisions. The slab pages are also allocated with 
> __GFP_RECLAIMABLE,
> which is good for anti-fragmentation through grouping pages by mobility.
> 
> The generic kmalloc-X caches are created without this flag, but sometimes are
> used also for objects that can be reclaimed, which due to varying size cannot
> have a dedicated kmem cache with SLAB_RECLAIM_ACCOUNT flag. A prominent 
> example
> are dcache external names, which prompted the creation of a new, manually
> managed vmstat counter NR_INDIRECTLY_RECLAIMABLE_BYTES in commit f1782c9bc547
> ("dcache: account external names as indirectly reclaimable memory").
> 
> To better handle this and any other similar cases, this patch introduces
> SLAB_RECLAIM_ACCOUNT variants of kmalloc caches, named kmalloc-rcl-X.
> They are used whenever the kmalloc() call passes __GFP_RECLAIMABLE among gfp
> flags. They are added to the kmalloc_caches array as a new type. Allocations
> with both __GFP_DMA and __GFP_RECLAIMABLE will use a dma type cache.
> 
> This change only applies to SLAB and SLUB, not SLOB. This is fine, since 
> SLOB's
> target are tiny system and this patch does add some overhead of kmem 
> management
> objects.
> 
> Signed-off-by: Vlastimil Babka 
>
> 
>
> @@ -309,12 +310,19 @@ extern struct kmem_cache 
> *kmalloc_caches[KMALLOC_TYPES][KMALLOC_SHIFT_HIGH + 1];
>  static __always_inline unsigned int kmalloc_type(gfp_t flags)
>  {
>   int is_dma = 0;
> + int is_reclaimable;
>  
>  #ifdef CONFIG_ZONE_DMA
>   is_dma = !!(flags & __GFP_DMA);
>  #endif
>  
> - return is_dma;
> + is_reclaimable = !!(flags & __GFP_RECLAIMABLE);
> +
> + /*
> +  * If an allocation is botth __GFP_DMA and __GFP_RECLAIMABLE, return
> +  * KMALLOC_DMA and effectively ignore __GFP_RECLAIMABLE
> +  */
> + return (is_dma * 2) + (is_reclaimable & !is_dma);
>  }
>  

s/botth/both/



>  /*
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 4614248ca381..614fb7ab8312 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1107,10 +1107,21 @@ void __init setup_kmalloc_cache_index_table(void)
>   }
>  }
>  
> -static void __init new_kmalloc_cache(int idx, slab_flags_t flags)
> +static void __init
> +new_kmalloc_cache(int idx, int type, slab_flags_t flags)
>  {
> - kmalloc_caches[KMALLOC_NORMAL][idx] = create_kmalloc_cache(
> - kmalloc_info[idx].name,
> + const char *name;
> +
> + if (type == KMALLOC_RECLAIM) {
> + flags |= SLAB_RECLAIM_ACCOUNT;
> + name = kasprintf(GFP_NOWAIT, "kmalloc-rcl-%u",
> + kmalloc_info[idx].size);
> + BUG_ON(!name);
> + } else {
> + name = kmalloc_info[idx].name;
> + }
> +
> + kmalloc_caches[type][idx] = create_kmalloc_cache(name,
>   kmalloc_info[idx].size, flags, 0,
>   kmalloc_info[idx].size);
>  }

I was going to query that BUG_ON but if I'm reading it right, we just
have to be careful in the future that the "normal" kmalloc cache is always
initialised before the reclaimable cache or there will be issues.

> @@ -1122,22 +1133,25 @@ static void __init new_kmalloc_cache(int idx, 
> slab_flags_t flags)
>   */
>  void __init create_kmalloc_caches(slab_flags_t flags)
>  {
> - int i;
> - int type = KMALLOC_NORMAL;
> + int i, type;
>  
> - for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
> - if (!kmalloc_caches[type][i])
> - new_kmalloc_cache(i, flags);
> + for (type = KMALLOC_NORMAL; type <= KMALLOC_RECLAIM; type++) {
> + for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
> + if (!kmalloc_caches[type][i])
> + new_kmalloc_cache(i, type, flags);
>  

I don't see a problem here as such but the values of the KMALLOC_* types
is important both for this function and the kmalloc_type(). It might be
worth adding a warning that these functions be examined if updating the
types but then again, anyone trying and getting it wrong will have a
broken kernel so;

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs


Re: [RFC PATCH] mtd: nand: toshiba: Add support for ->exec_op()

2018-07-19 Thread Boris Brezillon
On Thu, 19 Jul 2018 16:53:47 +0900
KOBAYASHI Yoshitake  wrote:

> This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND
> memory devices.  This use vendor specific command
> (TOSHIBA_NAND_CMD_ECC_STATUS) to know the exact bitflips.  However, I
> could not test this patch because I do not have a platform that
> supports chip-> exec_op.  Therefore, I post this patch as RFC.
> 
> As soon as I get a platform that supports chip-> exec_op, I would like
> to test and re-post.
> 
> Signed-off-by: KOBAYASHI Yoshitake 
> ---
>  drivers/mtd/nand/raw/nand_toshiba.c | 76
> + 1 file changed, 61
> insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_toshiba.c
> b/drivers/mtd/nand/raw/nand_toshiba.c index 6cec923..12218cd 100644
> --- a/drivers/mtd/nand/raw/nand_toshiba.c
> +++ b/drivers/mtd/nand/raw/nand_toshiba.c
> @@ -17,28 +17,74 @@
>  
>  #include 
>  
> +/* ECC Status Read Command for BENAND */
> +#define TOSHIBA_NAND_CMD_ECC_STATUS_READ 0x7A
> +
> +/* ECC Status Mask for BENAND */
> +#define TOSHIBA_NAND_ECC_STATUS_MASK 0x0F
> +
>  /* Recommended to rewrite for BENAND */
>  #define TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED  BIT(3)
>  
> +static int toshiba_nand_benand_read_eccstatus_op(struct nand_chip
> *chip,
> +  u8 *buf)
> +{
> + u8 *ecc_status = buf;
> +

How about letting this function return -ENOTSUPP when ->exec_op() is
not implemented?

if (!chip->exec_op)
return -ENOTSUPP;

> + const struct nand_sdr_timings *sdr =
> + nand_get_sdr_timings(&chip->data_interface);
> + struct nand_op_instr instrs[] = {
> + NAND_OP_CMD(TOSHIBA_NAND_CMD_ECC_STATUS_READ,
> + PSEC_TO_NSEC(sdr->tADL_min)),
> + NAND_OP_8BIT_DATA_IN(chip->ecc.steps, ecc_status, 0),
> + };
> + struct nand_operation op = NAND_OPERATION(instrs);
> +
> + /* Drop the DATA_IN instruction if chip->ecc.steps is set to
> 0. */
> + if (!chip->ecc.steps)

Can this really happen? I hope not.

> + op.ninstrs--;
> +
> + return nand_exec_op(chip, &op);
> +}
> +
>  static int toshiba_nand_benand_eccstatus(struct mtd_info *mtd,
>struct nand_chip *chip)
>  {
> - int ret;
> + int ret, i;
>   unsigned int max_bitflips = 0;
> - u8 status;
> -
> - /* Check Status */
> - ret = nand_status_op(chip, &status);
> - if (ret)
> - return ret;
> -
> - if (status & NAND_STATUS_FAIL) {
> - /* uncorrected */
> - mtd->ecc_stats.failed++;
> - } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED)
> {
> - /* corrected */
> - max_bitflips = mtd->bitflip_threshold;
> - mtd->ecc_stats.corrected += max_bitflips;
> + u8 status, bitflips, ecc_status[8];
> +
> + if (chip->exec_op) {
> + /* Check ECC Status */
> + ret = toshiba_nand_benand_read_eccstatus_op(chip,
> ecc_status);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < chip->ecc.steps; i++) {
> + bitflips = (ecc_status[i] &
> + TOSHIBA_NAND_ECC_STATUS_MASK);

Unneeded parens.

> + if (bitflips == 0x0F) {

Please define a macro for the UNCORRECTABLE (0xf) value.

> + mtd->ecc_stats.failed++;
> + } else {
> + mtd->ecc_stats.corrected += bitflips;
> + max_bitflips = max_t(unsigned int,
> +  max_bitflips,
> bitflips);

Declare bitflips as an unsigned int, so that you can use max() instead
of max_t().

> + }
> + }
> + } else {
> + /* Check Status */
> + ret = nand_status_op(chip, &status);
> + if (ret)
> + return ret;
> +
> + if (status & NAND_STATUS_FAIL) {
> + /* uncorrected */
> + mtd->ecc_stats.failed++;
> + } else if (status &
> TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
> + /* corrected */
> + max_bitflips = mtd->bitflip_threshold;
> + mtd->ecc_stats.corrected += max_bitflips;
> + }
>   }

If you go for the "toshiba_nand_benand_read_eccstatus_op() returns
-ENOTSUPP solution", you could replace the above section by:

ret = toshiba_nand_benand_read_eccstatus_op(chip, ecc_status);
if (!ret) {
u8 ecc_status[8];
unsigned int i;

for (i = 0; i < chip->ecc.steps; i++) {
bitflips = ecc_status[i] & TOSHIBA_NAND_ECC_STATUS_MASK;
if (bitflips == TOSHIBA_NAND_ECC_STATUS_UNCORR) {
mtd-

Re: [RFC] perf annotate: option to report global percentage

2018-07-19 Thread Jiri Olsa
On Wed, Jul 18, 2018 at 02:55:14PM -0700, Stephane Eranian wrote:
> Hi Jiri,
> 
> As far as I know, once you go into annotate mode, via perf report TUI
> mode, the percentage you see per instruction is relative to the
> function. I would like the option to display the total percentage,
> i..e, the importance of the instruction for the entire run. Right now,
> if I want that, I need to do function_percentage * insn_percentage by
> hand. This is not convenient. Having a key toggle would be very
> useful, worst case a cmdline option.
> 
> What do you think?

hi,
that should be simple to add, we already have the 'F' in the
main browser window to toggle among full/filtered scale

I'll try to add something similar for annotation window

jirka


Re: [PATCH v2 1/2] mm: fix race on soft-offlining free huge pages

2018-07-19 Thread Michal Hocko
On Thu 19-07-18 08:08:05, Naoya Horiguchi wrote:
> On Thu, Jul 19, 2018 at 09:15:16AM +0200, Michal Hocko wrote:
> > On Thu 19-07-18 06:19:45, Naoya Horiguchi wrote:
> > > On Wed, Jul 18, 2018 at 10:50:32AM +0200, Michal Hocko wrote:
[...]
> > > > Why do we even need HWPoison flag here? Everything can be completely
> > > > transparent to the application. It shouldn't fail from what I
> > > > understood.
> > > 
> > > PageHWPoison flag is used to the 'remove from the allocator' part
> > > which is like below:
> > > 
> > >   static inline
> > >   struct page *rmqueue(
> > >   ...
> > >   do {
> > >   page = NULL;
> > >   if (alloc_flags & ALLOC_HARDER) {
> > >   page = __rmqueue_smallest(zone, order, 
> > > MIGRATE_HIGHATOMIC);
> > >   if (page)
> > >   trace_mm_page_alloc_zone_locked(page, 
> > > order, migratetype);
> > >   }
> > >   if (!page)
> > >   page = __rmqueue(zone, order, migratetype);
> > >   } while (page && check_new_pages(page, order));
> > > 
> > > check_new_pages() returns true if the page taken from free list has
> > > a hwpoison page so that the allocator iterates another round to get
> > > another page.
> > > 
> > > There's no function that can be called from outside allocator to remove
> > > a page in allocator.  So actual page removal is done at allocation time,
> > > not at error handling time. That's the reason why we need PageHWPoison.
> > 
> > hwpoison is an internal mm functionality so why cannot we simply add a
> > function that would do that?
> 
> That's one possible solution.

I would prefer that much more than add an overhead (albeit small) into
the page allocator directly. HWPoison should be a really rare event so
why should everybody pay the price? I would much rather see that the
poison path pays the additional price.

> I know about another downside in current implementation.
> If a hwpoison page is found during high order page allocation,
> all 2^order pages (not only hwpoison page) are removed from
> buddy because of the above quoted code. And these leaked pages
> are never returned to freelist even with unpoison_memory().
> If we have a page removal function which properly splits high order
> free pages into lower order pages, this problem is avoided.

Even more reason to move to a new scheme.

> OTOH PageHWPoison still has a role to report error to userspace.
> Without it unpoison_memory() doesn't work.

Sure but we do not really need a special page flag for that. We know the
page is not reachable other than via pfn walkers. If you make the page
reserved and note the fact it has been poisoned in the past then you can
emulate the missing functionality.

Btw. do we really need unpoisoning functionality? Who is really using
it, other than some tests? How does the memory become OK again? Don't we
really need to go through physical hotremove & hotadd to clean the
poison status?

Thanks!
-- 
Michal Hocko
SUSE Labs


Re: [PATCHv5 05/19] mm/page_alloc: Handle allocation for encrypted memory

2018-07-19 Thread Kirill A. Shutemov
On Wed, Jul 18, 2018 at 04:03:53PM -0700, Dave Hansen wrote:
> I asked about this before and it still isn't covered in the description:
> You were specifically asked (maybe in person at LSF/MM?) not to modify
> allocator to pass the keyid around.  Please specifically mention how
> this design addresses that feedback in the patch description.
> 
> You were told, "don't change the core allocator", so I think you just
> added new functions that wrap the core allocator and called them from
> the majority of sites that call into the core allocator.  Personally, I
> think that misses the point of the original request.
> 
> Do I have a better way?  Nope, not really.

+Michal.

IIRC, Michal was not happy that I propagate the KeyID to very core
allcoator and we've talked about wrappers around existing APIs as a better
solution.

Michal, is it correct?

> > +/*
> > + * Encrypted page has to be cleared once keyid is set, not on allocation.
> > + */
> > +static inline bool encrypted_page_needs_zero(int keyid, gfp_t *gfp_mask)
> > +{
> > +   if (!keyid)
> > +   return false;
> > +
> > +   if (*gfp_mask & __GFP_ZERO) {
> > +   *gfp_mask &= ~__GFP_ZERO;
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}
> 
> Shouldn't this be zero_page_at_alloc()?
> 
> Otherwise, it gets confusing about whether the page needs zeroing at
> *all*, vs at alloc vs. free.

I like your idea with deferred_page_zero() below. I'll go with it.

> > +static inline struct page *alloc_pages_node_keyid(int nid, int keyid,
> > +   gfp_t gfp_mask, unsigned int order)
> > +{
> > +   if (nid == NUMA_NO_NODE)
> > +   nid = numa_mem_id();
> > +
> > +   return __alloc_pages_node_keyid(nid, keyid, gfp_mask, order);
> > +}
> 
> We have an innumerable number of (__)?alloc_pages* functions.  This adds
> two more.  I'm not a big fan of making this worse.
> 
> Do I have a better idea?  Not really.  The best I have is to start being
> more careful about all of the arguments and actually formalize the list
> of things that we need to succeed in an allocation in a struct
> alloc_args or something.

Sounds like a separate project to me :)

> >  #define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
> >  #define alloc_page_vma(gfp_mask, vma, addr)\
> > diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> > index f2b4abbca55e..fede9bfa89d9 100644
> > --- a/include/linux/migrate.h
> > +++ b/include/linux/migrate.h
> > @@ -38,9 +38,15 @@ static inline struct page *new_page_nodemask(struct page 
> > *page,
> > unsigned int order = 0;
> > struct page *new_page = NULL;
> >  
> > -   if (PageHuge(page))
> > +   if (PageHuge(page)) {
> > +   /*
> > +* HugeTLB doesn't support encryption. We shouldn't see
> > +* such pages.
> > +*/
> > +   WARN_ON(page_keyid(page));
> > return 
> > alloc_huge_page_nodemask(page_hstate(compound_head(page)),
> > preferred_nid, nodemask);
> > +   }
> 
> Shouldn't we be returning NULL?  Seems like failing the allocation is
> much less likely to result in bad things happening.

Okay.

> > if (PageTransHuge(page)) {
> > gfp_mask |= GFP_TRANSHUGE;
> > @@ -50,8 +56,8 @@ static inline struct page *new_page_nodemask(struct page 
> > *page,
> > if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE))
> > gfp_mask |= __GFP_HIGHMEM;
> >  
> > -   new_page = __alloc_pages_nodemask(gfp_mask, order,
> > -   preferred_nid, nodemask);
> > +   new_page = __alloc_pages_nodemask_keyid(gfp_mask, order,
> > +   preferred_nid, nodemask, page_keyid(page));
> 
> Needs a comment please.  It's totally non-obvious that this is the
> migration case from the context, new_page_nodemask()'s name, or the name
> of 'page'.
> 
>   /* Allocate a page with the same KeyID as the source page */

Sure.

> 
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index faca45ebe62d..fd51aa32ad96 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -1187,6 +1187,7 @@ static struct page *compaction_alloc(struct page 
> > *migratepage,
> > list_del(&freepage->lru);
> > cc->nr_freepages--;
> >  
> > +   prep_encrypted_page(freepage, 0, page_keyid(migratepage), false);
> > return freepage;
> >  }
> 
> Comments, please.
> 
> Why is this here?

/* Prepare the page using the same KeyID as the source page */

> What other code might need prep_encrypted_page()?

Custom pages allocators if these pages can end up in encrypted VMAs.

It this case compaction creates own pool of pages to be used for
allocation during page migration.

> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> > index 581b729e05a0..ce7b436444b5 100644
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -921,22 +921,28 @@ static void migrate_page_add(struct page *page, 
> > struct list_head *pagelist,
> >  /* page alloc

[PATCH] ARM: dts: imx7d: remove "operating-points" property for cpu1

2018-07-19 Thread Anson Huang
Commit b97872d4eb22 ("ARM: dts: imx: Add missing OPP properties for CPUs")
added "operating-points" property for all CPUs, but i.MX7D already has
"operating-points-v2" property on both CPUs, so no need to add
"operating-points" property again, this patch removes it.

Fixes: b97872d4eb22 ("ARM: dts: imx: Add missing OPP properties for CPUs")
Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx7d.dtsi | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 9a772fc..7cbc2ff 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -18,11 +18,6 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
-   operating-points = <
-   /* KHz  uV */
-   996000  1075000
-   792000  975000
-   >;
clock-frequency = <99600>;
operating-points-v2 = <&cpu0_opp_table>;
};
-- 
2.7.4



RE: [PATCH] ARM: dts: imx7d: add missing OPP property for cpu0

2018-07-19 Thread Anson Huang
Hi, Shawn

Anson Huang
Best Regards!


> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Thursday, July 19, 2018 11:20 AM
> To: Anson Huang ; Viresh Kumar
> 
> Cc: s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx 
> Subject: Re: [PATCH] ARM: dts: imx7d: add missing OPP property for cpu0
> 
> On Wed, Jul 18, 2018 at 02:54:49PM +0800, Anson Huang wrote:
> > Commit b97872d4eb22 ("ARM: dts: imx: Add missing OPP properties for
> > CPUs") added "operating-points" property for all CPUs, but missed
> > i.MX7D's cpu0, this patch adds it.
> >
> > Fixes: b97872d4eb22 ("ARM: dts: imx: Add missing OPP properties for
> > CPUs")
> > Signed-off-by: Anson Huang 
> 
> In general, when you send a patch fixing a commit, you should have the author
> of that commit copied.  I added Viresh here.

Thanks, I missed it.

> 
> It looks like a wrong fix to me.  It seems that commit b97872d4eb22 shouldn't
> change imx7d.dtsi at all.  So the correct fix would be reverting the change on
> imx7d.dtsi, @Viresh?

Agreed, I think the arch/arm/boot/dts/imx7d.dtsi should NOT be changed, as it 
already
had operating-points-v2 on both CPUs, I sent out another new patch with correct 
fix,
please review it.

Thanks.

Anson.


> 
> Shawn
> 
> > ---
> >  arch/arm/boot/dts/imx7d.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7d.dtsi
> > b/arch/arm/boot/dts/imx7d.dtsi index 9a772fc..30a1a73 100644
> > --- a/arch/arm/boot/dts/imx7d.dtsi
> > +++ b/arch/arm/boot/dts/imx7d.dtsi
> > @@ -9,6 +9,11 @@
> >  / {
> > cpus {
> > cpu0: cpu@0 {
> > +   operating-points = <
> > +   /* KHz  uV */
> > +   996000  1075000
> > +   792000  975000
> > +   >;
> > clock-frequency = <99600>;
> > operating-points-v2 = <&cpu0_opp_table>;
> > #cooling-cells = <2>;
> > --
> > 2.7.4
> >


Re: [PATCH 1/3] clk: meson: clk-pll: add enable bit

2018-07-19 Thread Neil Armstrong
On 17/07/2018 11:56, Jerome Brunet wrote:
> Add the enable the bit of the pll clocks.
> These pll clocks may be disabled but we can't model this as an external
> gate since the pll needs to lock when enabled.
> 
> Signed-off-by: Jerome Brunet 
> ---
>  drivers/clk/meson/axg.c | 28 ---
>  drivers/clk/meson/clk-pll.c | 47 
> -
>  drivers/clk/meson/clkc.h|  1 +
>  drivers/clk/meson/gxbb.c| 32 --
>  drivers/clk/meson/meson8b.c | 15 +++
>  5 files changed, 113 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 00ce62ad6416..6d8976554656 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -24,6 +24,11 @@ static DEFINE_SPINLOCK(meson_clk_lock);
>  
>  static struct clk_regmap axg_fixed_pll = {
>   .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_MPLL_CNTL,
> + .shift   = 30,
> + .width   = 1,
> + },
>   .m = {
>   .reg_off = HHI_MPLL_CNTL,
>   .shift   = 0,
> @@ -65,6 +70,11 @@ static struct clk_regmap axg_fixed_pll = {
>  
>  static struct clk_regmap axg_sys_pll = {
>   .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_SYS_PLL_CNTL,
> + .shift   = 30,
> + .width   = 1,
> + },
>   .m = {
>   .reg_off = HHI_SYS_PLL_CNTL,
>   .shift   = 0,
> @@ -197,11 +207,15 @@ static const struct reg_sequence axg_gp0_init_regs[] = {
>   { .reg = HHI_GP0_PLL_CNTL3, .def = 0x0a59a288 },
>   { .reg = HHI_GP0_PLL_CNTL4, .def = 0xc04d },
>   { .reg = HHI_GP0_PLL_CNTL5, .def = 0x00078000 },
> - { .reg = HHI_GP0_PLL_CNTL,  .def = 0x40010250 },
>  };
>  
>  static struct clk_regmap axg_gp0_pll = {
>   .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_GP0_PLL_CNTL,
> + .shift   = 30,
> + .width   = 1,
> + },
>   .m = {
>   .reg_off = HHI_GP0_PLL_CNTL,
>   .shift   = 0,
> @@ -250,11 +264,15 @@ static const struct reg_sequence axg_hifi_init_regs[] = 
> {
>   { .reg = HHI_HIFI_PLL_CNTL3,.def = 0x0a6a3a88 },
>   { .reg = HHI_HIFI_PLL_CNTL4,.def = 0xc04d },
>   { .reg = HHI_HIFI_PLL_CNTL5,.def = 0x00058000 },
> - { .reg = HHI_HIFI_PLL_CNTL, .def = 0x40010250 },
>  };
>  
>  static struct clk_regmap axg_hifi_pll = {
>   .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_HIFI_PLL_CNTL,
> + .shift   = 30,
> + .width   = 1,
> + },
>   .m = {
>   .reg_off = HHI_HIFI_PLL_CNTL,
>   .shift   = 0,
> @@ -637,7 +655,6 @@ static const struct pll_rate_table 
> axg_pcie_pll_rate_table[] = {
>  };
>  
>  static const struct reg_sequence axg_pcie_init_regs[] = {
> - { .reg = HHI_PCIE_PLL_CNTL, .def = 0x400106c8 },
>   { .reg = HHI_PCIE_PLL_CNTL1,.def = 0x0084a2aa },
>   { .reg = HHI_PCIE_PLL_CNTL2,.def = 0xb75020be },
>   { .reg = HHI_PCIE_PLL_CNTL3,.def = 0x0a47488e },
> @@ -648,6 +665,11 @@ static const struct reg_sequence axg_pcie_init_regs[] = {
>  
>  static struct clk_regmap axg_pcie_pll = {
>   .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_PCIE_PLL_CNTL,
> + .shift   = 30,
> + .width   = 1,
> + },
>   .m = {
>   .reg_off = HHI_PCIE_PLL_CNTL,
>   .shift   = 0,
> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> index 3e04617ac47f..8aaefe67025f 100644
> --- a/drivers/clk/meson/clk-pll.c
> +++ b/drivers/clk/meson/clk-pll.c
> @@ -185,12 +185,45 @@ static void meson_clk_pll_init(struct clk_hw *hw)
>   }
>  }
>  
> +static int meson_clk_pll_enable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
> +
> + /* Make sure the pll is in reset */
> + meson_parm_write(clk->map, &pll->rst, 1);
> +
> + /* Enable the pll */
> + meson_parm_write(clk->map, &pll->en, 1);
> +
> + /* Take the pll out reset */
> + meson_parm_write(clk->map, &pll->rst, 0);
> +
> + if (meson_clk_pll_wait_lock(hw))
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static void meson_clk_pll_disable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
> +
> + /* Put

[PATCH v14 01/12] PCI: dwc: Fix EP link notification implementation

2018-07-19 Thread Gustavo Pimentel
Move specific features settings from EP shared code
(pcie-designware-ep.c) to the driver (pcie-designware-plat.c).

Previous implementation disables the EP link notification
by default for all SoCs that uses EP DesignWare IP, which affects
directly the dra7xx and artpec6 SoCs.

Signed-off-by: Gustavo Pimentel 
Acked-by: Kishon Vijay Abraham I 
---
Change v8->v9:
 - Created patch file.
Change v9->v10:
 - Nothing changed, just to follow the patch set version.
Change v10->v11:
 - Missed Kishon acknowledge.
Change v11->v12:
 - Nothing changed, just to follow the patch set version.
Change v12->v13:
 - Re-sending the patch series.
Change v13->v14:
 - Nothing changed, just to follow the patch set version.

 drivers/pci/controller/dwc/pcie-designware-ep.c   | 14 ++
 drivers/pci/controller/dwc/pcie-designware-plat.c |  3 +++
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 8650416..04092a7 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -386,15 +386,18 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
return -ENOMEM;
ep->outbound_addr = addr;
 
-   if (ep->ops->ep_init)
-   ep->ops->ep_init(ep);
-
epc = devm_pci_epc_create(dev, &epc_ops);
if (IS_ERR(epc)) {
dev_err(dev, "Failed to create epc device\n");
return PTR_ERR(epc);
}
 
+   ep->epc = epc;
+   epc_set_drvdata(epc, ep);
+
+   if (ep->ops->ep_init)
+   ep->ops->ep_init(ep);
+
ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
if (ret < 0)
epc->max_functions = 1;
@@ -413,11 +416,6 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
return -ENOMEM;
}
 
-   epc->features = EPC_FEATURE_NO_LINKUP_NOTIFIER;
-   EPC_FEATURE_SET_BAR(epc->features, BAR_0);
-
-   ep->epc = epc;
-   epc_set_drvdata(epc, ep);
dw_pcie_setup(pci);
 
return 0;
diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c 
b/drivers/pci/controller/dwc/pcie-designware-plat.c
index 5937fed..0ce3440 100644
--- a/drivers/pci/controller/dwc/pcie-designware-plat.c
+++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
@@ -70,10 +70,13 @@ static const struct dw_pcie_ops dw_pcie_ops = {
 static void dw_plat_pcie_ep_init(struct dw_pcie_ep *ep)
 {
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+   struct pci_epc *epc = ep->epc;
enum pci_barno bar;
 
for (bar = BAR_0; bar <= BAR_5; bar++)
dw_pcie_ep_reset_bar(pci, bar);
+
+   epc->features |= EPC_FEATURE_NO_LINKUP_NOTIFIER;
 }
 
 static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
-- 
2.7.4



[PATCH v14 07/12] pci-epf-test/pci_endpoint_test: Cleanup PCI_ENDPOINT_TEST memspace

2018-07-19 Thread Gustavo Pimentel
Cleanup PCI_ENDPOINT_TEST memspace (by moving the interrupt number away
from command section).

Add IRQ_TYPE register to identify the triggered ID interrupt required
for the READ/WRITE/COPY tests and raise IRQ test commands.

Update documentation accordingly.

Signed-off-by: Gustavo Pimentel 
Acked-by: Kishon Vijay Abraham I 
---
Change v2->v3:
 - New patch file created base on the previous patch
"misc: pci_endpoint_test: Add MSI-X support" patch file following
Kishon's suggestion.
Change v3->v4:
 - Rebased to Lorenzo's master branch v4.18-rc1.
Change v4->v5:
 - Reverted irq_num rename to msi_num.
 - Added comment about the MSI-X bit reservation for future implementation.
Change v5->v6:
 - Nothing changed, just to follow the patch set version.
Change v6->v7:
 - Updated documentation.
Change v7->v8:
 - Re-sending the patch series.
Change v8->v9:
 - Nothing changed, just to follow the patch set version.
Change v9->v10:
 - Update documentation and patch description.
Change v10->v11:
 - Nothing changed, just to follow the patch set version.
Change v11->v12:
 - Nothing changed, just to follow the patch set version.
Change v12->v13:
 - Re-sending the patch series.
Change v13->v14:
 - Change variable type from u16 to int.

 Documentation/PCI/endpoint/pci-test-function.txt |  8 +--
 Documentation/PCI/endpoint/pci-test-function.txt | 27 ++--
 drivers/misc/pci_endpoint_test.c | 81 +++-
 drivers/pci/endpoint/functions/pci-epf-test.c| 61 --
 3 files changed, 114 insertions(+), 55 deletions(-)

diff --git a/Documentation/PCI/endpoint/pci-test-function.txt 
b/Documentation/PCI/endpoint/pci-test-function.txt
index 0c519c9..bf4b5cf 100644
--- a/Documentation/PCI/endpoint/pci-test-function.txt
+++ b/Documentation/PCI/endpoint/pci-test-function.txt
@@ -20,6 +20,8 @@ The PCI endpoint test device has the following registers:
5) PCI_ENDPOINT_TEST_DST_ADDR
6) PCI_ENDPOINT_TEST_SIZE
7) PCI_ENDPOINT_TEST_CHECKSUM
+   8) PCI_ENDPOINT_TEST_IRQ_TYPE
+   9) PCI_ENDPOINT_TEST_IRQ_NUMBER
 
 *) PCI_ENDPOINT_TEST_MAGIC
 
@@ -34,10 +36,10 @@ that the endpoint device must perform.
 Bitfield Description:
   Bit 0: raise legacy IRQ
   Bit 1: raise MSI IRQ
-  Bit 2 - 7: MSI interrupt number
-  Bit 8: read command (read data from RC buffer)
-  Bit 9: write command (write data to RC buffer)
-  Bit 10   : copy command (copy data from one RC buffer to another
+  Bit 2: raise MSI-X IRQ (reserved for future implementation)
+  Bit 3: read command (read data from RC buffer)
+  Bit 4: write command (write data to RC buffer)
+  Bit 5: copy command (copy data from one RC buffer to another
  RC buffer)
 
 *) PCI_ENDPOINT_TEST_STATUS
@@ -64,3 +66,20 @@ COPY/READ command.
 
 This register contains the destination address (RC buffer address) for
 the COPY/WRITE command.
+
+*) PCI_ENDPOINT_TEST_IRQ_TYPE
+
+This register contains the interrupt type (Legacy/MSI) triggered
+for the READ/WRITE/COPY and raise IRQ (Legacy/MSI) commands.
+
+Possible types:
+ - Legacy  : 0
+ - MSI : 1
+
+*) PCI_ENDPOINT_TEST_IRQ_NUMBER
+
+This register contains the triggered ID interrupt.
+
+Admissible values:
+ - Legacy  : 0
+ - MSI : [1 .. 32]
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 7b37046..35fbfbd 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -35,38 +35,43 @@
 
 #include 
 
-#define DRV_MODULE_NAME"pci-endpoint-test"
-
-#define PCI_ENDPOINT_TEST_MAGIC0x0
-
-#define PCI_ENDPOINT_TEST_COMMAND  0x4
-#define COMMAND_RAISE_LEGACY_IRQ   BIT(0)
-#define COMMAND_RAISE_MSI_IRQ  BIT(1)
-#define MSI_NUMBER_SHIFT   2
-/* 6 bits for MSI number */
-#define COMMAND_READBIT(8)
-#define COMMAND_WRITE   BIT(9)
-#define COMMAND_COPYBIT(10)
-
-#define PCI_ENDPOINT_TEST_STATUS   0x8
-#define STATUS_READ_SUCCESS BIT(0)
-#define STATUS_READ_FAILBIT(1)
-#define STATUS_WRITE_SUCCESSBIT(2)
-#define STATUS_WRITE_FAIL   BIT(3)
-#define STATUS_COPY_SUCCESS BIT(4)
-#define STATUS_COPY_FAILBIT(5)
-#define STATUS_IRQ_RAISED   BIT(6)
-#define STATUS_SRC_ADDR_INVALID BIT(7)
-#define STATUS_DST_ADDR_INVALID BIT(8)
-
-#define PCI_ENDPOINT_TEST_LOWER_SRC_ADDR   0xc
+#define DRV_MODULE_NAME"pci-endpoint-test"
+
+#define IRQ_TYPE_LEGACY0
+#define IRQ_TYPE_MSI   1
+
+#define PCI_ENDPOINT_TEST_MAGIC0x0
+
+#define PCI_ENDPOINT_TEST_COMMAND  0x4
+#define COMMAND_RAISE_LEGACY_IRQ   BIT(0)
+#define COMMA

[PATCH v14 09/12] pci-epf-test/pci_endpoint_test: Add MSI-X support

2018-07-19 Thread Gustavo Pimentel
Add MSI-X support and update driver documentation accordingly.

Signed-off-by: Gustavo Pimentel 
Acked-by: Kishon Vijay Abraham I 
---
Change v2->v3:
 - New patch file created base on the previous patch
"misc: pci_endpoint_test: Add MSI-X support" patch file following
Kishon's suggestion.
Change v3->v4:
 - Rebased to Lorenzo's master branch v4.18-rc1.
Change v4->v5:
 - Nothing changed, just to follow the patch set version.
Change v5->v6:
 - Moved PCITEST_MSIX ioctl entry from patch #10 to here.
 - Documented ioctl parameter type associated to
drivers/misc/pci_endpoint_test.c driver.
Change v6->v7:
 - Updated documentation.
 - Added flag that enables or not the MSI-X on the EP features. 
Change v7->v8:
 - Re-sending the patch series.
Change v8->v9:
 - Moving the EPC_FEATURE_MSIX_AVAILABLE feature set from the
dw_pcie_ep_init() to dw_plat_pcie_ep_init().
Change v9->v10:
 - Update documentation.
Change v10->v11:
 - Nothing changed, just to follow the patch set version.
Change v11->v12:
 - Nothing changed, just to follow the patch set version.
Change v12->v13:
 - Re-sending the patch series.
Change v13->v14:
 - Nothing changed, just to follow the patch set version.

 Documentation/PCI/endpoint/pci-test-function.txt  |  2 +-
 Documentation/PCI/endpoint/pci-endpoint.txt   |  4 ++--
 Documentation/PCI/endpoint/pci-test-function.txt  |  4 +++-
 Documentation/PCI/endpoint/pci-test-howto.txt | 22 ++---
 Documentation/ioctl/ioctl-number.txt  |  1 +
 Documentation/misc-devices/pci-endpoint-test.txt  |  3 +++
 drivers/misc/pci_endpoint_test.c  | 29 ---
 drivers/pci/controller/dwc/pcie-designware-plat.c |  1 +
 drivers/pci/endpoint/functions/pci-epf-test.c | 29 +--
 include/linux/pci-epc.h   |  1 +
 include/uapi/linux/pcitest.h  |  1 +
 10 files changed, 79 insertions(+), 16 deletions(-)

diff --git a/Documentation/PCI/endpoint/pci-endpoint.txt 
b/Documentation/PCI/endpoint/pci-endpoint.txt
index 9b1d668..e86a96b 100644
--- a/Documentation/PCI/endpoint/pci-endpoint.txt
+++ b/Documentation/PCI/endpoint/pci-endpoint.txt
@@ -44,7 +44,7 @@ by the PCI controller driver.
 * clear_bar: ops to reset the BAR
 * alloc_addr_space: ops to allocate in PCI controller address space
 * free_addr_space: ops to free the allocated address space
-* raise_irq: ops to raise a legacy or MSI interrupt
+* raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
 * start: ops to start the PCI link
 * stop: ops to stop the PCI link
 
@@ -96,7 +96,7 @@ by the PCI endpoint function driver.
 *) pci_epc_raise_irq()
 
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
-   Legacy Interrupt or MSI Interrupt.
+   Legacy Interrupt, MSI or MSI-X Interrupt.
 
 *) pci_epc_mem_alloc_addr()
 
diff --git a/Documentation/PCI/endpoint/pci-test-function.txt 
b/Documentation/PCI/endpoint/pci-test-function.txt
index bf4b5cf..5916f1f 100644
--- a/Documentation/PCI/endpoint/pci-test-function.txt
+++ b/Documentation/PCI/endpoint/pci-test-function.txt
@@ -36,7 +36,7 @@ that the endpoint device must perform.
 Bitfield Description:
   Bit 0: raise legacy IRQ
   Bit 1: raise MSI IRQ
-  Bit 2: raise MSI-X IRQ (reserved for future implementation)
+  Bit 2: raise MSI-X IRQ
   Bit 3: read command (read data from RC buffer)
   Bit 4: write command (write data to RC buffer)
   Bit 5: copy command (copy data from one RC buffer to another
@@ -75,6 +75,7 @@ for the READ/WRITE/COPY and raise IRQ (Legacy/MSI) commands.
 Possible types:
  - Legacy  : 0
  - MSI : 1
+ - MSI-X   : 2
 
 *) PCI_ENDPOINT_TEST_IRQ_NUMBER
 
@@ -83,3 +84,4 @@ This register contains the triggered ID interrupt.
 Admissible values:
  - Legacy  : 0
  - MSI : [1 .. 32]
+ - MSI-X   : [1 .. 2048]
diff --git a/Documentation/PCI/endpoint/pci-test-howto.txt 
b/Documentation/PCI/endpoint/pci-test-howto.txt
index 75f48c3..65f1a13 100644
--- a/Documentation/PCI/endpoint/pci-test-howto.txt
+++ b/Documentation/PCI/endpoint/pci-test-howto.txt
@@ -45,9 +45,9 @@ The PCI endpoint framework populates the directory with the 
following
 configurable fields.
 
# ls functions/pci_epf_test/func1
- baseclass_codeinterrupt_pin   revid   subsys_vendor_id
- cache_line_size   msi_interrupts  subclass_code   vendorid
- deviceid  progif_code subsys_id
+ baseclass_codeinterrupt_pin   progif_code subsys_id
+ cache_line_size   msi_interrupts  revid   subsys_vendorid
+ deviceid  msix_interrupts subclass_code   vendorid
 
 The PCI endpoint function driver populates these entries with default values
 when the device is bound to the driver. The pci-epf-test driver pop

[PATCH v14 03/12] PCI: Update xxx_pcie_ep_raise_irq() and pci_epc_raise_irq() signatures

2018-07-19 Thread Gustavo Pimentel
Change {cdns, dra7xx, artpec6, dw, rockchip}_pcie_ep_raise_irq() and
pci_epc_raise_irq() signature, namely the interrupt_num variable type
from u8 to u16 to accommodate 2048 maximum MSI-X interrupts.

Signed-off-by: Gustavo Pimentel 
Acked-by: Alan Douglas 
Acked-by: Shawn Lin 
Acked-by: Jesper Nilsson 
Acked-by: Joao Pinto 
Acked-by: Kishon Vijay Abraham I 
---
Change v1->v2:
 - Nothing changed, just to follow the patch set version.
Change v2->v3:
 - Move into here the pci_epc_raise_irq() signature change from patch
file #1.
 - Move into here the {dra7xx, artpec6}_pcie_ep_raise_irq() signature
changes from patch file #2.
Change v3->v4:
 - Rebased to Lorenzo's master branch v4.18-rc1.
Change v4->v5:
 - Swap patch files position (#3 -> #2).
 - Moved dw_pcie_ep_raise_irq and dw_plat_pcie_ep_raise_irq functions
signatures changes from patch file #3.
 - Changed rockchip_pcie_ep_raise_irq function signature.
Change v5->v6:
 - Nothing changed, just to follow the patch set version.
Change v6->v7:
 - Nothing changed, just to follow the patch set version.
Change v7->v8:
 - Re-sending the patch series.
Change v8->v9:
 - Nothing changed, just to follow the patch set version.
Change v9->v10:
 - Nothing changed, just to follow the patch set version.
Change v10->v11:
 - Nothing changed, just to follow the patch set version.
Change v11->v12:
 - Nothing changed, just to follow the patch set version.
Change v12->v13:
 - Re-sending the patch series.
Change v13->v14:
 - Nothing changed, just to follow the patch set version.

 drivers/pci/controller/dwc/pci-dra7xx.c   | 2 +-
 drivers/pci/controller/dwc/pcie-artpec6.c | 2 +-
 drivers/pci/controller/dwc/pcie-designware-ep.c   | 2 +-
 drivers/pci/controller/dwc/pcie-designware-plat.c | 2 +-
 drivers/pci/controller/dwc/pcie-designware.h  | 2 +-
 drivers/pci/controller/pcie-cadence-ep.c  | 3 ++-
 drivers/pci/controller/pcie-rockchip-ep.c | 2 +-
 drivers/pci/endpoint/pci-epc-core.c   | 8 
 include/linux/pci-epc.h   | 6 +++---
 9 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c 
b/drivers/pci/controller/dwc/pci-dra7xx.c
index 345aab5..ce9224a 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -370,7 +370,7 @@ static void dra7xx_pcie_raise_msi_irq(struct dra7xx_pcie 
*dra7xx,
 }
 
 static int dra7xx_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
-enum pci_epc_irq_type type, u8 interrupt_num)
+enum pci_epc_irq_type type, u16 interrupt_num)
 {
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c 
b/drivers/pci/controller/dwc/pcie-artpec6.c
index 321b56c..9a2474b 100644
--- a/drivers/pci/controller/dwc/pcie-artpec6.c
+++ b/drivers/pci/controller/dwc/pcie-artpec6.c
@@ -428,7 +428,7 @@ static void artpec6_pcie_ep_init(struct dw_pcie_ep *ep)
 }
 
 static int artpec6_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
- enum pci_epc_irq_type type, u8 interrupt_num)
+ enum pci_epc_irq_type type, u16 interrupt_num)
 {
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
 
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 04092a7..69d039d 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -242,7 +242,7 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 
func_no, u8 encode_int)
 }
 
 static int dw_pcie_ep_raise_irq(struct pci_epc *epc, u8 func_no,
-   enum pci_epc_irq_type type, u8 interrupt_num)
+   enum pci_epc_irq_type type, u16 interrupt_num)
 {
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
 
diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c 
b/drivers/pci/controller/dwc/pcie-designware-plat.c
index 0ce3440..0efb318 100644
--- a/drivers/pci/controller/dwc/pcie-designware-plat.c
+++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
@@ -81,7 +81,7 @@ static void dw_plat_pcie_ep_init(struct dw_pcie_ep *ep)
 
 static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
 enum pci_epc_irq_type type,
-u8 interrupt_num)
+u16 interrupt_num)
 {
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index bee4e25..9d581c0 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -191,7 +191,7 @@ enum dw_pcie_as_type {
 struct dw_pcie_ep_ops {
void(*ep_init)(struct dw_pcie_ep *e

[PATCH v14 04/12] PCI: dwc: Add MSI-X callbacks handler

2018-07-19 Thread Gustavo Pimentel
Add PCIe config space capability search function.

Add sysfs set/get interface to allow the change of EP MSI-X maximum number.

Add EP MSI-X callback for triggering interruptions.

Signed-off-by: Gustavo Pimentel 
Acked-by: Kishon Vijay Abraham I 
---
Change v1->v2:
 - Nothing changed, just to follow the patch set version.
Change v2->v3:
 - Moved dra7xx_pcie_raise_irq() signature change to patch file #3.
 - Moved artpec6_pcie_raise_irq() signature change to patch file #3.
 - Replaced wrong return value 0 to -EINVAL.
 - Removed an else if by code refactoring.
 - Reduced the size of ioremap_nocache mapping from ep->addr_size to
PCI_MSIX_ENTRY_SIZE.
 - Fixed a small bug. If the MSI-X vector bit has been set, the function
would return without executing the proper unmap.
Change v3->v4:
 - Rebased to Lorenzo's master branch v4.18-rc1.
 - Added static prefix to __dw_pcie_ep_find_next_cap function.
Change v4->v5:
 - Added static prefix to dw_pcie_ep_find_capability function.
 - Swap patch files position (#2 <-> #3).
 - Moved dw_pcie_ep_raise_irq and dw_plat_pcie_ep_raise_irq functions
signatures change to patch file #2.
Change v5->v6:
 - Nothing changed, just to follow the patch set version.
Change v6->v7:
 - Nothing changed, just to follow the patch set version.
Change v7->v8:
 - Re-sending the patch series.
Change v8->v9:
 - Nothing changed, just to follow the patch set version.
Change v9->v10:
 - Reuse of msix_mem and msi_mem_phys variables.
Change v10->v11:
 - Nothing changed, just to follow the patch set version.
Change v11->v12:
 - Nothing changed, just to follow the patch set version.
Change v12->v13:
 - Re-sending the patch series.
Change v13->v14:
 - Nothing changed, just to follow the patch set version.

 drivers/pci/controller/dwc/pcie-designware-ep.c   | 137 +-
 drivers/pci/controller/dwc/pcie-designware-plat.c |   2 +
 drivers/pci/controller/dwc/pcie-designware.h  |  10 ++
 3 files changed, 148 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 69d039d..23be2c0 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -40,6 +40,39 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum 
pci_barno bar)
__dw_pcie_ep_reset_bar(pci, bar, 0);
 }
 
+static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie *pci, u8 cap_ptr,
+ u8 cap)
+{
+   u8 cap_id, next_cap_ptr;
+   u16 reg;
+
+   reg = dw_pcie_readw_dbi(pci, cap_ptr);
+   next_cap_ptr = (reg & 0xff00) >> 8;
+   cap_id = (reg & 0x00ff);
+
+   if (!next_cap_ptr || cap_id > PCI_CAP_ID_MAX)
+   return 0;
+
+   if (cap_id == cap)
+   return cap_ptr;
+
+   return __dw_pcie_ep_find_next_cap(pci, next_cap_ptr, cap);
+}
+
+static u8 dw_pcie_ep_find_capability(struct dw_pcie *pci, u8 cap)
+{
+   u8 next_cap_ptr;
+   u16 reg;
+
+   reg = dw_pcie_readw_dbi(pci, PCI_CAPABILITY_LIST);
+   next_cap_ptr = (reg & 0x00ff);
+
+   if (!next_cap_ptr)
+   return 0;
+
+   return __dw_pcie_ep_find_next_cap(pci, next_cap_ptr, cap);
+}
+
 static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
   struct pci_epf_header *hdr)
 {
@@ -241,6 +274,45 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 
func_no, u8 encode_int)
return 0;
 }
 
+static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
+{
+   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+   u32 val, reg;
+
+   if (!ep->msix_cap)
+   return -EINVAL;
+
+   reg = ep->msix_cap + PCI_MSIX_FLAGS;
+   val = dw_pcie_readw_dbi(pci, reg);
+   if (!(val & PCI_MSIX_FLAGS_ENABLE))
+   return -EINVAL;
+
+   val &= PCI_MSIX_FLAGS_QSIZE;
+
+   return val;
+}
+
+static int dw_pcie_ep_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts)
+{
+   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+   u32 val, reg;
+
+   if (!ep->msix_cap)
+   return -EINVAL;
+
+   reg = ep->msix_cap + PCI_MSIX_FLAGS;
+   val = dw_pcie_readw_dbi(pci, reg);
+   val &= ~PCI_MSIX_FLAGS_QSIZE;
+   val |= interrupts;
+   dw_pcie_dbi_ro_wr_en(pci);
+   dw_pcie_writew_dbi(pci, reg, val);
+   dw_pcie_dbi_ro_wr_dis(pci);
+
+   return 0;
+}
+
 static int dw_pcie_ep_raise_irq(struct pci_epc *epc, u8 func_no,
enum pci_epc_irq_type type, u16 interrupt_num)
 {
@@ -282,6 +354,8 @@ static const struct pci_epc_ops epc_ops = {
.unmap_addr = dw_pcie_ep_unmap_addr,
.set_msi= dw_pcie_ep_set_msi,
.get_msi= dw_pcie_ep_get_msi,
+   .set_msix   = dw_pcie_ep_set_msix,
+   .get_msix

Re: [PATCH v3 3/7] mm, slab: allocate off-slab freelists as reclaimable when appropriate

2018-07-19 Thread Mel Gorman
On Wed, Jul 18, 2018 at 03:36:16PM +0200, Vlastimil Babka wrote:
> In SLAB, OFF_SLAB caches allocate management structures (currently just the
> freelist) from kmalloc caches when placement in a slab page together with
> objects would lead to suboptimal memory usage. For SLAB_RECLAIM_ACCOUNT 
> caches,
> we can allocate the freelists from the newly introduced reclaimable kmalloc
> caches, because shrinking the OFF_SLAB cache will in general result to freeing
> of the freelists as well. This should improve accounting and 
> anti-fragmentation
> a bit.
> 
> Signed-off-by: Vlastimil Babka 

I'm not quite convinced by this one. The freelist cache is tied to the
lifetime of the slab and not the objects. A single freelist can be reclaimed
eventually but for caches with many objects per slab, it could take a lot
of shrinking random objects to reclaim one freelist. Functionally the
patch appears to be fine.

-- 
Mel Gorman
SUSE Labs


[RFC PATCH] mtd: nand: toshiba: Add support for ->exec_op()

2018-07-19 Thread KOBAYASHI Yoshitake
This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND
memory devices.  This use vendor specific command
(TOSHIBA_NAND_CMD_ECC_STATUS) to know the exact bitflips.  However, I
could not test this patch because I do not have a platform that
supports chip-> exec_op.  Therefore, I post this patch as RFC.

As soon as I get a platform that supports chip-> exec_op, I would like
to test and re-post.

Signed-off-by: KOBAYASHI Yoshitake 
---
 drivers/mtd/nand/raw/nand_toshiba.c | 76 +
 1 file changed, 61 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_toshiba.c 
b/drivers/mtd/nand/raw/nand_toshiba.c
index 6cec923..12218cd 100644
--- a/drivers/mtd/nand/raw/nand_toshiba.c
+++ b/drivers/mtd/nand/raw/nand_toshiba.c
@@ -17,28 +17,74 @@
 
 #include 
 
+/* ECC Status Read Command for BENAND */
+#define TOSHIBA_NAND_CMD_ECC_STATUS_READ   0x7A
+
+/* ECC Status Mask for BENAND */
+#define TOSHIBA_NAND_ECC_STATUS_MASK   0x0F
+
 /* Recommended to rewrite for BENAND */
 #define TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDEDBIT(3)
 
+static int toshiba_nand_benand_read_eccstatus_op(struct nand_chip *chip,
+u8 *buf)
+{
+   u8 *ecc_status = buf;
+
+   const struct nand_sdr_timings *sdr =
+   nand_get_sdr_timings(&chip->data_interface);
+   struct nand_op_instr instrs[] = {
+   NAND_OP_CMD(TOSHIBA_NAND_CMD_ECC_STATUS_READ,
+   PSEC_TO_NSEC(sdr->tADL_min)),
+   NAND_OP_8BIT_DATA_IN(chip->ecc.steps, ecc_status, 0),
+   };
+   struct nand_operation op = NAND_OPERATION(instrs);
+
+   /* Drop the DATA_IN instruction if chip->ecc.steps is set to 0. */
+   if (!chip->ecc.steps)
+   op.ninstrs--;
+
+   return nand_exec_op(chip, &op);
+}
+
 static int toshiba_nand_benand_eccstatus(struct mtd_info *mtd,
 struct nand_chip *chip)
 {
-   int ret;
+   int ret, i;
unsigned int max_bitflips = 0;
-   u8 status;
-
-   /* Check Status */
-   ret = nand_status_op(chip, &status);
-   if (ret)
-   return ret;
-
-   if (status & NAND_STATUS_FAIL) {
-   /* uncorrected */
-   mtd->ecc_stats.failed++;
-   } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
-   /* corrected */
-   max_bitflips = mtd->bitflip_threshold;
-   mtd->ecc_stats.corrected += max_bitflips;
+   u8 status, bitflips, ecc_status[8];
+
+   if (chip->exec_op) {
+   /* Check ECC Status */
+   ret = toshiba_nand_benand_read_eccstatus_op(chip, ecc_status);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < chip->ecc.steps; i++) {
+   bitflips = (ecc_status[i] &
+   TOSHIBA_NAND_ECC_STATUS_MASK);
+   if (bitflips == 0x0F) {
+   mtd->ecc_stats.failed++;
+   } else {
+   mtd->ecc_stats.corrected += bitflips;
+   max_bitflips = max_t(unsigned int,
+max_bitflips, bitflips);
+   }
+   }
+   } else {
+   /* Check Status */
+   ret = nand_status_op(chip, &status);
+   if (ret)
+   return ret;
+
+   if (status & NAND_STATUS_FAIL) {
+   /* uncorrected */
+   mtd->ecc_stats.failed++;
+   } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
+   /* corrected */
+   max_bitflips = mtd->bitflip_threshold;
+   mtd->ecc_stats.corrected += max_bitflips;
+   }
}
 
return max_bitflips;
-- 
2.7.4




[PATCH V3 1/4] X86/Hyper-V: Add flush HvFlushGuestPhysicalAddressSpace hypercall support

2018-07-19 Thread Tianyu Lan
Hyper-V supports a pv hypercall HvFlushGuestPhysicalAddressSpace to
flush nested VM address space mapping in l1 hypervisor and it's to
reduce overhead of flushing ept tlb among vcpus. This patch is to
implement it.

Signed-off-by: Lan Tianyu 
---
 arch/x86/hyperv/Makefile   |  2 +-
 arch/x86/hyperv/nested.c   | 64 ++
 arch/x86/include/asm/hyperv-tlfs.h |  8 +
 arch/x86/include/asm/mshyperv.h|  2 ++
 4 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/hyperv/nested.c

diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index b173d404e3df..b21ee65c4101 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1,2 +1,2 @@
-obj-y  := hv_init.o mmu.o
+obj-y  := hv_init.o mmu.o nested.o
 obj-$(CONFIG_X86_64)   += hv_apic.o
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
new file mode 100644
index ..74dd38b5221d
--- /dev/null
+++ b/arch/x86/hyperv/nested.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Hyper-V nested virtualization code.
+ *
+ * Copyright (C) 2018, Microsoft, Inc.
+ *
+ * Author : Lan Tianyu 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+
+int hyperv_flush_guest_mapping(u64 as)
+{
+   struct hv_guest_mapping_flush **flush_pcpu;
+   struct hv_guest_mapping_flush *flush;
+   u64 status;
+   unsigned long flags;
+   int ret = -EFAULT;
+
+   if (!hv_hypercall_pg)
+   goto fault;
+
+   local_irq_save(flags);
+
+   flush_pcpu = (struct hv_guest_mapping_flush **)
+   this_cpu_ptr(hyperv_pcpu_input_arg);
+
+   flush = *flush_pcpu;
+
+   if (unlikely(!flush)) {
+   local_irq_restore(flags);
+   goto fault;
+   }
+
+   flush->address_space = as;
+   flush->flags = 0;
+
+   status = hv_do_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE,
+flush, NULL);
+   local_irq_restore(flags);
+
+   if (!(status & HV_HYPERCALL_RESULT_MASK))
+   ret = 0;
+
+fault:
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index b8c89265baf0..08e24f552030 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -309,6 +309,7 @@ struct ms_hyperv_tsc_page {
 #define HV_X64_MSR_REENLIGHTENMENT_CONTROL 0x4106
 
 /* Nested features (CPUID 0x400A) EAX */
+#define HV_X64_NESTED_GUEST_MAPPING_FLUSH  BIT(18)
 #define HV_X64_NESTED_MSR_BITMAP   BIT(19)
 
 struct hv_reenlightenment_control {
@@ -350,6 +351,7 @@ struct hv_tsc_emulation_status {
 #define HVCALL_SEND_IPI_EX 0x0015
 #define HVCALL_POST_MESSAGE0x005c
 #define HVCALL_SIGNAL_EVENT0x005d
+#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
 
 #define HV_X64_MSR_VP_ASSIST_PAGE_ENABLE   0x0001
 #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT12
@@ -741,6 +743,12 @@ struct ipi_arg_ex {
struct hv_vpset vp_set;
 };
 
+/* HvFlushGuestPhysicalAddressSpace hypercalls */
+struct hv_guest_mapping_flush {
+   u64 address_space;
+   u64 flags;
+};
+
 /* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
 struct hv_tlb_flush {
u64 address_space;
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 3cd14311edfa..a6a615b49876 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -302,6 +302,7 @@ void hyperv_reenlightenment_intr(struct pt_regs *regs);
 void set_hv_tscchange_cb(void (*cb)(void));
 void clear_hv_tscchange_cb(void);
 void hyperv_stop_tsc_emulation(void);
+int hyperv_flush_guest_mapping(u64 as);
 
 #ifdef CONFIG_X86_64
 void hv_apic_init(void);
@@ -321,6 +322,7 @@ static inline struct hv_vp_assist_page 
*hv_get_vp_assist_page(unsigned int cpu)
 {
return NULL;
 }
+static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
 #endif /* CONFIG_HYPERV */
 
 #ifdef CONFIG_HYPERV_TSCPAGE
-- 
2.14.3


[PATCH V3 2/4] X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace support

2018-07-19 Thread Tianyu Lan
This patch is to add hyperv_nested_flush_guest_mapping support to trace
hvFlushGuestPhysicalAddressSpace hypercall.

Signed-off-by: Lan Tianyu 
---
 arch/x86/hyperv/nested.c|  3 +++
 arch/x86/include/asm/trace/hyperv.h | 14 ++
 2 files changed, 17 insertions(+)

diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index 74dd38b5221d..42a3232f2835 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+#include 
+
 int hyperv_flush_guest_mapping(u64 as)
 {
struct hv_guest_mapping_flush **flush_pcpu;
@@ -59,6 +61,7 @@ int hyperv_flush_guest_mapping(u64 as)
ret = 0;
 
 fault:
+   trace_hyperv_nested_flush_guest_mapping(as, ret);
return ret;
 }
 EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
diff --git a/arch/x86/include/asm/trace/hyperv.h 
b/arch/x86/include/asm/trace/hyperv.h
index 4253bca99989..e1ffe61de8d6 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -28,6 +28,20 @@ TRACE_EVENT(hyperv_mmu_flush_tlb_others,
  __entry->addr, __entry->end)
);
 
+TRACE_EVENT(hyperv_nested_flush_guest_mapping,
+   TP_PROTO(u64 as, int ret),
+   TP_ARGS(as, ret),
+
+   TP_STRUCT__entry(
+   __field(u64, as)
+   __field(int, ret)
+   ),
+   TP_fast_assign(__entry->as = as;
+  __entry->ret = ret;
+   ),
+   TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+   );
+
 #endif /* CONFIG_HYPERV */
 
 #undef TRACE_INCLUDE_PATH
-- 
2.14.3


[PATCH V3 4/4] KVM/x86: Add tlb_remote_flush callback support for vmx

2018-07-19 Thread Tianyu Lan
Register tlb_remote_flush callback for vmx when hyperv capability of
nested guest mapping flush is detected. The interface can help to
reduce overhead when flush ept table among vcpus for nested VM. The
tradition way is to send IPIs to all affected vcpus and executes
INVEPT on each vcpus. It will trigger several vmexits for IPI
and INVEPT emulation. Hyper-V provides such hypercall to do
flush for all vcpus and call the hypercall when all ept table
pointers of single VM are same.

Signed-off-by: Lan Tianyu 
---
Change since v2:
   Make ept_pointers_match as tristate "check", "match" and
"mismatch". Set "check" in vmx_set_cr3(), check all ept table
pointers in hv_remote_flush_tlb() and call hypercall when all
ept pointers are same.

Change since v1:
   Replace identical_ept_pointer with ept_pointers_match and
check kvm_x86_ops->tlb_remote_flush in check_ept_pointer().
---
 arch/x86/kvm/vmx.c | 72 +-
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1689f433f3a0..601ee37937a9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -188,12 +188,21 @@ module_param(ple_window_max, uint, 0444);
 
 extern const ulong vmx_return;
 
+enum ept_pointers_status {
+   EPT_POINTERS_CHECK = 0,
+   EPT_POINTERS_MATCH = 1,
+   EPT_POINTERS_MISMATCH = 2
+};
+
 struct kvm_vmx {
struct kvm kvm;
 
unsigned int tss_addr;
bool ept_identity_pagetable_done;
gpa_t ept_identity_map_addr;
+
+   enum ept_pointers_status ept_pointers_match;
+   spinlock_t ept_pointer_lock;
 };
 
 #define NR_AUTOLOAD_MSRS 8
@@ -853,6 +862,7 @@ struct vcpu_vmx {
 */
u64 msr_ia32_feature_control;
u64 msr_ia32_feature_control_valid_bits;
+   u64 ept_pointer;
 };
 
 enum segment_cache_field {
@@ -4774,6 +4784,48 @@ static inline void __vmx_flush_tlb(struct kvm_vcpu 
*vcpu, int vpid,
}
 }
 
+/* check_ept_pointer() should be under protection of ept_pointer_lock. */
+static void check_ept_pointer(struct kvm *kvm)
+{
+   struct kvm_vcpu *vcpu;
+   u64 tmp_eptp = INVALID_PAGE;
+   int i;
+
+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   if (!VALID_PAGE(tmp_eptp)) {
+   tmp_eptp = to_vmx(vcpu)->ept_pointer;
+   } else if (tmp_eptp != to_vmx(vcpu)->ept_pointer) {
+   to_kvm_vmx(kvm)->ept_pointers_match
+   = EPT_POINTERS_MISMATCH;
+   return;
+   }
+   }
+
+   to_kvm_vmx(kvm)->ept_pointers_match = EPT_POINTERS_MATCH;
+}
+
+static int hv_remote_flush_tlb(struct kvm *kvm)
+{
+   int ret;
+
+   spin_lock(&to_kvm_vmx(kvm)->ept_pointer_lock);
+
+   if (to_kvm_vmx(kvm)->ept_pointers_match == EPT_POINTERS_CHECK)
+   check_ept_pointer(kvm);
+
+   if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   ret = hyperv_flush_guest_mapping(
+   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
+
+out:
+   spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
+   return ret;
+}
+
 static void vmx_flush_tlb(struct kvm_vcpu *vcpu, bool invalidate_gpa)
 {
__vmx_flush_tlb(vcpu, to_vmx(vcpu)->vpid, invalidate_gpa);
@@ -4960,6 +5012,7 @@ static u64 construct_eptp(struct kvm_vcpu *vcpu, unsigned 
long root_hpa)
 
 static void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
 {
+   struct kvm *kvm = vcpu->kvm;
unsigned long guest_cr3;
u64 eptp;
 
@@ -4967,11 +5020,20 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned 
long cr3)
if (enable_ept) {
eptp = construct_eptp(vcpu, cr3);
vmcs_write64(EPT_POINTER, eptp);
+
+   if (kvm_x86_ops->tlb_remote_flush) {
+   spin_lock(&to_kvm_vmx(kvm)->ept_pointer_lock);
+   to_vmx(vcpu)->ept_pointer = eptp;
+   to_kvm_vmx(kvm)->ept_pointers_match
+   = EPT_POINTERS_CHECK;
+   spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
+   }
+
if (enable_unrestricted_guest || is_paging(vcpu) ||
is_guest_mode(vcpu))
guest_cr3 = kvm_read_cr3(vcpu);
else
-   guest_cr3 = 
to_kvm_vmx(vcpu->kvm)->ept_identity_map_addr;
+   guest_cr3 = to_kvm_vmx(kvm)->ept_identity_map_addr;
ept_load_pdptrs(vcpu);
}
 
@@ -7538,6 +7600,12 @@ static __init int hardware_setup(void)
if (enable_ept && !cpu_has_vmx_ept_2m_page())
kvm_disable_largepages();
 
+#if IS_ENABLED(CONFIG_HYPERV)
+   if (ms_hyperv.nested_features & HV_X64_NESTED_GUEST_MAPPING_FLUSH
+   && enable_ept)
+   kvm_x86_ops->tlb_remote_flush = hv_remote_flush_t

Re: [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

2018-07-19 Thread Boris Brezillon
Hi Yixun,

On Thu, 19 Jul 2018 16:13:47 +0800
Yixun Lan  wrote:

> >>> You're doing DMA on those buffers, and devm_kzalloc() is not
> >>> DMA-friendly (returned buffers are not aligned on a cache line). Also,
> >>> you don't have to allocate your own buffers because the core already
> >>> allocate them (chip->data_buf, chip->oob_poi). All you need to do is
> >>> set the NAND_USE_BOUNCE_BUFFER flag in chip->options to make sure
> >>> you're always passed a DMA-able buffer.
> >>> 
> >>
> >> thanks for the suggestion, we've migrated to use the
> >> dmam_alloc_coherent() API  
> > 
> > kzalloc() should be just fine, no need to alloc a DMA coherent region. 
> >   
> 
> we're a little bit confused here, isn't devm_kzalloc (previously we are
> using) a variant of kzalloc? and since the NAND controller is doing DMA
> here, using DMA coherent API is more proper way?

Well, making buffers DMA coherent might be expensive, especially if you
access them a lot (unless you have a coherency unit and the cache is
kept enabled).

Regarding the "why is devm_kzalloc() is not DMA-safe?" question, I'd
recommend that you read this discussion [1].

>  +mtd->name = devm_kasprintf(nfc->dev, GFP_KERNEL,
>  +   "%s:nand", dev_name(dev));
>  +if (!mtd->name) {
>  +dev_err(nfc->dev, "Failed to allocate mtd->name\n");
>  +return -ENOMEM;
>  +}
> >>>
> >>> You set the name after nand_scan_ident() and make it conditional (only
> >>> if ->name == NULL) so that the label property defined in the DT takes
> >>> precedence over the default name.
> >>  
> for setting mtd->name conditional, do you mean doing something like this?
> 
> if (!mtd->name)
>   mtd->name = devm_kasprintf(..)

Yes, that's what I meant.

> 
> but we found mtd->name = "ffe07800.nfc" after function
> nand_scan_ident(), which is same value as dev_name(dev)..
> and there is no cs information encoded there.

Hm, that shouldn't be the case. Maybe you can add traces to find out
who is setting mtd->name to this value.

> 
> >>  
> >>> Also, I recommend suffixing this name
> >>> with the CS id, just in case you ever need to support connecting several
> >>> chips to the same controller. 
> >>> 
> >>
> >> we actually didn't get the point here, cs is about chip selection with
> >> multiple nand chip? and how to get this information?  
> > 
> > Well, you currently seem to only support one chip per controller, but I
> > guess the IP can handle several CS lines. So my recommendation is about
> > choosing a name so that you can later easily add support for multiple
> > chips without breaking setups where mtdparts is used.
> > 
> > To sum-up, assuming your NAND chip is always connected to CS0 (on the
> > controller side), I'd suggest doing:
> >   
> yes, this is exactly how the hardware connected.
> > mtd->name = devm_kasprintf(nfc->dev, GFP_KERNEL,
> >"%s:nand.%d", dev_name(dev), cs_id);
> > 
> > where cs_id is the value you extracted from the reg property of the
> > NAND node.
> >   
> Ok, you right.
> current, the NAND chip is only use one CS (which CE0) for now, what's in
> the DT is
> 
> nand@0 {
>  reg = < 0 >;
>  ..
> };
> 
> so for the multiple chips it would something like this in DT?
> 
> nand@0 {
>   reg = < 0 >;
> };
> 
> nand@1 {
>   reg = < 1 >;
> };

Yep, that's for 2 single-die chips.

> 
> or even
> nand@0 {
>   reg = < 0 2 >;
> };
> 
> nand@1 {

nand@3 {

>   reg = < 3 4 >;
> };

And this is describing 2 dual-die chips.

> 
> do we need to encode all the cs information here? not sure if we
> understand this correctly, but could send out the patch for review..

Yes, reg should contain an array of controller-side CS lines used to
select the chip (or a specific die in a chip, the index in the reg
table being the id of the die).

Regards,

Boris

[1]http://linux-arm-kernel.infradead.narkive.com/vyJqy0RQ/question-devm-kmalloc-for-dma


[PATCH V3 0/4] KVM/x86/hyper-V: Introduce PV guest address space mapping flush support

2018-07-19 Thread Tianyu Lan
Hyper-V provides a para-virtualization hypercall 
HvFlushGuestPhysicalAddressSpace
to flush nested VM address space mapping in l1 hypervisor and it's to reduce 
overhead
of flushing ept tlb among vcpus. The tradition way is to send IPIs to all 
affected
vcpus and executes INVEPT on each vcpus. It will trigger several vmexits for 
IPI and
INVEPT emulation. The pv hypercall can help to flush specified ept table on all 
vcpus
via one single hypercall.

Change since v2:
   - Make ept_pointers_match as tristate "check", "match" and "mismatch".
   Set "check" in vmx_set_cr3(), check all ept table pointers in 
hv_remote_flush_tlb()
   and call hypercall when all ept pointers are same.
   - Rename kvm_arch_hv_flush_remote_tlb with kvm_arch_flush_remote_tlb and
   Rename kvm_x86_ops->hv_tlb_remote_flush with 
kvm_x86_ops->tlb_remote_flush
   - Fix issue that ignore updating tlbs_dirty during calling 
kvm_arch_flush_remote_tlbs()
   - Merge patch "KVM/VMX: Add identical ept table pointer check" and
   patch "KVM/x86: Add tlb_remote_flush callback support for vmx"

Change since v1:
   - Fix compilation error for non-x86 platform.
   - Use ept_pointers_match to check condition of identical ept
table pointer and get ept pointer from struct vcpu_vmx->ept_pointer.
   - Add hyperv_nested_flush_guest_mapping ftrace support
 


Lan Tianyu (4):
  X86/Hyper-V: Add flush HvFlushGuestPhysicalAddressSpace hypercall
support
  X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace support
  KVM: Add tlb remote flush callback in kvm_x86_ops.
  KVM/x86: Add tlb_remote_flush callback support for vmx

 arch/x86/hyperv/Makefile|  2 +-
 arch/x86/hyperv/nested.c| 67 ++
 arch/x86/include/asm/hyperv-tlfs.h  |  8 +
 arch/x86/include/asm/kvm_host.h | 11 ++
 arch/x86/include/asm/mshyperv.h |  2 ++
 arch/x86/include/asm/trace/hyperv.h | 14 
 arch/x86/kvm/vmx.c  | 72 -
 include/linux/kvm_host.h|  7 
 virt/kvm/kvm_main.c |  3 +-
 9 files changed, 183 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/hyperv/nested.c

-- 
2.14.3


[PATCH V3 3/4] KVM: Add tlb remote flush callback in kvm_x86_ops.

2018-07-19 Thread Tianyu Lan
This patch is to provide a way for platforms to register hv tlb remote
flush callback and this helps to optimize operation of tlb flush
among vcpus for nested virtualization case.

Signed-off-by: Lan Tianyu 
---
Change since v2:
   Rename kvm_arch_hv_flush_remote_tlb with kvm_arch_flush_remote_tlb
   Rename kvm_x86_ops->hv_tlb_remote_flush with 
kvm_x86_ops->tlb_remote_flush
   Fix issue that ignore updating tlbs_dirty during calling 
kvm_arch_flush_remote_tlbs()
Change since v1:
   Add kvm_arch_hv_flush_remote_tlb() to avoid compilation issue
for non-x86 platform.
---
 arch/x86/include/asm/kvm_host.h | 11 +++
 include/linux/kvm_host.h|  7 +++
 virt/kvm/kvm_main.c |  3 ++-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c13cd28d9d1b..76e806bc4ef8 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -973,6 +973,7 @@ struct kvm_x86_ops {
void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
 
void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
+   int  (*tlb_remote_flush)(struct kvm *kvm);
 
void (*run)(struct kvm_vcpu *vcpu);
int (*handle_exit)(struct kvm_vcpu *vcpu);
@@ -1117,6 +1118,16 @@ static inline void kvm_arch_free_vm(struct kvm *kvm)
return kvm_x86_ops->vm_free(kvm);
 }
 
+#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB
+static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm)
+{
+   if (kvm_x86_ops->tlb_remote_flush &&
+   !kvm_x86_ops->tlb_remote_flush(kvm))
+   return 0;
+   else
+   return -EFAULT;
+}
+
 int kvm_mmu_module_init(void);
 void kvm_mmu_module_exit(void);
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 4ee7bc548a83..0781d94200df 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -827,6 +827,13 @@ static inline void kvm_arch_free_vm(struct kvm *kvm)
 }
 #endif
 
+#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB
+static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm)
+{
+   return -EFAULT;
+}
+#endif
+
 #ifdef __KVM_HAVE_ARCH_NONCOHERENT_DMA
 void kvm_arch_register_noncoherent_dma(struct kvm *kvm);
 void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8b47507faab5..1a13cdb2822b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -273,7 +273,8 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that
 * barrier here.
 */
-   if (kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH))
+   if (!kvm_arch_flush_remote_tlb(kvm)
+   || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH))
++kvm->stat.remote_tlb_flush;
cmpxchg(&kvm->tlbs_dirty, dirty_count, 0);
 }
-- 
2.14.3


Re: [PATCH v3 4/7] dcache: allocate external names from reclaimable kmalloc caches

2018-07-19 Thread Mel Gorman
On Wed, Jul 18, 2018 at 03:36:17PM +0200, Vlastimil Babka wrote:
> We can use the newly introduced kmalloc-reclaimable-X caches, to allocate
> external names in dcache, which will take care of the proper accounting
> automatically, and also improve anti-fragmentation page grouping.
> 
> This effectively reverts commit f1782c9bc547 ("dcache: account external names
> as indirectly reclaimable memory") and instead passes __GFP_RECLAIMABLE to
> kmalloc(). The accounting thus moves from NR_INDIRECTLY_RECLAIMABLE_BYTES to
> NR_SLAB_RECLAIMABLE, which is also considered in MemAvailable calculation and
> overcommit decisions.
> 
> Signed-off-by: Vlastimil Babka 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs


Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters

2018-07-19 Thread Neil Armstrong
On 17/07/2018 11:56, Jerome Brunet wrote:
> Remove od parameters from pll clocks and add post dividers clocks
> instead. Some clock, especially the one which feature several ods,
> may provide output between those ods. Also, some drivers, such
> as the hdmi driver, may require a more detailed control of the
> clock dividers, compared to what CCF would perform automatically.
> 
> One added benefit of removing ods is that it also greatly reduce the
> size of the rate parameter tables.
> 
> In the future, we could possibly take the predivider 'n' out of this
> driver as well. To do so, we will need to understand the constraints
> for the PLL to lock and whether or not it depends on the input clock
> rate.
> 
> Signed-off-by: Jerome Brunet 
> ---
>  drivers/clk/meson/axg.c | 279 ++
>  drivers/clk/meson/axg.h |   8 +-
>  drivers/clk/meson/clk-pll.c |  40 ++--
>  drivers/clk/meson/clkc.h|   9 +-
>  drivers/clk/meson/gxbb.c| 474 
> +---
>  drivers/clk/meson/gxbb.h|  10 +-
>  drivers/clk/meson/meson8b.c | 148 +++---
>  drivers/clk/meson/meson8b.h |   5 +-
>  8 files changed, 480 insertions(+), 493 deletions(-)
> 
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 6d8976554656..572358062459 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -22,7 +22,7 @@
>  
>  static DEFINE_SPINLOCK(meson_clk_lock);
>  
> -static struct clk_regmap axg_fixed_pll = {
> +static struct clk_regmap axg_fixed_pll_dco = {
>   .data = &(struct meson_clk_pll_data){
>   .en = {
>   .reg_off = HHI_MPLL_CNTL,
> @@ -39,11 +39,6 @@ static struct clk_regmap axg_fixed_pll = {
>   .shift   = 9,
>   .width   = 5,
>   },
> - .od = {
> - .reg_off = HHI_MPLL_CNTL,
> - .shift   = 16,
> - .width   = 2,
> - },
>   .frac = {
>   .reg_off = HHI_MPLL_CNTL2,
>   .shift   = 0,
> @@ -61,14 +56,29 @@ static struct clk_regmap axg_fixed_pll = {
>   },
>   },
>   .hw.init = &(struct clk_init_data){
> - .name = "fixed_pll",
> + .name = "fixed_pll_dco",
>   .ops = &meson_clk_pll_ro_ops,
>   .parent_names = (const char *[]){ "xtal" },
>   .num_parents = 1,
>   },
>  };
>  
> -static struct clk_regmap axg_sys_pll = {
> +static struct clk_regmap axg_fixed_pll = {
> + .data = &(struct clk_regmap_div_data){
> + .offset = HHI_MPLL_CNTL,
> + .shift = 16,
> + .width = 2,
> + .flags = CLK_DIVIDER_POWER_OF_TWO,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "fixed_pll",
> + .ops = &clk_regmap_divider_ro_ops,
> + .parent_names = (const char *[]){ "fixed_pll_dco" },
> + .num_parents = 1,
> + },
> +};
> +
> +static struct clk_regmap axg_sys_pll_dco = {
>   .data = &(struct meson_clk_pll_data){
>   .en = {
>   .reg_off = HHI_SYS_PLL_CNTL,
> @@ -85,11 +95,6 @@ static struct clk_regmap axg_sys_pll = {
>   .shift   = 9,
>   .width   = 5,
>   },
> - .od = {
> - .reg_off = HHI_SYS_PLL_CNTL,
> - .shift   = 16,
> - .width   = 2,
> - },
>   .l = {
>   .reg_off = HHI_SYS_PLL_CNTL,
>   .shift   = 31,
> @@ -102,7 +107,7 @@ static struct clk_regmap axg_sys_pll = {
>   },
>   },
>   .hw.init = &(struct clk_init_data){
> - .name = "sys_pll",
> + .name = "sys_pll_dco",
>   .ops = &meson_clk_pll_ro_ops,
>   .parent_names = (const char *[]){ "xtal" },
>   .num_parents = 1,
> @@ -110,94 +115,51 @@ static struct clk_regmap axg_sys_pll = {
>   },
>  };
>  
> +static struct clk_regmap axg_sys_pll = {
> + .data = &(struct clk_regmap_div_data){
> + .offset = HHI_SYS_PLL_CNTL,
> + .shift = 16,
> + .width = 2,
> + .flags = CLK_DIVIDER_POWER_OF_TWO,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "sys_pll",
> + .ops = &clk_regmap_divider_ro_ops,
> + .parent_names = (const char *[]){ "sys_pll_dco" },
> + .num_parents = 1,
> + },
> +};
> +
>  static const struct pll_rate_table axg_gp0_pll_rate_table[] = {
> - PLL_RATE(24000, 40, 1, 2),
> - PLL_RATE(24600, 41, 1, 2),
> - PLL_RATE(25200, 42, 1, 2),
> - PLL_RATE(25800, 43, 1, 2),
> - PLL_RATE(26400, 44, 1, 2),
> - PLL_RATE(27000, 45, 1, 2),
> - PLL_RATE(27600, 46, 1, 2),
> - PLL_RATE(28200, 47, 1, 2),
> - PLL_R

[PATCH] pty: fix O_CLOEXEC for TIOCGPTPEER

2018-07-19 Thread Matthijs van Duin
It was being ignored because the flags were not passed to fd allocation.

Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Signed-off-by: Matthijs van Duin 
---
 drivers/tty/pty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index b0e2c4847a5d..678406e0948b 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -625,7 +625,7 @@ int ptm_open_peer(struct file *master, struct tty_struct 
*tty, int flags)
if (tty->driver != ptm_driver)
return -EIO;
 
-   fd = get_unused_fd_flags(0);
+   fd = get_unused_fd_flags(flags);
if (fd < 0) {
retval = fd;
goto err;
-- 
2.18.0



Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables

2018-07-19 Thread Neil Armstrong
On 17/07/2018 11:56, Jerome Brunet wrote:
> Putting hard-coded rates inside the parameter tables assumes that
> the parent is known and will never change. That's a big assumption
> we should not make.
> 
> We have everything we need to recalculate the output rate using
> the parent rate and the rest of the parameters. Let's do so and
> drop the rates from the tables.
> 
> Signed-off-by: Jerome Brunet 
> ---
>  drivers/clk/meson/axg.c |  73 +--
>  drivers/clk/meson/clk-pll.c |  69 -
>  drivers/clk/meson/clkc.h|   8 ++-
>  drivers/clk/meson/gxbb.c| 120 
> ++--
>  drivers/clk/meson/meson8b.c |  34 ++---
>  5 files changed, 162 insertions(+), 142 deletions(-)
> 
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 572358062459..d34954bd8c5e 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -130,36 +130,36 @@ static struct clk_regmap axg_sys_pll = {
>   },
>  };
>  
> -static const struct pll_rate_table axg_gp0_pll_rate_table[] = {
> - PLL_RATE(96000, 40, 1),
> - PLL_RATE(98400, 41, 1),
> - PLL_RATE(100800, 42, 1),
> - PLL_RATE(103200, 43, 1),
> - PLL_RATE(105600, 44, 1),
> - PLL_RATE(108000, 45, 1),
> - PLL_RATE(110400, 46, 1),
> - PLL_RATE(112800, 47, 1),
> - PLL_RATE(115200, 48, 1),
> - PLL_RATE(117600, 49, 1),
> - PLL_RATE(12, 50, 1),
> - PLL_RATE(122400, 51, 1),
> - PLL_RATE(124800, 52, 1),
> - PLL_RATE(127200, 53, 1),
> - PLL_RATE(129600, 54, 1),
> - PLL_RATE(132000, 55, 1),
> - PLL_RATE(134400, 56, 1),
> - PLL_RATE(136800, 57, 1),
> - PLL_RATE(139200, 58, 1),
> - PLL_RATE(141600, 59, 1),
> - PLL_RATE(144000, 60, 1),
> - PLL_RATE(146400, 61, 1),
> - PLL_RATE(148800, 62, 1),
> - PLL_RATE(151200, 63, 1),
> - PLL_RATE(153600, 64, 1),
> - PLL_RATE(156000, 65, 1),
> - PLL_RATE(158400, 66, 1),
> - PLL_RATE(160800, 67, 1),
> - PLL_RATE(163200, 68, 1),
> +static const struct pll_params_table axg_gp0_pll_params_table[] = {
> + PLL_PARAMS(40, 1),
> + PLL_PARAMS(41, 1),
> + PLL_PARAMS(42, 1),
> + PLL_PARAMS(43, 1),
> + PLL_PARAMS(44, 1),
> + PLL_PARAMS(45, 1),
> + PLL_PARAMS(46, 1),
> + PLL_PARAMS(47, 1),
> + PLL_PARAMS(48, 1),
> + PLL_PARAMS(49, 1),
> + PLL_PARAMS(50, 1),
> + PLL_PARAMS(51, 1),
> + PLL_PARAMS(52, 1),
> + PLL_PARAMS(53, 1),
> + PLL_PARAMS(54, 1),
> + PLL_PARAMS(55, 1),
> + PLL_PARAMS(56, 1),
> + PLL_PARAMS(57, 1),
> + PLL_PARAMS(58, 1),
> + PLL_PARAMS(59, 1),
> + PLL_PARAMS(60, 1),
> + PLL_PARAMS(61, 1),
> + PLL_PARAMS(62, 1),
> + PLL_PARAMS(63, 1),
> + PLL_PARAMS(64, 1),
> + PLL_PARAMS(65, 1),
> + PLL_PARAMS(66, 1),
> + PLL_PARAMS(67, 1),
> + PLL_PARAMS(68, 1),
>   { /* sentinel */ },
>  };
>  
> @@ -203,7 +203,7 @@ static struct clk_regmap axg_gp0_pll_dco = {
>   .shift   = 29,
>   .width   = 1,
>   },
> - .table = axg_gp0_pll_rate_table,
> + .table = axg_gp0_pll_params_table,
>   .init_regs = axg_gp0_init_regs,
>   .init_count = ARRAY_SIZE(axg_gp0_init_regs),
>   },
> @@ -271,7 +271,7 @@ static struct clk_regmap axg_hifi_pll_dco = {
>   .shift   = 29,
>   .width   = 1,
>   },
> - .table = axg_gp0_pll_rate_table,
> + .table = axg_gp0_pll_params_table,
>   .init_regs = axg_hifi_init_regs,
>   .init_count = ARRAY_SIZE(axg_hifi_init_regs),
>   .flags = CLK_MESON_PLL_ROUND_CLOSEST,
> @@ -627,11 +627,10 @@ static struct clk_regmap axg_mpll3 = {
>   },
>  };
>  
> -static const struct pll_rate_table axg_pcie_pll_rate_table[] = {
> +static const struct pll_params_table axg_pcie_pll_params_table[] = {
>   {
> - .rate   = 16,
> - .m  = 200,
> - .n  = 3,
> + .m = 200,
> + .n = 3,
>   },
>   { /* sentinel */ },
>  };
> @@ -678,7 +677,7 @@ static struct clk_regmap axg_pcie_pll_dco = {
>   .shift   = 29,
>   .width   = 1,
>   },
> - .table = axg_pcie_pll_rate_table,
> + .table = axg_pcie_pll_params_table,
>   .init_regs = axg_pcie_init_regs,
>   .init_count = ARRAY_SIZE(axg_pcie_init_regs),
>   },
> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> index 348a866f09eb..f5b5b3fabe3c 100644
> --- a/drivers/clk/meson/clk-pll.c
> +++ b/drivers/clk/meson/clk-pll.c
> @@ -45,7 +45,7 @@ meson_clk_pll_data(struct clk_regmap *clk)
>  }
>  
>  static unsigned long __pll_params_to_rate(unsign

Re: [PATCH v3 7/7] mm, slab: shorten kmalloc cache names for large sizes

2018-07-19 Thread Mel Gorman
On Wed, Jul 18, 2018 at 03:36:20PM +0200, Vlastimil Babka wrote:
> Kmalloc cache names can get quite long for large object sizes, when the sizes
> are expressed in bytes. Use 'k' and 'M' prefixes to make the names as short
> as possible e.g. in /proc/slabinfo. This works, as we mostly use power-of-two
> sizes, with exceptions only below 1k.
> 
> Example: 'kmalloc-4194304' becomes 'kmalloc-4M'
> 
> Suggested-by: Matthew Wilcox 
> Signed-off-by: Vlastimil Babka 

There is a slight chance this will break any external tooling that
calculates fragmentation stats for slab/slub if they are particularly
stupid parsers but other than that;

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs


Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters

2018-07-19 Thread Jerome Brunet
On Thu, 2018-07-19 at 10:42 +0200, Neil Armstrong wrote:
> > +static struct clk_regmap gxl_hdmi_pll_od = {
> > + .data = &(struct clk_regmap_div_data){
> > + .offset = HHI_HDMI_PLL_CNTL + 8,
> > + .shift = 16,
> > + .width = 2,
> > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> > + },
> > + .hw.init = &(struct clk_init_data){
> > + .name = "hdmi_pll_od",
> > + .ops = &clk_regmap_divider_ro_ops,
> > + .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > + .num_parents = 1,
> > + .flags = CLK_GET_RATE_NOCACHE,
> > + },
> > +};
> 
> In my code, the GXL OD1 is at bit 21
> 
> > +
> > +static struct clk_regmap gxl_hdmi_pll_od2 = {
> > + .data = &(struct clk_regmap_div_data){
> > + .offset = HHI_HDMI_PLL_CNTL + 8,
> > + .shift = 22,
> > + .width = 2,
> > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> > + },
> > + .hw.init = &(struct clk_init_data){
> > + .name = "hdmi_pll_od2",
> > + .ops = &clk_regmap_divider_ro_ops,
> > + .parent_names = (const char *[]){ "hdmi_pll_od" },
> > + .num_parents = 1,
> > + .flags = CLK_GET_RATE_NOCACHE,
> > + },
> > +};
> 
> 
> In my code, the GXL OD3 is at bit 23
> 
> > +
> >   static struct clk_regmap gxl_hdmi_pll = {
> > - .data = &(struct meson_clk_pll_data){
> > - .en = {
> > - .reg_off = HHI_HDMI_PLL_CNTL,
> > - .shift   = 30,
> > - .width   = 1,
> > - },
> > - .m = {
> > - .reg_off = HHI_HDMI_PLL_CNTL,
> > - .shift   = 0,
> > - .width   = 9,
> > - },
> > - .n = {
> > - .reg_off = HHI_HDMI_PLL_CNTL,
> > - .shift   = 9,
> > - .width   = 5,
> > - },
> > - .frac = {
> > - /*
> > -  * On gxl, there is a register shift due to
> > -  * HHI_HDMI_PLL_CNTL1 which does not exist on gxbb,
> > -  * so we compute the register offset based on the PLL
> > -  * base to get it right
> > -  */
> > - .reg_off = HHI_HDMI_PLL_CNTL + 4,
> > - .shift   = 0,
> > - .width   = 12,
> > - },
> > - .od = {
> > - .reg_off = HHI_HDMI_PLL_CNTL + 8,
> > - .shift   = 21,
> > - .width   = 2,
> > - },
> > - .od2 = {
> > - .reg_off = HHI_HDMI_PLL_CNTL + 8,
> > - .shift   = 23,
> > - .width   = 2,
> > - },
> > - .od3 = {
> > - .reg_off = HHI_HDMI_PLL_CNTL + 8,
> > - .shift   = 19,
> > - .width   = 2,
> > - },
> > - .l = {
> > - .reg_off = HHI_HDMI_PLL_CNTL,
> > - .shift   = 31,
> > - .width   = 1,
> > - },
> > - .rst = {
> > - .reg_off = HHI_HDMI_PLL_CNTL,
> > - .shift   = 29,
> > - .width   = 1,
> > - },
> > + .data = &(struct clk_regmap_div_data){
> > + .offset = HHI_HDMI_PLL_CNTL + 8,
> > + .shift = 18,
> > + .width = 2,
> > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> 
> 
> In my code, the GXL OD3 is at bit 19
> 
> It's only a copy/paste error, the original code had the correct shifts.

Absolutely. Good catch. 



[PATCH v3 2/8] mm/swapfile.c: Replace some #ifdef with IS_ENABLED()

2018-07-19 Thread Huang Ying
In mm/swapfile.c, THP (Transparent Huge Page) swap specific code is
enclosed by #ifdef CONFIG_THP_SWAP/#endif to avoid code dilating when
THP isn't enabled.  But #ifdef/#endif in .c file hurt the code
readability, so Dave suggested to use IS_ENABLED(CONFIG_THP_SWAP)
instead and let compiler to do the dirty job for us.  This has
potential to remove some duplicated code too.  From output of `size`,

text   data bss dec hex filename
THP=y: 26269   2076 340   28685700d mm/swapfile.o
ifdef/endif:   24115   2028 340   264836773 mm/swapfile.o
IS_ENABLED:24179   2028 340   2654767b3 mm/swapfile.o

IS_ENABLED() based solution works quite well, almost as good as that
of #ifdef/#endif.  And from the diffstat, the removed lines are more
than added lines.

One #ifdef for split_swap_cluster() is kept.  Because it is a public
function with a stub implementation for CONFIG_THP_SWAP=n in swap.h.

Signed-off-by: "Huang, Ying" 
Suggested-by: Dave Hansen 
Reviewed-by: Daniel Jordan 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 60 ---
 1 file changed, 20 insertions(+), 40 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 29da44411734..87c4c3446aed 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -870,7 +870,6 @@ static int scan_swap_map_slots(struct swap_info_struct *si,
return n_ret;
 }
 
-#ifdef CONFIG_THP_SWAP
 static int swap_alloc_cluster(struct swap_info_struct *si, swp_entry_t *slot)
 {
unsigned long idx;
@@ -878,6 +877,15 @@ static int swap_alloc_cluster(struct swap_info_struct *si, 
swp_entry_t *slot)
unsigned long offset, i;
unsigned char *map;
 
+   /*
+* Should not even be attempting cluster allocations when huge
+* page swap is disabled.  Warn and fail the allocation.
+*/
+   if (!IS_ENABLED(CONFIG_THP_SWAP)) {
+   VM_WARN_ON_ONCE(1);
+   return 0;
+   }
+
if (cluster_list_empty(&si->free_clusters))
return 0;
 
@@ -908,13 +916,6 @@ static void swap_free_cluster(struct swap_info_struct *si, 
unsigned long idx)
unlock_cluster(ci);
swap_range_free(si, offset, SWAPFILE_CLUSTER);
 }
-#else
-static int swap_alloc_cluster(struct swap_info_struct *si, swp_entry_t *slot)
-{
-   VM_WARN_ON_ONCE(1);
-   return 0;
-}
-#endif /* CONFIG_THP_SWAP */
 
 static unsigned long scan_swap_map(struct swap_info_struct *si,
   unsigned char usage)
@@ -1260,7 +1261,6 @@ static void swapcache_free(swp_entry_t entry)
}
 }
 
-#ifdef CONFIG_THP_SWAP
 static void swapcache_free_cluster(swp_entry_t entry)
 {
unsigned long offset = swp_offset(entry);
@@ -1271,6 +1271,9 @@ static void swapcache_free_cluster(swp_entry_t entry)
unsigned int i, free_entries = 0;
unsigned char val;
 
+   if (!IS_ENABLED(CONFIG_THP_SWAP))
+   return;
+
si = _swap_info_get(entry);
if (!si)
return;
@@ -1306,6 +1309,7 @@ static void swapcache_free_cluster(swp_entry_t entry)
}
 }
 
+#ifdef CONFIG_THP_SWAP
 int split_swap_cluster(swp_entry_t entry)
 {
struct swap_info_struct *si;
@@ -1320,11 +1324,7 @@ int split_swap_cluster(swp_entry_t entry)
unlock_cluster(ci);
return 0;
 }
-#else
-static inline void swapcache_free_cluster(swp_entry_t entry)
-{
-}
-#endif /* CONFIG_THP_SWAP */
+#endif
 
 void put_swap_page(struct page *page, swp_entry_t entry)
 {
@@ -1483,7 +1483,6 @@ int swp_swapcount(swp_entry_t entry)
return count;
 }
 
-#ifdef CONFIG_THP_SWAP
 static bool swap_page_trans_huge_swapped(struct swap_info_struct *si,
 swp_entry_t entry)
 {
@@ -1494,6 +1493,9 @@ static bool swap_page_trans_huge_swapped(struct 
swap_info_struct *si,
int i;
bool ret = false;
 
+   if (!IS_ENABLED(CONFIG_THP_SWAP))
+   return swap_swapcount(si, entry) != 0;
+
ci = lock_cluster_or_swap_info(si, offset);
if (!ci || !cluster_is_huge(ci)) {
if (map[roffset] != SWAP_HAS_CACHE)
@@ -1516,7 +1518,7 @@ static bool page_swapped(struct page *page)
swp_entry_t entry;
struct swap_info_struct *si;
 
-   if (likely(!PageTransCompound(page)))
+   if (!IS_ENABLED(CONFIG_THP_SWAP) || likely(!PageTransCompound(page)))
return page_swapcount(page) != 0;
 
page = compound_head(page);
@@ -1540,10 +1542,8 @@ static int page_trans_huge_map_swapcount(struct page 
*page, int *total_mapcount,
/* hugetlbfs shouldn't call it */
VM_BUG_ON_PAGE(PageHuge(page), page);
 
-   if (likely(!PageTransCompound(page))) {
-   mapcount = atomic_read(&page->_mapcount) + 1;
-   if (total_mapcount)
-

[PATCH v3 6/8] swap, get_swap_pages: Use entry_size instead of cluster in parameter

2018-07-19 Thread Huang Ying
As suggested by Matthew Wilcox, it is better to use "int entry_size"
instead of "bool cluster" as parameter to specify whether to operate
for huge or normal swap entries.  Because this improve the flexibility
to support other swap entry size.  And Dave Hansen thinks that this
improves code readability too.

So in this patch, the "bool cluster" parameter of get_swap_pages() is
replaced by "int entry_size".

And nr_swap_entries() trick is used to reduce the binary size when
!CONFIG_TRANSPARENT_HUGE_PAGE.

   textdata bss dec hex filename
base  242152028 340   2658367d7 mm/swapfile.o
head  241232004 340   264676763 mm/swapfile.o

Signed-off-by: "Huang, Ying" 
Cc: Daniel Jordan 
Cc: Dave Hansen 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 include/linux/swap.h |  2 +-
 mm/swap_slots.c  |  8 
 mm/swapfile.c| 16 
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index e20c240d6c65..34de0d8bf4fa 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -443,7 +443,7 @@ extern void si_swapinfo(struct sysinfo *);
 extern swp_entry_t get_swap_page(struct page *page);
 extern void put_swap_page(struct page *page, swp_entry_t entry);
 extern swp_entry_t get_swap_page_of_type(int);
-extern int get_swap_pages(int n, bool cluster, swp_entry_t swp_entries[]);
+extern int get_swap_pages(int n, swp_entry_t swp_entries[], int entry_size);
 extern int add_swap_count_continuation(swp_entry_t, gfp_t);
 extern void swap_shmem_alloc(swp_entry_t);
 extern int swap_duplicate(swp_entry_t);
diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index 008ccb22fee6..63a7b4563a57 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -269,8 +269,8 @@ static int refill_swap_slots_cache(struct swap_slots_cache 
*cache)
 
cache->cur = 0;
if (swap_slot_cache_active)
-   cache->nr = get_swap_pages(SWAP_SLOTS_CACHE_SIZE, false,
-  cache->slots);
+   cache->nr = get_swap_pages(SWAP_SLOTS_CACHE_SIZE,
+  cache->slots, 1);
 
return cache->nr;
 }
@@ -316,7 +316,7 @@ swp_entry_t get_swap_page(struct page *page)
 
if (PageTransHuge(page)) {
if (IS_ENABLED(CONFIG_THP_SWAP))
-   get_swap_pages(1, true, &entry);
+   get_swap_pages(1, &entry, HPAGE_PMD_NR);
goto out;
}
 
@@ -350,7 +350,7 @@ swp_entry_t get_swap_page(struct page *page)
goto out;
}
 
-   get_swap_pages(1, false, &entry);
+   get_swap_pages(1, &entry, 1);
 out:
if (mem_cgroup_try_charge_swap(page, entry)) {
put_swap_page(page, entry);
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 407f97287ab3..318ceb527c78 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -943,18 +943,18 @@ static unsigned long scan_swap_map(struct 
swap_info_struct *si,
 
 }
 
-int get_swap_pages(int n_goal, bool cluster, swp_entry_t swp_entries[])
+int get_swap_pages(int n_goal, swp_entry_t swp_entries[], int entry_size)
 {
-   unsigned long nr_pages = cluster ? SWAPFILE_CLUSTER : 1;
+   unsigned long size = swap_entry_size(entry_size);
struct swap_info_struct *si, *next;
long avail_pgs;
int n_ret = 0;
int node;
 
/* Only single cluster request supported */
-   WARN_ON_ONCE(n_goal > 1 && cluster);
+   WARN_ON_ONCE(n_goal > 1 && size == SWAPFILE_CLUSTER);
 
-   avail_pgs = atomic_long_read(&nr_swap_pages) / nr_pages;
+   avail_pgs = atomic_long_read(&nr_swap_pages) / size;
if (avail_pgs <= 0)
goto noswap;
 
@@ -964,7 +964,7 @@ int get_swap_pages(int n_goal, bool cluster, swp_entry_t 
swp_entries[])
if (n_goal > avail_pgs)
n_goal = avail_pgs;
 
-   atomic_long_sub(n_goal * nr_pages, &nr_swap_pages);
+   atomic_long_sub(n_goal * size, &nr_swap_pages);
 
spin_lock(&swap_avail_lock);
 
@@ -991,14 +991,14 @@ int get_swap_pages(int n_goal, bool cluster, swp_entry_t 
swp_entries[])
spin_unlock(&si->lock);
goto nextsi;
}
-   if (cluster) {
+   if (size == SWAPFILE_CLUSTER) {
if (!(si->flags & SWP_FILE))
n_ret = swap_alloc_cluster(si, swp_entries);
} else
n_ret = scan_swap_map_slots(si, SWAP_HAS_CACHE,
n_goal, swp_entries);
spin_unlock(&si->lock);
-   if (n_ret || cluster)
+   if (n_ret || size == SWAPFILE_CLUSTER)
goto check_out;
pr_debug("scan_swap_map of si %d failed to find offset\n"

[PATCH v3 0/8] swap: THP optimizing refactoring

2018-07-19 Thread Huang Ying
This patchset is based on 2018-07-13 head of mmotm tree.

Now the THP (Transparent Huge Page) swap optimizing is implemented in
the way like below,

#ifdef CONFIG_THP_SWAP
huge_function(...)
{
}
#else
normal_function(...)
{
}
#endif

general_function(...)
{
if (huge)
return thp_function(...);
else
return normal_function(...);
}

As pointed out by Dave Hansen, this will,

1. Created a new, wholly untested code path for huge page
2. Created two places to patch bugs
3. Are not reusing code when possible

This patchset is to address these problems via merging huge/normal
code path/functions if possible.

One concern is that this may cause code size to dilate when
!CONFIG_TRANSPARENT_HUGEPAGE.  The data shows that most refactoring
will only cause quite slight code size increase.

Best Regards,
Huang, Ying


[PATCH v3 3/8] swap: Use swap_count() in swap_page_trans_huge_swapped()

2018-07-19 Thread Huang Ying
In swap_page_trans_huge_swapped(), to identify whether there's any
page table mapping for a 4k sized swap entry, "si->swap_map[i] !=
SWAP_HAS_CACHE" is used.  This works correctly now, because all users
of the function will only call it after checking SWAP_HAS_CACHE.  But
as pointed out by Daniel, it is better to use "swap_count(map[i])"
here, because it works for "map[i] == 0" case too.

And this makes the implementation more consistent between normal and
huge swap entry.

Signed-off-by: "Huang, Ying" 
Suggested-and-reviewed-by: Daniel Jordan 
Cc: Dave Hansen 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 87c4c3446aed..cb0bc54e99c0 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1498,12 +1498,12 @@ static bool swap_page_trans_huge_swapped(struct 
swap_info_struct *si,
 
ci = lock_cluster_or_swap_info(si, offset);
if (!ci || !cluster_is_huge(ci)) {
-   if (map[roffset] != SWAP_HAS_CACHE)
+   if (swap_count(map[roffset]))
ret = true;
goto unlock_out;
}
for (i = 0; i < SWAPFILE_CLUSTER; i++) {
-   if (map[offset + i] != SWAP_HAS_CACHE) {
+   if (swap_count(map[offset + i])) {
ret = true;
break;
}
-- 
2.16.4



[PATCH v3 1/8] swap: Add comments to lock_cluster_or_swap_info()

2018-07-19 Thread Huang Ying
To improve the code readability.

Signed-off-by: "Huang, Ying" 
Suggested-by: Dave Hansen 
Reviewed-by: Daniel Jordan 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index d8fddfb000ec..29da44411734 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -297,13 +297,19 @@ static inline void unlock_cluster(struct 
swap_cluster_info *ci)
spin_unlock(&ci->lock);
 }
 
+/*
+ * Determine the locking method in use for this device.  Return
+ * swap_cluster_info if SSD-style cluster-based locking is in place.
+ */
 static inline struct swap_cluster_info *lock_cluster_or_swap_info(
struct swap_info_struct *si,
unsigned long offset)
 {
struct swap_cluster_info *ci;
 
+   /* Try to use fine-grained SSD-style locking if available: */
ci = lock_cluster(si, offset);
+   /* Otherwise, fall back to traditional, coarse locking: */
if (!ci)
spin_lock(&si->lock);
 
-- 
2.16.4



[PATCH v3 5/8] swap: Unify normal/huge code path in put_swap_page()

2018-07-19 Thread Huang Ying
In this patch, the normal/huge code path in put_swap_page() and
several helper functions are unified to avoid duplicated code, bugs,
etc. and make it easier to review the code.

The removed lines are more than added lines.  And the binary size is
kept exactly same when CONFIG_TRANSPARENT_HUGEPAGE=n.

Signed-off-by: "Huang, Ying" 
Suggested-by: Dave Hansen 
Reviewed-by: Daniel Jordan 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 83 ++-
 1 file changed, 37 insertions(+), 46 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 96018207b582..407f97287ab3 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -205,8 +205,16 @@ static void discard_swap_cluster(struct swap_info_struct 
*si,
 
 #ifdef CONFIG_THP_SWAP
 #define SWAPFILE_CLUSTER   HPAGE_PMD_NR
+
+#define swap_entry_size(size)  (size)
 #else
 #define SWAPFILE_CLUSTER   256
+
+/*
+ * Define swap_entry_size() as constant to let compiler to optimize
+ * out some code if !CONFIG_THP_SWAP
+ */
+#define swap_entry_size(size)  1
 #endif
 #define LATENCY_LIMIT  256
 
@@ -1253,18 +1261,7 @@ void swap_free(swp_entry_t entry)
 /*
  * Called after dropping swapcache to decrease refcnt to swap entries.
  */
-static void swapcache_free(swp_entry_t entry)
-{
-   struct swap_info_struct *p;
-
-   p = _swap_info_get(entry);
-   if (p) {
-   if (!__swap_entry_free(p, entry, SWAP_HAS_CACHE))
-   free_swap_slot(entry);
-   }
-}
-
-static void swapcache_free_cluster(swp_entry_t entry)
+void put_swap_page(struct page *page, swp_entry_t entry)
 {
unsigned long offset = swp_offset(entry);
unsigned long idx = offset / SWAPFILE_CLUSTER;
@@ -1273,39 +1270,41 @@ static void swapcache_free_cluster(swp_entry_t entry)
unsigned char *map;
unsigned int i, free_entries = 0;
unsigned char val;
-
-   if (!IS_ENABLED(CONFIG_THP_SWAP))
-   return;
+   int size = swap_entry_size(hpage_nr_pages(page));
 
si = _swap_info_get(entry);
if (!si)
return;
 
-   ci = lock_cluster(si, offset);
-   VM_BUG_ON(!cluster_is_huge(ci));
-   map = si->swap_map + offset;
-   for (i = 0; i < SWAPFILE_CLUSTER; i++) {
-   val = map[i];
-   VM_BUG_ON(!(val & SWAP_HAS_CACHE));
-   if (val == SWAP_HAS_CACHE)
-   free_entries++;
-   }
-   if (!free_entries) {
-   for (i = 0; i < SWAPFILE_CLUSTER; i++)
-   map[i] &= ~SWAP_HAS_CACHE;
-   }
-   cluster_clear_huge(ci);
-   unlock_cluster(ci);
-   if (free_entries == SWAPFILE_CLUSTER) {
-   spin_lock(&si->lock);
+   if (size == SWAPFILE_CLUSTER) {
ci = lock_cluster(si, offset);
-   memset(map, 0, SWAPFILE_CLUSTER);
+   VM_BUG_ON(!cluster_is_huge(ci));
+   map = si->swap_map + offset;
+   for (i = 0; i < SWAPFILE_CLUSTER; i++) {
+   val = map[i];
+   VM_BUG_ON(!(val & SWAP_HAS_CACHE));
+   if (val == SWAP_HAS_CACHE)
+   free_entries++;
+   }
+   if (!free_entries) {
+   for (i = 0; i < SWAPFILE_CLUSTER; i++)
+   map[i] &= ~SWAP_HAS_CACHE;
+   }
+   cluster_clear_huge(ci);
unlock_cluster(ci);
-   mem_cgroup_uncharge_swap(entry, SWAPFILE_CLUSTER);
-   swap_free_cluster(si, idx);
-   spin_unlock(&si->lock);
-   } else if (free_entries) {
-   for (i = 0; i < SWAPFILE_CLUSTER; i++, entry.val++) {
+   if (free_entries == SWAPFILE_CLUSTER) {
+   spin_lock(&si->lock);
+   ci = lock_cluster(si, offset);
+   memset(map, 0, SWAPFILE_CLUSTER);
+   unlock_cluster(ci);
+   mem_cgroup_uncharge_swap(entry, SWAPFILE_CLUSTER);
+   swap_free_cluster(si, idx);
+   spin_unlock(&si->lock);
+   return;
+   }
+   }
+   if (size == 1 || free_entries) {
+   for (i = 0; i < size; i++, entry.val++) {
if (!__swap_entry_free(si, entry, SWAP_HAS_CACHE))
free_swap_slot(entry);
}
@@ -1329,14 +1328,6 @@ int split_swap_cluster(swp_entry_t entry)
 }
 #endif
 
-void put_swap_page(struct page *page, swp_entry_t entry)
-{
-   if (!PageTransHuge(page))
-   swapcache_free(entry);
-   else
-   swapcache_free_cluster(entry);
-}
-
 static int swp_entry_cmp(const void *ent1, const void *ent2)
 {
const swp_entry_t *e1 = ent1, *e2 = ent2;
-- 

[PATCH v3 4/8] swap: Unify normal/huge code path in swap_page_trans_huge_swapped()

2018-07-19 Thread Huang Ying
As suggested by Dave, we should unify the code path for normal and
huge swap support if possible to avoid duplicated code, bugs, etc. and
make it easier to review code.

In this patch, the normal/huge code path in swap_page_trans_huge_swapped()
is unified, the added and removed lines are same.  And the binary size
is kept almost same when CONFIG_TRANSPARENT_HUGEPAGE=n.

 text  data bss dec hex filename
base:   24179  2028 340   2654767b3 mm/swapfile.o
unified:24215  2028 340   2658367d7 mm/swapfile.o

Signed-off-by: "Huang, Ying" 
Suggested-by: Dave Hansen 
Reviewed-by: Daniel Jordan 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index cb0bc54e99c0..96018207b582 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -270,7 +270,10 @@ static inline void cluster_set_null(struct 
swap_cluster_info *info)
 
 static inline bool cluster_is_huge(struct swap_cluster_info *info)
 {
-   return info->flags & CLUSTER_FLAG_HUGE;
+   if (IS_ENABLED(CONFIG_THP_SWAP))
+   return info->flags & CLUSTER_FLAG_HUGE;
+   else
+   return false;
 }
 
 static inline void cluster_clear_huge(struct swap_cluster_info *info)
@@ -1493,9 +1496,6 @@ static bool swap_page_trans_huge_swapped(struct 
swap_info_struct *si,
int i;
bool ret = false;
 
-   if (!IS_ENABLED(CONFIG_THP_SWAP))
-   return swap_swapcount(si, entry) != 0;
-
ci = lock_cluster_or_swap_info(si, offset);
if (!ci || !cluster_is_huge(ci)) {
if (swap_count(map[roffset]))
-- 
2.16.4



[PATCH v3 7/8] swap: Add __swap_entry_free_locked()

2018-07-19 Thread Huang Ying
The part of __swap_entry_free() with lock held is separated into a new
function __swap_entry_free_locked().  Because we want to reuse that
piece of code in some other places.

Just mechanical code refactoring, there is no any functional change in
this function.

Signed-off-by: "Huang, Ying" 
Reviewed-by: Daniel Jordan 
Cc: Dave Hansen 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 318ceb527c78..d313f7512d26 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1184,16 +1184,13 @@ struct swap_info_struct *get_swap_device(swp_entry_t 
entry)
return NULL;
 }
 
-static unsigned char __swap_entry_free(struct swap_info_struct *p,
-  swp_entry_t entry, unsigned char usage)
+static unsigned char __swap_entry_free_locked(struct swap_info_struct *p,
+ unsigned long offset,
+ unsigned char usage)
 {
-   struct swap_cluster_info *ci;
-   unsigned long offset = swp_offset(entry);
unsigned char count;
unsigned char has_cache;
 
-   ci = lock_cluster_or_swap_info(p, offset);
-
count = p->swap_map[offset];
 
has_cache = count & SWAP_HAS_CACHE;
@@ -1221,6 +1218,17 @@ static unsigned char __swap_entry_free(struct 
swap_info_struct *p,
usage = count | has_cache;
p->swap_map[offset] = usage ? : SWAP_HAS_CACHE;
 
+   return usage;
+}
+
+static unsigned char __swap_entry_free(struct swap_info_struct *p,
+  swp_entry_t entry, unsigned char usage)
+{
+   struct swap_cluster_info *ci;
+   unsigned long offset = swp_offset(entry);
+
+   ci = lock_cluster_or_swap_info(p, offset);
+   usage = __swap_entry_free_locked(p, offset, usage);
unlock_cluster_or_swap_info(p, ci);
 
return usage;
-- 
2.16.4



[PATCH v3 8/8] swap, put_swap_page: Share more between huge/normal code path

2018-07-19 Thread Huang Ying
In this patch, locking related code is shared between huge/normal code
path in put_swap_page() to reduce code duplication.  And `free_entries
== 0` case is merged into more general `free_entries !=
SWAPFILE_CLUSTER` case, because the new locking method makes it easy.

The added lines is same as the removed lines.  But the code size is
increased when CONFIG_TRANSPARENT_HUGEPAGE=n.

text   data bss dec hex filename
base:  24123   2004 340   264676763 mm/swapfile.o
unified:   24485   2004 340   2682968cd mm/swapfile.o

Dig on step deeper with `size -A mm/swapfile.o` for base and unified
kernel and compare the result, yields,

  -.text17723  0
  +.text17835  0
  -.orc_unwind_ip1380  0
  +.orc_unwind_ip1480  0
  -.orc_unwind   2070  0
  +.orc_unwind   2220  0
  -Total26686
  +Total27048

The total difference is the same.  The text segment difference is much
smaller: 112.  More difference comes from the ORC unwinder
segments: (1480 + 2220) - (1380 + 2070) = 250.  If the frame pointer
unwinder is used, this costs nothing.

Signed-off-by: "Huang, Ying" 
Reviewed-by: Daniel Jordan 
Cc: Dave Hansen 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shaohua Li 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Dan Williams 
---
 mm/swapfile.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index d313f7512d26..2fe2e93cee0e 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1284,8 +1284,8 @@ void put_swap_page(struct page *page, swp_entry_t entry)
if (!si)
return;
 
+   ci = lock_cluster_or_swap_info(si, offset);
if (size == SWAPFILE_CLUSTER) {
-   ci = lock_cluster(si, offset);
VM_BUG_ON(!cluster_is_huge(ci));
map = si->swap_map + offset;
for (i = 0; i < SWAPFILE_CLUSTER; i++) {
@@ -1294,13 +1294,9 @@ void put_swap_page(struct page *page, swp_entry_t entry)
if (val == SWAP_HAS_CACHE)
free_entries++;
}
-   if (!free_entries) {
-   for (i = 0; i < SWAPFILE_CLUSTER; i++)
-   map[i] &= ~SWAP_HAS_CACHE;
-   }
cluster_clear_huge(ci);
-   unlock_cluster(ci);
if (free_entries == SWAPFILE_CLUSTER) {
+   unlock_cluster_or_swap_info(si, ci);
spin_lock(&si->lock);
ci = lock_cluster(si, offset);
memset(map, 0, SWAPFILE_CLUSTER);
@@ -1311,12 +1307,16 @@ void put_swap_page(struct page *page, swp_entry_t entry)
return;
}
}
-   if (size == 1 || free_entries) {
-   for (i = 0; i < size; i++, entry.val++) {
-   if (!__swap_entry_free(si, entry, SWAP_HAS_CACHE))
-   free_swap_slot(entry);
+   for (i = 0; i < size; i++, entry.val++) {
+   if (!__swap_entry_free_locked(si, offset + i, SWAP_HAS_CACHE)) {
+   unlock_cluster_or_swap_info(si, ci);
+   free_swap_slot(entry);
+   if (i == size - 1)
+   return;
+   lock_cluster_or_swap_info(si, offset);
}
}
+   unlock_cluster_or_swap_info(si, ci);
 }
 
 #ifdef CONFIG_THP_SWAP
-- 
2.16.4



Re: [PATCH] vfs: make open_with_fake_path() not contribute to nr_files

2018-07-19 Thread Miklos Szeredi
On Thu, Jul 19, 2018 at 10:09 AM, David Howells  wrote:
> Miklos Szeredi  wrote:
>
>> Stacking file operations in overlay will store an extra open file for each
>> overlay file opened.
>>
>> The overhead is just that of "struct file" which is about 256bytes, because
>> overlay already pins an extra dentry and inode when the file is open, which
>> add up to a much larger overhead.
>>
>> For fear of breaking working setups, don't start accounting the extra file.
>
> Sounds useful for cachefiles too, though Christoph Hellwig objected strongly
> last time I tried this, so you might want to check with him directly.

What the cachefiles use case would be?

Overlayfs wants the "shadow" file open only as long as the real file
is open.  Is the cachefiles case the same?

For overlays the real cost of pinned memory by open files  is already
sunk in the layered dentry references.  Which means overlayfs is
already pinning substantially more memory for an open file than other
fs (by about a factor of 2-3, due to pinned lower and/or upper
dentries and inodes).   If this was a problem in real life, then we'd
be already be in trouble.  The stacked open file patch only adds the
overhead of the actual struct file, which is small compared to the
multiple pinned dentry and inode structs.

Christoph already commented on a previous version of the patch and I
pointed out the above.

Thanks,
Miklos


Re: [PATCH 4/5] crypto: Add IV generation templates

2018-07-19 Thread Arnd Bergmann
On Thu, Jul 19, 2018 at 3:46 AM, Xiongfeng Wang
 wrote:
> Hi,
>
> On 2018/7/19 1:17, Milan Broz wrote:
>> On 18/07/18 18:46, Mark Brown wrote:
>>> On Wed, Jul 18, 2018 at 10:16:05AM +0200, Milan Broz wrote:
>>>
 So we are here again and moving INTERNAL dm-crypt functionality into
 cryptoapi.
>>
>> 2) If the reason is performance, please provide numbers with the patch.
>> What I see now is that the performance is almost the same. So why you are 
>> doing it?
>> Any real hw that benefits from it?
>
> Because the internal implementation of the IV template 'benbi()' is still
> dividing the whole bio into sectors, so the performance is almost the same.
> The purpose of this patch is to let dm-crypt rely on the new algorithm 
> 'aes-cbc-benbi'
> and pass the whole bio to the new algorithm.
> And then if the hardware driver implements this new algorithm, it can get the 
> data of
> the bio at one time, and return the processed data at one time.
> I think it will decrease the overhead of passing each sector alternatively.
> But the hardware need to implement the new algorithm if it want to benefit 
> from this.

There seems to be some support for at least essiv(aes) in
drivers/crypto/ccree/cc_cipher.c, is that compatible with your essiv(*)
template, or is that something else?

   Arnd


[PATCH v2 2/2] tty/serial: atmel: add ISO7816 support

2018-07-19 Thread Ludovic Desroches
From: Nicolas Ferre 

When mode is set in atmel_config_iso7816() we backup last RS232 mode
for coming back to this mode if requested.
Also allow setup of T=0 and T=1 parameter and basic support in set_termios
function as well.
Report NACK and ITER errors in irq handler.

Signed-off-by: Nicolas Ferre 
Signed-off-by: Ludovic Desroches 
---
 drivers/tty/serial/atmel_serial.c | 170 +++---
 drivers/tty/serial/atmel_serial.h |   3 +-
 2 files changed, 162 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index 8e4428725848..cec958f1e7d4 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -147,6 +148,8 @@ struct atmel_uart_port {
struct circ_buf rx_ring;
 
struct mctrl_gpios  *gpios;
+   u32 backup_mode;/* MR saved during iso7816 
operations */
+   u32 backup_brgr;/* BRGR saved during iso7816 
operations */
unsigned inttx_done_mask;
u32 fifo_size;
u32 rts_high;
@@ -362,6 +365,132 @@ static int atmel_config_rs485(struct uart_port *port,
return 0;
 }
 
+static unsigned int atmel_calc_cd(struct uart_port *port,
+ struct serial_iso7816 *iso7816conf)
+{
+   struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+   unsigned int cd;
+   u64 mck_rate;
+
+   mck_rate = (u64)clk_get_rate(atmel_port->clk);
+   do_div(mck_rate, iso7816conf->clk);
+   cd = mck_rate;
+   return cd;
+}
+
+static unsigned int atmel_calc_fidi(struct uart_port *port,
+   struct serial_iso7816 *iso7816conf)
+{
+   u64 fidi = 0;
+
+   if (iso7816conf->sc_fi && iso7816conf->sc_di) {
+   fidi = (u64)iso7816conf->sc_fi;
+   do_div(fidi, iso7816conf->sc_di);
+   }
+   return (u32)fidi;
+}
+
+/* Enable or disable the iso7816 support */
+/* Called with interrupts disabled */
+static int atmel_config_iso7816(struct uart_port *port,
+   struct serial_iso7816 *iso7816conf)
+{
+   struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+   unsigned int mode, t;
+   unsigned int cd, fidi;
+   int ret = 0;
+
+   /* Disable RX and TX */
+   atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_RXDIS | ATMEL_US_TXDIS);
+   /* Disable interrupts */
+   atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
+
+   mode = atmel_uart_readl(port, ATMEL_US_MR);
+
+   if (iso7816conf->flags & SER_ISO7816_ENABLED) {
+   mode &= ~ATMEL_US_USMODE;
+
+   if ((iso7816conf->flags & SER_ISO7816_T_PARAM)
+   == SER_ISO7816_T(0)) {
+   mode |= ATMEL_US_USMODE_ISO7816_T0;
+   t = 0;
+   } else if ((iso7816conf->flags & SER_ISO7816_T_PARAM)
+   == SER_ISO7816_T(1)) {
+   mode |= ATMEL_US_USMODE_ISO7816_T1;
+   t = 1;
+   } else {
+   dev_warn(port->dev, "ISO7816 Type not supported. 
Resetting\n");
+   memset(iso7816conf, 0, sizeof(struct serial_iso7816));
+   goto err_out;
+   }
+
+   dev_dbg(port->dev, "Setting USART to ISO7816 mode T%d\n", t);
+
+   mode &= ~(ATMEL_US_USCLKS | ATMEL_US_CHRL
+   | ATMEL_US_NBSTOP | ATMEL_US_PAR);
+
+   /* NACK configuration */
+   if ((iso7816conf->flags & SER_ISO7816_T_PARAM)
+   == SER_ISO7816_T(0))
+   mode |= ATMEL_US_DSNACK;
+   else
+   mode |= ATMEL_US_INACK;
+   /* select mck clock, and output  */
+   mode |= ATMEL_US_USCLKS_MCK | ATMEL_US_CLKO;
+   /* set parity for normal/inverse mode + max iterations */
+   mode |= ATMEL_US_PAR_EVEN | ATMEL_US_NBSTOP_1 | (3 << 24);
+
+   cd = atmel_calc_cd(port, iso7816conf);
+   fidi = atmel_calc_fidi(port, iso7816conf);
+   if (fidi < 0) {
+   dev_warn(port->dev, "ISO7816 fidi = 0, Generator 
generates no signal\n");
+   } else if (fidi == 1 || fidi == 2) {
+   dev_err(port->dev, "ISO7816 fidi = %u, value not 
supported\n", fidi);
+   ret = -EINVAL;
+   goto err_out;
+   }
+
+   if (!(port->iso7816.flags & SER_ISO7816_ENABLED)) {
+   /* port not yet in iso7816 mode: store configuration */
+   atmel_port->backup_mode = atmel_uart_readl(port, 
ATMEL_US_MR);
+  

[PATCH v2 1/2] tty/serial_core: add ISO7816 infrastructure

2018-07-19 Thread Ludovic Desroches
From: Nicolas Ferre 

Add the ISO7816 ioctl and associated accessors and data structure.
Drivers can then use this common implementation to handle ISO7816.

Signed-off-by: Nicolas Ferre 
Signed-off-by: Ludovic Desroches 
---
 arch/alpha/include/uapi/asm/ioctls.h   |  2 ++
 arch/mips/include/uapi/asm/ioctls.h|  2 ++
 arch/powerpc/include/uapi/asm/ioctls.h |  2 ++
 arch/sh/include/uapi/asm/ioctls.h  |  2 ++
 arch/sparc/include/uapi/asm/ioctls.h   |  2 ++
 arch/xtensa/include/uapi/asm/ioctls.h  |  2 ++
 drivers/tty/serial/serial_core.c   | 60 ++
 include/linux/serial_core.h|  3 ++
 include/uapi/asm-generic/ioctls.h  |  2 ++
 include/uapi/linux/serial.h| 17 ++
 10 files changed, 94 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/ioctls.h 
b/arch/alpha/include/uapi/asm/ioctls.h
index 3729d92d3fa8..1e9121c9b3c7 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -102,6 +102,8 @@
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
 #define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
+#define TIOCGISO7816   _IOR('T', 0x42, struct serial_iso7816)
+#define TIOCSISO7816   _IOWR('T', 0x43, struct serial_iso7816)
 
 #define TIOCSERCONFIG  0x5453
 #define TIOCSERGWILD   0x5454
diff --git a/arch/mips/include/uapi/asm/ioctls.h 
b/arch/mips/include/uapi/asm/ioctls.h
index 890245a9f0c4..16aa8a766aec 100644
--- a/arch/mips/include/uapi/asm/ioctls.h
+++ b/arch/mips/include/uapi/asm/ioctls.h
@@ -93,6 +93,8 @@
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
 #define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
+#define TIOCGISO7816   _IOR('T', 0x42, struct serial_iso7816)
+#define TIOCSISO7816   _IOWR('T', 0x43, struct serial_iso7816)
 
 /* I hope the range from 0x5480 on is free ... */
 #define TIOCSCTTY  0x5480  /* become controlling tty */
diff --git a/arch/powerpc/include/uapi/asm/ioctls.h 
b/arch/powerpc/include/uapi/asm/ioctls.h
index 41b1a5c15734..2c145da3b774 100644
--- a/arch/powerpc/include/uapi/asm/ioctls.h
+++ b/arch/powerpc/include/uapi/asm/ioctls.h
@@ -102,6 +102,8 @@
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
 #define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
+#define TIOCGISO7816   _IOR('T', 0x42, struct serial_iso7816)
+#define TIOCSISO7816   _IOWR('T', 0x43, struct serial_iso7816)
 
 #define TIOCSERCONFIG  0x5453
 #define TIOCSERGWILD   0x5454
diff --git a/arch/sh/include/uapi/asm/ioctls.h 
b/arch/sh/include/uapi/asm/ioctls.h
index cc62f6f98103..11866d4f60e1 100644
--- a/arch/sh/include/uapi/asm/ioctls.h
+++ b/arch/sh/include/uapi/asm/ioctls.h
@@ -95,6 +95,8 @@
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
 #define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
+#define TIOCGISO7816   _IOR('T', 0x42, struct serial_iso7816)
+#define TIOCSISO7816   _IOWR('T', 0x43, struct serial_iso7816)
 
 #define TIOCSERCONFIG  _IO('T', 83) /* 0x5453 */
 #define TIOCSERGWILD   _IOR('T', 84,  int) /* 0x5454 */
diff --git a/arch/sparc/include/uapi/asm/ioctls.h 
b/arch/sparc/include/uapi/asm/ioctls.h
index 2df52711e170..7fd2f5873c9e 100644
--- a/arch/sparc/include/uapi/asm/ioctls.h
+++ b/arch/sparc/include/uapi/asm/ioctls.h
@@ -27,6 +27,8 @@
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
 #define TIOCGRS485 _IOR('T', 0x41, struct serial_rs485)
 #define TIOCSRS485 _IOWR('T', 0x42, struct serial_rs485)
+#define TIOCGISO7816   _IOR('T', 0x43, struct serial_iso7816)
+#define TIOCSISO7816   _IOWR('T', 0x44, struct serial_iso7816)
 
 /* Note that all the ioctls that are not available in Linux have a
  * double underscore on the front to: a) avoid some programs to
diff --git a/arch/xtensa/include/uapi/asm/ioctls.h 
b/arch/xtensa/include/uapi/asm/ioctls.h
index ec43609cbfc5..6d4a87296c95 100644
--- a/arch/xtensa/include/uapi/asm/ioctls.h
+++ b/arch/xtensa/include/uapi/asm/ioctls.h
@@ -107,6 +107,8 @@
 #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
 #define TIOCGEXCL  _IOR('T', 0x40, int) /* Get exclusive mode state */
 #define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
+#define TIOCGISO7816   _IOR('T', 0x42, struct serial_iso7816)
+#define TIOCSISO7816   _IOWR('T', 0x43, struct serial_iso7816)
 
 #define TIOCSERCONFIG  _IO('T', 83)
 #define TIOCSERGWILD   _IOR('T', 84,  int)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9c14a453f73c..af8d5b12fba9 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1301,

[PATCH v2 0/2] add ISO7816 support

2018-07-19 Thread Ludovic Desroches
Hi,

This patchset adds support for the ISO7816 standard. The USART devices in
Microchip SoCs have an ISO7816 mode. It allows to let the USART managing
the CLK and I/O signals of a smart card.

Changes:
- v2
  - uart_get_iso7816_config: check there is an iso7816_config function
  - use IOCTL macros to generate the IOCTL number
  - check that reserved field is not used
  - remove debug logs
  - check that the iso7816_config is right before doing any action
  - change the error from nack and max iteration status to a debug message
  - remove patch 3 as it concerns both rs485 and iso7816 to think more
  about the need of adding a lock or not

Nicolas Ferre (2):
  tty/serial_core: add ISO7816 infrastructure
  tty/serial: atmel: add ISO7816 support

 arch/alpha/include/uapi/asm/ioctls.h   |   2 +
 arch/mips/include/uapi/asm/ioctls.h|   2 +
 arch/powerpc/include/uapi/asm/ioctls.h |   2 +
 arch/sh/include/uapi/asm/ioctls.h  |   2 +
 arch/sparc/include/uapi/asm/ioctls.h   |   2 +
 arch/xtensa/include/uapi/asm/ioctls.h  |   2 +
 drivers/tty/serial/atmel_serial.c  | 170 +++--
 drivers/tty/serial/atmel_serial.h  |   3 +-
 drivers/tty/serial/serial_core.c   |  60 
 include/linux/serial_core.h|   3 +
 include/uapi/asm-generic/ioctls.h  |   2 +
 include/uapi/linux/serial.h|  17 
 12 files changed, 256 insertions(+), 11 deletions(-)

-- 
2.12.2



[PATCH v1] lib: Remove 'default n' in Kconfig for tests

2018-07-19 Thread Andy Shevchenko
It seems contributors follow the style of Kconfig entries where explicit
'default n' is present. The default 'default' is 'n' already, thus, drop
these lines from Kconfig to make it more clear.

Cc: Coly Li 
Signed-off-by: Andy Shevchenko 
---
 lib/Kconfig   |  1 -
 lib/Kconfig.debug | 17 -
 2 files changed, 18 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index 031655d26dce..40bfa6ccd294 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -231,7 +231,6 @@ config AUDIT_COMPAT_GENERIC
 
 config RANDOM32_SELFTEST
bool "PRNG perform self test on init"
-   default n
help
  This option enables the 32 bit PRNG library functions to perform a
  self test on initialization.
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c731ff97500c..244c08055d8e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1225,7 +1225,6 @@ config LOCK_TORTURE_TEST
tristate "torture tests for locking"
depends on DEBUG_KERNEL
select TORTURE_TEST
-   default n
help
  This option provides a kernel module that runs torture tests
  on kernel locking primitives.  The kernel module may be built
@@ -1692,7 +1691,6 @@ config LKDTM
tristate "Linux Kernel Dump Test Tool Module"
depends on DEBUG_FS
depends on BLOCK
-   default n
help
This module enables testing of the different dumping mechanisms by
inducing system failures at predefined crash points.
@@ -1726,7 +1724,6 @@ config KPROBES_SANITY_TEST
bool "Kprobes sanity tests"
depends on DEBUG_KERNEL
depends on KPROBES
-   default n
help
  This option provides for testing basic kprobes functionality on
  boot. Samples of kprobe and kretprobe are inserted and
@@ -1737,7 +1734,6 @@ config KPROBES_SANITY_TEST
 config BACKTRACE_SELF_TEST
tristate "Self test for the backtrace code"
depends on DEBUG_KERNEL
-   default n
help
  This option provides a kernel module that can be used to test
  the kernel stack backtrace code. This option is not useful
@@ -1807,7 +1803,6 @@ config TEST_PRINTF
 
 config TEST_BITMAP
tristate "Test bitmap_*() family of functions at runtime"
-   default n
help
  Enable this option to test the bitmap functions at boot.
 
@@ -1831,7 +1826,6 @@ config TEST_OVERFLOW
 
 config TEST_RHASHTABLE
tristate "Perform selftest on resizable hash table"
-   default n
help
  Enable this option to test the rhashtable functions at boot.
 
@@ -1839,7 +1833,6 @@ config TEST_RHASHTABLE
 
 config TEST_HASH
tristate "Perform selftest on hash functions"
-   default n
help
  Enable this option to test the kernel's integer (),
  string (), and siphash ()
@@ -1853,7 +1846,6 @@ config TEST_IDA
 
 config TEST_PARMAN
tristate "Perform selftest on priority array manager"
-   default n
depends on PARMAN
help
  Enable this option to test priority array manager on boot
@@ -1863,7 +1855,6 @@ config TEST_PARMAN
 
 config TEST_LKM
tristate "Test module loading with 'hello world' module"
-   default n
depends on m
help
  This builds the "test_module" module that emits "Hello, world"
@@ -1877,7 +1868,6 @@ config TEST_LKM
 
 config TEST_USER_COPY
tristate "Test user/kernel boundary protections"
-   default n
depends on m
help
  This builds the "test_user_copy" module that runs sanity checks
@@ -1890,7 +1880,6 @@ config TEST_USER_COPY
 
 config TEST_BPF
tristate "Test BPF filter functionality"
-   default n
depends on m && NET
help
  This builds the "test_bpf" module that runs various test vectors
@@ -1904,7 +1893,6 @@ config TEST_BPF
 
 config FIND_BIT_BENCHMARK
tristate "Test find_bit functions"
-   default n
help
  This builds the "test_find_bit" module that measure find_*_bit()
  functions performance.
@@ -1913,7 +1901,6 @@ config FIND_BIT_BENCHMARK
 
 config TEST_FIRMWARE
tristate "Test firmware loading via userspace interface"
-   default n
depends on FW_LOADER
help
  This builds the "test_firmware" module that creates a userspace
@@ -1926,7 +1913,6 @@ config TEST_FIRMWARE
 
 config TEST_SYSCTL
tristate "sysctl test driver"
-   default n
depends on PROC_SYSCTL
help
  This builds the "test_sysctl" module. This driver enables to test the
@@ -1937,7 +1923,6 @@ config TEST_SYSCTL
 
 config TEST_UDELAY
tristate "udelay test driver"
-   default n
help
  This builds the "udelay_test" module that helps to make sure
  that udelay() is working properly.
@@ -1946,7 +1931,6 @@ config TEST_UDELAY
 
 config TEST_STATIC_KEYS
tristate "Test static keys"
-   default n
depen

Re: NULL pointer dereference in msi_set_mask_bit

2018-07-19 Thread Paul Menzel
Dear Thomas,


On 07/18/18 22:05, Paul Menzel wrote:

> Am 18.07.2018 um 21:00 schrieb Thomas Gleixner:
> 
>> On Wed, 18 Jul 2018, Paul Menzel wrote:
>>> On 07/18/18 17:39, Thomas Gleixner wrote:
 Bah. Could you please enable GENERIC_IRQ_DEBUGFS and after a successful
 boot up provide me the content of all files in /sys/kernel/debug/irq/ and
 its subfolders?
>>>
>>> Sure, please find them attached. `7zr x sys-kernel-debug-irq.7z` should
>>> extract it.
>>
>> It generates the files, but they are all size '1' and contain nothing.
> 
> Sorry, I do not know what I did wrong. I’ll try it again tomorrow.

Strange `sudo tar cf sys-kernel-debug-irq.tar /sys/kernel/debug/irq` had the
same problem.

I had to copy the files, and then was able to create an archive with
non-zero files. Please find the tar archive attached.


Kind regards,

Paul


sys-kernel-debug-irq.tar
Description: Unix tar archive


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH V3 0/4] KVM/x86/hyper-V: Introduce PV guest address space mapping flush support

2018-07-19 Thread Paolo Bonzini
On 19/07/2018 10:39, Tianyu Lan wrote:
> Hyper-V provides a para-virtualization hypercall 
> HvFlushGuestPhysicalAddressSpace
> to flush nested VM address space mapping in l1 hypervisor and it's to reduce 
> overhead
> of flushing ept tlb among vcpus. The tradition way is to send IPIs to all 
> affected
> vcpus and executes INVEPT on each vcpus. It will trigger several vmexits for 
> IPI and
> INVEPT emulation. The pv hypercall can help to flush specified ept table on 
> all vcpus
> via one single hypercall.

Thanks, this looks good apart from a global replace of EFAULT with
ENOTSUP (which can be done when applying).  Can I have an explicit ack
for patches 1 and 2 from the Hyper-V people?

Thanks,

Paolo

> Change since v2:
>- Make ept_pointers_match as tristate "check", "match" and "mismatch".
>Set "check" in vmx_set_cr3(), check all ept table pointers in 
> hv_remote_flush_tlb()
>and call hypercall when all ept pointers are same.
>- Rename kvm_arch_hv_flush_remote_tlb with kvm_arch_flush_remote_tlb 
> and
>Rename kvm_x86_ops->hv_tlb_remote_flush with 
> kvm_x86_ops->tlb_remote_flush
>- Fix issue that ignore updating tlbs_dirty during calling 
> kvm_arch_flush_remote_tlbs()
>- Merge patch "KVM/VMX: Add identical ept table pointer check" and
>patch "KVM/x86: Add tlb_remote_flush callback support for vmx"
> 
> Change since v1:
>- Fix compilation error for non-x86 platform.
>- Use ept_pointers_match to check condition of identical ept
> table pointer and get ept pointer from struct 
> vcpu_vmx->ept_pointer.
>- Add hyperv_nested_flush_guest_mapping ftrace support
>
> 
> 
> Lan Tianyu (4):
>   X86/Hyper-V: Add flush HvFlushGuestPhysicalAddressSpace hypercall
> support
>   X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace support
>   KVM: Add tlb remote flush callback in kvm_x86_ops.
>   KVM/x86: Add tlb_remote_flush callback support for vmx
> 
>  arch/x86/hyperv/Makefile|  2 +-
>  arch/x86/hyperv/nested.c| 67 ++
>  arch/x86/include/asm/hyperv-tlfs.h  |  8 +
>  arch/x86/include/asm/kvm_host.h | 11 ++
>  arch/x86/include/asm/mshyperv.h |  2 ++
>  arch/x86/include/asm/trace/hyperv.h | 14 
>  arch/x86/kvm/vmx.c  | 72 
> -
>  include/linux/kvm_host.h|  7 
>  virt/kvm/kvm_main.c |  3 +-
>  9 files changed, 183 insertions(+), 3 deletions(-)
>  create mode 100644 arch/x86/hyperv/nested.c
> 



Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

2018-07-19 Thread Jan Kara
On Thu 19-07-18 16:17:26, Chengguang Xu wrote:
> When we try to truncate read count in generic_file_buffered_read(),
> should deliver (sb->s_maxbytes - offset) as maximum count not
> sb->s_maxbytes itself.
> 
> Signed-off-by: Chengguang Xu 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

BTW, I can see you didn't include two (I'd say the most important ;)
addresses to CC: Al Viro as a VFS maintainer and linux-fsdevel mailing
list. Although this code resides in mm/ it is in fact a filesystem code.
Added now.

Honza

> ---
>  mm/filemap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 52517f28e6f4..5c2d481d21cf 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2064,7 +2064,7 @@ static ssize_t generic_file_buffered_read(struct kiocb 
> *iocb,
>  
>   if (unlikely(*ppos >= inode->i_sb->s_maxbytes))
>   return 0;
> - iov_iter_truncate(iter, inode->i_sb->s_maxbytes);
> + iov_iter_truncate(iter, inode->i_sb->s_maxbytes - *ppos);
>  
>   index = *ppos >> PAGE_SHIFT;
>   prev_index = ra->prev_pos >> PAGE_SHIFT;
> -- 
> 2.17.1
> 
-- 
Jan Kara 
SUSE Labs, CR


Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables

2018-07-19 Thread Jerome Brunet
On Thu, 2018-07-19 at 10:44 +0200, Neil Armstrong wrote:
> We could even add ranges instead of table when we know the PLL supports a 
> well-known continuous dividers range.

I was thinking about this too.
I did not went for it because it would mean yet another rework of the pll
driver, which I did not had time to do now.

I suspect that the min and max value of 'm' the pll can lock on might depend on
the input rate of the DCO, so past the 'n' prediv.

So, to replace the tuple (m, n) table with ranges, I think it would be best to
take the predivider 'n' out first and try to clarify the contraints on the input
rate of the DCO with amlogic ... we can also try and see ;)

> 
> Acked-by: Neil Armstrong 



Re: [PATCHv5 06/19] mm/khugepaged: Handle encrypted pages

2018-07-19 Thread Kirill A. Shutemov
On Wed, Jul 18, 2018 at 04:11:57PM -0700, Dave Hansen wrote:
> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> > khugepaged allocates page in advance, before we found a VMA for
> > collapse. We don't yet know which KeyID to use for the allocation.
> 
> That's not really true.  We have the VMA and the address in the caller
> (khugepaged_scan_pmd()), but we drop the lock and have to revalidate the
> VMA.

For !NUMA we allocate the page in khugepaged_do_scan(), well before we
know VMA.

> 
> 
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index 5ae34097aed1..d116f4ebb622 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -1056,6 +1056,16 @@ static void collapse_huge_page(struct mm_struct *mm,
> >  */
> > anon_vma_unlock_write(vma->anon_vma);
> >  
> > +   /*
> > +* At this point new_page is allocated as non-encrypted.
> > +* If VMA's KeyID is non-zero, we need to prepare it to be encrypted
> > +* before coping data.
> > +*/
> > +   if (vma_keyid(vma)) {
> > +   prep_encrypted_page(new_page, HPAGE_PMD_ORDER,
> > +   vma_keyid(vma), false);
> > +   }
> 
> I guess this isn't horribly problematic now, but if we ever keep pools
> of preassigned-keyids, this won't work any more.

I don't get this. What pools of preassigned-keyids are you talking about?

-- 
 Kirill A. Shutemov


Re: [PATCH v2 0/2] add ISO7816 support

2018-07-19 Thread Neil Armstrong
Hi Ludovic,

On 19/07/2018 10:47, Ludovic Desroches wrote:
> Hi,
> 
> This patchset adds support for the ISO7816 standard. The USART devices in
> Microchip SoCs have an ISO7816 mode. It allows to let the USART managing
> the CLK and I/O signals of a smart card.

Wow, I would have loved to have this at the time...
I'm curious, do you have an example of userspace code using this ?
The ATR rx needs a very weird handling, I'm curious how you managed it.

Thanks,
Neil

> 
> Changes:
> - v2
>   - uart_get_iso7816_config: check there is an iso7816_config function
>   - use IOCTL macros to generate the IOCTL number
>   - check that reserved field is not used
>   - remove debug logs
>   - check that the iso7816_config is right before doing any action
>   - change the error from nack and max iteration status to a debug message
>   - remove patch 3 as it concerns both rs485 and iso7816 to think more
>   about the need of adding a lock or not
> 
> Nicolas Ferre (2):
>   tty/serial_core: add ISO7816 infrastructure
>   tty/serial: atmel: add ISO7816 support
> 
>  arch/alpha/include/uapi/asm/ioctls.h   |   2 +
>  arch/mips/include/uapi/asm/ioctls.h|   2 +
>  arch/powerpc/include/uapi/asm/ioctls.h |   2 +
>  arch/sh/include/uapi/asm/ioctls.h  |   2 +
>  arch/sparc/include/uapi/asm/ioctls.h   |   2 +
>  arch/xtensa/include/uapi/asm/ioctls.h  |   2 +
>  drivers/tty/serial/atmel_serial.c  | 170 
> +++--
>  drivers/tty/serial/atmel_serial.h  |   3 +-
>  drivers/tty/serial/serial_core.c   |  60 
>  include/linux/serial_core.h|   3 +
>  include/uapi/asm-generic/ioctls.h  |   2 +
>  include/uapi/linux/serial.h|  17 
>  12 files changed, 256 insertions(+), 11 deletions(-)
> 



RE: [PATCH] pinctrl: uniphier: add spi pin-mux settings

2018-07-19 Thread Keiji Hayashibara
Hi,

Sorry.
I will fix this and send v2 patch.

Thank you.

Best Regards,
Keiji Hayashibara

> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: Thursday, July 19, 2018 5:02 PM
> To: Hayashibara, Keiji/林原 啓二 
> Cc: kbuild-...@01.org; linus.wall...@linaro.org; Yamada, Masahiro/山田 真弘 
> ;
> linux-g...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
> masami.hirama...@linaro.org;
> jaswinder.si...@linaro.org; linux-kernel@vger.kernel.org; Hayashibara, 
> Keiji/林原 啓二
> ; Hayashi, Kunihiko/林 邦彦 
> 
> Subject: Re: [PATCH] pinctrl: uniphier: add spi pin-mux settings
>
> Hi Kunihiko,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on pinctrl/devel] [also build test WARNING on 
> v4.18-rc5 next-20180718] [if your patch
> is applied to the wrong git tree, please drop us a note to help improve the 
> system]
>
> url:
> https://github.com/0day-ci/linux/commits/Keiji-Hayashibara/pinctrl-uniphier-add-spi-pin-mux-settings/2018071
> 9-144943
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-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
> GCC_VERSION=7.2.0 make.cross ARCH=mips
>
> All warnings (new ones prefixed by >>):
>
>In file included from 
> drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:21:0:
>drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:629:27: error: 
> 'spi0_groups' undeclared here (not in a
> function); did you mean 'spi_groups'?
>  UNIPHIER_PINMUX_FUNCTION(spi0),
>   ^
>drivers/pinctrl/uniphier/pinctrl-uniphier.h:188:13: note: in definition of 
> macro 'UNIPHIER_PINMUX_FUNCTION'
>   .groups = func##_groups,\
> ^~~~
>In file included from include/linux/kernel.h:15:0,
> from drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:16:
>include/linux/build_bug.h:29:45: error: bit-field '' width not 
> an integer constant
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
> ^
>include/linux/compiler-gcc.h:65:28: note: in expansion of macro 
> 'BUILD_BUG_ON_ZERO'
> #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>^
>include/linux/kernel.h:72:59: note: in expansion of macro '__must_be_array'
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>   ^~~
> >> drivers/pinctrl/uniphier/pinctrl-uniphier.h:189:17: note: in expansion of 
> >> macro 'ARRAY_SIZE'
>   .num_groups = ARRAY_SIZE(func##_groups),  \
> ^~
> >> drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c:629:2: note: in expansion 
> >> of macro
> 'UNIPHIER_PINMUX_FUNCTION'
>  UNIPHIER_PINMUX_FUNCTION(spi0),
>  ^~~~
>
> vim +/UNIPHIER_PINMUX_FUNCTION +629 
> drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c
>
>618
>619static const struct uniphier_pinmux_function 
> uniphier_sld8_functions[] = {
>620UNIPHIER_PINMUX_FUNCTION(emmc),
>621UNIPHIER_PINMUX_FUNCTION(ether_mii),
>622UNIPHIER_PINMUX_FUNCTION(ether_rmii),
>623UNIPHIER_PINMUX_FUNCTION(i2c0),
>624UNIPHIER_PINMUX_FUNCTION(i2c1),
>625UNIPHIER_PINMUX_FUNCTION(i2c2),
>626UNIPHIER_PINMUX_FUNCTION(i2c3),
>627UNIPHIER_PINMUX_FUNCTION(nand),
>628UNIPHIER_PINMUX_FUNCTION(sd),
>  > 629UNIPHIER_PINMUX_FUNCTION(spi0),
>630UNIPHIER_PINMUX_FUNCTION(system_bus),
>631UNIPHIER_PINMUX_FUNCTION(uart0),
>632UNIPHIER_PINMUX_FUNCTION(uart1),
>633UNIPHIER_PINMUX_FUNCTION(uart2),
>634UNIPHIER_PINMUX_FUNCTION(uart3),
>635UNIPHIER_PINMUX_FUNCTION(usb0),
>636UNIPHIER_PINMUX_FUNCTION(usb1),
>637UNIPHIER_PINMUX_FUNCTION(usb2),
>638};
>639
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation




Re: [PATCH v2 2/2] arm64: dts: Add Mediatek X20 Development Board support

2018-07-19 Thread Matthias Brugger



On 18/07/18 18:43, Manivannan Sadhasivam wrote:
> Hi Matthias,
> 
> On Wed, Jul 18, 2018 at 05:07:38PM +0200, Matthias Brugger wrote:
>>
>>
>> On 17/07/18 16:04, Manivannan Sadhasivam wrote:
>>> Hi Matthias,
>>>
>>> On Mon, Jul 16, 2018 at 03:24:44PM +0200, Matthias Brugger wrote:
 Hi Manivanna,

 On 05/06/18 18:34, Manivannan Sadhasivam wrote:
> Add initial device tree support for Mediatek X20 Development Board
> based on MT6797 Deca core SoC. This board is one of the 96Boards
> Consumer Edition platform.
>
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  arch/arm64/boot/dts/mediatek/Makefile |  1 +
>  .../boot/dts/mediatek/mt6797-x20-dev.dts  | 33 +++
>  2 files changed, 34 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
> b/arch/arm64/boot/dts/mediatek/Makefile
> index ac17f60f998c..5b7fd6ad96e4 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts 
> b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> new file mode 100644
> index ..2c09ca95d9e2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for MediaTek X20 Development Board
> + *
> + * Copyright (C) 2018, Linaro Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "mt6797.dtsi"
> +
> +/ {
> + model = "Mediatek X20 Development Board";
> + compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
> +
> + aliases {
> + serial0 = &uart1;
> + };

 Sorry for the late answer.
 Why did you use uart1 instead of uart0?
 I know that uart0 is used by the bootloader, but because of their exotic 
 flash
 procedure I find it quite useful to see this messages in my serial 
 connection.
 Of course you can only use 921600 baudrate then.

>>>
>>> The reason is, most of the Mezzanine boards use USB to UART bridge on the
>>> UART1 port available on the Low Speed Expansion header. Additionally, the
>>> convention followed by most of the Consumer Edition 96Boards is to use UART1
>>> as the debug serial port. That's why eventhough the bootloader is using 
>>> UART0,
>>> I forced the kernel to use UART1.
>>>
>>
>> Sounds reasonable, I don't have this 96 boards adapter and I forgot about it.
>>
> 
> That's fine :)
> 
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0 0x4000 0 0x1e605000>;

 How comes this strange number for the memory size?

>>>
>>> Actually, the memory size is extracted from the downstream kernel [1].
>>>
>>
>> Hm, Archermind "Helio X20 Development Board Hardware Manual" talks about 2GB
>> LPDDR3-SDRAM. Would you mind to check if that is actually true?
>>
> 
> Yes, it is 2GB. Shall I change the size to 0x8000?
> 

Best would be if you boot the machine with this value and see if things look
sane. Then resubmit. The other option is to resubmit and I'll check it tomorrow 
:)

Let me know if you can't do it for tomorrow morning. I plan to submit the pull
requests tomorrow as I'm through nearly all open patches (yes, two days earlier
\o/ )

Best regards,
Matthias

> Thanks,
> Mani
> 
 BTW do you know the differences between the EVB board and the x20 one?
 I used the evb dts for booting up to now.

>>>
>>> Sorry, I don't know the difference between both boards!
>>
>> Sure, no problem :)
>>
>> Regards,
>> Matthias
>>
>>>
>>> Thanks,
>>> Mani
>>>
>>> [1] 
>>> https://github.com/helio-x20/linux/blob/helio-x20/arch/arm64/boot/dts/amt6797_64_open.dts#L8
>>>
 Best regards,
 Matthias

> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
>


[PATCH v2] pinctrl: uniphier: add spi pin-mux settings

2018-07-19 Thread Keiji Hayashibara
From: Kunihiko Hayashi 

Add pin-mux settings for spi controller.

Signed-off-by: Kunihiko Hayashi 
Signed-off-by: Keiji Hayashibara 
---
 Changes since v1:
 - Fix build error of "pinctrl-uniphier-sld8.c".

 drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 10 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 20 
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c  |  5 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c | 10 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 10 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 15 +++
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c | 10 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs3.c | 10 ++
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c |  5 +
 9 files changed, 95 insertions(+)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
index 58825f6..bce533f 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
@@ -517,6 +517,10 @@ static const int i2c4_muxvals[] = {1, 1};
 static const unsigned nand_pins[] = {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
 15, 16, 17};
 static const int nand_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0};
+static const unsigned spi0_pins[] = {56, 57, 58, 59};
+static const int spi0_muxvals[] = {0, 0, 0, 0};
+static const unsigned spi1_pins[] = {169, 170, 171, 172};
+static const int spi1_muxvals[] = {1, 1, 1, 1};
 static const unsigned system_bus_pins[] = {1, 2, 6, 7, 8, 9, 10, 11, 12, 13,
   14, 15, 16, 17};
 static const int system_bus_muxvals[] = {0, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
@@ -596,6 +600,8 @@ static const struct uniphier_pinctrl_group 
uniphier_ld11_groups[] = {
UNIPHIER_PINCTRL_GROUP(i2c3),
UNIPHIER_PINCTRL_GROUP(i2c4),
UNIPHIER_PINCTRL_GROUP(nand),
+   UNIPHIER_PINCTRL_GROUP(spi0),
+   UNIPHIER_PINCTRL_GROUP(spi1),
UNIPHIER_PINCTRL_GROUP(system_bus),
UNIPHIER_PINCTRL_GROUP(system_bus_cs1),
UNIPHIER_PINCTRL_GROUP(uart0),
@@ -632,6 +638,8 @@ static const char * const i2c1_groups[] = {"i2c1"};
 static const char * const i2c3_groups[] = {"i2c3"};
 static const char * const i2c4_groups[] = {"i2c4"};
 static const char * const nand_groups[] = {"nand"};
+static const char * const spi0_groups[] = {"spi0"};
+static const char * const spi1_groups[] = {"spi1"};
 static const char * const system_bus_groups[] = {"system_bus",
 "system_bus_cs1"};
 static const char * const uart0_groups[] = {"uart0"};
@@ -657,6 +665,8 @@ static const struct uniphier_pinmux_function 
uniphier_ld11_functions[] = {
UNIPHIER_PINMUX_FUNCTION(i2c3),
UNIPHIER_PINMUX_FUNCTION(i2c4),
UNIPHIER_PINMUX_FUNCTION(nand),
+   UNIPHIER_PINMUX_FUNCTION(spi0),
+   UNIPHIER_PINMUX_FUNCTION(spi1),
UNIPHIER_PINMUX_FUNCTION(system_bus),
UNIPHIER_PINMUX_FUNCTION(uart0),
UNIPHIER_PINMUX_FUNCTION(uart1),
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index 9f449b3..99f06fe 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -606,6 +606,14 @@ static const unsigned nand_pins[] = {3, 4, 5, 6, 7, 8, 9, 
10, 11, 12, 13, 14,
 static const int nand_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0};
 static const unsigned sd_pins[] = {10, 11, 12, 13, 14, 15, 16, 17};
 static const int sd_muxvals[] = {3, 3, 3, 3, 3, 3, 3, 3};  /* No SDVOLC */
+static const unsigned spi0_pins[] = {56, 57, 58, 59};
+static const int spi0_muxvals[] = {0, 0, 0, 0};
+static const unsigned spi1_pins[] = {169, 170, 171, 172};
+static const int spi1_muxvals[] = {1, 1, 1, 1};
+static const unsigned spi2_pins[] = {86, 87, 88, 89};
+static const int spi2_muxvals[] = {1, 1, 1, 1};
+static const unsigned spi3_pins[] = {74, 75, 76, 77};
+static const int spi3_muxvals[] = {1, 1, 1, 1};
 static const unsigned system_bus_pins[] = {1, 2, 6, 7, 8, 9, 10, 11, 12, 13,
   14, 15, 16, 17};
 static const int system_bus_muxvals[] = {0, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
@@ -685,6 +693,10 @@ static const struct uniphier_pinctrl_group 
uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP(i2c4),
UNIPHIER_PINCTRL_GROUP(nand),
UNIPHIER_PINCTRL_GROUP(sd),
+   UNIPHIER_PINCTRL_GROUP(spi0),
+   UNIPHIER_PINCTRL_GROUP(spi1),
+   UNIPHIER_PINCTRL_GROUP(spi2),
+   UNIPHIER_PINCTRL_GROUP(spi3),
UNIPHIER_PINCTRL_GROUP(system_bus),
UNIPHIER_PINCTRL_GROUP(system_bus_cs1),
UNIPHIER_PINCTRL_GROUP(uart0),
@@ -722,6 +734,10 @@ static const char * const i2c3_groups[] = {"i2c3"};
 static const char * const i2c4_groups[] = {"i2c4"};
 st

[PATCH v7 5/5] arm64: dts: actions: Set UART clock reference from CMU

2018-07-19 Thread Saravanan Sekar
Signed-off-by: Parthiban Nallathambi 
Signed-off-by: Saravanan Sekar 
Reviewed-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts 
b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index ef79d7905f44..c08808ca3346 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -28,12 +28,6 @@
device_type = "memory";
reg = <0x1 0xe000 0x0 0x0>;
};
-
-   uart3_clk: uart3-clk {
-   compatible = "fixed-clock";
-   clock-frequency = <921600>;
-   #clock-cells = <0>;
-   };
 };
 
 &timer {
@@ -42,5 +36,5 @@
 
 &uart3 {
status = "okay";
-   clocks = <&uart3_clk>;
+   clocks = <&cmu CLK_UART3>;
 };
-- 
2.14.4



[PATCH v7 0/5] Add clock driver for Actions S700 SoC

2018-07-19 Thread Saravanan Sekar
This patchset adds clock support for Actions Semi Owl series S700 SoC
with relevant clock bindings and device tree info. 

Changed the UART clock using CMU instance and changes are tested in
cubieboard7

Changelog v7:
- Moved cmu (clock controller) dts entry under soc node and
positioned based on address

Changelog v6:
- Adding Fixes tag for adding REGMAP dependency addition

Changelog v5:
- Commit message corrections
- Removed MMC_OWL_CLK_NANDPLL option, as no active consumer
- Device tree clock label name correction

Changelog v4:
- dt-bindings use absolute numbering for clocks
- Patch re-oredering

Changelog v3:
- Splitted uart clock DTS changes into separate patch
- Splitted REGMAP Kconfig selection into separate patch
- General naming convention as "Actions Semi" in dt-binding documentation
- Patch re-oredering
- Cleanup and fixed review findings

Changelog v2:
Fixed 0 day compilation warning
Modified existing dts Actions S900 clock bindings common to Actions
Soc family

Thanks and regards,
Saravanan,
Parthiban


Saravanan Sekar (5):
  clk: actions: Add missing REGMAP_MMIO dependency
  dt-bindings: clock: Add S700 support for Actions Semi Soc's
  clk: actions: Add S700 SoC clock support
  arm64: dts: actions: Add Clock Management Unit for S700
  arm64: dts: actions: Set UART clock reference from CMU

 .../{actions,s900-cmu.txt => actions,owl-cmu.txt}  |  20 +-
 arch/arm64/boot/dts/actions/s700-cubieboard7.dts   |   8 +-
 arch/arm64/boot/dts/actions/s700.dtsi  |  14 +
 drivers/clk/actions/Kconfig|   7 +
 drivers/clk/actions/Makefile   |   1 +
 drivers/clk/actions/owl-s700.c | 606 +
 include/dt-bindings/clock/actions,s700-cmu.h   | 118 
 7 files changed, 758 insertions(+), 16 deletions(-)
 rename Documentation/devicetree/bindings/clock/{actions,s900-cmu.txt => 
actions,owl-cmu.txt} (68%)
 create mode 100644 drivers/clk/actions/owl-s700.c
 create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h

-- 
2.14.4



[PATCH v7 2/5] dt-bindings: clock: Add S700 support for Actions Semi Soc's

2018-07-19 Thread Saravanan Sekar
Add clock bindings constants for action S700
Maintain common clock dt-bindings for Actions Semi SoC's
S700 and S900.

Signed-off-by: Parthiban Nallathambi 
Signed-off-by: Saravanan Sekar 
Reviewed-by: Rob Herring 
---
 .../{actions,s900-cmu.txt => actions,owl-cmu.txt}  |  20 ++--
 include/dt-bindings/clock/actions,s700-cmu.h   | 118 +
 2 files changed, 129 insertions(+), 9 deletions(-)
 rename Documentation/devicetree/bindings/clock/{actions,s900-cmu.txt => 
actions,owl-cmu.txt} (68%)
 create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h

diff --git a/Documentation/devicetree/bindings/clock/actions,s900-cmu.txt 
b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
similarity index 68%
rename from Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
rename to Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
index 93e4fb827cd6..d1e60d297387 100644
--- a/Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
+++ b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
@@ -1,12 +1,14 @@
-* Actions S900 Clock Management Unit (CMU)
+* Actions Semi Owl Clock Management Unit (CMU)
 
-The Actions S900 clock management unit generates and supplies clock to various
-controllers within the SoC. The clock binding described here is applicable to
-S900 SoC.
+The Actions Semi Owl Clock Management Unit generates and supplies clock
+to various controllers within the SoC. The clock binding described here is
+applicable to S900 and S700 SoC's.
 
 Required Properties:
 
-- compatible: should be "actions,s900-cmu"
+- compatible: should be one of the following,
+   "actions,s900-cmu"
+   "actions,s700-cmu"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - clocks: Reference to the parent clocks ("hosc", "losc")
@@ -15,16 +17,16 @@ Required Properties:
 Each clock is assigned an identifier, and client nodes can use this identifier
 to specify the clock which they consume.
 
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/actions,s900-cmu.h header and can be used in device
-tree sources.
+All available clocks are defined as preprocessor macros in corresponding
+dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h header and can be
+used in device tree sources.
 
 External clocks:
 
 The hosc clock used as input for the plls is generated outside the SoC. It is
 expected that it is defined using standard clock bindings as "hosc".
 
-Actions S900 CMU also requires one more clock:
+Actions Semi S900 CMU also requires one more clock:
  - "losc" - internal low frequency oscillator
 
 Example: Clock Management Unit node:
diff --git a/include/dt-bindings/clock/actions,s700-cmu.h 
b/include/dt-bindings/clock/actions,s700-cmu.h
new file mode 100644
index ..3e1942996724
--- /dev/null
+++ b/include/dt-bindings/clock/actions,s700-cmu.h
@@ -0,0 +1,118 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Device Tree binding constants for Actions Semi S700 Clock Management Unit
+ *
+ * Copyright (c) 2014 Actions Semi Inc.
+ * Author: David Liu 
+ *
+ * Author: Pathiban Nallathambi 
+ * Author: Saravanan Sekar 
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_S700_H
+#define __DT_BINDINGS_CLOCK_S700_H
+
+#define CLK_NONE   0
+
+/* pll clocks */
+#define CLK_CORE_PLL   1
+#define CLK_DEV_PLL2
+#define CLK_DDR_PLL3
+#define CLK_NAND_PLL   4
+#define CLK_DISPLAY_PLL5
+#define CLK_TVOUT_PLL  6
+#define CLK_CVBS_PLL   7
+#define CLK_AUDIO_PLL  8
+#define CLK_ETHERNET_PLL   9
+
+/* system clock */
+#define CLK_CPU10
+#define CLK_DEV11
+#define CLK_AHB12
+#define CLK_APB13
+#define CLK_DMAC   14
+#define CLK_NOC0_CLK_MUX   15
+#define CLK_NOC1_CLK_MUX   16
+#define CLK_HP_CLK_MUX 17
+#define CLK_HP_CLK_DIV 18
+#define CLK_NOC1_CLK_DIV   19
+#define CLK_NOC0   20
+#define CLK_NOC1   21
+#define CLK_SENOR_SRC  22
+
+/* peripheral device clock */
+#define CLK_GPIO   23
+#define CLK_TIMER  24
+#define CLK_DSI25
+#define CLK_CSI26
+#define CLK_SI 27
+#define CLK_DE 28
+#define CLK_HDE29
+#define CLK_VDE30
+#define CLK_VCE31
+#define CLK_NAND   32
+#define CLK_SD033
+#define CLK_SD134
+#define CLK_SD235
+
+#define C

[PATCH v7 1/5] clk: actions: Add missing REGMAP_MMIO dependency

2018-07-19 Thread Saravanan Sekar
Add REGMAP_MMIO as dependency to avoid undefined
reference to regmap symbols.

Fixes: d85d20053e19 ("clk: actions: Add S900 SoC clock support")
Signed-off-by: Saravanan Sekar 
Reviewed-by: Andreas Färber 
Reviewed-by: Manivannan Sadhasivam 
---
 drivers/clk/actions/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
index 8854adb37847..39491154abbf 100644
--- a/drivers/clk/actions/Kconfig
+++ b/drivers/clk/actions/Kconfig
@@ -1,6 +1,7 @@
 config CLK_ACTIONS
bool "Clock driver for Actions Semi SoCs"
depends on ARCH_ACTIONS || COMPILE_TEST
+   select REGMAP_MMIO
default ARCH_ACTIONS
 
 if CLK_ACTIONS
-- 
2.14.4



[PATCH v7 3/5] clk: actions: Add S700 SoC clock support

2018-07-19 Thread Saravanan Sekar
Add Actions Semi S700 SoC clock support

Signed-off-by: Parthiban Nallathambi 
Signed-off-by: Saravanan Sekar 
Reviewed-by: Manivannan Sadhasivam 
---
 drivers/clk/actions/Kconfig|   6 +
 drivers/clk/actions/Makefile   |   1 +
 drivers/clk/actions/owl-s700.c | 606 +
 3 files changed, 613 insertions(+)
 create mode 100644 drivers/clk/actions/owl-s700.c

diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
index 39491154abbf..dc38c85a4833 100644
--- a/drivers/clk/actions/Kconfig
+++ b/drivers/clk/actions/Kconfig
@@ -8,8 +8,14 @@ if CLK_ACTIONS
 
 # SoC Drivers
 
+config CLK_OWL_S700
+   bool "Support for the Actions Semi OWL S700 clocks"
+   depends on (ARM64 && ARCH_ACTIONS) || COMPILE_TEST
+   default ARM64 && ARCH_ACTIONS
+
 config CLK_OWL_S900
bool "Support for the Actions Semi OWL S900 clocks"
depends on (ARM64 && ARCH_ACTIONS) || COMPILE_TEST
default ARM64 && ARCH_ACTIONS
+
 endif
diff --git a/drivers/clk/actions/Makefile b/drivers/clk/actions/Makefile
index 76e431434d10..78c17d56f991 100644
--- a/drivers/clk/actions/Makefile
+++ b/drivers/clk/actions/Makefile
@@ -9,4 +9,5 @@ clk-owl-y   += owl-composite.o
 clk-owl-y  += owl-pll.o
 
 # SoC support
+obj-$(CONFIG_CLK_OWL_S700) += owl-s700.o
 obj-$(CONFIG_CLK_OWL_S900) += owl-s900.o
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
new file mode 100644
index ..5e9531392ee5
--- /dev/null
+++ b/drivers/clk/actions/owl-s700.c
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi S700 clock driver
+ *
+ * Copyright (c) 2014 Actions Semi Inc.
+ * Author: David Liu 
+ *
+ * Author: Pathiban Nallathambi 
+ * Author: Saravanan Sekar 
+ */
+
+#include 
+#include 
+
+#include "owl-common.h"
+#include "owl-composite.h"
+#include "owl-divider.h"
+#include "owl-factor.h"
+#include "owl-fixed-factor.h"
+#include "owl-gate.h"
+#include "owl-mux.h"
+#include "owl-pll.h"
+
+#include 
+
+#define CMU_COREPLL(0x)
+#define CMU_DEVPLL (0x0004)
+#define CMU_DDRPLL (0x0008)
+#define CMU_NANDPLL(0x000C)
+#define CMU_DISPLAYPLL (0x0010)
+#define CMU_AUDIOPLL   (0x0014)
+#define CMU_TVOUTPLL   (0x0018)
+#define CMU_BUSCLK (0x001C)
+#define CMU_SENSORCLK  (0x0020)
+#define CMU_LCDCLK (0x0024)
+#define CMU_DSIPLLCLK  (0x0028)
+#define CMU_CSICLK (0x002C)
+#define CMU_DECLK  (0x0030)
+#define CMU_SICLK  (0x0034)
+#define CMU_BUSCLK1(0x0038)
+#define CMU_HDECLK (0x003C)
+#define CMU_VDECLK (0x0040)
+#define CMU_VCECLK (0x0044)
+#define CMU_NANDCCLK   (0x004C)
+#define CMU_SD0CLK (0x0050)
+#define CMU_SD1CLK (0x0054)
+#define CMU_SD2CLK (0x0058)
+#define CMU_UART0CLK   (0x005C)
+#define CMU_UART1CLK   (0x0060)
+#define CMU_UART2CLK   (0x0064)
+#define CMU_UART3CLK   (0x0068)
+#define CMU_UART4CLK   (0x006C)
+#define CMU_UART5CLK   (0x0070)
+#define CMU_UART6CLK   (0x0074)
+#define CMU_PWM0CLK(0x0078)
+#define CMU_PWM1CLK(0x007C)
+#define CMU_PWM2CLK(0x0080)
+#define CMU_PWM3CLK(0x0084)
+#define CMU_PWM4CLK(0x0088)
+#define CMU_PWM5CLK(0x008C)
+#define CMU_GPU3DCLK   (0x0090)
+#define CMU_CORECTL(0x009C)
+#define CMU_DEVCLKEN0  (0x00A0)
+#define CMU_DEVCLKEN1  (0x00A4)
+#define CMU_DEVRST0(0x00A8)
+#define CMU_DEVRST1(0x00AC)
+#define CMU_USBPLL (0x00B0)
+#define CMU_ETHERNETPLL(0x00B4)
+#define CMU_CVBSPLL(0x00B8)
+#define CMU_SSTSCLK(0x00C0)
+
+static struct clk_pll_table clk_audio_pll_table[] = {
+   {0, 45158400}, {1, 49152000},
+   {0, 0},
+};
+
+static struct clk_pll_table clk_cvbs_pll_table[] = {
+   {27, 29 * 1200}, {28, 30 * 1200}, {29, 31 * 1200},
+   {30, 32 * 1200}, {31, 33 * 1200}, {32, 34 * 1200},
+   {33, 35 * 1200}, {34, 36 * 1200}, {35, 37 * 1200},
+   {36, 38 * 1200}, {37, 39 * 1200}, {38, 40 * 1200},
+   {39, 41 * 1200}, {40, 42 * 1200}, {41, 43 * 1200},
+   {42, 44 * 1200}, {43, 45 * 1200}, {0, 0},
+};
+
+/* pll clocks */
+static OWL_PLL_NO_PARENT(clk_core_pll,   "core_pll", CMU_COREPLL, 1200, 9, 
0, 8,  4, 174, NULL, CLK_IGNORE_UNUSED);
+static OWL_PLL_NO_PARENT(clk_dev_pll,"dev_pll", CMU_DEVPLL,  600, 8, 
0, 8, 8, 126, NULL, CLK_IGNORE_UNUSED);
+static OWL_PLL_NO_PARENT(clk_ddr_pll,"ddr_pll", CMU_DDRPLL, 600, 8, 0, 
8,  2,  180, NULL, CLK_IGNORE_UNUSED);
+static OWL_PLL_NO_PARENT(clk_nand_pll,   "nand_pll", CMU_NANDPLL,  600, 8, 
0, 8,  2, 86, NULL, CLK_IGNORE_UNUSE

[PATCH v7 4/5] arm64: dts: actions: Add Clock Management Unit for S700

2018-07-19 Thread Saravanan Sekar
Add Clock Management Unit for Actions Semi S700 SoC.

Signed-off-by: Parthiban Nallathambi 
Signed-off-by: Saravanan Sekar 
---
 arch/arm64/boot/dts/actions/s700.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s700.dtsi 
b/arch/arm64/boot/dts/actions/s700.dtsi
index 66dd5309f0a2..59d29e4ca404 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 
 / {
compatible = "actions,s700";
@@ -87,6 +88,12 @@
#clock-cells = <0>;
};
 
+   losc: losc {
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   #clock-cells = <0>;
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -153,6 +160,13 @@
status = "disabled";
};
 
+   cmu: clock-controller@e0168000 {
+   compatible = "actions,s700-cmu";
+   reg = <0x0 0xe0168000 0x0 0x1000>;
+   clocks = <&hosc>, <&losc>;
+   #clock-cells = <1>;
+   };
+
sps: power-controller@e01b0100 {
compatible = "actions,s700-sps";
reg = <0x0 0xe01b0100 0x0 0x100>;
-- 
2.14.4



Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

2018-07-19 Thread Yu Chen
On Wed, Jul 18, 2018 at 11:48:19PM +0800, joeyli wrote:
> On Fri, Jul 13, 2018 at 03:34:25PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> > > Hi Yu Chen, 
> > > 
> > > Sorry for my delay...
> > > 
> > > On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> [...snip]
> > > > > Why the cryption code must be indepent of snapshot code?
> > > > >
> > > > Modules can be easier to be maintained and customized/improved in the 
> > > > future IMO..
> > > 
> > > hm... currently I didn't see apparent benefit on this...
> > > 
> > > About modularization, is it possible to separate the key handler code
> > > from crypto_hibernation.c? Otherwise the snapshot signature needs
> > > to depend on encrypt function.
> > > 
> > I understand.
> > It seems that we can reuse crypto_data() for the signature logic.
> > For example, add one parameter for crypto_data(..., crypto_mode)
> > the crypto_mode is a combination of 
> > ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
> > and can be controled by sysfs. If SIGNATURE_START is enabled, the 
> > crypto_data()
> > invokes crypto_shash_update() to get "hmac(sha512)" hash, and if 
> > SIGNATURE_END
> > is enabled, crypto_shash_final() stores the final result in global buffer
> 
> I agree that the swsusp_prepare and hmac-hash codes can be extract to
> crypto_hibernation.  
> 
> > struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
> > passed to the restore kernel, the same as the salt. Besides,
> 
> The salt is stored in the swsusp_header and put in swap. What I want
> is that the signature of snapshot should be keep in the snapshot header
> as my original design in patch. The benefit is that the snapshot with
> signature can be stored to any place but not just swap. The user space
> can take snapshot image with signature to anywhere.
>
Okay, got it.
> > the swsusp_prepare_hash() in your code could be moved into
> > init_crypto_helper(), thus the signature key could also reuse
> > the same key passed from user space or via get_efi_secret_key().
> > In this way, the change in snapshot.c is minimal and the crypto
> > facilities could be maintained in one file.
> 
> I agree. But as I mentioned in that mail, the key handler codes
> in hibernation_crypto() should be extract to another C file to avoid
> the logic is mixed with the crypto code. The benefit is that we can
> add more key sources like encrypted key or EFI key in the future. 
> 
Ok, will extract the key handler code from this file.
> > > > > > 2. There's no need to traverse the snapshot image twice, if the
> > > > > >image is large(there's requirement on servers now) we can
> > > > > >simplyly do the encryption before the disk IO, and this is
> > > > > >why PATCH[2/3] looks like this.
> > > > > 
> > > > > If the encryption solution is only for block device, then the uswsusp
> > > > > interface must be locked-down when kernel is in locked mode:
> > > > > 
> > > > > uswsusp: Disable when the kernel is locked down
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410&id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > > > > 
> > > > > I still suggest to keep the solution to direct encript the snapshot
> > > > > image for uswsusp because the snapshot can be encrypted by kernel
> > > > > before user space get it.
> > > > > 
> > > > > I mean that if the uswsusp be used, then kernel direct encrypts the
> > > > > snapshot image, otherwise kernel encrypts pages before block io.
> > > > > 
> > > > I did not quite get the point, if the kernel has been locked down,
> > > > then the uswsusp is disabled, why the kernel encrypts the snapshot
> > > > for uswsusp?
> > > 
> > > There have some functions be locked-down because there have no
> > > appropriate mechanisms to check the integrity of writing data. If
> > > the snapshot image can be encrypted and authentication, then the
> > > uswsusp interface is avaiable for userspace. We do not need to lock
> > > it down.
> > Ok, I got your point. To be honest, I like your implementation to treat
> > the snapshot data seperately except that it might cause small overhead
> > when traversing large number of snapshot and make snapshot logic a little
> > coupling with crypto logic. Let me send our v2 using the 
> > crypto-before-blockio
> > for review and maybe change to your solution using the encapsulated APIs in
> > crypto_hibernate.c.
> 
> Because sometimes I stick on other topics...
> 
> If you are urgent for pushing your encryption solution. Please do not
> consider too much on signature check. Just complete your patches and push
> to kernel mainline. I will follow your result to respin my signature work.
> 
Thanks, I've just sent out another version before I noticed your
comment yesterday, let me address your concern in v3,
but please feel free to comment on v2.
Thanks,
Yu

> Thanks
> Joey Lee 


Re: [PATCH] ALSA: core: fix unsigned int pages overflow when comapred

2018-07-19 Thread Takashi Iwai
On Thu, 19 Jul 2018 08:42:14 +0200,
Takashi Iwai wrote:
> 
> On Thu, 19 Jul 2018 08:08:06 +0200,
> Zhang, Jun wrote:
> > 
> > Hello, Takashi
> > 
> > I think use our patch, it's NOT possible that the returned size is over 
> > sgbuf->tblsize.
> > 
> > In function snd_malloc_sgbuf_pages, 
> > 
> > Pages is align page,
> > sgbuf->tblsize is align 32*page,
> > chunk is align 2^n*page,
> > 
> > in our panic case, pages = 123, tlbsize = 128,  
> > 1st loop trunk = 32
> > 2nd loop trunk = 32
> > 3rd loop trunk = 32
> > 4th loop trunk = 16
> > 5th loop trunk = 16
> > So in 5th loop pages-trunk = -5, which make dead loop. 
> 
> Looking at the code again, yeah, you are right, that won't happen.
> 
> And now it becomes clear: the fundamental problem is that
> snd_dma_alloc_pages_fallback() returns a larger size than requested.
> It would be acceptable if the internal allocator aligns a larger size,
> but it shouldn't appear in the returned size outside.  I believe this
> was just a misunderstanding of get_order() usage there.
> (BTW, it's interesting that the allocation with a larger block worked
>  while allocation with a smaller chunk failed; it must be a rare case
>  and that's one of reasons this bug didn't hit frequently.)
> 
> That being said, what we should fix is rather the function
> snd_dma_alloc_pages_fallback() to behave as expected, and it'll be
> like the patch below.

And we can reduce even more lines.  A proper patch is below.


thanks,

Takashi

-- 8< --
From: Takashi Iwai 
Subject: [PATCH] ALSA: memalloc: Don't exceed over the requested size

snd_dma_alloc_pages_fallback() tries to allocate pages again when the
allocation fails with reduced size.  But the first try actually
*increases* the size to power-of-two, which may give back a larger
chunk than the requested size.  This confuses the callers, e.g. sgbuf
assumes that the size is equal or less, and it may result in a bad
loop due to the underflow and eventually lead to Oops.

The code of this function seems incorrectly assuming the usage of
get_order().  We need to decrease at first, then align to
power-of-two.

Reported-by: he, bo 
Reported-by: zhang jun 
Cc: 
Signed-off-by: Takashi Iwai 
---
 sound/core/memalloc.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c
index 7f89d3c79a4b..753d5fc4b284 100644
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -242,16 +242,12 @@ int snd_dma_alloc_pages_fallback(int type, struct device 
*device, size_t size,
int err;
 
while ((err = snd_dma_alloc_pages(type, device, size, dmab)) < 0) {
-   size_t aligned_size;
if (err != -ENOMEM)
return err;
if (size <= PAGE_SIZE)
return -ENOMEM;
-   aligned_size = PAGE_SIZE << get_order(size);
-   if (size != aligned_size)
-   size = aligned_size;
-   else
-   size >>= 1;
+   size >>= 1;
+   size = PAGE_SIZE << get_order(size);
}
if (! dmab->area)
return -ENOMEM;
-- 
2.18.0



Re: [tip:x86/mm] x86/mm/tlb: Make lazy TLB mode lazier

2018-07-19 Thread Peter Zijlstra
On Wed, Jul 18, 2018 at 02:51:45PM -0400, Rik van Riel wrote:

> > Ah, ok. I wasn't entirely sure the new lazy was purely for the idle
> > case. But yes, the KVM paravirt thing should get the idle case right.
> > 
> Not just idle, but also running in kernel threads like ksoftirqd,
> kworker, kswapd, etc.

Right, that's what I thought.

> However, kvm_flush_tlb_other calls
> native_flush_tlb_other, so it should get that optimization automatically
> from my patch series.

Aah, seems I forgot that part, then yes indeed, it all works.


[PATCH 1/6] drivers: qcom: rpmh-rsc: return if the controller is idle

2018-07-19 Thread Raju P L S S S N
From: Lina Iyer 

Allow the controller status be queried. The controller is busy if it is
actively processing request.

Signed-off-by: Lina Iyer 
Signed-off-by: Raju P.L.S.S.S.N 
---
 drivers/soc/qcom/rpmh-internal.h |  1 +
 drivers/soc/qcom/rpmh-rsc.c  | 21 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h
index a76..4ff43bf 100644
--- a/drivers/soc/qcom/rpmh-internal.h
+++ b/drivers/soc/qcom/rpmh-internal.h
@@ -108,6 +108,7 @@ struct rsc_drv {
 int rpmh_rsc_write_ctrl_data(struct rsc_drv *drv,
 const struct tcs_request *msg);
 int rpmh_rsc_invalidate(struct rsc_drv *drv);
+bool rpmh_rsc_ctrlr_is_idle(struct rsc_drv *drv);
 
 void rpmh_tx_done(const struct tcs_request *msg, int r);
 
diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 33fe9f9..e513c3c 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -496,6 +496,27 @@ static int tcs_ctrl_write(struct rsc_drv *drv, const 
struct tcs_request *msg)
 }
 
 /**
+ *  rpmh_rsc_ctrlr_is_idle: Check if any of the AMCs are busy.
+ *
+ *  @drv: The controller
+ *
+ *  Returns true if the TCSes are engaged in handling requests.
+ */
+bool rpmh_rsc_ctrlr_is_idle(struct rsc_drv *drv)
+{
+   int m;
+   struct tcs_group *tcs = get_tcs_of_type(drv, ACTIVE_TCS);
+
+   for (m = tcs->offset; m < tcs->offset + tcs->num_tcs; m++) {
+   if (!tcs_is_free(drv, m))
+   return false;
+   }
+
+   return true;
+}
+EXPORT_SYMBOL(rpmh_rsc_ctrlr_is_idle);
+
+/**
  * rpmh_rsc_write_ctrl_data: Write request to the controller
  *
  * @drv: the controller
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project



[PATCH 0/6] drivers/qcom: add additional functionality to RPMH

2018-07-19 Thread Raju P L S S S N
From: "Raju P.L.S.S.S.N" 

This set of patches add additional functionality to RPMH drivers[1].

PM drivers can choose to disallow idle modes when RSC controller is busy sending
or processing requests. The patches add necesary functions to query the 
controller status.

The controllers may be in 'solver' state, where they could be in autonomous
mode executing low power modes for their hardware and as such are not available
for sending active votes. Functionality to get notified about such state and 
disallow requests for state change in that case is added in these patches.

The Power Domain Controller can be programmed to wakeup the RSC and
setup the resources back in the active state, before the processor is
woken up by a timer interrupt. The wakeup value from the timer hardware
can be copied to the PDC which has its own timer and is in an always-on
power domain. Programming the wakeup value is done through a separate
register on the RSC. Fuctions necessary to program wakeup is added in
the patches.

Please consider reviewing this patchset.

[1] https://lkml.org/lkml/2018/6/20/519

Lina Iyer (5):
  drivers: qcom: rpmh-rsc: return if the controller is idle
  drivers: qcom: rpmh: export controller idle status
  drivers: qcom: rpmh: disallow active requests in solver mode
  drivers: qcom: rpmh-rsc: write PDC data
  drivers: qcom: rpmh: write PDC data

Raju P.L.S.S.S.N (1):
  drivers: qcom: rpmh-rsc: clear active mode configuration for waketcs

 drivers/soc/qcom/rpmh-internal.h |   6 ++
 drivers/soc/qcom/rpmh-rsc.c  | 134 ++-
 drivers/soc/qcom/rpmh.c  | 100 +
 include/soc/qcom/rpmh.h  |  16 +
 4 files changed, 227 insertions(+), 29 deletions(-)

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



[PATCH 2/6] drivers: qcom: rpmh: export controller idle status

2018-07-19 Thread Raju P L S S S N
From: Lina Iyer 

Allow the controller state be read by platform drivers. This is useful
for PM drivers which can choose to disallow idle modes when the
controller is busy.

Signed-off-by: Lina Iyer 
Signed-off-by: Raju P.L.S.S.S.N 
---
 drivers/soc/qcom/rpmh.c | 13 +
 include/soc/qcom/rpmh.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index c7beb68..2382276 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -511,3 +511,16 @@ int rpmh_invalidate(const struct device *dev)
return ret;
 }
 EXPORT_SYMBOL(rpmh_invalidate);
+
+/**
+ * rpmh_ctrlr_idle: Return the controller idle status
+ *
+ * @dev: the device making the request
+ */
+int rpmh_ctrlr_idle(const struct device *dev)
+{
+   struct rpmh_ctrlr *ctrlr = get_rpmh_ctrlr(dev);
+
+   return rpmh_rsc_ctrlr_is_idle(ctrlr_to_drv(ctrlr));
+}
+EXPORT_SYMBOL(rpmh_ctrlr_idle);
diff --git a/include/soc/qcom/rpmh.h b/include/soc/qcom/rpmh.h
index 619e07c..d445322 100644
--- a/include/soc/qcom/rpmh.h
+++ b/include/soc/qcom/rpmh.h
@@ -24,6 +24,8 @@ int rpmh_write_batch(const struct device *dev, enum 
rpmh_state state,
 
 int rpmh_invalidate(const struct device *dev);
 
+int rpmh_ctrlr_idle(const struct device *dev);
+
 #else
 
 static inline int rpmh_write(const struct device *dev, enum rpmh_state state,
@@ -46,6 +48,9 @@ static inline int rpmh_flush(const struct device *dev)
 static inline int rpmh_invalidate(const struct device *dev)
 { return -ENODEV; }
 
+static inline int rpmh_ctrlr_idle(const struct device *dev)
+{ return -ENODEV; }
+
 #endif /* CONFIG_QCOM_RPMH */
 
 #endif /* __SOC_QCOM_RPMH_H__ */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project



  1   2   3   4   5   6   7   8   >