[PATCH] xtensa: remove unneeded BITS_PER_LONG define

[Masahiro Yamada]

Xtensa does not define CONFIG_64BIT. The generic definition in
include/asm-generic/bitsperlong.h should work.

Signed-off-by: Masahiro Yamada 
---

 arch/xtensa/include/asm/types.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/xtensa/include/asm/types.h b/arch/xtensa/include/asm/types.h
index 2b410b8c7f79..44f411c75837 100644
--- a/arch/xtensa/include/asm/types.h
+++ b/arch/xtensa/include/asm/types.h
@@ -12,12 +12,4 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
-/*
- * These aren't exported outside the kernel to avoid name space clashes
- */
-
-#define BITS_PER_LONG 32
-
-#endif
 #endif /* _XTENSA_TYPES_H */
-- 
2.17.1

RE: [PATCH] soc: imx-scu: Add SoC UID(unique identifier) support

[Anson Huang]

Hi, Daniel

> -Original Message-
> From: Daniel Baluta 
> Sent: Thursday, June 27, 2019 2:44 PM
> To: Anson Huang 
> Cc: Shawn Guo ; Sascha Hauer
> ; Pengutronix Kernel Team
> ; Fabio Estevam ; Aisheng
> Dong ; Abel Vesa ; linux-
> arm-kernel ; Linux Kernel Mailing List
> ; dl-linux-imx ; Daniel
> Baluta 
> Subject: Re: [PATCH] soc: imx-scu: Add SoC UID(unique identifier) support
> 
> On Thu, Jun 27, 2019 at 3:48 AM Anson Huang 
> wrote:
> >
> > Hi, Daniel
> >
> > > -Original Message-
> > > From: Daniel Baluta 
> > > Sent: Wednesday, June 26, 2019 8:42 PM
> > > To: Anson Huang 
> > > Cc: Shawn Guo ; Sascha Hauer
> > > ; Pengutronix Kernel Team
> > > ; Fabio Estevam ;
> Aisheng
> > > Dong ; Abel Vesa ; linux-
> > > arm-kernel ; Linux Kernel
> > > Mailing List ; dl-linux-imx
> > > ; Daniel Baluta 
> > > Subject: Re: [PATCH] soc: imx-scu: Add SoC UID(unique identifier)
> > > support
> > >
> > > On Wed, Jun 26, 2019 at 10:06 AM  wrote:
> > > >
> > > > From: Anson Huang 
> > > >
> > > > Add i.MX SCU SoC's UID(unique identifier) support, user can read
> > > > it from sysfs:
> > > >
> > > > root@imx8qxpmek:~# cat /sys/devices/soc0/soc_uid
> > > > 7B64280B57AC1898
> > > >
> > > > Signed-off-by: Anson Huang 
> > > > ---
> > > >  drivers/soc/imx/soc-imx-scu.c | 35
> > > > +++
> > > >  1 file changed, 35 insertions(+)
> > > >
> > > > diff --git a/drivers/soc/imx/soc-imx-scu.c
> > > > b/drivers/soc/imx/soc-imx-scu.c index 676f612..8d322a1 100644
> > > > --- a/drivers/soc/imx/soc-imx-scu.c
> > > > +++ b/drivers/soc/imx/soc-imx-scu.c
> > > > @@ -27,6 +27,36 @@ struct imx_sc_msg_misc_get_soc_id {
> > > > } data;
> > > >  } __packed;
> > > >
> > > > +struct imx_sc_msg_misc_get_soc_uid {
> > > > +   struct imx_sc_rpc_msg hdr;
> > > > +   u32 uid_low;
> > > > +   u32 uid_high;
> > > > +} __packed;
> > > > +
> > > > +static ssize_t soc_uid_show(struct device *dev,
> > > > +   struct device_attribute *attr, char
> > > > +*buf) {
> > > > +   struct imx_sc_msg_misc_get_soc_uid msg;
> > > > +   struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > > > +   u64 soc_uid;
> > > > +
> > > > +   hdr->ver = IMX_SC_RPC_VERSION;
> > > > +   hdr->svc = IMX_SC_RPC_SVC_MISC;
> > > > +   hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
> > > > +   hdr->size = 1;
> > > > +
> > > > +   /* the return value of SCU FW is in correct, skip return
> > > > + value check */
> > >
> > > Why do you mean by "in correct"?
> >
> > I made a mistake, it should be "incorrect", the existing SCFW of this
> > API returns an error value even this API is successfully called, to
> > make it work with current SCFW, I have to skip the return value check
> > for this API for now. Will send V2 patch to fix this typo.
> 
> Thanks Anson! It makes sense now. It is a little bit sad though because we
> won't know when there is a "real" error :).
> 
> Lets update the comment to be more specific:
> 
> /* SCFW FW API always returns an error even the function is successfully
> executed, so skip returned value */

OK, as for external users, the SCFW formally released has this issue, so for now
I have to skip the return value check for this API, once next SCFW release has 
this issue
fixed, I will add a patch to check the return value.

Thanks,
Anson.
> 
> 
> > > > +   imx_scu_call_rpc(soc_ipc_handle, &msg, true);
> > > > +
> > > > +   soc_uid = msg.uid_high;
> > > > +   soc_uid <<= 32;
> > > > +   soc_uid |= msg.uid_low;
> > > > +
> > > > +   return sprintf(buf, "%016llX\n", soc_uid);
> > >
> > > snprintf?
> >
> > The snprintf is to avoid buffer overflow, which in this case, I don't
> > know the size of "buf", and the value(u64) to be printed is with fixed
> > length of 64, so I think sprint is just OK.
> 
> Ok.

Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems

[kbuild test robot]

Hi Ivan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Ivan-Khoronzhuk/xdp-xdp_umem-fix-umem-pages-mapping-for-32bits-systems/20190627-135949
config: i386-randconfig-x073-201925 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   net//xdp/xdp_umem.c: In function 'xdp_umem_unmap_pages':
   net//xdp/xdp_umem.c:177:3: error: implicit declaration of function 'kunmap'; 
did you mean 'vunmap'? [-Werror=implicit-function-declaration]
  kunmap(umem->pgs[i]);
  ^~
  vunmap
   net//xdp/xdp_umem.c: In function 'xdp_umem_reg':
>> net//xdp/xdp_umem.c:384:25: error: implicit declaration of function 'kmap'; 
>> did you mean 'vmap'? [-Werror=implicit-function-declaration]
  umem->pages[i].addr = kmap(umem->pgs[i]);
^~~~
vmap
   net//xdp/xdp_umem.c:384:23: warning: assignment makes pointer from integer 
without a cast [-Wint-conversion]
  umem->pages[i].addr = kmap(umem->pgs[i]);
  ^
   cc1: some warnings being treated as errors

vim +384 net//xdp/xdp_umem.c

   311  
   312  static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
   313  {
   314  u32 chunk_size = mr->chunk_size, headroom = mr->headroom;
   315  unsigned int chunks, chunks_per_page;
   316  u64 addr = mr->addr, size = mr->len;
   317  int size_chk, err, i;
   318  
   319  if (chunk_size < XDP_UMEM_MIN_CHUNK_SIZE || chunk_size > 
PAGE_SIZE) {
   320  /* Strictly speaking we could support this, if:
   321   * - huge pages, or*
   322   * - using an IOMMU, or
   323   * - making sure the memory area is consecutive
   324   * but for now, we simply say "computer says no".
   325   */
   326  return -EINVAL;
   327  }
   328  
   329  if (!is_power_of_2(chunk_size))
   330  return -EINVAL;
   331  
   332  if (!PAGE_ALIGNED(addr)) {
   333  /* Memory area has to be page size aligned. For
   334   * simplicity, this might change.
   335   */
   336  return -EINVAL;
   337  }
   338  
   339  if ((addr + size) < addr)
   340  return -EINVAL;
   341  
   342  chunks = (unsigned int)div_u64(size, chunk_size);
   343  if (chunks == 0)
   344  return -EINVAL;
   345  
   346  chunks_per_page = PAGE_SIZE / chunk_size;
   347  if (chunks < chunks_per_page || chunks % chunks_per_page)
   348  return -EINVAL;
   349  
   350  headroom = ALIGN(headroom, 64);
   351  
   352  size_chk = chunk_size - headroom - XDP_PACKET_HEADROOM;
   353  if (size_chk < 0)
   354  return -EINVAL;
   355  
   356  umem->address = (unsigned long)addr;
   357  umem->chunk_mask = ~((u64)chunk_size - 1);
   358  umem->size = size;
   359  umem->headroom = headroom;
   360  umem->chunk_size_nohr = chunk_size - headroom;
   361  umem->npgs = size / PAGE_SIZE;
   362  umem->pgs = NULL;
   363  umem->user = NULL;
   364  INIT_LIST_HEAD(&umem->xsk_list);
   365  spin_lock_init(&umem->xsk_list_lock);
   366  
   367  refcount_set(&umem->users, 1);
   368  
   369  err = xdp_umem_account_pages(umem);
   370  if (err)
   371  return err;
   372  
   373  err = xdp_umem_pin_pages(umem);
   374  if (err)
   375  goto out_account;
   376  
   377  umem->pages = kcalloc(umem->npgs, sizeof(*umem->pages), 
GFP_KERNEL);
   378  if (!umem->pages) {
   379  err = -ENOMEM;
   380  goto out_account;
   381  }
   382  
   383  for (i = 0; i < umem->npgs; i++)
 > 384  umem->pages[i].addr = kmap(umem->pgs[i]);
   385  
   386  return 0;
   387  
   388  out_account:
   389  xdp_umem_unaccount_pages(umem);
   390  return err;
   391  }
   392  

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


.config.gz
Description: application/gzip

Re: [PATCH] media: staging/imx: Fix NULL deref in find_pipeline_entity()

[Dan Carpenter]

On Wed, Jun 26, 2019 at 11:52:25AM -0700, Steve Longerbeam wrote:
> Fix a cut&paste error in find_pipeline_entity(). The start entity must be
> passed to media_entity_to_video_device() in find_pipeline_entity(), not
> pad->entity. The pad is only put to use later, after determining the start
> entity is not the entity being searched for.
> 
> Fixes: 3ef46bc97ca2 ("media: staging/imx: Improve pipeline searching")
> 
> Reported-by: Colin Ian King 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/imx-media-utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/imx/imx-media-utils.c 
> b/drivers/staging/media/imx/imx-media-utils.c
> index b5b8a3b7730a..6fb88c22ee27 100644
> --- a/drivers/staging/media/imx/imx-media-utils.c
> +++ b/drivers/staging/media/imx/imx-media-utils.c
> @@ -842,7 +842,7 @@ find_pipeline_entity(struct media_entity *start, u32 
> grp_id,
>   if (sd->grp_id & grp_id)
>   return &sd->entity;
>   } else if (buftype && is_media_entity_v4l2_video_device(start)) {
> - vfd = media_entity_to_video_device(pad->entity);
> + vfd = media_entity_to_video_device(start);

Can we also remove the "pad = NULL" assignment at the start of the
function?  Otherwise static checkers and new versions of GCC will warn
that the assignment isn't used.  Plus removing the initialization will
prevent bugs like this in the future.

regards,
dan carpenter

Re: [PATCH v3 3/4] iommu/arm-smmu: Add support to handle Qcom's wait-for-safe logic

[Vivek Gautam]

On Wed, Jun 26, 2019 at 8:18 PM Will Deacon  wrote:
>
> On Wed, Jun 26, 2019 at 12:03:02PM +0530, Vivek Gautam wrote:
> > On Tue, Jun 25, 2019 at 7:09 PM Will Deacon  wrote:
> > >
> > > On Tue, Jun 25, 2019 at 12:34:56PM +0530, Vivek Gautam wrote:
> > > > On Mon, Jun 24, 2019 at 10:33 PM Will Deacon  wrote:
> > > > > Instead, I think this needs to be part of a separate file that is 
> > > > > maintained
> > > > > by you, which follows on from the work that Krishna is doing for 
> > > > > nvidia
> > > > > built on top of Robin's prototype patches:
> > > > >
> > > > > http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/smmu-impl
> > > >
> > > > Looking at this branch quickly, it seem there can be separate 
> > > > implementation
> > > > level configuration file that can be added.
> > > > But will this also handle separate page table ops when required in 
> > > > future.
> > >
> > > Nothing's set in stone, but having the implementation-specific code
> > > constrain the page-table format (especially wrt quirks) sounds reasonable 
> > > to
> > > me. I'm currently waiting for Krishna to respin the nvidia changes [1] on
> > > top of this so that we can see how well the abstractions are holding up.
> >
> > Sure. Would you want me to try Robin's branch and take out the qualcomm
> > related stuff to its own implementation? Or, would you like me to respin 
> > this
> > series so that you can take it in to enable SDM845 boards such as, MTP
> > and dragonboard to have a sane build - debian, etc. so people benefit
> > out of it.
>
> I can't take this series without Acks on the firmware calling changes, and I
> plan to send my 5.3 patches to Joerg at the end of the week so they get some
> time in -next. In which case, I think it may be worth you having a play with
> the branch above so we can get a better idea of any additional smmu_impl hooks
> you may need.

Cool. I will play around with it and get something tangible and meaningful.

>
> > Qualcomm stuff is lying in qcom-smmu and arm-smmu and may take some
> > time to stub out the implementation related details.
>
> Not sure I follow you here. Are you talking about qcom_iommu.c?

That's right. The qcom_iommu.c solved a different issue of secure context bank
allocations, when Rob forked out this driver and reused some of the
arm-smmu.c stuff.

We will take a look at that once we start adding the qcom implementation.

Thanks
Vivek

>
> Will
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] reset: Add driver for dispmix reset

[Philipp Zabel]

On Wed, 2019-06-26 at 06:46 +, Fancy Fang wrote:
[...]
> > The same goes for the clock soft enable bits on i.MX8MM. If those 
> > bits actually control clock gates, they should not be described as 
> > reset controls in the device tree.
>
> [FF] Make sense. The functions provided by the "dispmix reset" is more
> likely to be a combination of a clock gating module and a reset
> control than a standard reset controller. The reason why I choose
> reset framework to implement this device is that: First, this module
> is named as "dispmix reset" in the dispmix's design spec, so it gives
> me the first impression that it should be acted as a reset controller.
> And I'll check this with the IC designer.

Thank you.

> Second, the "dispmix reset" is separated from the CCM LPCG module
> which is used as the only clock controller device for the whole
> platform. So the CCM clock driver seems cannot cover this device.
> Last, the "dispmix reset" is shared by all the submodules in the
> dispmix, so I abstract this device to be a reset controller driver to
> simplify the 'reset' logic for all the submodules drivers.

Agreed on both points.

> If using clock framework to cover this device, another driver needs to
> be implemented. I'll take a close look at it to see if this can
> happen.

Yes, if my assumptions are correct, it would be good if this could be
rewritten as a combined clock and reset driver. There are quite a few
examples for this in drivers/clk already.

[...]
> > Is there any reason not to just use straight readl/writel besides 
> > the automatic clock handling?
>
> [FF] Use regmap is for simplifying the register modifications since
> the register has no SET or CLR shadow, so when set or clear one bit,
> the register needs to be read-and-modify. And besides, the register
> access requires disp-apb clock open, and regmap can handle this
> properly.

Ok, this makes sense to me.

regards
Philipp

Re: [PATCH v2] jffs2: remove C++ style comments from uapi header

[Masahiro Yamada]

On Tue, Jun 18, 2019 at 3:20 PM Richard Weinberger  wrote:
>
> - Ursprüngliche Mail -
> > Von: "Masahiro Yamada" 
> > An: "linux-mtd" 
> > CC: "Boris Brezillon" , "Miquel Raynal" 
> > , "Brian Norris"
> > , "Vignesh Raghavendra" , 
> > "Marek Vasut" ,
> > "Masahiro Yamada" , "richard" 
> > , "David Woodhouse" ,
> > "linux-kernel" 
> > Gesendet: Dienstag, 18. Juni 2019 05:09:26
> > Betreff: [PATCH v2] jffs2: remove C++ style comments from uapi header
>
> > Linux kernel tolerates C++ style comments these days. Actually, the
> > SPDX License tags for .c files start with //.
> >
> > On the other hand, uapi headers are written in more strict C, where
> > the C++ comment style is forbidden.
> >
> > I simply dropped these lines instead of fixing the comment style.
> >
> > This code has been always commented out since it was added around
> > Linux 2.4.9 (i.e. commented out for more than 17 years).
> >
> > 'Maybe later...' will never happen.
>
> :-)
>
> > Signed-off-by: Masahiro Yamada 
>
> Acked-by: Richard Weinberger 
>
> Thanks,
> //richard


Will this be picked up for v5.3-rc1 ?



-- 
Best Regards
Masahiro Yamada

[PATCH v2] rcu: Change return type of rcu_spawn_one_boost_kthread()

[Byungchul Park]

Hello,

I tested if the WARN_ON_ONCE() is fired with my box and it was ok.

Thanks,
Byungchul

Changes from v1
-. WARN_ON_ONCE() on failing to create rcu_boost_kthread.
-. Changed title and commit message a bit.

---8<---
>From 7100fcf82202f063f70f45def208ea5198412f5a Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Thu, 27 Jun 2019 15:58:10 +0900
Subject: [PATCH v2] rcu: Change return type of rcu_spawn_one_boost_kthread()

The return value of rcu_spawn_one_boost_kthread() is not used any
longer. Change return type of that function from int to void.

Signed-off-by: Byungchul Park 
---
 kernel/rcu/tree_plugin.h | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 1102765..3c8444e 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1131,7 +1131,7 @@ static void rcu_preempt_boost_start_gp(struct rcu_node 
*rnp)
  * already exist.  We only create this kthread for preemptible RCU.
  * Returns zero if all is well, a negated errno otherwise.
  */
-static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
+static void rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
 {
int rnp_index = rnp - rcu_get_root();
unsigned long flags;
@@ -1139,25 +1139,24 @@ static int rcu_spawn_one_boost_kthread(struct rcu_node 
*rnp)
struct task_struct *t;
 
if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
-   return 0;
+   return;
 
if (!rcu_scheduler_fully_active || rcu_rnp_online_cpus(rnp) == 0)
-   return 0;
+   return;
 
rcu_state.boost = 1;
if (rnp->boost_kthread_task != NULL)
-   return 0;
+   return;
t = kthread_create(rcu_boost_kthread, (void *)rnp,
   "rcub/%d", rnp_index);
-   if (IS_ERR(t))
-   return PTR_ERR(t);
+   if (WARN_ON_ONCE(IS_ERR(t)))
+   return;
raw_spin_lock_irqsave_rcu_node(rnp, flags);
rnp->boost_kthread_task = t;
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
sp.sched_priority = kthread_prio;
sched_setscheduler_nocheck(t, SCHED_FIFO, &sp);
wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
-   return 0;
 }
 
 static void rcu_cpu_kthread_setup(unsigned int cpu)
@@ -1265,7 +1264,7 @@ static void __init rcu_spawn_boost_kthreads(void)
if (WARN_ONCE(smpboot_register_percpu_thread(&rcu_cpu_thread_spec), 
"%s: Could not start rcub kthread, OOM is now expected behavior\n", __func__))
return;
rcu_for_each_leaf_node(rnp)
-   (void)rcu_spawn_one_boost_kthread(rnp);
+   rcu_spawn_one_boost_kthread(rnp);
 }
 
 static void rcu_prepare_kthreads(int cpu)
@@ -1275,7 +1274,7 @@ static void rcu_prepare_kthreads(int cpu)
 
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
if (rcu_scheduler_fully_active)
-   (void)rcu_spawn_one_boost_kthread(rnp);
+   rcu_spawn_one_boost_kthread(rnp);
 }
 
 #else /* #ifdef CONFIG_RCU_BOOST */
-- 
1.9.1

[PATCH] mtd: abi: do not use C++ style comments in uapi header

[Masahiro Yamada]

Linux kernel tolerates C++ style comments these days. Actually, the
SPDX License tags for .c files start with //.

On the other hand, uapi headers are written in more strict C, where
the C++ comment style is forbidden.

Signed-off-by: Masahiro Yamada 
---

 include/uapi/mtd/mtd-abi.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index aff5b5e59845..47ffe3208c27 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -113,11 +113,11 @@ struct mtd_write_req {
 #define MTD_CAP_NVRAM  (MTD_WRITEABLE | MTD_BIT_WRITEABLE | 
MTD_NO_ERASE)
 
 /* Obsolete ECC byte placement modes (used with obsolete MEMGETOOBSEL) */
-#define MTD_NANDECC_OFF0   // Switch off ECC (Not 
recommended)
-#define MTD_NANDECC_PLACE  1   // Use the given placement in the 
structure (YAFFS1 legacy mode)
-#define MTD_NANDECC_AUTOPLACE  2   // Use the default placement scheme
-#define MTD_NANDECC_PLACEONLY  3   // Use the given placement in the 
structure (Do not store ecc result on read)
-#define MTD_NANDECC_AUTOPL_USR 4   // Use the given autoplacement 
scheme rather than using the default
+#define MTD_NANDECC_OFF0   /* Switch off ECC (Not 
recommended) */
+#define MTD_NANDECC_PLACE  1   /* Use the given placement in the 
structure (YAFFS1 legacy mode) */
+#define MTD_NANDECC_AUTOPLACE  2   /* Use the default placement scheme */
+#define MTD_NANDECC_PLACEONLY  3   /* Use the given placement in the 
structure (Do not store ecc result on read) */
+#define MTD_NANDECC_AUTOPL_USR 4   /* Use the given autoplacement 
scheme rather than using the default */
 
 /* OTP mode selection */
 #define MTD_OTP_OFF0
-- 
2.17.1

Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

[Peter Zijlstra]

