date:20190701


Switching Andy's email address.

On Mon, Jul 01 2019 at 09:32 -0600, Lina Iyer wrote:

When triggering a TCS to send its contents, reading back the trigger
value may return an incorrect value. That is because, writing the
trigger may raise an interrupt which could be handled immediately and
the trigger value could be reset in the interrupt handler. By doing a
read back we may end up spinning waiting for the value we wrote.

Fixes: 658628 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM
SoCs")
Signed-off-by: Lina Iyer 
---
drivers/soc/qcom/rpmh-rsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 92461311aef3..2fc2fa879480 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -300,7 +300,7 @@ static void __tcs_trigger(struct rsc_drv *drv, int tcs_id)
enable = TCS_AMC_MODE_ENABLE;
write_tcs_reg_sync(drv, RSC_DRV_CONTROL, tcs_id, enable);
enable |= TCS_AMC_MODE_TRIGGER;
-   write_tcs_reg_sync(drv, RSC_DRV_CONTROL, tcs_id, enable);
+   write_tcs_reg(drv, RSC_DRV_CONTROL, tcs_id, enable);
}

static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] drivers: qcom: rpmh-rsc: simplify TCS locking


Switching Andy's email address.

On Mon, Jul 01 2019 at 09:32 -0600, Lina Iyer wrote:

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

tcs->lock was introduced to serialize access with in TCS group. But
even without tcs->lock, drv->lock is serving the same purpose. So
use a single drv->lock.

Other optimizations include -
- Remove locking around clear_bit() in IRQ handler. clear_bit() is
  atomic.
- Remove redundant read of TCS registers.
- Use spin_lock instead of _irq variants as the locks are not held
  in interrupt context.

Fixes: 658628 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM
SoCs")
Signed-off-by: Raju P.L.S.S.S.N 
Signed-off-by: Lina Iyer 
---
drivers/soc/qcom/rpmh-internal.h |  2 --
drivers/soc/qcom/rpmh-rsc.c  | 37 +++-
drivers/soc/qcom/rpmh.c  | 20 +++--
3 files changed, 21 insertions(+), 38 deletions(-)

diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h
index a767991c..969d5030860e 100644
--- a/drivers/soc/qcom/rpmh-internal.h
+++ b/drivers/soc/qcom/rpmh-internal.h
@@ -28,7 +28,6 @@ struct rsc_drv;
 * @offset:start of the TCS group relative to the TCSes in the RSC
 * @num_tcs:   number of TCSes in this type
 * @ncpt:  number of commands in each TCS
- * @lock:  lock for synchronizing this TCS writes
 * @req:   requests that are sent from the TCS
 * @cmd_cache: flattened cache of cmds in sleep/wake TCS
 * @slots: indicates which of @cmd_addr are occupied
@@ -40,7 +39,6 @@ struct tcs_group {
u32 offset;
int num_tcs;
int ncpt;
-   spinlock_t lock;
const struct tcs_request *req[MAX_TCS_PER_TYPE];
u32 *cmd_cache;
DECLARE_BITMAP(slots, MAX_TCS_SLOTS);
diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index e278fc11fe5c..92461311aef3 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -93,8 +93,7 @@ static void write_tcs_reg_sync(struct rsc_drv *drv, int reg, 
int tcs_id,

static bool tcs_is_free(struct rsc_drv *drv, int tcs_id)
{
-   return !test_bit(tcs_id, drv->tcs_in_use) &&
-  read_tcs_reg(drv, RSC_DRV_STATUS, tcs_id, 0);
+   return !test_bit(tcs_id, drv->tcs_in_use);
}

static struct tcs_group *get_tcs_of_type(struct rsc_drv *drv, int type)
@@ -104,29 +103,28 @@ static struct tcs_group *get_tcs_of_type(struct rsc_drv 
*drv, int type)

static int tcs_invalidate(struct rsc_drv *drv, int type)
{
-   int m;
+   int m, ret = 0;
struct tcs_group *tcs;

tcs = get_tcs_of_type(drv, type);

-   spin_lock(>lock);
-   if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS)) {
-   spin_unlock(>lock);
-   return 0;
-   }
+   spin_lock(>lock);
+   if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS))
+   goto done;

for (m = tcs->offset; m < tcs->offset + tcs->num_tcs; m++) {
if (!tcs_is_free(drv, m)) {
-   spin_unlock(>lock);
-   return -EAGAIN;
+   ret = -EAGAIN;
+   goto done;
}
write_tcs_reg_sync(drv, RSC_DRV_CMD_ENABLE, m, 0);
write_tcs_reg_sync(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, m, 0);
}
bitmap_zero(tcs->slots, MAX_TCS_SLOTS);
-   spin_unlock(>lock);

-   return 0;
+done:
+   spin_unlock(>lock);
+   return ret;
}

/**
@@ -242,9 +240,7 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
write_tcs_reg(drv, RSC_DRV_CMD_ENABLE, i, 0);
write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, i, 0);
write_tcs_reg(drv, RSC_DRV_IRQ_CLEAR, 0, BIT(i));
-   spin_lock(>lock);
clear_bit(i, drv->tcs_in_use);
-   spin_unlock(>lock);
if (req)
rpmh_tx_done(req, err);
}
@@ -349,14 +345,12 @@ static int tcs_write(struct rsc_drv *drv, const struct 
tcs_request *msg)
{
struct tcs_group *tcs;
int tcs_id;
-   unsigned long flags;
int ret;

tcs = get_tcs_for_msg(drv, msg);
if (IS_ERR(tcs))
return PTR_ERR(tcs);

-   spin_lock_irqsave(>lock, flags);
spin_lock(>lock);
/*
 * The h/w does not like if we send a request to the same address,
@@ -364,26 +358,23 @@ static int tcs_write(struct rsc_drv *drv, const struct 
tcs_request *msg)
 */
ret = check_for_req_inflight(drv, tcs, msg);
if (ret) {
-   spin_unlock(>lock);
goto done_write;
}

tcs_id = find_free_tcs(tcs);
if (tcs_id < 0) {
ret = tcs_id;
-   spin_unlock(>lock);
goto done_write;
}

tcs->req[tcs_id - tcs->offset] = msg;
set_bit(tcs_id, drv->tcs_in_use);
-   spin_unlock(>lock);

__tcs_buffer_write(drv, tcs_id, 0, msg);
__tcs_trigger(drv, tcs_id);

[PATCH] Revert "x86/build: Move _etext to actual end of .text"

2019-07-01 Thread Ross Zwisler

This reverts commit 392bef709659abea614abfe53cf228e7a59876a4.

Per the discussion here:

https://lkml.org/lkml/2019/6/20/830

the above referenced commit breaks kernel compilation with old GCC
toolchains as well as current versions of the Gold linker.  Revert it so
we don't regress and lose the ability to compile the kernel with these
tools.

Signed-off-by: Ross Zwisler 
---
 arch/x86/kernel/vmlinux.lds.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 0850b5149345..4d1517022a14 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -141,10 +141,10 @@ SECTIONS
*(.text.__x86.indirect_thunk)
__indirect_thunk_end = .;
 #endif
-   } :text = 0x9090
 
-   /* End of text section */
-   _etext = .;
+   /* End of text section */
+   _etext = .;
+   } :text = 0x9090
 
NOTES :text :note
 
-- 
2.20.1

Re: Adding some trees to linux-next?

2019-07-01 Thread Darrick J. Wong

On Tue, Jul 02, 2019 at 01:42:10AM +1000, Stephen Rothwell wrote:
> Hi Darrick,
> 
> On Mon, 1 Jul 2019 08:35:52 -0700 "Darrick J. Wong"  
> wrote:
> >
> > Could you add my iomap-for-next and vfs-for-next branches to linux-next,
> > please?  They can be found here:
> > 
> > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#iomap-for-next
> > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#vfs-for-next
> > 
> > I've decided that trying to munge all that through the xfs for-next
> > branch is too much insanity and splitting them up will help me prevent
> > my head from falling off.
> 
> Just out of interest, do you intend to send these directly to Linus, or
> via another tree?

The iomap stuff I'd definitely send directly to Linus.

For vfs stuff, it depends.  For work in the core vfs I'll probably just
keep sending patches through Al, but for treewide things like ioctl
cleanups I suspect it'll be easier to let them soak in -next and then
send them directly.

I also dropped the f2fs parts of the setflags/fssetxattr patches because
while I think your fix from yesterday's for-next is correct, I prefer to
let Eric Biggers' cleanup land through the f2fs tree before I try to
clean up f2fs again.  There shouldn't be any harm in letting that lag a
little while longer.

--D

> -- 
> Cheers,
> Stephen Rothwell

Re: Adding some trees to linux-next?

2019-07-01 Thread Stephen Rothwell

Hi Darrick,

On Mon, 1 Jul 2019 08:35:52 -0700 "Darrick J. Wong"  
wrote:
>
> Could you add my iomap-for-next and vfs-for-next branches to linux-next,
> please?  They can be found here:
> 
> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#iomap-for-next
> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#vfs-for-next
> 
> I've decided that trying to munge all that through the xfs for-next
> branch is too much insanity and splitting them up will help me prevent
> my head from falling off.

Added from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
s...@canb.auug.org.au

pgpIDLyYdm30f.pgp
Description: OpenPGP digital signature

[PATCH v2] sched/fair: fix imbalance due to CPU affinity

2019-07-01 Thread Vincent Guittot

The load_balance() has a dedicated mecanism to detect when an imbalance
is due to CPU affinity and must be handled at parent level. In this case,
the imbalance field of the parent's sched_group is set.

The description of sg_imbalanced() gives a typical example of two groups
of 4 CPUs each and 4 tasks each with a cpumask covering 1 CPU of the first
group and 3 CPUs of the second group. Something like:

{ 0 1 2 3 } { 4 5 6 7 }
* * * *

But the load_balance fails to fix this UC on my octo cores system
made of 2 clusters of quad cores.

Whereas the load_balance is able to detect that the imbalanced is due to
CPU affinity, it fails to fix it because the imbalance field is cleared
before letting parent level a chance to run. In fact, when the imbalance is
detected, the load_balance reruns without the CPU with pinned tasks. But
there is no other running tasks in the situation described above and
everything looks balanced this time so the imbalance field is immediately
cleared.

The imbalance field should not be cleared if there is no other task to move
when the imbalance is detected.

Signed-off-by: Vincent Guittot 
---

Sorry, I sent the patch before rebasing it on top of sched-tip and it might
conlfict when applying because it was on top of my ongoing rework of 
load_balance

