Re: [PATCH 4/4] selftests/sysctl: Make sysctl test driver as a module

[Kees Cook]

On Thu, May 28, 2020 at 11:52:37PM +0900, Masami Hiramatsu wrote:
> Fix config file to require CONFIG_TEST_SYSCTL=m instead of y
> because this driver introduces a test sysctl interfaces which
> are normally not used, and only used for the selftest.
> 
> Signed-off-by: Masami Hiramatsu 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH 3/4] selftests/sysctl: Fix to load test_sysctl module

[Kees Cook]

On Thu, May 28, 2020 at 11:52:26PM +0900, Masami Hiramatsu wrote:
> Fix to load test_sysctl.ko module correctly.
> 
> sysctl.sh checks whether the test module is embedded (or loaded
> already) or not at first, and if not, it returns skip error
> instead of trying modprobe. Thus, there is no chance to load the
> test_sysctl test module.
> 
> Instead, this removes that module embedded check and returns
> skip error only if it ensures that there is no embedded test
> module *and* no loadable test module.
> 
> This also avoid referring config file since that is not
> installed.
> 
> Signed-off-by: Masami Hiramatsu 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode

[Jiping Ma]

On 05/28/2020 03:54 PM, Will Deacon wrote:

On Thu, May 28, 2020 at 09:06:07AM +0800, Jiping Ma wrote:

On 05/27/2020 11:19 PM, Mark Rutland wrote:

On Wed, May 27, 2020 at 09:33:00AM +0800, Jiping Ma wrote:

On 05/26/2020 06:26 PM, Mark Rutland wrote:

On Mon, May 11, 2020 at 10:52:07AM +0800, Jiping Ma wrote:

This modification can not fix our issue,  we need
perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32 to judge if it is 32-bit
task or not,
then return the correct PC value.

I must be missing something here.

The core code perf_reg_abi(task) is called with the task being sampled,
and the regs are from the task being sampled. For a userspace sample for
a compat task, compat_user_mode(regs) should be equivalent to the
is_compat_thread(task_thread_info(task)) check.

What am I missing?

This issue caused by PC value is not correct. regs are sampled in function
perf_output_sample_regs, that call perf_reg_value(regs, bit) to get PC
value.
PC value is regs[15] in perf_reg_value() function. it should be regs[32].

perf_output_sample_regs(struct perf_output_handle *handle,
     struct pt_regs *regs, u64 mask)
{
     int bit;
     DECLARE_BITMAP(_mask, 64);

     bitmap_from_u64(_mask, mask);
     for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
     u64 val;

     val = perf_reg_value(regs, bit);
     perf_output_put(handle, val);
     }
}

Yes, but Mark's point is that checking 'compat_user_mode(regs)' should be
exactly the same as checking 'perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32'.
Are you saying that's not the case? If so, please can you provide an example
of when they are different?
Yes, compat_user_mode(regs) is same with 'perf_reg_abi(current) == 
PERF_SAMPLE_REGS_ABI_32'.

I tested it.

Jiping


Leaving that aside for a second, I also think it's reasonable to question
whether this whole interface is busted or not. I looked at it last night but
struggled to work out what it's supposed to do. Consider these three
scenarios, all under an arm64 kernel:

   1. 64-bit perf + 64-bit application being profiled
   2. 64-bit perf + 32-bit application being profiled
   3. 32-bit perf + 32-bit application being profiled

It looks like the current code is a bodge to try to handle both (2) and
(3) at the same time:

   - In case (3), userspace only asks about registers 0-15
   - In case (2), we fudge the higher registers so that 64-bit SP and LR
 hold the 32-bit values as a bodge to allow a 64-bit dwarf unwinder
 to unwind the stack

So the idea behind the patch looks fine because case (3) is expecting the PC
in register 15 and instead gets 0, but the temptation is to clean this up so
that cases (2) and (3) report the same data to userspace (along the lines of
Mark's patch), namely only the first 16 registers with the PC moved down. We
can only do that if the unwinder is happy, which it might be if it only ever
looks up dwarf register numbers based on the unwind tables in the binary.
Somebody would need to dig into that. Otherwise, if it generates unconditional
references to things like register 30 to grab the link register, then we're
stuck with the bodge and need to special-case the PC.

Thoughts?

Will

Re: [PATCH 1/4] lib: Make prime number generator independently selectable

[Kees Cook]

On Thu, May 28, 2020 at 11:52:06PM +0900, Masami Hiramatsu wrote:
> Make prime number generator independently selectable from
> kconfig. This allows us to enable CONFIG_PRIME_NUMBERS=m
> and run the tools/testing/selftests/lib/prime_numbers.sh
> without other DRM selftest modules.

Nice catch! I see that tools/testing/selftests/lib/config already has
CONFIG_PRIME_NUMBERS=m (based on this commit log I was expecting to see
it added in the diff, but I see it's not needed).

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH 09/14] fs: don't change the address limit for ->write_iter in __kernel_write

[Christoph Hellwig]

On Thu, May 28, 2020 at 08:00:52PM +0100, Al Viro wrote:
> On Thu, May 28, 2020 at 07:40:38AM +0200, Christoph Hellwig wrote:
> > If we write to a file that implements ->write_iter there is no need
> > to change the address limit if we send a kvec down.  Implement that
> > case, and prefer it over using plain ->write with a changed address
> > limit if available.
> 
> Umm...  It needs a comment along the lines of "weird shits like
> /dev/sg that currently check for uaccess_kernel() will just
> have to make sure they never switch to ->write_iter()"

sg and hid has the uaccess_kernel because it accesses userspace memory not
in the range passed to it.  Something using write_iter/read_iter should
never access any memory outside the iter passed to.  rdma has it because
it uses write as a bidirectional interface, which obviously can't work at
all with an iter.  So I'm not sure what we should comment on, but if
you have a desire and a proposal for a comment I'll happily add it.

Re: [PATCH] mm, memory_failure: only send BUS_MCEERR_AO to early-kill process

[wetp]

On 2020/5/29 上午10:12, HORIGUCHI NAOYA(堀口 直也) wrote:

On Thu, May 28, 2020 at 02:50:09PM +0800, wetp wrote:

On 2020/5/28 上午10:22, HORIGUCHI NAOYA(堀口 直也) wrote:

Hi Zhang,

Sorry for my late response.

On Tue, May 26, 2020 at 03:06:41PM +0800, Wetp Zhang wrote:

From: Zhang Yi 

If a process don't need early-kill, it may not care the BUS_MCEERR_AO.
Let the process to be killed when it really access the corrupted memory.

Signed-off-by: Zhang Yi 

Thank you for pointing this. This looks to me a bug (per-process flag
is ignored when system-wide flag is set).

The flag is not problem for me.

In my case, two processes share memory with no any flag setting, both will
be killed when only one

access the fail memory.

Thanks, now your problem seems clearer.

It seems that this happens because in "Action Required" case kill_proc()
takes the first branch for current process, while it takes the else branch
for other affected processes:

 static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags)
 {
 ...
 
 if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {

 ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user 
*)tk->addr,
addr_lsb);
 } else {
 /*
  * Don't use force here, it's convenient if the signal
  * can be temporarily blocked.
  * This could cause a loop when the user sets SIGBUS
  * to SIG_IGN, but hopefully no one will do that?
  */
 ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user 
*)tk->addr,
   addr_lsb, t);  /* synchronous? */
 }

Sending SIGBUS with BUS_MCEERR_AO for action optional error is strange, so
maybe this logic should be like this:


 if (flags & MF_ACTION_REQUIRED) {
 if (t->mm == current->mm)
 ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user 
*)tk->addr,
addr_lsb);
 /* send no signal to non-current processes */

Ok, this can solve my problem.


 } else {
 /*
  * Don't use force here, it's convenient if the signal
  * can be temporarily blocked.
  * This could cause a loop when the user sets SIGBUS
  * to SIG_IGN, but hopefully no one will do that?
  */
 ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user 
*)tk->addr,
   addr_lsb, t);  /* synchronous? */
 }


---
   mm/memory-failure.c | 7 ---
   1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index a96364be8ab4..2db13d48865c 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -210,7 +210,7 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, 
int flags)
   {
struct task_struct *t = tk->tsk;
short addr_lsb = tk->size_shift;
-   int ret;
+   int ret = 0;

pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware memory 
corruption\n",
pfn, t->comm, t->pid);
@@ -225,8 +225,9 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, 
int flags)
 * This could cause a loop when the user sets SIGBUS
 * to SIG_IGN, but hopefully no one will do that?
 */
-   ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr,
- addr_lsb, t);  /* synchronous? */
+   if ((t->flags & PF_MCE_PROCESS) && (t->flags & PF_MCE_EARLY))
+   ret = send_sig_mceerr(BUS_MCEERR_AO,
+   (void __user *)tk->addr, addr_lsb, t);

kill_proc() could be called only for processes that are selected by
collect_procs() with task_early_kill().  So I think that we should fix
task_early_kill(), maybe by reordering sysctl_memory_failure_early_kill
check and find_early_kill_thread() check.

  static struct task_struct *task_early_kill(struct task_struct *tsk,
 int force_early)
  {
  struct task_struct *t;
  if (!tsk->mm)
  return NULL;
  if (force_early)
  return tsk;

The force_early is rely the flag MF_ACTION_REQUIRED, so it is always true
when MCE occurs.

This leads always sending SIGBUS to processes even if those are not current
or no flag setting.

  I think it could keep the non-current processes which has no flag setting
running.


Besides, base on your recommendation I reorder the force_early check and
find_early_kill_thread()

check, to send the signal to the right thread.

Sorry, my previous comment around 

Re: [PATCH 2/4] lib: Make test_sysctl initialized as module

[Kees Cook]

On Thu, May 28, 2020 at 11:52:16PM +0900, Masami Hiramatsu wrote:
> test_sysctl.c is expected to be used as a module, but since
> it does not use module_init(), it never be registered as
> a module and not appeared under /sys/module/.
> In the result, the selftests/sysctl/sysctl.sh always fails
> to find the test module and is skipped.
> 
> This makes test_sysctl.c initialized as a module by module_init()
> and allow sysctl.sh to find the test module is loaded.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  lib/test_sysctl.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
> index 566dad3f4196..ec4d0f03475d 100644
> --- a/lib/test_sysctl.c
> +++ b/lib/test_sysctl.c
> @@ -149,7 +149,7 @@ static int __init test_sysctl_init(void)
>   }
>   return 0;
>  }
> -late_initcall(test_sysctl_init);
> +module_init(test_sysctl_init);

This is the only part I think we need to double check. As a non-module,
module_init() becomes device_initcall() not late_initcall().

I don't see any notes in the commit log for the original driver that
mention why this needs to be late_initcall(), though, so I *think* it's
safe. Luis?

-- 
Kees Cook

Re: [PATCH 06/14] fs: remove the call_{read,write}_iter functions

[Christoph Hellwig]

On Thu, May 28, 2020 at 07:56:43PM +0100, Al Viro wrote:
> On Thu, May 28, 2020 at 07:40:35AM +0200, Christoph Hellwig wrote:
> > Just open coding the methods calls is a lot easier to follow.
> 
> Not sure about this one, TBH - it's harder to grep that way, since
> you get all the initializers for read_iter/write_iter thrown into
> the mix.  Sure, you can do something like '\->[   ]*read_iter\>',
> but it's a PITA.

Which you have to do anyway as not all calls go through these weird
helpers.

Re: [PATCH linux-rcu] docs/litmus-tests: add BPF ringbuf MPSC litmus tests

[Andrii Nakryiko]

On Thu, May 28, 2020 at 3:54 PM Joel Fernandes  wrote:
>
> Hello Andrii,
> This is quite exciting. Some comments below:
>
> On Wed, May 27, 2020 at 11:24:08PM -0700, Andrii Nakryiko wrote:
> [...]
> > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus 
> > b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
> > new file mode 100644
> > index ..558f054fb0b4
> > --- /dev/null
> > +++ b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
> > @@ -0,0 +1,91 @@
> > +C bpf-rb+1p1c+bounded
> > +
> > +(*
> > + * Result: Always
> > + *
> > + * This litmus test validates BPF ring buffer implementation under the
> > + * following assumptions:
> > + * - 1 producer;
> > + * - 1 consumer;
> > + * - ring buffer has capacity for only 1 record.
> > + *
> > + * Expectations:
> > + * - 1 record pushed into ring buffer;
> > + * - 0 or 1 element is consumed.
> > + * - no failures.
> > + *)
> > +
> > +{
> > + atomic_t dropped;
> > +}
> > +
> > +P0(int *lenFail, int *len1, int *cx, int *px)
> > +{
> > + int *rLenPtr;
> > + int rLen;
> > + int rPx;
> > + int rCx;
> > + int rFail;
> > +
> > + rFail = 0;
> > +
> > + rCx = smp_load_acquire(cx);
> > + rPx = smp_load_acquire(px);
>
> Is it possible for you to put some more comments around which ACQUIRE is
> paired with which RELEASE? And, in general more comments around the reason
> for a certain memory barrier and what pairs with what. In the kernel sources,
> the barriers needs a comment anyway.
>
> > + if (rCx < rPx) {
> > + if (rCx == 0) {
> > + rLenPtr = len1;
> > + } else {
> > + rLenPtr = lenFail;
> > + rFail = 1;
> > + }
> > +
> > + rLen = smp_load_acquire(rLenPtr);
> > + if (rLen == 0) {
> > + rFail = 1;
> > + } else if (rLen == 1) {
> > + rCx = rCx + 1;
> > + smp_store_release(cx, rCx);
> > + }
> > + }
> > +}
> > +
> > +P1(int *lenFail, int *len1, spinlock_t *rb_lock, int *px, int *cx, 
> > atomic_t *dropped)
> > +{
> > + int rPx;
> > + int rCx;
> > + int rFail;
> > + int *rLenPtr;
> > +
> > + rFail = 0;
> > +
> > + rCx = smp_load_acquire(cx);
> > + spin_lock(rb_lock);
> > +
> > + rPx = *px;
> > + if (rPx - rCx >= 1) {
> > + atomic_inc(dropped);
>
> Why does 'dropped' need to be atomic if you are always incrementing under a
> lock?

It doesn't, strictly speaking, but making it atomic in litmus test was
just more convenient, especially that I initially also had a lock-less
variant of this algorithm.

>
> > + spin_unlock(rb_lock);
> > + } else {
> > + if (rPx == 0) {
> > + rLenPtr = len1;
> > + } else {
> > + rLenPtr = lenFail;
> > + rFail = 1;
> > + }
> > +
> > + *rLenPtr = -1;
>
> Clarify please the need to set the length intermittently to -1. Thanks.

This corresponds to setting a "busy bit" in kernel implementation.
These litmus tests are supposed to be correlated with in-kernel
implementation, I'm not sure I want to maintain extra 4 copies of
comments here and in kernel code. Especially for 2-producer cases,
there are 2 identical P1 and P2, which is unfortunate, but I haven't
figured out how to have a re-usable pieces of code with litmus tests
:)

>
> > + smp_store_release(px, rPx + 1);
> > +
> > + spin_unlock(rb_lock);
> > +
> > + smp_store_release(rLenPtr, 1);
> > + }
> > +}
> > +
> > +exists (
> > + 0:rFail=0 /\ 1:rFail=0
> > + /\
> > + (
> > + (dropped=0 /\ px=1 /\ len1=1 /\ (cx=0 \/ cx=1))
> > + )
> > +)
> > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus 
> > b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus
> > new file mode 100644
> > index ..7ab5d0e6e49f
> > --- /dev/null
> > +++ b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+unbound.litmus
>
> I wish there was a way to pass args to litmus tests, then perhaps it would
> have been possible to condense some of these tests. :-)

It wouldn't help much, actually, because litmus tests can't have
arrays. See all those "if selectors" between len1 and len2, I had to
do explicitly.

>
> > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus 
> > b/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus
> > new file mode 100644
> > index ..83f80328c92b
> > --- /dev/null
> > +++ b/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus
> [...]
> > +P0(int *lenFail, int *len1, int *cx, int *px)
> > +{
> > + int *rLenPtr;
> > + int rLen;
> > + int rPx;
> > + int rCx;
> > + int rFail;
> > +
> > + rFail = 0;
> > +
> > + rCx = smp_load_acquire(cx);
> > + rPx = 

Re: [RFC 02/17] dma-fence: basic lockdep annotations

[Daniel Vetter]

On Thu, May 28, 2020 at 11:54 PM Luben Tuikov  wrote:
>
> On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> >   this explicit annotation can be more liberally sprinkled around.
> >   With read locks lockdep isn't going to complain if the read-side
> >   isn't nested the same way under all circumstances, so ABBA deadlocks
> >   are ok. Which they are, since this is an annotation only.
> >
> > - We're using non-recursive lockdep read lock mode, since in recursive
> >   read lock mode lockdep does not catch read side hazards. And we
> >   _very_ much want read side hazards to be caught. For full details of
> >   this limitation see
> >
> >   commit e91498589746065e3ae95d9a00b068e525eec34f
> >   Author: Peter Zijlstra 
> >   Date:   Wed Aug 23 13:13:11 2017 +0200
> >
> >   locking/lockdep/selftests: Add mixed read-write ABBA tests
> >
> > - To allow nesting of the read-side explicit annotations we explicitly
> >   keep track of the nesting. lock_is_held() allows us to do that.
> >
> > - The wait-side annotation is a write lock, and entirely done within
> >   dma_fence_wait() for everyone by default.
> >
> > - To be able to freely annotate helper functions I want to make it ok
> >   to call dma_fence_begin/end_signalling from soft/hardirq context.
> >   First attempt was using the hardirq locking context for the write
> >   side in lockdep, but this forces all normal spinlocks nested within
> >   dma_fence_begin/end_signalling to be spinlocks. That bollocks.
> >
> >   The approach now is to simple check in_atomic(), and for these cases
> >   entirely rely on the might_sleep() check in dma_fence_wait(). That
> >   will catch any wrong nesting against spinlocks from soft/hardirq
> >   contexts.
> >
> > The idea here is that every code path that's critical for eventually
> > signalling a dma_fence should be annotated with
> > dma_fence_begin/end_signalling. The annotation ideally starts right
> > after a dma_fence is published (added to a dma_resv, exposed as a
> > sync_file fd, attached to a drm_syncobj fd, or anything else that
> > makes the dma_fence visible to other kernel threads), up to and
> > including the dma_fence_wait(). Examples are irq handlers, the
> > scheduler rt threads, the tail of execbuf (after the corresponding
> > fences are visible), any workers that end up signalling dma_fences and
> > really anything else. Not annotated should be code paths that only
> > complete fences opportunistically as the gpu progresses, like e.g.
> > shrinker/eviction code.
> >
> > The main class of deadlocks this is supposed to catch are:
> >
> > Thread A:
> >
> >   mutex_lock(A);
> >   mutex_unlock(A);
> >
> >   dma_fence_signal();
> >
> > Thread B:
> >
> >   mutex_lock(A);
> >   dma_fence_wait();
> >   mutex_unlock(A);
> >
> > Thread B is blocked on A signalling the fence, but A never gets around
> > to that because it cannot acquire the lock A.
> >
> > Note that dma_fence_wait() is allowed to be nested within
> > dma_fence_begin/end_signalling sections. To allow this to happen the
> > read lock needs to be upgraded to a write lock, which means that any
> > other lock is acquired between the dma_fence_begin_signalling() call and
> > the call to dma_fence_wait(), and still held, this will result in an
> > immediate lockdep complaint. The only other option would be to not
> > annotate such calls, defeating the point. Therefore these annotations
> > cannot be sprinkled over the code entirely mindless to avoid false
> > positives.
> >
> > v2: handle soft/hardirq ctx better against write side and dont forget
> > EXPORT_SYMBOL, drivers can't use this otherwise.
> >
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: amd-...@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Cc: Christian König 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/dma-buf/dma-fence.c | 53 +
> >  include/linux/dma-fence.h   | 12 +
> >  2 files changed, 65 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 6802125349fb..d5c0fd2efc70 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> >  }
> >  EXPORT_SYMBOL(dma_fence_context_alloc);
> >
> > +#ifdef CONFIG_LOCKDEP
> > +struct lockdep_map   dma_fence_lockdep_map = {
> > + .name = "dma_fence_map"
> > +};
> > +
> > +bool dma_fence_begin_signalling(void)
> > +{
> > + /* explicitly nesting ... */
> > + if (lock_is_held_type(_fence_lockdep_map, 1))
> > + return true;
> > +
> > + /* rely on might_sleep check for soft/hardirq locks */
> > + if 

Re: [PATCH] usb/phy-generic: Add support for OTG VBUS supply control

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 28-05-2020 13:20, Peter Chen wrote:

On 20-05-26 16:50:51, Mike Looijmans wrote:

This enables support for VBUS on boards where the power is supplied
by a regulator. The regulator is enabled when the USB port enters
HOST mode.


Why you don't do this at your host controller driver?


That was my first thought too, but it made more sense to do it here. 
It's about how things are connected on the board, and not about the 
controller. Also makes for a consistent devicetree when using different 
SOCs on the same carrier board.


I already needed this driver to properly reset the USB phy, which the 
controller driver also did not do. So it made sense to add the vbus 
power control to this driver too.


If you have a strong preference for the controller driver, I can move 
this to the DWC3 driver which happens to be the controller for the 
latest batch of SOMs.





Peter

Signed-off-by: Mike Looijmans 
---
  .../devicetree/bindings/usb/usb-nop-xceiv.txt |  3 ++
  drivers/usb/phy/phy-generic.c | 44 ++-
  drivers/usb/phy/phy-generic.h |  2 +
  3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt 
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index 4dc6a8ee3071..775a19fdb613 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -16,6 +16,9 @@ Optional properties:
  
  - vcc-supply: phandle to the regulator that provides power to the PHY.
  
+- vbus-supply: phandle to the regulator that provides the VBUS power for when

+  the device is in HOST mode.
+
  - reset-gpios: Should specify the GPIO for reset.
  
  - vbus-detect-gpio: should specify the GPIO detecting a VBus insertion

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 661a229c105d..ebfb90764511 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -203,13 +203,43 @@ static int nop_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
  }
  
+static int nop_set_vbus(struct usb_otg *otg, bool enabled)

+{
+   struct usb_phy_generic *nop;
+   int ret;
+
+   if (!otg)
+   return -ENODEV;
+
+   nop = container_of(otg->usb_phy, struct usb_phy_generic, phy);
+
+   if (!nop->vbus_reg)
+   return 0;
+
+   if (enabled) {
+   if (nop->vbus_reg_enabled)
+   return 0;
+   ret = regulator_enable(nop->vbus_reg);
+   if (ret < 0)
+   return ret;
+   nop->vbus_reg_enabled = true;
+   } else {
+   if (!nop->vbus_reg_enabled)
+   return 0;
+   ret = regulator_disable(nop->vbus_reg);
+   if (ret < 0)
+   return ret;
+   nop->vbus_reg_enabled = false;
+   }

There's a "return 0" missing here, will fix that in v2

+}
+
  int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
  {
enum usb_phy_type type = USB_PHY_TYPE_USB2;
int err = 0;
  
  	u32 clk_rate = 0;

-   bool needs_vcc = false, needs_clk = false;
+   bool needs_vcc = false, needs_clk = false, needs_vbus = false;
  
  	if (dev->of_node) {

struct device_node *node = dev->of_node;
@@ -219,6 +249,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop)
  
  		needs_vcc = of_property_read_bool(node, "vcc-supply");

needs_clk = of_property_read_bool(node, "clocks");
+   needs_vbus = of_property_read_bool(node, "vbus-supply");
}
nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
   GPIOD_ASIS);
@@ -268,6 +299,16 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop)
return -EPROBE_DEFER;
}
  
+	nop->vbus_reg = devm_regulator_get(dev, "vbus");

+   if (IS_ERR(nop->vbus_reg)) {
+   dev_dbg(dev, "Error getting vbus regulator: %ld\n",
+   PTR_ERR(nop->vbus_reg));
+   if (needs_vbus)
+   return -EPROBE_DEFER;
+
+   nop->vbus_reg = NULL;
+   }
+
nop->dev = dev;
nop->phy.dev = nop->dev;
nop->phy.label   = "nop-xceiv";
@@ -278,6 +319,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop)
nop->phy.otg->usb_phy = >phy;
nop->phy.otg->set_host= nop_set_host;

Re: [PATCH] PCI: Fix reference count leak in pci_create_slot()

[Markus Elfring]

Please add a prefix to the patch subject.


> kobject_init_and_add() takes reference even when it fails.

I suggest to extend this description another bit.
Which object is affected here?


> If this function returns an error, kobject_put() must be called to
> properly clean up the memory associated with the object.

Such a copy from the function description of this programming interface
can be helpful.


> Thus, when call of kobject_init_and_add() fail,

I propose to avoid the repetition of this condition.


> we should call kobject_put() instead of kfree().

How do you think about a wording variant like the following?

   Replace a call of the function “kfree” by “kobject_put”
   because of using kernel objects in the proper way.


> Previous commit "b8eb718348b8" fixed a similar problem.

I wonder if such information is really relevant for the commit message.

Regards,
Markus

Re: [PATCH v3 4/4] kdb: Switch kdb_msg_write() to use safer polling I/O

[Sumit Garg]