On Wed, Jun 26, 2019 at 03:33:36PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 26, 2019 at 9:31 AM Peter Zijlstra  wrote:
> >
> > On Tue, Jun 25, 2019 at 11:47:06PM +0200, Thomas Gleixner wrote:
> > > > On Tue, Jun 25, 2019 at 09:53:09PM +0200, Thomas Gleixner wrote:
> >
> > > > > but it also makes objtool unhappy:
> >
> > > > >  arch/x86/kernel/cpu/mtrr/generic.o: warning: objtool: 
> > > > > get_fixed_ranges()+0x9b: unreachable instruction
> >
> > > I just checked two of them in the disassembly. In both cases it's jump
> > > label related. Here is one:
> > >
> > >   asm volatile("1: rdmsr\n"
> > >  410:   b9 59 02 00 00  mov$0x259,%ecx
> > >  415:   0f 32   rdmsr
> > >  417:   49 89 c6mov%rax,%r14
> > >  41a:   48 89 d3mov%rdx,%rbx
> > >   return EAX_EDX_VAL(val, low, high);
> > >  41d:   48 c1 e3 20 shl$0x20,%rbx
> > >  421:   48 09 c3or %rax,%rbx
> > >  424:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
> > >  429:   eb 0f   jmp43a 
> > >   do_trace_read_msr(msr, val, 0);
> > >  42b:   bf 59 02 00 00  mov$0x259,%edi   <--- 
> > > "unreachable"
> 
> I assume if 0x42b is unreachable, that's bad as $0x259 is never stored
> in %edi before the call to get_fixed_ranges+0xaa...

So what happens is that the __jump_table entry for 424 is wrong. When we
enable that key (read msr tracepoint) the code will jump to another
instance of the read msr tracepoint and continue running from there.

So we'll jump from one inlined instance to another, with all the
ramifications thereof; the code-flow will be completely screwy.

> > >  430:   48 89 demov%rbx,%rsi
> > >  433:   31 d2   xor%edx,%edx
> > >  435:   e8 00 00 00 00  callq  43a 
> > >  43a:   44 89 35 00 00 00 00mov%r14d,0x0(%rip)# 441 
> > > 
> >
> > Thomas provided the actual .o file, and from that we find that the
> > .rela__jump_table entries look like:
> >
> > 0010  00010002 R_X86_64_PC32  .text + 3e9
> > 0014  00010002 R_X86_64_PC32  .text + 3f0
> > 0018  00610018 R_X86_64_PC64  
> > __tracepoint_read_msr + 8
> 
> I assume these relocations come from arch_static_branch() (and thus
> appear in triples?)
> 
>  21 static __always_inline bool arch_static_branch(struct static_key
> *key, bool branch)
>  22 {
>  23   asm_volatile_goto("1:"
>  24 ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"

>  25 ".pushsection __jump_table,  \"aw\" \n\t"
>  26 _ASM_ALIGN "\n\t"
>  27 ".long 1b - ., %l[l_yes] - . \n\t" // 1, 2
>  28 _ASM_PTR "%c0 + %c1 - .\n\t" // 3
>  29 ".popsection \n\t"

Yes, its lines 25-29 ^ that generate the jump_table entries. The first
entry is the code location, the second is the jump target and the third
is a pointer (and two LSB state bits) to the key this belongs to.

The compiler emits .rela objects for these and this is what we use with
objtool -- just like a linker would to resolve and create the actual
__jump_table section.

>  30 : :  "i" (key), "i" (branch) : : l_yes);
> 
> > 0020  00010002 R_X86_64_PC32  .text + 424
> > 0024  00010002 R_X86_64_PC32  .text + 3f0
> > 0028  00610018 R_X86_64_PC64  
> > __tracepoint_read_msr + 8
> >
> > From this we find that the jump target that goes with the NOP at +424 is
> > +3f0, not +42b as one would expect.
> >
> > And as Josh noted, it is also 'weird' that this +3f0 is the very same as
> > the target for the previous entry.
> 
> (Ok, I think I did talk to Josh about this, and I think he did mention
> something about the jump targets, but I didn't really understand the
> issue well at the time).

So what we have here is two instances of the same read msr inline. They
have code in different offsets (+3e9 and +424 resp.) but somehow the
compiler messed up and collapsed their jump target (or didn't properly
de-duplicate -- I've no idea how inline instantiation actually works).

> >
> > When we compare the code at both sites, we find:
> >
> > 3f0:   bf 58 02 00 00  mov$0x258,%edi
> > 3f5:   48 89 demov%rbx,%rsi
> > 3f8:   31 d2   xor%edx,%edx
> > 3fa:   e8 00 00 00 00  callq  3ff 
> > 3fb: R_X86_64_PC32  do_trace_read_msr-0x4
> >
> > vs
> >
> > 42b:   bf 59 02 00 00  mov$0x259,%edi
> > 430:   48 89 demov%rbx,%rsi
> > 433:   31 d2   xor%edx,%edx
> > 435:   e8 00 00 00 00  callq  43a 
> > 436: R_X86_64_PC32  do_trace_read_msr-0x4
> >
> > Which is not in fact the same code.
> >
> > So for some reason the .rela__jump_table are buggy on this clang build.
> 
> So that sounds like a correctness b

Re: [PATCH v9 11/17] kvm/vmx: Emulate MSR TEST_CTL

[Thomas Gleixner]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

A: Yes
Q: Should I trim all irrelevant context?

On Thu, 27 Jun 2019, Xiaoyao Li wrote:
>
> Do you have any comments on this one as the policy of how to expose split lock
> detection (emulate TEST_CTL) for guest changed.
> 
> This patch makes the implementation as below:
> 
> Host  |Guest  |Actual value in guest  |split lock happen in guest
> --
> on|off|   on  |report #AC to userspace
>   |on |   on  |inject #AC back to guest
> --
> off   |off|   off |No #AC
>   |on |   on  |inject #AC back to guest

A: Because it's way better to provide implementation details and useless
   references to the SDM.

Q: What's the reason that this table is _NOT_ part of the changelog?

> In case 2, when split lock detection of both host and guest on, if there is a
> split lock is guest, it will inject #AC back to userspace. Then if #AC is from
> guest userspace apps, guest kernel sends SIGBUS to userspace apps instead of
> whole guest killed by host. If #AC is from guest kernel, guest kernel may
> clear it's split lock bit in test_ctl msr and re-execute the instruction, then
> it goes into case 1, the #AC will report to host userspace, e.g., QEMU.

The real interesting question is whether the #AC on split lock prevents the
actual bus lock or not. If it does then the above is fine.

If not, then it would be trivial for a malicious guest to set the
SPLIT_LOCK_ENABLE bit and "handle" the exception pro forma, return to the
offending instruction and trigger another one. It lowers the rate, but that
doesn't make it any better.

The SDM is as usual too vague to be useful. Please clarify.

Thanks,

tglx

Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

[Peter Zijlstra]

On Wed, Jun 26, 2019 at 03:14:05PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 26, 2019 at 1:49 AM Peter Zijlstra  wrote:
> >
> > On Tue, Jun 25, 2019 at 11:15:57AM -0700, Nick Desaulniers wrote:
> >
> > > Unreleased versions of Clang built from source can;
> >
> > I've bad experiences with using unreleased compilers; life is too short.
> 
> Yes; but before release is when they need the help the most in order
> for testing to find regressions.
> 
> >
> > > We're currently planning multiple output constraint support w/ asm
> > > goto, and have recently implemented things like
> > > __GCC_ASM_FLAG_OUTPUTS__.
> >
> > That's good to hear.
> >
> > > If there's other features that we should
> > > start implementing, please let us know.
> >
> > If you've got any ideas on how to make this:
> >
> >   
> > https://lkml.kernel.org/r/20190621120923.gt3...@hirez.programming.kicks-ass.net
> >
> > work, that'd be nice. Basically I wanted the asm goto to emit a 2 or 5
> > byte JMP/NOP depending on the displacement size. We can trivially get
> > JMP right by using:
> >
> > jmp \l_yes
> >
> > and letting the assembler sort it, but getting the NOP right has so far
> > eluded me:
> >
> > .if \l_yes - (. + 2) < 127
> > .byte 0x66, 0x90
> > .else
> > .byte STATIC_KEY_INIT_NOP
> > .endif
> >
> > doesn't work. We can ofcourse unconditionally emit the JMP and then
> > rewrite the binary afterward, and replace the emitted jumps with the
> > right size NOP, but that's a bit yuck.
> >
> > Once it emits the variable size instruction consistently, we can update
> > the patching side to use the same condition to select the new
> > instruction (and fix objtool).
> 
> Not sure; the assembler directives and their requirements aren't
> something I'm too familiar with.

Josh came up with the following:

+   /* If the jump target is close, do a 2-byte nop: */
+   ".skip -(%l[l_yes] - 1b <= 126), 0x66\n"
+   ".skip -(%l[l_yes] - 1b <= 126), 0x90\n"
+   /* Otherwise do a 5-byte nop: */
+   ".skip -(%l[l_yes] - 1b > 126), 0x0f\n"
+   ".skip -(%l[l_yes] - 1b > 126), 0x1f\n"
+   ".skip -(%l[l_yes] - 1b > 126), 0x44\n"
+   ".skip -(%l[l_yes] - 1b > 126), 0x00\n"
+   ".skip -(%l[l_yes] - 1b > 126), 0x00\n"

Which is a wonderfully gruesome hack :-) So I'll be playing with that
for a bit.

Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

[Peter Zijlstra]

On Wed, Jun 26, 2019 at 03:15:38PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 26, 2019 at 2:24 AM Peter Zijlstra  wrote:
> >
> > On Tue, Jun 25, 2019 at 11:47:06PM +0200, Thomas Gleixner wrote:
> > > > On Tue, Jun 25, 2019 at 09:53:09PM +0200, Thomas Gleixner wrote:
> >
> > > > > but it also makes objtool unhappy:
> > > > >
> > > > >  arch/x86/events/intel/core.o: warning: objtool: 
> > > > > intel_pmu_nhm_workaround()+0xb3: unreachable instruction
> > > > >  kernel/fork.o: warning: objtool: free_thread_stack()+0x126: 
> > > > > unreachable instruction
> > > > >  mm/workingset.o: warning: objtool: count_shadow_nodes()+0x11f: 
> > > > > unreachable instruction
> > > > >  arch/x86/kernel/cpu/mtrr/generic.o: warning: objtool: 
> > > > > get_fixed_ranges()+0x9b: unreachable instruction
> > > > >  arch/x86/kernel/platform-quirks.o: warning: objtool: 
> > > > > x86_early_init_platform_quirks()+0x84: unreachable instruction
> > > > >  drivers/iommu/irq_remapping.o: warning: objtool: 
> > > > > irq_remap_enable_fault_handling()+0x1d: unreachable instruction
> >
> > > I just checked two of them in the disassembly. In both cases it's jump
> > > label related. Here is one:
> > >
> > >   asm volatile("1: rdmsr\n"
> > >  410:   b9 59 02 00 00  mov$0x259,%ecx
> > >  415:   0f 32   rdmsr
> > >  417:   49 89 c6mov%rax,%r14
> > >  41a:   48 89 d3mov%rdx,%rbx
> > >   return EAX_EDX_VAL(val, low, high);
> > >  41d:   48 c1 e3 20 shl$0x20,%rbx
> > >  421:   48 09 c3or %rax,%rbx
> > >  424:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
> > >  429:   eb 0f   jmp43a 
> > >   do_trace_read_msr(msr, val, 0);
> > >  42b:   bf 59 02 00 00  mov$0x259,%edi   <--- 
> > > "unreachable"
> > >  430:   48 89 demov%rbx,%rsi
> > >  433:   31 d2   xor%edx,%edx
> > >  435:   e8 00 00 00 00  callq  43a 
> > >  43a:   44 89 35 00 00 00 00mov%r14d,0x0(%rip)# 441 
> > > 
> > >
> > > Interestingly enough there are some more hunks of the same pattern in that
> > > function which look all the same. Those are not upsetting objtool. Josh
> > > might give an hint where to stare at.
> >
> > That's pretty atrocious code-gen :/ Does LLVM support things like label
> > attributes? Back when we did jump labels GCC didn't, or rather, it
> > ignored it completely when combined with asm goto (and it might still).
> >
> > That is, would something like this:
> >
> > diff --git a/arch/x86/include/asm/jump_label.h 
> > b/arch/x86/include/asm/jump_label.h
> > index 06c3cc22a058..1761b1e76ddc 100644
> > --- a/arch/x86/include/asm/jump_label.h
> > +++ b/arch/x86/include/asm/jump_label.h
> > @@ -32,7 +32,7 @@ static __always_inline bool arch_static_branch(struct 
> > static_key *key, bool bran
> > : :  "i" (key), "i" (branch) : : l_yes);
> >
> > return false;
> > -l_yes:
> > +l_yes: __attribute__((cold));
> > return true;
> >  }
> >
> > @@ -49,7 +49,7 @@ static __always_inline bool 
> > arch_static_branch_jump(struct static_key *key, bool
> > : :  "i" (key), "i" (branch) : : l_yes);
> >
> > return false;
> > -l_yes:
> > +l_yes: __attribute__((hot));
> > return true;
> >  }
> >
> > Help LLVM?

As I wrote later; the above suggestion is actually wrong :/

> So Clang definitely complains about putting attribute hot/cold on
> labels: https://godbolt.org/z/N-Z33Q
> In my test case I wasn't able to influence code gen with them though
> in GCC at -O2 or -O0.  Maybe GCC has a test case that shows how they
> should work?

As I wrote in that same later email; the way we influence the actual
code-layout is with the __builtin_expect() thing. Let me expand on that
in another email.

Sadly, I've no clue what so ever about compiler internals, be it GCC or
LLVM.

Re: [PATCH][next][V2] media: vivid: fix potential integer overflow on left shift

[walter harms]

Am 26.06.2019 16:47, schrieb Colin King:
> From: Colin Ian King 
> 
> There is a potential integer overflow when int 2 is left shifted
> as this is evaluated using 32 bit arithmetic but is being used in
> a context that expects an expression of type s64.  Fix this by
> shifting 2ULL to avoid a 32 bit overflow.
> 
> Addresses-Coverity: ("Unintentional integer overflow")
> Fixes: 8a99e9faa131 ("media: vivid: add HDMI (dis)connect RX emulation")
> Fixes: 79a792dafac6 ("media: vivid: add HDMI (dis)connect TX emulation")
> Signed-off-by: Colin Ian King 

Reviewed-by: wharms 
 looks less confusing now, thx


> ---
> V2: use intermediate variables for the shifted expression to make code
> a bit more readable.
> ---
>  drivers/media/platform/vivid/vivid-ctrls.c | 24 +++---
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
> b/drivers/media/platform/vivid/vivid-ctrls.c
> index 3e916c8befb7..df1598e81c7a 100644
> --- a/drivers/media/platform/vivid/vivid-ctrls.c
> +++ b/drivers/media/platform/vivid/vivid-ctrls.c
> @@ -1613,6 +1613,8 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
> show_ccs_cap,
>   }
>  
>   if (dev->num_hdmi_inputs) {
> + s64 hdmi_input = (2ULL << (dev->num_hdmi_inputs - 1)) - 1;
> +
>   dev->ctrl_dv_timings_signal_mode = 
> v4l2_ctrl_new_custom(hdl_vid_cap,
>   &vivid_ctrl_dv_timings_signal_mode, 
> NULL);
>  
> @@ -1633,12 +1635,13 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
> show_ccs_cap,
>   V4L2_CID_DV_RX_RGB_RANGE, V4L2_DV_RGB_RANGE_FULL,
>   0, V4L2_DV_RGB_RANGE_AUTO);
>   dev->ctrl_rx_power_present = v4l2_ctrl_new_std(hdl_vid_cap,
> - NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0,
> - (2 << (dev->num_hdmi_inputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_inputs - 1)) - 1);
> + NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0, hdmi_input,
> + 0, hdmi_input);
>  
>   }
>   if (dev->num_hdmi_outputs) {
> + s64 hdmi_output = (2ULL << (dev->num_hdmi_outputs - 1)) - 1;
> +
>   /*
>* We aren't doing anything with this at the moment, but
>* HDMI outputs typically have this controls.
> @@ -1652,17 +1655,14 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
> show_ccs_cap,
>   dev->ctrl_display_present = v4l2_ctrl_new_custom(hdl_vid_out,
>   &vivid_ctrl_display_present, NULL);
>   dev->ctrl_tx_hotplug = v4l2_ctrl_new_std(hdl_vid_out,
> - NULL, V4L2_CID_DV_TX_HOTPLUG, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + NULL, V4L2_CID_DV_TX_HOTPLUG, 0, hdmi_output,
> + 0, hdmi_output);
>   dev->ctrl_tx_rxsense = v4l2_ctrl_new_std(hdl_vid_out,
> - NULL, V4L2_CID_DV_TX_RXSENSE, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + NULL, V4L2_CID_DV_TX_RXSENSE, 0, hdmi_output,
> + 0, hdmi_output);
>   dev->ctrl_tx_edid_present = v4l2_ctrl_new_std(hdl_vid_out,
> - NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0, hdmi_output,
> + 0, hdmi_output);
>   }
>   if ((dev->has_vid_cap && dev->has_vid_out) ||
>   (dev->has_vbi_cap && dev->has_vbi_out))

[PATCH 3/3] usb: dwc3: Remove generic PHY calibrate() calls

[Marek Szyprowski]

Calls to USB2 generic PHY calibrate() method were added by commit
d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800"), but it turned out that the mentioned patch worked only
by the pure luck and fixed only one use case. To fix the issues with PHY
calibration it has been moved to XHCI HCD driver, what allows to perform
calibration in the proper time window. This patch removes those calls
from DWC3 driver, as they are no longer needed there.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc3/core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index baa029ceede9..f62e8442c614 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -168,7 +168,6 @@ static void __dwc3_set_mode(struct work_struct *work)
otg_set_vbus(dwc->usb2_phy->otg, true);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
-   phy_calibrate(dwc->usb2_generic_phy);
}
break;
case DWC3_GCTL_PRTCAP_DEVICE:
@@ -1166,7 +1165,6 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
dev_err(dev, "failed to initialize host\n");
return ret;
}
-   phy_calibrate(dwc->usb2_generic_phy);
break;
case USB_DR_MODE_OTG:
INIT_WORK(&dwc->drd_work, __dwc3_set_mode);
-- 
2.17.1

[PATCH 1/3] usb: host: xhci-plat: Add support for Exynos5/DWC3 specific variant

[Marek Szyprowski]

USB3.0 DRD PHY found in Exynos5 SoCs requires calibration to be done
after every HCD reset. This was initially handled by DWC3 core by commit
d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800"), but it turned out that the mentioned patch worked only
by the pure luck and fixed only one use case.

PHY calibration was done in DWC3 driver, just before initializing XHCI
core. This approach was prone to a race. It worked for the fresh boot
case iff XHCI-plat driver was compiled into the kernel or it's module has
been loaded before DWC3 probe. In other cases (XHCI-plat module loaded on
demand after DWC3 probe or during suspend/resume cycle) - the
calibration was not performed at proper time and had no effect.

This patch creates Exynos5/DWC3 specific variant of XHCI-plat driver,
which takes care of proper PHY calibration after XHCI core reset, what
fixes all known use cases (XHCI driver compiled as module and loaded on
demand as well as during system suspend/resume cycle).

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/host/Kconfig   |  8 ++
 drivers/usb/host/Makefile  |  3 ++
 drivers/usb/host/xhci-exynos.c | 51 ++
 drivers/usb/host/xhci-exynos.h | 26 +
 drivers/usb/host/xhci-plat.c   | 38 -
 drivers/usb/host/xhci-plat.h   |  2 ++
 6 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/host/xhci-exynos.c
 create mode 100644 drivers/usb/host/xhci-exynos.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 40b5de597112..5a17a9b1fbff 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -53,6 +53,14 @@ config USB_XHCI_PLATFORM
 
  If unsure, say N.
 
+config USB_XHCI_EXYNOS
+   tristate "xHCI support for Samsung Exynos SoCs"
+   depends on USB_XHCI_PLATFORM
+   depends on ARCH_EXYNOS || COMPILE_TEST
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Samsung Exynos ARM SoCs.
+
 config USB_XHCI_HISTB
tristate "xHCI support for HiSilicon STB SoCs"
depends on USB_XHCI_PLATFORM && (ARCH_HISI || COMPILE_TEST)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 84514f71ae44..34afd6680751 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,9 @@ endif
 ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
 endif
+ifneq ($(CONFIG_USB_XHCI_EXYNOS), )
+   xhci-plat-hcd-y += xhci-exynos.o
+endif
 
 ifneq ($(CONFIG_DEBUG_FS),)
xhci-hcd-y  += xhci-debugfs.o
diff --git a/drivers/usb/host/xhci-exynos.c b/drivers/usb/host/xhci-exynos.c
new file mode 100644
index ..446d33998382
--- /dev/null
+++ b/drivers/usb/host/xhci-exynos.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * xHCI host controller driver for Samsung Exynos5 SoCs
+ *
+ * Copyright (C) 2019 Samsung Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+#include "xhci-plat.h"
+#include "xhci-exynos.h"
+
+int xhci_exynos_init_quirk(struct usb_hcd *hcd)
+{
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   struct device *dev = hcd->self.controller;
+   struct xhci_plat_priv *xhci_priv = hcd_to_xhci_priv(hcd);
+   struct phy *usb2_generic_phy;
+   int ret;
+
+   usb2_generic_phy = devm_phy_get(dev->parent, "usb2-phy");
+   if (IS_ERR(usb2_generic_phy)) {
+   ret = PTR_ERR(usb2_generic_phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else {
+   dev_err(dev, "no usb2 phy configured\n");
+   return ret;
+   }
+   }
+
+   phy_calibrate(usb2_generic_phy);
+   xhci_priv->priv = usb2_generic_phy;
+
+   xhci->quirks |= XHCI_RESET_ON_RESUME;
+
+   return 0;
+}
+
+int xhci_exynos_post_resume_quirk(struct usb_hcd *hcd)
+{
+   struct xhci_plat_priv *xhci_priv = hcd_to_xhci_priv(hcd);
+   struct phy *usb2_generic_phy = xhci_priv->priv;
+
+   phy_calibrate(usb2_generic_phy);
+
+   return 0;
+}
diff --git a/drivers/usb/host/xhci-exynos.h b/drivers/usb/host/xhci-exynos.h
new file mode 100644
index ..58ea3e9aea8d
--- /dev/null
+++ b/drivers/usb/host/xhci-exynos.h
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * drivers/usb/host/xhci-exynos.h
+ *
+ * Copyright (C) 2019 Samsung Electronics Co., Ltd.
+ */
+
+#ifndef _XHCI_EXYNOS_H
+#define _XHCI_EXYNOS_H
+
+
+#if IS_ENABLED(CONFIG_USB_XHCI_EXYNOS)
+int xhci_exynos_init_quirk(struct usb_hcd *hcd);
+int xhci_exynos_post_resume_quirk(struct usb_hcd *hcd);
+#else
+static inline int xhci_exynos_init_quirk(struct usb_hcd *hcd)
+{
+   return 0;
+}
+
+static inline int xhci_exynos_post_resume_quirk(struct usb_hcd *hcd)
+{
+   return 0;
+}
+#endif
+#endif /* _XHCI_EXYNOS_H */
diff --git a/drivers/usb/host/xhci-

[PATCH 0/3] Fix USB3.0 DRD PHY calibration issues (DWC3/XHCI) on Exynos542x SoCs

[Marek Szyprowski]

Dear All,

Commit d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800") added support for Exynos5 USB3.0 DRD PHY calibration,
what enabled proper Super-Speed enumeration of USB3.0 devices connected
to various Exynos5 SoCs. After some time it turned out that the mentioned
patch worked a bit by pure luck and covered only one use case (fresh
boot with all drivers compiled into the kernel).

If drivers were compiled as modules, due to timing issue, it worked only
if XHCI-plat driver was loaded before the DWC3 driver:
https://patchwork.kernel.org/patch/10773947/

Also during the system suspend/resume cycle the calibration was not
performed at the proper time and resulted in switching USB 3.0 devices to
USB 2.0 high-speed compatibility mode.

This patch addresses all those issues. Exynos5 USB3.0 DRD PHY calibration
is moved to the Exynos5 specific variant of the XHCI-plat driver, which
takes care of proper PHY calibration after XHCI core reset. This fixes
all known use cases (XHCI driver compiled as module and loaded on demand
as well as during system suspend/resume cycle).

Here are the logs taken on Exynos5422-based Odroid HC1 board (with USB3.0
RTL8153 LAN and USB3.0 JMicron SATA-USB bridge):

Vanilla Linux next-20190620:
->8-
root@target:~# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
root@target:~# time rtcwake -s 10 -m mem
rtcwake: wakeup from "mem" using /dev/rtc0 at Tue Jan  1 01:03:40 2019
[   31.372801] PM: suspend entry (deep)
[   31.376555] Filesystems sync: 0.001 seconds
[   31.396437] Freezing user space processes ... (elapsed 0.006 seconds) done.
[   31.408300] OOM killer disabled.
[   31.411329] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[   31.419336] printk: Suspending console(s) (use no_console_suspend to debug)
[   31.508432] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   31.586243] wake enabled for irq 145
[   31.748908] samsung-pinctrl 1340.pinctrl: Setting external wakeup 
interrupt mask: 0xffef
[   31.758671] Disabling non-boot CPUs ...
[   31.772117] IRQ 51: no longer affine to CPU1
[   31.782147] IRQ 52: no longer affine to CPU2
[   31.789290] IRQ 53: no longer affine to CPU3
[   31.792439] IRQ 54: no longer affine to CPU4
[   31.794942] IRQ 55: no longer affine to CPU5
[   31.797365] IRQ 56: no longer affine to CPU6
[   31.801387] IRQ 57: no longer affine to CPU7
[   31.811149] Enabling non-boot CPUs ...
[   31.815607] CPU1 is up
[   31.818790] CPU2 is up
[   31.821709] CPU3 is up
[   31.826095] CPU4 is up
[   31.828672] CPU5 is up
[   31.831215] CPU6 is up
[   31.834158] CPU7 is up
[   31.859900] s3c2410-wdt 101d.watchdog: watchdog disabled
[   31.860158] usb usb1: root hub lost power or was reset
[   31.931175] usb usb2: root hub lost power or was reset
[   31.940717] wake disabled for irq 145
[   31.949146] usb usb3: root hub lost power or was reset
[   31.949235] usb usb4: root hub lost power or was reset
[   31.949329] s3c-rtc 101e.rtc: rtc disabled, re-enabling
[   31.950751] usb usb5: root hub lost power or was reset
[   31.950773] usb usb6: root hub lost power or was reset
[   36.201351] OOM killer enabled.
[   36.204381] Restarting tasks ...
[   36.206110] usb 4-1: USB disconnect, device number 2
[   36.206529] usb 6-1: USB disconnect, device number 2
[   36.210588] done.
[   36.220679] PM: suspend exit

real0m15.613s
user0m0.000s
sys 0m0.329s
[   36.237525] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   36.254403] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 
40Hz, actual 396825HZ div = 63)
root@target:~# [   36.341609] mmc_host mmc0: Bus speed (slot 0) = 2Hz 
(slot req 2Hz, actual 2HZ div = 0)
[   36.597244] usb 5-1: new high-speed USB device number 3 using xhci-hcd
[   36.837573] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: 
hostbyte=0x07 driverbyte=0x00
[   37.099089] usb 5-1: New USB device found, idVendor=0bda, idProduct=8153, 
bcdDevice=30.00
[   37.105793] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[   37.112962] usb 5-1: Product: USB 10/100/1000 LAN
[   37.117629] usb 5-1: Manufacturer: Realtek
[   37.121645] usb 5-1: SerialNumber: 0100
[   37.373152] usb 5-1: reset high-speed USB device number 3 using xhci-hcd
[   37.407459] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?
[   37.664128] r8152 5-1:1.0 eth0: v1.09.9
[   38.4

[PATCH 2/3] usb: dwc3: exynos: Use Exynos specific XHCI-plat driver variant

[Marek Szyprowski]

Exynos5 SoCs needs to calibrate USB3.0 DRD PHY after every XHCI HCD
reset. This patch adds support for instantiating Exynos5-specific variant
of XHCI-plat driver, which handles the required USB3.0 DRD PHY
calibration.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc3/Kconfig   |  1 +
 drivers/usb/dwc3/core.c|  1 +
 drivers/usb/dwc3/core.h|  1 +
 drivers/usb/dwc3/dwc3-exynos.c | 64 +++---
 drivers/usb/dwc3/host.c|  2 +-
 5 files changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 89abc6078703..badf86dfb027 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -67,6 +67,7 @@ config USB_DWC3_OMAP
 config USB_DWC3_EXYNOS
tristate "Samsung Exynos Platform"
depends on (ARCH_EXYNOS || COMPILE_TEST) && OF
+   select USB_XHCI_EXYNOS if USB_XHCI_PLATFORM
default USB_DWC3
help
  Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c9bb93a2c81e..baa029ceede9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1303,6 +1303,7 @@ static void dwc3_get_properties(struct dwc3 *dwc)
&dwc->hsphy_interface);
device_property_read_u32(dev, "snps,quirk-frame-length-adjustment",
 &dwc->fladj);
+   device_property_read_string(dev, "snps,xhci_variant", &dwc->hcd_name);
 
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 3dd783b889cb..1b8f5f5814a4 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1176,6 +1176,7 @@ struct dwc3 {
u8  tx_max_burst_prd;
 
const char  *hsphy_interface;
+   const char  *hcd_name;
 
unsignedconnected:1;
unsigneddelayed_status:1;
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index c1e9ea621f41..4e847073e85e 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,22 +36,20 @@ struct dwc3_exynos {
 
struct regulator*vdd33;
struct regulator*vdd10;
+   struct platform_device  *dwc3;
 };
 
-static int dwc3_exynos_remove_child(struct device *dev, void *unused)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-
-   platform_device_unregister(pdev);
-
-   return 0;
-}
+static const struct property_entry dwc3_exynos_properties[] = {
+   PROPERTY_ENTRY_STRING("snps,xhci_variant", "exynos5-dwc3-xhci"),
+   {}
+};
 
 static int dwc3_exynos_probe(struct platform_device *pdev)
 {
struct dwc3_exynos  *exynos;
struct device   *dev = &pdev->dev;
-   struct device_node  *node = dev->of_node;
+   struct device_node  *node = dev->of_node, *child;
+   struct platform_device  *dwc3;
const struct dwc3_exynos_driverdata *driver_data;
int i, ret;
 
@@ -109,21 +108,43 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto vdd10_err;
}
 