This version is rebased on top of latest shced-tip/sched/core

 kernel/sched/fair.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b798fe7..fff5632 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8992,9 +8992,10 @@ static int load_balance(int this_cpu, struct rq *this_rq,
 out_balanced:
/*
 * We reach balance although we may have faced some affinity
-* constraints. Clear the imbalance flag if it was set.
+* constraints. Clear the imbalance flag only if other tasks got
+* a chance to move and fix the imbalance.
 */
-   if (sd_parent) {
+   if (sd_parent && !(env.flags & LBF_ALL_PINNED)) {
int *group_imbalance = _parent->groups->sgc->imbalance;
 
if (*group_imbalance)
-- 
2.7.4

Re: [PATCH] csky: Improve abiv1 mem ops performance with glibc codes

On Mon, Jul 1, 2019 at 5:26 PM Guo Ren  wrote:
> On Mon, Jul 1, 2019 at 10:52 PM Arnd Bergmann  wrote:
> >
> > On Sat, Jun 29, 2019 at 7:36 AM  wrote:
> > >
> > > From: Guo Ren 
> > >
> > > These codes are copied from glibc/string directory, they are the generic
> > > implementation for string operations. We may further optimize them with
> > > assembly code in the future.
> > >
> > > In fact these code isn't tested enough for kernel, but we've tested them
> > > on glibc and it seems good. We just trust them :)
> >
> > Are these files from the architecture independent portion of glibc or
> > are they csky specific? If they are architecture independent, we might
> > want to see if they make sense for other architectures as well, and
> > add them to lib/ rather than arch/csky/lib/
> They are just copied from glibc-2.28/string/*.c and they are generic.
> OK, I'll try to add them to lib/.

Ok. Note that lib/string.c contains very basic versions of these already,
so please see which of the functions you have actually make a
difference in practice over those (if you haven't done that already).

Otherwise you can probably follow the example of the libgcc functions
in lib/ashldi3.c etc: add a Kconfig symbol like CONFIG_GENERIC_LIB_ASHLDI3
for each function you had, put the glibc version into a new file, and allow
architectures to select them individually, which in turn should
replace the version from lib/string.c.

   Arnd

Re: [PATCH] media: venus: Update to bitrate based clock scaling

2019-07-01 Thread Stanimir Varbanov

Hi Aniket,

On 6/26/19 11:23 AM, Aniket Masule wrote:
> Introduced clock scaling using bitrate, current
> calculations consider only the cycles per mb.
> Also, clock scaling is now triggered before every
> buffer being queued to the device. This helps in
> deciding precise clock cycles required.
> 
> Signed-off-by: Aniket Masule 
> ---
>  drivers/media/platform/qcom/venus/core.c| 16 +--
>  drivers/media/platform/qcom/venus/core.h|  1 +
>  drivers/media/platform/qcom/venus/helpers.c | 43 
> +
>  3 files changed, 47 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.c 
> b/drivers/media/platform/qcom/venus/core.c
> index f1597d6..ad6bb74 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -474,14 +474,14 @@ static __maybe_unused int venus_runtime_resume(struct 
> device *dev)
>  };
>  
>  static struct codec_freq_data sdm845_codec_freq_data[] =  {
> - { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_ENC, 675 },
> - { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_ENC, 675 },
> - { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_ENC, 675 },
> - { V4L2_PIX_FMT_MPEG2, VIDC_SESSION_TYPE_DEC, 200 },
> - { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_DEC, 200 },
> - { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_DEC, 200 },
> - { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_DEC, 200 },
> - { V4L2_PIX_FMT_VP9, VIDC_SESSION_TYPE_DEC, 200 },
> + { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_ENC, 675, 10 },
> + { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_ENC, 675, 10 },
> + { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_ENC, 675, 10 },
> + { V4L2_PIX_FMT_MPEG2, VIDC_SESSION_TYPE_DEC, 200, 10 },
> + { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_DEC, 200, 10 },
> + { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_DEC, 200, 10 },
> + { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_DEC, 200, 10 },
> + { V4L2_PIX_FMT_VP9, VIDC_SESSION_TYPE_DEC, 200, 10 },
>  };
>  
>  static const struct venus_resources sdm845_res = {
> diff --git a/drivers/media/platform/qcom/venus/core.h 
> b/drivers/media/platform/qcom/venus/core.h
> index 2ed6496..b964b7c 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -39,6 +39,7 @@ struct codec_freq_data {
>   u32 pixfmt;
>   u32 session_type;
>   unsigned int vpp_freq;
> + unsigned int vsp_freq;

unsigned long?

>  };
>  
>  struct venus_resources {
> diff --git a/drivers/media/platform/qcom/venus/helpers.c 
> b/drivers/media/platform/qcom/venus/helpers.c
> index ef35fd8..634778a 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -379,6 +379,9 @@ static int scale_clocks(struct venus_inst *inst)
>   unsigned int i;
>   int ret;
>  
> + if (inst->state == INST_START)
> + return 0;

This condition is related (probably) to the change in
venus_helper_vb2_buf_queue() but shouldn't it be copied in
scale_clocks_v4 too?

> +
>   mbs_per_sec = load_per_type(core, VIDC_SESSION_TYPE_ENC) +
> load_per_type(core, VIDC_SESSION_TYPE_DEC);
>  
> @@ -418,17 +421,26 @@ static int scale_clocks(struct venus_inst *inst)
>   return ret;
>  }
>  
> -static unsigned long calculate_vpp_freq(struct venus_inst *inst)
> +static unsigned long calculate_inst_freq(struct venus_inst *inst,
> +  unsigned long filled_len)
>  {
> - unsigned long vpp_freq = 0;
> + unsigned long vpp_freq = 0, vsp_freq = 0;
> + u64 fps = inst->fps;
>   u32 mbs_per_sec;
>  
>   mbs_per_sec = load_per_instance(inst);
>   vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
>   /* 21 / 20 is overhead factor */
>   vpp_freq += vpp_freq / 20;
> + vsp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vsp_freq;

this calculation is not used below. Is that intentional?

> +
> + /* 10 / 7 is overhead factor */
> + if (inst->session_type == VIDC_SESSION_TYPE_ENC)
> + vsp_freq = (inst->controls.enc.bitrate * 10) / 7;
> + else
> + vsp_freq = ((fps * filled_len * 8) * 10) / 7;
>  
> - return vpp_freq;
> + return max(vpp_freq, vsp_freq);
>  }
>  
>  static int scale_clocks_v4(struct venus_inst *inst)
> @@ -436,14 +448,30 @@ static int scale_clocks_v4(struct venus_inst *inst)
>   struct venus_core *core = inst->core;
>   const struct freq_tbl *table = core->res->freq_tbl;
>   unsigned int num_rows = core->res->freq_tbl_size;
> -
> + struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
>   struct clk *clk = core->clks[0];
>   struct device *dev = core->dev;
> +

drop this addition of blank line.

>   unsigned int i;
>   unsigned long freq = 0, freq_core0 = 0, freq_core1 = 0;
> + unsigned long filled_len = 0;
> + struct venus_buffer *buf, *n;
> + struct vb2_buffer *vb;
>   int ret;
>  
> - freq =

Re: [PATCH] vfs: move_mount: reject moving kernel internal mounts

2019-07-01 Thread Eric Biggers

On Mon, Jul 01, 2019 at 02:08:48AM +0100, Al Viro wrote:
> 
> Let's reorder that a bit:
> /* The mountpoint must be in our namespace. */
> if (!check_mnt(p))
> goto out;
> 
>   /* The thing moved must be mounted... */
>   if (!is_mounted(old_path->mnt))
>   goto out;
> 
> /* ... and either ours or the root of anon namespace */
>   if (!(attached ? check_mnt(old) : is_anon_ns(ns)))
>   goto out;
> 
> IMO that looks saner and all it costs us is a redundant check
> in attached case.  Objections?

Looks good to me.

- Eric

Re: Adding some trees to linux-next?

2019-07-01 Thread Stephen Rothwell

Hi Darrick,

On Mon, 1 Jul 2019 08:35:52 -0700 "Darrick J. Wong"  
wrote:
>
> Could you add my iomap-for-next and vfs-for-next branches to linux-next,
> please?  They can be found here:
> 
> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#iomap-for-next
> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#vfs-for-next
> 
> I've decided that trying to munge all that through the xfs for-next
> branch is too much insanity and splitting them up will help me prevent
> my head from falling off.

Just out of interest, do you intend to send these directly to Linus, or
via another tree?

-- 
Cheers,
Stephen Rothwell


pgpIfGQPKW_kY.pgp
Description: OpenPGP digital signature

Re: remove asm-generic/ptrace.h v3

On Mon, Jun 24, 2019 at 9:23 AM Thomas Gleixner  wrote:
>
> On Mon, 24 Jun 2019, Christoph Hellwig wrote:
> >
> > asm-generic/ptrace.h is a little weird in that it doesn't actually
> > implement any functionality, but it provided multiple layers of macros
> > that just implement trivial inline functions.  We implement those
> > directly in the few architectures and be off with a much simpler
> > design.
> >
> > I'm not sure which tree is the right place, but may this can go through
> > the asm-generic tree since it removes an asm-generic header?
>
> Makes sense.

Applied and pushed to asm-generic.git/master now, sorry for the delay.

 Arnd

Re: Perf framework : Cluster based counter support

2019-07-01 Thread Mukesh Ojha




On 6/28/2019 10:29 PM, Mark Rutland wrote:

On Fri, Jun 28, 2019 at 10:23:10PM +0530, Mukesh Ojha wrote:

Hi All,

Hi Mukesh,


Is it looks considerable to add cluster based event support to add in
current perf event framework and later in userspace perf to support
such events ?

Could you elaborate on what you mean by "cluster based event"?

I assume you mean something like events for a cluster-affine shared
resource like some level of cache?

If so, there's a standard pattern for supporting such system/uncore
PMUs, see drivers/perf/qcom_l2_pmu.c and friends for examples.



Thanks Mark for pointing it out.
Also What is stopping us in adding cluster based event e.g L2 cache 
hit/miss or some other type raw events  in core framework ?



Thanks.
Mukesh








Thanks,
Mark.

[PATCH] sched/fair: fix imbalance due to CPU affinity

2019-07-01 Thread Vincent Guittot

The load_balance() has a dedicated mecanism to detect when an imbalance
is due to CPU affinity and must be handled at parent level. In this case,
the imbalance field of the parent's sched_group is set.

The description of sg_imbalanced() gives a typical example of two groups
of 4 CPUs each and 4 tasks each with a cpumask covering 1 CPU of the first
group and 3 CPUs of the second group. Something like:

{ 0 1 2 3 } { 4 5 6 7 }
* * * *

But the load_balance fails to fix this UC on my octo cores system
made of 2 clusters of quad cores.

Whereas the load_balance is able to detect that the imbalanced is due to
CPU affinity, it fails to fix it because the imbalance field is cleared
before letting parent level a chance to run. In fact, when the imbalance is
detected, the load_balance reruns without the CPU with pinned tasks. But
there is no other running tasks in the situation described above and
everything looks balanced this time so the imbalance field is immediately
cleared.

The imbalance field should not be cleared if there is no other task to move
when the imbalance is detected.

Signed-off-by: Vincent Guittot 
---

 kernel/sched/fair.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9f9dcb1..bd94171 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9032,9 +9032,10 @@ static int load_balance(int this_cpu, struct rq *this_rq,
 out_balanced:
/*
 * We reach balance although we may have faced some affinity
-* constraints. Clear the imbalance flag if it was set.
+* constraints. Clear the imbalance flag only if other tasks get
+* a chance to move and fix the imbalance.
 */
-   if (sd_parent) {
+   if (sd_parent && !(env.flags & LBF_ALL_PINNED)) {
int *group_imbalance = _parent->groups->sgc->imbalance;
 
if (*group_imbalance)
-- 
2.7.4

Re: [PATCH 2/2] leds: tlc591xx: Use the OF version of the LED registration function

2019-07-01 Thread Dan Murphy


JJ

On 7/1/19 10:26 AM, Jean-Jacques Hiblot wrote:

The driver parses the device-tree to identify which LED should be handled.
Since the information about the device node is known at this time, we can
provide the LED core with it. It may be useful later.

Signed-off-by: Jean-Jacques Hiblot 
---
  drivers/leds/leds-tlc591xx.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-tlc591xx.c b/drivers/leds/leds-tlc591xx.c
index 14e47ff44df5..6a2936c94b73 100644
--- a/drivers/leds/leds-tlc591xx.c
+++ b/drivers/leds/leds-tlc591xx.c
@@ -207,7 +207,7 @@ tlc591xx_probe(struct i2c_client *client,
led->led_no = idx++;
led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
led->ldev.max_brightness = LED_FULL;
-   err = devm_led_classdev_register(dev, >ldev);
+   err = devm_of_led_classdev_register(dev, child, >ldev);
if (err < 0) {
dev_err(dev, "couldn't register LED %s\n",
led->ldev.name);



Reviewed-by: Dan Murphy

Re: [PATCH 1/2] leds: tlc591xx: simplify driver by using the managed led API

2019-07-01 Thread Dan Murphy




On 7/1/19 10:26 AM, Jean-Jacques Hiblot wrote:

Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices

Signed-off-by: Jean-Jacques Hiblot 
---
  drivers/leds/leds-tlc591xx.c | 81 ++--
  1 file changed, 21 insertions(+), 60 deletions(-)

diff --git a/drivers/leds/leds-tlc591xx.c b/drivers/leds/leds-tlc591xx.c
index 59ff088c7d75..14e47ff44df5 100644
--- a/drivers/leds/leds-tlc591xx.c
+++ b/drivers/leds/leds-tlc591xx.c
@@ -128,51 +128,6 @@ tlc591xx_brightness_set(struct led_classdev *led_cdev,
return err;
  }
  
-static void

-tlc591xx_destroy_devices(struct tlc591xx_priv *priv, unsigned int j)
-{
-   int i = j;
-
-   while (--i >= 0) {
-   if (priv->leds[i].active)
-   led_classdev_unregister(>leds[i].ldev);
-   }
-}
-
-static int
-tlc591xx_configure(struct device *dev,
-  struct tlc591xx_priv *priv,
-  const struct tlc591xx *tlc591xx)
-{
-   unsigned int i;
-   int err = 0;
-
-   tlc591xx_set_mode(priv->regmap, MODE2_DIM);
-   for (i = 0; i < TLC591XX_MAX_LEDS; i++) {
-   struct tlc591xx_led *led = >leds[i];
-
-   if (!led->active)
-   continue;
-
-   led->priv = priv;
-   led->led_no = i;
-   led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
-   led->ldev.max_brightness = LED_FULL;
-   err = led_classdev_register(dev, >ldev);
-   if (err < 0) {
-   dev_err(dev, "couldn't register LED %s\n",
-   led->ldev.name);
-   goto exit;
-   }
-   }
-
-   return 0;
-
-exit:
-   tlc591xx_destroy_devices(priv, i);
-   return err;
-}
-
  static const struct regmap_config tlc591xx_regmap = {
.reg_bits = 8,
.val_bits = 8,
@@ -197,7 +152,7 @@ tlc591xx_probe(struct i2c_client *client,
const struct of_device_id *match;
const struct tlc591xx *tlc591xx;
struct tlc591xx_priv *priv;
-   int err, count, reg;
+   int err, count, reg, idx = 0;
  
  	match = of_match_device(of_tlc591xx_leds_match, dev);

if (!match)
@@ -225,7 +180,11 @@ tlc591xx_probe(struct i2c_client *client,
  
  	i2c_set_clientdata(client, priv);
  
+	tlc591xx_set_mode(priv->regmap, MODE2_DIM);

+
for_each_child_of_node(np, child) {
+   struct tlc591xx_led *led;
+
err = of_property_read_u32(child, "reg", );


You should check to make sure "reg" is not out of bounds for the device.

This was handled in the for..loop in the configure routine

Dan


if (err) {
of_node_put(child);
@@ -236,22 +195,25 @@ tlc591xx_probe(struct i2c_client *client,
of_node_put(child);
return -EINVAL;
}
-   priv->leds[reg].active = true;
-   priv->leds[reg].ldev.name =
+   led = >leds[reg];
+
+   led->active = true;
+   led->ldev.name =
of_get_property(child, "label", NULL) ? : child->name;
-   priv->leds[reg].ldev.default_trigger =
+   led->ldev.default_trigger =
of_get_property(child, "linux,default-trigger", NULL);
-   }
-   return tlc591xx_configure(dev, priv, tlc591xx);
-}
-
-static int
-tlc591xx_remove(struct i2c_client *client)
-{
-   struct tlc591xx_priv *priv = i2c_get_clientdata(client);
-
-   tlc591xx_destroy_devices(priv, TLC591XX_MAX_LEDS);
  
+		led->priv = priv;

+   led->led_no = idx++;
+   led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
+   led->ldev.max_brightness = LED_FULL;
+   err = devm_led_classdev_register(dev, >ldev);
+   if (err < 0) {
+   dev_err(dev, "couldn't register LED %s\n",
+   led->ldev.name);
+   return err;
+   }
+   }
return 0;
  }
  
@@ -268,7 +230,6 @@ static struct i2c_driver tlc591xx_driver = {

.of_match_table = of_match_ptr(of_tlc591xx_leds_match),
},
.probe = tlc591xx_probe,
-   .remove = tlc591xx_remove,
.id_table = tlc591xx_id,
  };

Adding some trees to linux-next?

2019-07-01 Thread Darrick J. Wong

Hi Stephen,

Could you add my iomap-for-next and vfs-for-next branches to linux-next,
please?  They can be found here:

git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#iomap-for-next
git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git#vfs-for-next

I've decided that trying to munge all that through the xfs for-next
branch is too much insanity and splitting them up will help me prevent
my head from falling off.

--Darrick

Re: [PATCH v2 1/2] ASoC: tas5720.c: cleanup variant management

2019-07-01 Thread Nikolaus Voss


On Mon, 1 Jul 2019, Andrew F. Davis wrote:

On 7/1/19 9:42 AM, Nikolaus Voss wrote:

Replace enum tas572x_type with struct tas5720_variant which aggregates
variant specific stuff and can be directly referenced from an id table.

Signed-off-by: Nikolaus Voss 
---
 sound/soc/codecs/tas5720.c | 98 +-
 1 file changed, 33 insertions(+), 65 deletions(-)

diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index 37fab8f22800..b2e897f094b4 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -28,9 +28,10 @@
 /* Define how often to check (and clear) the fault status register (in ms) */
 #define TAS5720_FAULT_CHECK_INTERVAL   200

-enum tas572x_type {
-   TAS5720,
-   TAS5722,
+struct tas5720_variant {
+   const int device_id;
+   const struct regmap_config *reg_config;
+   const struct snd_soc_component_driver *comp_drv;
 };

 static const char * const tas5720_supply_names[] = {
@@ -44,7 +45,7 @@ struct tas5720_data {
struct snd_soc_component *component;
struct regmap *regmap;
struct i2c_client *tas5720_client;
-   enum tas572x_type devtype;
+   const struct tas5720_variant *variant;


Why add a new struct? Actually I don't see the need for this patch at
all, the commit message only explains the 'what' not the 'why'. We can
and do already build this info from the tas572x_type.


As the commit message says, the purpose is to aggregate the variant 
specifics and make it accessible via one pointer. This is a standard 
approach for of/acpi_device_id tables and thus makes the code simpler and 
improves readability. This is a maintenance patch to prepare using the 
device match API in a proper way.




Also below are several functional changes, the cover letter says this is
not a functional change, yet the driver behaves differently now.


Can you be a little bit more specific? The code should behave exactly as 
before.


Niko



Andrew


struct regulator_bulk_data supplies[TAS5720_NUM_SUPPLIES];
struct delayed_work fault_check_work;
unsigned int last_fault;
@@ -179,17 +180,13 @@ static int tas5720_set_dai_tdm_slot(struct snd_soc_dai 
*dai,
goto error_snd_soc_component_update_bits;

/* Configure TDM slot width. This is only applicable to TAS5722. */
-   switch (tas5720->devtype) {
-   case TAS5722:
+   if (tas5720->variant->device_id == TAS5722_DEVICE_ID) {
ret = snd_soc_component_update_bits(component, 
TAS5722_DIGITAL_CTRL2_REG,
TAS5722_TDM_SLOT_16B,
slot_width == 16 ?
TAS5722_TDM_SLOT_16B : 0);
if (ret < 0)
goto error_snd_soc_component_update_bits;
-   break;
-   default:
-   break;
}

return 0;
@@ -277,7 +274,7 @@ static void tas5720_fault_check_work(struct work_struct 
*work)
 static int tas5720_codec_probe(struct snd_soc_component *component)
 {
struct tas5720_data *tas5720 = snd_soc_component_get_drvdata(component);
-   unsigned int device_id, expected_device_id;
+   unsigned int device_id;
int ret;

tas5720->component = component;
@@ -301,21 +298,9 @@ static int tas5720_codec_probe(struct snd_soc_component 
*component)
goto probe_fail;
}

-   switch (tas5720->devtype) {
-   case TAS5720:
-   expected_device_id = TAS5720_DEVICE_ID;
-   break;
-   case TAS5722:
-   expected_device_id = TAS5722_DEVICE_ID;
-   break;
-   default:
-   dev_err(component->dev, "unexpected private driver data\n");
-   return -EINVAL;
-   }
-
-   if (device_id != expected_device_id)
+   if (device_id != tas5720->variant->device_id)
dev_warn(component->dev, "wrong device ID. expected: %u read: 
%u\n",
-expected_device_id, device_id);
+tas5720->variant->device_id, device_id);

/* Set device to mute */
ret = snd_soc_component_update_bits(component, 
TAS5720_DIGITAL_CTRL2_REG,
@@ -637,7 +622,6 @@ static int tas5720_probe(struct i2c_client *client,
 {
struct device *dev = >dev;
struct tas5720_data *data;
-   const struct regmap_config *regmap_config;
int ret;
int i;

@@ -646,20 +630,10 @@ static int tas5720_probe(struct i2c_client *client,
return -ENOMEM;

data->tas5720_client = client;
-   data->devtype = id->driver_data;

-   switch (id->driver_data) {
-   case TAS5720:
-   regmap_config = _regmap_config;
-   break;
-   case TAS5722:
-   regmap_config = _regmap_config;
-   break;
-   default:
-   dev_err(dev, "unexpected

NO_HZ_IDLE causes consistently low cpu "iowait" time (and higher cpu "idle" time)

2019-07-01 Thread Alan Jenkins

I tried running a simple test:

dd if=testfile iflag=direct bs=1M of=/dev/null

With my default settings, `vmstat 10` shows something like 85% idle time
to 15% iowait time. I have 4 CPUs, so this is much less than one CPU
worth of iowait time.

If I boot with "nohz=off", I see idle time fall to 75% or below, and
iowait rise to about 25%, equivalent to one CPU. That is what I had
originally expected.

(I can also see my expected numbers, if I disable *all* C-states and
force polling using `pm_qos_resume_latency_us` in sysfs).

The numbers above are from a kernel somewhere around v5.2-rc5. I saw
the "wrong" results on some previous kernels as well. I just now
realized the link to NO_HZ_IDLE.[1]

[1]
https://unix.stackexchange.com/questions/517757/my-basic-assumption-about-system-iowait-does-not-hold/527836#527836

I did not find any information about this high level of inaccuracy. Can
anyone explain, is this behaviour expected?

I found several patches that mentioned "iowait" and NO_HZ_IDLE. But if
they described this problem, it was not clear to me.

I thought this might also be affecting the "IO pressure" values from the
new "pressure stall information"... but I am too confused already, so I
am only asking about iowait at the moment :-).[2]

[2]
https://unix.stackexchange.com/questions/527342/why-does-the-new-linux-pressure-stall-information-for-io-not-show-as-100/527347#527347

I have seen the disclaimers for iowait in
Documentation/filesystems/proc.txt, and the derived man page.
Technically, the third disclaimer might cover anything. But I was
optimistic; I hoped it was talking about relatively small glitches :-).
I didn't think it would mean a large systematic undercounting, which
applied to the vast majority of current systems (which are not tuned for
realtime use).

- iowait: In a word, iowait stands for waiting for I/O to complete. But there
are several problems:
1. Cpu will not wait for I/O to complete, iowait is the time that a task is
waiting for I/O to complete. When cpu goes into idle state for
outstanding task io, another task will be scheduled on this CPU.
2. In a multi-core CPU, the task waiting for I/O to complete is not running
on any CPU, so the iowait of each CPU is difficult to calculate.
3. The value of iowait field in /proc/stat will decrease in certain
conditions|

Thanks for all the power-saving code
Alan

[PATCH 1/2] drivers: qcom: rpmh-rsc: simplify TCS locking

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

tcs->lock was introduced to serialize access with in TCS group. But
even without tcs->lock, drv->lock is serving the same purpose. So
use a single drv->lock.

Other optimizations include -
 - Remove locking around clear_bit() in IRQ handler. clear_bit() is
   atomic.
 - Remove redundant read of TCS registers.
 - Use spin_lock instead of _irq variants as the locks are not held
   in interrupt context.

Fixes: 658628 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM
SoCs")
Signed-off-by: Raju P.L.S.S.S.N 
Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/rpmh-internal.h |  2 --
 drivers/soc/qcom/rpmh-rsc.c  | 37 +++-
 drivers/soc/qcom/rpmh.c  | 20 +++--
 3 files changed, 21 insertions(+), 38 deletions(-)

diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h
index a767991c..969d5030860e 100644
--- a/drivers/soc/qcom/rpmh-internal.h
+++ b/drivers/soc/qcom/rpmh-internal.h
@@ -28,7 +28,6 @@ struct rsc_drv;
  * @offset:start of the TCS group relative to the TCSes in the RSC
  * @num_tcs:   number of TCSes in this type
  * @ncpt:  number of commands in each TCS
- * @lock:  lock for synchronizing this TCS writes
  * @req:   requests that are sent from the TCS
  * @cmd_cache: flattened cache of cmds in sleep/wake TCS
  * @slots: indicates which of @cmd_addr are occupied
@@ -40,7 +39,6 @@ struct tcs_group {
u32 offset;
int num_tcs;
int ncpt;
-   spinlock_t lock;
const struct tcs_request *req[MAX_TCS_PER_TYPE];
u32 *cmd_cache;
DECLARE_BITMAP(slots, MAX_TCS_SLOTS);
diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index e278fc11fe5c..92461311aef3 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -93,8 +93,7 @@ static void write_tcs_reg_sync(struct rsc_drv *drv, int reg, 
int tcs_id,
 
 static bool tcs_is_free(struct rsc_drv *drv, int tcs_id)
 {
-   return !test_bit(tcs_id, drv->tcs_in_use) &&
-  read_tcs_reg(drv, RSC_DRV_STATUS, tcs_id, 0);
+   return !test_bit(tcs_id, drv->tcs_in_use);
 }
 
 static struct tcs_group *get_tcs_of_type(struct rsc_drv *drv, int type)
@@ -104,29 +103,28 @@ static struct tcs_group *get_tcs_of_type(struct rsc_drv 
*drv, int type)
 
 static int tcs_invalidate(struct rsc_drv *drv, int type)
 {
-   int m;
+   int m, ret = 0;
struct tcs_group *tcs;
 
tcs = get_tcs_of_type(drv, type);
 
-   spin_lock(>lock);
-   if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS)) {
-   spin_unlock(>lock);
-   return 0;
-   }
+   spin_lock(>lock);
+   if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS))
+   goto done;
 
for (m = tcs->offset; m < tcs->offset + tcs->num_tcs; m++) {
if (!tcs_is_free(drv, m)) {
-   spin_unlock(>lock);
-   return -EAGAIN;
+   ret = -EAGAIN;
+   goto done;
}
write_tcs_reg_sync(drv, RSC_DRV_CMD_ENABLE, m, 0);
write_tcs_reg_sync(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, m, 0);
}
bitmap_zero(tcs->slots, MAX_TCS_SLOTS);
-   spin_unlock(>lock);
 
-   return 0;
+done:
+   spin_unlock(>lock);
+   return ret;
 }
 
 /**
@@ -242,9 +240,7 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
write_tcs_reg(drv, RSC_DRV_CMD_ENABLE, i, 0);
write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, i, 0);
write_tcs_reg(drv, RSC_DRV_IRQ_CLEAR, 0, BIT(i));
-   spin_lock(>lock);
clear_bit(i, drv->tcs_in_use);
-   spin_unlock(>lock);
if (req)
rpmh_tx_done(req, err);
}
@@ -349,14 +345,12 @@ static int tcs_write(struct rsc_drv *drv, const struct 
tcs_request *msg)
 {
struct tcs_group *tcs;
int tcs_id;
-   unsigned long flags;
int ret;
 
tcs = get_tcs_for_msg(drv, msg);
if (IS_ERR(tcs))
return PTR_ERR(tcs);
 
-   spin_lock_irqsave(>lock, flags);
spin_lock(>lock);
/*
 * The h/w does not like if we send a request to the same address,
@@ -364,26 +358,23 @@ static int tcs_write(struct rsc_drv *drv, const struct 
tcs_request *msg)
 */
ret = check_for_req_inflight(drv, tcs, msg);
if (ret) {
-   spin_unlock(>lock);
goto done_write;
}
 
tcs_id = find_free_tcs(tcs);
if (tcs_id < 0) {
ret = tcs_id;
-   spin_unlock(>lock);
goto done_write;
}
 
tcs->req[tcs_id - tcs->offset] = msg;
set_bit(tcs_id, drv->tcs_in_use);
-   spin_unlock(>lock);
 
__tcs_buffer_write(drv, tcs_id, 0, msg);
__tcs_trigger(drv, tcs_id);
 
 done_write:
-   spin_unlock_irqrestore(>lock, flags);

[PATCH 2/2] drivers: qcom: rpmh-rsc: fix read back of trigger register

When triggering a TCS to send its contents, reading back the trigger
value may return an incorrect value. That is because, writing the
trigger may raise an interrupt which could be handled immediately and
the trigger value could be reset in the interrupt handler. By doing a
read back we may end up spinning waiting for the value we wrote.

Fixes: 658628 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM
SoCs")
Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/rpmh-rsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 92461311aef3..2fc2fa879480 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -300,7 +300,7 @@ static void __tcs_trigger(struct rsc_drv *drv, int tcs_id)
enable = TCS_AMC_MODE_ENABLE;
write_tcs_reg_sync(drv, RSC_DRV_CONTROL, tcs_id, enable);
enable |= TCS_AMC_MODE_TRIGGER;
-   write_tcs_reg_sync(drv, RSC_DRV_CONTROL, tcs_id, enable);
+   write_tcs_reg(drv, RSC_DRV_CONTROL, tcs_id, enable);
 }
 
 static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] net: usb: asix: init MAC address buffers

2019-07-01 Thread Dan Williams

On Mon, 2019-07-01 at 06:45 +0700, Phong Tran wrote:
> This is for fixing bug KMSAN: uninit-value in ax88772_bind
> 
> Tested by
> https://groups.google.com/d/msg/syzkaller-bugs/aFQurGotng4/cFe9nxMCCwAJ
> 
> Reported-by: syzbot+8a3fc6674bbc3978e...@syzkaller.appspotmail.com
> 
> syzbot found the following crash on:
> 
> HEAD commit:f75e4cfe kmsan: use kmsan_handle_urb() in urb.c
> git tree:   kmsan
> console output: 
> https://syzkaller.appspot.com/x/log.txt?x=136d720ea0
> kernel config:
> https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=8a3fc6674bbc3978ed4e
> compiler:   clang version 9.0.0 (/home/glider/llvm/clang
> 06d00afa61eef8f7f501ebdb4e8612ea43ec2d78)
> syz repro:
> https://syzkaller.appspot.com/x/repro.syz?x=12788316a0
> C reproducer:   
> https://syzkaller.appspot.com/x/repro.c?x=120359aaa0
> 
> ==
> BUG: KMSAN: uninit-value in is_valid_ether_addr
> include/linux/etherdevice.h:200 [inline]
> BUG: KMSAN: uninit-value in asix_set_netdev_dev_addr
> drivers/net/usb/asix_devices.c:73 [inline]
> BUG: KMSAN: uninit-value in ax88772_bind+0x93d/0x11e0
> drivers/net/usb/asix_devices.c:724
> CPU: 0 PID: 3348 Comm: kworker/0:2 Not tainted 5.1.0+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS
> Google 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>   __dump_stack lib/dump_stack.c:77 [inline]
>   dump_stack+0x191/0x1f0 lib/dump_stack.c:113
>   kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
>   __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
>   is_valid_ether_addr include/linux/etherdevice.h:200 [inline]
>   asix_set_netdev_dev_addr drivers/net/usb/asix_devices.c:73 [inline]
>   ax88772_bind+0x93d/0x11e0 drivers/net/usb/asix_devices.c:724
>   usbnet_probe+0x10f5/0x3940 drivers/net/usb/usbnet.c:1728
>   usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361
>   really_probe+0xdae/0x1d80 drivers/base/dd.c:513
>   driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
>   __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
>   bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
>   __device_attach+0x454/0x730 drivers/base/dd.c:844
>   device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
>   bus_probe_device+0x137/0x390 drivers/base/bus.c:514
>   device_add+0x288d/0x30e0 drivers/base/core.c:2106
>   usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027
>   generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210
>   usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266
>   really_probe+0xdae/0x1d80 drivers/base/dd.c:513
>   driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
>   __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
>   bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
>   __device_attach+0x454/0x730 drivers/base/dd.c:844
>   device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
>   bus_probe_device+0x137/0x390 drivers/base/bus.c:514
>   device_add+0x288d/0x30e0 drivers/base/core.c:2106
>   usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534
>   hub_port_connect drivers/usb/core/hub.c:5089 [inline]
>   hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
>   port_event drivers/usb/core/hub.c:5350 [inline]
>   hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432
>   process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269
>   process_scheduled_works kernel/workqueue.c:2331 [inline]
>   worker_thread+0x189c/0x2460 kernel/workqueue.c:2417
>   kthread+0x4b5/0x4f0 kernel/kthread.c:254
>   ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355
> 
> Signed-off-by: Phong Tran 
> ---
>  drivers/net/usb/asix_devices.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/usb/asix_devices.c
> b/drivers/net/usb/asix_devices.c
> index c9bc96310ed4..f514d19316b1 100644
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -230,6 +230,7 @@ static int ax88172_bind(struct usbnet *dev,
> struct usb_interface *intf)
>   int i;
>   unsigned long gpio_bits = dev->driver_info->data;
>  
> + memset(buf, 0, sizeof(buf));

For array variables defined in the function itself, isn't this usually
done with:

 int ret = 0;
-u8 buf[ETH_ALEN];
+u8 buf[ETH_ALEN] = {0};
 int i;
 unsigned long gpio_bits = dev->driver_info->data;

eg make the compiler do it (though maybe it's smart enough to elide the
memset, I don't know). See drivers/net/ethernet/intel/igb/e1000_mac.c
for an example.

Dan

>   usbnet_get_endpoints(dev,intf);
>  
>   /* Toggle the GPIOs in a manufacturer/model specific way */
> @@ -681,6 +682,7 @@ static int ax88772_bind(struct usbnet *dev,
> struct usb_interface *intf)
>   u32 phyid;
>   struct asix_common_private *priv;
>  
> + memset(buf, 0, sizeof(buf));
>   usbnet_get_endpoints(dev, intf);
>  
>   /* Maybe the boot loader passed the MAC

Re: [PATCH] media: venus: Update to bitrate based clock scaling

2019-07-01 Thread Stanimir Varbanov

Hi Aniket,

On 6/26/19 11:23 AM, Aniket Masule wrote:
> This patch introduces bitrate based clock scaling. Also, clock scaling is now
> triggered before buffer being queued to the device. This checks for frequency
> requirement throughout the session and updates clock with correct frequency 
> only
> if requirement is changed.
> 
> Aniket Masule (1):
>   media: venus: Update to bitrate based clock scaling

You don't need cover letter for one patch. Also, please include this
patch in "venus: Update clock scaling and core selection" series.

> 
>  drivers/media/platform/qcom/venus/core.c| 16 +--
>  drivers/media/platform/qcom/venus/core.h|  1 +
>  drivers/media/platform/qcom/venus/helpers.c | 43 
> +
>  3 files changed, 47 insertions(+), 13 deletions(-)
> 

-- 
regards,
Stan

[PATCH 1/4] net: dsa: Change DT bindings for Vitesse VSC73xx switches

This commit document changes after split vsc73xx driver into core and
spi part. The change of DT bindings is required for support the same
vsc73xx chip, which need PI bus to communicate with CPU. It also
introduce how to use vsc73xx platform driver.

Signed-off-by: Pawel Dembicki 
---
 .../bindings/net/dsa/vitesse,vsc73xx.txt  | 74 ---
 1 file changed, 64 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt 
b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
index ed4710c40641..c6a4cd85891c 100644
--- a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
+++ b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
@@ -2,8 +2,8 @@ Vitesse VSC73xx Switches
 
 
 This defines device tree bindings for the Vitesse VSC73xx switch chips.
-The Vitesse company has been acquired by Microsemi and Microsemi in turn
-acquired by Microchip but retains this vendor branding.
+The Vitesse company has been acquired by Microsemi and Microsemi has
+been acquired Microchip but retains this vendor branding.
 
 The currently supported switch chips are:
 Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
@@ -11,16 +11,26 @@ Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet 
Switch
 Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
 Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
 
-The device tree node is an SPI device so it must reside inside a SPI bus
-device tree node, see spi/spi-bus.txt
+This switch could have two different management interface.
+
+If SPI interface is used, the device tree node is an SPI device so it must
+reside inside a SPI bus device tree node, see spi/spi-bus.txt
+
+If Platform driver is used, the device tree node is an platform device so it
+must reside inside a platform bus device tree node.
 
 Required properties:
 
-- compatible: must be exactly one of:
-   "vitesse,vsc7385"
-   "vitesse,vsc7388"
-   "vitesse,vsc7395"
-   "vitesse,vsc7398"
+- compatible (SPI): must be exactly one of:
+   "vitesse,vsc7385-spi"
+   "vitesse,vsc7388-spi"
+   "vitesse,vsc7395-spi"
+   "vitesse,vsc7398-spi"
+- compatible (Platform): must be exactly one of:
+   "vitesse,vsc7385-platform"
+   "vitesse,vsc7388-platform"
+   "vitesse,vsc7395-platform"
+   "vitesse,vsc7398-platform"
 - gpio-controller: indicates that this switch is also a GPIO controller,
   see gpio/gpio.txt
 - #gpio-cells: this must be set to <2> and indicates that we are a twocell
@@ -38,8 +48,9 @@ and subnodes of DSA switches.
 
 Examples:
 
+SPI:
 switch@0 {
-   compatible = "vitesse,vsc7395";
+   compatible = "vitesse,vsc7395-spi";
reg = <0>;
/* Specified for 2.5 MHz or below */
spi-max-frequency = <250>;
@@ -79,3 +90,46 @@ switch@0 {
};
};
 };
+
+Platform:
+switch@2,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "vitesse,vsc7385-platform";
+   reg = <0x2 0x0 0x2>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan1";
+   };
+   port@1 {
+   reg = <1>;
+   label = "lan2";
+   };
+   port@2 {
+   reg = <2>;
+   label = "lan3";
+   };
+   port@3 {
+   reg = <3>;
+   label = "lan4";
+   };
+   vsc: port@6 {
+   reg = <6>;
+   label = "cpu";
+   ethernet = <>;
+   phy-mode = "rgmii";
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   pause;
+   };
+   };
+   };
+
+};
-- 
2.20.1

[PATCH 4/4] net: dsa: vsc73xx: Assert reset if iCPU is enabled

Driver allow to use devices with disabled iCPU only.

Some devices have pre-initialised iCPU by bootloader.
That state make switch unmanaged. This patch force reset
if device is in unmanaged state. In the result chip lost
internal firmware from RAM and it can be managed.

Signed-off-by: Pawel Dembicki 
---
 drivers/net/dsa/vitesse-vsc73xx-core.c | 36 --
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c 
b/drivers/net/dsa/vitesse-vsc73xx-core.c
index 9975446cdc66..5cdf91849b5d 100644
--- a/drivers/net/dsa/vitesse-vsc73xx-core.c
+++ b/drivers/net/dsa/vitesse-vsc73xx-core.c
@@ -405,22 +405,8 @@ static int vsc73xx_detect(struct vsc73xx *vsc)
}
 
if (val == 0x) {
-   dev_info(vsc->dev, "chip seems dead, assert reset\n");
-   gpiod_set_value_cansleep(vsc->reset, 1);
-   /* Reset pulse should be 20ns minimum, according to datasheet
-* table 245, so 10us should be fine
-*/
-   usleep_range(10, 100);
-   gpiod_set_value_cansleep(vsc->reset, 0);
-   /* Wait 20ms according to datasheet table 245 */
-   msleep(20);
-
-   ret = vsc->ops->read(vsc, VSC73XX_BLOCK_SYSTEM, 0,
-  VSC73XX_ICPU_MBOX_VAL, );
-   if (val == 0x) {
-   dev_err(vsc->dev, "seems not to help, giving up\n");
-   return -ENODEV;
-   }
+   dev_info(vsc->dev, "chip seems dead.\n");
+   return -EAGAIN;
}
 
ret = vsc->ops->read(vsc, VSC73XX_BLOCK_SYSTEM, 0,
@@ -471,9 +457,8 @@ static int vsc73xx_detect(struct vsc73xx *vsc)
}
if (icpu_si_boot_en && !icpu_pi_en) {
dev_err(vsc->dev,
-   "iCPU enabled boots from SI, no external memory\n");
-   dev_err(vsc->dev, "no idea how to deal with this\n");
-   return -ENODEV;
+   "iCPU enabled boots from PI/SI, no external memory\n");
+   return -EAGAIN;
}
if (!icpu_si_boot_en && icpu_pi_en) {
dev_err(vsc->dev,
@@ -1147,6 +1132,19 @@ int vsc73xx_probe(struct vsc73xx *vsc)
msleep(20);
 
ret = vsc73xx_detect(vsc);
+   if (ret == -EAGAIN) {
+   dev_err(vsc->dev,
+   "Chip seams to be out of control. Assert reset and try 
again.\n");
+   gpiod_set_value_cansleep(vsc->reset, 1);
+   /* Reset pulse should be 20ns minimum, according to datasheet
+* table 245, so 10us should be fine
+*/
+   usleep_range(10, 100);
+   gpiod_set_value_cansleep(vsc->reset, 0);
+   /* Wait 20ms according to datasheet table 245 */
+   msleep(20);
+   ret = vsc73xx_detect(vsc);
+   }
if (ret) {
dev_err(vsc->dev, "no chip found (%d)\n", ret);
return -ENODEV;
-- 
2.20.1

[PATCH 2/4] net: dsa: vsc73xx: Split vsc73xx driver

This driver (currently) only takes control of the switch chip over
SPI and configures it to route packages around when connected to a
CPU port. But Vitesse chip support also parallel interface.

This patch split driver into two parts: core and spi. It is required
for add support to another managing interface.

Tested-by: Linus Walleij 
Signed-off-by: Pawel Dembicki 
---
 arch/arm/boot/dts/gemini-sl93512r.dts |   2 +-
 arch/arm/boot/dts/gemini-sq201.dts|   2 +-
 drivers/net/dsa/Kconfig   |  11 +-
 drivers/net/dsa/Makefile  |   3 +-
 ...tesse-vsc73xx.c => vitesse-vsc73xx-core.c} | 265 --
 drivers/net/dsa/vitesse-vsc73xx-spi.c | 201 +
 drivers/net/dsa/vitesse-vsc73xx.h |  30 ++
 7 files changed, 297 insertions(+), 217 deletions(-)
 rename drivers/net/dsa/{vitesse-vsc73xx.c => vitesse-vsc73xx-core.c} (85%)
 create mode 100644 drivers/net/dsa/vitesse-vsc73xx-spi.c
 create mode 100644 drivers/net/dsa/vitesse-vsc73xx.h

diff --git a/arch/arm/boot/dts/gemini-sl93512r.dts 
b/arch/arm/boot/dts/gemini-sl93512r.dts
index 2bb953440793..87f5340387a4 100644
--- a/arch/arm/boot/dts/gemini-sl93512r.dts
+++ b/arch/arm/boot/dts/gemini-sl93512r.dts
@@ -94,7 +94,7 @@
num-chipselects = <1>;
 
switch@0 {
-   compatible = "vitesse,vsc7385";
+   compatible = "vitesse,vsc7385-spi";
reg = <0>;
/* Specified for 2.5 MHz or below */
spi-max-frequency = <250>;
diff --git a/arch/arm/boot/dts/gemini-sq201.dts 
b/arch/arm/boot/dts/gemini-sq201.dts
index 239dfacaae4d..4fcb20f87ba0 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -79,7 +79,7 @@
num-chipselects = <1>;
 
switch@0 {
-   compatible = "vitesse,vsc7395";
+   compatible = "vitesse,vsc7395-spi";
reg = <0>;
/* Specified for 2.5 MHz or below */
spi-max-frequency = <250>;
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index b91e78e3598f..4ab2aa09e2e4 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -99,8 +99,8 @@ config NET_DSA_SMSC_LAN9303_MDIO
  for MDIO managed mode.
 
 config NET_DSA_VITESSE_VSC73XX
-   tristate "Vitesse VSC7385/7388/7395/7398 support"
-   depends on OF && SPI
+   tristate
+   depends on OF
depends on NET_DSA
select FIXED_PHY
select VITESSE_PHY
@@ -109,4 +109,11 @@ config NET_DSA_VITESSE_VSC73XX
  This enables support for the Vitesse VSC7385, VSC7388,
  VSC7395 and VSC7398 SparX integrated ethernet switches.
 
+config NET_DSA_VITESSE_VSC73XX_SPI
+   tristate "Vitesse VSC7385/7388/7395/7398 SPI mode support"
+   depends on SPI
+   select NET_DSA_VITESSE_VSC73XX
+   ---help---
+ This enables support for the Vitesse VSC7385, VSC7388, VSC7395
+ and VSC7398 SparX integrated ethernet switches in SPI managed mode.
 endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index fefb6aaa82ba..117bf78be211 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -14,7 +14,8 @@ realtek-objs  := realtek-smi.o rtl8366.o 
rtl8366rb.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
-obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX) += vitesse-vsc73xx.o
+obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX) += vitesse-vsc73xx-core.o
+obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX_SPI) += vitesse-vsc73xx-spi.o
 obj-y  += b53/
 obj-y  += microchip/
 obj-y  += mv88e6xxx/
diff --git a/drivers/net/dsa/vitesse-vsc73xx.c 
b/drivers/net/dsa/vitesse-vsc73xx-core.c
similarity index 85%
rename from drivers/net/dsa/vitesse-vsc73xx.c
rename to drivers/net/dsa/vitesse-vsc73xx-core.c
index d4780610ea8a..9975446cdc66 100644
--- a/drivers/net/dsa/vitesse-vsc73xx.c
+++ b/drivers/net/dsa/vitesse-vsc73xx-core.c
@@ -10,10 +10,6 @@
  * handling the switch in a memory-mapped manner by connecting to that external
  * CPU's memory bus.
  *
- * This driver (currently) only takes control of the switch chip over SPI and
- * configures it to route packages around when connected to a CPU port. The
- * chip has embedded PHYs and VLAN support so we model it using DSA.
- *
  * Copyright (C) 2018 Linus Wallej 
  * Includes portions of code from the firmware uploader by:
  * Copyright (C) 2009 Gabor Juhos 
@@ -24,8 +20,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -34,6 +28,8 @@
 #include 
 #include 
 
+#include "vitesse-vsc73xx.h"
+
 #define VSC73XX_BLOCK_MAC  0x1 /* Subblocks 0-4, 6 (CPU

[PATCH 3/4] net: dsa: vsc73xx: add support for parallel mode

This patch add platform part of vsc73xx driver.
It allows to use chip connected by PI interface.

Signed-off-by: Pawel Dembicki 
---
 drivers/net/dsa/Kconfig|   8 +
 drivers/net/dsa/Makefile   |   1 +
 drivers/net/dsa/vitesse-vsc73xx-platform.c | 166 +
 3 files changed, 175 insertions(+)
 create mode 100644 drivers/net/dsa/vitesse-vsc73xx-platform.c

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 4ab2aa09e2e4..80965808949d 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -116,4 +116,12 @@ config NET_DSA_VITESSE_VSC73XX_SPI
---help---
  This enables support for the Vitesse VSC7385, VSC7388, VSC7395
  and VSC7398 SparX integrated ethernet switches in SPI managed mode.
+
+config NET_DSA_VITESSE_VSC73XX_PLATFORM
+   tristate "Vitesse VSC7385/7388/7395/7398 Platform mode support"
+   depends on HAS_IOMEM
+   select NET_DSA_VITESSE_VSC73XX
+   ---help---
+ This enables support for the Vitesse VSC7385, VSC7388, VSC7395
+ and VSC7398 SparX integrated ethernet switches in Platform managed 
mode.
 endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 117bf78be211..d5e4c668ac03 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
 obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX) += vitesse-vsc73xx-core.o
+obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX_PLATFORM) += vitesse-vsc73xx-platform.o
 obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX_SPI) += vitesse-vsc73xx-spi.o
 obj-y  += b53/
 obj-y  += microchip/
diff --git a/drivers/net/dsa/vitesse-vsc73xx-platform.c 
b/drivers/net/dsa/vitesse-vsc73xx-platform.c
new file mode 100644
index ..b2e5da0ffde3
--- /dev/null
+++ b/drivers/net/dsa/vitesse-vsc73xx-platform.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/* DSA driver for:
+ * Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
+ * Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
+ * Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
+ * Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
+ *
+ * This driver takes control of the switch chip over Platform and
+ * configures it to route packages around when connected to a CPU port.
+ *
+ * Copyright (C) 2019 pawel Dembicki 
+ * Based on vitesse-vsc-spi.c by:
+ * Copyright (C) 2018 Linus Wallej 
+ * Includes portions of code from the firmware uploader by:
+ * Copyright (C) 2009 Gabor Juhos 
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "vitesse-vsc73xx.h"
+
+#define VSC73XX_CMD_PLATFORM_BLOCK_SHIFT   14
+#define VSC73XX_CMD_PLATFORM_BLOCK_MASK0x7
+#define VSC73XX_CMD_PLATFORM_SUBBLOCK_SHIFT10
+#define VSC73XX_CMD_PLATFORM_SUBBLOCK_MASK 0xf
+#define VSC73XX_CMD_PLATFORM_REGISTER_SHIFT2
+
+/**
+ * struct vsc73xx_platform - VSC73xx Platform state container
+ */
+struct vsc73xx_platform {
+   struct platform_device *pdev;
+   void __iomem *base_addr;
+   struct vsc73xx vsc;
+};
+
+static const struct vsc73xx_ops vsc73xx_platform_ops;
+
+static u32 vsc73xx_make_addr(u8 block, u8 subblock, u8 reg)
+{
+   u32 ret;
+
+   ret = (block & VSC73XX_CMD_PLATFORM_BLOCK_MASK)
+   << VSC73XX_CMD_PLATFORM_BLOCK_SHIFT;
+   ret |= (subblock & VSC73XX_CMD_PLATFORM_SUBBLOCK_MASK)
+   << VSC73XX_CMD_PLATFORM_SUBBLOCK_SHIFT;
+   ret |= reg << VSC73XX_CMD_PLATFORM_REGISTER_SHIFT;
+
+   return ret;
+}
+
+static int vsc73xx_platform_read(struct vsc73xx *vsc, u8 block, u8 subblock,
+u8 reg, u32 *val)
+{
+   struct vsc73xx_platform *vsc_platform = vsc->priv;
+   u32 offset;
+
+   if (!vsc73xx_is_addr_valid(block, subblock))
+   return -EINVAL;
+
+   offset = vsc73xx_make_addr(block, subblock, reg);
+
+   mutex_lock(>lock);
+   *val = ioread32be(vsc_platform->base_addr + offset);
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static int vsc73xx_platform_write(struct vsc73xx *vsc, u8 block, u8 subblock,
+ u8 reg, u32 val)
+{
+   struct vsc73xx_platform *vsc_platform = vsc->priv;
+   u32 offset;
+
+   if (!vsc73xx_is_addr_valid(block, subblock))
+   return -EINVAL;
+
+   offset = vsc73xx_make_addr(block, subblock, reg);
+
+   mutex_lock(>lock);
+   iowrite32be(val, vsc_platform->base_addr + offset);
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static int vsc73xx_platform_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct vsc73xx_platform *vsc_platform;
+   struct resource *res = NULL;
+

[PATCH] md/raid: Replace a seq_printf() call by seq_putc() in three functions

2019-07-01 Thread Markus Elfring

From: Markus Elfring 
Date: Mon, 1 Jul 2019 17:10:13 +0200

A single character (depending on a condition check) should be put
into a sequence. Thus use the corresponding function “seq_putc”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/md/raid1.c  | 4 ++--
 drivers/md/raid10.c | 3 ++-
 drivers/md/raid5.c  | 3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 34e26834ad28..769d79a1d2cf 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1597,7 +1597,7 @@ static void raid1_status(struct seq_file *seq, struct 
mddev *mddev)
rcu_read_lock();
for (i = 0; i < conf->raid_disks; i++) {
struct md_rdev *rdev = rcu_dereference(conf->mirrors[i].rdev);
-   seq_printf(seq, "%s",
-  rdev && test_bit(In_sync, >flags) ? "U" : "_");
+   seq_putc(seq,
+rdev && test_bit(In_sync, >flags) ? 'U' : '_');
}
rcu_read_unlock();
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 8a1354a08a1a..4e7da5dcbf86 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1572,6 +1572,7 @@ static void raid10_status(struct seq_file *seq, struct 
mddev *mddev)
rcu_read_lock();
for (i = 0; i < conf->geo.raid_disks; i++) {
struct md_rdev *rdev = rcu_dereference(conf->mirrors[i].rdev);
-   seq_printf(seq, "%s", rdev && test_bit(In_sync, >flags) ? 
"U" : "_");
+   seq_putc(seq,
+rdev && test_bit(In_sync, >flags) ? 'U' : '_');
}
rcu_read_unlock();
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 3de4e13bde98..4b0e93869801 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7510,6 +7510,7 @@ static void raid5_status(struct seq_file *seq, struct 
mddev *mddev)
rcu_read_lock();
for (i = 0; i < conf->raid_disks; i++) {
struct md_rdev *rdev = rcu_dereference(conf->disks[i].rdev);
-   seq_printf (seq, "%s", rdev && test_bit(In_sync, >flags) 
? "U" : "_");
+   seq_putc(seq,
+rdev && test_bit(In_sync, >flags) ? 'U' : '_');
}
rcu_read_unlock();
--
2.22.0

Re: [PATCH] csky: Improve abiv1 mem ops performance with glibc codes

2019-07-01 Thread Guo Ren

Hi Arnd,

On Mon, Jul 1, 2019 at 10:52 PM Arnd Bergmann  wrote:
>
> On Sat, Jun 29, 2019 at 7:36 AM  wrote:
> >
> > From: Guo Ren 
> >
> > These codes are copied from glibc/string directory, they are the generic
> > implementation for string operations. We may further optimize them with
> > assembly code in the future.
> >
> > In fact these code isn't tested enough for kernel, but we've tested them
> > on glibc and it seems good. We just trust them :)
>
> Are these files from the architecture independent portion of glibc or
> are they csky specific? If they are architecture independent, we might
> want to see if they make sense for other architectures as well, and
> add them to lib/ rather than arch/csky/lib/
They are just copied from glibc-2.28/string/*.c and they are generic.
OK, I'll try to add them to lib/.

>
> Should the SPDX identifier list the original LGPL-2.1 license instead
> of GPL-2.0?
Yes, I removed full Licenses' description:
   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version

I'll change it to:
// SPDX-License-Identifier: LGPL-2.1

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH v2] mmc: sdhci-msm: fix mutex while in spinlock

2019-07-01 Thread Vinod Koul

On 01-07-19, 17:01, Jorge Ramirez-Ortiz wrote:
> mutexes can sleep and therefore should not be taken while holding a
> spinlock. move clk_get_rate (can sleep) outside the spinlock protected
> region.

Reviewed-by: Vinod Koul 

-- 
~Vinod

[PATCH 1/2] leds: tlc591xx: simplify driver by using the managed led API

2019-07-01 Thread Jean-Jacques Hiblot

Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices

Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/leds/leds-tlc591xx.c | 81 ++--
 1 file changed, 21 insertions(+), 60 deletions(-)

diff --git a/drivers/leds/leds-tlc591xx.c b/drivers/leds/leds-tlc591xx.c
index 59ff088c7d75..14e47ff44df5 100644
--- a/drivers/leds/leds-tlc591xx.c
+++ b/drivers/leds/leds-tlc591xx.c
@@ -128,51 +128,6 @@ tlc591xx_brightness_set(struct led_classdev *led_cdev,
return err;
 }
 
-static void
-tlc591xx_destroy_devices(struct tlc591xx_priv *priv, unsigned int j)
-{
-   int i = j;
-
-   while (--i >= 0) {
-   if (priv->leds[i].active)
-   led_classdev_unregister(>leds[i].ldev);
-   }
-}
-
-static int
-tlc591xx_configure(struct device *dev,
-  struct tlc591xx_priv *priv,
-  const struct tlc591xx *tlc591xx)
-{
-   unsigned int i;
-   int err = 0;
-
-   tlc591xx_set_mode(priv->regmap, MODE2_DIM);
-   for (i = 0; i < TLC591XX_MAX_LEDS; i++) {
-   struct tlc591xx_led *led = >leds[i];
-
-   if (!led->active)
-   continue;
-
-   led->priv = priv;
-   led->led_no = i;
-   led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
-   led->ldev.max_brightness = LED_FULL;
-   err = led_classdev_register(dev, >ldev);
-   if (err < 0) {
-   dev_err(dev, "couldn't register LED %s\n",
-   led->ldev.name);
-   goto exit;
-   }
-   }
-
-   return 0;
-
-exit:
-   tlc591xx_destroy_devices(priv, i);
-   return err;
-}
-
 static const struct regmap_config tlc591xx_regmap = {
.reg_bits = 8,
.val_bits = 8,
@@ -197,7 +152,7 @@ tlc591xx_probe(struct i2c_client *client,
const struct of_device_id *match;
const struct tlc591xx *tlc591xx;
struct tlc591xx_priv *priv;
-   int err, count, reg;
+   int err, count, reg, idx = 0;
 
match = of_match_device(of_tlc591xx_leds_match, dev);
if (!match)
@@ -225,7 +180,11 @@ tlc591xx_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, priv);
 
+   tlc591xx_set_mode(priv->regmap, MODE2_DIM);
+
for_each_child_of_node(np, child) {
+   struct tlc591xx_led *led;
+
err = of_property_read_u32(child, "reg", );
if (err) {
of_node_put(child);
@@ -236,22 +195,25 @@ tlc591xx_probe(struct i2c_client *client,
of_node_put(child);
return -EINVAL;
}
-   priv->leds[reg].active = true;
-   priv->leds[reg].ldev.name =
+   led = >leds[reg];
+
+   led->active = true;
+   led->ldev.name =
of_get_property(child, "label", NULL) ? : child->name;
-   priv->leds[reg].ldev.default_trigger =
+   led->ldev.default_trigger =
of_get_property(child, "linux,default-trigger", NULL);
-   }
-   return tlc591xx_configure(dev, priv, tlc591xx);
-}
-
-static int
-tlc591xx_remove(struct i2c_client *client)
-{
-   struct tlc591xx_priv *priv = i2c_get_clientdata(client);
-
-   tlc591xx_destroy_devices(priv, TLC591XX_MAX_LEDS);
 
+   led->priv = priv;
+   led->led_no = idx++;
+   led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
+   led->ldev.max_brightness = LED_FULL;
+   err = devm_led_classdev_register(dev, >ldev);
+   if (err < 0) {
+   dev_err(dev, "couldn't register LED %s\n",
+   led->ldev.name);
+   return err;
+   }
+   }
return 0;
 }
 
@@ -268,7 +230,6 @@ static struct i2c_driver tlc591xx_driver = {
.of_match_table = of_match_ptr(of_tlc591xx_leds_match),
},
.probe = tlc591xx_probe,
-   .remove = tlc591xx_remove,
.id_table = tlc591xx_id,
 };
 
-- 
2.17.1

[PATCH 0/2] leds: tlc591xx: switch to OF and managed API

2019-07-01 Thread Jean-Jacques Hiblot

This mini-series updates the tlc591xx driver to use the managed API. The
driver is also modified to pass the DT node to the LED core layer.
The goal is to be able to the generic led-backlight [0] driver on top of
it.

[0] https://lore.kernel.org/patchwork/project/lkml/list/?series=400524

Jean-Jacques Hiblot (2):
  leds: tlc591xx: simplify driver by using the managed led API
  leds: tlc591xx: Use the OF version of the LED registration function

 drivers/leds/leds-tlc591xx.c | 81 ++--
 1 file changed, 21 insertions(+), 60 deletions(-)

-- 
2.17.1

[PATCH 2/2] leds: tlc591xx: Use the OF version of the LED registration function

2019-07-01 Thread Jean-Jacques Hiblot

The driver parses the device-tree to identify which LED should be handled.
Since the information about the device node is known at this time, we can
provide the LED core with it. It may be useful later.

Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/leds/leds-tlc591xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-tlc591xx.c b/drivers/leds/leds-tlc591xx.c
index 14e47ff44df5..6a2936c94b73 100644
--- a/drivers/leds/leds-tlc591xx.c
+++ b/drivers/leds/leds-tlc591xx.c
@@ -207,7 +207,7 @@ tlc591xx_probe(struct i2c_client *client,
led->led_no = idx++;
led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
led->ldev.max_brightness = LED_FULL;
-   err = devm_led_classdev_register(dev, >ldev);
+   err = devm_of_led_classdev_register(dev, child, >ldev);
if (err < 0) {
dev_err(dev, "couldn't register LED %s\n",
led->ldev.name);
-- 
2.17.1

Re: [PATCH v3 2/2] arch: wire-up clone3() syscall

2019-07-01 Thread Christian Brauner

On Mon, Jul 01, 2019 at 05:14:51PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 21, 2019 at 5:30 PM Christian Brauner  
> wrote:
> > On Fri, Jun 21, 2019 at 04:20:15PM +0200, Arnd Bergmann wrote:
> > > On Fri, Jun 21, 2019 at 1:18 PM Christian Brauner  
> > > wrote:
> > Hm, if you believe that this is fine and want to "vouch" for it by
> > whipping up a patch that replaces the wiring up done in [1] I'm happy to
> > take it. :) Otherwise I'd feel more comfortable not adding all arches at
> > once.
> >
> > [1]: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=clone
> 
> Sorry for my late reply. I had actually looked at the implementations
> in a little
> more detail and I think you are right that adding these are better
> left to the arch
> maintainers in case of clone3.

Perfect, thanks!

Christian

Re: [PATCH] scsi: virtio_scsi: Use struct_size() helper

On Wed, Jun 19, 2019 at 02:28:33PM -0500, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
> 
> struct virtio_scsi {
>   ...
> struct virtio_scsi_vq req_vqs[];
> };
> 
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> So, replace the following form:
> 
> sizeof(*vscsi) + sizeof(vscsi->req_vqs[0]) * num_queues
> 
> with:
> 
> struct_size(vscsi, req_vqs, num_queues)
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/scsi/virtio_scsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [UPDATE][PATCH 10/10] tools/power/x86: A tool to validate Intel Speed Select commands

2019-07-01 Thread Srinivas Pandruvada

On Mon, 2019-07-01 at 14:32 +0300, Andy Shevchenko wrote:
> On Sun, Jun 30, 2019 at 8:14 PM Srinivas Pandruvada
>  wrote:
> > 
> > The Intel(R) Speed select technologies contains four features.
> > 
> > Performance profile:An non architectural mechanism that allows
> > multiple
> > optimized performance profiles per system via static and/or dynamic
> > adjustment of core count, workload, Tjmax, and TDP, etc. aka ISS
> > in the documentation.
> > 
> > Base Frequency: Enables users to increase guaranteed base frequency
> > on
> > certain cores (high priority cores) in exchange for lower base
> > frequency
> > on remaining cores (low priority cores). aka PBF in the
> > documenation.
> > 
> > Turbo frequency: Enables the ability to set different turbo ratio
> > limits
> > to cores based on priority. aka FACT in the documentation.
> > 
> > Core power: An Interface that allows user to define per core/tile
> > priority.
> > 
> > There is a multi level help for commands and options. This can be
> > used
> > to check required arguments for each feature and commands for the
> > feature.
> > 
> > To start navigating the features start with
> > 
> > $sudo intel-speed-select --help
> > 
> > For help on a specific feature for example
> > $sudo intel-speed-select perf-profile --help
> > 
> > To get help for a command for a feature for example
> > $sudo intel-speed-select perf-profile get-lock-status --help
> > 
> > Signed-off-by: Srinivas Pandruvada <
> > srinivas.pandruv...@linux.intel.com>
> > ---
> > Updates:
> > - Copied Makefile from tools/gpio and moified the Makefile here
> > - Added entry to tools/build/Makefile
> > - Rename directory to match the executable name
> > - Fix one error message
> 
> Thanks!
> I pushed to my review and testing queue, while still waiting for some
> ACKs.
> 
> It seems I can promote the driver itself now,w/o tools, if you want
> me to do so.
I am fine with driver only push if we don't get ACK by your deadline
for the next kernel.

Thanks,
Srinivas

[PATCH 1/2] sh: stub out pud_page

2019-07-01 Thread Christoph Hellwig

There wasn't any actual need to add a real pud_page, as pud_huge
always returns false on sh.  Just stub it out to fix the sh3
compile failure.

Fixes: 937b4e1d6471 ("sh: add the missing pud_page definition")
Reported-by: Guenter Roeck 
Signed-off-by: Christoph Hellwig 
---
 arch/sh/include/asm/pgtable-3level.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/sh/include/asm/pgtable-3level.h 
b/arch/sh/include/asm/pgtable-3level.h
index 3c7ff20f3f94..779260b721ca 100644
--- a/arch/sh/include/asm/pgtable-3level.h
+++ b/arch/sh/include/asm/pgtable-3level.h
@@ -37,7 +37,9 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
 {
return pud_val(pud);
 }
-#define pud_page(pud)  pfn_to_page(pud_pfn(pud))
+
+/* only used by the stubbed out hugetlb gup code, should never be called */
+#define pud_page(pud)  NULL
 
 #define pmd_index(address) (((address) >> PMD_SHIFT) & (PTRS_PER_PMD-1))
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
-- 
2.20.1

generic gup fixups

2019-07-01 Thread Christoph Hellwig

Hi Andrew,

below two fixups for the generic GUP series, as reported by Guenter.

[PATCH 2/2] MIPS: don't select ARCH_HAS_PTE_SPECIAL

2019-07-01 Thread Christoph Hellwig

MIPS doesn't really have a proper pte_special implementation, just
stubs.  It turns out they were not enough to make get_user_pages_fast
work, so drop the select.  This means get_user_pages_fast won't
actually use the fast path for non-hugepage mappings, so someone who
actually knows about mips page table management should look into
adding real pte_special support.

Fixes: eb9488e58bbc ("MIPS: use the generic get_user_pages_fast code")
Reported-by: Guenter Roeck 
Signed-off-by: Christoph Hellwig 
---
 arch/mips/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b1e42f0e4ed0..7957d3457156 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -6,7 +6,6 @@ config MIPS
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_ELF_RANDOMIZE
-   select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_UPROBES
-- 
2.20.1

Re: general protection fault in do_move_mount (2)

2019-07-01 Thread Eric Biggers

On Mon, Jul 01, 2019 at 04:59:04PM +0200, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> >
> > Dmitry, any idea why syzbot found such a bizarre reproducer for this?
> > This is actually reproducible by a simple single threaded program:
> >
> > #include 
> >
> > #define __NR_move_mount 429
> > #define MOVE_MOUNT_F_EMPTY_PATH 0x0004
> >
> > int main()
> > {
> > int fds[2];
> >
> > pipe(fds);
> > syscall(__NR_move_mount, fds[0], "", -1, "/", 
> > MOVE_MOUNT_F_EMPTY_PATH);
> > }
> 
> 
> There is no pipe in the reproducer, so it could not theoretically come
> up with the reproducer with the pipe. During minimization syzkaller
> only tries to remove syscalls and simplify arguments and execution
> mode.
> What would be the simplest reproducer expressed as further
> minimization of this reproducer?
> https://syzkaller.appspot.com/x/repro.syz?x=154e8c2aa0
> I assume one of the syscalls is still move_mount, but what is the
> other one? If it's memfd_create, or open of the procfs file, then it
> seems that [ab]used heavy threading and syscall colliding as way to do
> an arbitrary mutation of the program. Per se results of
> memfd_create/procfs are not passed to move_mount. But by abusing races
> it probably managed to do so in small percent of cases. It would also
> explain why it's hard to reproduce.

To be clear, memfd_create() works just as well:

#define _GNU_SOURCE
#include 
#include 

#define __NR_move_mount 429
#define MOVE_MOUNT_F_EMPTY_PATH 0x0004

int main()
{
int fd = memfd_create("foo", 0);

syscall(__NR_move_mount, fd, "", -1, "/", 
MOVE_MOUNT_F_EMPTY_PATH);
}

I just changed it to pipe() in my example, because pipe() is less obscure.

> 
> 
> > FYI, it also isn't really appropriate for syzbot to bisect all bugs in new
> > syscalls to wiring them up to x86, and then blame all the x86 maintainers.
> > Normally such bugs will be in the syscall itself, regardless of 
> > architecture.
> 
> Agree. Do you think it's something worth handling automatically
> (stands out of the long tail of other inappropriate cases)? If so, how
> could we detect such cases? It seems that some of these predicates are
> quite hard to program. Similar things happen with introduction of new
> bug detection tools and checks, wiring any functionality to new access
> points and similar things.
> 

Yes, this case could easily be automatically detected (most of the time) by
listing the filenames changed in the commit, and checking whether they all match
the pattern syscall.*\.tbl.  Sure, it's not common, but it could be alongside
other similar straightforward checks like checking for merge commits and
checking for commits that only modify Documentation/.

I'm not even asking for more correct bisection results at this point, I'm just
asking for fewer bad bisection results.

- Eric

Re: [PATCH v3 2/2] arch: wire-up clone3() syscall

On Fri, Jun 21, 2019 at 5:30 PM Christian Brauner  wrote:
> On Fri, Jun 21, 2019 at 04:20:15PM +0200, Arnd Bergmann wrote:
> > On Fri, Jun 21, 2019 at 1:18 PM Christian Brauner  
> > wrote:
> Hm, if you believe that this is fine and want to "vouch" for it by
> whipping up a patch that replaces the wiring up done in [1] I'm happy to
> take it. :) Otherwise I'd feel more comfortable not adding all arches at
> once.
>
> [1]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=clone

Sorry for my late reply. I had actually looked at the implementations
in a little
more detail and I think you are right that adding these are better
left to the arch
maintainers in case of clone3.

  Arnd

Re: [PATCH v2 0/3] vsock/virtio: several fixes in the .probe() and .remove()

On Fri, Jun 28, 2019 at 02:36:56PM +0200, Stefano Garzarella wrote:
> During the review of "[PATCH] vsock/virtio: Initialize core virtio vsock
> before registering the driver", Stefan pointed out some possible issues
> in the .probe() and .remove() callbacks of the virtio-vsock driver.
> 
> This series tries to solve these issues:
> - Patch 1 adds RCU critical sections to avoid use-after-free of
>   'the_virtio_vsock' pointer.
> - Patch 2 stops workers before to call vdev->config->reset(vdev) to
>   be sure that no one is accessing the device.
> - Patch 3 moves the works flush at the end of the .remove() to avoid
>   use-after-free of 'vsock' object.
> 
> v2:
> - Patch 1: use RCU to protect 'the_virtio_vsock' pointer
> - Patch 2: no changes
> - Patch 3: flush works only at the end of .remove()
> - Removed patch 4 because virtqueue_detach_unused_buf() returns all the 
> buffers
>   allocated.
> 
> v1: https://patchwork.kernel.org/cover/10964733/

This looks good to me.

Did you run any stress tests?  For example an SMP guest constantly
connecting and sending packets together with a script that
hotplug/unplugs vhost-vsock-pci from the host side.

Stefan


signature.asc
Description: PGP signature

Re: [PATCH 1/2] ARM: davinci: da830-evm: add missing regulator constraints for OHCI

2019-07-01 Thread Sekhar Nori

On 25/06/19 10:19 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> We need to enable status changes for the fixed power supply for the USB
> controller.
> 
> Fixes: 274e4c336192 ("ARM: davinci: da830-evm: add a fixed regulator for 
> ohci-da8xx")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Bartosz Golaszewski 

For both these patches as well, the offending commit was introduced in
v5.2 so I dropped the stable tag while applying.

Will send pull request tomorrow after some build and boot testing.

Thanks,
Sekhar

Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock

On Fri, Jun 28, 2019 at 02:36:57PM +0200, Stefano Garzarella wrote:
> Some callbacks used by the upper layers can run while we are in the
> .remove(). A potential use-after-free can happen, because we free
> the_virtio_vsock without knowing if the callbacks are over or not.
> 
> To solve this issue we move the assignment of the_virtio_vsock at the
> end of .probe(), when we finished all the initialization, and at the
> beginning of .remove(), before to release resources.
> For the same reason, we do the same also for the vdev->priv.
> 
> We use RCU to be sure that all callbacks that use the_virtio_vsock
> ended before freeing it. This is not required for callbacks that
> use vdev->priv, because after the vdev->config->del_vqs() we are sure
> that they are ended and will no longer be invoked.

My question is answered in Patch 3.


signature.asc
Description: PGP signature

Re: [PATCH v2 3/3] vsock/virtio: fix flush of works during the .remove()

On Fri, Jun 28, 2019 at 02:36:59PM +0200, Stefano Garzarella wrote:
> This patch moves the flush of works after vdev->config->del_vqs(vdev),
> because we need to be sure that no workers run before to free the
> 'vsock' object.
> 
> Since we stopped the workers using the [tx|rx|event]_run flags,
> we are sure no one is accessing the device while we are calling
> vdev->config->reset(vdev), so we can safely move the workers' flush.
> 
> Before the vdev->config->del_vqs(vdev), workers can be scheduled
> by VQ callbacks, so we must flush them after del_vqs(), to avoid
> use-after-free of 'vsock' object.

Nevermind, I looked back at Patch 2 and saw the send_pkt and loopback
work functions were also updated.  Thanks!

Stefan


signature.asc
Description: PGP signature

Re: [PATCH] ARM: davinci: da830-evm: fix GPIO lookup for OHCI

2019-07-01 Thread Sekhar Nori

On 25/06/19 8:46 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> The fixed regulator driver doesn't specify any con_id for gpio lookup
> so it must be NULL in the table entry.
> 
> Fixes: 274e4c336192 ("ARM: davinci: da830-evm: add a fixed regulator for 
> ohci-da8xx")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Bartosz Golaszewski 

The offending commit was introduced in v5.2 so I dropped the stable tag
while applying.

Will send pull request tomorrow after some build and testing.

Thanks,
Sekhar

Re: [PATCH v2 3/3] vsock/virtio: fix flush of works during the .remove()

On Fri, Jun 28, 2019 at 02:36:59PM +0200, Stefano Garzarella wrote:
> This patch moves the flush of works after vdev->config->del_vqs(vdev),
> because we need to be sure that no workers run before to free the
> 'vsock' object.
> 
> Since we stopped the workers using the [tx|rx|event]_run flags,
> we are sure no one is accessing the device while we are calling
> vdev->config->reset(vdev), so we can safely move the workers' flush.

What about send_pkt and loopback work?  How were they stopped safely?

For example, if send_pkt work executes then we're in trouble since it
accesses the tx virtqueue which is deleted by ->del_vqs().


signature.asc
Description: PGP signature

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

2019-07-01 Thread Cornelia Huck

On Mon, 01 Jul 2019 08:54:44 -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 
> ---
> 
> v2: Don't remove the dev_info(), Kirti requested they stay and
> removing them is only tangential to the goal of this change.
> 
>  drivers/vfio/mdev/mdev_core.c |8 
>  1 file changed, 8 insertions(+)

Not that fond of the dev_info(), but this still looks sane.

Reviewed-by: Cornelia Huck

[PATCH] staging: kpc2000: drop useless softdep statement

2019-07-01 Thread Jean Delvare

The i2c-dev module is for access to I2C buses from user-space.
Kernel drivers do not care about its presence.

Signed-off-by: Jean Delvare 
Cc: Matt Sickler 
Cc: Greg Kroah-Hartman 
---
 drivers/staging/kpc2000/kpc_i2c/i2c_driver.c |1 -
 1 file changed, 1 deletion(-)

--- linux-5.2-rc7.orig/drivers/staging/kpc2000/kpc_i2c/i2c_driver.c 
2019-06-30 05:25:36.0 +0200
+++ linux-5.2-rc7/drivers/staging/kpc2000/kpc_i2c/i2c_driver.c  2019-07-01 
11:33:17.336697545 +0200
@@ -26,7 +26,6 @@
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("matt.sick...@daktronics.com");
-MODULE_SOFTDEP("pre: i2c-dev");
 
 struct i2c_device {
 unsigned long   smba;


-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] hinic: reduce rss_init stack usage

On Fri, Jun 28, 2019 at 6:32 PM David Miller  wrote:
>
> From: Arnd Bergmann 
> Date: Fri, 28 Jun 2019 12:31:44 +0200
>
> > On 32-bit architectures, putting an array of 256 u32 values on the
> > stack uses more space than the warning limit:
> >
> > drivers/net/ethernet/huawei/hinic/hinic_main.c: In function 
> > 'hinic_rss_init':
> > drivers/net/ethernet/huawei/hinic/hinic_main.c:286:1: error: the frame size 
> > of 1068 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> >
> > I considered changing the code to use u8 values here, since that's
> > all the hardware supports, but dynamically allocating the array is
> > a more isolated fix here.
> >
> > Signed-off-by: Arnd Bergmann 
>
> Applied to net-next.

Thanks

> Arnd, please make it clear what tree you are targetting in the
> future.

Sorry about missing this again. I usually remember but sometimes
one slips through when I send a lot of patches for different subsystems
at once.

  Arnd

Re: [PATCH] mtd: rawnand: ingenic: fix ingenic_ecc dependency