On Thu, 28 May 2020 at 20:27, Petr Mladek  wrote:
>
> On Thu 2020-05-28 12:26:20, Daniel Thompson wrote:
> > On Thu, May 28, 2020 at 11:48:48AM +0530, Sumit Garg wrote:
> > > On Wed, 27 May 2020 at 19:01, Daniel Thompson
> > >  wrote:
> > > >
> > > > On Wed, May 27, 2020 at 11:55:59AM +0530, Sumit Garg wrote:
> > > > > In kgdb NMI context, calling console handlers isn't safe due to locks
> > > > > used in those handlers which could lead to a deadlock. Although, using
> > > > > oops_in_progress increases the chance to bypass locks in most console
> > > > > handlers but it might not be sufficient enough in case a console uses
> > > > > more locks (VT/TTY is good example).
> > > > >
> > > > > Currently when a driver provides both polling I/O and a console then 
> > > > > kdb
> > > > > will output using the console. We can increase robustness by using the
> > > > > currently active polling I/O driver (which should be lockless) instead
> > > > > of the corresponding console. For several common cases (e.g. an
> > > > > embedded system with a single serial port that is used both for 
> > > > > console
> > > > > output and debugger I/O) this will result in no console handler being
> > > > > used.
> > > >
> > > > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> > > > > index b072aeb..05d165d 100644
> > > > > --- a/include/linux/kgdb.h
> > > > > +++ b/include/linux/kgdb.h
> > > > > @@ -275,6 +275,7 @@ struct kgdb_arch {
> > > > >   * for the I/O driver.
> > > > >   * @is_console: 1 if the end device is a console 0 if the I/O device 
> > > > > is
> > > > >   * not a console
> > > > > + * @tty_drv: Pointer to polling tty driver.
> > > > >   */
> > > > >  struct kgdb_io {
> > > > >   const char  *name;
> > > > > @@ -285,6 +286,7 @@ struct kgdb_io {
> > > > >   void(*pre_exception) (void);
> > > > >   void(*post_exception) (void);
> > > > >   int is_console;
> > > > > + struct tty_driver   *tty_drv;
> > > >
> > > > Should this be a struct tty_driver or a struct console?
> > > >
> > > > In other words if the lifetime the console structure is the same as the
> > > > tty_driver then isn't it better to capture the console instead
> > > > (easier to compare and works with non-tty devices such as the
> > > > USB debug mode).
> > > >
> > >
> > > IIUC, you mean to say we can easily replace "is_console" with "struct
> > > console". This sounds feasible and should be a straightforward
> > > comparison in order to prefer "dbg_io_ops" over console handlers. So I
> > > will switch to use "struct console" instead.
> >
> > My comment contains an if ("if the lifetime of the console structure is
> > the same") so you need to check that it is true before sharing a patch to
> > make the change.
>
> Honestly, I am not completely familiar with the console an tty drivers
> code.
>
> Anyway, struct console is typically statically defined by the console
> driver code. It is not must to have but I am not aware of any
> driver where it would be dynamically defined.
>

Yes this is mine understanding as well.

> On the other hand, struct tty_driver is dynamically allocated
> when the driver gets initialized.
>
> So I would say that it is pretty safe to store struct console.

Okay.

> Well, you need to call con->device() to see if the tty_driver
> is actually initialized.

Agree and con->device() is already invoked here [1]. So we only need
to store struct console if con->device() invocation returns success.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/kgdboc.c#n174

-Sumit

>
> Best Regards,
> Petr

Re: [PATCH] regulator: do not balance regulators without constraints

[Marek Szyprowski]

Hi Mark,

On 28.05.2020 15:43, Mark Brown wrote:
> On Thu, May 28, 2020 at 03:11:30PM +0200, Marek Szyprowski wrote:
>> Balancing coupled regulators must wait until the clients for all of the
>> coupled regualtors set their constraints, otherwise the balancing code
>> might change the voltage of the not-yet-constrained regulator to the
>> value below the bootloader-configured operation point, what might cause a
>> system crash.
> This forces every supply to have something which explicitly manages
> voltages which means that if one of the coupled supplies doesn't really
> care about the voltage (perhaps doesn't even have any explicit
> consumers) and just needs to be within a certain range of another supply
> then it'll end up restricting things needlessly.
Frankly, that's exactly what we need for Exynos5422 case. If devfreq 
driver is not enabled/compiled, we want to keep the "vdd_int" volatage 
unchanged. This confirms me that we really need to have a custom coupler 
for Exynos5422 case. It will solve such issues without adding hacks to 
regulator core.
> Saravana was trying to do some stuff with sync_state() which might be
> interesting here although I have concerns with that approach too:
>
> https://lore.kernel.org/lkml/20200527074057.246606-1-sarava...@google.com/

This still doesn't solve the above mentioned case.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v2 2/2] tests: test seccomp filter notifications

[Kees Cook]

On Thu, May 28, 2020 at 05:14:12PM +0200, Christian Brauner wrote:
> This verifies we're correctly notified when a seccomp filter becomes
> unused when a notifier is in use.

While you're adding this, can you adjust the other user_notif tests to
check for POLLHUP as well (i.e fail if it appears)?

Otherwise, yes, tests look good. :) Yay tests!

-- 
Kees Cook

Re: [PATCH] misc: mic: Replace kmalloc with kzalloc in the error message

[Greg KH]

On Fri, May 29, 2020 at 09:01:21AM +0800, Yi Wang wrote:
> From: Liao Pingfang 
> 
> Use kzalloc instead of kmalloc in the error message according to
> the previous kzalloc() call.
> 
> Signed-off-by: Liao Pingfang 
> ---
>  drivers/misc/mic/host/mic_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mic/host/mic_main.c 
> b/drivers/misc/mic/host/mic_main.c
> index be0784f..8296f31 100644
> --- a/drivers/misc/mic/host/mic_main.c
> +++ b/drivers/misc/mic/host/mic_main.c
> @@ -164,7 +164,7 @@ static int mic_probe(struct pci_dev *pdev,
>   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
>   if (!mdev) {
>   rc = -ENOMEM;
> - dev_err(>dev, "mdev kmalloc failed rc %d\n", rc);
> + dev_err(>dev, "mdev kzalloc failed rc %d\n", rc);

The message should just be dropped as the call will print the failure
message anyway.

thanks,

greg k-h

Re: [PATCH v4 3/4] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check

[Feng Tang]

On Thu, May 28, 2020 at 10:49:28PM -0400, Qian Cai wrote:
> On Fri, May 29, 2020 at 09:06:09AM +0800, Feng Tang wrote:
> > As is explained by Michal Hocko:
> > 
> > : Looking at the history, this has been added by 82f71ae4a2b8
> > : ("mm: catch memory commitment underflow") to have a safety check
> > : for issues which have been fixed. There doesn't seem to be any bug
> > : reports mentioning this splat since then so it is likely just
> > : spending cycles for a hot path (yes many people run with DEBUG_VM)
> > : without a strong reason.
> 
> Hmm, it looks like the warning is still useful to catch issues in,
> 
> https://lore.kernel.org/linux-mm/20140624201606.18273.44270.stgit@zurg
> https://lore.kernel.org/linux-mm/54bb9a32.7080...@oracle.com/
> 
> After read the whole discussion in that thread, I actually disagree with
> Michal. In order to get ride of this existing warning, it is rather
> someone needs a strong reason that could prove the performance hit is
> noticeable with some data.

One problem with current check is percpu_counter_read(_committed_as)
is not accurate, and percpu_counter_sum() is way too heavy.

Thanks,
Feng

Re: [PATCH 1/2] mtd: spi-nor: create/Export parameter softwareseq for intel-spi driver to user

[Mika Westerberg]

Hi,

I wonder if we can "generalize" this a bit and use SW sequencer to run
commands HW sequencer does not support? The BIOS can then setup the
allowed SW sequencer opcodes and lock the thing down if needed.

There are couple of other commands related to FSR register where this
could be useful.

On Thu, May 28, 2020 at 04:16:38PM +0530, Vignesh Raghavendra wrote:
> +Mika Westerberg original author of the driver
> 
> On 18/05/20 11:29 pm, Daniel Walker wrote:
> > From: Bobby Liu 
> > 
> > How to use:
> > append softwareseq=1 while probe the driver.
> > example:
> > modprobe intel-spi writeable=1 softwareseq=1
> > it will let driver use software sequence to write register for opt=EN4B
> > by default it's 0 if not specified, driver will do usual HW cycle
> > 
> 
> Could some one from Intel please review this patch?
> 
> Regards
> Vignesh
> 
> > Why this parameter is posted to user:
> > Intel PCH provides two groups of registers for SPI flash operation,
> > Hard Sequence registers and Software Sequence registers,
> > corresponding to intel_spi_hw_cycle() and intel_spi_sw_cycle()
> > respectively in driver code. But HW sequence register won't send EN4B
> > opcode to SPI flash. BIOS code use SW register to send EN4B.
> > 
> > On some Cisco routers, two 32M SPI flashes, which require 4-byte address 
> > mode enabled,
> > are physically connected to an FPGA, one flash is active and one is 
> > inactive.
> > When we do BIOS upgrade, we need switch to the inactive one,
> > but unfortunately, this one is still 3-byte address mode as default,
> > after we do real-time switch, we need reload SPI driver to send EN4B code to
> > enable 4-byte address mode.
> > 
> > Refering to our BIOS code, Software sequence register is processed
> > while sending EN4B opcode. So here we use sw_cycle in driver for EN4B as 
> > well.
> > 
> > Why I don't just easily use software sequence for all:
> > 1.It will impact all flash operation, include flash W/R, high risk
> > 2.The only SPI type I can use is INTEL_SPI_BXT according to datasheet,
> >   this will require using hw seq.
> >   I tried to specify other SPI type, it couldn't work with Intel PCH.
> >   If I force SW seq for all, during boot up, sw_cycle fails to read
> >   vendor ID.
> > 
> > In conclusion, I only use SW cycle for EN4B opcode to minimize impact.
> > It won't impact other users as well.
> > 
> > Why the default flash can work at 4-byte address mode:
> > BIOS sets 4-byte address mode for the current active SPI flash with SW seq 
> > registers.
> > So we don't need append softwareseq=1 for normal boot up script,
> > it will only be used in BIOS upgrade script.
> > 
> > Cc: xe-linux-exter...@cisco.com
> > Signed-off-by: Bobby Liu 
> > [ danielwa: edited the commit message a little. ]
> > Signed-off-by: Daniel Walker 
> > ---
> >  drivers/mtd/spi-nor/controllers/intel-spi.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.c 
> > b/drivers/mtd/spi-nor/controllers/intel-spi.c
> > index 61d2a0ad2131..e5a3d51a2e4d 100644
> > --- a/drivers/mtd/spi-nor/controllers/intel-spi.c
> > +++ b/drivers/mtd/spi-nor/controllers/intel-spi.c
> > @@ -163,6 +163,10 @@ static bool writeable;
> >  module_param(writeable, bool, 0);
> >  MODULE_PARM_DESC(writeable, "Enable write access to SPI flash chip 
> > (default=0)");
> >  
> > +static bool softwareseq;
> > +module_param(softwareseq, bool, 0);
> > +MODULE_PARM_DESC(softwareseq, "Use software sequence for register write 
> > (default=0)");
> > +
> >  static void intel_spi_dump_regs(struct intel_spi *ispi)
> >  {
> > u32 value;
> > @@ -619,6 +623,18 @@ static int intel_spi_write_reg(struct spi_nor *nor, u8 
> > opcode, const u8 *buf,
> > if (ret)
> > return ret;
> >  
> > +   /*
> > +* Intel Skylake will not send EN4B to SPI flash if we use HW sequence
> > +* Here export one interface "softwareseq" to OS,
> > +* let driver user decide if use SW sequence or not
> > +*/
> > +   if (opcode == SPINOR_OP_EN4B && softwareseq) {
> > +   dev_info(ispi->dev,
> > +   "Write register opcode is SPINOR_OP_EN4B, do SW cycle\n");
> > +   return intel_spi_sw_cycle(ispi, opcode, len,
> > +   OPTYPE_WRITE_NO_ADDR);
> > +   }
> > +
> > if (ispi->swseq_reg)
> > return intel_spi_sw_cycle(ispi, opcode, len,
> >   OPTYPE_WRITE_NO_ADDR);
> > 

Re: [PATCH v2 1/2] seccomp: notify user trap about unused filter

[Kees Cook]

On Fri, May 29, 2020 at 01:32:03AM +0200, Jann Horn wrote:
> On Fri, May 29, 2020 at 1:11 AM Kees Cook  wrote:
> > So, is it safe to detach the filter in release_task()? Has dethreading
> > happened yet? i.e. can we race TSYNC? -- is there a possible
> > inc-from-zero?
> 
> release_task -> __exit_signal -> __unhash_process ->
> list_del_rcu(>thread_node) drops us from the thread list under
> siglock, which is the same lock TSYNC uses.

Ah, there it is. I missed the __unhash_process() in __exit_signal, but
once I saw the call to release_task(), I figured it was safe at that
point. So this seems correct:

> > I *think* we can do it
> > before the release_thread() call (instead of after cgroup_release()).

> One other interesting thing that can look at seccomp state is
> task_seccomp() in procfs - that can still happen at this point. At the
> moment, procfs only lets you see the numeric filter state, not the
> actual filter contents, so that's not a problem; but if we ever add a
> procfs interface for dumping seccomp filters (in addition to the
> ptrace interface that already exists), that's something to keep in
> mind.

Right -- but we can just reuse the get/put to pin the filter while
dumping it from proc (there IS someone working on this feature...)

> > (Actually, all our refcount_inc()s should be
> > refcount_inc_not_zero() just for robustness.)
> 
> Eeeh... wouldn't that just make the code more complicated for no good reason?

Sorry, ignore that. I got myself briefly confused -- we're fine;
refcount_inc() already does inc-from-zero checking.

-- 
Kees Cook

RE: [PATCH net-next v3] ice: Replace one-element arrays with flexible-arrays

[Kirsher, Jeffrey T]

> -Original Message-
> From: Gustavo A. R. Silva 
> Sent: Wednesday, May 27, 2020 07:11
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski 
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Gustavo A. R. Silva ;
> Kees Cook 
> Subject: [PATCH net-next v3] ice: Replace one-element arrays with flexible-
> arrays
> 
> The current codebase makes use of one-element arrays in the following
> form:
> 
> struct something {
> int length;
> u8 data[1];
> };
> 
> struct something *instance;
> 
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
> 
> but the preferred mechanism to declare variable-length types such as these
> ones is a flexible array member[1][2], introduced in C99:
> 
> struct foo {
> int stuff;
> struct boo array[];
> };
> 
> By making use of the mechanism above, we will get a compiler warning in case
> the flexible array does not occur last in the structure, which will help us 
> prevent
> some kind of undefined behavior bugs from being inadvertently introduced[3]
> to the codebase from now on. So, replace the one-element array with a
> flexible-array member.
> 
> Also, make use of the offsetof() helper in order to simplify some macros and
> properly calculate the size of the structures that contain flexible-array 
> members.
> 
> This issue was found with the help of Coccinelle and, audited _manually_.
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> 
> Signed-off-by: Gustavo A. R. Silva 
[Kirsher, Jeffrey T] 

Thanks Gustavo, but we (or I should say Bruce Allan) already has a patch to 
resolve this,
and is a bit more thorough.  I will make sure you get CC'd on the patch, for 
your review.

> ---
> Changes in v3:
>  - We still can simply the code even more by using offsetof() just once. :)
> 
> Changes in v2:
>  - Use offsetof(struct ice_aqc_sw_rules_elem, pdata) instead of
>sizeof(struct ice_aqc_sw_rules_elem) - sizeof(((struct 
> ice_aqc_sw_rules_elem
> *)0)->pdata)
>  - Update changelog text.
> 
>  .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  6 ++---
>  drivers/net/ethernet/intel/ice/ice_switch.c   | 23 ++-
>  2 files changed, 10 insertions(+), 19 deletions(-)
> 

Re: [PATCH 1/2] workqueue: pin the pool while it is managing

[Lai Jiangshan]

On Thu, May 28, 2020 at 10:35 PM Tejun Heo  wrote:
>
> Hello,
>
> On Thu, May 28, 2020 at 03:06:55AM +, Lai Jiangshan wrote:
> > @@ -2129,10 +2128,21 @@ __acquires(>lock)
> >  static bool manage_workers(struct worker *worker)
> >  {
> >   struct worker_pool *pool = worker->pool;
> > + struct work_struct *work = list_first_entry(>worklist,
> > + struct work_struct, entry);
>
> I'm not sure about this. It's depending on an external condition (active
> work item) which isn't obvious and when that condition breaks the resulting
> bug will be one which is difficult to reproduce. Adding to that, pwq isn't
> even the object this code path is interested in, which is the cause of the
> previous problem too.

Ok, I agree with you.

Thanks
Lai

linux-next: manual merge of the tip tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/firmware/efi/libstub/arm32-stub.c

between commit:

  d0f9ca9be11f ("ARM: decompressor: run decompressor in place if loaded via 
UEFI")

from the arm tree and commit:

  793473c28a4b ("efi/libstub: Move pr_efi/pr_efi_err into efi namespace")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/arm32-stub.c
index 0050d811bf20,b038afe2ee7a..
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@@ -209,10 -215,11 +209,10 @@@ efi_status_t handle_kernel_image(unsign
 * base of the kernel image is only partially used at the moment.
 * (Up to 5 pages are used for the swapper page tables)
 */
 -  kernel_base += TEXT_OFFSET - 5 * PAGE_SIZE;
 -
 -  status = reserve_kernel_base(kernel_base, reserve_addr, reserve_size);
 +  status = reserve_kernel_base(kernel_base - 5 * PAGE_SIZE, reserve_addr,
 +   reserve_size);
if (status != EFI_SUCCESS) {
-   pr_efi_err("Unable to allocate memory for uncompressed 
kernel.\n");
+   efi_err("Unable to allocate memory for uncompressed kernel.\n");
return status;
}
  


pgpJetqu1hjit.pgp
Description: OpenPGP digital signature

Re: [PATCHv2 2/2] tpm_ftpm_tee: register driver on TEE bus

[Sumit Garg]

On Thu, 28 May 2020 at 15:41, Jens Wiklander  wrote:
>
> On Thu, May 28, 2020 at 11:08:18AM +0300, Maxim Uvarov wrote:
> > On Wed, 27 May 2020 at 22:42, Jarkko Sakkinen
> >  wrote:
> > >
> > > On Mon, 2020-05-25 at 09:50 +0300, Maxim Uvarov wrote:
> > > > Jakko,
> > > > tee-supplicant application provides state machine over callbacks with
> > > > RPC messages.
> > > > https://github.com/OP-TEE/optee_client/blob/master/tee-supplicant/src/tee_supplicant.c#L614
> > > > It also allocates shm. Without running tee-supplicant
> > > > tee_client_open_session() will fail.
> > > > optee_open_session()->get_msg_arg()->tee_shm_alloc()->...
> > > > Optee team wanted to remove some dependencies from tee-supplicant with
> > > > moving code
> > > > to the kernel. But for now I think that should be out of the scope of
> > > > current patches due to
> > > > they fix driver initialization on tee bus without breaking current
> > > > functionality.
> > >
> > > So what is the role in high-level for tee-supplicant? Why does it
> > > exist? No time to dive into code unfortunately.
> > >
> >
> > Original implementation for tee-supplicant does several things:
> > 1. allocate shm
> > 2. load ta from user space (fs file)
> > 3. emulate rpmb
> > 4. also there are some ftrace and socket functions which I did not use.
> >
> > As I I understand, current implementation uses tee-supplicant and it's
> > library as
> > API from user land to Trusted OS.
> >
> > Some docs can be found here:
> > https://optee.readthedocs.io/en/latest/architecture/index.html
> >
> >
> >
> > > These kernel commits do not explain in simple terms enough how all
> > > of these entities connect with each other, if you don't have that
> > > understanding beforehand.
> > >
> >
> > Yes, that is true. But I think it's something new and good docs will
> > be some time later.
>
> There's already some in Documentation/tee.txt, but it will get outdated
> if we don't update it when we architectural changes like this. It's a
> pity we missed updating it with the introduction of the bus. It seems a
> good time to do it now so it easier to follow what's done.

Agree, let me try to update documentation for TEE bus. Will share it
as a separate patch.

-Sumit

>
> Cheers,
> Jens
>
> >
> > > /Jarkko
> > >
> >
> > Regards,
> > Maxim.

RE: [PATCH 1/4] exfat: redefine PBR as boot_sector

[Sungjong Seo]

> > [snip]
> >> +/* EXFAT: Main and Backup Boot Sector (512 bytes) */ struct
> >> +boot_sector {
> >> +  __u8jmp_boot[BOOTSEC_JUMP_BOOT_LEN];
> >> +  __u8oem_name[BOOTSEC_OEM_NAME_LEN];
> >
> > According to the exFAT specification, fs_name and BOOTSEC_FS_NAME_LEN
> > look better.
> 
> Oops.
> I sent v2 patches, before I noticed this comment,
> 
> I'll make another small patch, OK?

No, It make sense to make v3, because you have renamed the variables in
boot_sector on this patch.

> BTW
> I have a concern about fs_name.
> The exfat specification says that this field is "EXFAT".
> 
> I think it's a important field for determining the filesystem.
> However, in this patch, I gave up checking this field.
> Because there is no similar check in FATFS.
> Do you know why Linux FATFS does not check this filed?
> And, what do you think of checking this field?

FATFS has the same field named "oem_name" and whatever is okay for its value.
However, in case of exFAT, it is an important field to determine filesystem.

I think it would be better to check this field for exFAT-fs.
Would you like to contribute new patch for checking it?

> 
> BR

Re: [PATCH v3 00/14] mtd: spi-nor: add xSPI Octal DTR support

[masonccyang]

Hi Boris,

> > 
> > 
> > Summary of change log
> > v3:
> > Add support command sequences to change octal DTR mode and based on
> > part of Pratyush's patches set.
> > 
> > v2: 
> > Parse BFPT & xSPI table for Octal 8D-8D-8D mode parameters and enable 
Octal
> > mode in spi_nor_late_init_params().
> > Using Macros in spi_nor_spimem_read_data, spi_nor_spimem_write_data 
and
> > so on by Vignesh comments.
> > 
> > v1:
> > Without parsing BFPT & xSPI profile 1.0 table and enter Octal 8D-8D-8D
> > mode directly in spi_nor_fixups hooks.
> > 
> > 
> > thnaks for your time and review.
> > best regards,
> > Mason
> > 
> > --
> > Mason Yang (7):
> >   mtd: spi-nor: sfdp: get octal mode maximum speed from BFPT
> >   mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
> >   mtd: spi-nor: sfdp: parse command sequences to change octal DTR mode
> >   mtd: spi-nor: core: add configuration register 2 read & write 
support
> >   spi: mxic: patch for octal DTR mode support
> >   mtd: spi-nor: core: execute command sequences to change octal DTR 
mode
> >   mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix
> > mx25uw51245g
> > 
> > Pratyush Yadav (7):
> >   spi: spi-mem: allow specifying whether an op is DTR or not
> >   spi: spi-mem: allow specifying a command's extension
> >   mtd: spi-nor: add support for DTR protocol
> >   mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D
> >   mtd: spi-nor: sfdp: get command opcode extension type from BFPT
> >   mtd: spi-nor: core: use dummy cycle and address width info from SFDP
> >   mtd: spi-nor: core: enable octal DTR mode when possible
> 
> Why are you doing that?! This series is being actively worked on by
> Pratyush, and all you gain by sending it on your own is more
> confusion. If you have patches on top of a series that's not been
> merged yet, mention the dependency in the cover letter, but don't
> resend patches that have already been sent and are being reviewed.

okay, much thank for your comments.
Will re-submit and mention the dependency in my cover letter.

Hi Pratyush,
Sorry if these patches make you uncomfortable.

> 
> I think it's time you spend a bit of time learning about the submission
> process, because that's not the first mistake you do, and I'm pretty
> sure I already mentioned that in my previous reviews.

best regards,
Mason

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=





CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or 
personal data, which is protected by applicable laws. Please be reminded that 
duplication, disclosure, distribution, or use of this e-mail (and/or its 
attachments) or any part thereof is prohibited. If you receive this e-mail in 
error, please notify us immediately and delete this mail as well as its 
attachment(s) from your system. In addition, please be informed that 
collection, processing, and/or use of personal data is prohibited unless 
expressly permitted by personal data protection laws. Thank you for your 
attention and cooperation.

Macronix International Co., Ltd.

=

Re: next-20200528 - build error in kernel/rcu/refperf.c

[Valdis Klētnieks]

On Thu, 28 May 2020 21:48:18 -0700, Randy Dunlap said:

> > ERROR: modpost: "__aeabi_uldivmod" [kernel/rcu/refperf.ko] undefined!

Gaah.  And the reason I didn't spot Paul's post while grepping my linux-kernel
mailbox is because *that* thread had a different undefined reference:

> > > > > > m68k-linux-ld: kernel/rcu/refperf.o: in function `main_func':
> > > > > > >> refperf.c:(.text+0x762): undefined reference to `__umoddi3'

> Paul has already responded: (unfortunately)
>
> "So I am restricting to 64BIT for the time being.  Yeah, I know, lazy of
> me.  ;-)"

It's the sort of issue that's well into "as long as it gets mostly fixed before
it hits Linus's tree" territory.   I've seen lots of far worse work-arounds in
the years since the 2.5.47 kernel. :)







pgphPzLQIiLb8.pgp
Description: PGP signature

Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU

[Jassi Brar]

On Thu, May 28, 2020 at 2:20 PM Rob Herring  wrote:
>
> On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> > From: Sudeep Holla 
> >
> > Hi Rob, Arnd and Jassi,
> >
> > This stuff has been doing rounds on the mailing list since several years
> > now with no agreed conclusion by all the parties. And here is another
> > attempt to get some feedback from everyone involved to close this once
> > and for ever. Your comments will very much be appreciated.
> >
> > The ARM MHU is defined here in the TRM [1] for your reference, which
> > states following:
> >
> >   "The MHU drives the signal using a 32-bit register, with all 32
> >   bits logically ORed together. The MHU provides a set of
> >   registers to enable software to set, clear, and check the status
> >   of each of the bits of this register independently.  The use of
> >   32 bits for each interrupt line enables software to provide more
> >   information about the source of the interrupt. For example, each
> >   bit of the register can be associated with a type of event that
> >   can contribute to raising the interrupt."
> >
> > On few other platforms, like qcom, similar doorbell mechanism is present
> > with separate interrupt for each of the bits (that's how I understood
> > it), while in case of ARM MHU, there is a single interrupt line for all
> > the 32 bits. Also in case of ARM MHU, these registers and interrupts
> > have 3 copies for different priority levels, i.e. low priority
> > non-secure, high priority non-secure and secure channels.
> >
> > For ARM MHU, both the dt bindings and the Linux driver support 3
> > channels for the different priorities right now and support sending a 32
> > bit data on every transfer in a locked fashion, i.e. only one transfer
> > can be done at once and the other have to wait for it to finish first.
> >
> > Here are the point of view of the parties involved on this subject:
> >
> > Jassi's viewpoint:
> >
> > - Virtualization of channels should be discouraged in software based on
> >   specific usecases of the application. This may invite other mailbox
> >   driver authors to ask for doing virtualization in their drivers.
> >
> > - In mailbox's terminology, every channel is equivalent to a signal,
> >   since there is only one signal generated here by the MHU, there should
> >   be only one channel per priority level.
> >
> > - The clients should send data (of just setting 1 bit or many in the 32
> >   bit word) using the existing mechanism as the delays due to
> >   serialization shouldn't be significant anyway.
> >
> > - The driver supports 90% of the users with the current implementation
> >   and it shouldn't be extended to support doorbell and implement two
> >   different modes by changing value of #mbox-cells field in bindings.
> >
> > Sudeep (ARM) and myself as well to some extent:
> >
> > - The hardware gives us the capability to write the register in
> >   parallel, i.e. we can write 0x800 and 0x400 together without any
> >   software locks, and so these 32 bits should be considered as separate
> >   channel even if only one interrupt is issued by the hardware finally.
> >   This shouldn't be called as virtualization of the channels, as the
> >   hardware supports this (as clearly mentioned in the TRM) and it takes
> >   care of handling the signal properly.
> >
> > - With serialization, if we use only one channel as today at every
> >   priority, if there are 5 requests to send signal to the receiver and
> >   the dvfs request is the last one in queue (which may be called from
> >   scheduler's hot path with fast switching), it unnecessarily needs to
> >   wait for the first four transfers to finish due to the software
> >   locking imposed by the mailbox framework. This adds additional delay,
> >   maybe of few ms only, which isn't required by the hardware but just by
> >   the software and few ms can be important in scheduler's hotpath.
> >
> > - With the current approach it isn't possible to assign different bits
> >   (or doorbell numbers) to clients from DT and the only way of doing
> >   that without adding new bindings is by extending #mbox-cells to accept
> >   a value of 2 as done in this patch.
> >
> > Jassi and Sudeep, I hope I was able to represent both the view points
> > properly here. Please correct me if I have made a mistake here.
> >
> > This is it. It would be nice to get the views of everyone now on this
> > and how should this be handled.
>
> I am perfectly fine with adding another cell which seems appropriate
> here. You can have 5 cells for all I care if that makes sense for
> the h/w. That has nothing to do with the Linux design. Whether Linux
> requires serializing mailbox accesses is a separate issue. On that side,
> it seems silly to not allow driving the h/w in the most efficient way
> possible.
>
The fact that all these bits are backed by one physical signal makes
the firmware implement its own mux-demux'ing scheme. So the choice 

Re: [PATCH] OPP: Check for bandwidth values before creating icc paths

[Viresh Kumar]

On 28-05-20, 00:54, Sibi Sankar wrote:
> Prevent the core from creating and voting on icc paths when the
> opp-table does not have the bandwidth values populated. Currently
> this check is performed on the first OPP node.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  drivers/opp/of.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 61fce1284f012..95cf6f1312765 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -338,6 +338,21 @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
>   struct device_node *np;
>   int ret = 0, i, count, num_paths;
>   struct icc_path **paths;
> + struct property *prop;
> +
> + /* Check for bandwidth values on the first OPP node */
> + if (opp_table && opp_table->np) {
> + np = of_get_next_available_child(opp_table->np, NULL);
> + if (!np) {
> + dev_err(dev, "Empty OPP table\n");
> + return 0;
> + }
> +
> + prop = of_find_property(np, "opp-peak-kBps", NULL);
> + of_node_put(np);
> + if (!prop || !prop->length)
> + return 0;
> + }

This doesn't support the call made from cpufreq-dt driver. Pushed
this, please give this a try:

From: Sibi Sankar 
Date: Thu, 28 May 2020 00:54:18 +0530
Subject: [PATCH] opp: Don't parse icc paths unnecessarily

The DT node of the device may contain interconnect paths while the OPP
table doesn't have the bandwidth values. There is no need to parse the
paths in such cases.

Signed-off-by: Sibi Sankar 
[ Viresh: Support the case of !opp_table and massaged changelog ]
Signed-off-by: Viresh Kumar 
---
 drivers/opp/of.c | 45 -
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 61fce1284f01..8c1bf01f0e50 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -332,13 +332,56 @@ static int _of_opp_alloc_required_opps(struct opp_table 
*opp_table,
return ret;
 }
 
+static int _bandwidth_supported(struct device *dev, struct opp_table 
*opp_table)
+{
+   struct device_node *np, *opp_np;
+   struct property *prop;
+
+   if (!opp_table) {
+   np = of_node_get(dev->of_node);
+   if (!np)
+   return -ENODEV;
+
+   opp_np = _opp_of_get_opp_desc_node(np, 0);
+   of_node_put(np);
+
+   /* Lets not fail in case we are parsing opp-v1 bindings */
+   if (!opp_np)
+   return 0;
+   } else {
+   opp_np = of_node_get(opp_table->np);
+   }
+
+   /* Checking only first OPP is sufficient */
+   np = of_get_next_available_child(opp_np, NULL);
+   if (!np) {
+   dev_err(dev, "OPP table empty\n");
+   return -EINVAL;
+   }
+   of_node_put(opp_np);
+
+   prop = of_find_property(np, "opp-peak-kBps", NULL);
+   of_node_put(np);
+
+   if (!prop || !prop->length)
+   return 0;
+
+   return 1;
+}
+
 int dev_pm_opp_of_find_icc_paths(struct device *dev,
 struct opp_table *opp_table)
 {
struct device_node *np;
-   int ret = 0, i, count, num_paths;
+   int ret, i, count, num_paths;
struct icc_path **paths;
 
+   ret = _bandwidth_supported(dev, opp_table);
+   if (ret <= 0)
+   return ret;
+
+   ret = 0;
+
np = of_node_get(dev->of_node);
if (!np)
return 0;

-- 
viresh

[tip:ras/core] BUILD SUCCESS 45811ba140593e288a288c2a2e45d25f38d20d73

[kbuild test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
ras/core
branch HEAD: 45811ba140593e288a288c2a2e45d25f38d20d73  x86/mce/dev-mcelog: Fix 
-Wstringop-truncation warning about strncpy()

elapsed time: 2010m

configs tested: 100
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
xtensa virt_defconfig
arm   milbeaut_m10v_defconfig
arm  lpd270_defconfig
openrisc alldefconfig
mips  malta_kvm_defconfig
arm rpc_defconfig
arm assabet_defconfig
armmulti_v5_defconfig
arm  simpad_defconfig
m68kmac_defconfig
arc nsimosci_hs_defconfig
armmvebu_v5_defconfig
arcnsim_700_defconfig
armmvebu_v7_defconfig
mips  maltaaprp_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a013-20200529
i386 randconfig-a011-20200529
i386 randconfig-a012-20200529
i386 randconfig-a015-20200529
i386 randconfig-a016-20200529
i386 randconfig-a014-20200529
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390  allnoconfig
s390defconfig
s390 allyesconfig
s390 allmodconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
um   allmodconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64  kexec

---
0-DAY CI Kernel Test 

Re: Some -serious- BPF-related litmus tests

[Andrii Nakryiko]

On Thu, May 28, 2020 at 3:17 PM Peter Zijlstra  wrote:
>
> On Thu, May 28, 2020 at 06:00:47PM -0400, Joel Fernandes wrote:
>
> > Any idea why this choice of locking-based ring buffer implementation in BPF?
> > The ftrace ring buffer can support NMI interruptions as well for writes.
> >
> > Also, is it possible for BPF to reuse the ftrace ring buffer implementation
> > or does it not meet the requirements?
>
> Both perf and ftrace are per-cpu, which, according to the patch
> description is too much memory overhead for them. Neither have ever
> considered anything else, atomic ops are expensive.

Right, as mentioned in commit description to [0], desire to use shared
ring buffer across multiple CPUs to save memory and absorb bigger
spikes with overall lower memory use was one of main motivations.
Ordered events was another one. Both perf buffer and ftrace buffer use
strictly per-CPU buffers, which in practice makes a lot of developers
make hard and non-obvious choice between using too much memory or
losing too much events due to running out of space in a buffer.

  [0] 
https://patchwork.ozlabs.org/project/netdev/patch/20200526063255.1675186-2-andr...@fb.com/

>
> On top of that, they want multi-producer support. Yes, doing that gets
> interesting really fast, but using spinlocks gets you a trainwreck like
> this.
>
> This thing so readily wanting to drop data on the floor should worry

It's true that *in NMI context*, if spinlock is already taken,
reservation will fail, so under high contention there will be
potentially high number of drops. So for such cases perfbuf might be a
better approach and BPF applications will have to deal with higher
memory usage. In practice, though, most BPF programs are not running
in NMI context, so there won't be any drop due to spinlock usage.
Having both perfbuf and this new BPF ringbuf gives people choice and
more options to tailor to their needs.

There is another cluster of applications which are unnecessarily more
complicated just for the fact that there is no ordering between
correlated events that happen on different CPUs. Per-CPU buffers are
not well suited for such cases, unfortunately.

> people, but apparently they've not spend enough time debugging stuff
> with partial logs yet. Of course, bpf_prog_active already makes BPF
> lossy, so maybe they went with that.

Not sure which "partial logs" you mean, I'll assume dropped samples?
All production BPF applications are already designed to handle data
loss, because it could and does happen due to running out of buffer
space. Of course, amount of such drops is minimized however possible,
but applications still need to be able to handle that.

Now, though, there will be more options. Now it's not just a question
of whether to allocate a tiny 64KB per-CPU buffer on 80 core server
and use reasonable 5MB for perfbuf overall, but suffer high and
frequent data loss whenever a burst of incoming events happen. Or bump
it up to, say, 256KB (or higher) and use 20MB+ now, which most of the
time will be completely unused, but be able to absorb 4x more events.
Now it might be more than enough to just allocate a single shared 5MB
buffer and be able to absorb much higher spikes (of course, assuming
not all CPUs will be spiking at the same time, in which case nothing
can really help you much w.r.t. data loss).

So many BPF users are acutely aware of data loss and care a lot, but
there are other constraints that they have to take into account.

As for expensiveness of spinlock and atomics, a lot of applications we
are seeing do not require huge throughput that per-CPU data structures
provide, so such overhead is acceptable. Even under high contention,
BPF ringbuf performance is pretty reasonable and will satisfy a lot of
applications, see [1].

  [1] 
https://patchwork.ozlabs.org/project/netdev/patch/20200526063255.1675186-5-andr...@fb.com/

>
> All reasons why I never bother with BPF, aside from it being more
> difficult than hacking up a kernel in the first place.

It's not my goal to pitch BPF here, but for a lot of real-world use
cases, hacking kernel is not an option at all, for many reasons. One
of them is that kernel upgrades across huge fleet of servers take a
long time, which teams can't afford to wait. In such cases, BPF is a
perfect solution, which can't be beaten, as evidenced by a wide
variety of BPF applications solving real problems.

不況に強い社会福祉事業 新規参入オンラインセミナー

[社会福祉プロジェクト]

代表者様

社会福祉事業を応援するメディアを運営しております
社会福祉プロジェクトと申します。

今、新規事業をお考えの経営者様を対象に
社会福祉事業が大変注目されているのを
ご存知でしょうか？


今月複数回にわたって開催された
社会福祉プロジェクトオンラインセミナーも
大変な盛会のうちに終える事となりました。

社会福祉プロジェクトセミナーを少しのぞいてみる。
https://fukushi-service.work/seminar/


実際にセミナーに参加された方からも

「福祉総合企業というビジネスモデルが
印象的でした。」

「リピート率が高い、高収益、貢献ビジネス。
青山先生の熱意に感銘を受けました。」

「国を相手にする手堅いビジネスであること。
実は同様の事を目立たずにやっている人達が
いることが知れた。」

「労働時間に対して売り上げが高いことに
驚きました。」


などなど

ここでは全部紹介しきれませんが
参加後のアンケートでも93.6%の方から
大変満足の声をいただきました。

社会福祉プロジェクトセミナーを少しのぞいてみる。
https://fukushi-service.work/seminar/

今月24日が最後のセミナー開催でしたが
大変好評の声をいただいており

もう一度この優れたビジネスモデルについて
知っていただく機会を特別に設ける事にしました。

この特別開催のお知らせを告知して早速申し込みの
数も殺到しており、残り枠数も大変少なくなってきて
おります。

「やっぱりあの時話だけでも聞いておくべきだった。」
と後から後悔するまえに

まずは参加枠の確保をしていただく事を
強くオススメ致します。


社会福祉プロジェクトセミナーの残り席数と日程を確認する。
https://fukushi-service.work/seminar/


大切なお子様をお預かりする福祉事業
を、ビジネスと呼ぶのは少し抵抗がありますが

収益面でも充実しなければ、質の高い
サービスを提供する事も困難になります。

このセミナーでお伝えするのは

福祉事業を通じた高い社会貢献の実現と、
資産形成含め、効果実証済みのビジネスモデルを
活用した安定した収益の確保。

この２つを両立させ、物心両面を満たす
再現性ある経営ノウハウについてです。

社会福祉プロジェクトセミナーの残り席数と日程を確認する。
https://fukushi-service.work/seminar/


特に人一倍働いているのに、利益が
なかなか伸びない。上がらない。

自分が働けなくなったら、事業として
成り立たない。

人財がなかなか定着しない。育たない。


そのような事でお悩みの経営者の方や
事業主の方に、知っていただきたい内容です。

次回セミナー開催の予定はございません。

今回がラストチャンスとなるかもしれませんので
少しでも興味がある方は

この機を逃さず物心両面を満たすノウハウを
手に入れて下さい。

社会福祉プロジェクト最終セミナーの残り席数と日程を確認する。
https://fukushi-service.work/seminar/


それでは、当日お会いできる事を
楽しみにしております。


主催：社会福祉プロジェクト

-
社会福祉プロジェクト

i...@fukushi-service.work
https://fukushi-service.work/seminar/

〒531-0072
大阪府大阪市北区豊崎２丁目７−９いずみビル4F
TEL : 06--4030
-

配信停止をご希望の方は下記ＵＲＬより
ご登録いただくか、本メールにそのまま
『配信停止』の旨を記載しご返信をお願いいたします。
配信停止フォーム：https://form2dm.site/kaijo/

Re: [PATCH] twist: allow converting pr_devel()/pr_debug() into printk(KERN_DEBUG)

[Tetsuo Handa]

On 2020/05/29 11:04, Sergey Senozhatsky wrote:
> You are not going to add pr_debug() all over the kernel, are you?

Of course, I'm not planning to add pr_debug() all over the kernel.

When I need to print something to consoles, I will use one-time patch
(like https://syzkaller.appspot.com/text?tag=Patch=135f254a10 ) for
adding custom printk() and turning on some switches for making existing
printk() calls work.

Re: [PATCH v30 08/20] x86/sgx: Add functions to allocate and free EPC pages

[Jarkko Sakkinen]

On Thu, May 28, 2020 at 08:37:16PM -0700, Sean Christopherson wrote:
> On Fri, May 29, 2020 at 06:28:16AM +0300, Jarkko Sakkinen wrote:
> > On Thu, May 28, 2020 at 12:59:17PM -0700, Sean Christopherson wrote:
> > > On Thu, May 28, 2020 at 10:07:18PM +0300, Jarkko Sakkinen wrote:
> > > >  * sgx_grab_page() - Grab a free EPC page
> > > >  * @owner:  the owner of the EPC page
> > > >  * @reclaim:reclaim pages if necessary
> > > >  *
> > > >  * Iterate through EPC sections and borrow a free EPC page to the 
> > > > caller. When a
> > > >  * page is no longer needed it must be released with sgx_free_page(). If
> > > >  * @reclaim is set to true, directly reclaim pages when we are out of 
> > > > pages. No
> > > >  * mm's can be locked when @reclaim is set to true.
> > > >  *
> > > >  * Finally, wake up ksgxswapd when the number of pages goes below the 
> > > > watermark
> > > >  * before returning back to the caller.
> > > >  *
> > > >  * Return:
> > > >  *   an EPC page,
> > > >  *   -errno on error
> > > >  */
> > > > 
> > > > I also rewrote the kdoc.
> > > > 
> > > > I do agree that sgx_try_grab_page() should be renamed as 
> > > > __sgx_grab_page().
> > > 
> > > FWIW, I really, really dislike "grab".  The nomenclature for normal memory
> > > and pages uses "alloc" when taking a page off a free list, and "grab" when
> > > elevating the refcount.  I don't understand the motivation for diverging
> > > from that.  SGX is weird enough as is, using names that don't align with
> > > exist norms will only serve to further obfuscate the code.
> > 
> > OK, what would be a better name then? The semantics are not standard
> > memory allocation semantics in the first place. And kdoc in v30 speaks
> > about grabbing.
> 
> In what way are they not standard allocation semantics?  sgx_alloc_page()
> is an API to allocate (EPC) memory on-demand, sgx_free_page() is its partner
> to free that memory when it is no longer needed.  There are many different
> ways to manage and allocate memory, but the basic premise is the same for
> all and no different than what we're doing.

I'll go with sgx_alloc_epc_page(). It is more precise name.

It's not as precise as sgx_alloc_epc_page_from_section but is a great
compromise between scree estate and clarity of expression :-)

/Jarkko

Re: [PATCHES] uaccess i915

[Jani Nikula]

On Fri, 29 May 2020, Al Viro  wrote:
>   Low-hanging fruit in i915 uaccess-related stuff.
> There's some subtler stuff remaining after that; these
> are the simple ones.

Please Cc: intel-...@lists.freedesktop.org for i915 changes.

Also added Chris who I believe will be able to best review the changes.


BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [02/12] net: hns3: Destroy a mutex after initialisation failure in hclge_init_ae_dev()

[Markus Elfring]

>>> Add a mutex destroy call in hclge_init_ae_dev() when fails.
>>
>> How do you think about a wording variant like the following?
…
> It looks better. I will try to improve the skill of patch description
> and make as many as people can understand the patch.

Thanks for your positive feedback.

I suggest to avoid also a typo in the function name of the patch subject.

Regards,
Markus

Re: [PATCH v5 4/6] clocksource/drivers/timer-riscv: Use per-CPU timer interrupt

[Atish Patra]

On Thu, May 21, 2020 at 6:34 AM Anup Patel  wrote:
>
> Instead of directly calling RISC-V timer interrupt handler from
> RISC-V local interrupt conntroller driver, this patch implements
> RISC-V timer interrupt as a per-CPU interrupt using per-CPU APIs
> of Linux IRQ subsystem.
>
> Signed-off-by: Anup Patel 
> ---
>  arch/riscv/include/asm/irq.h  |  2 --
>  drivers/clocksource/timer-riscv.c | 30 +++---
>  drivers/irqchip/irq-riscv-intc.c  |  8 
>  3 files changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
> index a9e5f07a7e9c..9807ad164015 100644
> --- a/arch/riscv/include/asm/irq.h
> +++ b/arch/riscv/include/asm/irq.h
> @@ -10,8 +10,6 @@
>  #include 
>  #include 
>
> -void riscv_timer_interrupt(void);
> -
>  #include 
>
>  #endif /* _ASM_RISCV_IRQ_H */
> diff --git a/drivers/clocksource/timer-riscv.c 
> b/drivers/clocksource/timer-riscv.c
> index c4f15c4068c0..5fb7c5ba5c91 100644
> --- a/drivers/clocksource/timer-riscv.c
> +++ b/drivers/clocksource/timer-riscv.c
> @@ -14,6 +14,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>
> @@ -39,6 +42,7 @@ static int riscv_clock_next_event(unsigned long delta,
> return 0;
>  }
>
> +static unsigned int riscv_clock_event_irq;
>  static DEFINE_PER_CPU(struct clock_event_device, riscv_clock_event) = {
> .name   = "riscv_timer_clockevent",
> .features   = CLOCK_EVT_FEAT_ONESHOT,
> @@ -74,30 +78,35 @@ static int riscv_timer_starting_cpu(unsigned int cpu)
> struct clock_event_device *ce = per_cpu_ptr(_clock_event, cpu);
>
> ce->cpumask = cpumask_of(cpu);
> +   ce->irq = riscv_clock_event_irq;
> clockevents_config_and_register(ce, riscv_timebase, 100, 0x7fff);
>
> -   csr_set(CSR_IE, IE_TIE);
> +   enable_percpu_irq(riscv_clock_event_irq,
> + irq_get_trigger_type(riscv_clock_event_irq));
> return 0;
>  }
>
>  static int riscv_timer_dying_cpu(unsigned int cpu)
>  {
> -   csr_clear(CSR_IE, IE_TIE);
> +   disable_percpu_irq(riscv_clock_event_irq);
> return 0;
>  }
>
>  /* called directly from the low-level interrupt handler */
> -void riscv_timer_interrupt(void)
> +static irqreturn_t riscv_timer_interrupt(int irq, void *dev_id)
>  {
> struct clock_event_device *evdev = this_cpu_ptr(_clock_event);
>
> csr_clear(CSR_IE, IE_TIE);
> evdev->event_handler(evdev);
> +
> +   return IRQ_HANDLED;
>  }
>
>  static int __init riscv_timer_init_dt(struct device_node *n)
>  {
> int cpuid, hartid, error;
> +   struct of_phandle_args oirq;
>
> hartid = riscv_of_processor_hartid(n);
> if (hartid < 0) {
> @@ -115,6 +124,13 @@ static int __init riscv_timer_init_dt(struct device_node 
> *n)
> if (cpuid != smp_processor_id())
> return 0;
>
> +   oirq.np = riscv_of_intc_domain_node();
> +   oirq.args_count = 1;
> +   oirq.args[0] = RV_IRQ_TIMER;
> +   riscv_clock_event_irq = irq_create_of_mapping();
> +   if (!riscv_clock_event_irq)
> +   return -ENODEV;
> +

As the error case will result in a system without a clock, a warning message
may be a good option.

> pr_info("%s: Registering clocksource cpuid [%d] hartid [%d]\n",
>__func__, cpuid, hartid);
> error = clocksource_register_hz(_clocksource, riscv_timebase);
> @@ -126,6 +142,14 @@ static int __init riscv_timer_init_dt(struct device_node 
> *n)
>
> sched_clock_register(riscv_sched_clock, 64, riscv_timebase);
>
> +   error = request_percpu_irq(riscv_clock_event_irq,
> +   riscv_timer_interrupt,
> +   "riscv-timer", _clock_event);
> +   if (error) {
> +   pr_err("registering percpu irq failed [%d]\n", error);
> +   return error;
> +   }
> +
> error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
>  "clockevents/riscv/timer:starting",
>  riscv_timer_starting_cpu, riscv_timer_dying_cpu);
> diff --git a/drivers/irqchip/irq-riscv-intc.c 
> b/drivers/irqchip/irq-riscv-intc.c
> index 2f364e6a87f9..d4fbc3543459 100644
> --- a/drivers/irqchip/irq-riscv-intc.c
> +++ b/drivers/irqchip/irq-riscv-intc.c
> @@ -23,20 +23,12 @@ static struct irq_domain *intc_domain;
>
>  static asmlinkage void riscv_intc_irq(struct pt_regs *regs)
>  {
> -   struct pt_regs *old_regs;
> unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG;
>
> if (unlikely(cause >= BITS_PER_LONG))
> panic("unexpected interrupt cause");
>
> switch (cause) {
> -   case RV_IRQ_TIMER:
> -   old_regs = set_irq_regs(regs);
> -   irq_enter();
> -   riscv_timer_interrupt();
> -   irq_exit();
> - 

Re: [PATCH net-next v3] net: phy: micrel: add phy-mode support for the KSZ9031 PHY

[Oleksij Rempel]

On Thu, May 28, 2020 at 06:08:39PM +0200, Andrew Lunn wrote:
> On Thu, May 28, 2020 at 03:10:06PM +0200, Geert Uytterhoeven wrote:
> > Hi Andrew,
> > 
> > On Wed, May 27, 2020 at 10:52 PM Andrew Lunn  wrote:
> > > > You may wonder what's the difference between 3 and 4? It's not just the
> > > > PHY driver that looks at phy-mode!
> > > > drivers/net/ethernet/renesas/ravb_main.c:ravb_set_delay_mode() also
> > > > does, and configures an additional TX clock delay of 1.8 ns if TXID is
> > > > enabled.
> > >
> > > That sounds like a MAC bug. Either the MAC insert the delay, or the
> > > PHY does. If the MAC decides it is going to insert the delay, it
> > > should be masking what it passes to phylib so that the PHY does not
> > > add a second delay.
> > 
> > And so I gave this a try, and modified the ravb driver to pass "rgmii"
> > to the PHY if it has inserted a delay.
> > That fixes the speed issue on R-Car M3-W!
> > And gets rid of the "*-skew-ps values should be used only with..."
> > message.
> > 
> > I also tried if I can get rid of "rxc-skew-ps = <1500>". After dropping
> > the property, DHCP failed.  Compensating by changing the PHY mode in DT
> > from "rgmii-txid" to "rgmii-id" makes it work again.
> 
> In general, i suggest that the PHY implements the delay, not the MAC.
> Most PHYs support it, where as most MACs don't. It keeps maintenance
> and understanding easier, if everything is the same. But there are
> cases where the PHY does not have the needed support, and the MAC does
> the delays.
> 
> > However, given Philippe's comment that the rgmi-*id apply to the PHY
> > only, I think we need new DT properties for enabling MAC internal delays.
> 
> Do you actually need MAC internal delays?
> 
> > That description is not quite correct: the driver expects skews for
> > plain RGMII only. For RGMII-*ID, it prints a warning, but still applies
> > the supplied skew values.
> 
> O.K. so not so bad.
> 
> > 
> > To fix the issue, I came up with the following problem statement and
> > plan:
> > 
> > A. Old behavior:
> > 
> >   1. ravb acts upon "rgmii-*id" (on SoCs that support it[1]),
> >   2. ksz9031 ignored "rgmii-*id", using hardware defaults for skew
> >  values.
> 
> So two bugs which cancelled each other out :-)
> 
> > B. New behavior (broken):
> > 
> >   1. ravb acts upon "rgmii-*id",
> >   2. ksz9031 acts upon "rgmii-*id".
> > 
> > C. Quick fix for v5.8 (workaround, backwards-compatible with old DTB):
> > 
> >   1. ravb acts upon "rgmii-*id", but passes "rgmii" to phy,
> >   2. ksz9031 acts upon "rgmi", using new "rgmii" skew values.
> > 
> > D. Long-term fix:
> 
> I don't know if it is possible, but i would prefer that ravb does
> nothing and the PHY does the delay. The question is, can you get to
> this state without more things breaking?

Some MACs, for example the Atheros AG71XX support delay configuration as
well. But it support also the clock direction. It means (please correct me if
i'm wrong), the MAC can be configured to act as PHY. The same is about
switches, the MAC attached to CPU is act as a PHY and should care about proper
delay configuration.

Regards,
Oleksij

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: nilfs2: Fix reference count leak in nilfs_sysfs_create_snapshot_group()

[Markus Elfring]

> I think there is only one object that can be modified in this function,

Such a view can be reasonable.


> so I didn't mention it.

I suggest to reconsider the conclusion.


>> I guess that an imperative wording is preferred also for this change 
>> description.
>
> This sentence is referenced from the code comment, so I haven't change it.
> https://elixir.bootlin.com/linux/v5.7-rc7/source/lib/kobject.c#L459

I find that that there are further possibilities to consider for improvements
around the presented commit message (even after the mentioned copy
from the function description of this programming interface).


>> How do you think about to combine this update step together with
>> “nilfs2: Fix reference count leak in nilfs_sysfs_create_device_group”
>> into a small patch series?
>
> I'd like to improve the similar issues after I reporting this bunch of bugs.

Did you find questionable implementation details with the help of an evolving
source code analysis tool?

Regards,
Markus

Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf()

[Tetsuo Handa]

On 2020/05/29 11:24, Linus Torvalds wrote:
> Some flags do end up having to be practically system-wide, because
> they end up being used in contexts other than the test environment (ie
> anything that ends up doing workqueues or networking or VM or whatever
> - it's a "global context").

Right. And since fuzz testing can't determine whether it will involve
"global context", the options for fuzz testing (currently referenced as
"twist") can't be "per process". It might be possible to make the twist
options "per boot", but we are conflicting on whether making the twist
options "per boot" worth the effort.

> At the same time, some of the flags might well be "in the test
> environment" if they act on behavior that is all synchronous. Then
> other testers can use them on production machines for testing, even
> when the kernel might be used for other things at the same time.

I don't think that people use their machines for testing and non-testing
at the same time. When testing kernels, people enable a lot of debugging
kernel config options (e.g. KASAN, lockdep) because finding bugs has
higher priority than faster kernels. Some of debugging functionality
could be enabled/disabled using kernel command line, but it is hardly
possible to convert such debugging functionality into "per process".
It is much safer to run a qemu-kvm instance on their machines if they
want to test kernels without affecting the rest of their machines.

> And absolutely none of this should be named "twist". If you can't make
> a config have a sane name that talks about what it does, then it
> shouldn't exist at all.

CONFIG_TWIST_* options are analogy of CONFIG_DEBUG_* options.
The TWIST part is a prefix for grouping. If you don't like the grouping,
it is just a matter of renaming CONFIG_TWIST_* options.

> And making that a build-time option is the worst of all worlds.

Can we avoid discussing "the config option naming" (which is build-time
things) and "the kernel command line option" (which is boot-time things)
at the same time? What I am saying is

 THE TWIST OPTIONS ARE INTENDED FOR "IMPROVING THE QUALITY OF KERNEL TESTING"

which will in turn help improving the quality of kernel itself, and your
insistence on making them boot-time things (which might increase flexibility
for users) can decrease the reliability/robustness of testing.

Re: next-20200528 - build error in kernel/rcu/refperf.c

[Randy Dunlap]

On 5/28/20 9:16 PM, Valdis Klētnieks wrote:
> commit 9088b449814f788d24f35a5840b6b2c2a23cd32a
> Author: Paul E. McKenney 
> Date:   Mon May 25 17:22:24 2020 -0700
> 
> refperf: Provide module parameter to specify number of experiments
> 
> changes this line of code (line 389)
> 
> -   reader_tasks[exp].result_avg = 1000 * process_durations(exp) 
> / ((exp + 1) * loops);
> +   result_avg[exp] = 1000 * process_durations(nreaders) / 
> (nreaders * loops);
> 
> On a 32-bit ARM make allmodconfig with gcc 8.3, this results in:
> 
> ERROR: modpost: "__aeabi_uldivmod" [kernel/rcu/refperf.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:103: __modpost] Error 1
> 
> I admit not understanding why the original line of code worked and the new 
> one doesn't.
> Maybe gcc is smarter/dumber about the ranges of 'exp' and 'nreaders' than we 
> thought?
> 

Paul has already responded: (unfortunately)

"So I am restricting to 64BIT for the time being.  Yeah, I know, lazy of
me.  ;-)"

https://lore.kernel.org/lkml/20200528180855.GP2869@paulmck-ThinkPad-P72/

-- 
~Randy

Re: [PATCH v8 04/10] OPP: Add support for parsing interconnect bandwidth

[Viresh Kumar]

On 12-05-20, 15:53, Georgi Djakov wrote:
>  struct dev_pm_opp *_opp_allocate(struct opp_table *table)
>  {
>   struct dev_pm_opp *opp;
> - int count, supply_size;
> + int supply_count, supply_size, icc_size;
>  
>   /* Allocate space for at least one supply */
> - count = table->regulator_count > 0 ? table->regulator_count : 1;
> - supply_size = sizeof(*opp->supplies) * count;
> + supply_count = table->regulator_count > 0 ? table->regulator_count : 1;
> + supply_size = sizeof(*opp->supplies) * supply_count;
> + icc_size = sizeof(*opp->bandwidth) * table->path_count;
>  
>   /* allocate new OPP node and supplies structures */
> - opp = kzalloc(sizeof(*opp) + supply_size, GFP_KERNEL);
> + opp = kzalloc(sizeof(*opp) + supply_size + icc_size, GFP_KERNEL);
> +
>   if (!opp)
>   return NULL;
>  
>   /* Put the supplies at the end of the OPP structure as an empty array */
>   opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
> + opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + 
> supply_count);
>   INIT_LIST_HEAD(>node);

Added this delta here.

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 7302f2631f8d..dfbd3d10410c 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1330,7 +1330,8 @@ struct dev_pm_opp *_opp_allocate(struct opp_table *table)
 
/* Put the supplies at the end of the OPP structure as an empty array */
opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
-   opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + 
supply_count);
+   if (icc_size)
+   opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + 
supply_count);
INIT_LIST_HEAD(>node);
 
return opp;


-- 
viresh

[tip:sched/urgent] BUILD SUCCESS 18f855e574d9799a0e7489f8ae6fd8447d0dd74a

[kbuild test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git  
sched/urgent
branch HEAD: 18f855e574d9799a0e7489f8ae6fd8447d0dd74a  sched/fair: Don't NUMA 
balance for kthreads

elapsed time: 3598m

configs tested: 115
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
mipsmalta_kvm_guest_defconfig
arm socfpga_defconfig
nds32 allnoconfig
mips  malta_defconfig
arc  alldefconfig
arm orion5x_defconfig
arc nsimosci_hs_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64defconfig
ia64  allnoconfig
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa  defconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a001-20200527
i386 randconfig-a004-20200527
i386 randconfig-a003-20200527
i386 randconfig-a006-20200527
i386 randconfig-a002-20200527
i386 randconfig-a005-20200527
x86_64   randconfig-a013-20200528
x86_64   randconfig-a015-20200528
x86_64   randconfig-a012-20200528
x86_64   randconfig-a016-20200528
x86_64   randconfig-a014-20200528
x86_64   randconfig-a011-20200528
i386 randconfig-a013-20200527
i386 randconfig-a015-20200527
i386 randconfig-a012-20200527
i386 randconfig-a011-20200527
i386 randconfig-a016-20200527
i386 randconfig-a014-20200527
i386 randconfig-a013-20200528
i386 randconfig-a011-20200528
i386 randconfig-a012-20200528
i386 randconfig-a015-20200528
i386 randconfig-a016-20200528
i386 randconfig-a014-20200528
x86_64   randconfig-a006-20200527
x86_64   randconfig-a002-20200527
x86_64   randconfig-a005-20200527
x86_64   randconfig-a003-20200527
x86_64   randconfig-a004-20200527
x86_64   randconfig-a001-20200527
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390  allnoconfig
s390defconfig
s390 allyesconfig
s390 allmodconfig
sparcallyesconfig
sparc   defconfig
sparc64

Re: Some -serious- BPF-related litmus tests

[Andrii Nakryiko]

On Thu, May 28, 2020 at 2:48 PM Joel Fernandes  wrote:
>
> On Mon, May 25, 2020 at 11:38:23AM -0700, Andrii Nakryiko wrote:
> > On Mon, May 25, 2020 at 7:53 AM Boqun Feng  wrote:
> > >
> > > Hi Andrii,
> > >
> > > On Fri, May 22, 2020 at 12:38:21PM -0700, Andrii Nakryiko wrote:
> > > > On 5/22/20 10:43 AM, Paul E. McKenney wrote:
> > > > > On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote:
> > > > > > On Fri, May 22, 2020 at 11:44:07AM +0200, Peter Zijlstra wrote:
> > > > > > > On Thu, May 21, 2020 at 05:38:50PM -0700, Paul E. McKenney wrote:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Just wanted to call your attention to some pretty cool and 
> > > > > > > > pretty serious
> > > > > > > > litmus tests that Andrii did as part of his BPF ring-buffer 
> > > > > > > > work:
> > > > > > > >
> > > > > > > > https://lore.kernel.org/bpf/20200517195727.279322-3-andr...@fb.com/
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > >
> > > > > > > I find:
> > > > > > >
> > > > > > > smp_wmb()
> > > > > > > smp_store_release()
> > > > > > >
> > > > > > > a _very_ weird construct. What is that supposed to even do?
> > > > > >
> > > > > > Indeed, it looks like one or the other of those is redundant 
> > > > > > (depending
> > > > > > on the context).
> > > > >
> > > > > Probably.  Peter instead asked what it was supposed to even do.  ;-)
> > > >
> > > > I agree, I think smp_wmb() is redundant here. Can't remember why I 
> > > > thought
> > > > that it's necessary, this algorithm went through a bunch of iterations,
> > > > starting as completely lockless, also using READ_ONCE/WRITE_ONCE at some
> > > > point, and settling on smp_read_acquire/smp_store_release, eventually. 
> > > > Maybe
> > > > there was some reason, but might be that I was just over-cautious. See 
> > > > reply
> > > > on patch thread as well ([0]).
> > > >
> > > >   [0] 
> > > > https://lore.kernel.org/bpf/caef4bza26abrmtwcod5+tfhnmnu6p5yj8zo+soajcdtp1jv...@mail.gmail.com/
> > > >
> > >
> > > While we are at it, could you explain a bit on why you use
> > > smp_store_release() on consumer_pos? I ask because IIUC, consumer_pos is
> > > only updated at consumer side, and there is no other write at consumer
> > > side that we want to order with the write to consumer_pos. So I fail
> > > to find why smp_store_release() is necessary.
> > >
> > > I did the following modification on litmus tests, and I didn't see
> > > different results (on States) between two versions of litmus tests.
> > >
> >
> > This is needed to ensure that producer can reliably detect whether it
> > needs to trigger poll notification.
>
> Boqun's question is on the consumer side though. Are you saying that on the
> consumer side, the loads prior to the smp_store_release() on the consumer
> side should have been seen by the consumer?  You are already using
> smp_load_acquire() so that should be satisified already because the
> smp_load_acquire() makes sure that the smp_load_acquire()'s happens before
> any future loads and stores.

Consumer is reading two things: producer_pos and each record's length
header, and writes consumer_pos. I re-read this paragraph many times,
but I'm still a bit confused on what exactly you are trying to say.
Can you please specify in each case release()/acquire() of which
variable you are talking about?

>
> > Basically, consumer caught up at
> > about same time as producer commits new record, we need to make sure
> > that:
> >   - either consumer sees updated producer_pos > consumer_pos, and thus
> > knows that there is more data to consumer (but producer might not send
> > notification of new data in this case);
> >   - or producer sees that consumer already caught up (i.e.,
> > consumer_pos == producer_pos before currently committed record), and
> > in such case will definitely send notifications.
>
> Could you set a variable on the producer side to emulate a notification, and
> check that in the conditions at the end?

Setting notification flag is easy, but determining when it has to or
shouldn't happen is the hard part and depends on exact interleaving of
memory operations. I haven't figured out reliable way to express
this... If you have a good idea, please post a snippet of code.

>
> thanks,
>
>  - Joel
>
> >
> > This is critical for correctness of epoll notifications.
> > Unfortunately, litmus tests don't test this notification aspect, as I
> > haven't originally figured out the invariant that can be defined to
> > validate this. I'll give it another thought, though, maybe this time
> > I'll come up with something.
> >
> > > Regards,
> > > Boqun
> > >
> >
> > [...]

Re: [PATCH 0/3] MIPS: Loongson64: Initial LS7A PCH support

[Jiaxun Yang]

于 2020年5月29日 GMT+08:00 下午12:13:36, Huacai Chen  写到:
>Hi, Jiaxun,
>
>On Fri, May 29, 2020 at 11:45 AM Jiaxun Yang  wrote:
>>
>> With this series, LS7A and Loongson-3A4000 is finally supported
>> note that this series should depend on irqchip support[1], which
>> is likely to get merged soon.
>>
>> Thanks.
>>
>> [1]: https://lkml.org/lkml/2020/5/16/72
>>
>> Jiaxun Yang (3):
>>   dt-bindings: mips: Document two Loongson generic boards
>>   MIPS: Loongson64: DeviceTree for LS7A PCH
>>   MIPS: Loongson64:Load LS7A dtbs
>>
>>  .../bindings/mips/loongson/devices.yaml   |   8 +
>>  arch/mips/boot/dts/loongson/Makefile  |   5 +-
>>  .../dts/loongson/loongson3-r4-package.dtsi|  74 +++
>>  .../dts/loongson/loongson3_4core_ls7a.dts |  25 +++
>>  .../boot/dts/loongson/loongson3_r4_ls7a.dts   |  10 +
>>  arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 185 ++
>>  .../asm/mach-loongson64/builtin_dtbs.h|   2 +
>>  arch/mips/loongson64/env.c|  56 +++---
>>  8 files changed, 342 insertions(+), 23 deletions(-)
>>  create mode 100644 arch/mips/boot/dts/loongson/loongson3-r4-package.dtsi
>>  create mode 100644 arch/mips/boot/dts/loongson/loongson3_4core_ls7a.dts
>>  create mode 100644 arch/mips/boot/dts/loongson/loongson3_r4_ls7a.dts
>>  create mode 100644 arch/mips/boot/dts/loongson/ls7a-pch.dtsi
>I think the naming can be like this: Old processor (Loongson 3A R1~R3)
>use loongson64c_ prefix instead of loongson3, new processor (Loongson
>3A R4) use loongson64g_ prefix instead of loongson3_r4, and
>Loongson-2K use loongson64r_ prefix, this makes them consistent with
>their PRID definitions.


DeviceTree bindings have stable ABI. Although they're currently 
only used internally in Kernel. I don't think it's a good idea
to rename existing bindings.

Also, Loongson64C/64G/64R never came to a part of Loongson's
official naming. I doubt if end users will recognize these names.

I'd prefer keep naming as is. It's really not a big deal.

Thanks.


>
>>
>> --
>> 2.27.0.rc0
>>

-- 
Jiaxun Yang

[PATCH v2] usb: host: xhci-mtk: avoid runtime suspend when removing hcd

[Macpaul Lin]

When runtime suspend was enabled, runtime suspend might happened
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.

Signed-off-by: Macpaul Lin 
---
 drivers/usb/host/xhci-mtk.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bfbdb3c..641d24e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct usb_hcd  *shared_hcd = xhci->shared_hcd;
 
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(shared_hcd);
xhci->shared_hcd = NULL;
device_init_wakeup(>dev, false);
@@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
xhci_mtk_sch_exit(mtk);
xhci_mtk_clks_disable(mtk);
xhci_mtk_ldos_disable(mtk);
-   pm_runtime_put_sync(>dev);
-   pm_runtime_disable(>dev);
 
return 0;
 }
-- 
1.7.9.5

Re: [PATCH v4 1/2] clk: hisilicon: Use correct return value about hisi_reset_init()

[Stephen Boyd]

Quoting Tiezhu Yang (2020-05-28 21:02:05)
> On 05/29/2020 11:58 AM, Stephen Boyd wrote:
> > Quoting Tiezhu Yang (2020-05-28 19:03:54)
> >> On 05/29/2020 07:15 AM, Stephen Boyd wrote:
> >>> Quoting Tiezhu Yang (2020-05-27 19:27:42)
>  On 05/28/2020 03:06 AM, Stephen Boyd wrote:
> > Quoting Tiezhu Yang (2020-05-27 07:39:21)
> >> The return value about hisi_reset_init() is not correct, fix it.
> >>
> >> Fixes: e9a2310fb689 ("reset: hisilicon: fix potential NULL pointer 
> >> dereference")
> > hisi_reset_init() returns NULL on error in that commit. This patch
> > doesn't make sense.
>  Hi Stephen,
> 
>  The initial aim of this patch is to use correct return value about
>  hisi_reset_init(), maybe NULL is OK, but the return value in this
>  patch is more accurate.
> >>> The implementation of hisi_reset_init() that I see is this:
> >>>
> >>>
> >>>struct hisi_reset_controller *rstc;
> >>>
> >>>rstc = devm_kmalloc(>dev, sizeof(*rstc), GFP_KERNEL);
> >>>if (!rstc)
> >>>return NULL;
> >>>
> >>>rstc->membase = devm_platform_ioremap_resource(pdev, 0);
> >>>if (IS_ERR(rstc->membase))
> >>>return NULL;
> >>>
> >>>spin_lock_init(>lock);
> >>>rstc->rcdev.owner = THIS_MODULE;
> >>>rstc->rcdev.ops = _reset_ops;
> >>>rstc->rcdev.of_node = pdev->dev.of_node;
> >>>rstc->rcdev.of_reset_n_cells = 2;
> >>>rstc->rcdev.of_xlate = hisi_reset_of_xlate;
> >>>reset_controller_register(>rcdev);
> >>>
> >>>return rstc;
> >>>
> >>> And that returns NULL on an error and a valid pointer on success.
> >>> Changing the code to check the return value of hisi_reset_init() for an
> >>> error pointer is simply wrong without updating hisi_reset_init() to
> >>> return an error pointer on error. Where is the patch that changes
> >>> hisi_reset_init() to return an error pointer?
> >> Hi Stephen,
> >>
> >> Do you mean the following changes?
> > Yes where is this change?
> 
> ERR_PTR(-ENOMEM) and ERR_CAST(rstc->membase)
> 

I think you didn't understand my question. I'm asking where is this
patch applied to the kernel and what commit is it? I don't see it in the
clk tree.

[PATCH] usb: host: xhci-mtk: avoid runtime suspend when removing hcd

[Macpaul Lin]

When runtime suspend was enabled, runtime suspend might happened
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.

Change-Id: I70a5dc8006207caeecbac6955ce8e5345dcc70e6
Signed-off-by: Macpaul Lin 
---
 drivers/usb/host/xhci-mtk.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bfbdb3c..641d24e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct usb_hcd  *shared_hcd = xhci->shared_hcd;
 
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(shared_hcd);
xhci->shared_hcd = NULL;
device_init_wakeup(>dev, false);
@@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
xhci_mtk_sch_exit(mtk);
xhci_mtk_clks_disable(mtk);
xhci_mtk_ldos_disable(mtk);
-   pm_runtime_put_sync(>dev);
-   pm_runtime_disable(>dev);
 
return 0;
 }
-- 
1.7.9.5

Re: [PATCH V2 1/3] clk: vc5: Allow Versaclock driver to support multiple instances

[Stephen Boyd]

Quoting Adam Ford (2020-05-02 05:21:24)
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index fa96659f8023..81255d923f00 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -881,6 +871,8 @@ static int vc5_probe(struct i2c_client *client,
> goto err_clk;
> }
>  
> +   dev_info(>dev, "probed");
> +

Please remove this.

> return 0;
>  
>  err_clk:

Re: [PATCH v2] clk: mediatek: assign the initial value to clk_init_data of mtk_mux

[Stephen Boyd]

Quoting Weiyi Lu (2020-05-26 23:25:49)
> When some new clock supports are introduced, e.g. [1]
> it might lead to an error although it should be NULL because
> clk_init_data is on the stack and it might have random values
> if using without initialization.
> Add the missing initial value to clk_init_data.
> 
> [1] https://android-review.googlesource.com/c/kernel/common/+/1278046
> 
> Fixes: a3ae549917f1 ("clk: mediatek: Add new clkmux register API")
> Cc: 
> Signed-off-by: Weiyi Lu 
> Reviewed-by: Matthias Brugger 
> ---

Applied to clk-next

RE: [PATCH v5 0/6] New RISC-V Local Interrupt Controller Driver

[Anup Patel]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of Palmer Dabbelt
> Sent: 29 May 2020 09:43
> To: a...@brainfault.org
> Cc: Marc Zyngier ; Anup Patel ; Paul
> Walmsley ; a...@eecs.berkeley.edu;
> daniel.lezc...@linaro.org; t...@linutronix.de; ja...@lakedaemon.net; Atish
> Patra ; Alistair Francis ;
> linux-ri...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 0/6] New RISC-V Local Interrupt Controller Driver
> 
> On Thu, 28 May 2020 20:57:26 PDT (-0700), a...@brainfault.org wrote:
> > On Thu, May 28, 2020 at 12:17 AM Palmer Dabbelt 
> wrote:
> >>
> >> On Thu, 21 May 2020 06:32:55 PDT (-0700), Anup Patel wrote:
> >> > This patchset provides a new RISC-V Local Interrupt Controller
> >> > Driver for managing per-CPU local interrupts. The overall approach
> >> > is inspired from the way per-CPU local interrupts are handled by
> >> > Linux ARM64 and ARM GICv3 driver.
> >> >
> >> > Few advantages of this new driver over previous one are:
> >> > 1. All local interrupts are registered as per-CPU interrupts 2. The
> >> > RISC-V timer driver can register timer interrupt handler
> >> >using kernel irq subsystem without relying on arch/riscv to
> >> >explicitly call it's interrupt handler 3. The KVM RISC-V can use
> >> > this driver to implement interrupt
> >> >handler for per-HART guest external interrupt defined by
> >> >the RISC-V H-Extension
> >> > 4. In future, we can develop drivers for devices with per-HART
> >> >interrupts without changing arch code or this driver (example,
> >> >CLINT timer driver for RISC-V M-mode kernel)
> >> >
> >> > With this patchset, output of "cat /proc/interrupts" looks as follows:
> >> >CPU0   CPU1   CPU2   CPU3
> >> >   2:379  0  0  0  SiFive PLIC  10  ttyS0
> >> >   3:591  0  0  0  SiFive PLIC   8  
> >> > virtio0
> >> >   5:   5079  10821   8435  12984  RISC-V INTC   5  
> >> > riscv-timer
> >> > IPI0:  2045   2537891870  Rescheduling interrupts
> >> > IPI1: 9269 91168  Function call 
> >> > interrupts
> >> > IPI2: 0  0  0  0  CPU stop interrupts
> >> >
> >> > The patchset is based up Linux-5.7-rc6 and can be found at
> >> > riscv_intc_v5 branch of: https://github.com/avpatel/linux.git
> >> >
> >> > This series is tested on:
> >> >  1. QEMU RV64 virt machine using Linux RISC-V S-mode  2. QEMU RV32
> >> > virt machine using Linux RISC-V S-mode  3. QEMU RV64 virt machine
> >> > using Linux RISC-V M-mode (i.e. NoMMU)
> >> >
> >> > Changes since v4:
> >> >  - Rebased to Linux-5.7-rc6 and multi-PLIC improvement patches
> >> >  - Added separate patch to force select RISCV_INTC for CONFIG_RISCV
> >> >  - Fixed the driver for Linux RISC-V NoMMU
> >> >
> >> > Changes since v3:
> >> >  - Rebased to Linux-5.6-rc5 and Atish's PLIC patches
> >> >  - Added separate patch to rename and move plic_find_hart_id()
> >> >to arch directory
> >> >  - Use riscv_of_parent_hartid() in riscv_intc_init() instead of
> >> >atomic counter
> >> >
> >> > Changes since v2:
> >> >  - Dropped PATCH2 since it was merged long-time back
> >> >  - Rebased series from Linux-4.19-rc2 to Linux-5.6-rc2
> >> >
> >> > Changes since v1:
> >> >  - Removed changes related to puggable IPI triggering
> >> >  - Separate patch for self-contained IPI handling routine
> >> >  - Removed patch for GENERIC_IRQ kconfig options
> >> >  - Added patch to remove do_IRQ() function
> >> >  - Rebased upon Atish's SMP patches
> >> >
> >> > Anup Patel (6):
> >> >   RISC-V: self-contained IPI handling routine
> >> >   RISC-V: Rename and move plic_find_hart_id() to arch directory
> >> >   irqchip: RISC-V per-HART local interrupt controller driver
> >> >   clocksource/drivers/timer-riscv: Use per-CPU timer interrupt
> >> >   RISC-V: Remove do_IRQ() function
> >> >   RISC-V: Force select RISCV_INTC for CONFIG_RISCV
> >> >
> >> >  arch/riscv/Kconfig |   2 +
> >> >  arch/riscv/include/asm/irq.h   |   5 -
> >> >  arch/riscv/include/asm/processor.h |   1 +
> >> >  arch/riscv/include/asm/smp.h   |   3 +
> >> >  arch/riscv/kernel/cpu.c|  16 +++
> >> >  arch/riscv/kernel/entry.S  |   4 +-
> >> >  arch/riscv/kernel/irq.c|  33 +-
> >> >  arch/riscv/kernel/smp.c|  11 +-
> >> >  arch/riscv/kernel/traps.c  |   2 -
> >> >  drivers/clocksource/timer-riscv.c  |  30 -
> >> >  drivers/irqchip/Kconfig|  13 +++
> >> >  drivers/irqchip/Makefile   |   1 +
> >> >  drivers/irqchip/irq-riscv-intc.c   | 150 +
> >> >  drivers/irqchip/irq-sifive-plic.c  |  52 +
> >> >  include/linux/cpuhotplug.h |   1 +
> >> >  include/linux/irqchip/irq-riscv-intc.h |  20 
> >> >  16 

Re: [PATCH] PCI: ERR: Don't override the status returned by error_detect()

[Kuppuswamy, Sathyanarayanan]

On 5/28/20 9:04 PM, Z.q. Hou wrote:

Hi Kuppuswamy,


-Original Message-
From: Kuppuswamy, Sathyanarayanan

Sent: 2020年5月29日 5:19
To: Z.q. Hou ; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; rus...@russell.cc; sbobr...@linux.ibm.com;
ooh...@gmail.com; bhelg...@google.com
Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
error_detect()

Hi,

On 5/27/20 1:31 AM, Zhiqiang Hou wrote:

From: Hou Zhiqiang 

The commit 6d2c89441571 ("PCI/ERR: Update error status after
reset_link()") overrode the 'status' returned by the error_detect()
call back function, which is depended on by the next step. This
overriding makes the Endpoint driver's required info (kept in the var
status) lost, so it results in the fatal errors' recovery failed and then kernel

panic.
Can you explain why updating status affects the recovery ?


Take the e1000e as an example:
Once a fatal error is reported by e1000e, the e1000e's error_detect() will be
called and it will return PCI_ERS_RESULT_NEED_RESET to request a slot reset,
the return value is stored in the '' of the calling
pci_walk_bus(bus,report_frozen_detected, ).
If you update the 'status' with the reset_link()'s return value
(PCI_ERS_RESULT_RECOVERED if the reset link succeed), then the 'status' has
the value PCI_ERS_RESULT_RECOVERED and e1000e's request
PCI_ERS_RESULT_NEED_RESET lost, then e1000e's callback function .slot_reset()
will be skipped and directly call the .resume().

I believe you are working with non hotplug capable device. If yes, then
this issue will be addressed by the following patch.
https://lkml.org/lkml/2020/5/6/1545


So this is how the update of 'status' break the handshake between RC's AER 
driver
and the Endpoint's protocol driver error_handlers, then result in the recovery 
failure.



In the e1000e case, the error logs:
pcieport 0002:00:00.0: AER: Uncorrected (Fatal) error received:
0002:01:00.0 e1000e 0002:01:00.0: AER: PCIe Bus Error:
severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent
ID) pcieport 0002:00:00.0: AER: Root Port link has been reset

As per above commit log, it looks like link is reset correctly.


Yes, see my comments above.

Thanks,
Zhiqiang


SError Interrupt on CPU0, code 0xbf02 -- SError
CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
5.7.0-rc7-next-20200526 #8 Hardware name: LS1046A RDB Board (DT)
pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--) pc :
__pci_enable_msix_range+0x4c8/0x5b8
lr : __pci_enable_msix_range+0x480/0x5b8
sp : 80001116bb30
x29: 80001116bb30 x28: 0003
x27: 0003 x26: 
x25: 00097243e0a8 x24: 0001
x23: 00097243e2d8 x22: 
x21: 0003 x20: 00095bd46080
x19: 00097243e000 x18: 
x17:  x16: 
x15: b958fa0e9948 x14: 00095bd46303
x13: 00095bd46302 x12: 0038
x11: 0040 x10: b958fa101e68
x9 : b958fa101e60 x8 : 0908
x7 : 0908 x6 : 80001160
x5 : 00095bd46800 x4 : 00096e7f6080
x3 :  x2 : 
x1 :  x0 :  Kernel panic - not
syncing: Asynchronous SError Interrupt
CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
5.7.0-rc7-next-20200526 #8

I think it's the expected result that "if the initial value of error
status is PCI_ERS_RESULT_DISCONNECT or

PCI_ERS_RESULT_NO_AER_DRIVER

then even after successful recovery (using reset_link())
pcie_do_recovery() will report the recovery result as failure" which
is described in commit 6d2c89441571 ("PCI/ERR: Update error status after

reset_link()").


Refer to the Documentation/PCI/pci-error-recovery.rst.
As the error_detect() is mandatory callback if the pci_err_handlers is
implemented, if it return the PCI_ERS_RESULT_DISCONNECT, it means the
driver doesn't want to recover at all; For the case
PCI_ERS_RESULT_NO_AER_DRIVER, if the pci_err_handlers is not
implemented, the failure is more expected.

Fixes: commit 6d2c89441571 ("PCI/ERR: Update error status after
reset_link()")
Signed-off-by: Hou Zhiqiang 
---
   drivers/pci/pcie/err.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index
14bb8f54723e..84f72342259c 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -165,8 +165,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev

*dev,

pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, );
-   status = reset_link(dev);
-   if (status != PCI_ERS_RESULT_RECOVERED) {
+   if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED) {
pci_warn(dev, "link reset failed\n");
goto failed;
}



--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer


--
Sathyanarayanan Kuppuswamy

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

[Michael Ellerman]

On Fri, 2020-04-17 at 17:08:51 UTC, Christophe Leroy wrote:
> unsafe_put_user() is designed to take benefit of 'asm goto'.
> 
> Instead of using the standard __put_user() approach and branch
> based on the returned error, use 'asm goto' and make the
> exception code branch directly to the error label. There is
> no code anymore in the fixup section.
> 
> This change significantly simplifies functions using
> unsafe_put_user()
...
> 
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Segher Boessenkool 

Applied to powerpc topic/uaccess-ppc, thanks.

https://git.kernel.org/powerpc/c/334710b1496af8a0960e70121f850e209c20958f

cheers

Re: [PATCH v2 4/5] powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin

[Michael Ellerman]

On Fri, 2020-04-03 at 07:20:53 UTC, Christophe Leroy wrote:
> Add support for selective read or write user access with
> user_read_access_begin/end and user_write_access_begin/end.
> 
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Kees Cook 

Applied to powerpc topic/uaccess-ppc, thanks.

https://git.kernel.org/powerpc/c/4fe5cda9f89d0aea8e915b7c96ae34bda4e12e51

cheers

Re: [PATCH 3/5] dt-bindings: clock: mediatek: document clk bindings vcodecsys for Mediatek MT6765 SoC

[Stephen Boyd]

Quoting Macpaul Lin (2020-02-21 01:52:20)
> This patch adds the binding documentation for vcodecsys.
> 
> Signed-off-by: Mars Cheng 
> Signed-off-by: Owen Chen 
> Signed-off-by: Macpaul Lin 
> ---

Applied to clk-next

Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling

[Guido Günther]

Hi Rob,
On Thu, May 28, 2020 at 01:59:14PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:12:12PM +0200, Guido Günther wrote:
> > No need to encode the SoC specifics in the bridge driver. For the
> > imx8mq we can use the mux-input-bridge.
> 
> You can't just change bindings like this. You'd still have to support 
> the "old" way. But IMO, this way is the right way.

My understanding is that binding stability only applies to released
kernels and this binding never was in released kernel yet. Does it still
apply in this case?
Cheers,
 -- Guido

> 
> > 
> > Signed-off-by: Guido Günther 
> > ---
> >  .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 --
> >  1 file changed, 6 deletions(-)
> 

Re: [PATCH v4 2/2] powerpc/uaccess: Implement unsafe_copy_to_user() as a simple loop

[Michael Ellerman]

On Fri, 2020-04-17 at 17:08:52 UTC, Christophe Leroy wrote:
> At the time being, unsafe_copy_to_user() is based on
> raw_copy_to_user() which calls __copy_tofrom_user().
> 
> __copy_tofrom_user() is a big optimised function to copy big amount
> of data. It aligns destinations to cache line in order to use
> dcbz instruction.
> 
> Today unsafe_copy_to_user() is called only from filldir().
> It is used to mainly copy small amount of data like filenames,
> so __copy_tofrom_user() is not fit.
> 
> Also, unsafe_copy_to_user() is used within user_access_begin/end
> sections. In those section, it is preferable to not call functions.
> 
> Rewrite unsafe_copy_to_user() as a macro that uses __put_user_goto().
> We first perform a loop of long, then we finish with necessary
> complements.
> 
> unsafe_copy_to_user() might be used in the near future to copy
> fixed-size data, like pt_regs structs during signal processing.
> Having it as a macro allows GCC to optimise it for instead when
> it knows the size in advance, it can unloop loops, drop complements
> when the size is a multiple of longs, etc ...
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc topic/uaccess-ppc, thanks.

https://git.kernel.org/powerpc/c/17bc43367fc2a720400d21c745db641c654c1e6b

cheers

Re: [PATCH 4/5] clk: mediatek: add mt6765 clock IDs

[Stephen Boyd]

Quoting Macpaul Lin (2020-02-21 01:52:21)
> From: Mars Cheng 
> 
> Add MT6765 clock dt-bindings, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
> 
> Signed-off-by: Mars Cheng 
> Signed-off-by: Owen Chen 
> Signed-off-by: Macpaul Lin 
> Reviewed-by: Rob Herring 
> ---

Applied to clk-next

Re: [PATCH 5/5] clk: mediatek: Add MT6765 clock support

[Stephen Boyd]

Quoting Macpaul Lin (2020-02-21 01:52:22)
> From: Owen Chen 
> 
> Add MT6765 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
> 
> Signed-off-by: Owen Chen 
> Signed-off-by: Mars Cheng 
> Signed-off-by: Macpaul Lin 
> ---

Applied to clk-next

Re: [PATCH v2 2/5] uaccess: Selectively open read or write user access

[Michael Ellerman]

On Fri, 2020-04-03 at 07:20:51 UTC, Christophe Leroy wrote:
> When opening user access to only perform reads, only open read access.
> When opening user access to only perform writes, only open write
> access.
> 
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Kees Cook 

Applied to powerpc topic/uaccess, thanks.

https://git.kernel.org/powerpc/c/41cd780524674082b037e7c8461f90c5e42103f0

cheers

Re: [PATCH v2 1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end

[Michael Ellerman]

On Fri, 2020-04-03 at 07:20:50 UTC, Christophe Leroy wrote:
> Some architectures like powerpc64 have the capability to separate
> read access and write access protection.
> For get_user() and copy_from_user(), powerpc64 only open read access.
> For put_user() and copy_to_user(), powerpc64 only open write access.
> But when using unsafe_get_user() or unsafe_put_user(),
> user_access_begin open both read and write.
> 
> Other architectures like powerpc book3s 32 bits only allow write
> access protection. And on this architecture protection is an heavy
> operation as it requires locking/unlocking per segment of 256Mbytes.
> On those architecture it is therefore desirable to do the unlocking
> only for write access. (Note that book3s/32 ranges from very old
> powermac from the 90's with powerpc 601 processor, till modern
> ADSL boxes with PowerQuicc II processors for instance so it
> is still worth considering.)
> 
> In order to avoid any risk based of hacking some variable parameters
> passed to user_access_begin/end that would allow hacking and
> leaving user access open or opening too much, it is preferable to
> use dedicated static functions that can't be overridden.
> 
> Add a user_read_access_begin and user_read_access_end to only open
> read access.
> 
> Add a user_write_access_begin and user_write_access_end to only open
> write access.
> 
> By default, when undefined, those new access helpers default on the
> existing user_access_begin and user_access_end.
> 
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Kees Cook 

Applied to powerpc topic/uaccess, thanks.

https://git.kernel.org/powerpc/c/999a22890cb183b918e4372395d24426a755cef2

cheers

Re: [PATCH v2 3/5] drm/i915/gem: Replace user_access_begin by user_write_access_begin

[Michael Ellerman]

On Fri, 2020-04-03 at 07:20:52 UTC, Christophe Leroy wrote:
> When i915_gem_execbuffer2_ioctl() is using user_access_begin(),
> that's only to perform unsafe_put_user() so use
> user_write_access_begin() in order to only open write access.
> 
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Kees Cook 

Applied to powerpc topic/uaccess, thanks.

https://git.kernel.org/powerpc/c/b44f687386875b714dae2afa768e73401e45c21c

cheers

Re: [PATCH 1/5] dt-bindings: clock: mediatek: document clk bindings for Mediatek MT6765 SoC

[Stephen Boyd]

Quoting Macpaul Lin (2020-02-21 01:52:18)
> This patch adds the binding documentation for apmixedsys, audsys, camsys,
> imgsys, infracfg, mmsys, pericfg, topckgen
> 
> Signed-off-by: Mars Cheng 
> Signed-off-by: Owen Chen 
> Signed-off-by: Macpaul Lin 
> ---

Applied to clk-next

Re: [PATCH 2/5] dt-bindings: clock: mediatek: document clk bindings mipi0a for Mediatek MT6765 SoC

[Stephen Boyd]

Quoting Macpaul Lin (2020-02-21 01:52:19)
> This patch adds the binding documentation for mipi0a.
> 
> Signed-off-by: Mars Cheng 
> Signed-off-by: Owen Chen 
> Signed-off-by: Macpaul Lin 
> ---

Applied to clk-next

Subject: [PATCH] ASoC: soc-pcm: fix BE dai not hw_free and shutdown during mixer update

[zhucancan]

FE state is SND_SOC_DPCM_STATE_PREPARE now, BE1 is
used by FE.

Later when new BE2 is added to FE by mixer update,
it will call dpcm_run_update_startup() to update
BE2's state, but unfortunately BE2 .prepare() meets
error, it will disconnect all non started BE.

This make BE1 dai skip .hw_free() and .shutdown(),
and the BE1 users will never decrease to zero.

Signed-off-by: zhucancan 
---
 sound/soc/soc-pcm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 1f302de44052..df34422bd0dd 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2730,12 +2730,12 @@ static int dpcm_run_update_startup(struct 
snd_soc_pcm_runtime *fe, int stream)
 close:
  dpcm_be_dai_shutdown(fe, stream);
 disconnect:
- /* disconnect any non started BEs */
+ /* disconnect any closed BEs */
  spin_lock_irqsave(>card->dpcm_lock, flags);
  for_each_dpcm_be(fe, stream, dpcm) {
   struct snd_soc_pcm_runtime *be = dpcm->be;
-  if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
-dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
+  if (be->dpcm[stream].state == SND_SOC_DPCM_STATE_CLOSE)
+   dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
  }
  spin_unlock_irqrestore(>card->dpcm_lock, flags);
 
-- 
2.21.0



2020-05-29

zhucancan 

Re: [PATCH V5 0/9] Enable ext4 support for per-file/directory DAX operations

[Theodore Y. Ts'o]

On Thu, May 28, 2020 at 10:54:41PM -0400, Theodore Y. Ts'o wrote:
> 
> Thanks, applied to the ext4-dax branch.
> 

I spoke too soon.  While I tried merging with the ext4.git dev branch,
a merge conflict made me look closer and I realize I needed to make
the following changes (see diff between your patch set and what is
currently in ext4-dax).

Essentially, I needed to rework the branch to take into account commit
e0198aff3ae3 ("ext4: reject mount options not supported when
remounting in handle_mount_opt()").

The problem is that if you allow handle_mount_opt() to apply the
changes to the dax settings, and then later on, ext4_remount() realize
that we're remounting, and we need to reject the change, there's a
race if we restore the mount options to the original configuration.
Specifically, as Syzkaller pointed out, between when we change the dax
settings and then reset them, it's possible for some file to be opened
with "wrong" dax setting, and then when they are reset, *boom*.

The correct way to deal with this is to reject the mount option change
much earlier, in handle_mount_opt(), *before* we mess with the dax
settings.

Please take a look at the ext4-dax for the actual changes which I
made.

Cheers,

- Ted


diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3658e3016999..9a37d70394b2 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1733,7 +1733,7 @@ static int clear_qf_name(struct super_block *sb, int 
qtype)
 #define MOPT_NO_EXT3   0x0200
 #define MOPT_EXT4_ONLY (MOPT_NO_EXT2 | MOPT_NO_EXT3)
 #define MOPT_STRING0x0400
-#define MOPT_SKIP  0x0800
+#define MOPT_NO_REMOUNT0x0800
 
 static const struct mount_opts {
int token;
@@ -1783,18 +1783,15 @@ static const struct mount_opts {
{Opt_min_batch_time, 0, MOPT_GTE0},
{Opt_inode_readahead_blks, 0, MOPT_GTE0},
{Opt_init_itable, 0, MOPT_GTE0},
-   {Opt_dax, EXT4_MOUNT_DAX_ALWAYS, MOPT_SET | MOPT_SKIP},
-   {Opt_dax_always, EXT4_MOUNT_DAX_ALWAYS,
-   MOPT_EXT4_ONLY | MOPT_SET | MOPT_SKIP},
-   {Opt_dax_inode, EXT4_MOUNT2_DAX_INODE,
-   MOPT_EXT4_ONLY | MOPT_SET | MOPT_SKIP},
-   {Opt_dax_never, EXT4_MOUNT2_DAX_NEVER,
-   MOPT_EXT4_ONLY | MOPT_SET | MOPT_SKIP},
+   {Opt_dax, 0, MOPT_NO_REMOUNT},
+   {Opt_dax_always, 0, MOPT_NO_REMOUNT},
+   {Opt_dax_inode, 0, MOPT_NO_REMOUNT},
+   {Opt_dax_never, 0, MOPT_NO_REMOUNT},
{Opt_stripe, 0, MOPT_GTE0},
{Opt_resuid, 0, MOPT_GTE0},
{Opt_resgid, 0, MOPT_GTE0},
-   {Opt_journal_dev, 0, MOPT_NO_EXT2 | MOPT_GTE0},
-   {Opt_journal_path, 0, MOPT_NO_EXT2 | MOPT_STRING},
+   {Opt_journal_dev, 0, MOPT_NO_EXT2 | MOPT_GTE0 | MOPT_NO_REMOUNT},
+   {Opt_journal_path, 0, MOPT_NO_EXT2 | MOPT_STRING | MOPT_NO_REMOUNT},
{Opt_journal_ioprio, 0, MOPT_NO_EXT2 | MOPT_GTE0},
{Opt_data_journal, EXT4_MOUNT_JOURNAL_DATA, MOPT_NO_EXT2 | MOPT_DATAJ},
{Opt_data_ordered, EXT4_MOUNT_ORDERED_DATA, MOPT_NO_EXT2 | MOPT_DATAJ},
@@ -1831,7 +1828,7 @@ static const struct mount_opts {
{Opt_jqfmt_vfsv1, QFMT_VFS_V1, MOPT_QFMT},
{Opt_max_dir_size_kb, 0, MOPT_GTE0},
{Opt_test_dummy_encryption, 0, MOPT_GTE0},
-   {Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET},
+   {Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET | MOPT_NO_REMOUNT},
{Opt_err, 0, 0}
 };
 
@@ -1929,6 +1926,12 @@ static int handle_mount_opt(struct super_block *sb, char 
*opt, int token,
 "Mount option \"%s\" incompatible with ext3", opt);
return -1;
}
+   if ((m->flags & MOPT_NO_REMOUNT) && is_remount) {
+   ext4_msg(sb, KERN_ERR,
+"Mount option \"%s\" not supported when remounting",
+opt);
+   return -1;
+   }
 
if (args->from && !(m->flags & MOPT_STRING) && match_int(args, ))
return -1;
@@ -2008,11 +2011,6 @@ static int handle_mount_opt(struct super_block *sb, char 
*opt, int token,
}
sbi->s_resgid = gid;
} else if (token == Opt_journal_dev) {
-   if (is_remount) {
-   ext4_msg(sb, KERN_ERR,
-"Cannot specify journal on remount");
-   return -1;
-   }
*journal_devnum = arg;
} else if (token == Opt_journal_path) {
char *journal_path;
@@ -2020,11 +2018,6 @@ static int handle_mount_opt(struct super_block *sb, char 
*opt, int token,
struct path path;
int error;
 
-   if (is_remount) {
-   ext4_msg(sb, KERN_ERR,
-"Cannot specify journal on remount");
-   return -1;
-   }
journal_path = match_strdup([0]);
if (!journal_path) {

next-20200528 - build error in kernel/rcu/refperf.c

[Valdis Klētnieks]

commit 9088b449814f788d24f35a5840b6b2c2a23cd32a
Author: Paul E. McKenney 
Date:   Mon May 25 17:22:24 2020 -0700

refperf: Provide module parameter to specify number of experiments

changes this line of code (line 389)

-   reader_tasks[exp].result_avg = 1000 * process_durations(exp) / 
((exp + 1) * loops);
+   result_avg[exp] = 1000 * process_durations(nreaders) / 
(nreaders * loops);

On a 32-bit ARM make allmodconfig with gcc 8.3, this results in:

ERROR: modpost: "__aeabi_uldivmod" [kernel/rcu/refperf.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:103: __modpost] Error 1

I admit not understanding why the original line of code worked and the new one 
doesn't.
Maybe gcc is smarter/dumber about the ranges of 'exp' and 'nreaders' than we 
thought?


pgpnulXfV2CN0.pgp
Description: PGP signature

Re: [PATCH v5 3/6] irqchip: RISC-V per-HART local interrupt controller driver

[Anup Patel]

On Fri, May 29, 2020 at 8:10 AM Palmer Dabbelt  wrote:
>
> On Thu, 21 May 2020 06:32:58 PDT (-0700), Anup Patel wrote:
> > The RISC-V per-HART local interrupt controller manages software
> > interrupts, timer interrupts, external interrupts (which are routed
> > via the platform level interrupt controller) and other per-HART
> > local interrupts.
> >
> > This patch adds a driver for the RISC-V local interrupt controller.
> > It is a major re-write over perviously submitted version.
> > (Refer, https://www.spinics.net/lists/devicetree/msg241230.html)
> >
> > Few advantages of this new driver over previous one are:
> > 1. All local interrupts are registered as per-CPU interrupts
> > 2. The RISC-V timer driver can register timer interrupt handler
> >using kernel irq subsystem without relying on arch/riscv to
> >explicitly call it's interrupt handler
> > 3. The KVM RISC-V can use this driver to implement interrupt
> >handler for per-HART guest external interrupt defined by
> >the RISC-V H-Extension
> > 4. In future, we can develop drivers for devices with per-HART
> >interrupts without changing arch code or this driver (example,
> >CLINT timer driver for RISC-V M-mode kernel)
> >
> > The RISC-V INTC driver is compliant with RISC-V Hart-Level Interrupt
> > Controller DT bindings located at:
> > Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> >
> > Signed-off-by: Palmer Dabbelt 
> > Signed-off-by: Anup Patel 
> > ---
> >  arch/riscv/Kconfig |   1 +
> >  arch/riscv/include/asm/irq.h   |   2 -
> >  arch/riscv/kernel/irq.c|  33 +-
> >  arch/riscv/kernel/traps.c  |   2 -
> >  drivers/irqchip/Kconfig|  13 ++
> >  drivers/irqchip/Makefile   |   1 +
> >  drivers/irqchip/irq-riscv-intc.c   | 158 +
> >  drivers/irqchip/irq-sifive-plic.c  |  38 +-
> >  include/linux/cpuhotplug.h |   1 +
> >  include/linux/irqchip/irq-riscv-intc.h |  20 
> >  10 files changed, 229 insertions(+), 40 deletions(-)
> >  create mode 100644 drivers/irqchip/irq-riscv-intc.c
> >  create mode 100644 include/linux/irqchip/irq-riscv-intc.h
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 90a008e28f7e..822cb0e1a380 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -40,6 +40,7 @@ config RISCV
> >   select HAVE_PERF_REGS
> >   select HAVE_PERF_USER_STACK_DUMP
> >   select HAVE_SYSCALL_TRACEPOINTS
> > + select HANDLE_DOMAIN_IRQ
> >   select IRQ_DOMAIN
> >   select SPARSE_IRQ
> >   select SYSCTL_EXCEPTION_TRACE
> > diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
> > index 0183e15ace66..a9e5f07a7e9c 100644
> > --- a/arch/riscv/include/asm/irq.h
> > +++ b/arch/riscv/include/asm/irq.h
> > @@ -10,8 +10,6 @@
> >  #include 
> >  #include 
> >
> > -#define NR_IRQS 0
> > -
> >  void riscv_timer_interrupt(void);
> >
> >  #include 
> > diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
> > index bb0bfcd537e7..eb8777642ce6 100644
> > --- a/arch/riscv/kernel/irq.c
> > +++ b/arch/riscv/kernel/irq.c
> > @@ -7,7 +7,6 @@
> >
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >
> > @@ -19,39 +18,13 @@ int arch_show_interrupts(struct seq_file *p, int prec)
> >
> >  asmlinkage __visible void __irq_entry do_IRQ(struct pt_regs *regs)
> >  {
> > - struct pt_regs *old_regs;
> > -
> > - switch (regs->cause & ~CAUSE_IRQ_FLAG) {
> > - case RV_IRQ_TIMER:
> > - old_regs = set_irq_regs(regs);
> > - irq_enter();
> > - riscv_timer_interrupt();
> > - irq_exit();
> > - set_irq_regs(old_regs);
> > - break;
> > -#ifdef CONFIG_SMP
> > - case RV_IRQ_SOFT:
> > - /*
> > -  * We only use software interrupts to pass IPIs, so if a 
> > non-SMP
> > -  * system gets one, then we don't know what to do.
> > -  */
> > - handle_IPI(regs);
> > - break;
> > -#endif
> > - case RV_IRQ_EXT:
> > - old_regs = set_irq_regs(regs);
> > - irq_enter();
> > + if (handle_arch_irq)
> >   handle_arch_irq(regs);
> > - irq_exit();
> > - set_irq_regs(old_regs);
> > - break;
> > - default:
> > - pr_alert("unexpected interrupt cause 0x%lx", regs->cause);
> > - BUG();
> > - }
> >  }
> >
> >  void __init init_IRQ(void)
> >  {
> >   irqchip_init();
> > + if (!handle_arch_irq)
> > + panic("No interrupt controller found.");
> >  }
> > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> > index 7f58fa53033f..f48c76aadbf3 100644
> > --- a/arch/riscv/kernel/traps.c
> > +++ b/arch/riscv/kernel/traps.c
> > @@ -178,6 +178,4 @@ void trap_init(void)
> >   csr_write(CSR_SCRATCH, 0);
> >   /* Set 

Re: [PATCH 0/3] MIPS: Loongson64: Initial LS7A PCH support

[Huacai Chen]

Hi, Jiaxun,

On Fri, May 29, 2020 at 11:45 AM Jiaxun Yang  wrote:
>
> With this series, LS7A and Loongson-3A4000 is finally supported
> note that this series should depend on irqchip support[1], which
> is likely to get merged soon.
>
> Thanks.
>
> [1]: https://lkml.org/lkml/2020/5/16/72
>
> Jiaxun Yang (3):
>   dt-bindings: mips: Document two Loongson generic boards
>   MIPS: Loongson64: DeviceTree for LS7A PCH
>   MIPS: Loongson64:Load LS7A dtbs
>
>  .../bindings/mips/loongson/devices.yaml   |   8 +
>  arch/mips/boot/dts/loongson/Makefile  |   5 +-
>  .../dts/loongson/loongson3-r4-package.dtsi|  74 +++
>  .../dts/loongson/loongson3_4core_ls7a.dts |  25 +++
>  .../boot/dts/loongson/loongson3_r4_ls7a.dts   |  10 +
>  arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 185 ++
>  .../asm/mach-loongson64/builtin_dtbs.h|   2 +
>  arch/mips/loongson64/env.c|  56 +++---
>  8 files changed, 342 insertions(+), 23 deletions(-)
>  create mode 100644 arch/mips/boot/dts/loongson/loongson3-r4-package.dtsi
>  create mode 100644 arch/mips/boot/dts/loongson/loongson3_4core_ls7a.dts
>  create mode 100644 arch/mips/boot/dts/loongson/loongson3_r4_ls7a.dts
>  create mode 100644 arch/mips/boot/dts/loongson/ls7a-pch.dtsi
I think the naming can be like this: Old processor (Loongson 3A R1~R3)
use loongson64c_ prefix instead of loongson3, new processor (Loongson
3A R4) use loongson64g_ prefix instead of loongson3_r4, and
Loongson-2K use loongson64r_ prefix, this makes them consistent with
their PRID definitions.

>
> --
> 2.27.0.rc0
>

Re: [PATCH v5 0/6] New RISC-V Local Interrupt Controller Driver

[Palmer Dabbelt]

On Thu, 28 May 2020 20:57:26 PDT (-0700), a...@brainfault.org wrote:

On Thu, May 28, 2020 at 12:17 AM Palmer Dabbelt  wrote:


On Thu, 21 May 2020 06:32:55 PDT (-0700), Anup Patel wrote:
> This patchset provides a new RISC-V Local Interrupt Controller Driver
> for managing per-CPU local interrupts. The overall approach is inspired
> from the way per-CPU local interrupts are handled by Linux ARM64 and
> ARM GICv3 driver.
>
> Few advantages of this new driver over previous one are:
> 1. All local interrupts are registered as per-CPU interrupts
> 2. The RISC-V timer driver can register timer interrupt handler
>using kernel irq subsystem without relying on arch/riscv to
>explicitly call it's interrupt handler
> 3. The KVM RISC-V can use this driver to implement interrupt
>handler for per-HART guest external interrupt defined by
>the RISC-V H-Extension
> 4. In future, we can develop drivers for devices with per-HART
>interrupts without changing arch code or this driver (example,
>CLINT timer driver for RISC-V M-mode kernel)
>
> With this patchset, output of "cat /proc/interrupts" looks as follows:
>CPU0   CPU1   CPU2   CPU3
>   2:379  0  0  0  SiFive PLIC  10  ttyS0
>   3:591  0  0  0  SiFive PLIC   8  virtio0
>   5:   5079  10821   8435  12984  RISC-V INTC   5  riscv-timer
> IPI0:  2045   2537891870  Rescheduling interrupts
> IPI1: 9269 91168  Function call interrupts
> IPI2: 0  0  0  0  CPU stop interrupts
>
> The patchset is based up Linux-5.7-rc6 and can be found at riscv_intc_v5
> branch of: https://github.com/avpatel/linux.git
>
> This series is tested on:
>  1. QEMU RV64 virt machine using Linux RISC-V S-mode
>  2. QEMU RV32 virt machine using Linux RISC-V S-mode
>  3. QEMU RV64 virt machine using Linux RISC-V M-mode (i.e. NoMMU)
>
> Changes since v4:
>  - Rebased to Linux-5.7-rc6 and multi-PLIC improvement patches
>  - Added separate patch to force select RISCV_INTC for CONFIG_RISCV
>  - Fixed the driver for Linux RISC-V NoMMU
>
> Changes since v3:
>  - Rebased to Linux-5.6-rc5 and Atish's PLIC patches
>  - Added separate patch to rename and move plic_find_hart_id()
>to arch directory
>  - Use riscv_of_parent_hartid() in riscv_intc_init() instead of
>atomic counter
>
> Changes since v2:
>  - Dropped PATCH2 since it was merged long-time back
>  - Rebased series from Linux-4.19-rc2 to Linux-5.6-rc2
>
> Changes since v1:
>  - Removed changes related to puggable IPI triggering
>  - Separate patch for self-contained IPI handling routine
>  - Removed patch for GENERIC_IRQ kconfig options
>  - Added patch to remove do_IRQ() function
>  - Rebased upon Atish's SMP patches
>
> Anup Patel (6):
>   RISC-V: self-contained IPI handling routine
>   RISC-V: Rename and move plic_find_hart_id() to arch directory
>   irqchip: RISC-V per-HART local interrupt controller driver
>   clocksource/drivers/timer-riscv: Use per-CPU timer interrupt
>   RISC-V: Remove do_IRQ() function
>   RISC-V: Force select RISCV_INTC for CONFIG_RISCV
>
>  arch/riscv/Kconfig |   2 +
>  arch/riscv/include/asm/irq.h   |   5 -
>  arch/riscv/include/asm/processor.h |   1 +
>  arch/riscv/include/asm/smp.h   |   3 +
>  arch/riscv/kernel/cpu.c|  16 +++
>  arch/riscv/kernel/entry.S  |   4 +-
>  arch/riscv/kernel/irq.c|  33 +-
>  arch/riscv/kernel/smp.c|  11 +-
>  arch/riscv/kernel/traps.c  |   2 -
>  drivers/clocksource/timer-riscv.c  |  30 -
>  drivers/irqchip/Kconfig|  13 +++
>  drivers/irqchip/Makefile   |   1 +
>  drivers/irqchip/irq-riscv-intc.c   | 150 +
>  drivers/irqchip/irq-sifive-plic.c  |  52 +
>  include/linux/cpuhotplug.h |   1 +
>  include/linux/irqchip/irq-riscv-intc.h |  20 
>  16 files changed, 280 insertions(+), 64 deletions(-)
>  create mode 100644 drivers/irqchip/irq-riscv-intc.c
>  create mode 100644 include/linux/irqchip/irq-riscv-intc.h

So I read through this a bit, and while I haven't gone through every line of
code I'm somewhat inclined toward taking it.

During the original RISC-V port submission we went back and forth between
having this first-level interrupt controller in arch/riscv/ vs
drivers/irqchip/.  The original deciding factor was that the ISA mandated the
interrupt controller, but as that's proving to be less and less the case every
day (with the CLIC and M-mode Linux) it certainly seem sane to move all our
interrupt controller drivers out of arch/riscv/.

This is certainly a step in the right direction, and it handles some of the
more glaring issues (iscv_timer_interrupt and lacking IRQs for the CLINT).  I
think we should just go ahead and merge it, even though there might be some
more 

Re: inux-next: build failure after merge of the drm-msm tree

[Stephen Rothwell]

Hi all,

On Tue, 26 May 2020 14:08:41 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> On Tue, 19 May 2020 15:09:55 +1000 Stephen Rothwell  
> wrote:
> >
> > Hi all,
> > 
> > After merging the drm-msm tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> > 
> > Caused by commit
> > 
> >   04d9044f6c57 ("drm/msm/dpu: add support for clk and bw scaling for 
> > display")
> > 
> > I applied the following patch for today (this is mechanical, there may
> > be a better way):
> > 
> > From: Stephen Rothwell 
> > Date: Tue, 19 May 2020 14:12:39 +1000
> > Subject: [PATCH] drm/msm/dpu: fix up u64/u32 division for 32 bit 
> > architectures
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 23 ++-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15 
> >  2 files changed, 28 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > index 9697abcbec3f..85c2a4190840 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "dpu_kms.h"
> >  #include "dpu_trace.h"
> > @@ -53,8 +54,11 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
> > }
> >  
> > bw_factor = kms->catalog->perf.bw_inefficiency_factor;
> > -   if (bw_factor)
> > -   crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
> > +   if (bw_factor) {
> > +   u64 quot = crtc_plane_bw;
> > +   u32 rem = do_div(quot, 100);
> > +   crtc_plane_bw = (quot * bw_factor) + ((rem * bw_factor) / 100);
> > +   }
> >  
> > return crtc_plane_bw;
> >  }
> > @@ -89,8 +93,11 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
> > }
> >  
> > clk_factor = kms->catalog->perf.clk_inefficiency_factor;
> > -   if (clk_factor)
> > -   crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
> > +   if (clk_factor) {
> > +   u64 quot = crtc_clk;
> > +   u32 rem = do_div(quot, 100);
> > +   crtc_clk = (quot * clk_factor) + ((rem * clk_factor) / 100);
> > +   }
> >  
> > return crtc_clk;
> >  }
> > @@ -234,8 +241,12 @@ static int _dpu_core_perf_crtc_update_bus(struct 
> > dpu_kms *kms,
> > }
> > }
> >  
> > -   avg_bw = kms->num_paths ?
> > -   perf.bw_ctl / kms->num_paths : 0;
> > +   if (kms->num_paths) {
> > +   avg_bw = perf.bw_ctl;
> > +   do_div(avg_bw, kms->num_paths);
> > +   } else {
> > +   avg_bw = 0;
> > +   }
> >  
> > for (i = 0; i < kms->num_paths; i++)
> > icc_set_bw(kms->path[i],
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index c2a6e3dacd68..ad95f32eac13 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -9,6 +9,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -174,7 +175,11 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
> > plane_prefill_bw =
> > src_width * hw_latency_lines * fps * fmt->bpp * scale_factor;
> >  
> > -   plane_prefill_bw = mult_frac(plane_prefill_bw, mode->vtotal, (vbp+vpw));
> > +   {
> > +   u64 quot = plane_prefill_bw;
> > +   u32 rem = do_div(plane_prefill_bw, vbp + vpw);
> > +   plane_prefill_bw = quot * mode->vtotal + rem * mode->vtotal / 
> > (vbp + vpw);
> > +   }
> >  
> > pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
> >  }
> > @@ -204,9 +209,11 @@ static void _dpu_plane_calc_clk(struct drm_plane 
> > *plane)
> > pstate->plane_clk =
> > dst_width * mode->vtotal * fps;
> >  
> > -   if (src_height > dst_height)
> > -   pstate->plane_clk = mult_frac(pstate->plane_clk,
> > -   src_height, dst_height);
> > +   if (src_height > dst_height) {
> > +   u64 quot = pstate->plane_clk;
> > +   u32 rem = do_div(quot, dst_height);
> > +   pstate->plane_clk = quot * src_height + rem * src_height / 
> > dst_height;
> > +   }
> >  }
> >  
> >  /**
> > -- 
> > 2.26.2  
> 
> I am still applying the above ...

Still applying.

Any comment even?
-- 
Cheers,
Stephen Rothwell


pgp5foQ1Wug5e.pgp
Description: OpenPGP digital signature

Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU

[Viresh Kumar]

On 28-05-20, 13:20, Rob Herring wrote:
> Whether Linux 
> requires serializing mailbox accesses is a separate issue. On that side, 
> it seems silly to not allow driving the h/w in the most efficient way 
> possible.

That's exactly what we are trying to say. The hardware allows us to
write all 32 bits in parallel, without any hardware issues, why
shouldn't we do that ? The delay (which Sudeep will find out, he is
facing issues with hardware access because of lockdown right now)
which may be small in transmitting across a mailbox becomes
significant because of the fact that it happens synchronously and the
receiver will send some sort of acknowledgement (and that depends on
the firmware there) and the kernel needs to wait for it, while the
kernel doesn't really need to. There is no reason IMHO for being
inefficient here while we can do better.

-- 
viresh

Re: [PATCH 1/3] CLK: HSDK: CGU: check if PLL is bypassed first

[Stephen Boyd]

Quoting Eugeniy Paltsev (2020-03-11 06:41:13)
> If PLL is bypassed the EN (enable) bit has no effect on
> output clock.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---

Applied to clk-next

Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq

[Zenghui Yu]

Hi,

On 2020/5/29 9:55, Ali Saidi wrote:

If an interrupt is disabled the ITS driver has sent a discard removing
the DeviceID and EventID from the ITT. After this occurs it can't be
moved to another collection with a MOVI and a command error occurs if
attempted. Before issuing the MOVI command make sure that the IRQ isn't
disabled and change the activate code to try and use the previous
affinity.

Signed-off-by: Ali Saidi 
---
  drivers/irqchip/irq-gic-v3-its.c | 18 +++---
  1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 124251b0ccba..1235dd9a2fb2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1540,7 +1540,11 @@ static int its_set_affinity(struct irq_data *d, const 
struct cpumask *mask_val,
/* don't set the affinity when the target cpu is same as current one */
if (cpu != its_dev->event_map.col_map[id]) {
target_col = _dev->its->collections[cpu];
-   its_send_movi(its_dev, target_col, id);
+
+   /* If the IRQ is disabled a discard was sent so don't move */
+   if (!irqd_irq_disabled(d))
+   its_send_movi(its_dev, target_col, id);


It looks to me that if the IRQ is disabled, we mask the enable bit in
the corresponding LPI configuration table entry, but not sending DISCARD
to remove the DevID/EventID mapping. And moving a disabled LPI is
actually allowed by the GIC architecture, right?


+
its_dev->event_map.col_map[id] = cpu;
irq_data_update_effective_affinity(d, cpumask_of(cpu));
}
@@ -3439,8 +3443,16 @@ static int its_irq_domain_activate(struct irq_domain 
*domain,
if (its_dev->its->numa_node >= 0)
cpu_mask = cpumask_of_node(its_dev->its->numa_node);
  
-	/* Bind the LPI to the first possible CPU */

-   cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
+   /* If the cpu set to a different CPU that is still online use it */
+   cpu = its_dev->event_map.col_map[event];
+
+   cpumask_and(cpu_mask, cpu_mask, cpu_online_mask);
+
+   if (!cpumask_test_cpu(cpu, cpu_mask)) {
+   /* Bind the LPI to the first possible CPU */
+   cpu = cpumask_first(cpu_mask);
+   }


I'd like to know what actual problem you had seen and the way to
reproduce it :-)


Thanks,
Zenghui

Re: [PATCH 3/3] CLK: HSDK: CGU: add support for 148.5MHz clock

[Stephen Boyd]

Quoting Eugeniy Paltsev (2020-03-11 06:41:15)
> Add support for 148.5MHz clock for HDMI PLL
> 
> Signed-off-by: Eugeniy Paltsev 
> ---

Applied to clk-next

Re: [PATCH 2/3] CLK: HSDK: CGU: support PLL bypassing

[Stephen Boyd]

Quoting Eugeniy Paltsev (2020-03-11 06:41:14)
> Support setting PLL to bypass mode to support output frequency
> equal to input one.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---

Applied to clk-next

Re: [PATCH 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Stephen Boyd]

Quoting Adam Ford (2020-04-04 09:15:36)
> IDT VersaClock 5 5P49V6965 has 5 clock outputs, 4 fractional dividers.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt 
> b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> index 05a245c9df08..bcff681a4bd0 100644
> --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt

Applied to clk-next

BTW, the patch format threw my scripts off because there isn't a triple
dash after the SoB line.

Re: [PATCH 1/2] clk: vc5: Add support for IDT VersaClock 5P49V6965

[Stephen Boyd]

Quoting Adam Ford (2020-04-04 09:15:35)
> Update IDT VersaClock 5 driver to support 5P49V6965.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> 
> index 24fef51fbcb5..fa96659f8023
> --- a/drivers/clk/clk-versaclock5.c

Applied to clk-next

RE: [PATCH] PCI: ERR: Don't override the status returned by error_detect()

[Z.q. Hou]

Hi Kuppuswamy,

> -Original Message-
> From: Kuppuswamy, Sathyanarayanan
> 
> Sent: 2020年5月29日 5:19
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; rus...@russell.cc; sbobr...@linux.ibm.com;
> ooh...@gmail.com; bhelg...@google.com
> Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
> error_detect()
> 
> Hi,
> 
> On 5/27/20 1:31 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The commit 6d2c89441571 ("PCI/ERR: Update error status after
> > reset_link()") overrode the 'status' returned by the error_detect()
> > call back function, which is depended on by the next step. This
> > overriding makes the Endpoint driver's required info (kept in the var
> > status) lost, so it results in the fatal errors' recovery failed and then 
> > kernel
> panic.
> Can you explain why updating status affects the recovery ?

Take the e1000e as an example:
Once a fatal error is reported by e1000e, the e1000e's error_detect() will be
called and it will return PCI_ERS_RESULT_NEED_RESET to request a slot reset,
the return value is stored in the '' of the calling 
pci_walk_bus(bus,report_frozen_detected, ). 
If you update the 'status' with the reset_link()'s return value
(PCI_ERS_RESULT_RECOVERED if the reset link succeed), then the 'status' has
the value PCI_ERS_RESULT_RECOVERED and e1000e's request
PCI_ERS_RESULT_NEED_RESET lost, then e1000e's callback function .slot_reset()
will be skipped and directly call the .resume().

So this is how the update of 'status' break the handshake between RC's AER 
driver
and the Endpoint's protocol driver error_handlers, then result in the recovery 
failure.

> >
> > In the e1000e case, the error logs:
> > pcieport 0002:00:00.0: AER: Uncorrected (Fatal) error received:
> > 0002:01:00.0 e1000e 0002:01:00.0: AER: PCIe Bus Error:
> > severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent
> > ID) pcieport 0002:00:00.0: AER: Root Port link has been reset
> As per above commit log, it looks like link is reset correctly.

Yes, see my comments above.

Thanks,
Zhiqiang

> > SError Interrupt on CPU0, code 0xbf02 -- SError
> > CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> > 5.7.0-rc7-next-20200526 #8 Hardware name: LS1046A RDB Board (DT)
> > pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--) pc :
> > __pci_enable_msix_range+0x4c8/0x5b8
> > lr : __pci_enable_msix_range+0x480/0x5b8
> > sp : 80001116bb30
> > x29: 80001116bb30 x28: 0003
> > x27: 0003 x26: 
> > x25: 00097243e0a8 x24: 0001
> > x23: 00097243e2d8 x22: 
> > x21: 0003 x20: 00095bd46080
> > x19: 00097243e000 x18: 
> > x17:  x16: 
> > x15: b958fa0e9948 x14: 00095bd46303
> > x13: 00095bd46302 x12: 0038
> > x11: 0040 x10: b958fa101e68
> > x9 : b958fa101e60 x8 : 0908
> > x7 : 0908 x6 : 80001160
> > x5 : 00095bd46800 x4 : 00096e7f6080
> > x3 :  x2 : 
> > x1 :  x0 :  Kernel panic - not
> > syncing: Asynchronous SError Interrupt
> > CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> > 5.7.0-rc7-next-20200526 #8
> >
> > I think it's the expected result that "if the initial value of error
> > status is PCI_ERS_RESULT_DISCONNECT or
> PCI_ERS_RESULT_NO_AER_DRIVER
> > then even after successful recovery (using reset_link())
> > pcie_do_recovery() will report the recovery result as failure" which
> > is described in commit 6d2c89441571 ("PCI/ERR: Update error status after
> reset_link()").
> >
> > Refer to the Documentation/PCI/pci-error-recovery.rst.
> > As the error_detect() is mandatory callback if the pci_err_handlers is
> > implemented, if it return the PCI_ERS_RESULT_DISCONNECT, it means the
> > driver doesn't want to recover at all; For the case
> > PCI_ERS_RESULT_NO_AER_DRIVER, if the pci_err_handlers is not
> > implemented, the failure is more expected.
> >
> > Fixes: commit 6d2c89441571 ("PCI/ERR: Update error status after
> > reset_link()")
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >   drivers/pci/pcie/err.c | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index
> > 14bb8f54723e..84f72342259c 100644
> > --- a/drivers/pci/pcie/err.c
> > +++ b/drivers/pci/pcie/err.c
> > @@ -165,8 +165,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev
> *dev,
> > pci_dbg(dev, "broadcast error_detected message\n");
> > if (state == pci_channel_io_frozen) {
> > pci_walk_bus(bus, report_frozen_detected, );
> > -   status = reset_link(dev);
> > -   if (status != PCI_ERS_RESULT_RECOVERED) {
> > +   if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED) {
> > pci_warn(dev, "link reset failed\n");
> > goto failed;
> > }
> >
> 
> --
> 

Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message

[Michael Ellerman]

Yi Wang  writes:
> From: Liao Pingfang 
>
> Use kzalloc instead of kmalloc in the error message according to
> the previous kzalloc() call.

Please just remove the message instead, it's a tiny allocation that's
unlikely to ever fail, and the caller will print an error anyway.

cheers

> diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
> index fb4f610..c3a0c8d 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -892,7 +892,7 @@ loff_t __init nvram_create_partition(const char *name, 
> int sig,
>   /* Create our OS partition */
>   new_part = kzalloc(sizeof(*new_part), GFP_KERNEL);
>   if (!new_part) {
> - pr_err("%s: kmalloc failed\n", __func__);
> + pr_err("%s: kzalloc failed\n", __func__);
>   return -ENOMEM;
>   }
>  
> -- 
> 2.9.5

Re: [PATCH V2 2/3] clk: vc5: Enable addition output configurations of the Versaclock

[Stephen Boyd]

Quoting Adam Ford (2020-05-12 15:21:49)
> On Tue, May 12, 2020 at 5:05 PM Rob Herring  wrote:
> >
> > On Sat, May 02, 2020 at 07:21:25AM -0500, Adam Ford wrote:
> > > The existing driver is expecting the Versaclock to be pre-programmed,
> > > and only sets the output frequency.  Unfortunately, not all devices
> > > are pre-programmed, and the Versaclock chip has more options beyond
> > > just the frequency.
> > >
> > > This patch enables the following additional features:
> > >
> > >- Programmable voltage: 1.8V, 2.5V, or 3.3V
> > >- Slew Percentage of normal: 85%, 90%, or 100%
> > >- Output Type: LVPECL, CMOS, HCSL, or LVDS
> > >
> > > Signed-off-by: Adam Ford 
> >
> >
> > > diff --git a/include/dt-bindings/clk/versaclock.h 
> > > b/include/dt-bindings/clk/versaclock.h
> > > new file mode 100644
> > > index ..c6a6a0946564
> > > --- /dev/null
> > > +++ b/include/dt-bindings/clk/versaclock.h
> >
> > Belongs in binding patch.
> 
> I can do that, but the binding patch will have to be applied before
> the rest of the series, or the source won't build because it's
> referencing the bindings.  Is that OK?

Yes that's usually how it works.

Re: [PATCH v4 1/2] clk: hisilicon: Use correct return value about hisi_reset_init()

[Tiezhu Yang]

On 05/29/2020 11:58 AM, Stephen Boyd wrote:

Quoting Tiezhu Yang (2020-05-28 19:03:54)

On 05/29/2020 07:15 AM, Stephen Boyd wrote:

Quoting Tiezhu Yang (2020-05-27 19:27:42)

On 05/28/2020 03:06 AM, Stephen Boyd wrote:

Quoting Tiezhu Yang (2020-05-27 07:39:21)

The return value about hisi_reset_init() is not correct, fix it.

Fixes: e9a2310fb689 ("reset: hisilicon: fix potential NULL pointer dereference")

hisi_reset_init() returns NULL on error in that commit. This patch
doesn't make sense.

Hi Stephen,

The initial aim of this patch is to use correct return value about
hisi_reset_init(), maybe NULL is OK, but the return value in this
patch is more accurate.

The implementation of hisi_reset_init() that I see is this:


   struct hisi_reset_controller *rstc;

   rstc = devm_kmalloc(>dev, sizeof(*rstc), GFP_KERNEL);
   if (!rstc)
   return NULL;

   rstc->membase = devm_platform_ioremap_resource(pdev, 0);
   if (IS_ERR(rstc->membase))
   return NULL;

   spin_lock_init(>lock);
   rstc->rcdev.owner = THIS_MODULE;
   rstc->rcdev.ops = _reset_ops;
   rstc->rcdev.of_node = pdev->dev.of_node;
   rstc->rcdev.of_reset_n_cells = 2;
   rstc->rcdev.of_xlate = hisi_reset_of_xlate;
   reset_controller_register(>rcdev);

   return rstc;

And that returns NULL on an error and a valid pointer on success.
Changing the code to check the return value of hisi_reset_init() for an
error pointer is simply wrong without updating hisi_reset_init() to
return an error pointer on error. Where is the patch that changes
hisi_reset_init() to return an error pointer?

Hi Stephen,

Do you mean the following changes?

Yes where is this change?


ERR_PTR(-ENOMEM) and ERR_CAST(rstc->membase)


rstc = devm_kmalloc(>dev, sizeof(*rstc), GFP_KERNEL);
if (!rstc)
- return NULL;
+ return ERR_PTR(-ENOMEM);
 
 	rstc->membase = devm_platform_ioremap_resource(pdev, 0);

if (IS_ERR(rstc->membase))
- return NULL;
+ return ERR_CAST(rstc->membase);

[PATCH v5 05/16] spi: dw: Add SPI Rx-done wait method to DMA-based transfer

[Serge Semin]

Having any data left in the Rx FIFO after the DMA engine claimed it has
finished all DMA transactions is an abnormal situation, since the DW SPI
controller driver expects to have all the data being fetched and placed
into the SPI Rx buffer at that moment. In case if this has happened we
assume that DMA engine still may be doing the data fetching, thus we give
it sometime to finish. If after a short period of time the data is still
left in the Rx FIFO, the driver will give up waiting and return an error
indicating that the SPI controller/DMA engine must have hung up or failed
at some point of doing their duties.

Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support")
Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Signed-off-by: Serge Semin 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Andy Shevchenko 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v5:
- Create a dedicated patch which adds the Rx-done wait method.
- Add more detailed description of the problem the patch fixes.
- Wait for the SPI Rx transfer finish in the mid_spi_dma_transfer() method
  executed in the task context.
- Use spi_delay_exec() to wait for the SPI Rx completion, since now the
  driver does in the kernel thread context.
- Wait for a delay correlated with the APB/SSI synchronous clock rate
  instead of using the SPI bus clock rate.
---
 drivers/spi/spi-dw-mid.c | 48 +++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 846e3db91329..4345881ebf66 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -248,6 +248,49 @@ static struct dma_async_tx_descriptor 
*dw_spi_dma_prepare_tx(struct dw_spi *dws,
return txdesc;
 }
 
+static inline bool dw_spi_dma_rx_busy(struct dw_spi *dws)
+{
+   return !!(dw_readl(dws, DW_SPI_SR) & SR_RF_NOT_EMPT);
+}
+
+static int dw_spi_dma_wait_rx_done(struct dw_spi *dws)
+{
+   int retry = WAIT_RETRIES;
+   struct spi_delay delay;
+   unsigned long ns, us;
+   u32 nents;
+
+   /*
+* It's unlikely that DMA engine is still doing the data fetching, but
+* if it's let's give it some reasonable time. The timeout calculation
+* is based on the synchronous APB/SSI reference clock rate, on a
+* number of data entries left in the Rx FIFO, times a number of clock
+* periods normally needed for a single APB read/write transaction
+* without PREADY signal utilized (which is true for the DW APB SSI
+* controller).
+*/
+   nents = dw_readl(dws, DW_SPI_RXFLR);
+   ns = NSEC_PER_SEC / dws->max_freq * 4 * nents;
+   if (ns <= NSEC_PER_USEC) {
+   delay.unit = SPI_DELAY_UNIT_NSECS;
+   delay.value = ns;
+   } else {
+   us = DIV_ROUND_UP(ns, NSEC_PER_USEC);
+   delay.unit = SPI_DELAY_UNIT_USECS;
+   delay.value = clamp_val(us, 0, USHRT_MAX);
+   }
+
+   while (dw_spi_dma_rx_busy(dws) && retry--)
+   spi_delay_exec(, NULL);
+
+   if (retry < 0) {
+   dev_err(>master->dev, "Rx hanged up\n");
+   return -EIO;
+   }
+
+   return 0;
+}
+
 /*
  * dws->dma_chan_busy is set before the dma transfer starts, callback for rx
  * channel will clear a corresponding bit.
@@ -358,7 +401,10 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, struct 
spi_transfer *xfer)
return ret;
}
 
-   return 0;
+   if (rxdesc && dws->master->cur_msg->status == -EINPROGRESS)
+   ret = dw_spi_dma_wait_rx_done(dws);
+
+   return ret;
 }
 
 static void mid_spi_dma_stop(struct dw_spi *dws)
-- 
2.26.2

Re: [PATCH] clk: clk-si5341: Add support for the Si5345 series

[Stephen Boyd]

Quoting Mike Looijmans (2020-05-06 23:15:44)
> Add support for the Si5342, Si5344 and Si5345 chips. These are equivalent
> to the Si5341 family, but with more clock input options (which are not
> supported yet by this driver).
> 
> Signed-off-by: Mike Looijmans 
> ---

Applied to clk-next

[PATCH v5 07/16] spi: dw: Use DMA max burst to set the request thresholds

[Serge Semin]

Each channel of DMA controller may have a limited length of burst
transaction (number of IO operations performed at ones in a single
DMA client request). This parameter can be used to setup the most
optimal DMA Tx/Rx data level values. In order to avoid the Tx buffer
overrun we can set the DMA Tx level to be of FIFO depth minus the
maximum burst transactions length. To prevent the Rx buffer underflow
the DMA Rx level should be set to the maximum burst transactions length.
This commit setups the DMA channels and the DW SPI DMA Tx/Rx levels
in accordance with these rules.

Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v3:
- Use min() method to calculate the optimal burst values.
---
 drivers/spi/spi-dw-mid.c | 37 +
 drivers/spi/spi-dw.h |  2 ++
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 93463bdba0f8..ff79b4239d68 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -36,6 +36,31 @@ static bool mid_spi_dma_chan_filter(struct dma_chan *chan, 
void *param)
return true;
 }
 
+static void mid_spi_maxburst_init(struct dw_spi *dws)
+{
+   struct dma_slave_caps caps;
+   u32 max_burst, def_burst;
+   int ret;
+
+   def_burst = dws->fifo_len / 2;
+
+   ret = dma_get_slave_caps(dws->rxchan, );
+   if (!ret && caps.max_burst)
+   max_burst = caps.max_burst;
+   else
+   max_burst = RX_BURST_LEVEL;
+
+   dws->rxburst = min(max_burst, def_burst);
+
+   ret = dma_get_slave_caps(dws->txchan, );
+   if (!ret && caps.max_burst)
+   max_burst = caps.max_burst;
+   else
+   max_burst = TX_BURST_LEVEL;
+
+   dws->txburst = min(max_burst, def_burst);
+}
+
 static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
 {
struct dw_dma_slave slave = {
@@ -73,6 +98,8 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct 
dw_spi *dws)
 
init_completion(>dma_completion);
 
+   mid_spi_maxburst_init(dws);
+
return 0;
 
 free_rxchan:
@@ -100,6 +127,8 @@ static int mid_spi_dma_init_generic(struct device *dev, 
struct dw_spi *dws)
 
init_completion(>dma_completion);
 
+   mid_spi_maxburst_init(dws);
+
return 0;
 }
 
@@ -229,7 +258,7 @@ static struct dma_async_tx_descriptor 
*dw_spi_dma_prepare_tx(struct dw_spi *dws,
memset(, 0, sizeof(txconf));
txconf.direction = DMA_MEM_TO_DEV;
txconf.dst_addr = dws->dma_addr;
-   txconf.dst_maxburst = TX_BURST_LEVEL;
+   txconf.dst_maxburst = dws->txburst;
txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
txconf.dst_addr_width = convert_dma_width(dws->n_bytes);
txconf.device_fc = false;
@@ -321,7 +350,7 @@ static struct dma_async_tx_descriptor 
*dw_spi_dma_prepare_rx(struct dw_spi *dws,
memset(, 0, sizeof(rxconf));
rxconf.direction = DMA_DEV_TO_MEM;
rxconf.src_addr = dws->dma_addr;
-   rxconf.src_maxburst = RX_BURST_LEVEL;
+   rxconf.src_maxburst = dws->rxburst;
rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
rxconf.src_addr_width = convert_dma_width(dws->n_bytes);
rxconf.device_fc = false;
@@ -346,8 +375,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct 
spi_transfer *xfer)
 {
u16 imr = 0, dma_ctrl = 0;
 
-   dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
-   dw_writel(dws, DW_SPI_DMATDLR, TX_BURST_LEVEL);
+   dw_writel(dws, DW_SPI_DMARDLR, dws->rxburst - 1);
+   dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - dws->txburst);
 
if (xfer->tx_buf) {
dma_ctrl |= SPI_DMA_TDMAE;
diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
index 9585d0c83a6d..9247670fcdfb 100644
--- a/drivers/spi/spi-dw.h
+++ b/drivers/spi/spi-dw.h
@@ -142,7 +142,9 @@ struct dw_spi {
 
/* DMA info */
struct dma_chan *txchan;
+   u32 txburst;
struct dma_chan *rxchan;
+   u32 rxburst;
unsigned long   dma_chan_busy;
dma_addr_t  dma_addr; /* phy address of the Data register */
const struct dw_spi_dma_ops *dma_ops;
-- 
2.26.2

[PATCH v5 15/16] spi: dw: Use regset32 DebugFS method to create regdump file

[Serge Semin]

DebugFS kernel interface provides a dedicated method to create the
registers dump file. Use it instead of creating a generic DebugFS
file with manually written read callback function.

Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v3:
- Add commas in the debugfs_reg32 structure initializer and after the last
  item of the array dw_spi_dbgfs_regs.
---
 drivers/spi/spi-dw-core.c | 86 ---
 drivers/spi/spi-dw.h  |  2 +
 2 files changed, 28 insertions(+), 60 deletions(-)

diff --git a/drivers/spi/spi-dw-core.c b/drivers/spi/spi-dw-core.c
index 4d1849699a12..323c66c5db50 100644
--- a/drivers/spi/spi-dw-core.c
+++ b/drivers/spi/spi-dw-core.c
@@ -29,66 +29,29 @@ struct chip_data {
 };
 
 #ifdef CONFIG_DEBUG_FS
-#define SPI_REGS_BUFSIZE   1024
-static ssize_t dw_spi_show_regs(struct file *file, char __user *user_buf,
-   size_t count, loff_t *ppos)
-{
-   struct dw_spi *dws = file->private_data;
-   char *buf;
-   u32 len = 0;
-   ssize_t ret;
-
-   buf = kzalloc(SPI_REGS_BUFSIZE, GFP_KERNEL);
-   if (!buf)
-   return 0;
-
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "%s registers:\n", dev_name(>master->dev));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "=\n");
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "CTRLR0: \t0x%08x\n", dw_readl(dws, DW_SPI_CTRLR0));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "CTRLR1: \t0x%08x\n", dw_readl(dws, DW_SPI_CTRLR1));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "SSIENR: \t0x%08x\n", dw_readl(dws, DW_SPI_SSIENR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "SER: \t\t0x%08x\n", dw_readl(dws, DW_SPI_SER));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "BAUDR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_BAUDR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "TXFTLR: \t0x%08x\n", dw_readl(dws, DW_SPI_TXFTLR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "RXFTLR: \t0x%08x\n", dw_readl(dws, DW_SPI_RXFTLR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "TXFLR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_TXFLR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "RXFLR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_RXFLR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "SR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_SR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "IMR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_IMR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "ISR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_ISR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "DMACR: \t\t0x%08x\n", dw_readl(dws, DW_SPI_DMACR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "DMATDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMATDLR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "DMARDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMARDLR));
-   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
-   "=\n");
-
-   ret = simple_read_from_buffer(user_buf, count, ppos, buf, len);
-   kfree(buf);
-   return ret;
+
+#define DW_SPI_DBGFS_REG(_name, _off)  \
+{  \
+   .name = _name,  \
+   .offset = _off, \
 }
 
-static const struct file_operations dw_spi_regs_ops = {
-   .owner  = THIS_MODULE,
-   .open   = simple_open,
-   .read   = dw_spi_show_regs,
-   .llseek = default_llseek,
+static const struct debugfs_reg32 dw_spi_dbgfs_regs[] = {
+   DW_SPI_DBGFS_REG("CTRLR0", DW_SPI_CTRLR0),
+   DW_SPI_DBGFS_REG("CTRLR1", DW_SPI_CTRLR1),
+   DW_SPI_DBGFS_REG("SSIENR", DW_SPI_SSIENR),
+   DW_SPI_DBGFS_REG("SER", DW_SPI_SER),
+   DW_SPI_DBGFS_REG("BAUDR", DW_SPI_BAUDR),
+   DW_SPI_DBGFS_REG("TXFTLR", DW_SPI_TXFTLR),
+   DW_SPI_DBGFS_REG("RXFTLR", DW_SPI_RXFTLR),
+   DW_SPI_DBGFS_REG("TXFLR", DW_SPI_TXFLR),
+   DW_SPI_DBGFS_REG("RXFLR", DW_SPI_RXFLR),
+   DW_SPI_DBGFS_REG("SR", DW_SPI_SR),
+   DW_SPI_DBGFS_REG("IMR", DW_SPI_IMR),
+   DW_SPI_DBGFS_REG("ISR", DW_SPI_ISR),
+   DW_SPI_DBGFS_REG("DMACR", DW_SPI_DMACR),
+   DW_SPI_DBGFS_REG("DMATDLR", 

[PATCH v5 13/16] spi: dw: Cleanup generic DW DMA code namings

[Serge Semin]

Since from now the former Intel MID platform layer is used as a generic
DW SPI DMA module, let's alter the internal methods naming to be
DMA-related instead of having the "mid_" prefix.

Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Co-developed-by: Ramil Zaripov 
Signed-off-by: Ramil Zaripov 
Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v2:
- Leave the DMA setup method suffixes to be mfld and generic.
---
 drivers/spi/spi-dw-dma.c | 85 
 drivers/spi/spi-dw-pci.c |  4 +-
 drivers/spi/spi-dw.h |  8 ++--
 3 files changed, 49 insertions(+), 48 deletions(-)

diff --git a/drivers/spi/spi-dw-dma.c b/drivers/spi/spi-dw-dma.c
index 30bd9800f2df..69b7051e5323 100644
--- a/drivers/spi/spi-dw-dma.c
+++ b/drivers/spi/spi-dw-dma.c
@@ -23,7 +23,7 @@
 #define TX_BUSY1
 #define TX_BURST_LEVEL 16
 
-static bool mid_spi_dma_chan_filter(struct dma_chan *chan, void *param)
+static bool dw_spi_dma_chan_filter(struct dma_chan *chan, void *param)
 {
struct dw_dma_slave *s = param;
 
@@ -34,7 +34,7 @@ static bool mid_spi_dma_chan_filter(struct dma_chan *chan, 
void *param)
return true;
 }
 
-static void mid_spi_maxburst_init(struct dw_spi *dws)
+static void dw_spi_dma_maxburst_init(struct dw_spi *dws)
 {
struct dma_slave_caps caps;
u32 max_burst, def_burst;
@@ -59,7 +59,7 @@ static void mid_spi_maxburst_init(struct dw_spi *dws)
dws->txburst = min(max_burst, def_burst);
 }
 
-static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
+static int dw_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
 {
struct dw_dma_slave slave = {
.src_id = 0,
@@ -81,13 +81,13 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct 
dw_spi *dws)
 
/* 1. Init rx channel */
slave.dma_dev = _dev->dev;
-   dws->rxchan = dma_request_channel(mask, mid_spi_dma_chan_filter, 
);
+   dws->rxchan = dma_request_channel(mask, dw_spi_dma_chan_filter, );
if (!dws->rxchan)
goto err_exit;
 
/* 2. Init tx channel */
slave.dst_id = 1;
-   dws->txchan = dma_request_channel(mask, mid_spi_dma_chan_filter, 
);
+   dws->txchan = dma_request_channel(mask, dw_spi_dma_chan_filter, );
if (!dws->txchan)
goto free_rxchan;
 
@@ -96,7 +96,7 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct 
dw_spi *dws)
 
init_completion(>dma_completion);
 
-   mid_spi_maxburst_init(dws);
+   dw_spi_dma_maxburst_init(dws);
 
return 0;
 
@@ -107,7 +107,7 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct 
dw_spi *dws)
return -EBUSY;
 }
 
-static int mid_spi_dma_init_generic(struct device *dev, struct dw_spi *dws)
+static int dw_spi_dma_init_generic(struct device *dev, struct dw_spi *dws)
 {
dws->rxchan = dma_request_slave_channel(dev, "rx");
if (!dws->rxchan)
@@ -125,12 +125,12 @@ static int mid_spi_dma_init_generic(struct device *dev, 
struct dw_spi *dws)
 
init_completion(>dma_completion);
 
-   mid_spi_maxburst_init(dws);
+   dw_spi_dma_maxburst_init(dws);
 
return 0;
 }
 
-static void mid_spi_dma_exit(struct dw_spi *dws)
+static void dw_spi_dma_exit(struct dw_spi *dws)
 {
if (dws->txchan) {
dmaengine_terminate_sync(dws->txchan);
@@ -145,7 +145,7 @@ static void mid_spi_dma_exit(struct dw_spi *dws)
dw_writel(dws, DW_SPI_DMACR, 0);
 }
 
-static irqreturn_t dma_transfer(struct dw_spi *dws)
+static irqreturn_t dw_spi_dma_transfer_handler(struct dw_spi *dws)
 {
u16 irq_status = dw_readl(dws, DW_SPI_ISR);
 
@@ -161,15 +161,16 @@ static irqreturn_t dma_transfer(struct dw_spi *dws)
return IRQ_HANDLED;
 }
 
-static bool mid_spi_can_dma(struct spi_controller *master,
-   struct spi_device *spi, struct spi_transfer *xfer)
+static bool dw_spi_can_dma(struct spi_controller *master,
+  struct spi_device *spi, struct spi_transfer *xfer)
 {
struct dw_spi *dws = spi_controller_get_devdata(master);
 
return xfer->len > dws->fifo_len;
 }
 
-static enum dma_slave_buswidth convert_dma_width(u8 n_bytes) {
+static enum dma_slave_buswidth dw_spi_dma_convert_width(u8 n_bytes)
+{
if (n_bytes == 1)
return DMA_SLAVE_BUSWIDTH_1_BYTE;
else if (n_bytes == 2)
@@ -244,8 +245,8 @@ static void dw_spi_dma_tx_done(void *arg)
complete(>dma_completion);
 }
 
-static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi 
*dws,
-   struct spi_transfer *xfer)
+static struct dma_async_tx_descriptor *
+dw_spi_dma_prepare_tx(struct dw_spi *dws, struct spi_transfer *xfer)
 {
struct dma_slave_config txconf;
struct 

[PATCH v5 08/16] spi: dw: Fix Rx-only DMA transfers

[Serge Semin]

Tx-only DMA transfers are working perfectly fine since in this case
the code just ignores the Rx FIFO overflow interrupts. But it turns
out the SPI Rx-only transfers are broken since nothing pushing any
data to the shift registers, so the Rx FIFO is left empty and the
SPI core subsystems just returns a timeout error. Since DW DMAC
driver doesn't support something like cyclic write operations of
a single byte to a device register, the only way to support the
Rx-only SPI transfers is to fake it by using a dummy Tx-buffer.
This is what we intend to fix in this commit by setting the
SPI_CONTROLLER_MUST_TX flag for DMA-capable platform.

Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/spi-dw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 6939e003e3e9..4d1849699a12 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -515,6 +515,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
dev_warn(dev, "DMA init failed\n");
} else {
master->can_dma = dws->dma_ops->can_dma;
+   master->flags |= SPI_CONTROLLER_MUST_TX;
}
}
 
-- 
2.26.2

[PATCH v5 10/16] spi: dw: Move Non-DMA code to the DW PCIe-SPI driver

[Serge Semin]

This is a preparation patch before adding the DW DMA support into the
DW SPI MMIO driver. We need to unpin the Non-DMA-specific code from the
intended to be generic DW APB SSI DMA code. This isn't that hard,
since the most part of the spi-dw-mid.c driver in fact implements a
generic DMA interface for the DW SPI controller driver. The only Intel
MID specifics concern getting the max frequency from the MRST Clock
Control Unit and fetching the DMA controller channels from
corresponding PCIe DMA controller. Since first one is related with the
SPI interface configuration we moved it' implementation into the
DW PCIe-SPI driver module. After that former spi-dw-mid.c file
can be just renamed to be the DW SPI DMA module optionally compiled in to
the DW APB SSI core driver.

Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Co-developed-by: Ramil Zaripov 
Signed-off-by: Ramil Zaripov 
Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v2:
- Compile the DW SPI DMA module into the DW APB SSI core instead of being
  a separate driver.
---
 drivers/spi/Kconfig|  8 +--
 drivers/spi/Makefile   |  4 +-
 drivers/spi/{spi-dw-mid.c => spi-dw-dma.c} | 66 +++---
 drivers/spi/spi-dw-pci.c   | 50 +++-
 drivers/spi/spi-dw.h   | 14 -
 5 files changed, 73 insertions(+), 69 deletions(-)
 rename drivers/spi/{spi-dw-mid.c => spi-dw-dma.c} (88%)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 741b9140992a..03b061975f70 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -226,14 +226,14 @@ config SPI_DESIGNWARE
help
  general driver for SPI controller core from DesignWare
 
+config SPI_DW_DMA
+   bool "DMA support for DW SPI controller"
+   depends on SPI_DESIGNWARE && DW_DMAC_PCI
+
 config SPI_DW_PCI
tristate "PCI interface driver for DW SPI core"
depends on SPI_DESIGNWARE && PCI
 
-config SPI_DW_MID_DMA
-   bool "DMA support for DW SPI controller on Intel MID platform"
-   depends on SPI_DW_PCI && DW_DMAC_PCI
-
 config SPI_DW_MMIO
tristate "Memory-mapped io interface driver for DW SPI core"
depends on SPI_DESIGNWARE
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 70ebc2a62e5f..c4aa80085257 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -37,9 +37,9 @@ obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
 obj-$(CONFIG_SPI_DLN2) += spi-dln2.o
 obj-$(CONFIG_SPI_DESIGNWARE)   += spi-dw.o
 spi-dw-y   := spi-dw-core.o
+spi-dw-$(CONFIG_SPI_DW_DMA)+= spi-dw-dma.o
 obj-$(CONFIG_SPI_DW_MMIO)  += spi-dw-mmio.o
-obj-$(CONFIG_SPI_DW_PCI)   += spi-dw-midpci.o
-spi-dw-midpci-objs := spi-dw-pci.o spi-dw-mid.o
+obj-$(CONFIG_SPI_DW_PCI)   += spi-dw-pci.o
 obj-$(CONFIG_SPI_EFM32)+= spi-efm32.o
 obj-$(CONFIG_SPI_EP93XX)   += spi-ep93xx.o
 obj-$(CONFIG_SPI_FALCON)   += spi-falcon.o
diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-dma.c
similarity index 88%
rename from drivers/spi/spi-dw-mid.c
rename to drivers/spi/spi-dw-dma.c
index ff79b4239d68..30bd9800f2df 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-dma.c
@@ -1,16 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Special handling for DW core on Intel MID platform
+ * Special handling for DW DMA core
  *
  * Copyright (c) 2009, 2014 Intel Corporation.
  */
 
-#include 
-#include 
-
-#include "spi-dw.h"
-
-#ifdef CONFIG_SPI_DW_MID_DMA
 #include 
 #include 
 #include 
@@ -18,6 +12,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include "spi-dw.h"
 
 #define WAIT_RETRIES   5
 #define RX_BUSY0
@@ -461,10 +459,11 @@ static const struct dw_spi_dma_ops mfld_dma_ops = {
.dma_stop   = mid_spi_dma_stop,
 };
 
-static void dw_spi_mid_setup_dma_mfld(struct dw_spi *dws)
+void dw_spi_mid_setup_dma_mfld(struct dw_spi *dws)
 {
dws->dma_ops = _dma_ops;
 }
+EXPORT_SYMBOL_GPL(dw_spi_mid_setup_dma_mfld);
 
 static const struct dw_spi_dma_ops generic_dma_ops = {
.dma_init   = mid_spi_dma_init_generic,
@@ -475,55 +474,8 @@ static const struct dw_spi_dma_ops generic_dma_ops = {
.dma_stop   = mid_spi_dma_stop,
 };
 
-static void dw_spi_mid_setup_dma_generic(struct dw_spi *dws)
+void dw_spi_mid_setup_dma_generic(struct dw_spi *dws)
 {
dws->dma_ops = _dma_ops;
 }
-#else  /* CONFIG_SPI_DW_MID_DMA */
-static inline void dw_spi_mid_setup_dma_mfld(struct dw_spi *dws) {}
-static inline void dw_spi_mid_setup_dma_generic(struct dw_spi *dws) {}
-#endif
-
-/* Some specific info for SPI0 controller on Intel MID */
-
-/* HW info for 

[PATCH v5 16/16] dt-bindings: spi: Convert DW SPI binding to DT schema

[Serge Semin]

Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces two DW SPI legacy
bare text bindings with YAML file. As before the bindings file states
that the corresponding dts node is supposed to be compatible either
with generic DW APB SSI controller or with Microsemi/Amazon/Renesas/Intel
vendors-specific controllers, to have registers, interrupts and clocks
properties. Though in case of Microsemi version of the controller
there must be two registers resources specified. Properties like
clock-names, reg-io-width, cs-gpio, num-cs, DMA and slave device
sub-nodes are optional.

Signed-off-by: Serge Semin 
Reviewed-by: Rob Herring 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Feng Tang 
Cc: Andy Shevchenko 
Cc: Arnd Bergmann 
Cc: linux-m...@vger.kernel.org
---
 .../bindings/spi/snps,dw-apb-ssi.txt  |  44 --
 .../bindings/spi/snps,dw-apb-ssi.yaml | 127 ++
 .../devicetree/bindings/spi/spi-dw.txt|  24 
 3 files changed, 127 insertions(+), 68 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt

diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt 
b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
deleted file mode 100644
index 020e3168ee41..
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface.
-
-Required properties:
-- compatible : "snps,dw-apb-ssi" or "mscc,-spi", where soc is "ocelot" or
-  "jaguar2", or "amazon,alpine-dw-apb-ssi", or "snps,dwc-ssi-1.01a" or
-  "intel,keembay-ssi"
-- reg : The register base for the controller. For "mscc,-spi", a second
-  register set is required (named ICPU_CFG:SPI_MST)
-- interrupts : One interrupt, used by the controller.
-- #address-cells : <1>, as required by generic SPI binding.
-- #size-cells : <0>, also as required by generic SPI binding.
-- clocks : phandles for the clocks, see the description of clock-names below.
-   The phandle for the "ssi_clk" is required. The phandle for the "pclk" clock
-   is optional. If a single clock is specified but no clock-name, it is the
-   "ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first.
-
-Optional properties:
-- clock-names : Contains the names of the clocks:
-"ssi_clk", for the core clock used to generate the external SPI clock.
-"pclk", the interface clock, required for register access. If a clock 
domain
- used to enable this clock then it should be named "pclk_clkdomain".
-- cs-gpios : Specifies the gpio pins to be used for chipselects.
-- num-cs : The number of chipselects. If omitted, this will default to 4.
-- reg-io-width : The I/O register width (in bytes) implemented by this
-  device.  Supported values are 2 or 4 (the default).
-- dmas : Phandle + identifiers of Tx and Rx DMA channels.
-- dma-names : Contains the names of the DMA channels. Must be "tx" and "rx".
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
-   spi@fff0 {
-   compatible = "snps,dw-apb-ssi";
-   reg = <0xfff0 0x1000>;
-   interrupts = <0 154 4>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   clocks = <_m_clk>;
-   num-cs = <2>;
-   cs-gpios = < 13 0>,
-  < 14 0>;
-   };
-
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml 
b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
new file mode 100644
index ..1fcab6415136
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/snps,dw-apb-ssi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface
+
+maintainers:
+  - Mark Brown 
+
+allOf:
+  - $ref: "spi-controller.yaml#"
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - mscc,ocelot-spi
+  - mscc,jaguar2-spi
+then:
+  properties:
+reg:
+  minItems: 2
+
+properties:
+  compatible:
+oneOf:
+  - description: Generic DW SPI Controller
+enum:
+  - snps,dw-apb-ssi
+  - snps,dwc-ssi-1.01a
+  - description: Microsemi Ocelot/Jaguar2 SoC SPI Controller
+items:
+  - enum:
+  - mscc,ocelot-spi
+  - mscc,jaguar2-spi
+  - const: snps,dw-apb-ssi
+  - description: Amazon Alpine SPI Controller
+const: amazon,alpine-dw-apb-ssi
+  - description: Renesas RZ/N1 SPI Controller
+

[PATCH v5 12/16] spi: dw: Add DW SPI DMA/PCI/MMIO dependency on the DW SPI core

[Serge Semin]

Seeing all of the DW SPI driver components like DW SPI DMA/PCI/MMIO
depend on the DW SPI core code it's better to use the if-endif
conditional kernel config statement to signify that common dependency.

Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Co-developed-by: Ramil Zaripov 
Signed-off-by: Ramil Zaripov 
Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/Kconfig | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 6a84f3dad35c..3cdf8310d185 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -226,17 +226,20 @@ config SPI_DESIGNWARE
help
  general driver for SPI controller core from DesignWare
 
+if SPI_DESIGNWARE
+
 config SPI_DW_DMA
bool "DMA support for DW SPI controller"
-   depends on SPI_DESIGNWARE
 
 config SPI_DW_PCI
tristate "PCI interface driver for DW SPI core"
-   depends on SPI_DESIGNWARE && PCI
+   depends on PCI
 
 config SPI_DW_MMIO
tristate "Memory-mapped io interface driver for DW SPI core"
-   depends on SPI_DESIGNWARE
+   depends on HAS_IOMEM
+
+endif
 
 config SPI_DLN2
tristate "Diolan DLN-2 USB SPI adapter"
-- 
2.26.2

[PATCH v5 03/16] spi: dw: Locally wait for the DMA transactions completion

[Serge Semin]

Even if DMA transactions are finished it doesn't mean that the SPI
transfers are also completed. It's specifically concerns the Tx-only
SPI transfers, since there might be data left in the SPI Tx FIFO after
the DMA engine notifies that the Tx DMA procedure is done. In order to
completely fix the problem first the driver has to wait for the DMA
transaction completion, then for the corresponding SPI operations to be
finished. In this commit we implement the former part of the solution.

Note we can't just move the SPI operations wait procedure to the DMA
completion callbacks, since these callbacks might be executed in the
tasklet context (and they will be in case of the DW DMA). In case of
slow SPI bus it can cause significant system performance drop.

Signed-off-by: Serge Semin 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Andy Shevchenko 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/spi-dw-mid.c | 44 
 drivers/spi/spi-dw.h |  2 ++
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 7ff1acaa55f8..355b641c4483 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -11,9 +11,11 @@
 #include "spi-dw.h"
 
 #ifdef CONFIG_SPI_DW_MID_DMA
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +68,8 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct 
dw_spi *dws)
dws->master->dma_rx = dws->rxchan;
dws->master->dma_tx = dws->txchan;
 
+   init_completion(>dma_completion);
+
return 0;
 
 free_rxchan:
@@ -91,6 +95,8 @@ static int mid_spi_dma_init_generic(struct device *dev, 
struct dw_spi *dws)
dws->master->dma_rx = dws->rxchan;
dws->master->dma_tx = dws->txchan;
 
+   init_completion(>dma_completion);
+
return 0;
 }
 
@@ -121,7 +127,7 @@ static irqreturn_t dma_transfer(struct dw_spi *dws)
 
dev_err(>master->dev, "%s: FIFO overrun/underrun\n", __func__);
dws->master->cur_msg->status = -EIO;
-   spi_finalize_current_transfer(dws->master);
+   complete(>dma_completion);
return IRQ_HANDLED;
 }
 
@@ -142,6 +148,29 @@ static enum dma_slave_buswidth convert_dma_width(u8 
n_bytes) {
return DMA_SLAVE_BUSWIDTH_UNDEFINED;
 }
 
+static int dw_spi_dma_wait(struct dw_spi *dws, struct spi_transfer *xfer)
+{
+   unsigned long long ms;
+
+   ms = xfer->len * MSEC_PER_SEC * BITS_PER_BYTE;
+   do_div(ms, xfer->effective_speed_hz);
+   ms += ms + 200;
+
+   if (ms > UINT_MAX)
+   ms = UINT_MAX;
+
+   ms = wait_for_completion_timeout(>dma_completion,
+msecs_to_jiffies(ms));
+
+   if (ms == 0) {
+   dev_err(>master->cur_msg->spi->dev,
+   "DMA transaction timed out\n");
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
 /*
  * dws->dma_chan_busy is set before the dma transfer starts, callback for tx
  * channel will clear a corresponding bit.
@@ -155,7 +184,7 @@ static void dw_spi_dma_tx_done(void *arg)
return;
 
dw_writel(dws, DW_SPI_DMACR, 0);
-   spi_finalize_current_transfer(dws->master);
+   complete(>dma_completion);
 }
 
 static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi 
*dws,
@@ -204,7 +233,7 @@ static void dw_spi_dma_rx_done(void *arg)
return;
 
dw_writel(dws, DW_SPI_DMACR, 0);
-   spi_finalize_current_transfer(dws->master);
+   complete(>dma_completion);
 }
 
 static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi 
*dws,
@@ -260,6 +289,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct 
spi_transfer *xfer)
/* Set the interrupt mask */
spi_umask_intr(dws, imr);
 
+   reinit_completion(>dma_completion);
+
dws->transfer_handler = dma_transfer;
 
return 0;
@@ -268,6 +299,7 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct 
spi_transfer *xfer)
 static int mid_spi_dma_transfer(struct dw_spi *dws, struct spi_transfer *xfer)
 {
struct dma_async_tx_descriptor *txdesc, *rxdesc;
+   int ret;
 
/* Prepare the TX dma transfer */
txdesc = dw_spi_dma_prepare_tx(dws, xfer);
@@ -288,7 +320,11 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, struct 
spi_transfer *xfer)
dma_async_issue_pending(dws->txchan);
}
 
-   return 1;
+   ret = dw_spi_dma_wait(dws, xfer);
+   if (ret)
+   return ret;
+
+   return 0;
 }
 
 static void mid_spi_dma_stop(struct dw_spi *dws)
diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
index 79782e93eb12..9585d0c83a6d 100644
--- a/drivers/spi/spi-dw.h
+++ b/drivers/spi/spi-dw.h
@@ -2,6 +2,7 @@
 #ifndef DW_SPI_HEADER_H
 #define DW_SPI_HEADER_H
 

[PATCH v5 14/16] spi: dw: Add DMA support to the DW SPI MMIO driver

[Serge Semin]

Since the common code in the spi-dw-dma.c driver is ready to be used
by the MMIO driver and now provides a method to generically (on any
DT or ACPI-based platforms) retrieve the Tx/Rx DMA channel handlers,
we can use it and a set of the common DW SPI DMA callbacks to enable
DMA at least for generic "snps,dw-apb-ssi" and "snps,dwc-ssi-1.01a"
devices.

Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Co-developed-by: Ramil Zaripov 
Signed-off-by: Ramil Zaripov 
Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/spi-dw-mmio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index 0894b4c09496..e23d0c53a664 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -149,6 +149,8 @@ static int dw_spi_dw_apb_init(struct platform_device *pdev,
/* Register hook to configure CTRLR0 */
dwsmmio->dws.update_cr0 = dw_spi_update_cr0;
 
+   dw_spi_dma_setup_generic(>dws);
+
return 0;
 }
 
@@ -158,6 +160,8 @@ static int dw_spi_dwc_ssi_init(struct platform_device *pdev,
/* Register hook to configure CTRLR0 */
dwsmmio->dws.update_cr0 = dw_spi_update_cr0_v1_01a;
 
+   dw_spi_dma_setup_generic(>dws);
+
return 0;
 }
 
-- 
2.26.2

[PATCH v5 06/16] spi: dw: Parameterize the DMA Rx/Tx burst length

[Serge Semin]

It isn't good to have numeric literals in the code especially if there
are multiple of them and they are related. Let's replace the Tx and Rx
burst level literals with the corresponding constants.

Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Co-developed-by: Ramil Zaripov 
Signed-off-by: Ramil Zaripov 
Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v3:
- Discard the dws->fifo_len utilization in the Tx FIFO DMA threshold
  setting.
---
 drivers/spi/spi-dw-mid.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 4345881ebf66..93463bdba0f8 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -21,7 +21,9 @@
 
 #define WAIT_RETRIES   5
 #define RX_BUSY0
+#define RX_BURST_LEVEL 16
 #define TX_BUSY1
+#define TX_BURST_LEVEL 16
 
 static bool mid_spi_dma_chan_filter(struct dma_chan *chan, void *param)
 {
@@ -227,7 +229,7 @@ static struct dma_async_tx_descriptor 
*dw_spi_dma_prepare_tx(struct dw_spi *dws,
memset(, 0, sizeof(txconf));
txconf.direction = DMA_MEM_TO_DEV;
txconf.dst_addr = dws->dma_addr;
-   txconf.dst_maxburst = 16;
+   txconf.dst_maxburst = TX_BURST_LEVEL;
txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
txconf.dst_addr_width = convert_dma_width(dws->n_bytes);
txconf.device_fc = false;
@@ -319,7 +321,7 @@ static struct dma_async_tx_descriptor 
*dw_spi_dma_prepare_rx(struct dw_spi *dws,
memset(, 0, sizeof(rxconf));
rxconf.direction = DMA_DEV_TO_MEM;
rxconf.src_addr = dws->dma_addr;
-   rxconf.src_maxburst = 16;
+   rxconf.src_maxburst = RX_BURST_LEVEL;
rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
rxconf.src_addr_width = convert_dma_width(dws->n_bytes);
rxconf.device_fc = false;
@@ -344,8 +346,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct 
spi_transfer *xfer)
 {
u16 imr = 0, dma_ctrl = 0;
 
-   dw_writel(dws, DW_SPI_DMARDLR, 0xf);
-   dw_writel(dws, DW_SPI_DMATDLR, 0x10);
+   dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
+   dw_writel(dws, DW_SPI_DMATDLR, TX_BURST_LEVEL);
 
if (xfer->tx_buf) {
dma_ctrl |= SPI_DMA_TDMAE;
-- 
2.26.2

[PATCH v5 00/16] spi: dw: Add generic DW DMA controller support

[Serge Semin]

Baikal-T1 SoC provides a DW DMA controller to perform low-speed peripherals
Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
APB SSI devices embedded into the SoC. Currently the DMA-based transfers
are supported by the DW APB SPI driver only as a middle layer code for
Intel MID/Elkhart PCI devices. Seeing the same code can be used for normal
platform DMAC device we introduced a set of patches to fix it within this
series.

First of all we need to add the Tx and Rx DMA channels support into the DW
APB SSI binding. Then there are several fixes and cleanups provided as a
initial preparation for the Generic DMA support integration: add Tx/Rx
finish wait methods, clear DMAC register when done or stopped, Fix native
CS being unset, enable interrupts in accordance with DMA xfer mode,
discard static DW DMA slave structures, discard unused void priv pointer
and dma_width member of the dw_spi structure, provide the DMA Tx/Rx burst
length parametrisation and make sure it's optionally set in accordance
with the DMA max-burst capability.

In order to have the DW APB SSI MMIO driver working with DMA we need to
initialize the paddr field with the physical base address of the DW APB SSI
registers space. Then we unpin the Intel MID specific code from the
generic DMA one and placed it into the spi-dw-pci.c driver, which is a
better place for it anyway. After that the naming cleanups are performed
since the code is going to be used for a generic DMAC device. Finally the
Generic DMA initialization can be added to the generic version of the
DW APB SSI IP.

Last but not least we traditionally convert the legacy plain text-based
dt-binding file with yaml-based one and as a cherry on a cake replace
the manually written DebugFS registers read method with a ready-to-use
for the same purpose regset32 DebugFS interface usage.

This patchset is rebased and tested on the spi/for-next (5.7-rc5):
base-commit: fe9fce6b2cf3 ("Merge remote-tracking branch 'spi/for-5.8' into 
spi-next")

Link: 
https://lore.kernel.org/linux-spi/20200508132943.9826-1-sergey.se...@baikalelectronics.ru/
Changelog v2:
- Rebase on top of the spi repository for-next branch.
- Move bindings conversion patch to the tail of the series.
- Move fixes to the head of the series.
- Apply as many changes as possible to be applied the Generic DMA
  functionality support is added and the spi-dw-mid is moved to the
  spi-dw-dma driver.
- Discard patch "spi: dw: Fix dma_slave_config used partly uninitialized"
  since the problem has already been fixed.
- Add new patch "spi: dw: Discard unused void priv pointer".
- Add new patch "spi: dw: Discard dma_width member of the dw_spi structure".
  n_bytes member of the DW SPI data can be used instead.
- Build the DMA functionality into the DW APB SSI core if required instead
  of creating a separate kernel module.
- Use conditional statement instead of the ternary operator in the ref
  clock getter.

Link: 
https://lore.kernel.org/linux-spi/20200515104758.6934-1-sergey.se...@baikalelectronics.ru/
Changelog v3:
- Use spi_delay_exec() method to wait for the DMA operation completion.
- Explicitly initialize the dw_dma_slave members on stack.
- Discard the dws->fifo_len utilization in the Tx FIFO DMA threshold
  setting from the patch where we just add the default burst length
  constants.
- Use min() method to calculate the optimal burst values.
- Add new patch which moves the spi-dw.c source file to spi-dw-core.c in
  order to preserve the DW APB SSI core driver name.
- Add commas in the debugfs_reg32 structure initializer and after the last
  entry of the dw_spi_dbgfs_regs array.

Link: 
https://lore.kernel.org/linux-spi/20200521012206.14472-1-sergey.se...@baikalelectronics.ru
Changelog v4:
- Get back ndelay() method to wait for an SPI transfer completion.
  spi_delay_exec() isn't suitable for the atomic context.

Link: 
https://lore.kernel.org/linux-spi/20200522000806.7381-1-sergey.se...@baikalelectronics.ru
Changelog v5:
- Refactor the Tx/Rx DMA-based SPI transfers wait methods.
- Add a new patch "spi: dw: Set xfer effective_speed_hz".
- Add a new patch "spi: dw: Return any value retrieved from the
  dma_transfer callback" as a preparation patch before implementing
  the local DMA, Tx SPI and Rx SPI transfers wait methods.
- Add a new patch "spi: dw: Locally wait for the DMA transactions
  completion", which provides a local DMA transaction complete
  method
- Create a dedicated patch which adds the Rx-done wait method:
  "spi: dw: Add SPI Rx-done wait method to DMA-based transfer".
- Add more detailed description of the problems the Tx/Rx-wait
  methods-related patches fix.
- Wait for the SPI Tx and Rx transfers being finished in the
  mid_spi_dma_transfer() method executed in the task context.
- Use spi_delay_exec() to wait for the SPI Tx/Rx completion, since now
  the driver calls the wait methods in the kernel thread context.
- Use SPI_DELAY_UNIT_SCK spi_delay unit for Tx-wait delay, since SPI
  xfer's 

[PATCH v5 04/16] spi: dw: Add SPI Tx-done wait method to DMA-based transfer

[Serge Semin]

Since DMA transfers are performed asynchronously with actual SPI bus
transfers, then even if DMA transactions are finished it doesn't mean
all data is actually pushed to the SPI bus. Some data might still be
in the controller FIFO. This is specifically true for Tx-only transfers.
In this case if the next SPI transfer is recharged while a tail of the
previous one is still in FIFO, we'll loose that tail data. In order to
fix that problem let's add the wait procedure of the Tx SPI transfer
completion after the DMA transactions are finished.

Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support")
Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Signed-off-by: Serge Semin 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Andy Shevchenko 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v2:
- Use conditional statement instead of the ternary operator in the ref
  clock getter.
- Move the patch to the head of the series so one could be picked up to
  the stable kernels as a fix.

Changelog v3:
- Use spi_delay_exec() method to wait for the current operation completion.

Changelog v4:
- Get back ndelay() method to wait for an SPI transfer completion.
  spi_delay_exec() isn't suitable for the atomic context.

Changelog v5:
- Add more detailed description of the problems the patch fixes.
- Wait for the SPI Tx transfer finish in the mid_spi_dma_transfer() method
  executed in the task context.
- Use spi_delay_exec() to wait for the SPI Tx completion, since now the
  driver does in the kernel thread context.
- Use SPI_DELAY_UNIT_SCK spi_delay unit, since SPI xfer's are now have the
  effective_speed_hz initialized.
---
 drivers/spi/spi-dw-mid.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 355b641c4483..846e3db91329 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 
+#define WAIT_RETRIES   5
 #define RX_BUSY0
 #define TX_BUSY1
 
@@ -171,6 +172,33 @@ static int dw_spi_dma_wait(struct dw_spi *dws, struct 
spi_transfer *xfer)
return 0;
 }
 
+static inline bool dw_spi_dma_tx_busy(struct dw_spi *dws)
+{
+   return !(dw_readl(dws, DW_SPI_SR) & SR_TF_EMPT);
+}
+
+static int dw_spi_dma_wait_tx_done(struct dw_spi *dws,
+  struct spi_transfer *xfer)
+{
+   int retry = WAIT_RETRIES;
+   struct spi_delay delay;
+   u32 nents;
+
+   nents = dw_readl(dws, DW_SPI_TXFLR);
+   delay.unit = SPI_DELAY_UNIT_SCK;
+   delay.value = nents * dws->n_bytes * BITS_PER_BYTE;
+
+   while (dw_spi_dma_tx_busy(dws) && retry--)
+   spi_delay_exec(, xfer);
+
+   if (retry < 0) {
+   dev_err(>master->dev, "Tx hanged up\n");
+   return -EIO;
+   }
+
+   return 0;
+}
+
 /*
  * dws->dma_chan_busy is set before the dma transfer starts, callback for tx
  * channel will clear a corresponding bit.
@@ -324,6 +352,12 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, struct 
spi_transfer *xfer)
if (ret)
return ret;
 
+   if (txdesc && dws->master->cur_msg->status == -EINPROGRESS) {
+   ret = dw_spi_dma_wait_tx_done(dws, xfer);
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 
-- 
2.26.2

[PATCH v5 09/16] spi: dw: Add core suffix to the DW APB SSI core source file

[Serge Semin]

Generic DMA support is going to be part of the DW APB SSI core object.
In order to preserve the kernel loadable module name as spi-dw.ko, let's
add the "-core" suffix to the object with generic DW APB SSI code and
build it into the target spi-dw.ko driver.

Signed-off-by: Serge Semin 
Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: Arnd Bergmann 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org

---

Changelog v3:
- This is a new patch added as a result of the discussion with Andy
  Shevchenko.
---
 drivers/spi/Makefile| 1 +
 drivers/spi/{spi-dw.c => spi-dw-core.c} | 0
 2 files changed, 1 insertion(+)
 rename drivers/spi/{spi-dw.c => spi-dw-core.c} (100%)

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 28f601327f8c..70ebc2a62e5f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SPI_COLDFIRE_QSPI)   += 
spi-coldfire-qspi.o
 obj-$(CONFIG_SPI_DAVINCI)  += spi-davinci.o
 obj-$(CONFIG_SPI_DLN2) += spi-dln2.o
 obj-$(CONFIG_SPI_DESIGNWARE)   += spi-dw.o
+spi-dw-y   := spi-dw-core.o
 obj-$(CONFIG_SPI_DW_MMIO)  += spi-dw-mmio.o
 obj-$(CONFIG_SPI_DW_PCI)   += spi-dw-midpci.o
 spi-dw-midpci-objs := spi-dw-pci.o spi-dw-mid.o
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw-core.c
similarity index 100%
rename from drivers/spi/spi-dw.c
rename to drivers/spi/spi-dw-core.c
-- 
2.26.2

[PATCH v5 01/16] spi: dw: Set xfer effective_speed_hz

[Serge Semin]

Seeing DW APB SSI controller doesn't support setting the exactly
requested SPI bus frequency, but only a rounded frequency determined
by means of the odd-numbered half-worded reference clock divider,
it would be good tune the SPI core up and initialize the current
transfer effective_speed_hz. By doing so the core will be able to
execute the xfer-related delays with better accuracy.

Signed-off-by: Serge Semin 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Andy Shevchenko 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/spi-dw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 9d6904d30104..050cb2ea0812 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -352,6 +352,7 @@ static int dw_spi_transfer_one(struct spi_controller 
*master,
spi_set_clk(dws, chip->clk_div);
}
 
+   transfer->effective_speed_hz = dws->max_freq / chip->clk_div;
dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
 
cr0 = dws->update_cr0(master, spi, transfer);
-- 
2.26.2

[PATCH v5 02/16] spi: dw: Return any value retrieved from the dma_transfer callback

[Serge Semin]

DW APB SSI DMA may need to perform the synchronous operations. In that
case the dma_transfer() callback will return 0 as a marker of the SPI
transfer being finished so the SPI core can proceed with the SPI
message trasnfers pumping procedure. This will be needed to fix the
problem when DMA transactions are finished, but there is still data
left in the SPI Tx/Rx buffers. But for now make dma_transfer to
return 1 as the normal dw_spi_transfer_one() method.

Signed-off-by: Serge Semin 
Cc: Georgy Vlasov 
Cc: Ramil Zaripov 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Andy Shevchenko 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/spi-dw-mid.c | 2 +-
 drivers/spi/spi-dw.c | 7 ++-
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index b1710132b7b2..7ff1acaa55f8 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -288,7 +288,7 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, struct 
spi_transfer *xfer)
dma_async_issue_pending(dws->txchan);
}
 
-   return 0;
+   return 1;
 }
 
 static void mid_spi_dma_stop(struct dw_spi *dws)
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 050cb2ea0812..6939e003e3e9 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -389,11 +389,8 @@ static int dw_spi_transfer_one(struct spi_controller 
*master,
 
spi_enable_chip(dws, 1);
 
-   if (dws->dma_mapped) {
-   ret = dws->dma_ops->dma_transfer(dws, transfer);
-   if (ret < 0)
-   return ret;
-   }
+   if (dws->dma_mapped)
+   return dws->dma_ops->dma_transfer(dws, transfer);
 
return 1;
 }
-- 
2.26.2

[PATCH v5 11/16] spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI

[Serge Semin]

Since there is a generic method available to initialize the DW SPI DMA
interface on any DT and ACPI-based platforms, which in general can be
designed with not only DW DMAC but with any DMA engine on board, we can
freely remove the CONFIG_DW_DMAC_PCI config from dependency list of
CONFIG_SPI_DW_DMA. Especially seeing that we don't use anything DW DMAC
specific in the new driver.

Co-developed-by: Georgy Vlasov 
Signed-off-by: Georgy Vlasov 
Co-developed-by: Ramil Zaripov 
Signed-off-by: Ramil Zaripov 
Signed-off-by: Serge Semin 
Reviewed-by: Andy Shevchenko 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Arnd Bergmann 
Cc: Feng Tang 
Cc: Rob Herring 
Cc: linux-m...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 03b061975f70..6a84f3dad35c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -228,7 +228,7 @@ config SPI_DESIGNWARE
 
 config SPI_DW_DMA
bool "DMA support for DW SPI controller"
-   depends on SPI_DESIGNWARE && DW_DMAC_PCI
+   depends on SPI_DESIGNWARE
 
 config SPI_DW_PCI
tristate "PCI interface driver for DW SPI core"
-- 
2.26.2

Re: [PATCH v4 1/2] clk: hisilicon: Use correct return value about hisi_reset_init()

[Stephen Boyd]

Quoting Tiezhu Yang (2020-05-28 19:03:54)
> On 05/29/2020 07:15 AM, Stephen Boyd wrote:
> > Quoting Tiezhu Yang (2020-05-27 19:27:42)
> >> On 05/28/2020 03:06 AM, Stephen Boyd wrote:
> >>> Quoting Tiezhu Yang (2020-05-27 07:39:21)
>  The return value about hisi_reset_init() is not correct, fix it.
> 
>  Fixes: e9a2310fb689 ("reset: hisilicon: fix potential NULL pointer 
>  dereference")
> >>> hisi_reset_init() returns NULL on error in that commit. This patch
> >>> doesn't make sense.
> >> Hi Stephen,
> >>
> >> The initial aim of this patch is to use correct return value about
> >> hisi_reset_init(), maybe NULL is OK, but the return value in this
> >> patch is more accurate.
> > The implementation of hisi_reset_init() that I see is this:
> >
> >
> >   struct hisi_reset_controller *rstc;
> >
> >   rstc = devm_kmalloc(>dev, sizeof(*rstc), GFP_KERNEL);
> >   if (!rstc)
> >   return NULL;
> >
> >   rstc->membase = devm_platform_ioremap_resource(pdev, 0);
> >   if (IS_ERR(rstc->membase))
> >   return NULL;
> >
> >   spin_lock_init(>lock);
> >   rstc->rcdev.owner = THIS_MODULE;
> >   rstc->rcdev.ops = _reset_ops;
> >   rstc->rcdev.of_node = pdev->dev.of_node;
> >   rstc->rcdev.of_reset_n_cells = 2;
> >   rstc->rcdev.of_xlate = hisi_reset_of_xlate;
> >   reset_controller_register(>rcdev);
> >
> >   return rstc;
> >
> > And that returns NULL on an error and a valid pointer on success.
> > Changing the code to check the return value of hisi_reset_init() for an
> > error pointer is simply wrong without updating hisi_reset_init() to
> > return an error pointer on error. Where is the patch that changes
> > hisi_reset_init() to return an error pointer?
> 
> Hi Stephen,
> 
> Do you mean the following changes?

Yes where is this change?