-   if (node) {
-   ret = of_platform_populate(node, NULL, NULL, dev);
-   if (ret) {
-   dev_err(dev, "failed to add dwc3 core\n");
-   goto populate_err;
-   }
-   } else {
-   dev_err(dev, "no device node, failed to add dwc3 core\n");
-   ret = -ENODEV;
-   goto populate_err;
+   child = of_get_next_child(node, NULL);
+   if (!child) {
+   dev_err(dev, "Failed to find DWC3 core device node\n");
+   goto dwc3_child_err;
+   }
+
+   dwc3 = of_device_alloc(child, NULL, dev);
+   if (!dwc3) {
+   dev_err(dev, "Failed to allocate DWC3 core device\n");
+   goto dwc3_alloc_err;
+   }
+
+   dwc3->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   dwc3->dev.dma_mask = &dwc3->dev.coherent_dma_mask;
+   dwc3->dev.bus = &platform_bus_type;
+
+   ret = platform_device_add_properties(dwc3, dwc3_exynos_properties);
+   if (ret < 0) {
+   dev_err(dev, "Failed to add properties to DWC3 device\n");
+   goto dwc3_props_err;
+   }
+
+   ret = of_device_add(dwc3);
+   if (ret) {
+   dev_err(&pdev->dev, "Failed to register DWC3 core device\n");
+   goto dwc3_props_err;
}
+   exynos->dwc3 = dwc3;
+   of_node_put(child);
 
return 0;
 
-populate_err:
+dwc3_props_err:
+   platform_device_put(dwc3);
+dwc3_alloc_err:
+   of_node_put(child);
+dwc3_ch

Re: [PATCH][next][V2] media: vivid: fix potential integer overflow on left shift

[Hans Verkuil]

On 6/26/19 4:47 PM, Colin King wrote:
> From: Colin Ian King 
> 
> There is a potential integer overflow when int 2 is left shifted
> as this is evaluated using 32 bit arithmetic but is being used in
> a context that expects an expression of type s64.  Fix this by
> shifting 2ULL to avoid a 32 bit overflow.
> 
> Addresses-Coverity: ("Unintentional integer overflow")
> Fixes: 8a99e9faa131 ("media: vivid: add HDMI (dis)connect RX emulation")
> Fixes: 79a792dafac6 ("media: vivid: add HDMI (dis)connect TX emulation")
> Signed-off-by: Colin Ian King 
> ---
> V2: use intermediate variables for the shifted expression to make code
> a bit more readable.
> ---
>  drivers/media/platform/vivid/vivid-ctrls.c | 24 +++---
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
> b/drivers/media/platform/vivid/vivid-ctrls.c
> index 3e916c8befb7..df1598e81c7a 100644
> --- a/drivers/media/platform/vivid/vivid-ctrls.c
> +++ b/drivers/media/platform/vivid/vivid-ctrls.c
> @@ -1613,6 +1613,8 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
> show_ccs_cap,
>   }
>  
>   if (dev->num_hdmi_inputs) {
> + s64 hdmi_input = (2ULL << (dev->num_hdmi_inputs - 1)) - 1;

Please call this hdmi_input_mask, ditto for the hdmi_output. This is a bitmask,
not an HDMI input index.

We should also use the GENMASK macro here:

s64 hdmi_input_mask = GENMASK(dev->num_hdmi_inputs - 1, 0);

This is a lot easier to understand.

Regards,

Hans

> +
>   dev->ctrl_dv_timings_signal_mode = 
> v4l2_ctrl_new_custom(hdl_vid_cap,
>   &vivid_ctrl_dv_timings_signal_mode, 
> NULL);
>  
> @@ -1633,12 +1635,13 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
> show_ccs_cap,
>   V4L2_CID_DV_RX_RGB_RANGE, V4L2_DV_RGB_RANGE_FULL,
>   0, V4L2_DV_RGB_RANGE_AUTO);
>   dev->ctrl_rx_power_present = v4l2_ctrl_new_std(hdl_vid_cap,
> - NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0,
> - (2 << (dev->num_hdmi_inputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_inputs - 1)) - 1);
> + NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0, hdmi_input,
> + 0, hdmi_input);
>  
>   }
>   if (dev->num_hdmi_outputs) {
> + s64 hdmi_output = (2ULL << (dev->num_hdmi_outputs - 1)) - 1;
> +
>   /*
>* We aren't doing anything with this at the moment, but
>* HDMI outputs typically have this controls.
> @@ -1652,17 +1655,14 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
> show_ccs_cap,
>   dev->ctrl_display_present = v4l2_ctrl_new_custom(hdl_vid_out,
>   &vivid_ctrl_display_present, NULL);
>   dev->ctrl_tx_hotplug = v4l2_ctrl_new_std(hdl_vid_out,
> - NULL, V4L2_CID_DV_TX_HOTPLUG, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + NULL, V4L2_CID_DV_TX_HOTPLUG, 0, hdmi_output,
> + 0, hdmi_output);
>   dev->ctrl_tx_rxsense = v4l2_ctrl_new_std(hdl_vid_out,
> - NULL, V4L2_CID_DV_TX_RXSENSE, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + NULL, V4L2_CID_DV_TX_RXSENSE, 0, hdmi_output,
> + 0, hdmi_output);
>   dev->ctrl_tx_edid_present = v4l2_ctrl_new_std(hdl_vid_out,
> - NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0, hdmi_output,
> + 0, hdmi_output);
>   }
>   if ((dev->has_vid_cap && dev->has_vid_out) ||
>   (dev->has_vbi_cap && dev->has_vbi_out))
> 

Re: [PATCH 3/4] powerpc/powernv: remove unused NPU DMA code

[Christoph Hellwig]

On Thu, Jun 27, 2019 at 10:21:55AM +1000, Alexey Kardashevskiy wrote:
> > Which comment?  Last time I asked you complaint "it is still used in
> > exactly the same way as before" which you later clarified that you
> > have a hidden out of tree user somewhere, and you only objected to
> 
> It is not hidden, anyone can download and inspect that GPL driver.

For one no one has ever posted a link.  And second as mentioned
countless times it doesn't matter, it only matters if it is in mainline,
or as a special exception actively trying to go mainline.

> > the word "dead".  That has been fixed and there were no further
> > comments.
> 
> You still have it in the cover letter so at very least 3/4 is not a part
> of this patchset then.
> 
> And I still want to see a formal statement about out-of-tree drivers
> support/tolerance. If you manage to remove this code, I'll have to post
> a revert (again and again) but I would rather know the exact list of
> what we do and what we do not do about such drivers and if the list 1)
> exists 2) is reasonable then I could try to come up with a better
> solution or point others to the policy and push them to do the right
> thing. Right now it is just you pretending that the nVidia driver does
> not exist, this is not helping. Thanks,

We had that discussion at kernel summit and it was reported.  Anyway,
adding Greg, who usually has some pretty good prewritten letters for
this kind of thing.

Re: [PATCH bpf v4 2/2] xdp: fix hang while unregistering device bound to xdp socket

[Ilya Maximets]

On 26.06.2019 21:34, Jakub Kicinski wrote:
> On Wed, 26 Jun 2019 21:15:15 +0300, Ilya Maximets wrote:
>> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
>> index 267b82a4cbcf..56729e74cbea 100644
>> --- a/net/xdp/xdp_umem.c
>> +++ b/net/xdp/xdp_umem.c
>> @@ -140,34 +140,38 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct 
>> net_device *dev,
>>  return err;
>>  }
>>  
>> -static void xdp_umem_clear_dev(struct xdp_umem *umem)
>> +void xdp_umem_clear_dev(struct xdp_umem *umem)
>>  {
>> +bool lock = rtnl_is_locked();
> 
> How do you know it's not just locked by someone else?  You need to pass
> the locked state in if this is called from different paths, some of
> which already hold rtnl.

Oh. That's a shame. I need more sleep.

Thanks for spotting. I'll re-work this part.

Best regards, Ilya Maximets.

> 
> Preferably factor the code which needs the lock out into a separate
> function like this:
> 
> void __function()
> {
>   do();
>   the();
>   things();
>   under();
>   the();
>   lock();
> }
> 
> void function()
> {
>   rtnl_lock();
>   __function();
>   rtnl_unlock();
> }
> 
>>  struct netdev_bpf bpf;
>>  int err;
>>  
>> +if (!lock)
>> +rtnl_lock();
> 
> 
> 

Re: [PATCH v2 1/2] dt-bindings: i3c: Document MediaTek I3C master bindings

[Qii Wang]

On Wed, 2019-06-26 at 18:23 +0200, Boris Brezillon wrote:
> On Wed, 26 Jun 2019 13:36:27 +0800
> Qii Wang  wrote:
> 
> > Document MediaTek I3C master DT bindings.
> > 
> > Signed-off-by: Qii Wang 
> > ---
> >  .../devicetree/bindings/i3c/mtk,i3c-master.txt |   47 
> > 
> >  1 file changed, 47 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt 
> > b/Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
> > new file mode 100644
> > index 000..3fd4f17
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/mtk,i3c-master.txt
> > @@ -0,0 +1,47 @@
> > +Bindings for MediaTek I3C master block
> > +=
> > +
> > +Required properties:
> > +
> > +- compatible: shall be "mediatek,i3c-master"
> > +- reg: physical base address of the controller and apdma base, length of
> > +  memory mapped region.
> > +- reg-names: should be "main" for controller and "dma" for apdma.
> > +- interrupts: interrupt number to the cpu.
> 
> Depending on the interrupt controller, each interrupt cell might
> contain more than just the interrupt number.
> 

ok, I will modify it as "the interrupt line connected to this I3C
master"

> > +- clocks: clock name from clock manager.
> 
> This property does not contain clock names but clk references.
> 

ok, I will modify it as "shall reference the i3c and apdma clocks"

> > +- clock-names: must include "main" and "dma".
> > +
> > +Mandatory properties defined by the generic binding (see
> > +Documentation/devicetree/bindings/i3c/i3c.txt for more details):
> > +
> > +- #address-cells: shall be set to 3
> > +- #size-cells: shall be set to 0
> > +
> > +Optional properties defined by the generic binding (see
> > +Documentation/devicetree/bindings/i3c/i3c.txt for more details):
> > +
> > +- i2c-scl-hz
> > +- i3c-scl-hz
> > +
> > +I3C device connected on the bus follow the generic description (see
> > +Documentation/devicetree/bindings/i3c/i3c.txt for more details).
> > +
> > +Example:
> > +
> > +   i3c0: i3c@1100d000 {
> > +   compatible = "mediatek,i3c-master";
> > +   reg = <0x1100d000 0x100>,
> > + <0x11000300 0x80>;
> > +   reg-names = "main", "dma";
> > +   interrupts = ;
> > +   clocks = <&i3c0_ck>, <&ap_dma_ck>;
> > +   clock-names = "main", "dma";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   i2c-scl-hz = <10>;
> > +
> > +   nunchuk: nunchuk@52 {
> > +   compatible = "nintendo,nunchuk";
> > +   reg = <0x52 0x8010 0>;
> 
> reg is wrong here, should be
> 
>   reg = <0x52 0x0 0x10>;
> 
> While at it, can you send a patch to fix the example in the cadence
> binding doc?
> 

ok, I will do it. Thanks for your review.

> > +   };
> > +   };
> 

Re: [PATCH v4 3/7] s390: zcrypt: driver callback to indicate resource in use

[Cornelia Huck]

On Wed, 26 Jun 2019 17:13:50 -0400
Tony Krowiak  wrote:

> On 6/19/19 9:04 AM, Tony Krowiak wrote:
> > On 6/18/19 12:25 PM, Cornelia Huck wrote:  
> >> On Thu, 13 Jun 2019 15:39:36 -0400
> >> Tony Krowiak  wrote:
> >>  
> >>> Introduces a new driver callback to prevent a root user from unbinding
> >>> an AP queue from its device driver if the queue is in use. This prevents
> >>> a root user from inadvertently taking a queue away from a guest and
> >>> giving it to the host, or vice versa. The callback will be invoked
> >>> whenever a change to the AP bus's apmask or aqmask sysfs interfaces may
> >>> result in one or more AP queues being removed from its driver. If the
> >>> callback responds in the affirmative for any driver queried, the change
> >>> to the apmask or aqmask will be rejected with a device in use error.
> >>>
> >>> For this patch, only non-default drivers will be queried. Currently,
> >>> there is only one non-default driver, the vfio_ap device driver. The
> >>> vfio_ap device driver manages AP queues passed through to one or more
> >>> guests and we don't want to unexpectedly take AP resources away from
> >>> guests which are most likely independently administered.
> >>>
> >>> Signed-off-by: Tony Krowiak 
> >>> ---
> >>>   drivers/s390/crypto/ap_bus.c | 138 
> >>> +--
> >>>   drivers/s390/crypto/ap_bus.h |   3 +
> >>>   2 files changed, 135 insertions(+), 6 deletions(-)  
> >>
> >> Hm... I recall objecting to this patch before, fearing that it makes it
> >> possible for a bad actor to hog resources that can't be removed by
> >> root, even forcefully. (I have not had time to look at the intervening
> >> versions, so I might be missing something.)
> >>
> >> Is there a way for root to forcefully override this?  
> > 
> > You recall correctly; however, after many internal crypto team
> > discussions, it was decided that this feature was important
> > and should be kept.
> > 
> > Allow me to first address your fear that a bad actor can hog
> > resources that can't be removed by root. With this enhancement,
> > there is nothing preventing a root user from taking resources
> > from a matrix mdev, it simply forces him/her to follow the
> > proper procedure. The resources to be removed must first be
> > unassigned from the matrix mdev to which they are assigned.
> > The AP bus's /sys/bus/ap/apmask and /sys/bus/ap/aqmask
> > sysfs attributes can then be edited to transfer ownership
> > of the resources to zcrypt.
> > 
> > The rationale for keeping this feature is:
> > 
> > * It is a bad idea to steal an adapter in use from a guest. In the worst
> >    case, the guest could end up without access to any crypto adapters
> >    without knowing why. This could lead to performance issues on guests
> >    that rely heavily on crypto such as guests used for blockchain
> >    transactions.
> > 
> > * There are plenty of examples in linux of the kernel preventing a root
> >    user from performing a task. For example, a module can't be removed
> >    if references are still held for it. Another example would be trying
> >    to bind a CEX4 adapter to a device driver not registered for CEX4;
> >    this action will also be rejected.
> > 
> > * The semantics are much cleaner and the logic is far less complicated.
> > 
> > * It forces the use of the proper procedure to change ownership of AP
> >    queues.
> >  
> 
> Any feedback on this?

Had not yet time to look at this, sorry.


> 
> Tony K
> 
> >   
> >>  
> >   
> 

[PATCH v2] arm64: dts: sdm845: Add video nodes

[Aniket Masule]

From: Malathi Gottam 

This adds video nodes to sdm845 based on the examples
in the bindings.

Signed-off-by: Malathi Gottam 
Co-developed-by: Aniket Masule 
Signed-off-by: Aniket Masule 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index fcb9330..94813a9 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1893,6 +1893,36 @@
};
};
 
+   video-codec@aa0 {
+   compatible = "qcom,sdm845-venus";
+   reg = <0x0aa0 0xff000>;
+   interrupts = ;
+   power-domains = <&videocc VENUS_GDSC>;
+   clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+<&videocc VIDEO_CC_VENUS_AHB_CLK>,
+<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
+   clock-names = "core", "iface", "bus";
+   iommus = <&apps_smmu 0x10a0 0x8>,
+<&apps_smmu 0x10b0 0x0>;
+   memory-region = <&venus_region>;
+
+   video-core0 {
+   compatible = "venus-decoder";
+   clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+   clock-names = "core", "bus";
+   power-domains = <&videocc VCODEC0_GDSC>;
+   };
+
+   video-core1 {
+   compatible = "venus-encoder";
+   clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
+   clock-names = "core", "bus";
+   power-domains = <&videocc VCODEC1_GDSC>;
+   };
+   };
+
videocc: clock-controller@ab0 {
compatible = "qcom,sdm845-videocc";
reg = <0 0x0ab0 0 0x1>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2] arm64: dts: sdm845: Add video nodes

[Aniket Masule]

This adds video nodes to sdm845 based on the examples
in the bindings.

Changes since v1:
 - Corrected the Signed-off-by ordering.
 - Corrected the node position based on the address.

Aniket Masule (1):
  arm64: dts: sdm845: Add video nodes

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 30 ++
 1 file changed, 30 insertions(+)

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

Re: [PATCH v5 4/7] perf diff: Use hists to manage basic blocks per symbol

[Jiri Olsa]

On Thu, Jun 27, 2019 at 10:09:26PM +0800, Jin Yao wrote:

SNIP

> +
> +static int process_block_per_sym(struct hist_entry *he)
> +{
> + struct annotation *notes;
> + struct cyc_hist *ch;
> + struct block_hist *bh;
> +
> + if (!he->ms.map || !he->ms.sym)
> + return 0;
> +
> + notes = symbol__annotation(he->ms.sym);
> + if (!notes || !notes->src || !notes->src->cycles_hist)
> + return 0;
> +
> + bh = container_of(he, struct block_hist, he);
> + init_block_hist(bh);
> +
> + ch = notes->src->cycles_hist;
> + for (unsigned int i = 0; i < symbol__size(he->ms.sym); i++) {
> + if (ch[i].num_aggr) {
> + struct block_info *bi;
> + struct hist_entry *he_block;
> +
> + bi = block_info__new();
> + if (!bi)
> + return -1;
> +
> + init_block_info(bi, he->ms.sym, &ch[i], i);
> + he_block = hists__add_entry_block(&bh->block_hists,
> +   NULL, &dummy_al, bi);

nit, it's the only caller of hists__add_entry_block, so we don't need
the 'ops' argument in there

other than this, this all looks good to me

Reviewed-by: Jiri Olsa 

thanks,
jirka

Re: [PATCH] media:vivid: add sanity check to avoid divide error and set value to 1 if 0.

[Hans Verkuil]

On 6/26/19 8:01 AM, Vandana BN wrote:
> Syzbot reported divide error in vivid_thread_vid_cap, which has been
> seen only once and doesnot have a reproducer.
> This patch sanity checks for the denominator value with WARN_ON if it is 0 
> and replaces it with 1.
> 
> Reported-by: syz...@syzkaller.appspotmail.com
> 
> divide error:  [#1] PREEMPT SMP KASAN
> kobject: 'tx-0' (17161f7f): kobject_uevent_env
> CPU: 0 PID: 23689 Comm: vivid-003-vid-c Not tainted 5.0.0-rc4+ #58
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:vivid_cap_update_frame_period
> drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline]
> RIP: 0010:vivid_thread_vid_cap+0x221/0x284
> drivers/media/platform/vivid/vivid-kthread-cap.c:789
> Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38
> ca
> 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49
> 89
> c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45
> RSP: 0018:88808b4afd68 EFLAGS: 00010246
> kobject: 'tx-0' (17161f7f): fill_kobj_path: path
> = '/devices/virtual/net/gre0/queues/tx-0'
> RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: 
> RDX:  RSI: 0004 RDI: 0004
> RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008
> R10: 89997010 R11: 0001 R12: fffc
> R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140
> FS:  () GS:8880ae80()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0
> Call Trace:
> kobject: 'gretap0' (d7549098): kobject_add_internal: parent:
> 'net',
> set: 'devices'
> kobject: 'loop2' (94ed4ee4): kobject_uevent_env
> kobject: 'loop2' (94ed4ee4): fill_kobj_path: path
> = '/devices/virtual/block/loop2'
>   kthread+0x357/0x430 kernel/kthread.c:246
> kobject: 'gretap0' (d7549098): kobject_uevent_env
>   ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> Modules linked in:
> kobject: 'gretap0' (d7549098): fill_kobj_path: path
> = '/devices/virtual/net/gretap0'
> ---[ end trace bc5c8b25b64d768f ]---
> kobject: 'loop1' (32036b86): kobject_uevent_env
> RIP: 0010:vivid_cap_update_frame_period
> drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline]
> RIP: 0010:vivid_thread_vid_cap+0x221/0x2840
> drivers/media/platform/vivid/vivid-kthread-cap.c:789
> kobject: 'loop1' (32036b86): fill_kobj_path: path
> = '/devices/virtual/block/loop1'
> Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38
> ca
> 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49
> 89
> c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45
> kobject: 'loop0' (dd9927c3): kobject_uevent_env
> RSP: 0018:88808b4afd68 EFLAGS: 00010246
> RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: 
> kobject: 'queues' (7ed20666): kobject_add_internal:
> parent: 'gretap0', set: ''
> RDX:  RSI: 0004 RDI: 0004
> RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008
> kobject: 'loop0' (dd9927c3): fill_kobj_path: path
> = '/devices/virtual/block/loop0'
> R10: 89997010 R11: 0001 R12: fffc
> kobject: 'queues' (7ed20666): kobject_uevent_env
> R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140
> FS:  () GS:8880ae80()
> knlGS:
> kobject: 'loop5' (a41f9e79): kobject_uevent_env
> CS:  0010 DS:  ES:  CR0: 80050033
> kobject: 'queues' (7ed20666): kobject_uevent_env: filter
> function
> caused the event to drop!
> CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0
> kobject: 'loop5' (a41f9e79): fill_kobj_path: path
> = '/devices/virtual/block/loop5'
> 
> Signed-off-by: Vandana BN 
> ---
>  drivers/media/platform/vivid/vivid-kthread-cap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c 
> b/drivers/media/platform/vivid/vivid-kthread-cap.c
> index f8006a30c12f..025a8c68bd1c 100644
> --- a/drivers/media/platform/vivid/vivid-kthread-cap.c
> +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
> @@ -658,6 +658,8 @@ static void vivid_cap_update_frame_period(struct 
> vivid_dev *dev)
>   u64 f_period;
>  
>   f_period = (u64)dev->timeperframe_vid_cap.numerator * 10;
> + if(WARN_ON(dev->timeperframe_vid_cap.denominator == 0))
> + dev->timeperframe_vid_cap.denominator = 1;
>   do_div(f_period, dev->timeperframe_vid_cap.denominator);
>   if (dev->field_cap == V4L2_FIELD_ALTERNATE)
>   f_period >>= 1;
> 

Always run the patch over 'checkpatch.pl --strict'. It gives me:

WARNING: Possible unwrapped commit description (prefer a maximum 75 ch

Re: [PATCH] arm64: Move jump_label_init() before parse_early_param()

[Ard Biesheuvel]

On Wed, 26 Jun 2019 at 22:51, Kees Cook  wrote:
>
> While jump_label_init() was moved earlier in the boot process in commit
> efd9e03facd0 ("arm64: Use static keys for CPU features"), it wasn't
> early enough for early params to use it. The old state of things was as
> described here...
>
> init/main.c calls out to arch-specific things before general jump
> label and early param handling:
>
> asmlinkage __visible void __init start_kernel(void)
> {
> ...
> setup_arch(&command_line);
> ...
> smp_prepare_boot_cpu();
> ...
> /* parameters may set static keys */
> jump_label_init();
> parse_early_param();
> ...
> }
>
> x86 setup_arch() wants those earlier, so it handles jump label and
> early param:
>
> void __init setup_arch(char **cmdline_p)
> {
> ...
> jump_label_init();
> ...
> parse_early_param();
> ...
> }
>
> arm64 setup_arch() only had early param:
>
> void __init setup_arch(char **cmdline_p)
> {
> ...
> parse_early_param();
> ...
> }
>
> with jump label later in smp_prepare_boot_cpu():
>
> void __init smp_prepare_boot_cpu(void)
> {
> ...
> jump_label_init();
> ...
> }
>
> This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> setup_arch(), as done already on x86, in preparation from early param
> usage in the init_on_alloc/free() series:
> https://lkml.kernel.org/r/1561572949.5154.81.ca...@lca.pw
>
> Signed-off-by: Kees Cook 

Acked-by: Ard Biesheuvel 

> ---
>  arch/arm64/kernel/setup.c | 5 +
>  arch/arm64/kernel/smp.c   | 5 -
>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 7e541f947b4c..9c4bad7d7131 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -283,6 +283,11 @@ void __init setup_arch(char **cmdline_p)
>
> setup_machine_fdt(__fdt_pointer);
>
> +   /*
> +* Initialise the static keys early as they may be enabled by the
> +* cpufeature code and early parameters.
> +*/
> +   jump_label_init();
> parse_early_param();
>
> /*
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 6dcf9607d770..20c456b3862c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -424,11 +424,6 @@ void __init smp_cpus_done(unsigned int max_cpus)
>  void __init smp_prepare_boot_cpu(void)
>  {
> set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
> -   /*
> -* Initialise the static keys early as they may be enabled by the
> -* cpufeature code.
> -*/
> -   jump_label_init();
> cpuinfo_store_boot_cpu();
>
> /*
> --
> 2.17.1
>
>
> --
> Kees Cook

[PATCH -next] xfs: remove duplicated include

[YueHaibing]

Remove duplicated include.

Signed-off-by: YueHaibing 
---
 fs/xfs/xfs_extfree_item.c | 1 -
 fs/xfs/xfs_filestream.c   | 1 -
 fs/xfs/xfs_pnfs.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/fs/xfs/xfs_extfree_item.c b/fs/xfs/xfs_extfree_item.c
index 99fd40eb..e515506 100644
--- a/fs/xfs/xfs_extfree_item.c
+++ b/fs/xfs/xfs_extfree_item.c
@@ -13,7 +13,6 @@
 #include "xfs_mount.h"
 #include "xfs_defer.h"
 #include "xfs_trans.h"
-#include "xfs_trans.h"
 #include "xfs_trans_priv.h"
 #include "xfs_buf_item.h"
 #include "xfs_extfree_item.h"
diff --git a/fs/xfs/xfs_filestream.c b/fs/xfs/xfs_filestream.c
index b1869ae..a6d228c 100644
--- a/fs/xfs/xfs_filestream.c
+++ b/fs/xfs/xfs_filestream.c
@@ -21,7 +21,6 @@
 #include "xfs_trace.h"
 #include "xfs_ag_resv.h"
 #include "xfs_trans.h"
-#include "xfs_shared.h"
 
 struct xfs_fstrm_item {
struct xfs_mru_cache_elem   mru;
diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c
index 2d95355..6018e1c 100644
--- a/fs/xfs/xfs_pnfs.c
+++ b/fs/xfs/xfs_pnfs.c
@@ -17,7 +17,6 @@
 #include "xfs_bmap_util.h"
 #include "xfs_error.h"
 #include "xfs_iomap.h"
-#include "xfs_shared.h"
 #include "xfs_bit.h"
 #include "xfs_pnfs.h"
 
-- 
2.7.4

Re: [PATCH v5 4/7] perf diff: Use hists to manage basic blocks per symbol

[Jin, Yao]

On 6/27/2019 3:27 PM, Jiri Olsa wrote:

On Thu, Jun 27, 2019 at 10:09:26PM +0800, Jin Yao wrote:

SNIP


+
+static int process_block_per_sym(struct hist_entry *he)
+{
+   struct annotation *notes;
+   struct cyc_hist *ch;
+   struct block_hist *bh;
+
+   if (!he->ms.map || !he->ms.sym)
+   return 0;
+
+   notes = symbol__annotation(he->ms.sym);
+   if (!notes || !notes->src || !notes->src->cycles_hist)
+   return 0;
+
+   bh = container_of(he, struct block_hist, he);
+   init_block_hist(bh);
+
+   ch = notes->src->cycles_hist;
+   for (unsigned int i = 0; i < symbol__size(he->ms.sym); i++) {
+   if (ch[i].num_aggr) {
+   struct block_info *bi;
+   struct hist_entry *he_block;
+
+   bi = block_info__new();
+   if (!bi)
+   return -1;
+
+   init_block_info(bi, he->ms.sym, &ch[i], i);
+   he_block = hists__add_entry_block(&bh->block_hists,
+ NULL, &dummy_al, bi);


nit, it's the only caller of hists__add_entry_block, so we don't need
the 'ops' argument in there

other than this, this all looks good to me

Reviewed-by: Jiri Olsa 

thanks,
jirka



Hi Jiri,

Thanks so much!

Do you need me to send v6 which only removes the 'ops' argument from 
hists__add_entry_block? Or this v5 should be OK either?



Thanks
Jin Yao

Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

[Peter Zijlstra]

On Wed, Jun 26, 2019 at 03:23:24PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 26, 2019 at 2:55 AM Peter Zijlstra  wrote:
> >
> > On Wed, Jun 26, 2019 at 11:24:32AM +0200, Peter Zijlstra wrote:
> > > That's pretty atrocious code-gen :/
> >
> > And I know nobody reads comments (I don't either), but I did write one
> > on this as it happens.
> 
> I've definitely read that block in include/linux/jump_label.h; can't
> say I fully understand it yet, but appreciate patience and
> explanations.

So the relevant bits are:

 * type\branch| likely (1)| unlikely (0)
 * ---+---+--
 *|   |
 *  true (1)  |...|...
 *|NOP|JMP L
 *| | 1: ...
 *| L: ...|
 *|   |
 *|   | L: 
 *|   |jmp 1b
 *|   |
 * ---+---+--
 *|   |
 *  false (0) |...|...
 *|JMP L  |NOP
 *| | 1: ...
 *| L: ...|
 *|   |
 *|   | L: 
 *|   |jmp 1b
 *|   |
 * ---+---+--

So we have two types, static_key_true, which defaults to true and
static_key_false, which defaults (unsurprisingly) to false. At runtime
they can be switched at will, it is just the initial state which
determines what code we actually need to emit at compile time.

And we have two statements: static_branch_likely(), the branch is likely
-- or we want the block in-line, and static_branch_unlikely(), the
branch is unlikely -- or we want the block out-of-line.

This is coded like:

#define static_branch_likely(x) 
\
({  
\
bool branch;
\
if (__builtin_types_compatible_p(typeof(*x), struct static_key_true))   
\
branch = !arch_static_branch(&(x)->key, true);  
\
else if (__builtin_types_compatible_p(typeof(*x), struct 
static_key_false)) \
branch = !arch_static_branch_jump(&(x)->key, true); 
\
else
\
branch = wrong_branch_error();  
\
likely(branch); 
\
})

#define static_branch_unlikely(x)   
\
({  
\
bool branch;
\
if (__builtin_types_compatible_p(typeof(*x), struct static_key_true))   
\
branch = arch_static_branch_jump(&(x)->key, false); 
\
else if (__builtin_types_compatible_p(typeof(*x), struct 
static_key_false)) \
branch = arch_static_branch(&(x)->key, false);  
\
else
\
branch = wrong_branch_error();  
\
unlikely(branch);   
\
})

Let's walk through static_branch_unlikely() (the other is very similar,
just reversed).

We use __builtin_types_compatible_p() to compile-time detect which key
type is used, such that we can emit the right initial code:

  - static_key_true; we must emit a JMP to the block,
  - static_key_false; we must emit a NOP and not execute the block.
  - neither; we generate a link error.

Then we take the return value and use __builtin_expect(, 0) on it to
influence the block layout, specifically we want the block to be
out-of-line.

It appears the __builtin_expect() usage isn't working right with LLVM
resuling in that layout issue Thomas spotted. GCC8+ can even place them
in the .text.unlikely section as func.cold.N parts/symbols. But the main
point is to get the block away from the normal I$ content to minimize
impact.

[tip:smp/urgent] cpu/hotplug: Fix out-of-bounds read when setting fail state

[tip-bot for Eiichi Tsukata]

Commit-ID:  33d4a5a7a5b4d02915d765064b2319e90a11cbde
Gitweb: https://git.kernel.org/tip/33d4a5a7a5b4d02915d765064b2319e90a11cbde
Author: Eiichi Tsukata 
AuthorDate: Thu, 27 Jun 2019 11:47:32 +0900
Committer:  Thomas Gleixner 
CommitDate: Thu, 27 Jun 2019 09:34:04 +0200

cpu/hotplug: Fix out-of-bounds read when setting fail state

Setting invalid value to /sys/devices/system/cpu/cpuX/hotplug/fail
can control `struct cpuhp_step *sp` address, results in the following
global-out-of-bounds read.

Reproducer:

  # echo -2 > /sys/devices/system/cpu/cpu0/hotplug/fail

KASAN report:

  BUG: KASAN: global-out-of-bounds in write_cpuhp_fail+0x2cd/0x2e0
  Read of size 8 at addr 89734438 by task bash/1941

  CPU: 0 PID: 1941 Comm: bash Not tainted 5.2.0-rc6+ #31
  Call Trace:
   write_cpuhp_fail+0x2cd/0x2e0
   dev_attr_store+0x58/0x80
   sysfs_kf_write+0x13d/0x1a0
   kernfs_fop_write+0x2bc/0x460
   vfs_write+0x1e1/0x560
   ksys_write+0x126/0x250
   do_syscall_64+0xc1/0x390
   entry_SYSCALL_64_after_hwframe+0x49/0xbe
  RIP: 0033:0x7f05e4f4c970

  The buggy address belongs to the variable:
   cpu_hotplug_lock+0x98/0xa0

  Memory state around the buggy address:
   89734300: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
   89734380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  >89734400: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
  ^
   89734480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   89734500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Add a sanity check for the value written from user space.

Fixes: 1db49484f21ed ("smp/hotplug: Hotplug state fail injection")
Signed-off-by: Eiichi Tsukata 
Signed-off-by: Thomas Gleixner 
Cc: pet...@infradead.org
Link: https://lkml.kernel.org/r/20190627024732.31672-1-de...@etsukata.com

---
 kernel/cpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 551db494f153..ef1c565edc5d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1964,6 +1964,9 @@ static ssize_t write_cpuhp_fail(struct device *dev,
if (ret)
return ret;
 
+   if (fail < CPUHP_OFFLINE || fail > CPUHP_ONLINE)
+   return -EINVAL;
+
/*
 * Cannot fail STARTING/DYING callbacks.
 */

Re: [PATCH v2] jffs2: remove C++ style comments from uapi header

[Richard Weinberger]

- Ursprüngliche Mail -
> Von: "Masahiro Yamada" 
> An: "richard" 
> CC: "Vignesh Raghavendra" , "Boris Brezillon" 
> , "linux-kernel"
> , "Marek Vasut" , 
> "linux-mtd" ,
> "Miquel Raynal" , "Brian Norris" 
> , "David Woodhouse"
> 
> Gesendet: Donnerstag, 27. Juni 2019 09:06:31
> Betreff: Re: [PATCH v2] jffs2: remove C++ style comments from uapi header

> On Tue, Jun 18, 2019 at 3:20 PM Richard Weinberger  wrote:
>>
>> - Ursprüngliche Mail -
>> > Von: "Masahiro Yamada" 
>> > An: "linux-mtd" 
>> > CC: "Boris Brezillon" , "Miquel Raynal"
>> > , "Brian Norris"
>> > , "Vignesh Raghavendra" , 
>> > "Marek
>> > Vasut" ,
>> > "Masahiro Yamada" , "richard" 
>> > ,
>> > "David Woodhouse" ,
>> > "linux-kernel" 
>> > Gesendet: Dienstag, 18. Juni 2019 05:09:26
>> > Betreff: [PATCH v2] jffs2: remove C++ style comments from uapi header
>>
>> > Linux kernel tolerates C++ style comments these days. Actually, the
>> > SPDX License tags for .c files start with //.
>> >
>> > On the other hand, uapi headers are written in more strict C, where
>> > the C++ comment style is forbidden.
>> >
>> > I simply dropped these lines instead of fixing the comment style.
>> >
>> > This code has been always commented out since it was added around
>> > Linux 2.4.9 (i.e. commented out for more than 17 years).
>> >
>> > 'Maybe later...' will never happen.
>>
>> :-)
>>
>> > Signed-off-by: Masahiro Yamada 
>>
>> Acked-by: Richard Weinberger 
>>
>> Thanks,
>> //richard
> 
> 
> Will this be picked up for v5.3-rc1 ?

Yes.

Thanks,
//richard

Re: [PATCH] mtd: abi: do not use C++ style comments in uapi header

[Richard Weinberger]

- Ursprüngliche Mail -
> Von: "Masahiro Yamada" 
> An: "David Woodhouse" , "Brian Norris" 
> , "Marek Vasut"
> , "Miquel Raynal" , 
> "richard" , "Vignesh Raghavendra"
> , "linux-mtd" 
> CC: "Masahiro Yamada" , "linux-kernel" 
> 
> Gesendet: Donnerstag, 27. Juni 2019 09:07:45
> Betreff: [PATCH] mtd: abi: do not use C++ style comments in uapi header

> Linux kernel tolerates C++ style comments these days. Actually, the
> SPDX License tags for .c files start with //.
> 
> On the other hand, uapi headers are written in more strict C, where
> the C++ comment style is forbidden.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Richard Weinberger 

Thanks,
//richard

Re: [PATCH 2/2] dt-bindings: arm: fsl: Add DSP IPC binding support

[Daniel Baluta]

> > > > +  mboxes:
> > > > +description:
> > > > +  List of phandle of 2 MU channels for TXDB, 2 MU channels for RXDB
> > > > +  (see mailbox/fsl,mu.txt)
> > > > +maxItems: 1
> > >
> > > Should be 4?
> >
> > Actually is just a list with 1 item. I think is the terminology:
> >
> > You can have an example here of the mboxes defined for SCU.
> > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx8qxp.dtsi#L123
>
> mboxes = <&lsio_mu1 0 0
> &lsio_mu1 0 1
> &lsio_mu1 0 2
> &lsio_mu1 0 3
> &lsio_mu1 1 0
> &lsio_mu1 1 1
> &lsio_mu1 1 2
> &lsio_mu1 1 3
> &lsio_mu1 3 3>;
>
> Logically, this is 9 entries and each entry is 3 cells ( or phandle
> plus 2 cells). More below...

Ok..

>
> > > > +
> > > > +  mbox-names
>
> Also, missing a ':' here. This won't build. Make sure you build this
> (make dt_binding_check). See
> Documentation/devicetree/writing-schemas.md.
>
Fixed in v2. Awesome!

I thought that Documentation/devicetree/bindings/dsp/fsl,dsp_ipc.yaml
is purely decorative and used as an example. But it's actually the schema for
the newly yaml dts, right?

Used make dt_binding_check everything looks OK now.

> > > > +description:
> > > > +  Mailboxes names
> > > > +allOf:
> > > > +  - $ref: "/schemas/types.yaml#/definitions/string"
> > >
> > > No need for this, '*-names' already has a defined type.
> > So, should I remove the above two lines ?
>
> Actually, all 4. There's no need to describe what 'mbox-names' is.
>
> > > > +  - enum: [ "txdb0", "txdb1", "rxdb0", "rxdb1" ]
> > >
> > > Should be an 'items' list with 4 entries?
> >
> > Let me better read the yaml spec. But "items" list indeed sounds better.
>
> What you should end up with is:
>
> items:
>   - const: txdb0
>   - const: txdb1
>   - const: rxdb0
>   - const: rxdb1
>
> This is saying you have 4 strings in the listed order. The enum you
> had would be a single string of one of the 4 values.
>
I see! Thanks.

> > > > +required:
> > > > +  - compatible
> > > > +  - mboxes
> > > > +  - mbox-names
> > >
> > > This seems incomplete. How does one boot the DSP? Load firmware? No
> > > resources that Linux has to manage. Shared memory?
> >
> > This is only the IPC mailboxes used by DSP to communicate with Linux. The
> > loading of the firmware, the resources needed to be managed by Linux, etc
> > are part of the DSP node.
>
> You should just add the mailboxes to the DSP node then. I suppose you
> didn't because you want 2 drivers? If so, that's the OS's problem and
> not part of DT. A Linux driver can instantiate devices for other
> drivers.

Yes, I want the DSP IPC driver to be separated. And then the SOF Linux
driver that needs
to communicate with DSP just gets a handle to DSP IPC driver and does
the communication.

dts relevant nodes look like this now:

»   dsp_ipc: dsp_ipc {
»   »   compatible = "fsl,imx8qxp-dsp";
»   »   mbox-names = "txdb0", "txdb1",
»   »   »"rxdb0", "rxdb1";
»   »   mboxes = <&lsio_mu13 2 0>,
»   »   »<&lsio_mu13 2 1>,
»   »   »<&lsio_mu13 3 0>,
»   »   »<&lsio_mu13 3 1>;
»   };

»   adma_dsp: dsp@596e8000 {
»   »   compatible = "fsl,imx8qxp-sof-dsp";
»   »   reg = <0x596e8000 0x88000>;
»   »   reserved-region = <&dsp_reserved>;
»   »   ipc = <&dsp_ipc>;
»   };

Your suggeston would be to have something like this:

»   adma_dsp: dsp@596e8000 {
»   »   compatible = "fsl,imx8qxp-sof-dsp";
»   »   reg = <0x596e8000 0x88000>;
»   »   reserved-region = <&dsp_reserved>;
»mbox-names = "txdb0", "txdb1",
»   »   »"rxdb0", "rxdb1";
»   »   mboxes = <&lsio_mu13 2 0>,
»   »   »<&lsio_mu13 2 1>,
»   »   »<&lsio_mu13 3 0>,
»   »   »<&lsio_mu13 3 1>;
»   };

Not sure exactly how to instantiate IPC DSP driver then.

I already have prepared v2 with most of your feedback incorporated,
but not this latest
change with moving mboxes inside dsp driver.

More than that I have followed the model of SCFW IPC and having to
different approach
for similar IPC mechanism is a little bit confusing.

Anyhow, will try to address your further feedback, will send v2 now to
have more feedback from
Oleksij.

thanks,
Daniel.

Re: [PATCH v5 4/7] perf diff: Use hists to manage basic blocks per symbol

[Jiri Olsa]

On Thu, Jun 27, 2019 at 03:34:38PM +0800, Jin, Yao wrote:
> 
> 
> On 6/27/2019 3:27 PM, Jiri Olsa wrote:
> > On Thu, Jun 27, 2019 at 10:09:26PM +0800, Jin Yao wrote:
> > 
> > SNIP
> > 
> > > +
> > > +static int process_block_per_sym(struct hist_entry *he)
> > > +{
> > > + struct annotation *notes;
> > > + struct cyc_hist *ch;
> > > + struct block_hist *bh;
> > > +
> > > + if (!he->ms.map || !he->ms.sym)
> > > + return 0;
> > > +
> > > + notes = symbol__annotation(he->ms.sym);
> > > + if (!notes || !notes->src || !notes->src->cycles_hist)
> > > + return 0;
> > > +
> > > + bh = container_of(he, struct block_hist, he);
> > > + init_block_hist(bh);
> > > +
> > > + ch = notes->src->cycles_hist;
> > > + for (unsigned int i = 0; i < symbol__size(he->ms.sym); i++) {
> > > + if (ch[i].num_aggr) {
> > > + struct block_info *bi;
> > > + struct hist_entry *he_block;
> > > +
> > > + bi = block_info__new();
> > > + if (!bi)
> > > + return -1;
> > > +
> > > + init_block_info(bi, he->ms.sym, &ch[i], i);
> > > + he_block = hists__add_entry_block(&bh->block_hists,
> > > +   NULL, &dummy_al, bi);
> > 
> > nit, it's the only caller of hists__add_entry_block, so we don't need
> > the 'ops' argument in there
> > 
> > other than this, this all looks good to me
> > 
> > Reviewed-by: Jiri Olsa 
> > 
> > thanks,
> > jirka
> > 
> 
> Hi Jiri,
> 
> Thanks so much!
> 
> Do you need me to send v6 which only removes the 'ops' argument from
> hists__add_entry_block? Or this v5 should be OK either?

please send v6, thanks

jirka

[tip:x86/boot] x86/boot: Make gdt 8-byte aligned

[tip-bot for Xiaoyao Li]

Commit-ID:  1c30fe6cbba6997ae4740bb46910036f8a4a9edb
Gitweb: https://git.kernel.org/tip/1c30fe6cbba6997ae4740bb46910036f8a4a9edb
Author: Xiaoyao Li 
AuthorDate: Thu, 27 Jun 2019 12:55:25 +0800
Committer:  Thomas Gleixner 
CommitDate: Thu, 27 Jun 2019 09:40:41 +0200

x86/boot: Make gdt 8-byte aligned

The segment descriptors are loaded with a implicitly locked instruction,
which could trigger the split lock #AC if the variable is not properly
aligned and crosses a cache line.

Align gdt proper so the descriptors are 8 byte aligned.

Signed-off-by: Xiaoyao Li 
Signed-off-by: Thomas Gleixner 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Link: 
https://lkml.kernel.org/r/20190627045525.105266-1-xiaoyao...@linux.intel.com

---
 arch/x86/boot/compressed/head_64.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index fafb75c6c592..6233ae35d0d9 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -659,6 +659,7 @@ no_longmode:
 gdt64:
.word   gdt_end - gdt
.quad   0
+   .balign 8
 gdt:
.word   gdt_end - gdt
.long   gdt

[PATCH] dt-bindings: spi: stm32-qspi: add dma properties

[Ludovic Barre]

From: Ludovic Barre 

This patch adds description of dma properties (optional).

Signed-off-by: Ludovic Barre 
---
 Documentation/devicetree/bindings/spi/spi-stm32-qspi.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-stm32-qspi.txt 
b/Documentation/devicetree/bindings/spi/spi-stm32-qspi.txt
index adeeb63..bfc038b 100644
--- a/Documentation/devicetree/bindings/spi/spi-stm32-qspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-stm32-qspi.txt
@@ -19,8 +19,11 @@ Required properties:
 - reg: chip-Select number (QSPI controller may connect 2 flashes)
 - spi-max-frequency: max frequency of spi bus
 
-Optional property:
+Optional properties:
 - spi-rx-bus-width: see ./spi-bus.txt for the description
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names: DMA request names should include "tx" and "rx" if present.
 
 Example:
 
-- 
2.7.4

[PATCH] spi: stm32-qspi: remove signal sensitive on completion

[Ludovic Barre]

From: Ludovic Barre 

On umount step a sigkill signal is set (without user specific
action), due to sigkill signal the completion will be interrupted and
the data transfer can't be finished if a sync is needed.

Signed-off-by: Ludovic Barre 
---
 drivers/spi/spi-stm32-qspi.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 5dbb6a8..655e4af 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -245,12 +245,8 @@ static int stm32_qspi_tx_dma(struct stm32_qspi *qspi,
writel_relaxed(cr | CR_DMAEN, qspi->io_base + QSPI_CR);
 
t_out = sgt.nents * STM32_COMP_TIMEOUT_MS;
-   if (!wait_for_completion_interruptible_timeout(&qspi->dma_completion,
-  msecs_to_jiffies(t_out)))
-   err = -ETIMEDOUT;
-
-   if (dma_async_is_tx_complete(dma_ch, cookie,
-NULL, NULL) != DMA_COMPLETE)
+   if (!wait_for_completion_timeout(&qspi->dma_completion,
+msecs_to_jiffies(t_out)))
err = -ETIMEDOUT;
 
if (err)
@@ -304,7 +300,7 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi,
cr = readl_relaxed(qspi->io_base + QSPI_CR);
writel_relaxed(cr | CR_TCIE | CR_TEIE, qspi->io_base + QSPI_CR);
 
-   if (!wait_for_completion_interruptible_timeout(&qspi->data_completion,
+   if (!wait_for_completion_timeout(&qspi->data_completion,
msecs_to_jiffies(STM32_COMP_TIMEOUT_MS))) {
err = -ETIMEDOUT;
} else {
-- 
2.7.4

Re: [PATCH v2] flow_dissector: Fix vlan header offset in __skb_flow_dissect

[Jiri Pirko]

Thu, Jun 27, 2019 at 04:28:29AM CEST, da...@davemloft.net wrote:
>From: YueHaibing 
>Date: Mon, 24 Jun 2019 11:49:13 +0800
>
>> @@ -998,6 +998,9 @@ bool __skb_flow_dissect(const struct net *net,
>>  skb && skb_vlan_tag_present(skb)) {
>>  proto = skb->protocol;
>>  } else {
>> +if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX)
>> +nhoff -= sizeof(*vlan);
>> +
>
>But this is wrong when we are being called via eth_get_headlen(), in
>that case nhoff will be sizeof(struct ethhdr).

This patch was replaced by:
[PATCH] bonding: Always enable vlan tx offload
http://patchwork.ozlabs.org/patch/1122886/

Re: [Linux-kernel-mentees] [PATCH v4 RESEND] Media: Radio: Change devm_k*alloc to k*alloc

[Hans Verkuil]

Hi Luke,

On 6/22/19 3:04 AM, Luke Nowakowski-Krijger wrote:
> Change devm_k*alloc to k*alloc to manually allocate memory 
> 
> The manual allocation and freeing of memory is necessary because when
> the USB radio is disconnected, the memory associated with devm_k*alloc
> is freed. Meaning if we still have unresolved references to the radio
> device, then we get use-after-free errors. 
> 
> This patch fixes this by manually allocating memory, and freeing it in 
> the v4l2.release callback that gets called when the last radio device
> exits. 
> 
> Reported-and-tested-by: syzbot+a4387f5b6b799f6be...@syzkaller.appspotmail.com
> Signed-off-by: Luke Nowakowski-Krijger 

I've tested this patch with my raremono (I must be the last person on earth
to 1) have one, and 2) run it under linux!) and it works!

I'm accepting this patch, but I made some small changes, so for future 
reference:

1) The subject should have the driver name as prefix, so:

   media: radio-raremono: change devm_k*alloc to k*alloc

   That way reviewers can see based on the prefix who should review the patch.
   Radio driver are my responsibility, so that would be me.

2) Always run 'checkpatch.pl --strict'. It reported some minor issues:

CHECK: Please don't use multiple blank lines
#17: FILE: drivers/media/radio/radio-raremono.c:280:
+
+

CHECK: Prefer kzalloc(sizeof(*radio)...) over kzalloc(sizeof(struct 
raremono_device)...)
#30: FILE: drivers/media/radio/radio-raremono.c:305:
+   radio = kzalloc(sizeof(struct raremono_device), GFP_KERNEL);


I've fixed these issues, but next time remember to run checkpatch before 
submitting
the patch.

Regards,

Hans

> ---
> Changes in RESEND: 
> + Added reported-and-tested-by tag
> + Further updated description
> - Removed whitespace in patch description
> Changes in v4:
> - Removed whitespace to fix checkpatch.pl errors
> Changes in v3:
> + Update release method in v2 for v4l2.release callback 
> + Assign v4l2.release callback to release method
> - Remove vdev.release callback used in v2
> Changes in v2:
> + Create raremono_device_release method
> + Assign vdev.release to release method
> + Added gotos for better memory cleanup
> - Removed incorrect kfrees in usb_release in v1
> Changes in v1: 
> + Added k*allocs to raremono_device struct, and buffs
> + Added kfrees on error conditions in usb_probe
> + Added kfrees in usb_release
> - Removed devm_k*allocs
> 
>  drivers/media/radio/radio-raremono.c | 31 +---
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/radio/radio-raremono.c 
> b/drivers/media/radio/radio-raremono.c
> index 5e782b3c2fa9..a5b12372eccb 100644
> --- a/drivers/media/radio/radio-raremono.c
> +++ b/drivers/media/radio/radio-raremono.c
> @@ -271,6 +271,15 @@ static int vidioc_g_frequency(struct file *file, void 
> *priv,
>   return 0;
>  }
>  
> +static void raremono_device_release(struct v4l2_device *v4l2_dev)
> +{
> + struct raremono_device *radio = to_raremono_dev(v4l2_dev);
> +
> + kfree(radio->buffer);
> + kfree(radio);
> +}
> +
> +
>  /* File system interface */
>  static const struct v4l2_file_operations usb_raremono_fops = {
>   .owner  = THIS_MODULE,
> @@ -295,12 +304,14 @@ static int usb_raremono_probe(struct usb_interface 
> *intf,
>   struct raremono_device *radio;
>   int retval = 0;
>  
> - radio = devm_kzalloc(&intf->dev, sizeof(struct raremono_device), 
> GFP_KERNEL);
> - if (radio)
> - radio->buffer = devm_kmalloc(&intf->dev, BUFFER_LENGTH, 
> GFP_KERNEL);
> -
> - if (!radio || !radio->buffer)
> + radio = kzalloc(sizeof(struct raremono_device), GFP_KERNEL);
> + if (!radio)
> + return -ENOMEM;
> + radio->buffer = kmalloc(BUFFER_LENGTH, GFP_KERNEL);
> + if (!radio->buffer) {
> + kfree(radio);
>   return -ENOMEM;
> + }
>  
>   radio->usbdev = interface_to_usbdev(intf);
>   radio->intf = intf;
> @@ -324,7 +335,8 @@ static int usb_raremono_probe(struct usb_interface *intf,
>   if (retval != 3 ||
>   (get_unaligned_be16(&radio->buffer[1]) & 0xfff) == 0x0242) {
>   dev_info(&intf->dev, "this is not Thanko's Raremono.\n");
> - return -ENODEV;
> + retval = -ENODEV;
> + goto free_mem;
>   }
>  
>   dev_info(&intf->dev, "Thanko's Raremono connected: (%04X:%04X)\n",
> @@ -333,7 +345,7 @@ static int usb_raremono_probe(struct usb_interface *intf,
>   retval = v4l2_device_register(&intf->dev, &radio->v4l2_dev);
>   if (retval < 0) {
>   dev_err(&intf->dev, "couldn't register v4l2_device\n");
> - return retval;
> + goto free_mem;
>   }
>  
>   mutex_init(&radio->lock);
> @@ -345,6 +357,7 @@ static int usb_raremono_probe(struct usb_interface *intf,
>   radio->vdev.ioctl_ops = &usb_raremono_ioctl_ops;
>   radio->vdev.lock = &radio->lock;
>   radio->vdev.release = video

Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs

[Sebastian Andrzej Siewior]

On 2019-06-26 09:25:58 [-0700], Paul E. McKenney wrote:
> On Wed, Jun 26, 2019 at 03:54:47PM +0200, Sebastian Andrzej Siewior wrote:
> > one of my boxes boots with "threadirqs" and since commit 05f415715ce45
> > ("rcu: Speed up expedited GPs when interrupting RCU reader") I run
> > reliably into the following deadlock:
> > 
> > | 
> > | WARNING: possible recursive locking detected
> > | 5.2.0-rc6 #279 Not tainted
> > | 
> > | (cron)/2109 is trying to acquire lock:
> > | 88464daa (&p->pi_lock){-.-.}, at: try_to_wake_up+0x37/0x700
> > |
> > | but task is already holding lock:
> > | 88464daa (&p->pi_lock){-.-.}, at: try_to_wake_up+0x37/0x700
> > |
> > | other info that might help us debug this:
> > |  Possible unsafe locking scenario:
> > |
> > |CPU0
> > |
> > |   lock(&p->pi_lock);  
> > |   lock(&p->pi_lock);  
> > |
> > |  *** DEADLOCK ***
> > |
> > |  May be due to missing lock nesting notation
> > |
> > | 4 locks held by (cron)/2109:
> > |  #0: c0ae63d9 (&sb->s_type->i_mutex_key){}, at: 
> > iterate_dir+0x3d/0x170
> > |  #1: 88464daa (&p->pi_lock){-.-.}, at: try_to_wake_up+0x37/0x700
> > |  #2: f62f14cf (&rq->lock){-.-.}, at: try_to_wake_up+0x209/0x700
> > |  #3: 0d32568e (rcu_read_lock){}, at: cpuacct_charge+0x37/0x1e0
> > |
> > | stack backtrace:
> > | CPU: 3 PID: 2109 Comm: (cron) Not tainted 5.2.0-rc6 #279
> > | Call Trace:
> > |  
> > |  dump_stack+0x67/0x90 
> > |  __lock_acquire.cold.63+0x142/0x23a
> > |  lock_acquire+0x9b/0x1a0
> > |  ? try_to_wake_up+0x37/0x700
> > |  _raw_spin_lock_irqsave+0x33/0x50
> > |  ? try_to_wake_up+0x37/0x700
> > |  try_to_wake_up+0x37/0x700
> > wake up ksoftirqd
> > 
> > |  rcu_read_unlock_special+0x61/0xa0
> > |  __rcu_read_unlock+0x58/0x60
> > |  cpuacct_charge+0xeb/0x1e0
> > |  update_curr+0x15d/0x350
> > |  enqueue_entity+0x115/0x7e0
> > |  enqueue_task_fair+0x78/0x450
> > |  activate_task+0x41/0x90
> > |  ttwu_do_activate+0x49/0x80
> > |  try_to_wake_up+0x23f/0x700
> > 
> > wake up ksoftirqd
> > 
> > |  irq_exit+0xba/0xc0   
> > |  smp_apic_timer_interrupt+0xb2/0x2a0
> > |  apic_timer_interrupt+0xf/0x20
> > |  
> > 
> > based one the commit it seems the problem was always there but now the
> > mix of raise_softirq_irqoff() and set_tsk_need_resched() seems to hit
> > the window quite reliably. Replacing it with 
> > 
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index 1102765f91fd1..baab36f4d0f45 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -627,14 +627,7 @@ static void rcu_read_unlock_special(struct task_struct 
> > *t)
> > if (preempt_bh_were_disabled || irqs_were_disabled) {
> > WRITE_ONCE(t->rcu_read_unlock_special.b.exp_hint, false);
> > /* Need to defer quiescent state until everything is 
> > enabled. */
> > -   if (irqs_were_disabled) {
> > -   /* Enabling irqs does not reschedule, so... */
> > -   raise_softirq_irqoff(RCU_SOFTIRQ);
> > -   } else {
> > -   /* Enabling BH or preempt does reschedule, so... */
> > -   set_tsk_need_resched(current);
> > -   set_preempt_need_resched();
> > -   }
> > +   raise_softirq_irqoff(RCU_SOFTIRQ);
> > local_irq_restore(flags);
> > return;
> > }
> > 
> > will make it go away.
> 
> Color me confused.  Neither set_tsk_need_resched() nor
> set_preempt_need_resched() acquire locks or do wakeups.

This is correct.

> Yet raise_softirq_irqoff() can do a wakeup if not called
> from hardirq/softirq/NMI context, so I would instead expect
> raise_softirq_irqoff() to be the source of troubles when
> interrupts are threaded.

also correct and it is.

> What am I missing here?

Timing. If raise_softirq_irqoff() is always invoked then we end up in a
state where the thread either isn't invoked or is already running and
the wake up is skipped early (because ->state == TASK_RUNNING or
something).
Please be aware that timing is crucial here to trigger it. I have a
test-case running as an init-script which triggers the bug. Running the
tast-case later manually does not trigger it.

> > Any suggestions?
> 
> Does something like IRQ work help?  Please see -rcu commit 0864f057b050
> ("rcu: Use irq_work to get scheduler's attention in clean context")
> for one way of doing this.  Perhaps in combination with -rcu commit
> a69987a515c8 ("rcu: Simplify rcu_read_unlock_special() deferred wakeups").

I don't think this will help. The problem is that irq_exit() invokes
wake_up_process(ksoftirqd). This function will invoke itself on the same
task as part of rcu_unlock() / rcu_read_unlock_special(). I don't think
this changes here.

>   Thanx, Paul

Se

[PATCH -next] drm/amdgpu: remove set but not used variable 'psp_enabled'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/amdgpu/nv.c: In function 'nv_common_early_init':
drivers/gpu/drm/amd/amdgpu/nv.c:471:7: warning:
 variable 'psp_enabled' set but not used [-Wunused-but-set-variable]

It's not used since inroduction in
commit c6b6a42175f5 ("drm/amdgpu: add navi10 common ip block (v3)")

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/amd/amdgpu/nv.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index af20ffb55c54..8b9fa3db8daa 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -468,7 +468,6 @@ static const struct amdgpu_asic_funcs nv_asic_funcs =
 
 static int nv_common_early_init(void *handle)
 {
-   bool psp_enabled = false;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 
adev->smc_rreg = NULL;
@@ -485,10 +484,6 @@ static int nv_common_early_init(void *handle)
 
adev->asic_funcs = &nv_asic_funcs;
 
-   if (amdgpu_device_ip_get_ip_block(adev, AMD_IP_BLOCK_TYPE_PSP) &&
-   (amdgpu_ip_block_mask & (1 << AMD_IP_BLOCK_TYPE_PSP)))
-   psp_enabled = true;
-
adev->rev_id = nv_get_rev_id(adev);
adev->external_rev_id = 0xff;
switch (adev->asic_type) {

Re: [PATCH] mm/mempolicy: Fix an incorrect rebind node in mpol_rebind_nodemask

[Vlastimil Babka]

On 6/27/19 5:57 AM, Andrew Morton wrote:
> On Mon, 27 May 2019 21:58:17 +0800 zhong jiang  wrote:
> 
>> On 2019/5/27 20:23, Vlastimil Babka wrote:
>>> On 5/25/19 8:28 PM, Andrew Morton wrote:
 (Cc Vlastimil)
>>> Oh dear, 2 years and I forgot all the details about how this works.
>>>
 On Sat, 25 May 2019 15:07:23 +0800 zhong jiang  
 wrote:

> We bind an different node to different vma, Unluckily,
> it will bind different vma to same node by checking the 
> /proc/pid/numa_maps.   
> Commit 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies when 
> updating cpusets")
> has introduced the issue.  when we change memory policy by seting 
> cpuset.mems,
> A process will rebind the specified policy more than one times. 
> if the cpuset_mems_allowed is not equal to user specified nodes. hence 
> the issue will trigger.
> Maybe result in the out of memory which allocating memory from same node.
>>> I have a hard time understanding what the problem is. Could you please
>>> write it as a (pseudo) reproducer? I.e. an example of the process/admin
>>> mempolicy/cpuset actions that have some wrong observed results vs the
>>> correct expected result.
>> Sorry, I havn't an testcase to reproduce the issue. At first, It was 
>> disappeared by
>> my colleague to configure the xml to start an vm.  To his suprise, The bind 
>> mempolicy
>> doesn't work.
> 
> So... what do we do with this patch?
> 
>> Thanks,
>> zhong jiang
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -345,7 +345,7 @@ static void mpol_rebind_nodemask(struct mempolicy 
> *pol, const nodemask_t *nodes)
>   else {
>   nodes_remap(tmp, pol->v.nodes,pol->w.cpuset_mems_allowed,
>   *nodes);
> - pol->w.cpuset_mems_allowed = tmp;
> + pol->w.cpuset_mems_allowed = *nodes;
>>> Looks like a mechanical error on my side when removing the code for
>>> step1+step2 rebinding. Before my commit there was
>>>
>>> pol->w.cpuset_mems_allowed = step ? tmp : *nodes;
>>>
>>> Since 'step' was removed and thus 0, I should have used *nodes indeed.
>>> Thanks for catching that.
> 
> Was that an ack?

The fix should be fine, but the description is vague. I'll try to
improve it.

>   }
>  
>   if (nodes_empty(tmp))
 hm, I'm not surprised the code broke.  What the heck is going on in
 there?  It used to have a perfunctory comment, but Vlastimil deleted
 it.
>>> Yeah the comment was specific for the case that was being removed.
>>>
 Could someone please propose a comment for the above code block
 explaining why we're doing what we do?
>>> I'll have to relearn this first...
>>>
>>>
>>

Re: [PATCH v2 1/3] clk: sprd: Switch from of_iomap() to devm_ioremap_resource()

[Chunyan Zhang]

On Thu, 27 Jun 2019 at 02:16, Stephen Boyd  wrote:
>
> Quoting Chunyan Zhang (2019-05-21 18:15:01)
> > devm_ioremap_resources() automatically requests resources and devm_ wrappers
> > do better error handling and unmapping of the I/O region when needed,
> > that would make drivers more clean and simple.
> >
> > Signed-off-by: Chunyan Zhang 
>
> Applied to clk-next
>
> > diff --git a/drivers/clk/sprd/common.c b/drivers/clk/sprd/common.c
> > index e038b0447206..9ce690999eaa 100644
> > --- a/drivers/clk/sprd/common.c
> > +++ b/drivers/clk/sprd/common.c
> > @@ -50,7 +51,11 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
> > return PTR_ERR(regmap);
> > }
> > } else {
> > -   base = of_iomap(node, 0);
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   base = devm_ioremap_resource(&pdev->dev, res);
> > +   if (IS_ERR(base))
>
> There's also devm_platform_ioremap_resource() if you want to save even
> more lines!

Yes indeed, thanks for the information.
Considering this patch was queued to your tree, I decide to use this
more integrated function later :)

Cheers,
Chunyan

>
> > +   return PTR_ERR(base);
> > +

RE: [PATCH net-next 10/10] net: stmmac: Try to get C45 PHY if everything else fails

[Jose Abreu]

From: Andrew Lunn 

> On Wed, Jun 26, 2019 at 03:47:44PM +0200, Jose Abreu wrote:
> > On PCI based setups that are connected to C45 PHY we won't have DT
> > bindings specifying what's the correct PHY type.
> 
> You can associate a DT node to a PCI device. The driver does not have
> to do anything special, the PCI core code does all the work.
> 
> As an example look at imx6q-zii-rdu2.dts, node &pcie, which has an
> intel i210 on the pcie bus, and we need a handle to it.

That's for ARM but I'm using X86_64 which only has ACPI :/

RE: [PATCH net-next 07/10] net: stmmac: Enable support for > 32 Bits addressing in XGMAC

[Jose Abreu]

From: Andrew Lunn 

> > +
> > +   if (priv->dma_cap.addr64) {
> > +   ret = dma_set_mask_and_coherent(device,
> > +   DMA_BIT_MASK(priv->dma_cap.addr64));
> > +   if (!ret)
> > +   dev_info(priv->device, "Using %d bits DMA width\n",
> > +priv->dma_cap.addr64);
> > +   }
> 
> Hi Jose
> 
> If dma_set_mask_and_coherent() fails, i think you are supposed to fall
> back to 32 bits. So you might want to clear priv->dma_cap.addr64.

Yeah, seems right. Thanks for pointing!

Re: [PATCH v9 11/17] kvm/vmx: Emulate MSR TEST_CTL

[Xiaoyao Li]

On 6/27/2019 3:12 PM, Thomas Gleixner wrote:


A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

A: Yes
Q: Should I trim all irrelevant context?



Sorry about this.
Won't do it anymore.


On Thu, 27 Jun 2019, Xiaoyao Li wrote:


Do you have any comments on this one as the policy of how to expose split lock
detection (emulate TEST_CTL) for guest changed.

This patch makes the implementation as below:

Host|Guest  |Actual value in guest  |split lock happen in guest
--
on  |off|   on  |report #AC to userspace
|on |   on  |inject #AC back to guest
--
off |off|   off |No #AC
|on |   on  |inject #AC back to guest


A: Because it's way better to provide implementation details and useless
references to the SDM.

Q: What's the reason that this table is _NOT_ part of the changelog?



will add it in next version.


In case 2, when split lock detection of both host and guest on, if there is a
split lock is guest, it will inject #AC back to userspace. Then if #AC is from
guest userspace apps, guest kernel sends SIGBUS to userspace apps instead of
whole guest killed by host. If #AC is from guest kernel, guest kernel may
clear it's split lock bit in test_ctl msr and re-execute the instruction, then
it goes into case 1, the #AC will report to host userspace, e.g., QEMU.


The real interesting question is whether the #AC on split lock prevents the
actual bus lock or not. If it does then the above is fine.

If not, then it would be trivial for a malicious guest to set the
SPLIT_LOCK_ENABLE bit and "handle" the exception pro forma, return to the
offending instruction and trigger another one. It lowers the rate, but that
doesn't make it any better.

The SDM is as usual too vague to be useful. Please clarify.



This feature is to ensure no bus lock (due to split lock) in hardware, 
that to say, when bit 29 of TEST_CTL is set, there is no bus lock due to 
split lock can be acquired.



Thanks,

tglx

Re: [PATCH] arm64: Move jump_label_init() before parse_early_param()

[Catalin Marinas]

Hi Kees,

On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> setup_arch(), as done already on x86, in preparation from early param
> usage in the init_on_alloc/free() series:
> https://lkml.kernel.org/r/1561572949.5154.81.ca...@lca.pw

This looks fine to me. Is there any other series to be merged soon that
depends on this patch (the init_on_alloc/fail one)? If not, I can queue
it for 5.3.

-- 
Catalin

[PATCH][next][V3] media: vivid: fix potential integer overflow on left shift

[Colin King]

From: Colin Ian King 

There is a potential integer overflow when int 2 is left shifted
as this is evaluated using 32 bit arithmetic but is being used in
a context that expects an expression of type s64.  Fix this by
generating a mask using GENMASK to avoid a 32 bit overflow.

Addresses-Coverity: ("Unintentional integer overflow")
Fixes: 8a99e9faa131 ("media: vivid: add HDMI (dis)connect RX emulation")
Fixes: 79a792dafac6 ("media: vivid: add HDMI (dis)connect TX emulation")
Signed-off-by: Colin Ian King 
---
V2: use intermediate variables for the shifted expression to make code
a bit more readable.
V3: use GENMASK rather than shifting logic, rename variables adding
_mask suffix.
---

Signed-off-by: Colin Ian King 
---
 drivers/media/platform/vivid/vivid-ctrls.c | 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
index 3e916c8befb7..b04997569228 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -1613,6 +1613,8 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
show_ccs_cap,
}
 
if (dev->num_hdmi_inputs) {
+   s64 hdmi_input_mask = GENMASK(dev->num_hdmi_inputs - 1, 0);
+
dev->ctrl_dv_timings_signal_mode = 
v4l2_ctrl_new_custom(hdl_vid_cap,
&vivid_ctrl_dv_timings_signal_mode, 
NULL);
 
@@ -1633,12 +1635,13 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
show_ccs_cap,
V4L2_CID_DV_RX_RGB_RANGE, V4L2_DV_RGB_RANGE_FULL,
0, V4L2_DV_RGB_RANGE_AUTO);
dev->ctrl_rx_power_present = v4l2_ctrl_new_std(hdl_vid_cap,
-   NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0,
-   (2 << (dev->num_hdmi_inputs - 1)) - 1, 0,
-   (2 << (dev->num_hdmi_inputs - 1)) - 1);
+   NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0, hdmi_input_mask,
+   0, hdmi_input_mask);
 
}
if (dev->num_hdmi_outputs) {
+   s64 hdmi_output_mask = GENMASK(dev->num_hdmi_outputs - 1, 0);
+
/*
 * We aren't doing anything with this at the moment, but
 * HDMI outputs typically have this controls.
@@ -1652,17 +1655,14 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
show_ccs_cap,
dev->ctrl_display_present = v4l2_ctrl_new_custom(hdl_vid_out,
&vivid_ctrl_display_present, NULL);
dev->ctrl_tx_hotplug = v4l2_ctrl_new_std(hdl_vid_out,
-   NULL, V4L2_CID_DV_TX_HOTPLUG, 0,
-   (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
-   (2 << (dev->num_hdmi_outputs - 1)) - 1);
+   NULL, V4L2_CID_DV_TX_HOTPLUG, 0, hdmi_output_mask,
+   0, hdmi_output_mask);
dev->ctrl_tx_rxsense = v4l2_ctrl_new_std(hdl_vid_out,
-   NULL, V4L2_CID_DV_TX_RXSENSE, 0,
-   (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
-   (2 << (dev->num_hdmi_outputs - 1)) - 1);
+   NULL, V4L2_CID_DV_TX_RXSENSE, 0, hdmi_output_mask,
+   0, hdmi_output_mask);
dev->ctrl_tx_edid_present = v4l2_ctrl_new_std(hdl_vid_out,
-   NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0,
-   (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
-   (2 << (dev->num_hdmi_outputs - 1)) - 1);
+   NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0, hdmi_output_mask,
+   0, hdmi_output_mask);
}
if ((dev->has_vid_cap && dev->has_vid_out) ||
(dev->has_vbi_cap && dev->has_vbi_out))
-- 
2.20.1

Re: [PATCH RESEND V2 1/3] clocksource/drivers/sysctr: Add optional clock-frequency property

[Daniel Lezcano]

On 27/06/2019 02:43, Anson Huang wrote:
> Hi, Daniel
> 
>> On 26/06/2019 03:42, Anson Huang wrote:
>>> Hi, Daniel
>>>
 On 23/06/2019 14:38, anson.hu...@nxp.com wrote:
> From: Anson Huang 
>
> Systems which use platform driver model for clock driver require the
> clock frequency to be supplied via device tree when system counter
> driver is enabled.
>
> This is necessary as in the platform driver model the of_clk
> operations do not work correctly because system counter driver is
> initialized in early phase of system boot up, and clock driver using
> platform driver model is NOT ready at that time, it will cause
> system counter driver initialization failed.
>
> Add the optinal clock-frequency to the device tree bindings of the
> NXP system counter, so the frequency can be handed in and the of_clk
> operations can be skipped.

 Isn't it possible to create a fixed-clock and refer to it? So no need
 to create a specific action before calling timer_of_init() ?

>>>
>>> As the clock must be ready before the TIMER_OF_DECLARE, so adding a
>>> CLK_OF_DECLARE_DRIVER in clock driver to ONLY register a fixed-clock?
>>> The system counter's frequency are different on different platforms,
>>> so adding fixed clock in system counter driver is NOT a good idea,
>>> ONLY the DT node or the clock driver can create this fixed clock according 
>>> to
>> platforms, can you advise where to create this fixed clock is better?
>>
>> Can you point me to a DT with the "nxp,sysctr-timer" ?
> 
> The DT node of system counter is new added in 3/3 of this patch series, also 
> can be found
> from below link:
> https://patchwork.kernel.org/patch/11011703/

Sorry, I was unclear. I meant a patch with the timer defined using a
clock as defined currently in the binding (no clock-frequency).


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr

[Michal Hocko]

On Thu 27-06-19 10:50:57, Alastair D'Silva wrote:
> On Wed, 2019-06-26 at 08:57 +0200, Michal Hocko wrote:
> > On Wed 26-06-19 16:27:30, Alastair D'Silva wrote:
> > > On Wed, 2019-06-26 at 08:21 +0200, Michal Hocko wrote:
> > > > On Wed 26-06-19 16:11:21, Alastair D'Silva wrote:
> > > > > From: Alastair D'Silva 
> > > > > 
> > > > > If a memory section comes in where the physical address is
> > > > > greater
> > > > > than
> > > > > that which is managed by the kernel, this function would not
> > > > > trigger the
> > > > > bug and instead return a bogus section number.
> > > > > 
> > > > > This patch tracks whether the section was actually found, and
> > > > > triggers the
> > > > > bug if not.
> > > > 
> > > > Why do we want/need that? In other words the changelog should
> > > > contina
> > > > WHY and WHAT. This one contains only the later one.
> > > >  
> > > 
> > > Thanks, I'll update the comment.
> > > 
> > > During driver development, I tried adding peristent memory at a
> > > memory
> > > address that exceeded the maximum permissable address for the
> > > platform.
> > > 
> > > This caused __section_nr to silently return bogus section numbers,
> > > rather than complaining.
> > 
> > OK, I see, but is an additional code worth it for the non-development
> > case? I mean why should we be testing for something that shouldn't
> > happen normally? Is it too easy to get things wrong or what is the
> > underlying reason to change it now?
> > 
> 
> It took me a while to identify what the problem was - having the BUG_ON
> would have saved me a few hours.
> 
> I'm happy to just have the BUG_ON 'nd drop the new error return (I
> added that in response to Mike Rapoport's comment that the original
> patch would still return a bogus section number).

Well, BUG_ON is about the worst way to handle an incorrect input. You
really do not want to put a production environment down just because
there is a bug in a driver, right? There are still many {VM_}BUG_ONs
in the tree and there is a general trend to get rid of many of them
rather than adding new ones.

Now back to your patch. You are adding an error handling where we simply
do not expect invalid data. This is often the case for the core kernel
functionality because we do expect consumers of the code to do the right
thing. E.g. __section_nr already takes a pointer to struct section which
assumes that this core data structure is already valid. Adding a check
here adds an unnecessary overhead so this doesn't really sound like a
good idea to me.
-- 
Michal Hocko
SUSE Labs

[PATCH] dt-bindings: nvmem: Add YAML schemas for the generic NVMEM bindings

[Srinivas Kandagatla]

From: Maxime Ripard 

The nvmem providers and consumers have a bunch of generic properties that
are needed in a device tree. Add a YAML schemas for those.

Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
Signed-off-by: Srinivas Kandagatla 
---

Hi Greg,

Sorry for the delay in sending this patch, as this was a licence
change It took bit more time than expected to get approval.

Can you please consider this for 5.3 as we already had other patch
in next which reference this yaml.

Thanks,
srini

 .../bindings/nvmem/nvmem-consumer.yaml| 45 +
 .../devicetree/bindings/nvmem/nvmem.txt   | 81 +---
 .../devicetree/bindings/nvmem/nvmem.yaml  | 93 +++
 3 files changed, 139 insertions(+), 80 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
 create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml 
b/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
new file mode 100644
index ..c48b74733b68
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/nvmem-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM (Non Volatile Memory) Consumer Device Tree Bindings
+
+maintainers:
+  - Srinivas Kandagatla 
+
+select: true
+
+properties:
+  nvmem:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+  List of phandle to the nvmem providers.
+
+  nvmem-cells:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+  List of phandle to the nvmem data cells.
+
+  nvmem-names:
+$ref: /schemas/types.yaml#/definitions/string-array
+description:
+  Names for the each nvmem provider.
+
+  nvmem-cell-names:
+$ref: /schemas/types.yaml#/definitions/string-array
+description:
+  Names for each nvmem-cells specified.
+
+dependencies:
+  nvmem-names: [ nvmem ]
+  nvmem-cell-names: [ nvmem-cells ]
+
+examples:
+  - |
+tsens {
+/* ... */
+nvmem-cells = <&tsens_calibration>;
+nvmem-cell-names = "calibration";
+};
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt 
b/Documentation/devicetree/bindings/nvmem/nvmem.txt
index fd06c09b822b..46a7ef485e24 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.txt
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
@@ -1,80 +1 @@
-= NVMEM(Non Volatile Memory) Data Device Tree Bindings =
-
-This binding is intended to represent the location of hardware
-configuration data stored in NVMEMs like eeprom, efuses and so on.
-
-On a significant proportion of boards, the manufacturer has stored
-some data on NVMEM, for the OS to be able to retrieve these information
-and act upon it. Obviously, the OS has to know about where to retrieve
-these data from, and where they are stored on the storage device.
-
-This document is here to document this.
-
-= Data providers =
-Contains bindings specific to provider drivers and data cells as children
-of this node.
-
-Optional properties:
- read-only: Mark the provider as read only.
-
-= Data cells =
-These are the child nodes of the provider which contain data cell
-information like offset and size in nvmem provider.
-
-Required properties:
-reg:   specifies the offset in byte within the storage device.
-
-Optional properties:
-
-bits:  Is pair of bit location and number of bits, which specifies offset
-   in bit and number of bits within the address range specified by reg 
property.
-   Offset takes values from 0-7.
-
-For example:
-
-   /* Provider */
-   qfprom: qfprom@70 {
-   ...
-
-   /* Data cells */
-   tsens_calibration: calib@404 {
-   reg = <0x404 0x10>;
-   };
-
-   tsens_calibration_bckp: calib_bckp@504 {
-   reg = <0x504 0x11>;
-   bits = <6 128>
-   };
-
-   pvs_version: pvs-version@6 {
-   reg = <0x6 0x2>
-   bits = <7 2>
-   };
-
-   speed_bin: speed-bin@c{
-   reg = <0xc 0x1>;
-   bits = <2 3>;
-
-   };
-   ...
-   };
-
-= Data consumers =
-Are device nodes which consume nvmem data cells/providers.
-
-Required-properties:
-nvmem-cells: list of phandle to the nvmem data cells.
-nvmem-cell-names: names for the each nvmem-cells specified. Required if
-   nvmem-cells is used.
-
-Optional-properties:
-nvmem  : list of phandles to nvmem providers.
-nvmem-names: names for the each nvmem provider. required if nvmem is used.
-
-For example:
-
-   tsens {
-   ...
-   nvmem-cells = <&tsens_calibration>;
-   nvmem-cell-names = "cali

RE: [PATCH RESEND V2 1/3] clocksource/drivers/sysctr: Add optional clock-frequency property

[Anson Huang]

Hi, Daniel

> On 27/06/2019 02:43, Anson Huang wrote:
> > Hi, Daniel
> >
> >> On 26/06/2019 03:42, Anson Huang wrote:
> >>> Hi, Daniel
> >>>
>  On 23/06/2019 14:38, anson.hu...@nxp.com wrote:
> > From: Anson Huang 
> >
> > Systems which use platform driver model for clock driver require
> > the clock frequency to be supplied via device tree when system
> > counter driver is enabled.
> >
> > This is necessary as in the platform driver model the of_clk
> > operations do not work correctly because system counter driver is
> > initialized in early phase of system boot up, and clock driver
> > using platform driver model is NOT ready at that time, it will
> > cause system counter driver initialization failed.
> >
> > Add the optinal clock-frequency to the device tree bindings of the
> > NXP system counter, so the frequency can be handed in and the
> > of_clk operations can be skipped.
> 
>  Isn't it possible to create a fixed-clock and refer to it? So no
>  need to create a specific action before calling timer_of_init() ?
> 
> >>>
> >>> As the clock must be ready before the TIMER_OF_DECLARE, so adding a
> >>> CLK_OF_DECLARE_DRIVER in clock driver to ONLY register a fixed-clock?
> >>> The system counter's frequency are different on different platforms,
> >>> so adding fixed clock in system counter driver is NOT a good idea,
> >>> ONLY the DT node or the clock driver can create this fixed clock
> >>> according to
> >> platforms, can you advise where to create this fixed clock is better?
> >>
> >> Can you point me to a DT with the "nxp,sysctr-timer" ?
> >
> > The DT node of system counter is new added in 3/3 of this patch
> > series, also can be found from below link:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fpatch%2F11011703%2F&data=02%7C01%7Canson.
> huang%
> >
> 40nxp.com%7C8b9519ecceb346712be808d6fad675e4%7C686ea1d3bc2b4c6f
> a92cd99
> >
> c5c301635%7C0%7C0%7C636972196338405582&sdata=sOQQzDFxoCqe
> VuHFuYPHh
> > F8Bdj2Zu9WS7Go%2FV9lrWa8%3D&reserved=0
> 
> Sorry, I was unclear. I meant a patch with the timer defined using a clock as
> defined currently in the binding (no clock-frequency).

OK, for i.MX8MM, we use clocks, check below patch series:

https://patchwork.kernel.org/patch/11008519/

code piece as below:

+   system_counter: timer@306a {
+   compatible = "nxp,sysctr-timer";
+   reg = <0x306a 0x3>;
+   interrupts = ,
+;
+   clocks = <&clk IMX8MM_CLK_SYS_CTR>;
+   clock-names = "per";
+   };

Thanks,
Anson.

[PATCH v2 0/2] Add support for DSP IPC protocol driver

[Daniel Baluta]

Hifi4 DSP can be found on some i.MX8 platforms (e.g i.MX8QXP, i.MX8QM).
This patch series introduces the layer that allows Host CPU to
communicate with DSP.

This layer provides a doorbell and clients can used that to notify DSP
that a message is placed somewhere in the shared memory.

The protocol used is request - reply. Usually, Host/DSP write a message
in a shared memory area and notify the other side. The other side will
also write a reply in a designated shared memory area and then ring
the doorbell to let the counterpart that a message is ready.

Changes since v1: (after Rob's and Oleksij comments)
- removed imx_dsp_get_handle now drivers wanting to use DSP IPC
  will get a reference to dsp_ipc node in dts.
- added chip name in compatible string fsl,imx8qxp-dsp
- avoid memory leaks
- make dt_binding_check works fine now!

Daniel Baluta (2):
  firmware: imx: Add DSP IPC protocol interface
  dt-bindings: dsp: fsl: Add DSP IPC binding support

 .../devicetree/bindings/dsp/fsl,dsp_ipc.yaml  |  44 ++
 drivers/firmware/imx/Kconfig  |  11 ++
 drivers/firmware/imx/Makefile |   1 +
 drivers/firmware/imx/imx-dsp.c| 142 ++
 include/linux/firmware/imx/dsp.h  |  67 +
 5 files changed, 265 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dsp/fsl,dsp_ipc.yaml
 create mode 100644 drivers/firmware/imx/imx-dsp.c
 create mode 100644 include/linux/firmware/imx/dsp.h

-- 
2.17.1

[PATCH v2 1/2] firmware: imx: Add DSP IPC protocol interface

[Daniel Baluta]

Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
the Tensilica HiFi4 DSP for advanced pre- and post-audio
processing.

The communication between Host CPU and DSP firmware is
taking place using a shared memory area for message passing
and a dedicated Messaging Unit for notifications.

DSP IPC protocol driver offers a doorbell interface using
imx-mailbox API.

We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
request-reply protocol.

Connection 0 (txdb0, rxdb0):
- Host writes messasge to shared memory [SHMEM]
- Host sends a request [MU]
- DSP handles request [SHMEM]
- DSP sends reply [MU]

Connection 1 (txdb1, rxdb1):
- DSP writes a message to shared memory [SHMEM]
- DSP sends a request [MU]
- Host handles request [SHMEM]
- Host sends reply [MU]

The protocol driver will be used by a Host client to
communicate with the DSP. First client will be the i.MX8
part from Sound Open Firmware infrastructure.

The protocol drivers offers the following interface:

On Tx:
   - imx_dsp_ring_doorbell, will be called to notify the DSP
   that it needs to handle a request.

On Rx:
   - clients need to provide two callbacks:
.handle_reply
.handle_request
  - the callbacks will be used by the protocol driver on
notification arrival from DSP.

Signed-off-by: Daniel Baluta 
---
 drivers/firmware/imx/Kconfig |  11 +++
 drivers/firmware/imx/Makefile|   1 +
 drivers/firmware/imx/imx-dsp.c   | 142 +++
 include/linux/firmware/imx/dsp.h |  67 +++
 4 files changed, 221 insertions(+)
 create mode 100644 drivers/firmware/imx/imx-dsp.c
 create mode 100644 include/linux/firmware/imx/dsp.h

diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
index 42b566f8903f..ddb241708c31 100644
--- a/drivers/firmware/imx/Kconfig
+++ b/drivers/firmware/imx/Kconfig
@@ -1,4 +1,15 @@
 # SPDX-License-Identifier: GPL-2.0-only
+config IMX_DSP
+   bool "IMX DSP Protocol driver"
+   depends on IMX_MBOX
+   help
+ This enables DSP IPC protocol between host CPU (Linux)
+ and the firmware running on DSP.
+ DSP exists on some i.MX8 processors (e.g i.MX8QM, i.MX8QXP).
+
+ It acts like a doorbell. Client might use shared memory to
+ exchange information with DSP side.
+
 config IMX_SCU
bool "IMX SCU Protocol driver"
depends on IMX_MBOX
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 802c4ad8e8f9..08bc9ddfbdfb 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_IMX_DSP)  += imx-dsp.o
 obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o
 obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c
new file mode 100644
index ..c4d34a2fbff3
--- /dev/null
+++ b/drivers/firmware/imx/imx-dsp.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *  Author: Daniel Baluta 
+ *
+ * Implementation of the DSP IPC interface (host side)
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * imx_dsp_ring_doorbell - triggers an interrupt on the other side (DSP)
+ *
+ * @dsp: DSP IPC handle
+ * @chan_idx: index of the channel where to trigger the interrupt
+ *
+ * Returns non-negative value for success, negative value for error
+ */
+int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, unsigned int idx)
+{
+   int ret;
+   struct imx_dsp_chan *dsp_chan;
+
+   if (idx >= DSP_MU_CHAN_NUM)
+   return -EINVAL;
+
+   dsp_chan = &ipc->chans[idx];
+   ret = mbox_send_message(dsp_chan->ch, NULL);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(imx_dsp_ring_doorbell);
+
+/*
+ * imx_dsp_handle_rx - rx callback used by imx mailbox
+ *
+ * @c: mbox client
+ * @msg: message received
+ *
+ * Users of DSP IPC will need to privde handle_reply and handle_request
+ * callbacks.
+ */
+static void imx_dsp_handle_rx(struct mbox_client *c, void *msg)
+{
+   struct imx_dsp_chan *chan = container_of(c, struct imx_dsp_chan, cl);
+
+   if (chan->idx == 0) {
+   chan->ipc->ops->handle_reply(chan->ipc);
+   } else {
+   chan->ipc->ops->handle_request(chan->ipc);
+   imx_dsp_ring_doorbell(chan->ipc, 1);
+   }
+}
+
+static int imx_dsp_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct imx_dsp_ipc *dsp_ipc;
+   struct imx_dsp_chan *dsp_chan;
+   struct mbox_client *cl;
+   char *chan_name;
+   int ret;
+   int i, j;
+
+   dsp_ipc = devm_kzalloc(dev, sizeof(*dsp_ipc), GFP_KERNEL);
+   if (!dsp_ipc)
+   return -ENOMEM;
+
+   for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
+   if (i < 2)
+ 

[PATCH v2 2/2] dt-bindings: dsp: fsl: Add DSP IPC binding support

[Daniel Baluta]

DSP IPC is the layer that allows the Host CPU to communicate
with DSP firmware.
DSP is part of some i.MX8 boards (e.g i.MX8QM, i.MX8QXP)

Signed-off-by: Daniel Baluta 
---
 .../devicetree/bindings/dsp/fsl,dsp_ipc.yaml  | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dsp/fsl,dsp_ipc.yaml

diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp_ipc.yaml 
b/Documentation/devicetree/bindings/dsp/fsl,dsp_ipc.yaml
new file mode 100644
index ..1cbf5d25b258
--- /dev/null
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp_ipc.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/freescale/fsl,dsp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8 IPC DSP interface
+
+maintainers:
+  - Daniel Baluta 
+
+description: |
+  IPC communication layer between Host CPU and DSP on NXP i.MX8 platforms
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-dsp
+
+  mboxes:
+description:
+  List of <&phandle type channel> - 2 channels for TXDB, 2 channels for 
RXDB
+  (see mailbox/fsl,mu.txt)
+maxItems: 4
+
+  mbox-names:
+items:
+  - const: txdb0
+  - const: txdb1
+  - const: rxdb0
+  - const: rxdb1
+
+required:
+  - compatible
+  - mboxes
+  - mbox-names
+
+examples:
+  - |
+dsp_ipc {
+  compatbile = "fsl,imx8qxp-dsp";
+  mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
+  mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, 
<&lsio_mu13 3 1>;
+};
-- 
2.17.1

[PATCH] ftrace: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()

[Petr Mladek]

The commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text
permissions race") causes a possible deadlock between register_kprobe()
and ftrace_run_update_code() when ftrace is using stop_machine().

The existing dependency chain (in reverse order) is:

-> #1 (text_mutex){+.+.}:
   validate_chain.isra.21+0xb32/0xd70
   __lock_acquire+0x4b8/0x928
   lock_acquire+0x102/0x230
   __mutex_lock+0x88/0x908
   mutex_lock_nested+0x32/0x40
   register_kprobe+0x254/0x658
   init_kprobes+0x11a/0x168
   do_one_initcall+0x70/0x318
   kernel_init_freeable+0x456/0x508
   kernel_init+0x22/0x150
   ret_from_fork+0x30/0x34
   kernel_thread_starter+0x0/0xc

-> #0 (cpu_hotplug_lock.rw_sem){}:
   check_prev_add+0x90c/0xde0
   validate_chain.isra.21+0xb32/0xd70
   __lock_acquire+0x4b8/0x928
   lock_acquire+0x102/0x230
   cpus_read_lock+0x62/0xd0
   stop_machine+0x2e/0x60
   arch_ftrace_update_code+0x2e/0x40
   ftrace_run_update_code+0x40/0xa0
   ftrace_startup+0xb2/0x168
   register_ftrace_function+0x64/0x88
   klp_patch_object+0x1a2/0x290
   klp_enable_patch+0x554/0x980
   do_one_initcall+0x70/0x318
   do_init_module+0x6e/0x250
   load_module+0x1782/0x1990
   __s390x_sys_finit_module+0xaa/0xf0
   system_call+0xd8/0x2d0

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(text_mutex);
   lock(cpu_hotplug_lock.rw_sem);
   lock(text_mutex);
  lock(cpu_hotplug_lock.rw_sem);

It is similar problem that has been solved by the commit 2d1e38f56622b9b
("kprobes: Cure hotplug lock ordering issues"). Many locks are involved.
To be on the safe side, text_mutex must become a low level lock taken
after cpu_hotplug_lock.rw_sem.

This can't be achieved easily with the current ftrace design.
For example, arm calls set_all_modules_text_rw() already in
ftrace_arch_code_modify_prepare(), see arch/arm/kernel/ftrace.c.
This functions is called:

  + outside stop_machine() from ftrace_run_update_code()
  + without stop_machine() from ftrace_module_enable()

Fortunately, the problematic fix is needed only on x86_64. It is
the only architecture that calls set_all_modules_text_rw()
in ftrace path and supports livepatching at the same time.

Therefore it is enough to move text_mutex handling from the generic
kernel/trace/ftrace.c into arch/x86/kernel/ftrace.c:

   ftrace_arch_code_modify_prepare()
   ftrace_arch_code_modify_post_process()

This patch basically reverts the ftrace part of the problematic
commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module
text permissions race"). And provides x86_64 specific-fix.

Some refactoring of the ftrace code will be needed when livepatching
is implemented for arm or nds32. These architectures call
set_all_modules_text_rw() and use stop_machine() at the same time.

Fixes: 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text 
permissions race")
Signed-off-by: Petr Mladek 
---
 arch/x86/kernel/ftrace.c |  3 +++
 kernel/trace/ftrace.c| 10 +-
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 0927bb158ffc..33786044d5ac 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -35,6 +36,7 @@
 
 int ftrace_arch_code_modify_prepare(void)
 {
+   mutex_lock(&text_mutex);
set_kernel_text_rw();
set_all_modules_text_rw();
return 0;
@@ -44,6 +46,7 @@ int ftrace_arch_code_modify_post_process(void)
 {
set_all_modules_text_ro();
set_kernel_text_ro();
+   mutex_unlock(&text_mutex);
return 0;
 }
 
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 38277af44f5c..d3034a4a3fcc 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -2611,12 +2610,10 @@ static void ftrace_run_update_code(int command)
 {
int ret;
 
-   mutex_lock(&text_mutex);
-
ret = ftrace_arch_code_modify_prepare();
FTRACE_WARN_ON(ret);
if (ret)
-   goto out_unlock;
+   return ret;
 
/*
 * By default we use stop_machine() to modify the code.
@@ -2628,9 +2625,6 @@ static void ftrace_run_update_code(int command)
 
ret = ftrace_arch_code_modify_post_process();
FTRACE_WARN_ON(ret);
-
-out_unlock:
-   mutex_unlock(&text_mutex);
 }
 
 static void ftrace_run_modify_code(struct ftrace_ops *ops, int command,
@@ -5784,7 +5778,6 @@ void ftrace_module_enable(struct module *mod)
struct ftrace_page *pg;
 
mutex_lock(&ftrace_lock);
-   mutex_lock(&text_mutex);
 
if (ftrace_disabled)
goto out_unlock;
@@ -5846,7 +5839,6 @@ void ftrace_module_enable(struct m

memory leak in ip_mc_add_src (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=122594ada0
kernel config:  https://syzkaller.appspot.com/x/.config?x=1db8bd6825f9661c
dashboard link: https://syzkaller.appspot.com/bug?extid=6ca1abd0db68b5173a4f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15dc46eea0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17ee5aada0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6ca1abd0db68b5173...@syzkaller.appspotmail.com

executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0x88811450f140 (size 64):
  comm "softirq", pid 0, jiffies 4294942448 (age 32.070s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc_recursive  
include/linux/kmemleak.h:43 [inline]

[] slab_post_alloc_hook mm/slab.h:439 [inline]
[] slab_alloc mm/slab.c:3326 [inline]
[] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<9acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<9acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<9acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
[<9acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
[<4ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
[<52d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930  
net/ipv4/ip_sockglue.c:959

[<4ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
[<66cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
[<9383a786>] sock_common_setsockopt+0x38/0x50  
net/core/sock.c:3126

[] __sys_setsockopt+0x98/0x120 net/socket.c:2072
[<1b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
[<1b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
[<1b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
[<420d395e>] do_syscall_64+0x76/0x1a0  
arch/x86/entry/common.c:301

[<7fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0x88810ec5ab40 (size 64):
  comm "softirq", pid 0, jiffies 4294943651 (age 20.040s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc_recursive  
include/linux/kmemleak.h:43 [inline]

[] slab_post_alloc_hook mm/slab.h:439 [inline]
[] slab_alloc mm/slab.c:3326 [inline]
[] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<9acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<9acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<9acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
[<9acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
[<4ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
[<52d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930  
net/ipv4/ip_sockglue.c:959

[<4ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
[<66cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
[<9383a786>] sock_common_setsockopt+0x38/0x50  
net/core/sock.c:3126

[] __sys_setsockopt+0x98/0x120 net/socket.c:2072
[<1b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
[<1b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
[<1b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
[<420d395e>] do_syscall_64+0x76/0x1a0  
arch/x86/entry/common.c:301

[<7fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0x888112a6e080 (size 64):
  comm "softirq", pid 0, jiffies 4294944252 (age 14.030s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc_recursive  
include/linux/kmemleak.h:43 [inline]

[] slab_post_alloc_hook mm/slab.h:439 [inline]
[] slab_alloc mm/slab.c:3326 [inline]
[] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<9acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<9acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<9acc4151>] ip_mc_add1_src net/ipv4/igm

Re: [PATCH 0/2] scsi: add support for request batching

[Paolo Bonzini]

On 27/06/19 05:37, Martin K. Petersen wrote:
>> Ping?  Are there any more objections?
> It's a core change so we'll need some more reviews. I suggest you
> resubmit.

Resubmit exactly the same patches?

Paolo

Re: [PATCH v10 0/6] support a new type of PMIC,including two chips(rk817 and rk809)

[Heiko Stuebner]

Hi Lee,

Am Mittwoch, 26. Juni 2019, 13:52:51 CEST schrieb Lee Jones:
> On Fri, 21 Jun 2019, Tony Xie wrote:
> 
> > Most of functions and registers of the rk817 and rk808 are the same,
> > so they can share allmost all codes.
> > 
> > Their specifications are as follows:
> >   1) The RK809 and RK809 consist of 5 DCDCs, 9 LDOs and have the same
> > registers
> >  for these components except dcdc5.
> >   2) The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
> >   3) The RK817 has one switch but The Rk809 has two.
> 
> Just tried to apply this set to a v5.2-rc1 base, but it doesn't seem
> to do so cleanly.  Would you be able to rebase and resend please?

I took the liberty of rebasing patch 3 accordingly and sent it as reply
to the original patch3 as (v10.1). The other patches did apply cleanly
after that.


Heiko

Re: [PATCH v7 2/6] i2c: acpi: Use available IRQ helper functions

[Charles Keepax]

On Wed, Jun 26, 2019 at 10:09:06PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 26, 2019 at 04:02:58PM +0100, Charles Keepax wrote:
> > Use the available IRQ helper functions, most of the functions have
> > additional helpful side affects like configuring the trigger type of the
> > IRQ.
> 
> > -   acpi_dev_free_resource_list(&resource_list);
> 
> I have thought that we can drop completely the resource_list, though ACPI
> doesn't allow this. So, I would rather withdraw this change to be on the safe
> (symmetrical) side.
> 

Yeah would be my preference as well, will do another spin.

Thanks,
Charles

Re: [PATCH] media:vivid: add sanity check to avoid divide error and set value to 1 if 0.

[Vandana BN]

On 27/06/19 12:58 PM, Hans Verkuil wrote:
> On 6/26/19 8:01 AM, Vandana BN wrote:
>> Syzbot reported divide error in vivid_thread_vid_cap, which has been
>> seen only once and doesnot have a reproducer.
>> This patch sanity checks for the denominator value with WARN_ON if it is 0 
>> and replaces it with 1.
>>
>> Reported-by: syz...@syzkaller.appspotmail.com
>>
>> divide error:  [#1] PREEMPT SMP KASAN
>> kobject: 'tx-0' (17161f7f): kobject_uevent_env
>> CPU: 0 PID: 23689 Comm: vivid-003-vid-c Not tainted 5.0.0-rc4+ #58
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:vivid_cap_update_frame_period
>> drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline]
>> RIP: 0010:vivid_thread_vid_cap+0x221/0x284
>> drivers/media/platform/vivid/vivid-kthread-cap.c:789
>> Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38
>> ca
>> 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49
>> 89
>> c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45
>> RSP: 0018:88808b4afd68 EFLAGS: 00010246
>> kobject: 'tx-0' (17161f7f): fill_kobj_path: path
>> = '/devices/virtual/net/gre0/queues/tx-0'
>> RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: 
>> RDX:  RSI: 0004 RDI: 0004
>> RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008
>> R10: 89997010 R11: 0001 R12: fffc
>> R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140
>> FS:  () GS:8880ae80()
>> knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0
>> Call Trace:
>> kobject: 'gretap0' (d7549098): kobject_add_internal: parent:
>> 'net',
>> set: 'devices'
>> kobject: 'loop2' (94ed4ee4): kobject_uevent_env
>> kobject: 'loop2' (94ed4ee4): fill_kobj_path: path
>> = '/devices/virtual/block/loop2'
>>   kthread+0x357/0x430 kernel/kthread.c:246
>> kobject: 'gretap0' (d7549098): kobject_uevent_env
>>   ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
>> Modules linked in:
>> kobject: 'gretap0' (d7549098): fill_kobj_path: path
>> = '/devices/virtual/net/gretap0'
>> ---[ end trace bc5c8b25b64d768f ]---
>> kobject: 'loop1' (32036b86): kobject_uevent_env
>> RIP: 0010:vivid_cap_update_frame_period
>> drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline]
>> RIP: 0010:vivid_thread_vid_cap+0x221/0x2840
>> drivers/media/platform/vivid/vivid-kthread-cap.c:789
>> kobject: 'loop1' (32036b86): fill_kobj_path: path
>> = '/devices/virtual/block/loop1'
>> Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38
>> ca
>> 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49
>> 89
>> c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45
>> kobject: 'loop0' (dd9927c3): kobject_uevent_env
>> RSP: 0018:88808b4afd68 EFLAGS: 00010246
>> RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: 
>> kobject: 'queues' (7ed20666): kobject_add_internal:
>> parent: 'gretap0', set: ''
>> RDX:  RSI: 0004 RDI: 0004
>> RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008
>> kobject: 'loop0' (dd9927c3): fill_kobj_path: path
>> = '/devices/virtual/block/loop0'
>> R10: 89997010 R11: 0001 R12: fffc
>> kobject: 'queues' (7ed20666): kobject_uevent_env
>> R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140
>> FS:  () GS:8880ae80()
>> knlGS:
>> kobject: 'loop5' (a41f9e79): kobject_uevent_env
>> CS:  0010 DS:  ES:  CR0: 80050033
>> kobject: 'queues' (7ed20666): kobject_uevent_env: filter
>> function
>> caused the event to drop!
>> CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0
>> kobject: 'loop5' (a41f9e79): fill_kobj_path: path
>> = '/devices/virtual/block/loop5'
>>
>> Signed-off-by: Vandana BN 
>> ---
>>  drivers/media/platform/vivid/vivid-kthread-cap.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c 
>> b/drivers/media/platform/vivid/vivid-kthread-cap.c
>> index f8006a30c12f..025a8c68bd1c 100644
>> --- a/drivers/media/platform/vivid/vivid-kthread-cap.c
>> +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
>> @@ -658,6 +658,8 @@ static void vivid_cap_update_frame_period(struct 
>> vivid_dev *dev)
>>  u64 f_period;
>>  
>>  f_period = (u64)dev->timeperframe_vid_cap.numerator * 10;
>> +if(WARN_ON(dev->timeperframe_vid_cap.denominator == 0))
>> +dev->timeperframe_vid_cap.denominator = 1;
>>  do_div(f_period, dev->timeperframe_vid_cap.denominator);
>>  if (dev->field_cap == V4L2_FIELD_ALTERNATE)
>>  f_period >>= 1;
>>

Re: [PATCH] mdev: Send uevents around parent device registration

[Cornelia Huck]

On Wed, 26 Jun 2019 08:27:58 -0600
Alex Williamson  wrote:

> This allows udev to trigger rules when a parent device is registered
> or unregistered from mdev.
> 
> Signed-off-by: Alex Williamson 
> ---
>  drivers/vfio/mdev/mdev_core.c |   10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index ae23151442cb..ecec2a3b13cb 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -146,6 +146,8 @@ int mdev_register_device(struct device *dev, const struct 
> mdev_parent_ops *ops)
>  {
>   int ret;
>   struct mdev_parent *parent;
> + char *env_string = "MDEV_STATE=registered";

This string is probably reasonable enough.

> + char *envp[] = { env_string, NULL };
>  
>   /* check for mandatory ops */
>   if (!ops || !ops->create || !ops->remove || !ops->supported_type_groups)
> @@ -196,7 +198,8 @@ int mdev_register_device(struct device *dev, const struct 
> mdev_parent_ops *ops)
>   list_add(&parent->next, &parent_list);
>   mutex_unlock(&parent_list_lock);
>  
> - dev_info(dev, "MDEV: Registered\n");
> + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);

I also agree with the positioning here.

> +
>   return 0;
>  
>  add_dev_err:
> @@ -220,6 +223,8 @@ EXPORT_SYMBOL(mdev_register_device);
>  void mdev_unregister_device(struct device *dev)
>  {
>   struct mdev_parent *parent;
> + char *env_string = "MDEV_STATE=unregistered";

Ok.

> + char *envp[] = { env_string, NULL };
>  
>   mutex_lock(&parent_list_lock);
>   parent = __find_parent_device(dev);
> @@ -228,7 +233,6 @@ void mdev_unregister_device(struct device *dev)
>   mutex_unlock(&parent_list_lock);
>   return;
>   }
> - dev_info(dev, "MDEV: Unregistering\n");
>  
>   list_del(&parent->next);
>   mutex_unlock(&parent_list_lock);
> @@ -243,6 +247,8 @@ void mdev_unregister_device(struct device *dev)
>   up_write(&parent->unreg_sem);
>  
>   mdev_put_parent(parent);
> +
> + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);

I'm wondering whether we should indicate this uevent earlier: Once we
have detached from the parent list, we're basically done for all
practical purposes. So maybe move this right before we grab the
unreg_sem?

>  }
>  EXPORT_SYMBOL(mdev_unregister_device);
>  
> 

linux-next: build warning after merge of the gpio tree

[Stephen Rothwell]

Hi all,

After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe':
drivers/gpio/gpio-amd-fch.c:171:49: warning: passing argument 2 of 
'devm_ioremap_resource' discards 'const' qualifier from pointer target type 
[-Wdiscarded-qualifiers]
  priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores);
 ^~~
In file included from include/linux/platform_device.h:13,
 from drivers/gpio/gpio-amd-fch.c:15:
include/linux/device.h:708:15: note: expected 'struct resource *' but argument 
is of type 'const struct resource *'
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
   ^

Introduced by commit

  9bb2e0452508 ("gpio: amd: Make resource struct const")

-- 
Cheers,
Stephen Rothwell


pgpiLLH7f09vH.pgp
Description: OpenPGP digital signature

Re: [PATCH] mdev: Send uevents around parent device registration

[Cornelia Huck]

On Thu, 27 Jun 2019 00:33:59 +0530
Kirti Wankhede  wrote:

> On 6/26/2019 11:35 PM, Alex Williamson wrote:
> > On Wed, 26 Jun 2019 23:23:00 +0530
> > Kirti Wankhede  wrote:
> >   
> >> On 6/26/2019 7:57 PM, Alex Williamson wrote:  
> >>> This allows udev to trigger rules when a parent device is registered
> >>> or unregistered from mdev.
> >>>
> >>> Signed-off-by: Alex Williamson 
> >>> ---
> >>>  drivers/vfio/mdev/mdev_core.c |   10 --
> >>>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> >>> index ae23151442cb..ecec2a3b13cb 100644
> >>> --- a/drivers/vfio/mdev/mdev_core.c
> >>> +++ b/drivers/vfio/mdev/mdev_core.c
> >>> @@ -146,6 +146,8 @@ int mdev_register_device(struct device *dev, const 
> >>> struct mdev_parent_ops *ops)
> >>>  {
> >>>   int ret;
> >>>   struct mdev_parent *parent;
> >>> + char *env_string = "MDEV_STATE=registered";
> >>> + char *envp[] = { env_string, NULL };
> >>>  
> >>>   /* check for mandatory ops */
> >>>   if (!ops || !ops->create || !ops->remove || !ops->supported_type_groups)
> >>> @@ -196,7 +198,8 @@ int mdev_register_device(struct device *dev, const 
> >>> struct mdev_parent_ops *ops)
> >>>   list_add(&parent->next, &parent_list);
> >>>   mutex_unlock(&parent_list_lock);
> >>>  
> >>> - dev_info(dev, "MDEV: Registered\n");
> >>> + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);
> >>> +
> >>
> >> Its good to have udev event, but don't remove debug print from dmesg.
> >> Same for unregister.  
> > 
> > Who consumes these?  They seem noisy.  Thanks,
> >   
> 
> I don't think its noisy, its more of logging purpose. This is seen in
> kernel log only when physical device is registered to mdev.

Yes; but why do you want to log success? If you need to log it
somewhere, wouldn't a trace event be a much better choice?

[PATCH v2] media:vivid:add sanity check to avoid divide error and set value to 1 if 0.

[Vandana BN]

Syzbot reported divide error in vivid_thread_vid_cap, which has been
seen only once and doesnot have a reproducer.
This patch sanity checks for the
denominator value with WARN_ON if it is 0 and replaces it with 1.

Reported-by: syz...@syzkaller.appspotmail.com

divide error:  [#1] PREEMPT SMP KASAN
kobject: 'tx-0' (17161f7f): kobject_uevent_env
CPU: 0 PID: 23689 Comm: vivid-003-vid-c Not tainted 5.0.0-rc4+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:vivid_cap_update_frame_period
drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline]
RIP: 0010:vivid_thread_vid_cap+0x221/0x284
drivers/media/platform/vivid/vivid-kthread-cap.c:789
Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38
ca
7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49
89
c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45
RSP: 0018:88808b4afd68 EFLAGS: 00010246
kobject: 'tx-0' (17161f7f): fill_kobj_path: path
= '/devices/virtual/net/gre0/queues/tx-0'
RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: 
RDX:  RSI: 0004 RDI: 0004
RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008
R10: 89997010 R11: 0001 R12: fffc
R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140
FS:  () GS:8880ae80()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0
Call Trace:
kobject: 'gretap0' (d7549098): kobject_add_internal: parent:
'net',
set: 'devices'
kobject: 'loop2' (94ed4ee4): kobject_uevent_env
kobject: 'loop2' (94ed4ee4): fill_kobj_path: path
= '/devices/virtual/block/loop2'
  kthread+0x357/0x430 kernel/kthread.c:246
kobject: 'gretap0' (d7549098): kobject_uevent_env
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Modules linked in:
kobject: 'gretap0' (d7549098): fill_kobj_path: path
= '/devices/virtual/net/gretap0'
---[ end trace bc5c8b25b64d768f ]---
kobject: 'loop1' (32036b86): kobject_uevent_env
RIP: 0010:vivid_cap_update_frame_period
drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline]
RIP: 0010:vivid_thread_vid_cap+0x221/0x2840
drivers/media/platform/vivid/vivid-kthread-cap.c:789
kobject: 'loop1' (32036b86): fill_kobj_path: path
= '/devices/virtual/block/loop1'
Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38
ca
7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49
89
c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45
kobject: 'loop0' (dd9927c3): kobject_uevent_env
RSP: 0018:88808b4afd68 EFLAGS: 00010246
RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: 
kobject: 'queues' (7ed20666): kobject_add_internal:
parent: 'gretap0', set: ''
RDX:  RSI: 0004 RDI: 0004
RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008
kobject: 'loop0' (dd9927c3): fill_kobj_path: path
= '/devices/virtual/block/loop0'
R10: 89997010 R11: 0001 R12: fffc
kobject: 'queues' (7ed20666): kobject_uevent_env
R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140
FS:  () GS:8880ae80()
knlGS:
kobject: 'loop5' (a41f9e79): kobject_uevent_env
CS:  0010 DS:  ES:  CR0: 80050033
kobject: 'queues' (7ed20666): kobject_uevent_env: filter
function
caused the event to drop!
CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0
kobject: 'loop5' (a41f9e79): fill_kobj_path: path
= '/devices/virtual/block/loop5'

Signed-off-by: Vandana BN 
---
V2- fixed checkpatch errors.

 drivers/media/platform/vivid/vivid-kthread-cap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c 
b/drivers/media/platform/vivid/vivid-kthread-cap.c
index f8006a30c12f..cf6dfecf879f 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -658,6 +658,8 @@ static void vivid_cap_update_frame_period(struct vivid_dev 
*dev)
u64 f_period;

f_period = (u64)dev->timeperframe_vid_cap.numerator * 10;
+   if (WARN_ON(dev->timeperframe_vid_cap.denominator == 0))
+   dev->timeperframe_vid_cap.denominator = 1;
do_div(f_period, dev->timeperframe_vid_cap.denominator);
if (dev->field_cap == V4L2_FIELD_ALTERNATE)
f_period >>= 1;
--
2.17.1

Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation

[Petr Mladek]

On Wed 2019-06-26 23:43:56, John Ogness wrote:
> Here is where I have massive problems communicating. I don't understand
> why you say the barrier is _between_ newest and next. I would say the
> barrier is _on_ newest to _synchronize_ with next (or something). I am
> struggling with terminology. (To be honest, I'd much rather just post
> litmus tests.)
> 
> For example, if we have:
> 
> WRITE_ONCE(&a, 1);
> WRITE_ONCE(&b, 1);
> WRITE_ONCE(&c, 1);
> smp_store_release(&d, 1);
> 
> and:
> 
> local_d = smp_load_acquire(&d);
> local_a = READ_ONCE(&a);
> local_b = READ_ONCE(&b);
> local_c = READ_ONCE(&c);
> 
> How do you describe that? Do you say the memory barrier is between a and
> d? Or between a, b, c, d? (a, b, c aren't ordered, but they are one-way
> synchronized with d).
> 
> I would say there is a barrier on d to synchronize a, b, c.

Barriers are always paired. We need to know what variables are
synchonized against each other, what is the reason and where
is the counter part.

I think that it might be done many ways. I am familiar with
bariers in kernel/livepatch/ code. They use rather long description.
But I find it pretty useful especially when the problem is
complicated and more bariers are involved in a single
transition.

Best Regards,
Petr

Béren felüli juttatások

[Kapolcs Mátyás]

Üdvözlöm,

2019 januárjától minden nem bér jellegű juttatás a fizetéssel megegyezően lesz 
megadóztatva. A változások ellenére a vállalatok több mint 55%-a meg kívánja 
tartani a dolgozói juttatások támogatási mértékét.

A korlátlanul felhasználható juttatás kártya számos előnnyel jár a 
munkavállalók részére, a munkáltatók pedig ennek segítségével produktív és 
motivált csapatot tudnak fenntartani. 

A SZÉP kártyától eltérően a mi kártyánkat a felhasználó az alábbi célokra 
használhatja fel: élelmiszer vásárlás, egészségügyi ellátás, elektronika, 
szállás, oktatás és egyéb szolgáltatások, sőt, még készpénzfelvételre is 
alkalmas. 

Ez az egyetlen olyan a kártya a piacon, amelyet minden POS terminál elfogad, 
ezzel biztosítva a kártya széleskörű felhasználását.

Örömmel bemutatom milyen további előnyökkel jár kártyáink dolgozói juttatásként 
történő alkalmazása, és szívesen mesélek a kártyák felhasználási lehetőségeiről 
- ez iránti igényüket kérem, jelezzék.
 
Bemutathatom megoldásainkat részletesebben?


Kapolcs Mátyás
Hungary Team Leader  

[PATCH v2 2/2] drivers/staging/rtl8192u: style nonstyled comments

[Christian Müller]

The coding-styles.rst states, that multiline comments should
allways contain a leading "*" in each line.
For multiline comments in general they

/*
 * should look
 * like this.
 */

For multiline comments in either net/ or drivers/net/ however,
they should

/* omit
 * the first
 * empty line.
 */

Since this file is part of a networking driver, the goal for it would
be to reside in drivers/net/ one day.

This patch changes comments, that were in neither form of the two listed
above, to have the style that is specified for drivers/net/.

Signed-off-by: Christian Müller 
Signed-off-by: Felix Trommer 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 86215fee8f0b..cb6c653e624d 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -332,9 +332,10 @@ static void dm_check_rate_adaptive(struct net_device *dev)
((bshort_gi_enabled) ? BIT(31) : 0);

/* 2007/10/08 MH We support RA smooth scheme now. When it is 
the first
-  time to link with AP. We will not change upper/lower 
threshold. If
-  STA stay in high or low level, we must change two different 
threshold
-  to prevent jumping frequently. */
+* time to link with AP. We will not change upper/lower 
threshold. If
+* STA stay in high or low level, we must change two different 
threshold
+* to prevent jumping frequently.
+*/
if (pra->ratr_state == DM_RATR_STA_HIGH) {
HighRSSIThreshForRA = 
pra->high2low_rssi_thresh_for_ra;
LowRSSIThreshForRA  = (priv->CurrentChannelBW != 
HT_CHANNEL_WIDTH_20) ?
@@ -1738,10 +1739,12 @@ static void dm_ctrl_initgain_byrssi_by_fwfalse_alarm(
pHalData->UndecoratedSmoothedPWDB, DM_DigTable.RssiLowThresh,
DM_DigTable.RssiHighThresh, DM_DigTable.Dig_State);*/
/* 1. When RSSI decrease, We have to judge if it is smaller than a 
threshold
- and then execute the step below. */
+* and then execute the step below.
+*/
if (priv->undecorated_smoothed_pwdb <= dm_digtable.rssi_low_thresh) {
/* 2008/02/05 MH When we execute silent reset, the DIG PHY 
parameters
-  will be reset to init value. We must prevent the condition. 
*/
+* will be reset to init value. We must prevent the condition.
+*/
if (dm_digtable.dig_state == DM_STA_DIG_OFF &&
(priv->reset_count == reset_cnt)) {
return;
@@ -1786,7 +1789,8 @@ static void dm_ctrl_initgain_byrssi_by_fwfalse_alarm(
}

/* 2. When RSSI increase, We have to judge if it is larger than a 
threshold
- and then execute the step below.  */
+* and then execute the step below.
+*/
if (priv->undecorated_smoothed_pwdb >= dm_digtable.rssi_high_thresh) {
u8 reset_flag = 0;

@@ -2252,11 +2256,10 @@ static void dm_ctstoself(struct net_device *dev)
pHTInfo->IOTAction &= ~HT_IOT_ACT_FORCED_CTS2SELF;
return;
}
-   /*
-   1. Uplink
-   2. Linksys350/Linksys300N
-   3. <50 disable, >55 enable
-   */
+   /* 1. Uplink
+* 2. Linksys350/Linksys300N
+* 3. <50 disable, >55 enable
+*/

if (pHTInfo->IOTPeer == HT_IOT_PEER_BROADCOM) {
curTxOkCnt = priv->stats.txbytesunicast - lastTxOkCnt;
@@ -2333,7 +2336,8 @@ void dm_rf_pathcheck_workitemcallback(struct work_struct 
*work)
u8 rfpath = 0, i;

/* 2008/01/30 MH After discussing with SD3 Jerry, 0xc04/0xd04 register 
will
-  always be the same. We only read 0xc04 now. */
+* always be the same. We only read 0xc04 now.
+*/
read_nic_byte(dev, 0xc04, &rfpath);

/* Check Bit 0-3, it means if RF A-D is enabled. */
--
2.17.1

[PATCH v2 1/2] drivers/staging/rtl8192u: drop first comment line

[Christian Müller]

As stated in coding-styles.rst multiline comments should be structured in a way,
that the actual comment starts on the second line of the commented portion. E.g:

/*
 * Multiline comments
 * should look like
 * this.
 */

However, there is an exception to files in drivers/net/ and net/, where
multiline comments are prefered to look like this:

/* Mutliline comments for
 * drivers/net/ should look
 * like this.
 */

The comments in this file initially looked like the first example.
But since this file is part of a networking driver and thus should
be moved to drivers/net/ one day, this patch adjusts the comments
such that they are fitting to the style imposed for drivers/net/.

Signed-off-by: Christian Müller 
Signed-off-by: Felix Trommer 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 69 ++--
 1 file changed, 23 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 2ba01041406b..86215fee8f0b 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -99,8 +99,7 @@ staticvoiddm_dynamic_txpower(struct net_device 
*dev);
 static void dm_send_rssi_tofw(struct net_device *dev);
 static voiddm_ctstoself(struct net_device *dev);
 /*---Define function 
prototype*/
-/*
- * 

+/* 

  * HW Dynamic mechanism interface.
  * 

  *
@@ -178,8 +177,7 @@ void dm_CheckRxAggregation(struct net_device *dev)

ulValue = (pHTInfo->UsbRxFwAggrEn<<24) | 
(pHTInfo->UsbRxFwAggrPageNum<<16) |
(pHTInfo->UsbRxFwAggrPacketNum<<8) | 
(pHTInfo->UsbRxFwAggrTimeout);
-   /*
-* If usb rx firmware aggregation is enabled,
+   /* If usb rx firmware aggregation is enabled,
 * when anyone of three threshold conditions above is 
reached,
 * firmware will send aggregated packet to driver.
 */
@@ -219,8 +217,7 @@ void hal_dm_watchdog(struct net_device *dev)
 #endif
 }  /* HalDmWatchDog */

-/*
- * Decide Rate Adaptive Set according to distance (signal strength)
+/* Decide Rate Adaptive Set according to distance (signal strength)
  * 01/11/2008  MHC Modify input arguments and RATR table 
level.
  * 01/16/2008  MHC RF_Type is assigned in 
ReadAdapterInfo(). We must call
  * the function after making sure 
RF_Type.
@@ -246,8 +243,7 @@ void init_rate_adaptive(struct net_device *dev)
pra->ping_rssi_thresh_for_ra = 15;

if (priv->rf_type == RF_2T4R) {
-   /*
-* 07/10/08 MH Modify for RA smooth scheme.
+   /* 07/10/08 MH Modify for RA smooth scheme.
 * 2008/01/11 MH Modify 2T RATR table for different RSSI. 
080515 porting by amy from windows code.
 */
pra->upper_rssi_threshold_ratr  =   0x8f0f;
@@ -387,8 +383,7 @@ static void dm_check_rate_adaptive(struct net_device *dev)
}
}

-   /*
-* 2008.04.01
+   /* 2008.04.01
 * For RTL819X, if pairwisekey = wep/tkip, we support only 
MCS0~7.
 */
if (priv->ieee80211->GetHalfNmodeSupportByAPsHandler(dev))
@@ -683,8 +678,7 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
return;
}

-   /*
-* ==
+   /* ==
 * this is only for test, should be masked
 * ==
 */
@@ -850,8 +844,7 @@ static void dm_InitializeTXPowerTracking_TSSI(struct 
net_device *dev)
priv->txbbgain_table[36].txbb_iq_amplifygain =   -24;
priv->txbbgain_table[36].txbbgain_value = 0x1040;

-   /*
-* ccktxbb_valuearray[0] is 0xA22 [1] is 0xA24 ...[7] is 0xA29
+   /* ccktxbb_valuearray[0] is 0xA22 [1] is 0xA24 ...[7] is 0xA29
 * This Table is for CH1~CH13
 */
priv->cck_txbbgain_table[0].ccktxbb_valuearray[0] = 0x36;
@@ -1061,8 +1054,7 @@ static void dm_InitializeTXPowerTracking_TSSI(struct 
net_device *dev)
priv->cck_txbbgain_table[22].ccktxbb_valuearray[6] = 0x03;
priv->cck_txbbgain_table[22].ccktxbb_valuearray[7] = 0x01;

-   /*
-* ccktxbb_valuearray[0] is 0xA22 [1] is 0xA24 ...[7] is 0xA29
+   /* ccktxbb_valuearray[0] is 0xA22 [1] is 0xA24 ...[7] is 0xA29
 * This Table is for CH14
 */
priv->cck_txbbgain_ch14_table[0].cckt

[PATCH] riscv: ccache: Remove unused variable

[Yash Shah]

Reading the count register clears the interrupt signal. Currently, the
count registers are read into 'regval' variable but the variable is
never used. Therefore remove it.

Signed-off-by: Yash Shah 
---
 arch/riscv/mm/sifive_l2_cache.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/mm/sifive_l2_cache.c b/arch/riscv/mm/sifive_l2_cache.c
index 4eb6461..3052a42 100644
--- a/arch/riscv/mm/sifive_l2_cache.c
+++ b/arch/riscv/mm/sifive_l2_cache.c
@@ -109,13 +109,13 @@ int unregister_sifive_l2_error_notifier(struct 
notifier_block *nb)
 
 static irqreturn_t l2_int_handler(int irq, void *device)
 {
-   unsigned int regval, add_h, add_l;
+   unsigned int add_h, add_l;
 
if (irq == g_irq[DIR_CORR]) {
add_h = readl(l2_base + SIFIVE_L2_DIRECCFIX_HIGH);
add_l = readl(l2_base + SIFIVE_L2_DIRECCFIX_LOW);
pr_err("L2CACHE: DirError @ 0x%08X.%08X\n", add_h, add_l);
-   regval = readl(l2_base + SIFIVE_L2_DIRECCFIX_COUNT);
+   readl(l2_base + SIFIVE_L2_DIRECCFIX_COUNT);
atomic_notifier_call_chain(&l2_err_chain, SIFIVE_L2_ERR_TYPE_CE,
   "DirECCFix");
}
@@ -123,7 +123,7 @@ static irqreturn_t l2_int_handler(int irq, void *device)
add_h = readl(l2_base + SIFIVE_L2_DATECCFIX_HIGH);
add_l = readl(l2_base + SIFIVE_L2_DATECCFIX_LOW);
pr_err("L2CACHE: DataError @ 0x%08X.%08X\n", add_h, add_l);
-   regval = readl(l2_base + SIFIVE_L2_DATECCFIX_COUNT);
+   readl(l2_base + SIFIVE_L2_DATECCFIX_COUNT);
atomic_notifier_call_chain(&l2_err_chain, SIFIVE_L2_ERR_TYPE_CE,
   "DatECCFix");
}
@@ -131,7 +131,7 @@ static irqreturn_t l2_int_handler(int irq, void *device)
add_h = readl(l2_base + SIFIVE_L2_DATECCFAIL_HIGH);
add_l = readl(l2_base + SIFIVE_L2_DATECCFAIL_LOW);
pr_err("L2CACHE: DataFail @ 0x%08X.%08X\n", add_h, add_l);
-   regval = readl(l2_base + SIFIVE_L2_DATECCFAIL_COUNT);
+   readl(l2_base + SIFIVE_L2_DATECCFAIL_COUNT);
atomic_notifier_call_chain(&l2_err_chain, SIFIVE_L2_ERR_TYPE_UE,
   "DatECCFail");
}
-- 
1.9.1

Re: [PATCH 4.4 0/1] 4.4.184-stable review

[Jon Hunter]

On 26/06/2019 09:45, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.184 release.
> There are 1 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri 28 Jun 2019 08:35:42 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.184-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.4:
6 builds:   6 pass, 0 fail
12 boots:   12 pass, 0 fail
19 tests:   19 pass, 0 fail

Linux version:  4.4.184-rc1-g5f1824292521
Boards tested:  tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

Re: [PATCH 4.9 0/1] 4.9.184-stable review

[Jon Hunter]

On 26/06/2019 09:45, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.184 release.
> There are 1 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri 28 Jun 2019 08:35:42 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.184-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h


All tests are passing for Tegra ...

Test results for stable-v4.9:
8 builds:   8 pass, 0 fail
16 boots:   16 pass, 0 fail
24 tests:   24 pass, 0 fail

Linux version:  4.9.184-rc1-g493abc5bd149
Boards tested:  tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

Re: [PATCH 4.14 0/1] 4.14.131-stable review

[Jon Hunter]

On 26/06/2019 09:45, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.131 release.
> There are 1 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri 28 Jun 2019 08:35:42 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.131-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.14:
8 builds:   8 pass, 0 fail
16 boots:   16 pass, 0 fail
24 tests:   24 pass, 0 fail

Linux version:  4.14.131-rc1-g2f84eb215456
Boards tested:  tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

RE: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

[Zhang, Tina]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, June 27, 2019 12:08 PM
> To: Zhang, Tina 
> Cc: intel-gvt-...@lists.freedesktop.org; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; kra...@redhat.com; zhen...@linux.intel.com; Lv,
> Zhiyuan ; Wang, Zhi A ; Tian,
> Kevin ; Yuan, Hang 
> Subject: Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type
> capability
> 
> On Thu, 27 Jun 2019 11:37:59 +0800
> Tina Zhang  wrote:
> 
> > Cap the number of irqs with fixed indexes and use capability chains to
> > chain device specific irqs.
> >
> > Signed-off-by: Tina Zhang 
> > ---
> >  include/uapi/linux/vfio.h | 19 ++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 02bb7ad6e986..600784acc4ac 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -444,11 +444,27 @@ struct vfio_irq_info {
> >  #define VFIO_IRQ_INFO_MASKABLE (1 << 1)
> >  #define VFIO_IRQ_INFO_AUTOMASKED   (1 << 2)
> >  #define VFIO_IRQ_INFO_NORESIZE (1 << 3)
> > +#define VFIO_IRQ_INFO_FLAG_CAPS(1 << 4) /* Info
> supports caps */
> > __u32   index;  /* IRQ index */
> > +   __u32   cap_offset; /* Offset within info struct of first cap */
> > __u32   count;  /* Number of IRQs within this index */
> >  };
> 
> 
> This cannot be inserted into the middle of the structure, it breaks
> compatibility with all existing userspace binaries.  I must be added to the 
> end
> of the structure.
Indeed. Thanks.

BR,
Tina
> 
> >  #define VFIO_DEVICE_GET_IRQ_INFO   _IO(VFIO_TYPE, VFIO_BASE +
> 9)
> >
> > +/*
> > + * The irq type capability allows irqs unique to a specific device or
> > + * class of devices to be exposed.
> > + *
> > + * The structures below define version 1 of this capability.
> > + */
> > +#define VFIO_IRQ_INFO_CAP_TYPE  3
> > +
> > +struct vfio_irq_info_cap_type {
> > +   struct vfio_info_cap_header header;
> > +   __u32 type; /* global per bus driver */
> > +   __u32 subtype;  /* type specific */
> > +};
> > +
> >  /**
> >   * VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct
> vfio_irq_set)
> >   *
> > @@ -550,7 +566,8 @@ enum {
> > VFIO_PCI_MSIX_IRQ_INDEX,
> > VFIO_PCI_ERR_IRQ_INDEX,
> > VFIO_PCI_REQ_IRQ_INDEX,
> > -   VFIO_PCI_NUM_IRQS
> > +   VFIO_PCI_NUM_IRQS = 5   /* Fixed user ABI, IRQ indexes >=5
> use   */
> > +   /* device specific cap to define content */
> >  };
> >
> >  /*

RE: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

[Zhang, Tina]

> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, June 27, 2019 2:23 PM
> To: Zhang, Tina 
> Cc: intel-gvt-...@lists.freedesktop.org; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
> ; Wang, Zhi A ; Tian, Kevin
> ; Yuan, Hang ;
> alex.william...@redhat.com
> Subject: Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to
> userspace
> 
>   Hi,
> 
> > Instead of delivering page flip events, we choose to post display
> > vblank event. Handling page flip events for both primary plane and
> > cursor plane may make user space quite busy, although we have the
> > mask/unmask mechansim for mitigation. Besides, there are some cases
> > that guest app only uses one framebuffer for both drawing and display.
> > In such case, guest OS won't do the plane page flip when the
> > framebuffer is updated, thus the user land won't be notified about the
> updated framebuffer.
> 
> What happens when the guest is idle and doesn't draw anything to the
> framebuffer?
The vblank event will be delivered to userspace as well, unless guest OS 
disable the pipe.
Does it make sense to vfio/display?
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd

Re: [PATCH v2 0/7] misc fixes to PV extentions code

[Zhenzhong Duan]

On 2019/6/26 21:39, Thomas Gleixner wrote:

Documentation/process/submitting-patches.rst clearly explains why it is a
bad idea to send random collections of patches especially if some patches
are independent and contain bug fixes.

These rules exist for a reason and are not subject to personal
interpretation. You want your patches to be reviewed and merged, so pretty
please make the life of those who need to do that as easy as possible.

It's not the job of reviewers and maintainers to distangle your randomly
ordered patch series.


Ok，understood.  I'll send independent and unrelated patch seperately.

Thanks

Zhenzhong

[PATCH net-next v2] net: ethtool: Allow parsing ETHER_FLOW types when using flow_rule

[Maxime Chevallier]

When parsing an ethtool_rx_flow_spec, users can specify an ethernet flow
which could contain matches based on the ethernet header, such as the
MAC address, the VLAN tag or the ethertype.

ETHER_FLOW uses the src and dst ethernet addresses, along with the
ethertype as keys. Matches based on the vlan tag are also possible, but
they are specified using the special FLOW_EXT flag.

Signed-off-by: Maxime Chevallier 
---
V2 : Add src and dst mac address parsing, as suggested by Pablo.

 net/core/ethtool.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d1011b2e24f..6288e69e94fc 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -2883,6 +2883,30 @@ ethtool_rx_flow_rule_create(const struct 
ethtool_rx_flow_spec_input *input)
match->mask.basic.n_proto = htons(0x);
 
switch (fs->flow_type & ~(FLOW_EXT | FLOW_MAC_EXT | FLOW_RSS)) {
+   case ETHER_FLOW: {
+   const struct ethhdr *ether_spec, *ether_m_spec;
+
+   ether_spec = &fs->h_u.ether_spec;
+   ether_m_spec = &fs->m_u.ether_spec;
+
+   if (!is_zero_ether_addr(ether_m_spec->h_source)) {
+   ether_addr_copy(match->key.eth_addrs.src,
+   ether_spec->h_source);
+   ether_addr_copy(match->mask.eth_addrs.src,
+   ether_m_spec->h_source);
+   }
+   if (!is_zero_ether_addr(ether_m_spec->h_dest)) {
+   ether_addr_copy(match->key.eth_addrs.dst,
+   ether_spec->h_dest);
+   ether_addr_copy(match->mask.eth_addrs.dst,
+   ether_m_spec->h_dest);
+   }
+   if (ether_m_spec->h_proto) {
+   match->key.basic.n_proto = ether_spec->h_proto;
+   match->mask.basic.n_proto = ether_m_spec->h_proto;
+   }
+   }
+   break;
case TCP_V4_FLOW:
case UDP_V4_FLOW: {
const struct ethtool_tcpip4_spec *v4_spec, *v4_m_spec;
-- 
2.20.1

Re: No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot

[Daniel Drake]

Hi Thomas,

Picking up this issue again after a break!

We made some progress last time on reducing PIT usage in the TSC
calibration code, but we still have the bigger issue to resolve:
IO-APIC code panicing when the PIT isn't ticking.

On Wed, Apr 3, 2019 at 7:21 PM Thomas Gleixner  wrote:
> For newer CPUs we might assume that:
>
>  1) The TSC and APIC timer are actually usable
>
>  2) The frequencies can be retrieved from CPUID or MSRs
>
> If #1 and #2 are reliable we can avoid the whole calibration and interrupt
> delivery mess.
>
> That means we need the following decision logic:
>
>   1) If HPET is available in ACPI, boot normal.
>
>   2) If HPET is not available, verify that the PIT actually counts. If it
>  does, boot normal.
>
>  If it does not either:
>
>  2A) Verify that this is a PCH 300/C240 and fiddle with that ISST bit.
>
>  But that means that we need to chase PCH ids forever...
>
>  2B) Shrug and just avoid the whole PIT/HPET magic all over the place:
>
>  - Avoid the interrupt delivery check in the IOAPIC code as it's
>uninteresting in that case. Trivial to do.

I tried to explore this idea here:
https://lore.kernel.org/patchwork/patch/1064972/
https://lore.kernel.org/patchwork/patch/1064971/

But I can't say I really knew what I was doing there, and you
pointed out some problems.

Any new ideas that I can experiment with?

Being more conservative, how about something like this?
---
 arch/x86/kernel/apic/io_apic.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 53aa234a6803..36b1e7d5b657 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2073,7 +2073,7 @@ static int mp_alloc_timer_irq(int ioapic, int pin)
  *
  * FIXME: really need to revamp this for all platforms.
  */
-static inline void __init check_timer(void)
+static inline void __init check_timer(int timer_was_working)
 {
struct irq_data *irq_data = irq_get_irq_data(0);
struct mp_chip_data *data = irq_data->chip_data;
@@ -2216,8 +2216,15 @@ static inline void __init check_timer(void)
apic_printk(APIC_QUIET, KERN_INFO
"Perhaps problem with the pre-enabled x2apic mode\n"
"Try booting with x2apic and interrupt-remapping 
disabled in the bios.\n");
-   panic("IO-APIC + timer doesn't work!  Boot with apic=debug and send a "
-   "report.  Then try booting with the 'noapic' option.\n");
+
+   if (timer_was_working)
+   panic("IO-APIC + timer doesn't work!  Boot with apic=debug and 
send a "
+   "report.  Then try booting with the 'noapic' 
option.\n");
+   else
+   apic_printk(APIC_QUIET, KERN_INFO
+   "Continuing anyway with no 8254 timer, as it was 
not working even before IO-APIC setup was attempted.\n"
+   "Boot will fail unless another working clocksource 
is found.\n");
+
 out:
local_irq_restore(flags);
 }
@@ -2304,12 +2311,20 @@ static void ioapic_destroy_irqdomain(int idx)
 void __init setup_IO_APIC(void)
 {
int ioapic;
+   int timer_was_working = 0;
 
if (skip_ioapic_setup || !nr_ioapics)
return;
 
io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
 
+   /*
+* Record if the timer was in working state before we do any
+* IO-APIC setup.
+*/
+   if (nr_legacy_irqs())
+   timer_was_working = timer_irq_works();
+
apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
for_each_ioapic(ioapic)
BUG_ON(mp_irqdomain_create(ioapic));
@@ -2323,7 +2338,7 @@ void __init setup_IO_APIC(void)
setup_IO_APIC_irqs();
init_IO_APIC_traps();
if (nr_legacy_irqs())
-   check_timer();
+   check_timer(timer_was_working);
 
ioapic_initialized = 1;
 }
-- 
2.20.1

[PATCH RESEND] Revert "x86/paravirt: Set up the virt_spin_lock_key after static keys get initialized"

[Zhenzhong Duan]

This reverts commit ca5d376e17072c1b60c3fee66f3be58ef018952d.

Commit 8990cac6e5ea ("x86/jump_label: Initialize static branching
early") adds jump_label_init() call in setup_arch() to make static
keys initialized early, so we could use the original simpler code
again.

Signed-off-by: Zhenzhong Duan 
Cc: Waiman Long 
Cc: Peter Zijlstra (Intel) 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Dou Liyang 
---
 arch/x86/kernel/smpboot.c | 3 +--
 arch/x86/xen/spinlock.c   | 6 ++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 362dd89..44472ca 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1308,8 +1308,6 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
pr_info("CPU0: ");
print_cpu_info(&cpu_data(0));
 
-   native_pv_lock_init();
-
uv_system_init();
 
set_mtrr_aps_delayed_init();
@@ -1339,6 +1337,7 @@ void __init native_smp_prepare_boot_cpu(void)
/* already set me in cpu_online_mask in boot_cpu_init() */
cpumask_set_cpu(me, cpu_callout_mask);
cpu_set_state_online(me);
+   native_pv_lock_init();
 }
 
 void __init calculate_max_logical_packages(void)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 3776122..6deb490 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -68,11 +68,8 @@ void xen_init_lock_cpu(int cpu)
int irq;
char *name;
 
-   if (!xen_pvspin) {
-   if (cpu == 0)
-   static_branch_disable(&virt_spin_lock_key);
+   if (!xen_pvspin)
return;
-   }
 
WARN(per_cpu(lock_kicker_irq, cpu) >= 0, "spinlock on CPU%d exists on 
IRQ%d!\n",
 cpu, per_cpu(lock_kicker_irq, cpu));
@@ -124,6 +121,7 @@ void __init xen_init_spinlocks(void)
 
if (!xen_pvspin) {
printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
+   static_branch_disable(&virt_spin_lock_key);
return;
}
printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
-- 
1.8.3.1

[PATCH RESEND] locking/spinlocks, paravirt, hyperv: Correct the hv_nopvspin case

[Zhenzhong Duan]

With the boot parameter "hv_nopvspin" specified a Hyperv guest should
not make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.

In order to avoid this disable the virt_spin_lock_key.

Same change for XEN is already in Commit e6fd28eb3522
("locking/spinlocks, paravirt, xen: Correct the xen_nopvspin case")

Signed-off-by: Zhenzhong Duan 
Cc: Waiman Long 
Cc: Peter Zijlstra (Intel) 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: linux-hyp...@vger.kernel.org
---
 arch/x86/hyperv/hv_spinlock.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 07f21a0..d90b4b0 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -64,6 +64,9 @@ __visible bool hv_vcpu_is_preempted(int vcpu)
 
 void __init hv_init_spinlocks(void)
 {
+   if (unlikely(!hv_pvspin))
+   static_branch_disable(&virt_spin_lock_key);
+
if (!hv_pvspin || !apic ||
!(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
!(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {
-- 
1.8.3.1

RE: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Thursday, June 27, 2019 2:20 PM
> To: Zhang, Tina 
> Cc: Tian, Kevin ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhen...@linux.intel.com; Yuan, Hang
> ; alex.william...@redhat.com; Lv, Zhiyuan
> ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> 
> Subject: Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type
> capability
> 
>   Hi,
> 
> > +struct vfio_irq_info_cap_type {
> > +   struct vfio_info_cap_header header;
> > +   __u32 type; /* global per bus driver */
> > +   __u32 subtype;  /* type specific */
> 
> Do we really need both type and subtype?
Then, if one device has several irqs, how can we identify them?
Thanks.

BR,
tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

Re: [PATCH] riscv: ccache: Remove unused variable

[Christoph Hellwig]

On Thu, Jun 27, 2019 at 02:04:46PM +0530, Yash Shah wrote:
> Reading the count register clears the interrupt signal. Currently, the
> count registers are read into 'regval' variable but the variable is
> never used. Therefore remove it.
> 
> Signed-off-by: Yash Shah 
> ---
>  arch/riscv/mm/sifive_l2_cache.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Unrelated note:  that driver absolutely does not belong into
arch/riscv/mm.  arch/$(ARCH)/mm is for architecte-specific memory
management code, not for random drivers.

Re: [PATCH] MAINTAINERS: change the arch/riscv git tree to the new shared tree

[Christoph Hellwig]

On Thu, Jun 13, 2019 at 12:25:18AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 12:07:21AM -0700, Paul Walmsley wrote:
> > Palmer, with Konstantin's gracious help, set up a shared kernel.org
> > git tree for arch/riscv patches going forward.  Change the MAINTAINERS
> > file accordingly.
> > 
> > Signed-off-by: Paul Walmsley 
> > Cc: Palmer Dabbelt 
> 
> Should you be added to the maintainers?  Is Albert still around, as
> I see a lot of people Ccing him, but never getting an answer?

ping?

Re: [PATCH] riscv: Remove gate area stubs

[Christoph Hellwig]

On Wed, Jun 26, 2019 at 09:46:18PM -0700, Andy Lutomirski wrote:
> Since commit a6c19dfe3994 ("arm64,ia64,ppc,s390,sh,tile,um,x86,mm:
> remove default gate area"), which predates riscv's inclusion in
> Linux by almost three years, the default behavior wrt the gate area
> is sane.  Remove riscv's gate area stubs.

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [PATCH v12 04/13] mfd: Add Ingenic TCU driver

[Lee Jones]

On Thu, 27 Jun 2019, Paul Cercueil wrote:
> Le jeu. 27 juin 2019 à 8:58, Lee Jones  a écrit :
> > On Wed, 26 Jun 2019, Paul Cercueil wrote:
> > >  Le mer. 26 juin 2019 à 15:18, Lee Jones  a
> > > écrit :
> > >  > On Tue, 21 May 2019, Paul Cercueil wrote:
> > >  >
> > >  > >  This driver will provide a regmap that can be retrieved very
> > > early
> > >  > > in
> > >  > >  the boot process through the API function
> > > ingenic_tcu_get_regmap().
> > >  > >
> > >  > >  Additionally, it will call devm_of_platform_populate() so that
> > > all
> > >  > > the
> > >  > >  children devices will be probed.
> > >  > >
> > >  > >  Signed-off-by: Paul Cercueil 
> > >  > >  ---
> > >  > >
> > >  > >  Notes:
> > >  > >  v12: New patch
> > >  > >
> > >  > >   drivers/mfd/Kconfig |   8 +++
> > >  > >   drivers/mfd/Makefile|   1 +
> > >  > >   drivers/mfd/ingenic-tcu.c   | 113
> > >  > > 
> > >  > >   include/linux/mfd/ingenic-tcu.h |   8 +++
> > >  > >   4 files changed, 130 insertions(+)
> > >  > >   create mode 100644 drivers/mfd/ingenic-tcu.c
> > 
> > [...]
> > 
> > >  > >  +static struct regmap * __init ingenic_tcu_create_regmap(struct
> > >  > > device_node *np)
> > >  > >  +{
> > >  > >  +   struct resource res;
> > >  > >  +   void __iomem *base;
> > >  > >  +   struct regmap *map;
> > >  > >  +
> > >  > >  +   if (!of_match_node(ingenic_tcu_of_match, np))
> > >  > >  +   return ERR_PTR(-EINVAL);
> > 
> > Drop this check.
> > 
> > >  > >  +   base = of_io_request_and_map(np, 0, "TCU");
> > >  > >  +   if (IS_ERR(base))
> > >  > >  +   return ERR_PTR(PTR_ERR(base));
> > >  > >  +
> > >  > >  +   map = regmap_init_mmio(NULL, base,
> > > &ingenic_tcu_regmap_config);
> > >  > >  +   if (IS_ERR(map))
> > >  > >  +   goto err_iounmap;
> > 
> > Place this inside probe().
> > 
> > >  > >  +   return map;
> > >  > >  +
> > >  > >  +err_iounmap:
> > >  > >  +   iounmap(base);
> > >  > >  +   of_address_to_resource(np, 0, &res);
> > >  > >  +   release_mem_region(res.start, resource_size(&res));
> > >  > >  +
> > >  > >  +   return map;
> > >  > >  +}
> > >  >
> > >  > Why does this need to be set-up earlier than probe()?
> > > 
> > >  See the explanation below.
> > 
> > I think the answer is, it doesn't.
> > 
> > >  > >  +static int __init ingenic_tcu_probe(struct platform_device
> > > *pdev)
> > >  > >  +{
> > >  > >  +   struct regmap *map =
> > > ingenic_tcu_get_regmap(pdev->dev.of_node);
> > >  > >  +
> > >  > >  +   platform_set_drvdata(pdev, map);
> > >  > >  +
> > >  > >  +   regmap_attach_dev(&pdev->dev, map,
> > > &ingenic_tcu_regmap_config);
> > >  > >  +
> > >  > >  +   return devm_of_platform_populate(&pdev->dev);
> > >  > >  +}
> > >  > >  +
> > >  > >  +static struct platform_driver ingenic_tcu_driver = {
> > >  > >  +   .driver = {
> > >  > >  +   .name = "ingenic-tcu",
> > >  > >  +   .of_match_table = ingenic_tcu_of_match,
> > >  > >  +   },
> > >  > >  +};
> > >  > >  +
> > >  > >  +static int __init ingenic_tcu_platform_init(void)
> > >  > >  +{
> > >  > >  +   return platform_driver_probe(&ingenic_tcu_driver,
> > >  > >  +ingenic_tcu_probe);
> > >  >
> > >  > What?  Why?
> > > 
> > >  The device driver probed here will populate the children devices,
> > >  which will be able to retrieve the pointer to the regmap through
> > >  device_get_regmap(dev->parent).
> > 
> > I've never heard of this call.  Where is it?
> 
> dev_get_regmap, in .
> 
> > >  The children devices are normal platform drivers that can be probed
> > >  the normal way. These are the PWM driver, the watchdog driver, and
> > > the
> > >  OST (OS Timer) clocksource driver, all part of the same hardware
> > > block
> > >  (the Timer/Counter Unit or TCU).
> > 
> > If they are normal devices, then there is no need to roll your own
> > regmap-getter implementation like this.
> > 
> > >  > >  +}
> > >  > >  +subsys_initcall(ingenic_tcu_platform_init);
> > >  > >  +
> > >  > >  +struct regmap * __init ingenic_tcu_get_regmap(struct
> > > device_node
> > >  > > *np)
> > >  > >  +{
> > >  > >  +   if (!tcu_regmap)
> > >  > >  +   tcu_regmap = ingenic_tcu_create_regmap(np);
> > >  > >  +
> > >  > >  +   return tcu_regmap;
> > >  > >  +}
> > >  >
> > >  > This makes me pretty uncomfortable.
> > >  >
> > >  > What calls it?
> > > 
> > >  The TCU IRQ driver (patch [06/13]), clocks driver (patch [05/13]),
> > > and the
> > >  non-OST clocksource driver (patch [07/13]) all probe very early in
> > > the boot
> > >  process, and share the same devicetree node. They call this
> > > function to get
> > >  a pointer to the regmap.
> > 
> > Horrible!
> > 
> > Instead, you should send it through platform_set_drvdata() and collect
> > it in the child drivers with platform_get_drvdata(dev->parent).
> 
> The IRQ, clocks and clocksource driver do NOT have a "struct device" to
> begin with. They are not platform drivers, and c

Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems

[kbuild test robot]

Hi Ivan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Ivan-Khoronzhuk/xdp-xdp_umem-fix-umem-pages-mapping-for-32bits-systems/20190627-135949
config: x86_64-randconfig-x004-201925 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

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

   net//xdp/xdp_umem.c: In function 'xdp_umem_unmap_pages':
>> net//xdp/xdp_umem.c:177:3: error: implicit declaration of function 'kunmap'; 
>> did you mean 'vunmap'? [-Werror=implicit-function-declaration]
  kunmap(umem->pgs[i]);
  ^~
  vunmap
   net//xdp/xdp_umem.c: In function 'xdp_umem_reg':
>> net//xdp/xdp_umem.c:384:25: error: implicit declaration of function 'kmap'; 
>> did you mean 'bmap'? [-Werror=implicit-function-declaration]
  umem->pages[i].addr = kmap(umem->pgs[i]);
^~~~
bmap
>> net//xdp/xdp_umem.c:384:23: warning: assignment makes pointer from integer 
>> without a cast [-Wint-conversion]
  umem->pages[i].addr = kmap(umem->pgs[i]);
  ^
   cc1: some warnings being treated as errors

vim +177 net//xdp/xdp_umem.c

   171  
   172  static void xdp_umem_unmap_pages(struct xdp_umem *umem)
   173  {
   174  unsigned int i;
   175  
   176  for (i = 0; i < umem->npgs; i++)
 > 177  kunmap(umem->pgs[i]);
   178  }
   179  

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


.config.gz
Description: application/gzip

[tip:x86/boot] x86/boot: Make the GDT 8-byte aligned

[tip-bot for Xiaoyao Li]

Commit-ID:  2238246ff8d533a5f2327d1f953375876d8a013c
Gitweb: https://git.kernel.org/tip/2238246ff8d533a5f2327d1f953375876d8a013c
Author: Xiaoyao Li 
AuthorDate: Thu, 27 Jun 2019 12:55:25 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 27 Jun 2019 10:56:11 +0200

x86/boot: Make the GDT 8-byte aligned

The segment descriptors are loaded with an implicitly LOCK-ed instruction,
which could trigger the split lock #AC exception if the variable is not
properly aligned and crosses a cache line.

Align the GDT properly so the descriptors are all 8 byte aligned.

Signed-off-by: Xiaoyao Li 
Signed-off-by: Thomas Gleixner 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Link: 
https://lkml.kernel.org/r/20190627045525.105266-1-xiaoyao...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/boot/compressed/head_64.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index fafb75c6c592..6233ae35d0d9 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -659,6 +659,7 @@ no_longmode:
 gdt64:
.word   gdt_end - gdt
.quad   0
+   .balign 8
 gdt:
.word   gdt_end - gdt
.long   gdt

Re: [RFC PATCH 00/28] Removing struct page from P2PDMA

[Christoph Hellwig]

On Wed, Jun 26, 2019 at 12:31:08PM -0600, Logan Gunthorpe wrote:
> > we have a hole behind len where we could store flag.  Preferably
> > optionally based on a P2P or other magic memory types config
> > option so that 32-bit systems with 32-bit phys_addr_t actually
> > benefit from the smaller and better packing structure.
> 
> That seems sensible. The one thing that's unclear though is how to get
> the PCI Bus address when appropriate. Can we pass that in instead of the
> phys_addr with an appropriate flag? Or will we need to pass the actual
> physical address and then, at the map step, the driver has to some how
> lookup the PCI device to figure out the bus offset?

Yes, I think we'll need a lookup mechanism of some kind.

Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

[Sudeep Holla]

On Wed, Jun 26, 2019 at 01:27:41PM -0500, Jassi Brar wrote:
> On Wed, Jun 26, 2019 at 11:44 AM Florian Fainelli  
> wrote:
> >
> > On 6/26/19 6:31 AM, Peng Fan wrote:
> > >>> The firmware driver might not have func-id, such as SCMI/SCPI.
> > >>> So add an optional func-id to let smc mailbox driver could
> > >>> use smc SiP func id.
> > >>>
> > >> There is no end to conforming to protocols. Controller drivers should
> > >> be written having no particular client in mind.
> > >
> > > If the func-id needs be passed from user, then the chan_id suggested
> > > by Sudeep should also be passed from user, not in mailbox driver.
> > >
> > > Jassi, so from your point, arm_smc_send_data just send a0 - a6
> > > to firmware, right?
> > >
> > > Sudeep, Andre, Florian,
> > >
> > > What's your suggestion? SCMI not support, do you have
> > > plan to add smc transport in SCMI?
> >
> > On the platforms that I work with, we have taken the liberty of
> > implementing SCMI in our monitor firmware because the other MCU we use
> > for dynamic voltage and frequency scaling did not have enough memory to
> > support that and we still had the ability to make that firmware be
> > trusted enough we could give it power management responsibilities. I
> > would certainly feel more comfortable if the SCMI specification was
> > amended to indicate that the Agent could be such a software entity,
> > still residing on the same host CPU as the Platform(s), but if not,
> > that's fine.
> >
> > This has lead us to implement a mailbox driver that uses a proprietary
> > SMC call for the P2A path ("tx" channel) and the return being done via
> > either that same SMC or through SGI. You can take a look at it in our
> > downstream tree here actually:
> >
> > https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/mailbox/brcmstb-mailbox.c
> >
> > If we can get rid of our own driver and uses a standard SMC based
> > mailbox driver that supports our use case that involves interrupts (we
> > can always change their kind without our firmware/boot loader since FDT
> > is generated from that component), that would be great.
> >
> static irqreturn_t brcm_isr(void)
> {
>  mbox_chan_received_data(&chans[0], NULL);
>  return IRQ_HANDLED;
> }
> 
> Sorry, I fail to understand why the irq can't be moved inside the
> client driver itself? There can't be more cost to it and there
> definitely is no functionality lost.

What if there are multiple clients ?
And I assume you are referring to case like this where IRQ is not tied
to the mailbox IP.

--
Regards,
Sudeep

Re: [RFC PATCH 00/28] Removing struct page from P2PDMA

[Christoph Hellwig]

On Wed, Jun 26, 2019 at 02:45:38PM -0600, Logan Gunthorpe wrote:
> > The bar info would give the exporting struct device and any other info
> > we need to make the iommu mapping.
> 
> Well, the IOMMU mapping is the normal thing the mapping driver will
> always do. We'd really just need the submitting driver to, when
> appropriate, inform the mapping driver that this is a pci bus address
> and not to call dma_map_xxx(). Then, for special mappings for the CMB
> like Christoph is talking about, it's simply a matter of doing a range
> compare on the PCI Bus address and converting the bus address to a BAR
> and offset.

Well, range compare on the physical address.  We have a few different
options here:

 (a) a range is normal RAM, DMA mapping works as usual
 (b) a range is another devices BAR, in which case we need to do a
 map_resource equivalent (which really just means don't bother with
 cache flush on non-coherent architectures) and apply any needed
 offset, fixed or iommu based
 (c) a range points to a BAR on the acting device. In which case we
 don't need to DMA map at all, because no dma is happening but just an
 internal transfer.  And depending on the device that might also require
 a different addressing mode

I guess it might make sense to just have a block layer flag that (b) or
(c) might be contained in a bio.  Then we always look up the data
structure, but can still fall back to (a) if nothing was found.  That
even allows free mixing and matching of memory types, at least as long
as they are contained to separate bio_vec segments.

RE: [RFC PATCH v3 2/4] vfio: Introduce vGPU display irq type

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Thursday, June 27, 2019 2:21 PM
> To: Zhang, Tina 
> Cc: Tian, Kevin ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhen...@linux.intel.com; Yuan, Hang
> ; alex.william...@redhat.com; Lv, Zhiyuan
> ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> 
> Subject: Re: [RFC PATCH v3 2/4] vfio: Introduce vGPU display irq type
> 
> On Thu, Jun 27, 2019 at 11:38:00AM +0800, Tina Zhang wrote:
> > Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and
> > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display
> >
> > Signed-off-by: Tina Zhang 
> > ---
> >  include/uapi/linux/vfio.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 600784acc4ac..c3e9c821a5cb 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -465,6 +465,9 @@ struct vfio_irq_info_cap_type {
> > __u32 subtype;  /* type specific */
> >  };
> >
> > +#define VFIO_IRQ_TYPE_GFX  (1)
> > +#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ   (1)
> 
> VFIO_IRQ_TYPE_GFX_VBLANK ?
VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ is proposed to cover all the display related 
events. In this version, we only use VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to 
deliver vblank event. However, we might still want to reserve seat for other 
display event, like page flip event.
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

RE: [PATCH 00/10] x86/CPU and x86/resctrl: Support pseudo-lock regions spanning L2 and L3 cache

[David Laight]

From: Reinette Chatre
> Sent: 26 June 2019 18:49
> 
> Cache pseudo-locking involves preloading a region of physical memory into a
> reserved portion of cache that no task or CPU can subsequently fill into and
> from that point on will only serve cache hits. At this time it is only
> possible to create cache pseudo-locked regions in either L2 or L3 cache,
> supporting systems that support either L2 Cache Allocation Technology (CAT)
> or L3 CAT because CAT is the mechanism used to manage reservations of cache
> portions.

While this is a 'nice' hardware feature for some kinds of embedded systems
I don't see how it can be sensibly used inside a Linux kernel.
There are an awful lot of places where things can go horribly wrong.
I can imagine:
- Multiple requests to lock regions that end up trying to use the same
  set-associative cache lines leaving none for normal operation.
- Excessive cache line bouncing because fewer lines are available.
- The effect of cache invalidate requests for the locked addresses.
- I suspect the Linux kernel can do full cache invalidates at certain times.

You've not given a use case.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH] RISC-V: defconfig: enable MMC & SPI for RISC-V

[Andreas Schwab]

On Jun 25 2019, Troy Benjegerdes  wrote:

> and I see this in the log
>
> [1.106626] m25p80 spi0.0: unrecognized JEDEC id bytes: 9d 70 19 9d 70 19

You need the patchset "mtd: spi-nor: add support for is25wp256 spi-nor
flash".

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH v8 4/6] i2c: core: Move ACPI IRQ handling to probe time

[Charles Keepax]

Bring the ACPI path in sync with the device tree path and handle all the
IRQ fetching at probe time. This leaves the only IRQ handling at device
registration time being that which is passed directly through the board
info as either a resource or an actual IRQ number.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Charles Keepax 
---

No change since v7.

Thanks,
Charles

 drivers/i2c/i2c-core-acpi.c | 16 ++--
 drivers/i2c/i2c-core-base.c |  5 -
 drivers/i2c/i2c-core.h  |  7 +++
 3 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 3eb65f113c13b..eaf45cf8e5b91 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -144,8 +144,17 @@ static int i2c_acpi_add_resource(struct acpi_resource 
*ares, void *data)
return 1; /* No need to add resource to the list */
 }
 
-static int i2c_acpi_get_irq(struct acpi_device *adev)
+/**
+ * i2c_acpi_get_irq - get device IRQ number from ACPI
+ * @client: Pointer to the I2C client device
+ *
+ * Find the IRQ number used by a specific client device.
+ *
+ * Return: The IRQ number or an error code.
+ */
+int i2c_acpi_get_irq(struct i2c_client *client)
 {
+   struct acpi_device *adev = ACPI_COMPANION(&client->dev);
struct list_head resource_list;
int irq = -ENOENT;
int ret;
@@ -197,11 +206,6 @@ static int i2c_acpi_get_info(struct acpi_device *adev,
if (adapter_handle)
*adapter_handle = lookup.adapter_handle;
 
-   /* Then fill IRQ number if any */
-   info->irq = i2c_acpi_get_irq(adev);
-   if (info->irq < 0)
-   return info->irq;
-
acpi_set_modalias(adev, dev_name(&adev->dev), info->type,
  sizeof(info->type));
 
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 2a0a9cc8b8fbd..c8fa2b825dcef 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,7 +327,10 @@ static int i2c_device_probe(struct device *dev)
if (irq == -EINVAL || irq == -ENODATA)
irq = of_irq_get(dev->of_node, 0);
} else if (ACPI_COMPANION(dev)) {
-   irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
+   irq = i2c_acpi_get_irq(client);
+
+   if (irq == -ENOENT)
+   irq = 
acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
}
if (irq == -EPROBE_DEFER)
return irq;
diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
index 2a3b28bf826b1..517d98be68d25 100644
--- a/drivers/i2c/i2c-core.h
+++ b/drivers/i2c/i2c-core.h
@@ -63,6 +63,8 @@ const struct acpi_device_id *
 i2c_acpi_match_device(const struct acpi_device_id *matches,
  struct i2c_client *client);
 void i2c_acpi_register_devices(struct i2c_adapter *adap);
+
+int i2c_acpi_get_irq(struct i2c_client *client);
 #else /* CONFIG_ACPI */
 static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
 static inline const struct acpi_device_id *
@@ -71,6 +73,11 @@ i2c_acpi_match_device(const struct acpi_device_id *matches,
 {
return NULL;
 }
+
+static inline int i2c_acpi_get_irq(struct i2c_client *client)
+{
+   return 0;
+}
 #endif /* CONFIG_ACPI */
 extern struct notifier_block i2c_acpi_notifier;
 
-- 
2.11.0

[PATCH v8 2/6] i2c: acpi: Use available IRQ helper functions

[Charles Keepax]

Use the available IRQ helper functions, most of the functions have
additional helpful side affects like configuring the trigger type of the
IRQ.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Charles Keepax 
---

Changes since v7:
 - Leave call to acpi_dev_free_resource_list

Thanks,
Charles

 drivers/i2c/i2c-core-acpi.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index f1d648962b223..1820f18a4e5f9 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -133,13 +133,23 @@ static int i2c_acpi_do_lookup(struct acpi_device *adev,
return 0;
 }
 
+static int i2c_acpi_add_resource(struct acpi_resource *ares, void *data)
+{
+   int *irq = data;
+   struct resource r;
+
+   if (*irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r))
+   *irq = i2c_dev_irq_from_resources(&r, 1);
+
+   return 1; /* No need to add resource to the list */
+}
+
 static int i2c_acpi_get_info(struct acpi_device *adev,
 struct i2c_board_info *info,
 struct i2c_adapter *adapter,
 acpi_handle *adapter_handle)
 {
struct list_head resource_list;
-   struct resource_entry *entry;
struct i2c_acpi_lookup lookup;
int ret;
 
@@ -172,17 +182,11 @@ static int i2c_acpi_get_info(struct acpi_device *adev,
 
/* Then fill IRQ number if any */
INIT_LIST_HEAD(&resource_list);
-   ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
+   ret = acpi_dev_get_resources(adev, &resource_list,
+i2c_acpi_add_resource, &info->irq);
if (ret < 0)
return -EINVAL;
 
-   resource_list_for_each_entry(entry, &resource_list) {
-   if (resource_type(entry->res) == IORESOURCE_IRQ) {
-   info->irq = entry->res->start;
-   break;
-   }
-   }
-
acpi_dev_free_resource_list(&resource_list);
 
acpi_set_modalias(adev, dev_name(&adev->dev), info->type,
-- 
2.11.0

[PATCH v8 0/6] I2C IRQ Probe Improvements

[Charles Keepax]

This series attempts to align as much IRQ handling into the
probe path as possible. Note that I don't have a great setup
for testing these patches so they are mostly just build tested
and need careful review and testing before any of them are
merged.

The series brings the ACPI path inline with the way the device
tree path handles the IRQ entirely at probe time. However,
it still leaves any IRQ specified through the board_info as
being handled at device time. In that case we need to cache
something from the board_info until probe time, which leaves
any alternative solution with something basically the same as
the current handling although perhaps caching more stuff.

Thanks,
Charles

See previous discussions:
 - https://lkml.org/lkml/2019/2/15/989
 - https://www.spinics.net/lists/linux-i2c/msg39541.html

Charles Keepax (6):
  i2c: core: Allow whole core to use i2c_dev_irq_from_resources
  i2c: acpi: Use available IRQ helper functions
  i2c: acpi: Factor out getting the IRQ from ACPI
  i2c: core: Move ACPI IRQ handling to probe time
  i2c: core: Move ACPI gpio IRQ handling into i2c_acpi_get_irq
  i2c: core: Tidy up handling of init_irq

 drivers/i2c/i2c-core-acpi.c | 58 -
 drivers/i2c/i2c-core-base.c | 11 +
 drivers/i2c/i2c-core.h  |  9 +++
 3 files changed, 56 insertions(+), 22 deletions(-)

-- 
2.11.0

[PATCH v8 3/6] i2c: acpi: Factor out getting the IRQ from ACPI

[Charles Keepax]

In preparation for future refactoring factor out the fetch of the IRQ
into its own helper function. Whilst we are at it update the handling
to return the actual error code returned from acpi_dev_get_resources
as well.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Charles Keepax 
---

Changes since v7:
 - Leave call to acpi_dev_free_resource_list

Thanks,
Charles

 drivers/i2c/i2c-core-acpi.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 1820f18a4e5f9..3eb65f113c13b 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -144,12 +144,29 @@ static int i2c_acpi_add_resource(struct acpi_resource 
*ares, void *data)
return 1; /* No need to add resource to the list */
 }
 
+static int i2c_acpi_get_irq(struct acpi_device *adev)
+{
+   struct list_head resource_list;
+   int irq = -ENOENT;
+   int ret;
+
+   INIT_LIST_HEAD(&resource_list);
+
+   ret = acpi_dev_get_resources(adev, &resource_list,
+i2c_acpi_add_resource, &irq);
+   if (ret < 0)
+   return ret;
+
+   acpi_dev_free_resource_list(&resource_list);
+
+   return irq;
+}
+
 static int i2c_acpi_get_info(struct acpi_device *adev,
 struct i2c_board_info *info,
 struct i2c_adapter *adapter,
 acpi_handle *adapter_handle)
 {
-   struct list_head resource_list;
struct i2c_acpi_lookup lookup;
int ret;
 
@@ -181,13 +198,9 @@ static int i2c_acpi_get_info(struct acpi_device *adev,
*adapter_handle = lookup.adapter_handle;
 
/* Then fill IRQ number if any */
-   INIT_LIST_HEAD(&resource_list);
-   ret = acpi_dev_get_resources(adev, &resource_list,
-i2c_acpi_add_resource, &info->irq);
-   if (ret < 0)
-   return -EINVAL;
-
-   acpi_dev_free_resource_list(&resource_list);
+   info->irq = i2c_acpi_get_irq(adev);
+   if (info->irq < 0)
+   return info->irq;
 
acpi_set_modalias(adev, dev_name(&adev->dev), info->type,
  sizeof(info->type));
-- 
2.11.0

[PATCH v8 6/6] i2c: core: Tidy up handling of init_irq

[Charles Keepax]

Only set init_irq during i2c_device_new and only handle client->irq on
the probe/remove paths.

Suggested-by: Benjamin Tissoires 
Reviewed-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Charles Keepax 
---
 drivers/i2c/i2c-core-base.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index f0e1d338c7ddf..f26ed495d3842 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -314,6 +314,8 @@ static int i2c_device_probe(struct device *dev)
 
driver = to_i2c_driver(dev->driver);
 
+   client->irq = client->init_irq;
+
if (!client->irq && !driver->disable_i2c_core_irq_mapping) {
int irq = -ENOENT;
 
@@ -424,7 +426,7 @@ static int i2c_device_remove(struct device *dev)
dev_pm_clear_wake_irq(&client->dev);
device_init_wakeup(&client->dev, false);
 
-   client->irq = client->init_irq;
+   client->irq = 0;
if (client->flags & I2C_CLIENT_HOST_NOTIFY)
pm_runtime_put(&client->adapter->dev);
 
@@ -741,7 +743,6 @@ i2c_new_client_device(struct i2c_adapter *adap, struct 
i2c_board_info const *inf
if (!client->init_irq)
client->init_irq = i2c_dev_irq_from_resources(info->resources,
 info->num_resources);
-   client->irq = client->init_irq;
 
strlcpy(client->name, info->type, sizeof(client->name));
 
-- 
2.11.0