Re: [PATCH] Staging: wlan-ng: prism2sta: fixed indent coding style issues.

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 05:45:07AM +, Efstratios Gavas wrote:
> Fixed coding style issues.
> Signed-off-by: Efstratios Gavas 

We need a blank line before the signed-off-by: line in order to properly
work.

Also, please be much more specific in your changelog text as to what you
are doing here.

And finally, you sent 2 copies of this patch, but no way to tell which
one is the "correct" one.

Please fix this up and resend.

thanks,

greg k-h

Re: [PATCH v3 5/7] kprobes/x86: Fix %p uses in error messages

[Ingo Molnar]

* Masami Hiramatsu  wrote:

>   (addr < (u8 *) jprobe_return_end)) {
>   if (stack_addr(regs) != saved_sp) {
>   struct pt_regs *saved_regs = &kcb->jprobe_saved_regs;
> - printk(KERN_ERR
> -"current sp %p does not match saved sp %p\n",
> + pr_err("current sp %pS does not match saved sp %pS\n",
>  stack_addr(regs), saved_sp);

Why does this use %pS? Stack pointers are typically pointing into general 
kernel 
RAM, which is totally pointless to display 'symbolically'.

Thanks,

Ingo

Re: [PATCH v3 4/7] kprobes: Replace %p with other pointer types

[Ingo Molnar]

* Masami Hiramatsu  wrote:

> @@ -712,7 +712,7 @@ static void reuse_unused_kprobe(struct kprobe *ap)
>   op = container_of(ap, struct optimized_kprobe, kp);
>   if (unlikely(list_empty(&op->list)))
>   printk(KERN_WARNING "Warning: found a stray unused "
> - "aggrprobe@%p\n", ap->addr);
> + "aggrprobe@%pS\n", ap->addr);

Is this a kernel bug? If yes then please convert this to a WARN_ON_ONCE() that 
doesn't print any kernel addresses.

>   /* Enable the probe again */
>   ap->flags &= ~KPROBE_FLAG_DISABLED;
>   /* Optimize it again (remove from op->list) */
> @@ -985,7 +985,8 @@ static int arm_kprobe_ftrace(struct kprobe *p)
>   ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
>  (unsigned long)p->addr, 0, 0);
>   if (ret) {
> - pr_debug("Failed to arm kprobe-ftrace at %p (%d)\n", p->addr, 
> ret);
> + pr_debug("Failed to arm kprobe-ftrace at %pS (%d)\n",
> +  p->addr, ret);
>   return ret;

Can this happen during normal use? If yes then just remove the warning message.

>   }
>  
> @@ -1025,7 +1026,8 @@ static int disarm_kprobe_ftrace(struct kprobe *p)
>  
>   ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
>  (unsigned long)p->addr, 1, 0);
> - WARN(ret < 0, "Failed to disarm kprobe-ftrace at %p (%d)\n", p->addr, 
> ret);
> + WARN(ret < 0, "Failed to disarm kprobe-ftrace at %pS (%d)\n",
> +  p->addr, ret);

As this is a signal of a kernel bug, just convert this to a regular WARN_ONCE() 
that doesn't print any kernel addresses.

> +/* Caller must NOT call this in usual path. This is only for critical case */
>  void dump_kprobe(struct kprobe *kp)
>  {
> - printk(KERN_WARNING "Dumping kprobe:\n");
> - printk(KERN_WARNING "Name: %s\nAddress: %p\nOffset: %x\n",
> -kp->symbol_name, kp->addr, kp->offset);
> + pr_err("Dumping kprobe:\n");
> + pr_err("Name: %s\nOffset: %x\nAddress: %pS\n",
> +kp->symbol_name, kp->offset, kp->addr);

No, this function should just go away and be replaced by a WARN() in 
reenter_kprobe().

Thanks,

Ingo

Re: [PATCH -tip v2 0/7] kprobes: Fix %p in kprobes

[Greg KH]

On Thu, Apr 26, 2018 at 09:14:34PM -0400, Steven Rostedt wrote:
> On Thu, 26 Apr 2018 10:40:22 +0200
> Greg KH  wrote:
> 
> > 
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read:
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to do this properly.
> > 
> > 
> 
> Is it because he didn't add the Cc: sta...@vger.kernel.org tag?

Yes.

Re: [PATCH] m68k: Fix calendar month regression on M68328

[Geert Uytterhoeven]

Hi Greg, Finn,

On Fri, Apr 27, 2018 at 3:33 AM, Greg Ungerer  wrote:
> On 27/04/18 11:12, Finn Thain wrote:
>> My earlier fix for read_persistent_clock() neglected to cover
>> m68328_hwclk(). Correct this oversight.
>>
>> Cc: Geert Uytterhoeven 
>> Signed-off-by: Finn Thain 
>> ---
>> Greg, the read_persistent_clock() change has already been queued
>> by Geert. Should this patch be pushed together with that one
>> (presuming your ack)? Sorry for the inconvenience.
>
> If Geert is happy to add it to his tree that would seem to make sense.
> Otherwise I can take it via the m68knommu tree. Either way:
>
>   Acked-by: Greg Ungerer 

I'm reconsidering.

I'll apply it to my tree, and fold it into the original fix for v4.18.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 1/7] kprobes: Make blacklist root user read only

[Greg KH]

On Fri, Apr 27, 2018 at 03:40:09PM +0900, Masami Hiramatsu wrote:
> Since the blacklist file indicates a sensitive address
> information to reader, it should be restricted to the
> root user.
> 
> Suggested-by: Thomas Richter 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/kprobes.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.



If you want these to go to the stable tree(s), that is great, but please
mark them properly.  As you did it here for this series, it will not
work.

thanks,

greg k-h

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/25/2018 08:16 PM, Dongwon Kim wrote:

On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote:

On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:

On 04/24/2018 11:35 PM, Dongwon Kim wrote:

Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.

I will still have kernel side API, so backends/frontends implemented
in the kernel can access that functionality as well.

So assuming we use these IOCTLs as they are,
Several things I would like you to double-check..

1. returning gref as is to the user space is still unsafe because
it is a constant, easy to guess and any process that hijacks it can easily
exploit the buffer. So I am wondering if it's possible to keep dmabuf-to
-gref or gref-to-dmabuf in kernel space and add other layers on top
of those in actual IOCTLs to add some safety.. We introduced flink like
hyper_dmabuf_id including random number but many says even that is still
not safe.

Yes, it is generally unsafe. But even if we have implemented
the approach you have in hyper-dmabuf or similar, what stops
malicious software from doing the same with the existing gntdev UAPI?
No need to brute force new UAPI if there is a simpler one.
That being said, I'll put security aside at the first stage,
but of course we can start investigating ways to improve
(I assume you already have use-cases where security issues must
be considered, so, probably you can tell more on what was investigated
so far).

Yeah, although we think we lowered the chance of guessing the right id
by adding random number to it, the security hole is still there as far
as we use a constant id across VMs. We understood this from the beginning
but couldn't find a better way. So what we proposed is to make sure our
customer understand this and prepare very secure way to handle this id
in the userspace (mattrope however recently proposed a "hyper-pipe" which
FD-type id can be converted and exchanged safely through. So we are looking
into this now.)

And another approach we have proposed is to use event-polling, that lets
the privileged userapp in importing guest to know about a new exported
DMABUF so that it can retrieve it from the queue then redistribute to
other applications. This method is not very flexible however, is one way
to hide ID from userspace completely.

Anyway, yes, we can continue to investigate the possible way to make it
more secure.

Great, if you come up with something then you'll be able
to plumb this in

Maybe a bit more context here:

So in graphics we have this old flink approach for buffer sharing with
processes, and it's unsafe because way too easy to guess the buffer
handles. And anyone with access to the graphics driver can then import
that buffer object. We switched to file descriptor passing to make sure
only the intended recipient can import a buffer.

So at the vm->vm level it sounds like grefs are safe, because they're only
for a specific other guest (or sets of guests, not sure about). That means
security is only within the OS. For that you need to make sure that
unpriviledge userspace simply can't ever access a gref. If that doesn't
work out, then I guess we should improve the xen gref stuff to have a more
secure cookie.


2. maybe we could take hypervisor-independent process (e.g. SGT<->page)
out of xen-zcopy and put those in a new helper library.

I believe this can be done, but at the first stage I would go without
that helper library, so it is clearly seen what can be moved to it later
(I know that you want to run ACRN as well, but can I run it on ARM? ;)

There's already helpers for walking sgtables and adding pages/enumerating
pages. I don't think we need more.

ok, where would that helpers be located? If we consider we will use these
with other hypervisor drivers, maybe it's better to place those in some
common area?

I am not quite sure what and if those helpers be really needed.
Let's try to prototype the thing and then see what can be
moved to a helper library and where it should live

3. please consider the case where original DMA-BUF's first offset
and last length are not 0 and PAGE_SIZE respectively. I assume current
xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big.

Hm, what is the use-case for that?

Just in general use-case.. I was just considering the case (might be corner
case..) where sg->offset != 0 or sg->length != PAGE_SIZE. Hyper dmabuf sends
this information (first offset and last length) together with references for
pages. So I was wondering if we should so similar thing in zcopy since your
goal is now to cover general dma-buf use-cases (however, danvet mentioned
hard constaint of dma-buf below.. so if this can't happen according to the
spec, then we can ignore it..)

I won't be considering this use-case during prototyping as
it seems it doesn't have a *real* ground underneath

dm

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Lars-Peter Clausen]

On 04/27/2018 07:11 AM, Vinod Koul wrote:
> On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
>> Request IRQ with IRQF_SHARED flag. This works since the interrupt
>> handler already checks if there is an actual IRQ pending and returns
>> IRQ_NONE otherwise.
> 
> hmmm what are we trying to fix here? Is your device on a shared line or not?

IRQF_SHARED does not mean that the IRQ is on a shared line. It means that
the driver can handle it if the IRQ is on a shared line. Since the driver
can handle it setting the flag is a good idea since this enables usecases
where the line is shared.

> 
>>
>> Acked-by: Lars-Peter Clausen 
>> Signed-off-by: Moritz Fischer 
>> ---
>> Changes from v1:
>> - Added Lars' Acked-by
>> - Dropped patch [1/2] and changed accordingly
>> ---
>>  drivers/dma/dma-axi-dmac.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
>> index 2419fe524daa..15b2453d2647 100644
>> --- a/drivers/dma/dma-axi-dmac.c
>> +++ b/drivers/dma/dma-axi-dmac.c
>> @@ -687,7 +687,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
>>  if (ret)
>>  goto err_unregister_device;
>>  
>> -ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, 0,
>> +ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, IRQF_SHARED,
>>  dev_name(&pdev->dev), dmac);
>>  if (ret)
>>  goto err_unregister_of;
>> -- 
>> 2.17.0
>>
> 

Re: [PATCH] sched/numa: Stagger NUMA balancing scan periods for new threads

[Ingo Molnar]

* Mel Gorman  wrote:

> The different in headline performance across a range of machines and
> workloads is marginal but the system CPU usage is reduced due to less scan
> activity.  The following is the time reported by NAS Parallel Benchmark
> using unbound openmp threads and a D size class.
> 
>   4.17.0-rc1 4.17.0-rc1
>  vanilla   stagger-v1r1
> Time bt.D  442.77 (   0.00%)  419.70 (   5.21%)
> Time cg.D  171.90 (   0.00%)  180.85 (  -5.21%)
> Time ep.D   33.10 (   0.00%)   32.90 (   0.60%)
> Time is.D9.59 (   0.00%)9.42 (   1.77%)
> Time lu.D  306.75 (   0.00%)  304.65 (   0.68%)
> Time mg.D   54.56 (   0.00%)   52.38 (   4.00%)
> Time sp.D 1020.03 (   0.00%)  903.77 (  11.40%)
> Time ua.D  400.58 (   0.00%)  386.49 (   3.52%)
> 
> Note it's not a universal win but we have no prior knowledge of which
> thread matters but the number of threads created often exceeds the size of
> the node when the threads are not bound. On balance, the set of workloads
> complete faster and there is a a reducation of overall system CPU usage
> 
> 4.17.0-rc1 4.17.0-rc1
>vanilla   stagger-v1r1
> sys-time-bt.D 48.78 (   0.00%)   48.22 (   1.15%)
> sys-time-cg.D 25.31 (   0.00%)   26.63 (  -5.22%)
> sys-time-ep.D  1.65 (   0.00%)0.62 (  62.42%)
> sys-time-is.D 40.05 (   0.00%)   24.45 (  38.95%)
> sys-time-lu.D 37.55 (   0.00%)   29.02 (  22.72%)
> sys-time-mg.D 47.52 (   0.00%)   34.92 (  26.52%)
> sys-time-sp.D119.01 (   0.00%)  109.05 (   8.37%)
> sys-time-ua.D 51.52 (   0.00%)   45.13 (  12.40%)
> 
> NUMA scan activity is reduced as well as other balancing activity.
> 
> NUMA alloc local   1042828 1342670
> NUMA base PTE updates14048113893577468
> NUMA huge PMD updates   272171  180766
> NUMA page range updates  279832690   186129660
> NUMA hint faults   1395972 1193897
> NUMA hint local faults  877925  855053
> NUMA hint local percent 62  71
> NUMA pages migrated   12057909 9158023

Looks like a nice reduction in scanning overhead - which was always the main 
worry 
with the fault based active NUMA balancing technique.

I have a couple of minor code cleanliness nit:

> +void init_numa_balancing(unsigned long clone_flags, struct task_struct *p)
> +{
> + int mm_users = 0;
> +
> + if (p->mm) {
> + mm_users = atomic_read(&p->mm->mm_users);
> + if (mm_users == 1) {
> + p->mm->numa_next_scan = jiffies + 
> msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
> + p->mm->numa_scan_seq = 0;
> + }
> + }
> + p->node_stamp = 0ULL;
> + p->numa_scan_seq = p->mm ? p->mm->numa_scan_seq : 0;
> + p->numa_scan_period = sysctl_numa_balancing_scan_delay;
> + p->numa_work.next = &p->numa_work;
> + p->numa_faults = NULL;
> + p->last_task_numa_placement = 0;
> + p->last_sum_exec_runtime = 0;
> + p->numa_group = NULL;

While this is pre-existing code that you moved, could we please use a bit more 
organization to make this more readable:

p->node_stamp   = 0ULL;
p->numa_scan_seq= p->mm ? p->mm->numa_scan_seq : 0;
p->numa_scan_period = sysctl_numa_balancing_scan_delay;
p->numa_work.next   = &p->numa_work;
p->numa_faults  = NULL;
p->last_task_numa_placement = 0;
p->last_sum_exec_runtime= 0;
p->numa_group   = NULL;

?

This form made me notice a detail: the 0ULL asymmetry looks weird, this integer 
literal type specification is entirely superfluous here, we can just write '0'.

> + /* New address space */
> + if (!(clone_flags & CLONE_VM)) {
> + p->numa_preferred_nid = -1;
> + return;
> + }
> +
> + /* New thread, use existing preferred nid but stagger scans */
> + if (p->mm) {
> + unsigned int delay;
> +
> + delay = min_t(unsigned int, task_scan_max(current),
> + current->numa_scan_period * mm_users * NSEC_PER_MSEC);
> + delay += 2 * TICK_NSEC;
> + p->numa_preferred_nid = current->numa_preferred_nid;
> + p->node_stamp = delay;
> + }

So this is a fork time function, shouldn't p->numa_preferred_nid be equal to 
current->numa_preferred_nid already?

This is what happens in the !p->mm && CLONE_VM case anyway, right?

So we could leave out the superfluous assignment and make it clear in a comment 
that we inherit the parent's ->numa_preferred_nid intentionally.

Also, there's a lot of p->mm use, could we add this helper local variable

Re: [PATCH v3] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

[Christian Borntraeger]

On 04/27/2018 02:55 AM, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Our virtual machines make use of device assignment by configuring
> 12 NVMe disks for high I/O performance. Each NVMe device has 129 
> MSI-X Table entries:
> Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 
> offset=2000
> The windows virtual machines fail to boot since they will map the number of 
> MSI-table entries that the NVMe hardware reported to the bus to msi routing 
> table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 4096
> for all archs, in the future this might be extended again if needed.
> 
> Reviewed-by: Cornelia Huck 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Cornelia Huck 
> Cc: Christian Borntraeger 
> Signed-off-by: Wanpeng Li 
> Signed-off-by: Tonny Lu 

Acked-by: Christian Borntraeger 

> ---
> v2 -> v3:
>  * update comments in the code
> v1 -> v2:
>  * extend MAX_IRQ_ROUTES to 4096 for all archs 
> 
>  include/linux/kvm_host.h | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 6930c63..6d6e79c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1045,13 +1045,7 @@ static inline int mmu_notifier_retry(struct kvm *kvm, 
> unsigned long mmu_seq)
>  
>  #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
>  
> -#ifdef CONFIG_S390
> -#define KVM_MAX_IRQ_ROUTES 4096 //FIXME: we can have more than that...
> -#elif defined(CONFIG_ARM64)
> -#define KVM_MAX_IRQ_ROUTES 4096
> -#else
> -#define KVM_MAX_IRQ_ROUTES 1024
> -#endif
> +#define KVM_MAX_IRQ_ROUTES 4096 /* might need extension/rework in the future 
> */
>  
>  bool kvm_arch_can_set_irq_routing(struct kvm *kvm);
>  int kvm_set_irq_routing(struct kvm *kvm,
> 

[PATCH v3 6/7] kprobes/arm: Fix %p uses in error messages

[Masami Hiramatsu]

Fix %p uses in error messages by removing it and
using general dumper.

Signed-off-by: Masami Hiramatsu 
---
 arch/arm/probes/kprobes/core.c  |   10 +-
 arch/arm/probes/kprobes/test-core.c |1 -
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index e90cc8a08186..e90165a56620 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -289,8 +289,8 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
break;
case KPROBE_REENTER:
/* A nested probe was hit in FIQ, it is a BUG */
-   pr_warn("Unrecoverable kprobe detected at 
%p.\n",
-   p->addr);
+   pr_warn("Unrecoverable kprobe detected.\n");
+   dump_kprobe(p);
/* fall through */
default:
/* impossible cases */
@@ -615,11 +615,11 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
if (orig_sp != stack_addr) {
struct pt_regs *saved_regs =
(struct pt_regs *)kcb->jprobe_saved_regs.ARM_sp;
-   printk("current sp %lx does not match saved sp %lx\n",
+   pr_err("current sp %lx does not match saved sp %lx\n",
   orig_sp, stack_addr);
-   printk("Saved registers for jprobe %p\n", jp);
+   pr_err("Saved registers for jprobe\n");
show_regs(saved_regs);
-   printk("Current registers\n");
+   pr_err("Current registers\n");
show_regs(regs);
BUG();
}
diff --git a/arch/arm/probes/kprobes/test-core.c 
b/arch/arm/probes/kprobes/test-core.c
index 9ed0129bed3c..b5c892e24244 100644
--- a/arch/arm/probes/kprobes/test-core.c
+++ b/arch/arm/probes/kprobes/test-core.c
@@ -1460,7 +1460,6 @@ static bool check_test_results(void)
print_registers(&result_regs);
 
if (mem) {
-   pr_err("current_stack=%p\n", current_stack);
pr_err("expected_memory:\n");
print_memory(expected_memory, mem_size);
pr_err("result_memory:\n");

[PATCH v3 7/7] kprobes/arm64: Fix %p uses in error messages

[Masami Hiramatsu]

Fix %p uses in error messages by removing it because
those are redundant or meaningless.

Signed-off-by: Masami Hiramatsu 
Acked-by: Will Deacon 
---
 arch/arm64/kernel/probes/kprobes.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/probes/kprobes.c 
b/arch/arm64/kernel/probes/kprobes.c
index d849d9804011..34f78d07a068 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -275,7 +275,7 @@ static int __kprobes reenter_kprobe(struct kprobe *p,
break;
case KPROBE_HIT_SS:
case KPROBE_REENTER:
-   pr_warn("Unrecoverable kprobe detected at %p.\n", p->addr);
+   pr_warn("Unrecoverable kprobe detected.\n");
dump_kprobe(p);
BUG();
break;
@@ -521,7 +521,7 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
(struct pt_regs *)kcb->jprobe_saved_regs.sp;
pr_err("current sp %lx does not match saved sp %lx\n",
   orig_sp, stack_addr);
-   pr_err("Saved registers for jprobe %p\n", jp);
+   pr_err("Saved registers for jprobe\n");
__show_regs(saved_regs);
pr_err("Current registers\n");
__show_regs(regs);

[PATCH v3 5/7] kprobes/x86: Fix %p uses in error messages

[Masami Hiramatsu]

Fix %p uses in error messages in kprobes/x86.
- Some %p uses are not needed. Just remove it (or remove message).
- One %p use seems important to show some address
  so replaced with %pS.

Signed-off-by: Masami Hiramatsu 
---
 Changes in v3:
  - Do not use %px.
---
 arch/x86/kernel/kprobes/core.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 0715f827607c..d2c9d5c8e4ce 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -391,8 +391,6 @@ int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct 
insn *insn)
  - (u8 *) real;
if ((s64) (s32) newdisp != newdisp) {
pr_err("Kprobes error: new displacement does not fit 
into s32 (%llx)\n", newdisp);
-   pr_err("\tSrc: %p, Dest: %p, old disp: %x\n",
-   src, real, insn->displacement.value);
return 0;
}
disp = (u8 *) dest + insn_offset_displacement(insn);
@@ -636,8 +634,7 @@ static int reenter_kprobe(struct kprobe *p, struct pt_regs 
*regs,
 * Raise a BUG or we'll continue in an endless reentering loop
 * and eventually a stack overflow.
 */
-   printk(KERN_WARNING "Unrecoverable kprobe detected at %p.\n",
-  p->addr);
+   pr_err("Unrecoverable kprobe detected.\n");
dump_kprobe(p);
BUG();
default:
@@ -1146,12 +1143,11 @@ int longjmp_break_handler(struct kprobe *p, struct 
pt_regs *regs)
(addr < (u8 *) jprobe_return_end)) {
if (stack_addr(regs) != saved_sp) {
struct pt_regs *saved_regs = &kcb->jprobe_saved_regs;
-   printk(KERN_ERR
-  "current sp %p does not match saved sp %p\n",
+   pr_err("current sp %pS does not match saved sp %pS\n",
   stack_addr(regs), saved_sp);
-   printk(KERN_ERR "Saved registers for jprobe %p\n", jp);
+   pr_err("Saved registers for jprobe\n");
show_regs(saved_regs);
-   printk(KERN_ERR "Current registers\n");
+   pr_err("Current registers\n");
show_regs(regs);
BUG();
}

[PATCH v3 4/7] kprobes: Replace %p with other pointer types

[Masami Hiramatsu]

Replace %p with %pS or just remove it if unneeded.

Signed-off-by: Masami Hiramatsu 
---
 Changes in v3:
  - Do not use %px in any case.
 Changes in v2:
  - Rebased on linux-next
---
 kernel/kprobes.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 94af7c99cf81..a72ff4999b11 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -712,7 +712,7 @@ static void reuse_unused_kprobe(struct kprobe *ap)
op = container_of(ap, struct optimized_kprobe, kp);
if (unlikely(list_empty(&op->list)))
printk(KERN_WARNING "Warning: found a stray unused "
-   "aggrprobe@%p\n", ap->addr);
+   "aggrprobe@%pS\n", ap->addr);
/* Enable the probe again */
ap->flags &= ~KPROBE_FLAG_DISABLED;
/* Optimize it again (remove from op->list) */
@@ -985,7 +985,8 @@ static int arm_kprobe_ftrace(struct kprobe *p)
ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
   (unsigned long)p->addr, 0, 0);
if (ret) {
-   pr_debug("Failed to arm kprobe-ftrace at %p (%d)\n", p->addr, 
ret);
+   pr_debug("Failed to arm kprobe-ftrace at %pS (%d)\n",
+p->addr, ret);
return ret;
}
 
@@ -1025,7 +1026,8 @@ static int disarm_kprobe_ftrace(struct kprobe *p)
 
ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
   (unsigned long)p->addr, 1, 0);
-   WARN(ret < 0, "Failed to disarm kprobe-ftrace at %p (%d)\n", p->addr, 
ret);
+   WARN(ret < 0, "Failed to disarm kprobe-ftrace at %pS (%d)\n",
+p->addr, ret);
return ret;
 }
 #else  /* !CONFIG_KPROBES_ON_FTRACE */
@@ -2169,11 +2171,12 @@ int enable_kprobe(struct kprobe *kp)
 }
 EXPORT_SYMBOL_GPL(enable_kprobe);
 
+/* Caller must NOT call this in usual path. This is only for critical case */
 void dump_kprobe(struct kprobe *kp)
 {
-   printk(KERN_WARNING "Dumping kprobe:\n");
-   printk(KERN_WARNING "Name: %s\nAddress: %p\nOffset: %x\n",
-  kp->symbol_name, kp->addr, kp->offset);
+   pr_err("Dumping kprobe:\n");
+   pr_err("Name: %s\nOffset: %x\nAddress: %pS\n",
+  kp->symbol_name, kp->offset, kp->addr);
 }
 NOKPROBE_SYMBOL(dump_kprobe);
 
@@ -2196,11 +2199,8 @@ static int __init populate_kprobe_blacklist(unsigned 
long *start,
entry = arch_deref_entry_point((void *)*iter);
 
if (!kernel_text_address(entry) ||
-   !kallsyms_lookup_size_offset(entry, &size, &offset)) {
-   pr_err("Failed to find blacklist at %p\n",
-   (void *)entry);
+   !kallsyms_lookup_size_offset(entry, &size, &offset))
continue;
-   }
 
ent = kmalloc(sizeof(*ent), GFP_KERNEL);
if (!ent)

[PATCH v3 3/7] kprobes: Show address of kprobes if kallsyms does

[Masami Hiramatsu]

Show probed address in debugfs kprobe list file as same
as kallsyms does. This information is used for checking
kprobes are placed in the expected address. So it should
be able to compared with address in kallsyms.

Signed-off-by: Masami Hiramatsu 
---
 kernel/kprobes.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e7d7e3e8598a..94af7c99cf81 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2326,6 +2326,7 @@ static void report_probe(struct seq_file *pi, struct 
kprobe *p,
const char *sym, int offset, char *modname, struct kprobe *pp)
 {
char *kprobe_type;
+   void *addr = p->addr;
 
if (p->pre_handler == pre_handler_kretprobe)
kprobe_type = "r";
@@ -2334,13 +2335,16 @@ static void report_probe(struct seq_file *pi, struct 
kprobe *p,
else
kprobe_type = "k";
 
+   if (!kallsyms_show_value())
+   addr = NULL;
+
if (sym)
-   seq_printf(pi, "%p  %s  %s+0x%x  %s ",
-   p->addr, kprobe_type, sym, offset,
+   seq_printf(pi, "%px  %s  %s+0x%x  %s ",
+   addr, kprobe_type, sym, offset,
(modname ? modname : " "));
-   else
-   seq_printf(pi, "%p  %s  %p ",
-   p->addr, kprobe_type, p->addr);
+   else/* try to use %pS */
+   seq_printf(pi, "%px  %s  %pS ",
+   addr, kprobe_type, p->addr);
 
if (!pp)
pp = p;

[PATCH v3 2/7] kprobes: Show blacklist addresses as same as kallsyms does

[Masami Hiramatsu]

Show kprobes blacklist addresses under same condition of
showing kallsyms addresses.

Since there are several name conflict for local symbols,
kprobe blacklist needs to show each addresses so that
user can identify where is on blacklist by comparing
with kallsyms.

Signed-off-by: Masami Hiramatsu 
---
 Changes in v3:
  - Updated based on the latest linus tree.
---
 kernel/kprobes.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 51096eece801..e7d7e3e8598a 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2427,9 +2427,17 @@ static int kprobe_blacklist_seq_show(struct seq_file *m, 
void *v)
 {
struct kprobe_blacklist_entry *ent =
list_entry(v, struct kprobe_blacklist_entry, list);
+   void *start = (void *)ent->start_addr, *end = (void *)ent->end_addr;
 
-   seq_printf(m, "0x%px-0x%px\t%ps\n", (void *)ent->start_addr,
-  (void *)ent->end_addr, (void *)ent->start_addr);
+   /*
+* As long as kallsyms shows the address, kprobes blacklist also
+* show it, Or, it shows null address and symbol.
+*/
+   if (!kallsyms_show_value())
+   start = end = NULL;
+
+   seq_printf(m, "0x%px-0x%px\t%ps\n", start, end,
+  (void *)ent->start_addr);
return 0;
 }
 

[PATCH v3 1/7] kprobes: Make blacklist root user read only

[Masami Hiramatsu]

Since the blacklist file indicates a sensitive address
information to reader, it should be restricted to the
root user.

Suggested-by: Thomas Richter 
Signed-off-by: Masami Hiramatsu 
---
 kernel/kprobes.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index ea619021d901..51096eece801 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2621,7 +2621,7 @@ static int __init debugfs_kprobe_init(void)
if (!file)
goto error;
 
-   file = debugfs_create_file("blacklist", 0444, dir, NULL,
+   file = debugfs_create_file("blacklist", 0400, dir, NULL,
&debugfs_kprobe_blacklist_ops);
if (!file)
goto error;

[PATCH v3 0/7] kprobes: Fix %p in kprobes

[Masami Hiramatsu]

Hi,

This 3rd version of the series which fixes %p uses in kprobes.
Some by replacing with %pS, some by replacing with %px but
masking with kallsyms_show_value().

I've read the thread about %pK and if I understand correctly
we shouldn't print kernel addresses. However, kprobes debugfs
interface can not stop to show the actual probe address because
it should be compared with addresses in kallsyms for debugging.
So, it depends on that kallsyms_show_value() allows to show
address to user, because if it returns true, anyway that user
can dump /proc/kallsyms.
Other error messages are replaced it with %pS or just removed.

This series also including some fixes for arch ports too.

Changes in this version;
 - [2/7]: Updated for the latest linus tree.
 - [4/7][5/7]: Do not use %px.

Thank you,

---

Masami Hiramatsu (7):
  kprobes: Make blacklist root user read only
  kprobes: Show blacklist addresses as same as kallsyms does
  kprobes: Show address of kprobes if kallsyms does
  kprobes: Replace %p with other pointer types
  kprobes/x86: Fix %p uses in error messages
  kprobes/arm: Fix %p uses in error messages
  kprobes/arm64: Fix %p uses in error messages


 arch/arm/probes/kprobes/core.c  |   10 ---
 arch/arm/probes/kprobes/test-core.c |1 -
 arch/arm64/kernel/probes/kprobes.c  |4 +--
 arch/x86/kernel/kprobes/core.c  |   12 +++--
 kernel/kprobes.c|   48 ++-
 5 files changed, 41 insertions(+), 34 deletions(-)

--
Masami Hiramatsu (Linaro) 

RE: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments

[KY Srinivasan]

> -Original Message-
> From: Dan Carpenter 
> Sent: Thursday, April 26, 2018 2:32 PM
> To: KY Srinivasan 
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> h...@zytor.com; Stephen Hemminger ; Michael
> Kelley (EOSG) ; vkuzn...@redhat.com
> Subject: Re: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments
> 
> On Wed, Apr 25, 2018 at 11:12:47AM -0700, k...@linuxonhyperv.com wrote:
> > +/*
> > + * IPI implementation on Hyper-V.
> > + */
> > +
> > +static int __send_ipi_mask(const struct cpumask *mask, int vector)
> > +{
> > +   int cur_cpu, vcpu;
> > +   struct ipi_arg_non_ex **arg;
> > +   struct ipi_arg_non_ex *ipi_arg;
> > +   int ret = 1;
> 
> Not specifically related to this patch, but hv code sometimes returns 1
> on error or U64_MAX.  It's slightly magical.  Maybe
> HV_STATUS_INVALID_HYPERCALL_INPUT (3) would be more appropriate?
> Or we
> could make a new more generic error code:
> 
> #define HV_STATUS_INVALID1

Good point. We will look at cleaning this up.

Regards,

K. Y

RE: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments

[KY Srinivasan]

> -Original Message-
> From: Michael Kelley (EOSG)
> Sent: Thursday, April 26, 2018 3:55 PM
> To: KY Srinivasan ; x...@kernel.org;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; t...@linutronix.de; h...@zytor.com; Stephen
> Hemminger ; vkuzn...@redhat.com
> Subject: RE: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments
> 
> > -Original Message-
> > From: k...@linuxonhyperv.com 
> > Sent: Wednesday, April 25, 2018 11:13 AM
> > To: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org;
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com;
> > t...@linutronix.de; h...@zytor.com; Stephen Hemminger
> ;
> > Michael Kelley (EOSG) ;
> vkuzn...@redhat.com
> > Cc: KY Srinivasan 
> > Subject: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments
> >
> > From: "K. Y. Srinivasan" 
> >
> > Hyper-V supports hypercalls to implement IPI; use them.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  arch/x86/hyperv/hv_apic.c  | 125
> +
> >  arch/x86/hyperv/hv_init.c  |  17 +
> >  arch/x86/include/asm/hyperv-tlfs.h |   9 +++
> >  arch/x86/include/asm/mshyperv.h|   1 +
> >  4 files changed, 152 insertions(+)
> >
> > diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
> > index e0a5b36208fc..7f3322ecfb01 100644
> > --- a/arch/x86/hyperv/hv_apic.c
> > +++ b/arch/x86/hyperv/hv_apic.c
> > @@ -30,6 +30,14 @@
> >  #include 
> >  #include 
> >
> > +struct ipi_arg_non_ex {
> > +   u32 vector;
> > +   u32 reserved;
> > +   u64 cpu_mask;
> > +};
> 
> I think we'd like to put structures like this, which are defined in the
> Hyper-V Top Level Functional Spec, in hyperv-tlfs.h.  Also, the 5.0b
> version of the TLFS, which is latest, shows this structure on page 100:
> 
>   u32 vector;
>   u8  targetvtl;
>   u8  reserved[3];
>   u64 cpu_mask;
> 

Good point. I will make the necessary adjustments.

Regards,

K. Y

RE: [PATCH 5/5] X86: Hyper-V: Consolidate the allocation of the hypercall input page

[KY Srinivasan]

> -Original Message-
> From: Thomas Gleixner 
> Sent: Thursday, April 26, 2018 3:24 PM
> To: KY Srinivasan 
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; h...@zytor.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuzn...@redhat.com
> Subject: Re: [PATCH 5/5] X86: Hyper-V: Consolidate the allocation of the
> hypercall input page
> 
> On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> 
> > From: "K. Y. Srinivasan" 
> >
> > Consolidate the allocation of the hypercall input page.
> 
> Again. You can provide the new way of allocation first, then you don't have
> to add code first in order to remove it later again. 

I have implemented the new way upfront for the new code - the IPI code
[PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments.
What I am doing here using that infrastructure for the TLB flush enlightenments
and getting rid of unnecessary code.

Regards,

K. Y

Re: [PATCH] Revert "x86/mm: implement free pmd/pte page interfaces"

[Ingo Molnar]

* Kani, Toshi  wrote:

> On Thu, 2018-04-26 at 17:14 +0200, Joerg Roedel wrote:
> > From: Joerg Roedel 
> > 
> > This reverts commit 28ee90fe6048fa7b7ceaeb8831c0e4e454a4cf89.
> > 
> > This commit is broken for x86, as it unmaps the PTE and PMD
> > pages and immediatly frees them without doing a TLB flush.
> > 
> > Further this lacks synchronization with other page-tables in
> > the system when the PMD pages are not shared between
> > mm_structs.
> > 
> > On x86-32 with PAE and PTI patches on-top this patch
> > triggers the BUG_ON in vmalloc_sync_one() because the kernel
> > and the process page-table were not synchronized.
> > 
> > Signed-off-by: Joerg Roedel 
> 
> I do not agree with the comments and this revert.  Let's discuss further
> on the original thread.

The original patch is totally broken (it's based on a misunderstanding), so 
unless 
you have a fix the revert is justified.

Thanks,

Ingo

Re: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments

[kbuild test robot]

Hi Srinivasan,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.17-rc2]
[also build test ERROR on next-20180426]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-linuxonhyperv-com/X86-Hyper-V-APIC-enlightenments/20180427-114416
config: i386-randconfig-b0-04270034 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86//hyperv/hv_apic.c: In function 'hv_apic_read':
   arch/x86//hyperv/hv_apic.c:73:3: error: implicit declaration of function 
'native_apic_mem_read' [-Werror=implicit-function-declaration]
  return native_apic_mem_read(reg);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_apic_write':
   arch/x86//hyperv/hv_apic.c:87:3: error: implicit declaration of function 
'native_apic_mem_write' [-Werror=implicit-function-declaration]
  native_apic_mem_write(reg, val);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_send_ipi':
>> arch/x86//hyperv/hv_apic.c:155:3: error: invalid use of undefined type 
>> 'struct apic'
  orig_apic.send_IPI(cpu, vector);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_send_ipi_mask':
   arch/x86//hyperv/hv_apic.c:161:3: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_mask(mask, vector);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_send_ipi_mask_allbutself':
   arch/x86//hyperv/hv_apic.c:174:3: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_mask_allbutself(mask, vector);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_send_ipi_all':
   arch/x86//hyperv/hv_apic.c:185:3: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_all(vector);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_send_ipi_self':
   arch/x86//hyperv/hv_apic.c:191:3: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_self(vector);
  ^
   arch/x86//hyperv/hv_apic.c: In function 'hv_apic_init':
   arch/x86//hyperv/hv_apic.c:204:16: error: 'apic' undeclared (first use in 
this function)
  orig_apic = *apic;
   ^
   arch/x86//hyperv/hv_apic.c:204:16: note: each undeclared identifier is 
reported only once for each function it appears in
>> arch/x86//hyperv/hv_apic.c:204:3: error: 'orig_apic' has an incomplete type
  orig_apic = *apic;
  ^
   arch/x86//hyperv/hv_apic.c:217:3: error: implicit declaration of function 
'apic_set_eoi_write' [-Werror=implicit-function-declaration]
  apic_set_eoi_write(hv_apic_eoi_write);
  ^
   cc1: some warnings being treated as errors

vim +/orig_apic +204 arch/x86//hyperv/hv_apic.c

59  
60  static u32 hv_apic_read(u32 reg)
61  {
62  u32 reg_val, hi;
63  
64  switch (reg) {
65  case APIC_EOI:
66  rdmsr(HV_X64_MSR_EOI, reg_val, hi);
67  return reg_val;
68  case APIC_TASKPRI:
69  rdmsr(HV_X64_MSR_TPR, reg_val, hi);
70  return reg_val;
71  
72  default:
  > 73  return native_apic_mem_read(reg);
74  }
75  }
76  
77  static void hv_apic_write(u32 reg, u32 val)
78  {
79  switch (reg) {
80  case APIC_EOI:
81  wrmsr(HV_X64_MSR_EOI, val, 0);
82  break;
83  case APIC_TASKPRI:
84  wrmsr(HV_X64_MSR_TPR, val, 0);
85  break;
86  default:
87  native_apic_mem_write(reg, val);
88  }
89  }
90  
91  static void hv_apic_eoi_write(u32 reg, u32 val)
92  {
93  wrmsr(HV_X64_MSR_EOI, val, 0);
94  }
95  
96  /*
97   * IPI implementation on Hyper-V.
98   */
99  
   100  static int __send_ipi_mask(const struct cpumask *mask, int vector)
   101  {
   102  int cur_cpu, vcpu;
   103  struct ipi_arg_non_ex **arg;
   104  struct ipi_arg_non_ex *ipi_arg;
   105  int ret = 1;
   106  unsigned long flags;
   107  
   108  if (cpumask_empty(mask))
   109  return 0;
   110  
   111  if (!hv_hypercall_pg)
   112  return ret;
   113  
   114  if ((vector < HV_IPI_LOW_VECTOR) || (vector > 
HV_IPI_HIGH_VECTOR))
   115  return ret;
   116  
   117  local_irq_save(flags);
   118  arg = (struct ipi_arg_non_ex 
**)this_cpu_ptr(hyperv_pcpu_input_arg);
   119  
   120  

RE: [PATCH 3/5] X86: Hyper-V: Enhanced IPI enlightenment

[KY Srinivasan]

> -Original Message-
> From: Thomas Gleixner 
> Sent: Thursday, April 26, 2018 3:17 PM
> To: KY Srinivasan 
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; h...@zytor.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuzn...@redhat.com
> Subject: Re: [PATCH 3/5] X86: Hyper-V: Enhanced IPI enlightenment
> 
> On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> >
> > +struct ipi_arg_ex {
> > +   u32 vector;
> > +   u32  reserved;
> > +   struct hv_vpset vp_set;
> 
> Please align that in tabular fashion for easy of reading
> 
>   u32 vector;
>   u32 reserved;
>   struct hv_vpset vp_set;
> 
> > +};
> > +
> >  static struct apic orig_apic;
> >
> >  static u64 hv_apic_icr_read(void)
> > @@ -97,6 +103,40 @@ static void hv_apic_eoi_write(u32 reg, u32 val)
> >   * IPI implementation on Hyper-V.
> >   */
> >
> > +static int __send_ipi_mask_ex(const struct cpumask *mask, int vector)
> > +{
> > +   int nr_bank = 0;
> > +   struct ipi_arg_ex **arg;
> > +   struct ipi_arg_ex *ipi_arg;
> > +   int ret = 1;
> > +   unsigned long flags;
> 
> This is really horrible to read.
> 
>   struct ipi_arg_ex *ipi_arg;
>   struct ipi_arg_ex **arg;
>   unsigned long flags;
>   bool ret = false;
>   int nr_bank = 0;
> 
> is really more conveniant for quick reading.
> 
> So the other more limited function has a lot more sanity checks vs. vector
> number and other things. Why are they not required here? Comment
> please.

Yes, I will add the comments. This function is called from the other function
after all the sanity checks have been done and hence are not replicated here.
> 
> > +   local_irq_save(flags);
> > +   arg = (struct ipi_arg_ex **)this_cpu_ptr(hyperv_pcpu_input_arg);
> > +
> > +   ipi_arg = *arg;
> > +   if (unlikely(!ipi_arg))
> > +   goto ipi_mask_ex_done;
> > +
> > +   ipi_arg->vector = vector;
> > +   ipi_arg->reserved = 0;
> > +   ipi_arg->vp_set.valid_bank_mask = 0;
> > +
> > +   if (!cpumask_equal(mask, cpu_present_mask)) {
> > +   ipi_arg->vp_set.format = HV_GENERIC_SET_SPARCE_4K;
> > +   nr_bank = cpumask_to_vpset(&(ipi_arg->vp_set), mask);
> 
> nr_bank really confused me. bank_nr is what you mean, not number of
> banks,
> right?
It is the number of banks. The hypercall used here is a variable length
hypercall.

Regards,

K. Y  

Re: [PATCH v2 3/5] dmaengine: sprd: Move DMA request mode and interrupt type into head file

[Vinod Koul]

On Thu, Apr 19, 2018 at 10:00:48AM +0800, Baolin Wang wrote:
> From: Eric Long 
> 
> This patch will move the Spreadtrum DMA request mode and interrupt type
> into one head file for user to configure.

Applied this one, thanks
-- 
~Vinod

Re: [PATCH v2 2/5] dmaengine: sprd: Define the DMA data width type

[Vinod Koul]

On Thu, Apr 19, 2018 at 10:00:47AM +0800, Baolin Wang wrote:
> Define the DMA data width type to make code more readable.

Applied this one, thanks
-- 
~Vinod

Re: [PATCH v2 1/5] dmaengine: sprd: Define the DMA transfer step type

[Vinod Koul]

On Thu, Apr 19, 2018 at 10:00:46AM +0800, Baolin Wang wrote:
> From: Eric Long 
> 
> Define the DMA transfer step type to make code more readable.

Applied this one, thanks

-- 
~Vinod

Re: [PATCH v2 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration

[Vinod Koul]

On Thu, Apr 19, 2018 at 10:00:49AM +0800, Baolin Wang wrote:

> +/*
> + * struct sprd_dma_config - DMA configuration structure
> + * @src_addr: the physical address where DMA slave data should be read
> + * @dst_addr: the physical address where DMA slave data should be written
> + * @fragment_len: specify one fragment transfer length
> + * @block_len: specify one block transfer length
> + * @transcation_len: specify one transcation transfer length
> + * @src_step: source transfer step
> + * @dst_step: destination transfer step
> + * @src_datawidth: source transfer data width
> + * @dst_datawidth: destination transfer data width
> + * @wrap_ptr: wrap pointer address, once the transfer address reaches the
> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to' address.
> + * @wrap_to: wrap jump to address
> + * @req_mode: specify the DMA request mode
> + * @int_mode: specify the DMA interrupt type
> + * @slave_id: slave channel requester id
> + */
> +struct sprd_dma_config {

can you please not duplicate the dma_slave_config here. If you want to save
your own values then please embed dma_slave_config here
-- 
~Vinod

Re: [RFC v3 0/5] virtio: support packed ring

[Jason Wang]

On 2018年04月27日 12:18, Michael S. Tsirkin wrote:

On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote:

On 2018年04月25日 13:15, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support in virtio driver.

Some simple functional tests have been done with Jason's
packed ring implementation in vhost:

https://lkml.org/lkml/2018/4/23/12

Both of ping and netperf worked as expected (with EVENT_IDX
disabled). But there are below known issues:

1. Reloading the guest driver will break the Tx/Rx;

Will have a look at this issue.


2. Zeroing the flags when detaching a used desc will
 break the guest -> host path.

I still think zeroing flags is unnecessary or even a bug. At host, I track
last observed avail wrap counter and detect avail like (what is suggested in
the example code in the spec):

static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
{
    bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);

    return avail == vq->avail_wrap_counter;
}

So zeroing wrap can not work with this obviously.

Thanks

I agree. I think what one should do is flip the available bit.



But is this flipping a must?

Thanks

[PATCH/RFC] mtd: spi-nor: honour max_message_size for spi-nor writes.

[NeilBrown]

Hi,
 I've labeled this an RFC because I'm really not sure about removing the
 error path from spi_nor_write() -- maybe that really matters.  But on
 my hardware, performing multiple small spi writes to the flash seems
 to work.

 The spi driver is drivers/staging/mt7621-spi.  Possibly this needs to
 use DMA instead of a FIFO (assuming the hardware can) - or maybe
 drivers/spi/spi-mt65xx.c can be made to work on this hardware, though
 that is for an ARM SOC and mt7621 is a MIPS SOC.

 I note that openwrt has similar patches:
  
target/linux/generic/pending-4.14/450-mtd-spi-nor-allow-NOR-driver-to-write-fewer-bytes-th.patch

 They also change the spi driver to do a short write, rather
 than change m25p80 to request a short write.

 Is there something horribly wrong with this?

Thanks,
NeilBrown

---8<

m25p80 honours max_message_size and max_transfer_size
for reads, but not for writes.
I have a driver that has a max message size of 36 bytes
(command, address, 32 bytes data, all places in a FIFO
in the controller).
This requires m25p80_write() to honour the size limits.
For that to work, spi-nor needs to quietly accept partial
writes.

With this, I can successfully re-flash my device.

Signed-off-by: NeilBrown 
---
 drivers/mtd/devices/m25p80.c  | 3 ++-
 drivers/mtd/spi-nor/spi-nor.c | 7 ---
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index a4e18f6aaa33..7ded13507604 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -117,7 +117,8 @@ static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, 
size_t len,
 
t[data_idx].tx_buf = buf;
t[data_idx].tx_nbits = data_nbits;
-   t[data_idx].len = len;
+   t[data_idx].len = min3(len, spi_max_transfer_size(spi),
+  spi_max_message_size(spi) - cmd_sz);
spi_message_add_tail(&t[data_idx], &m);
 
ret = spi_sync(spi, &m);
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 42ae9a1529bb..cfa15f2801ad 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1445,13 +1445,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t 
to, size_t len,
goto write_err;
*retlen += written;
i += written;
-   if (written != page_remain) {
-   dev_err(nor->dev,
-   "While writing %zu bytes written %zd bytes\n",
-   page_remain, written);
-   ret = -EIO;
-   goto write_err;
-   }
}
 
 write_err:
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

RE: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments

[KY Srinivasan]

> -Original Message-
> From: Thomas Gleixner 
> Sent: Thursday, April 26, 2018 3:09 PM
> To: KY Srinivasan 
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; h...@zytor.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuzn...@redhat.com
> Subject: Re: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments
> 
> On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> > +static int __send_ipi_mask(const struct cpumask *mask, int vector)
> > +{
> > +   int cur_cpu, vcpu;
> > +   struct ipi_arg_non_ex **arg;
> > +   struct ipi_arg_non_ex *ipi_arg;
> > +   int ret = 1;
> 
> So this indicates whether __send_ipi_mask() can send to @mask or not. So
> please make it a bool and let it return false when it does not work, true
> otherwise. If you had used -E then it would have been more obvious,
> but
> this is really a boolean decision.

Agreed.
> 
> > +   unsigned long flags;
> > +
> > +   if (cpumask_empty(mask))
> > +   return 0;
> > +
> > +   if (!hv_hypercall_pg)
> > +   return ret;
> > +
> > +   if ((vector < HV_IPI_LOW_VECTOR) || (vector >
> HV_IPI_HIGH_VECTOR))
> > +   return ret;
> > +
> > +   local_irq_save(flags);
> > +   arg = (struct ipi_arg_non_ex
> **)this_cpu_ptr(hyperv_pcpu_input_arg);
> > +
> > +   ipi_arg = *arg;
> > +   if (unlikely(!ipi_arg))
> > +   goto ipi_mask_done;
> > +
> > +
> 
> Stray newline
> 
> > +   ipi_arg->vector = vector;
> > +   ipi_arg->reserved = 0;
> > +   ipi_arg->cpu_mask = 0;
> > +
> > +   for_each_cpu(cur_cpu, mask) {
> > +   vcpu = hv_cpu_number_to_vp_number(cur_cpu);
> > +   if (vcpu >= 64)
> > +   goto ipi_mask_done;
> 
> This is completely magic and deserves a comment.
> 
> > +
> > +   __set_bit(vcpu, (unsigned long *)&ipi_arg->cpu_mask);
> > +   }
> > +
> > +   ret = hv_do_hypercall(HVCALL_SEND_IPI, ipi_arg, NULL);
> > +
> > +ipi_mask_done:
> > +   local_irq_restore(flags);
> > +   return ret;
> > +}
> 
> 
> 
> >  static int hv_cpu_init(unsigned int cpu)
> >  {
> > u64 msr_vp_index;
> > struct hv_vp_assist_page **hvp =
> &hv_vp_assist_page[smp_processor_id()];
> > +   void **input_arg;
> > +
> > +   input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
> > +   *input_arg = page_address(alloc_page(GFP_ATOMIC));
> 
> This is called from the cpu hotplug thread and there is no need for an
> atomic allocation. Please use GFP_KERNEL.
> 
> > hv_get_vp_index(msr_vp_index);
> >
> > @@ -217,6 +224,10 @@ static int hv_cpu_die(unsigned int cpu)
> >  {
> > struct hv_reenlightenment_control re_ctrl;
> > unsigned int new_cpu;
> > +   void **input_arg;
> > +
> > +   input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
> > +   free_page((unsigned long)*input_arg);
> 
> Hrm. Again this is called from the CPU hotplug thread when the cou is about
> to go down. But you can be scheduled out after free() and before disabling
> the assist thing below and the pointer persist. There is no guarantee that
> nothing sends an IPI anymore after this point.
> 
> So you have two options here:
> 
>   1) Disable interrupts, get the pointer, set the per cpu pointer to NULL,
>  reenable interruots and free the page
I will implement this approach.
> 
>   2) Keep the page around and check for it in the CPU UP path and avoid the
>  allocation when the CPU comes online again.
> 
> > if (hv_vp_assist_page && hv_vp_assist_page[cpu])
> > wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, 0);
> > @@ -260,6 +271,12 @@ void __init hyperv_init(void)
> > if ((ms_hyperv.features & required_msrs) != required_msrs)
> > return;
> >
> > +   /* Allocate the per-CPU state for the hypercall input arg */
> > +   hyperv_pcpu_input_arg = alloc_percpu(void  *);
> > +
> > +   if (hyperv_pcpu_input_arg == NULL)
> > +   return;
> 
> Huch. When that allocation fails, you return and ignore the rest of the
> function which has been there before. Weird decision.
I should have explained this. Failure of this allocation means that we would 
not have the
per-cpu hypercall input page which in turn would mean that we would not be able 
to invoke
any hypercalls. 

Regards,

K. Y

[PATCH] arm64: dts: msm8996: fix gic_irq_domain_translate warnings

[Thierry Escande]

Remove the usage of IRQ_TYPE_NONE to fix loud warnings from
patch (83a86fbb5b56b "irqchip/gic: Loudly complain about
the use of IRQ_TYPE_NONE").

Signed-off-by: Thierry Escande 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 410ae787ebb4..1aaf1fa2604e 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -437,7 +437,7 @@
blsp2_i2c0: i2c@75b5000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0x075b5000 0x1000>;
-   interrupts = ;
+   interrupts = ;
clocks = <&gcc GCC_BLSP2_AHB_CLK>,
<&gcc GCC_BLSP2_QUP1_I2C_APPS_CLK>;
clock-names = "iface", "core";
@@ -468,7 +468,7 @@
blsp2_i2c1: i2c@75b6000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0x075b6000 0x1000>;
-   interrupts = ;
+   interrupts = ;
clocks = <&gcc GCC_BLSP2_AHB_CLK>,
<&gcc GCC_BLSP2_QUP2_I2C_APPS_CLK>;
clock-names = "iface", "core";
@@ -493,7 +493,7 @@
blsp1_i2c2: i2c@7577000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0x07577000 0x1000>;
-   interrupts = ;
+   interrupts = ;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
<&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
clock-names = "iface", "core";
@@ -526,7 +526,8 @@
 reg = <0x74a4900 0x314>, <0x74a4000 0x800>;
 reg-names = "hc_mem", "core_mem";
 
-interrupts = <0 125 0>, <0 221 0>;
+interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH>,
+ <0 221 IRQ_TYPE_LEVEL_HIGH>;
 interrupt-names = "hc_irq", "pwr_irq";
 
 clock-names = "iface", "core", "xo";
@@ -809,7 +810,7 @@
dwc3@760 {
compatible = "snps,dwc3";
reg = <0x760 0xcc00>;
-   interrupts = <0 138 0>;
+   interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
phys = <&hsusb_phy2>;
phy-names = "usb2-phy";
};
@@ -838,7 +839,7 @@
dwc3@6a0 {
compatible = "snps,dwc3";
reg = <0x6a0 0xcc00>;
-   interrupts = <0 131 0>;
+   interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
phys = <&hsusb_phy1>, <&ssusb_phy_0>;
phy-names = "usb2-phy", "usb3-phy";
};
@@ -872,7 +873,7 @@
ranges = <0x0100 0x0 0x0c20 0x0c20 
0x0 0x10>,
<0x0200 0x0 0x0c30 0x0c30 
0x0 0xd0>;
 
-   interrupts = ;
+   interrupts = ;
interrupt-names = "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
@@ -927,7 +928,7 @@
ranges = <0x0100 0x0 0x0d20 0x0d20 
0x0 0x10>,
<0x0200 0x0 0x0d30 0x0d30 
0x0 0xd0>;
 
-   interrupts = ;
+   interrupts = ;
interrupt-names = "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
@@ -980,7 +981,7 @@
 
device_type = "pci";
 
-   interrupts = ;
+   interrupts = ;
interrupt-names = "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
-- 
2.14.1

Re: [RFC PATCH 1/3] of: base: Introduce of_alias_check_id() to check alias IDs

[Michal Simek]

On 27.4.2018 04:39, Rob Herring wrote:
> On Thu, Apr 26, 2018 at 9:08 AM, Michal Simek  wrote:
>> The function travers the lookup table to check if the request alias
>> id is compatible with the device driver match structure.
>> This function will be used by serial drivers to check if requested alias
>> is allocated or free to use.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  drivers/of/base.c  | 49 ++
>>  include/linux/of.h |  2 ++
>>  2 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 848f549164cd..382de01acc72 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -1892,6 +1892,55 @@ int of_alias_get_id(struct device_node *np, const 
>> char *stem)
>>  }
>>  EXPORT_SYMBOL_GPL(of_alias_get_id);
>>
>> +/**
>> + * of_alias_check_id - Check alias id for the give compatibility
>> + * @matches:   Array of of device match structures to search in
>> + * @stem:  Alias stem of the given device_node
>> + * @id:Alias ID for checking
>> + *
>> + * The function travers the lookup table to check if the request alias id
>> + * is compatible with the device driver match structure
>> + *
>> + * Return true if ID is allocated, return false if not
>> + */
>> +bool of_alias_check_id(const struct of_device_id *matches, const char *stem,
>> +  int id)
> 
> Wouldn't it be simpler to just return a bitmap of all allocated ids
> that match rather than trying to build that up 1 bit at a time?

Is alias list stable or can dt overlay change it?

What should be the expected flow? Find out maximum number of aliases of
the same kind and allocate bitmap and return it with length.

Anyway if you look at that patches I sent then I call in the driver
of_alias_get_highest_id("serial") which doesn't take care if alias match
with actual driver. It means having information about max alias ID which
match actual driver that would be helpful but I am not quite sure what
should be the flow.

Any link to similar function would be good to understand how the flow is
supposed to work.

Thanks,
Michal

Re: [PATCH -tip v2 0/7] kprobes: Fix %p in kprobes

[Masami Hiramatsu]

On Thu, 26 Apr 2018 21:14:34 -0400
Steven Rostedt  wrote:

> On Thu, 26 Apr 2018 10:40:22 +0200
> Greg KH  wrote:
> 
> > 
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read:
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to do this properly.
> > 
> > 
> 
> Is it because he didn't add the Cc: sta...@vger.kernel.org tag?

I think this series actually conflict with Thomas's patch which is already
merged.

I'll update the series on the latest linus tree and resend it.

Thanks,

> 
> -- Steve


-- 
Masami Hiramatsu 

Re: [PATCH v2 1/2] dt-bindings: nvmem: Add binding for RAVE SP EEPROM driver

[Andrey Smirnov]

On Mon, Apr 16, 2018 at 8:05 AM, Rob Herring  wrote:
> On Tue, Apr 10, 2018 at 06:59:47PM -0700, Andrey Smirnov wrote:
>> Add Device Tree bindings for RAVE SP EEPROM driver - an MFD cell of
>> parent RAVE SP driver (documented in
>> Documentation/devicetree/bindings/mfd/zii,rave-sp.txt).
>>
>> Cc: Srinivas Kandagatla 
>> Cc: linux-kernel@vger.kernel.org
>> Cc: Chris Healy 
>> Cc: Lucas Stach 
>> Cc: Aleksander Morgado 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  .../bindings/nvmem/zii,rave-sp-eeprom.txt  | 29 
>> ++
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt 
>> b/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt
>> new file mode 100644
>> index ..a4e838c30b67
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt
>> @@ -0,0 +1,29 @@
>> +Zodiac Inflight Innovations RAVE EEPROM Bindings
>> +
>> +RAVE SP EEPROM device is a "MFD cell" device exposing physical EEPROM
>> +attached to RAVE Supervisory Processor. It is expected that its Device
>> +Tree node is specified as a child of the node corresponding to the
>> +parent RAVE SP device (as documented in
>> +Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "zii,rave-sp-eeprom"
>
> Need to state somewhere this follows the bindings/nvmem/nvmem.txt
> binding.
>

OK, will fix in v3.

>> +
>> +Example:
>> +
>> + rave-sp {
>> + compatible = "zii,rave-sp-rdu1";
>> + current-speed = <38400>;
>> +
>> + main-eeprom {
>
> eeprom@a4

Any chance I can keep it as is? I am asking because this node name is
used by the driver as device name which is how it also appears in
sysfs. Reason for that being that "main-eeprom" and "dds-eeprom"
(second EEPROM in the system) are easier to rembmer and tell apart
than "eeprom@a4" and "eeprom@a5". Granted, I can divorce naming scheme
in the driver from device node name, but then I'd have to keep a
"address -> deivce name" lookup table which I was hoping to avoid.

>
>> + compatible = "zii,rave-sp-eeprom";
>> + reg = <0xA4 0x4000>;
>
> lowercase hex please.

OK, will do in v3.

Thanks,
Andrey Smirnov

RE: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

[KY Srinivasan]

> -Original Message-
> From: Thomas Gleixner 
> Sent: Thursday, April 26, 2018 2:49 PM
> To: KY Srinivasan 
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; h...@zytor.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuzn...@redhat.com
> Subject: Re: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access
> 
> On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> > --- /dev/null
> > +++ b/arch/x86/hyperv/hv_apic.c
> > @@ -0,0 +1,98 @@
> > +// SPDX-License-Identifier: GPL-2.0
> 
> Thanks for putting the license identifier in.
> 
> > +
> > +/*
> > + * Hyper-V specific APIC code.
> > + *
> > + * Copyright (C) 2018, Microsoft, Inc.
> > + *
> > + * Author : K. Y. Srinivasan 
> 
> But can you please check with your lawyers whether you can avoid the
> pointless boilerplate? The SPDX identifier should cover it.

I will consult with MSFT legal on this.
> 
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as
> published
> > + * by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD
> TITLE or
> > + * NON INFRINGEMENT.  See the GNU General Public License for more
> > + * details.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> We usually order the includes
> 
> #include 
> ...
> #include 
> 
> #include 
> #include 
> 
> 
> > -void hyperv_init(void);
> > +void __init hyperv_init(void);
> >  void hyperv_setup_mmu_ops(void);
> >  void hyper_alloc_mmu(void);
> >  void hyperv_report_panic(struct pt_regs *regs, long err);
> > @@ -269,14 +269,16 @@ void hyperv_reenlightenment_intr(struct pt_regs
> *regs);
> >  void set_hv_tscchange_cb(void (*cb)(void));
> >  void clear_hv_tscchange_cb(void);
> >  void hyperv_stop_tsc_emulation(void);
> > +void hv_apic_init(void);
> >  #else /* CONFIG_HYPERV */
> > -static inline void hyperv_init(void) {}
> > +static __init  inline void hyperv_init(void) {}
> 
> The __init on the empty inline function is pointless.
> 
> Other than the few nits. This looks well done!

Thanks Thomas. I will address all the issues you have brought up in
the next version.

Regards,

K. Y

Re: [PATCH v2] mm: huge_memory: Change return type to vm_fault_t

[Souptick Joarder]

On Wed, Apr 25, 2018 at 12:39 PM, David Rientjes  wrote:
> On Wed, 25 Apr 2018, Souptick Joarder wrote:
>
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> Commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>
>> Signed-off-by: Souptick Joarder 
>> Reviewed-by: Matthew Wilcox 
>> ---
>> v2: Updated the change log
>>
>>  include/linux/huge_mm.h | 5 +++--
>>  mm/huge_memory.c| 4 ++--
>>  2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index a8a1262..d3bbf6b 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -3,6 +3,7 @@
>>  #define _LINUX_HUGE_MM_H
>>
>>  #include 
>> +#include 
>>
>>  #include  /* only for vma_is_dax() */
>>
>> @@ -46,9 +47,9 @@ extern bool move_huge_pmd(struct vm_area_struct *vma, 
>> unsigned long old_addr,
>>  extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
>>   unsigned long addr, pgprot_t newprot,
>>   int prot_numa);
>> -int vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,
>> +vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long 
>> addr,
>>   pmd_t *pmd, pfn_t pfn, bool write);
>> -int vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr,
>> +vm_fault_t vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long 
>> addr,
>>   pud_t *pud, pfn_t pfn, bool write);
>>  enum transparent_hugepage_flag {
>>   TRANSPARENT_HUGEPAGE_FLAG,
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 87ab9b8..1fe4705 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -755,7 +755,7 @@ static void insert_pfn_pmd(struct vm_area_struct *vma, 
>> unsigned long addr,
>>   spin_unlock(ptl);
>>  }
>>
>> -int vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,
>> +vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long 
>> addr,
>>   pmd_t *pmd, pfn_t pfn, bool write)
>>  {
>>   pgprot_t pgprot = vma->vm_page_prot;
>> @@ -815,7 +815,7 @@ static void insert_pfn_pud(struct vm_area_struct *vma, 
>> unsigned long addr,
>>   spin_unlock(ptl);
>>  }
>>
>> -int vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr,
>> +vm_fault_t vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long 
>> addr,
>>   pud_t *pud, pfn_t pfn, bool write)
>>  {
>>   pgprot_t pgprot = vma->vm_page_prot;
>
> This isn't very useful unless functions that return the return value of
> these functions, __dev_dax_{pmd,pud}_fault(), recast it as an int.
> __dev_dax_pte_fault() would do the same thing, so it should logically also
> be vm_fault_t, so then you would convert dev_dax_huge_fault() and
> dev_dax_fault() as well in the same patch.

yes, the return value of _dev_dax_{pmd,pud,pte}_fault(), dev_dax_huge_fault(),
dev_dax_fault() is already changed in a separate patch which was reviewed
by Matthew and Ross. Other patch was posted in linux-nvdimm mailing list.

Re: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

[kbuild test robot]

Hi Srinivasan,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.17-rc2]
[also build test ERROR on next-20180426]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-linuxonhyperv-com/X86-Hyper-V-APIC-enlightenments/20180427-114416
config: i386-randconfig-b0-04270034 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_read':
>> arch/x86/hyperv/hv_apic.c:65:3: error: implicit declaration of function 
>> 'native_apic_mem_read' [-Werror=implicit-function-declaration]
  return native_apic_mem_read(reg);
  ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_write':
>> arch/x86/hyperv/hv_apic.c:79:3: error: implicit declaration of function 
>> 'native_apic_mem_write' [-Werror=implicit-function-declaration]
  native_apic_mem_write(reg, val);
  ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_init':
>> arch/x86/hyperv/hv_apic.c:92:3: error: implicit declaration of function 
>> 'apic_set_eoi_write' [-Werror=implicit-function-declaration]
  apic_set_eoi_write(hv_apic_eoi_write);
  ^
>> arch/x86/hyperv/hv_apic.c:93:3: error: 'apic' undeclared (first use in this 
>> function)
  apic->read  = hv_apic_read;
  ^
   arch/x86/hyperv/hv_apic.c:93:3: note: each undeclared identifier is reported 
only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/native_apic_mem_read +65 arch/x86/hyperv/hv_apic.c

51  
52  static u32 hv_apic_read(u32 reg)
53  {
54  u32 reg_val, hi;
55  
56  switch (reg) {
57  case APIC_EOI:
58  rdmsr(HV_X64_MSR_EOI, reg_val, hi);
59  return reg_val;
60  case APIC_TASKPRI:
61  rdmsr(HV_X64_MSR_TPR, reg_val, hi);
62  return reg_val;
63  
64  default:
  > 65  return native_apic_mem_read(reg);
66  }
67  }
68  
69  static void hv_apic_write(u32 reg, u32 val)
70  {
71  switch (reg) {
72  case APIC_EOI:
73  wrmsr(HV_X64_MSR_EOI, val, 0);
74  break;
75  case APIC_TASKPRI:
76  wrmsr(HV_X64_MSR_TPR, val, 0);
77  break;
78  default:
  > 79  native_apic_mem_write(reg, val);
80  }
81  }
82  
83  static void hv_apic_eoi_write(u32 reg, u32 val)
84  {
85  wrmsr(HV_X64_MSR_EOI, val, 0);
86  }
87  
88  void __init hv_apic_init(void)
89  {
90  if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
91  pr_info("Hyper-V: Using MSR ased APIC access\n");
  > 92  apic_set_eoi_write(hv_apic_eoi_write);
  > 93  apic->read  = hv_apic_read;

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


.config.gz
Description: application/gzip

[git pull] drm fixes for v4.17-rc3

[Dave Airlie]

Hi Linus,

Pretty run of the mill for this stage in the cycle.

i915:
- Black screen fixes
- Display w/a fix
- HDA codec interop fix
sun4i:
- tbsa711 tablet regression fix
qxl:
- Regression fixes due to changes in TTM
virtio:
- Fix wait event condition
msm:
- DSI display fixes
amdgpu:
- fix hang on Carrizo
- DP MST hang fixes
- irq handling deadlock in DC.
amdkfd:
- Fix Kconfig issue
- Clock retrieval fix
- Sparse fixes

Regards,
Dave.


The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc3

for you to fetch changes up to 24d9092c8b7de0a0f630adbe3504bef8d3a618af:

  Merge tag 'drm-intel-fixes-2018-04-26' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-04-27
14:08:47 +1000)


msm, i915, amdgpu, qxl, virtio-gpu, sun4i fixes


Abhay Kumar (1):
  drm/i915/audio: set minimum CD clock to twice the BCLK

Abhinav Kumar (3):
  drm/msm/dsi: check return value for video done waits
  drm/msm/dsi: check video mode engine status before waiting
  drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

Andres Rodriguez (1):
  drm/amdkfd: fix clock counter retrieval for node without GPU

Ben Hutchings (1):
  drm/msm: Fix possible null dereference on failure of get_pages()

Dave Airlie (5):
  Merge tag 'drm-amdkfd-fixes-2018-04-24' of
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-msm-fixes-2018-04-25' of
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2018-04-25' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2018-04-26' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Emil Velikov (1):
  drm/msm: don't deref error pointer in the msm_fbdev_create error path

Gerd Hoffmann (3):
  qxl: fix qxl_release_{map,unmap}
  qxl: keep separate release_bo pointer
  drm/virtio: fix vq wait_event condition

Harry Wentland (2):
  drm/amd/display: Disallow enabling CRTC without primary plane with FB
  drm/amd/display: Don't read EDID in atomic_check

Imre Deak (1):
  drm/i915: Enable display WA#1183 from its correct spot

Jerry (Fangzhi) Zuo (2):
  drm/amd/display: Update MST edid property every time
  drm/amd/display: Check dc_sink every time in MST hotplug

Jeykumar Sankaran (1):
  drm/msm: Add modifier to mdp_get_format arguments

José Roberto de Souza (1):
  drm/i915/fbdev: Enable late fbdev initial configuration

Mika Kuoppala (1):
  drm/i915: Use ktime on wait_for

Mikita Lipski (1):
  drm/amd/display: Fix deadlock when flushing irq

Nicolai Hähnle (1):
  drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shaders

Ondrej Jirman (1):
  Revert "drm/sun4i: add lvds mode_valid function"

Randy Dunlap (1):
  drm/amdkfd: fix build, select MMU_NOTIFIER

Sean Paul (1):
  drm/msm: Mark the crtc->state->event consumed

Stefan Agner (1):
  drm/msm/dsi: use correct enum in dsi_get_cmd_fmt

Ville Syrjälä (1):
  drm/edid: Reset more of the display info

Wei Yongjun (1):
  drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

kbuild test robot (1):
  drm/amdkfd: kfd_dev_is_large_bar() can be static

 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   7 +-
 drivers/gpu/drm/amd/amdkfd/Kconfig |   1 +
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  17 ++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  10 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  |   5 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  54 +-
 drivers/gpu/drm/drm_edid.c |  11 +--
 drivers/gpu/drm/i915/intel_cdclk.c |  16 ++-
 drivers/gpu/drm/i915/intel_drv.h   |   4 +-
 drivers/gpu/drm/i915/intel_fbdev.c |   2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c|  11 +--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c  |   1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  |   1 +
 drivers/gpu/drm/msm/disp/mdp_format.c  |   3 +-
 drivers/gpu/drm/msm/disp/mdp_kms.h |   2 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c |  16 ++-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 109 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 --
 drivers/gpu/drm/msm/msm_fb.c   |   3 +-
 drivers/gpu/drm/msm/msm_fbdev.c|  11 +--
 drivers/gpu/drm/msm/msm_gem.c  |  20 

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

[Christoph Hellwig]

On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> In practice if you don't have a floppy device on x86, you don't need ZONE_DMA,

I call BS on that, and you actually explain later why it it BS due
to some drivers using it more explicitly.  But even more importantly
we have plenty driver using it through dma_alloc_* and a small DMA
mask, and they are in use - we actually had a 4.16 regression due to
them.

> SCSI is *severely* affected:

Not really.  We have unchecked_isa_dma to support about 4 drivers,
and less than a hand ful of drivers doing stupid things, which can
be fixed easily, and just need a volunteer.

> That's the end of the review of all current explicit callers on x86.
> 
> # dma_alloc_coherent_gfp_flags() and dma_generic_alloc_coherent()
> 
> dma_alloc_coherent_gfp_flags() and dma_generic_alloc_coherent() set
> GFP_DMA if if (dma_mask <= DMA_BIT_MASK(24))

All that code is long gone and replaced with dma-direct.  Which still
uses GFP_DMA based on the dma mask, though - see above.

KASAN: use-after-free Read in process_preds

[syzbot]

Hello,

syzbot hit the following crash on bpf-next commit
5d1365940a68dd57b031b6e3c07d7d451cd69daf (Thu Apr 12 18:09:05 2018 +)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=b6fc33dcecb65cd8ff80


Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=4606019153952768
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-5947642240294114534

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b6fc33dcecb65cd8f...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

==
BUG: KASAN: use-after-free in predicate_parse  
kernel/trace/trace_events_filter.c:563 [inline]
BUG: KASAN: use-after-free in process_preds+0x197f/0x19b0  
kernel/trace/trace_events_filter.c:1505

Read of size 4 at addr 8801b9832ce4 by task syz-executor0/28463

CPU: 0 PID: 28463 Comm: syz-executor0 Not tainted 4.16.0+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
 predicate_parse kernel/trace/trace_events_filter.c:563 [inline]
 process_preds+0x197f/0x19b0 kernel/trace/trace_events_filter.c:1505
 create_filter+0x1a8/0x370 kernel/trace/trace_events_filter.c:1714
 ftrace_profile_set_filter+0x109/0x2b0  
kernel/trace/trace_events_filter.c:2042

 perf_event_set_filter+0x248/0x1230 kernel/events/core.c:9064
 _perf_ioctl+0x84c/0x15e0 kernel/events/core.c:5056
 perf_ioctl+0x59/0x80 kernel/events/core.c:5107
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 SYSC_ioctl fs/ioctl.c:708 [inline]
 SyS_ioctl+0x24/0x30 fs/ioctl.c:706
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x455329
RSP: 002b:7f14b2c73c68 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7f14b2c746d4 RCX: 00455329
RDX: 2040 RSI: 40082406 RDI: 0013
RBP: 0072bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 0291 R14: 006f6e38 R15: 

Allocated by task 2370:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
 getname_flags+0xd0/0x5a0 fs/namei.c:140
 getname+0x19/0x20 fs/namei.c:211
 do_sys_open+0x39a/0x740 fs/open.c:1087
 SYSC_open fs/open.c: [inline]
 SyS_open+0x2d/0x40 fs/open.c:1106
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

Freed by task 2370:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
 __cache_free mm/slab.c:3498 [inline]
 kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
 putname+0xf2/0x130 fs/namei.c:261
 do_sys_open+0x554/0x740 fs/open.c:1102
 SYSC_open fs/open.c: [inline]
 SyS_open+0x2d/0x40 fs/open.c:1106
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

The buggy address belongs to the object at 8801b9832340
 which belongs to the cache names_cache of size 4096
The buggy address is located 2468 bytes inside of
 4096-byte region [8801b9832340, 8801b9833340)
The buggy address belongs to the page:
page:ea0006e60c80 count:1 mapcount:0 mapping:8801b9832340 index:0x0  
compound_mapcount: 0

flags: 0x2fffc008100(slab|head)
raw: 02fffc008100 8801b9832340  00010001
raw: ea000743eca0 ea0006628f20 8801dad86dc0 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8801b9832b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8801b9832c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

8801b9832c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

   ^
 8801b9832d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8801b9832d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==


---

KASAN: slab-out-of-bounds Read in process_preds

[syzbot]

Hello,

syzbot hit the following crash on bpf-next commit
af487c509d4b7f874fe1a33f9289d51b9adc (Wed Apr 25 07:56:11 2018 +)
Merge branch 'bpf-optimize-neg-sums'
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=e47d942a98e75b4bd03e


Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5744539889303552
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-2918904850634584293

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e47d942a98e75b4bd...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

==
BUG: KASAN: slab-out-of-bounds in predicate_parse  
kernel/trace/trace_events_filter.c:562 [inline]
BUG: KASAN: slab-out-of-bounds in process_preds+0x196f/0x19b0  
kernel/trace/trace_events_filter.c:1505

Read of size 4 at addr 8801b2b55ff0 by task syz-executor7/7974

CPU: 1 PID: 7974 Comm: syz-executor7 Not tainted 4.17.0-rc1+ #12
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
 predicate_parse kernel/trace/trace_events_filter.c:562 [inline]
 process_preds+0x196f/0x19b0 kernel/trace/trace_events_filter.c:1505
 create_filter+0x155/0x270 kernel/trace/trace_events_filter.c:1713
 ftrace_profile_set_filter+0x130/0x2e0  
kernel/trace/trace_events_filter.c:2038

 perf_event_set_filter+0x248/0x1230 kernel/events/core.c:9075
 _perf_ioctl+0x84c/0x15e0 kernel/events/core.c:5059
 perf_ioctl+0x59/0x80 kernel/events/core.c:5110
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455389
RSP: 002b:7f63bbd38c68 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7f63bbd396d4 RCX: 00455389
RDX: 2040 RSI: 40082406 RDI: 0013
RBP: 0072bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 029a R14: 006f6f10 R15: 

Allocated by task 6559:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
 anon_vma_chain_alloc mm/rmap.c:128 [inline]
 anon_vma_clone+0x138/0x720 mm/rmap.c:268
 anon_vma_fork+0xe8/0x950 mm/rmap.c:331
 dup_mmap kernel/fork.c:468 [inline]
 dup_mm kernel/fork.c:1235 [inline]
 copy_mm kernel/fork.c:1289 [inline]
 copy_process.part.38+0x2f21/0x6e90 kernel/fork.c:1795
 copy_process kernel/fork.c:1608 [inline]
 _do_fork+0x291/0x12a0 kernel/fork.c:2089
 __do_sys_clone kernel/fork.c:2196 [inline]
 __se_sys_clone kernel/fork.c:2190 [inline]
 __x64_sys_clone+0xbf/0x150 kernel/fork.c:2190
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 7294:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
 __cache_free mm/slab.c:3498 [inline]
 kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
 anon_vma_chain_free mm/rmap.c:133 [inline]
 unlink_anon_vmas+0x3aa/0xa40 mm/rmap.c:400
 free_pgtables+0x271/0x380 mm/memory.c:641
 exit_mmap+0x2ca/0x570 mm/mmap.c:3057
 __mmput kernel/fork.c:962 [inline]
 mmput+0x251/0x610 kernel/fork.c:983
 exec_mmap fs/exec.c:1044 [inline]
 flush_old_exec+0xb94/0x20e0 fs/exec.c:1276
 load_elf_binary+0xa33/0x5610 fs/binfmt_elf.c:869
 search_binary_handler+0x17d/0x570 fs/exec.c:1653
 exec_binprm fs/exec.c:1695 [inline]
 do_execveat_common.isra.34+0x16ce/0x2590 fs/exec.c:1817
 do_execve fs/exec.c:1862 [inline]
 __do_sys_execve fs/exec.c:1943 [inline]
 __se_sys_execve fs/exec.c:1938 [inline]
 __x64_sys_execve+0x8d/0xb0 fs/exec.c:1938
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 8801b2b55f60
 which belongs to the cache anon_vma_chain of size 64
The buggy address is located 80 bytes to the right of
 64-byte region [8801b2b55f60

BUG: unable to handle kernel paging request in process_preds

[syzbot]

Hello,

syzbot hit the following crash on bpf-next commit
0c90f2243ec67eeacf9624ae52ab43c734fe0e93 (Wed Apr 18 02:46:34 2018 +)
tools: bpftool: make it easier to feed hex bytes to bpftool
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=b76562b749bb67fca79f


Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5319914659250176
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-5947642240294114534

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b76562b749bb67fca...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

BUG: unable to handle kernel paging request at 87f9dbf70994
PGD 0 P4D 0
Oops:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 7133 Comm: syz-executor4 Not tainted 4.16.0+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:predicate_parse kernel/trace/trace_events_filter.c:563 [inline]
RIP: 0010:process_preds+0x146c/0x19b0  
kernel/trace/trace_events_filter.c:1505

RSP: 0018:880197cc7438 EFLAGS: 00010246
RAX: 0007 RBX: 87f9dbf70990 RCX: 
RDX:  RSI: 817f1ee9 RDI: 87f9dbf70994
RBP: 880197cc7540 R08: 8801b2146540 R09: ed003b6246c2
R10: ed003b6246c2 R11: 8801db123613 R12: dc00
R13: 8801c1f04fe0 R14: fffe R15: dc00
FS:  7fedc5480700() GS:8801db10() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 87f9dbf70994 CR3: 0001a0041000 CR4: 001406e0
DR0: 2000 DR1: 2000 DR2: 
DR3:  DR6: fffe0ff0 DR7: 0600
Call Trace:
 create_filter+0x1a8/0x370 kernel/trace/trace_events_filter.c:1714
 ftrace_profile_set_filter+0x109/0x2b0  
kernel/trace/trace_events_filter.c:2042

 perf_event_set_filter+0x248/0x1230 kernel/events/core.c:9064
 _perf_ioctl+0x84c/0x15e0 kernel/events/core.c:5056
 perf_ioctl+0x59/0x80 kernel/events/core.c:5107
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 SYSC_ioctl fs/ioctl.c:708 [inline]
 SyS_ioctl+0x24/0x30 fs/ioctl.c:706
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x455329
RSP: 002b:7fedc547fc68 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7fedc54806d4 RCX: 00455329
RDX: 2100 RSI: 40082406 RDI: 0014
RBP: 0072bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 0291 R14: 006f6e38 R15: 
Code: ff ff 41 8b 55 04 48 8d 7b 04 48 89 f8 48 c1 e8 03 42 0f b6 0c 20 48  
89 f8 83 e0 07 83 c0 03 38 c8 7c 08 84 c9 0f 85 08 05 00 00 <44> 8b 7b 04  
89 d7 89 95 68 ff ff ff 44 89 fe e8 80 0a f8 ff 8b
RIP: predicate_parse kernel/trace/trace_events_filter.c:563 [inline] RSP:  
880197cc7438
RIP: process_preds+0x146c/0x19b0 kernel/trace/trace_events_filter.c:1505  
RSP: 880197cc7438

CR2: 87f9dbf70994
---[ end trace 9971f5aefc423124 ]---


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

[PATCH] NFS: Avoid quadratic search when freeing delegations.

[NeilBrown]

If an NFS client has 10,000 delegations which are between 90 and 180 seconds 
old,
and 10,000 which are between 180 and 270 seconds old, with none of them still
in use, it is likely that the old ones are at the end of the list.
The first 10,000 will not be marked to be returned, the last 10,000 will.

To return these, the code starts at the front of the list and finds the
first delegation needing to be returned (testing 10,000 on the way).
Then it drops rcu_readlock(), returns the delegation and starts again,
and does this 10,000 times.

As delegation return is async, it may never block, so these 10,000
delegation will be returned without stopping for a breath.  The soft-lock
detector will notice and complain.

This patch makes 3 changes.

1/ cond_resched() is added so that the soft-lockup detector doesn't notice.
2/ A place-holder (an inode) is kept when locks are dropped, so that
   the place can usually be found again after taking rcu_readlock().
   This means we don't need to skip over 10,000 entries 10,000 times,
   100 million pointless operations - which could eaisly be a larger
   number.
3/ If nfs_sb_active() fails, break out of the loop - there is no point
   in continuing.

The patch also add list_for_each_entry_from_rcu() to rculist.h in
order to achieve 2/.

Signed-off-by: NeilBrown 
---

Hi,
 I'm hoping one of the RCU reviewers will provide an Acked-by for the
 rculist.h change.

 If you'ld like 3 patches instead of just one, please let me know.  But
 they all see to fit well together.

thanks,
NeilBrown


 fs/nfs/delegation.c | 57 -
 include/linux/rculist.h | 10 +
 2 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 1819d0d0ba4b..c3d9e21ab440 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -483,19 +483,56 @@ static bool nfs_delegation_need_return(struct 
nfs_delegation *delegation)
 int nfs_client_return_marked_delegations(struct nfs_client *clp)
 {
struct nfs_delegation *delegation;
+   struct nfs_delegation *prev;
struct nfs_server *server;
struct inode *inode;
+   struct inode *place_holder = NULL;
int err = 0;
 
 restart:
+   /*
+* To avoid quadratic looping we hold an reference
+* to an inode place_holder.  Each time we restart, we
+* list nfs_servers from the server of that inode, and
+* delegation in the server from the delegations of that
+* inode.
+* prev is an RCU-protected pointer to a delegation which
+* wasn't marked for return and might be a good choice for
+* the next place_holder.
+*/
rcu_read_lock();
-   list_for_each_entry_rcu(server, &clp->cl_superblocks, client_link) {
-   list_for_each_entry_rcu(delegation, &server->delegations,
-   super_list) {
-   if (!nfs_delegation_need_return(delegation))
+   prev = NULL;
+   if (place_holder)
+   server = NFS_SERVER(place_holder);
+   else
+   server = list_entry_rcu(clp->cl_superblocks.next,
+   struct nfs_server, client_link);
+   list_for_each_entry_from_rcu(server, &clp->cl_superblocks, client_link) 
{
+   delegation = NULL;
+   if (place_holder && server == NFS_SERVER(place_holder))
+   delegation = 
rcu_dereference(NFS_I(place_holder)->delegation);
+   if (!delegation)
+   delegation = list_entry_rcu(server->delegations.next,
+   struct nfs_delegation, 
super_list);
+   list_for_each_entry_from_rcu(delegation, &server->delegations, 
super_list) {
+   struct inode *to_put = NULL;
+
+   if (!nfs_delegation_need_return(delegation)) {
+   prev = delegation;
continue;
+   }
if (!nfs_sb_active(server->super))
-   continue;
+   break;
+
+   if (prev) {
+   struct inode *tmp;
+   tmp = nfs_delegation_grab_inode(prev);
+   if (tmp) {
+   to_put = place_holder;
+   place_holder = tmp;
+   }
+   }
+
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -505,16 +542,26 @@ int nfs_client_return_marked_delegations(struct 
nfs_client *clp)
delegation = 
nfs_start_delegation_return_locked(NFS_I(inode));
rcu_

[PATCH v3] net: qrtr: Expose tunneling endpoint to user space

[Bjorn Andersson]

This implements a misc character device named "qrtr-tun" for the purpose
of allowing user space applications to implement endpoints in the qrtr
network.

This allows more advanced (and dynamic) testing of the qrtr code as well
as opens up the ability of tunneling qrtr over a network or USB link.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Add support for read poll

Changes since v1:
- Dropped queue lock

 net/qrtr/Kconfig  |   7 +++
 net/qrtr/Makefile |   2 +
 net/qrtr/tun.c| 161 ++
 3 files changed, 170 insertions(+)
 create mode 100644 net/qrtr/tun.c

diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
index 326fd97444f5..1944834d225c 100644
--- a/net/qrtr/Kconfig
+++ b/net/qrtr/Kconfig
@@ -21,4 +21,11 @@ config QRTR_SMD
  Say Y here to support SMD based ipcrouter channels.  SMD is the
  most common transport for IPC Router.
 
+config QRTR_TUN
+   tristate "TUN device for Qualcomm IPC Router"
+   ---help---
+ Say Y here to expose a character device that allows user space to
+ implement endpoints of QRTR, for purpose of tunneling data to other
+ hosts or testing purposes.
+
 endif # QRTR
diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile
index ab09e40f7c74..be012bfd3e52 100644
--- a/net/qrtr/Makefile
+++ b/net/qrtr/Makefile
@@ -2,3 +2,5 @@ obj-$(CONFIG_QRTR) := qrtr.o
 
 obj-$(CONFIG_QRTR_SMD) += qrtr-smd.o
 qrtr-smd-y := smd.o
+obj-$(CONFIG_QRTR_TUN) += qrtr-tun.o
+qrtr-tun-y := tun.o
diff --git a/net/qrtr/tun.c b/net/qrtr/tun.c
new file mode 100644
index ..ccff1e544c21
--- /dev/null
+++ b/net/qrtr/tun.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, Linaro Ltd */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "qrtr.h"
+
+struct qrtr_tun {
+   struct qrtr_endpoint ep;
+
+   struct sk_buff_head queue;
+   wait_queue_head_t readq;
+};
+
+static int qrtr_tun_send(struct qrtr_endpoint *ep, struct sk_buff *skb)
+{
+   struct qrtr_tun *tun = container_of(ep, struct qrtr_tun, ep);
+
+   skb_queue_tail(&tun->queue, skb);
+
+   /* wake up any blocking processes, waiting for new data */
+   wake_up_interruptible(&tun->readq);
+
+   return 0;
+}
+
+static int qrtr_tun_open(struct inode *inode, struct file *filp)
+{
+   struct qrtr_tun *tun;
+
+   tun = kzalloc(sizeof(*tun), GFP_KERNEL);
+   if (!tun)
+   return -ENOMEM;
+
+   skb_queue_head_init(&tun->queue);
+   init_waitqueue_head(&tun->readq);
+
+   tun->ep.xmit = qrtr_tun_send;
+
+   filp->private_data = tun;
+
+   return qrtr_endpoint_register(&tun->ep, QRTR_EP_NID_AUTO);
+}
+
+static ssize_t qrtr_tun_read_iter(struct kiocb *iocb, struct iov_iter *to)
+{
+   struct file *filp = iocb->ki_filp;
+   struct qrtr_tun *tun = filp->private_data;
+   struct sk_buff *skb;
+   int count;
+
+   while (!(skb = skb_dequeue(&tun->queue))) {
+   if (filp->f_flags & O_NONBLOCK)
+   return -EAGAIN;
+
+   /* Wait until we get data or the endpoint goes away */
+   if (wait_event_interruptible(tun->readq,
+!skb_queue_empty(&tun->queue)))
+   return -ERESTARTSYS;
+   }
+
+   count = min_t(size_t, iov_iter_count(to), skb->len);
+   if (copy_to_iter(skb->data, count, to) != count)
+   count = -EFAULT;
+
+   kfree_skb(skb);
+
+   return count;
+}
+
+static ssize_t qrtr_tun_write_iter(struct kiocb *iocb, struct iov_iter *from)
+{
+   struct file *filp = iocb->ki_filp;
+   struct qrtr_tun *tun = filp->private_data;
+   size_t len = iov_iter_count(from);
+   ssize_t ret;
+   void *kbuf;
+
+   kbuf = kzalloc(len, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
+
+   if (!copy_from_iter_full(kbuf, len, from))
+   return -EFAULT;
+
+   ret = qrtr_endpoint_post(&tun->ep, kbuf, len);
+
+   return ret < 0 ? ret : len;
+}
+
+static __poll_t qrtr_tun_poll(struct file *filp, poll_table *wait)
+{
+   struct qrtr_tun *tun = filp->private_data;
+   __poll_t mask = 0;
+
+   poll_wait(filp, &tun->readq, wait);
+
+   if (!skb_queue_empty(&tun->queue))
+   mask |= EPOLLIN | EPOLLRDNORM;
+
+   return mask;
+}
+
+static int qrtr_tun_release(struct inode *inode, struct file *filp)
+{
+   struct qrtr_tun *tun = filp->private_data;
+   struct sk_buff *skb;
+
+   qrtr_endpoint_unregister(&tun->ep);
+
+   /* Discard all SKBs */
+   while (!skb_queue_empty(&tun->queue)) {
+   skb = skb_dequeue(&tun->queue);
+   kfree_skb(skb);
+   }
+
+   kfree(tun);
+
+   return 0;
+}
+
+static const struct file_operations qrtr_tun_ops = {
+   .owner = THIS_MODULE,
+   .open = qrtr_tun_open,
+   .poll = qrtr_tun_poll,
+   .read_iter

[PATCH] ASoC: uniphier: remove boilerplate from lisence comment

[Katsuhiro Suzuki]

This patch removes boilerplate of GPLv2, use only SPDX identifier as
same as other recently ASoC DAI drivers.

Signed-off-by: Katsuhiro Suzuki 
---
 sound/soc/uniphier/aio-compress.c | 13 -
 sound/soc/uniphier/aio-core.c | 13 -
 sound/soc/uniphier/aio-cpu.c  | 13 -
 sound/soc/uniphier/aio-dma.c  | 13 -
 sound/soc/uniphier/aio-ld11.c | 13 -
 sound/soc/uniphier/aio-reg.h  | 13 -
 sound/soc/uniphier/aio.h  | 13 -
 7 files changed, 91 deletions(-)

diff --git a/sound/soc/uniphier/aio-compress.c 
b/sound/soc/uniphier/aio-compress.c
index 4c1027aa615e..17f773ac5ca1 100644
--- a/sound/soc/uniphier/aio-compress.c
+++ b/sound/soc/uniphier/aio-compress.c
@@ -3,19 +3,6 @@
 // Socionext UniPhier AIO Compress Audio driver.
 //
 // Copyright (c) 2017-2018 Socionext Inc.
-//
-// This program is free software; you can redistribute it and/or
-// modify it under the terms of the GNU General Public License
-// as published by the Free Software Foundation; version 2
-// of the License.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, see .
 
 #include 
 #include 
diff --git a/sound/soc/uniphier/aio-core.c b/sound/soc/uniphier/aio-core.c
index 4a218ec90e68..638cb3fc5f7b 100644
--- a/sound/soc/uniphier/aio-core.c
+++ b/sound/soc/uniphier/aio-core.c
@@ -3,19 +3,6 @@
 // Socionext UniPhier AIO ALSA common driver.
 //
 // Copyright (c) 2016-2018 Socionext Inc.
-//
-// This program is free software; you can redistribute it and/or
-// modify it under the terms of the GNU General Public License
-// as published by the Free Software Foundation; version 2
-// of the License.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, see .
 
 #include 
 #include 
diff --git a/sound/soc/uniphier/aio-cpu.c b/sound/soc/uniphier/aio-cpu.c
index 2dc27e40c192..80daec17be25 100644
--- a/sound/soc/uniphier/aio-cpu.c
+++ b/sound/soc/uniphier/aio-cpu.c
@@ -3,19 +3,6 @@
 // Socionext UniPhier AIO ALSA CPU DAI driver.
 //
 // Copyright (c) 2016-2018 Socionext Inc.
-//
-// This program is free software; you can redistribute it and/or
-// modify it under the terms of the GNU General Public License
-// as published by the Free Software Foundation; version 2
-// of the License.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, see .
 
 #include 
 #include 
diff --git a/sound/soc/uniphier/aio-dma.c b/sound/soc/uniphier/aio-dma.c
index ef7bafa8e171..4ec6b65bfb44 100644
--- a/sound/soc/uniphier/aio-dma.c
+++ b/sound/soc/uniphier/aio-dma.c
@@ -3,19 +3,6 @@
 // Socionext UniPhier AIO DMA driver.
 //
 // Copyright (c) 2016-2018 Socionext Inc.
-//
-// This program is free software; you can redistribute it and/or
-// modify it under the terms of the GNU General Public License
-// as published by the Free Software Foundation; version 2
-// of the License.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, see .
 
 #include 
 #include 
diff --git a/sound/soc/uniphier/aio-ld11.c b/sound/soc/uniphier/aio-ld11.c
index 4c4dd3dd4dee..ab04d3331be9 100644
--- a/sound/soc/uniphier/aio-ld11.c
+++ b/sound/soc/uniphier/aio-ld11.c
@@ -3,19 +3,6 @@
 // Socionext UniPhier AIO ALSA driver for LD11/LD20.
 //
 // Copyright (c) 2016-2018 Socionext Inc.
-//
-// This program is free software; you can redistribute it and/or
-// modify it under the terms of the GNU General Public License
-// as published by the Free Software Foundation; version 2
-// of the License.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITN

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

[Marcel Holtmann]

Hi Sean,

> This adds a driver for the MediaTek serial protocol based on H4 protocol,
> which can enable the built-in Bluetooth device inside MT7622 SoC.
> 
> Signed-off-by: Sean Wang 
> ---
> 
> [... snip ...]
> 
> +
> + /* Start to build a WMT header and its actual payload. */
> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> + whdr->dir = 1;
> + whdr->op = opcode;
> + whdr->dlen = cpu_to_le16(plen + 1);
> + whdr->flag = flag;
> + skb_put_data(skb, param, plen);
> +
> + mtk_enqueue(hu, skb);
> + hci_uart_tx_wakeup(hu);
> +
> + /*
> +  * Waiting a WMT event response, while we must take care in case of
> +  * failures for the wait.
> +  */
> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> +
> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> +}
 
 All in all I am not convinced that this is super clean. I get that we need 
 something special for having this in the ACL data packets, but for the 
 standard HCI command I prefer that __hci_cmd_sync is used. I addition, it 
 seems that patch download is the only special case and that happens before 
 at the setup stage. So we could make things special for that. I need to 
 understand this a bit better. Can I get a btmon -w trace.log file from the 
 whole init procedure.
 
 
>>> 
>>> I can try to use __hci_cmd_sync to send those chip-specific hci commands
>>> which only can be recognized by the chip, but no meaningful to bluez
>>> core.
>>> 
>>> Is btmon able to capture these cmd/evt between driver and device?
>>> 
>>> my question's caused by that mtk_wmt_cmd_sync and its events only happen
>>> between driver and device,  it doesn't go to core.
>> 
>> for Intel, Broadcom, Qualcomm, Realtek etc. we use __hci_cmd_sync() in the 
>> ->setup() callback and it will show up in btmon. For at least Intel and 
>> Broadcom, btmon will decode them as well. You can hint the manufacturer id 
>> out of band it will be told to btmon. And that is also how I want it. If it 
>> is using HCI as transport, I want it to go through the Bluetooth core.
>> 
> 
> understood. I will allow chip-specific HCI cmd/evt to go to bluetooth
> core.
> 
> +
> +static int mtk_setup_fw(struct hci_uart *hu)
> +{
> + struct mtk_bt_dev *btdev = hu->priv;
> + const struct firmware *fw;
> + struct device *dev;
> + const char *fwname;
> + const u8 *fw_ptr;
> + size_t fw_size;
> + int err, dlen;
> + u8 flag;
> +
> + dev = &hu->serdev->dev;
> + fwname = FIRMWARE_MT7622;
> +
> + init_completion(&btdev->wmt_cmd);
> +
> + err = request_firmware(&fw, fwname, dev);
> + if (err < 0) {
> + dev_err(dev, "%s: Failed to load firmware file (%d)",
> + hu->hdev->name, err);
> + return err;
> + }
> +
> + fw_ptr = fw->data;
> + fw_size = fw->size;
> +
> + /* The size of a patch header at least has 30 bytes. */
> + if (fw_size < 30)
> + return -EINVAL;
> +
> + while (fw_size > 0) {
> + dlen = min_t(int, 1000, fw_size);
> +
> + /* Tell deivice the position in sequence. */
> + flag = (fw_size - dlen <= 0) ? 3 :
> +(fw_size < fw->size) ? 2 : 1;
> +
> + err = mtk_wmt_cmd_sync(hu, MTK_WMT_PATCH_DWNLD, flag,
> +dlen, fw_ptr);
> + if (err < 0)
> + break;
> +
> + fw_size -= dlen;
> + fw_ptr += dlen;
> + }
> +
> + release_firmware(fw);
> +
> + return err;
> +}
> +
> +static int mtk_open(struct hci_uart *hu)
> +{
> + struct mtk_bt_dev *btdev = hu->priv;
> + struct device *dev;
> + int err = 0;
> +
> + dev = &hu->serdev->dev;
> +
> + serdev_device_open(hu->serdev);
> + skb_queue_head_init(&btdev->txq);
> +
> + /* Setup the usage of H4. */
> + hu->alignment = 1;
> + hu->padding = 0;
> + mtk_stp_reset(btdev->sp);
> +
> + /* Enable the power domain and clock the device requires */
> + pm_runtime_enable(dev);
> + err = pm_runtime_get_sync(dev);
> + if (err < 0) {
> + pm_runtime_disable(dev);
> + return err;
> + }
> +
> + err = clk_prepare_enable(btdev->clk);
> + if (err < 0) {
> + pm_runtime_put_sync(dev);
> + pm_runtime_disable(dev);
> + }
> +
> + return err;
> +}
> +
> +static int mtk_close(struct hci_uart *hu)
> +{
> + struct mtk_bt_dev *btdev = hu->priv;
> + struct device *dev = &hu->serdev->dev;
> + u8 param = 0x0;
> +
> + skb_queue_purge(&btdev->txq);
> + kfree_skb(btdev->rx_skb);
> +
> + /* Disable the device. */
> + mtk_wmt_cmd_sync(hu, MTK_WMT_FUNC_CTRL, 0x0, sizeof(param), ¶m);
 
 Wouldn’t this r

Re: [PATCH v6] fs: dax: Adding new return type vm_fault_t

[Souptick Joarder]

> I noticed that we have the following status translation now in 4 places in 2
> files:
>
> if (err == -ENOMEM)
> return VM_FAULT_OOM;
> if (err < 0 && err != -EBUSY)
> return VM_FAULT_SIGBUS;
> return VM_FAULT_NOPAGE;
>
>
> This happens in vmf_insert_mixed_mkwrite(), vmf_insert_page(),
> vmf_insert_mixed() and vmf_insert_pfn().
>
> I think it'd be a good idea to consolidate this translation into an inline
> helper, in the spirit of dax_fault_return().  This will ensure that if/when we
> start changing this status translation, we won't accidentally miss some of the
> places which would make them get out of sync.  No need to fold this into this
> patch - it should be a separate change.

Sure, I will send this as a separate patch.

Re: [PULL 0/1] vfio-ccw: another bugfix

[Martin Schwidefsky]

On Tue, 24 Apr 2018 13:26:55 +0200
Cornelia Huck  wrote:

> The following changes since commit 6cf09958f32b9667bb3ebadf74367c791112771b:
> 
>   s390: correct module section names for expoline code revert (2018-04-23 
> 07:57:17 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git 
> tags/vfio-ccw-20180424
> 
> for you to fetch changes up to 427e522fc72395a4571b8dd7fe6d116927496bf7:
> 
>   vfio: ccw: fix cleanup if cp_prefetch fails (2018-04-23 14:11:20 +0200)
> 
> 
> Another vfio-ccw bug fix: Don't clean up things on error that were
> never translated in the first place.
> 
> 
> 
> Halil Pasic (1):
>   vfio: ccw: fix cleanup if cp_prefetch fails
> 
>  drivers/s390/cio/vfio_ccw_cp.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 

Now added the s390/linux:fixes. Thanks.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

> The CRNG changes were needed because were erroneously saying that the
> entropy pool was securely initialized before it really was.  Saying
> that CRNG should be able to init on its own is much like saying, "Ted
> should be able to fly wherever he wants in his own personal Gulfstream
> V."  It would certainly be _nice_ if I could afford my personal jet.
> I certainly wish I were that rich.  But the problem is that dollars
> (or Euro's) are like entropy, they don't just magically drop out of
> the sky.
>
> If there isn't user-provided entropy, and the hardware isn't providing
> sufficient entropy, where did you think the kernel is supposed to get
> the entropy from?  Should it dial 1-800-TRUST-NSA?
>
> From the dmesg log, you have a Chromebook Acer 14.  I'm guessing the
> problem is that Chromebooks have hardware tries *very* hard not to
> issue interrupts, since that helps with power savings.  The following
> from your dmesg is very interesting:
>
> [0.526786] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling 
> instead
>
> I suspect this isn't a firmware bug; it's the hardware working as
> intended / working as designed, for power savings reasons.
>
> So there are two ways to fix this that I can see.  One is to try to
> adjust userspace so that it allows the boot to proceed.  As there is
> more activity, the disk completion interrupts, the user typing their
> username/password into the login screen, etc., there will be timing
> events which can be used to harvest entropy.
>
> The other approach would be to compile the kernel with
> CONFIG_HW_RANDOM_TPM and to modify drivers/char/tpm/tpm-chip.c tot
> initalize chip->hwrng.quality = 500.  We've historically made this
> something that the system administrator must set via sysfs.  This is
> because we wanted system adminisrators to explicitly say that they
> trust the any hardware manufacturer that (a) they haven't been paid by
> your choice of the Chinese MSS or the US NSA to introduce a backdoor,i
> and (b) they are competent to actually implemnt a _secure_ hardware
> random number generator.  Sadly, this has not always been the case.
> Please see:
>
>   https://www.chromium.org/chromium-os/tpm_firmware_update
>
> And note that your Edgar Chromebook is one the list of devices that
> have a TPM with the buggy firmware.  Fortunately this particular TPM
> bug only affects RSA prime generation, so as far as I know there is no
> _known_ vulerability in your TPM's hardware random number generator.
> B ut we want it to be _your_ responsibility to decide you are willing
> to truste it.  I certainly don't want to be legally liable --- or even
> have the moral responsibility --- of guaranteeing that every single
> TPM out there is bug-free(tm).
>
>   - Ted

Why don't we tell users that they need to smash their keyboards to make their 
computers boot
then? And if they question it, we can tell them that it certainly would be 
_nice_ to not have
to smash their keyboards to make their computers boot, but alas, a part of me 
has a feeling that
users would not take kindly to that :)

I noted at least 20,000 mmc interrupts before I intervened in the boot process 
to provide entropy
myself. That's just for mmc, so I'm sure there were even more interrupts 
elsewhere. Is 20k+ interrupts
really not sufficient?

There are lots of other sources of entropy available as well, like the 
ever-changing CPU frequencies reported
by any recent Intel chip (i.e., they report precision down to 1 kHz). Why are 
we so limited to h/w interrupts?

Sultan

Re: [PATCH v2] nvme: change order of qid and cmdid in completion trace

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 

Re: testing io.low limit for blk-throttle

[Paolo Valente]

> Il giorno 27 apr 2018, alle ore 05:27, Joseph Qi  ha 
> scritto:
> 
> Hi Paolo,
> 
> On 18/4/27 01:27, Paolo Valente wrote:
>> 
>> 
>>> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi  ha 
>>> scritto:
>>> 
>>> Hi Paolo,
>>> 
>> 
>> Hi Joseph
>> 
>>> ...
>>> Could you run blktrace as well when testing your case? There are several
>>> throtl traces to help analyze whether it is caused by frequently
>>> upgrade/downgrade.
>> 
>> Certainly.  You can find a trace attached.  Unfortunately, I'm not
>> familiar with the internals of blk-throttle and low limit, so, if you
>> want me to analyze the trace, give me some hints on what I have to
>> look for.  Otherwise, I'll be happy to learn from your analysis.
>> 
> 
> I've taken a glance at your blktrace attached. It is only upgrade at first and
> then downgrade (just adjust limit, not to LIMIT_LOW) frequently.
> But I don't know why it always thinks throttle group is not idle.
> 
> For example:
> fio-2336  [004] d...   428.458249:   8,16   m   N throtl avg_idle=90, 
> idle_threshold=1000, bad_bio=10, total_bio=84, is_idle=0, scale=9
> fio-2336  [004] d...   428.458251:   8,16   m   N throtl downgrade, scale 4
> 
> In throtl_tg_is_idle():
> is_idle = ... ||
>   (tg->latency_target && tg->bio_cnt &&
>tg->bad_bio_cnt * 5 < tg->bio_cnt);
> 
> It should be idle and allow run more bandwidth. But here the result shows not
> idle (is_idle=0). I have to do more investigation to figure it out why. 
> 

Hi Joseph,
actually this doesn't surprise me much, for this scenario I expected
exactly that blk-throttle would have considered the random-I/O group,
for most of the time,
1) non idle,
2) above the 100usec target latency, and
3) below low limit,

In fact,
1) The group can evidently issue I/O at a much higher rate than that
received, so, immediately after its last pending I/O has been served,
the group issues new I/O; in the end, it is is non idle most of the
time
2) To try to enforce the 10MB/s limit, blk-throttle necessarily makes
the group oscillate around 10MB/s, which means that the group is
frequently below limit (this would not have held only if the group had
actually received much more than 10MB/s, but it is not so)
3) For each of the 4k random I/Os of the group, the time needed by the
drive to serve that I/O is already around 40-50usec.  So, since the
group is of course not constantly in service, it is very easy that,
because of throttling, the latency of most I/Os of the group goes
beyond 100usec.

But, as it is often the case for me, I might have simply misunderstood
blk-throttle parameters, and I might be just wrong here.

Thanks,
Paolo

> You can also filter these logs using:
> grep throtl trace | grep -E 'upgrade|downgrade|is_idle'
> 
> Thanks,
> Joseph

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

[vjitta]

On 2018-04-25 21:17, Laura Abbott wrote:

On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote:

From: Vijayanand Jitta 

An issue is observed where mallocs are failing due to overcommit 
failure.

The failure happens when there is high ION page pool since ION page
pool is not considered reclaimable by the overcommit calculation code.
This change considers ion pool pages as indirectly reclaimable and 
thus

accounted as available memory in the overcommit calculation.

Signed-off-by: Vijayanand Jitta 
---
  drivers/staging/android/ion/ion_page_pool.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c

index db8f614..9bc56eb 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -32,6 +32,9 @@ static void ion_page_pool_add(struct ion_page_pool 
*pool, struct page *page)

list_add_tail(&page->lru, &pool->low_items);
pool->low_count++;
}
+
+	mod_node_page_state(page_pgdat(page), 
NR_INDIRECTLY_RECLAIMABLE_BYTES,

+   (1 << (PAGE_SHIFT + pool->order)));
mutex_unlock(&pool->mutex);
  }
  @@ -50,6 +53,8 @@ static struct page *ion_page_pool_remove(struct 
ion_page_pool *pool, bool high)

}
list_del(&page->lru);
+	mod_node_page_state(page_pgdat(page), 
NR_INDIRECTLY_RECLAIMABLE_BYTES,

+   -(1 << (PAGE_SHIFT + pool->order)));
return page;
  }



I'm sure this fixes the problem but I don't think we want to
start throwing page adjustments into Ion. Why isn't this
memory already considered reclaimable by existing calculations?

Thanks,
Laura


You can refer to discussion here https://lkml.org/lkml/2018/3/5/361 
introducing
NR_INDIRECTLY_RECLAIMABLE_BYTES for the memory which is not currently 
considered

as reclaimable

Thanks,
Vijay

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

[Masami Hiramatsu]

On Thu, 26 Apr 2018 22:48:24 -0400
Steven Rostedt  wrote:

> On Fri, 27 Apr 2018 11:39:51 +0900
> Masami Hiramatsu  wrote:
> 
> > On Thu, 26 Apr 2018 21:13:51 -0400
> > Steven Rostedt  wrote:
> > 
> > > On Thu, 26 Apr 2018 17:10:03 +0900
> > > Masami Hiramatsu  wrote:
> > >   
> > > > Replace %p with appropriate pointer types (or just remove it)
> > > >  - Use %pS if possible
> > > >  - Use %px only for the function right before BUG().
> > > >  - Remove unneeded error message.  
> > > 
> > > I'm not sure "right before BUG()" is legitimate for using %px. Why not
> > > still use %pS?  
> > 
> > Since BUG() will dump all registers and stacks which includes
> > raw address information and reboot the system (means reset the
> > kaslr base offset), I thought it may not add additional damage.
> 
> BUG() has been changed to print out %pS and not the address while doing
> the stack dump. It only prints the address if it doesn't find a
> function name. For example:
> 
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc3-test+ #48
> Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
> Call Trace:
>  dump_stack+0x68/0x92
>  lockdep_rcu_suspicious+0xf7/0x100
>  rcu_read_lock+0x5f/0x61
>  __is_insn_slot_addr+0x23/0x5c
>  __kernel_text_address+0x4a/0x80
>  show_trace_log_lvl+0x157/0x296
>  ? module_assert_mutex_or_preempt+0x4f/0x51
>  show_stack+0x3d/0x3f
>  dump_stack+0x68/0x92
>  __warn+0xc2/0xdd
>  ? 0xa0026077
>  warn_slowpath_null+0x1d/0x1f
>  module_assert_mutex_or_preempt+0x4f/0x51
>  __module_address+0x2a/0xac
>  ? 0xa0026077
>  __module_text_address+0x12/0x59
>  ? 0xa0026077
>  is_module_text_address+0xe/0x16
>  __kernel_text_address+0x2b/0x80
>  ? 0xa0026077
>  unwind_get_return_address+0x50/0x5c
> 

Ah...
OK, I'll fix that.

> 
> > 
> > Anyway, for this patch we can use %pS. For the next [5/7] patch,
> > I'm not sure %pS is good for dumping a stack address...
> 
> Although it now is.

Got it.

Thank you!


-- 
Masami Hiramatsu 

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Vinod Koul]

On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
> Request IRQ with IRQF_SHARED flag. This works since the interrupt
> handler already checks if there is an actual IRQ pending and returns
> IRQ_NONE otherwise.

hmmm what are we trying to fix here? Is your device on a shared line or not?

> 
> Acked-by: Lars-Peter Clausen 
> Signed-off-by: Moritz Fischer 
> ---
> Changes from v1:
> - Added Lars' Acked-by
> - Dropped patch [1/2] and changed accordingly
> ---
>  drivers/dma/dma-axi-dmac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> index 2419fe524daa..15b2453d2647 100644
> --- a/drivers/dma/dma-axi-dmac.c
> +++ b/drivers/dma/dma-axi-dmac.c
> @@ -687,7 +687,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
>   if (ret)
>   goto err_unregister_device;
>  
> - ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, 0,
> + ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, IRQF_SHARED,
>   dev_name(&pdev->dev), dmac);
>   if (ret)
>   goto err_unregister_of;
> -- 
> 2.17.0
> 

-- 
~Vinod

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

[Michael Turquette]

Quoting Jerome Brunet (2018-02-02 04:50:28)
> On Thu, 2018-02-01 at 09:43 -0800, Stephen Boyd wrote:
> > > > > Applied to clk-protect-rate, with the exception that I did not apply
> > > > > "clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks
> > > > > qcom clk code.
> > > > > 
> > > > > Stephen, do you plan to fix up the qcom clock code so that the
> > > > > SET_RATE_GATE improvement can go in?
> > > > > 
> > > > 
> > > > I started working on it a while back. Let's see if I can finish
> > > > it off this weekend.
> > > > 
> > > 
> > > Hi Stephen,
> > > 
> > > Have you been able find something to fix the qcom code regarding this 
> > > issue ?
> > > 
> > 
> > This is what I have. I'm unhappy with a few things. First, I made
> > a spinlock for each clk, which is overkill. Most likely, just a
> > single spinlock is needed per clk-controller device. Second, I
> > haven't finished off the branch/gate part, so gating/ungating of
> > branches needs to be locked as well to prevent branches from
> > turning on while rates change. And finally, the 'branches' list is
> > duplicating a bunch of information about the child clks of an
> > RCG, so it feels like we need a core framework API to enable and
> > disable clks forcibly while remembering what is enabled/disabled
> > or at least to walk the clk tree and call some function.
> 
> Looks similar to Mike's CCR idea ;)

Giving clk provider drivers more control over the clocks that they
provide is a similar concept, but the ancient ccr series dealt almost
exclusively with set_rate and set_parent ops.

> 
> > 
> > The spinlock per clk-controller is duplicating the regmap lock we
> > already have, so we may want a regmap API to grab the lock, and
> > then another regmap API to do reads/writes without grabbing the
> > lock, and then finally release the lock with a regmap unlock API.
> 
> There is 'regsequence' for multiple write in a burst, but that's only if you 
> do
> write only ... I suppose you are more in read/update/writeback mode, so it
> probably does not help much.
> 
> Maybe we could extend regmap's regsequence, to do a sequence of
> regmap_update_bits() ?
> 
> Another possibility could be to provide your own lock/unlock ops when
> registering the regmap. With this, you might be able to supply your own 
> spinlock
> to regmap. This is already supported by regmap, would it help ?

Stephen, was there ever an update on your end? This patch has been
dangling for a while and I thought it was time to ping on it.

Regards,
Mike

> 
> > This part is mostly an optimization, but it would be nice to have
> > so that multiple writes could be done in sequence. This way, the
> > RCG code could do the special locking sequence and the branch
> > code could do the fire and forget single bit update.
>
 

Re: [PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver

[Ganapatrao Kulkarni]

On Fri, Apr 27, 2018 at 2:25 AM, Randy Dunlap  wrote:
> Hi,
>
> Just a few typo corrections...
>
> On 04/25/2018 02:00 AM, Ganapatrao Kulkarni wrote:
>> Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC.
>> The SoC has PMU support in its L3 cache controller (L3C) and in the
>> DDR4 Memory Controller (DMC).
>>
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  Documentation/perf/thunderx2-pmu.txt | 66 
>> 
>>  1 file changed, 66 insertions(+)
>>  create mode 100644 Documentation/perf/thunderx2-pmu.txt
>>
>> diff --git a/Documentation/perf/thunderx2-pmu.txt 
>> b/Documentation/perf/thunderx2-pmu.txt
>> new file mode 100644
>> index 000..9e9f535
>> --- /dev/null
>> +++ b/Documentation/perf/thunderx2-pmu.txt
>> @@ -0,0 +1,66 @@
>> +
>> +Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE)
>> +==
>> +
>> +ThunderX2 SoC PMU consists of independent system wide per Socket PMUs such
>> +as Level 3 Cache(L3C) and DDR4 Memory Controller(DMC).
>> +
>> +It has 8 independent DMC PMUs to capture performance events corresponding
>> +to 8 channels of DDR4 Memory Controller. There are 16 independent L3C PMUs
>> +to capture events corresponding to 16 tiles of L3 cache. Each PMU supports
>> +up to 4 counters.
>> +
>> +Counters are independent programmable and can be started and stopped
>
> independently

thanks, will update.
>
>> +individually. Each counter can be set to sample specific perf events.
>> +Counters are 32 bit and does not support overflow interrupt, they are
>
>do notinterrupt; they are
>
>
>> +sampled at every 2 seconds. The Counters register access are multiplexed
>> +across channels of DMC and L3C. The muxing(select channel) is done through
>> +write to a Secure register using smcc calls.
>> +
>> +PMU UNCORE (perf) driver:
>> +
>> +The thunderx2-pmu driver registers several perf PMUs for DMC and L3C 
>> devices.
>> +Each of the PMU provides description of its available events
>
> of the PMUs
>
>> +and configuration options in sysfs.
>> + see /sys/devices/uncore_
>> +
>> +S is socket id and X represents channel number.
>> +Each PMU can be used to sample up to 4 events simultaneously.
>> +
>> +The "format" directory describes format of the config (event ID).
>> +The "events" directory provides configuration templates for all
>> +supported event types that can be used with perf tool.
>> +
>> +For example, "uncore_dmc_0_0/cnt_cycles/" is an
>> +equivalent of "uncore_dmc_0_0/config=0x1/".
>> +
>> +Each perf driver also provides a "cpumask" sysfs attribute, which contains a
>> +single CPU ID of the processor which is likely to be used to handle all the
>> +PMU events. It will be the first online CPU from the NUMA node of PMU 
>> device.
>> +
>> +Example for perf tool use:
>> +
>> +perf stat -a -e \
>> +uncore_dmc_0_0/cnt_cycles/,\
>> +uncore_dmc_0_1/cnt_cycles/,\
>> +uncore_dmc_0_2/cnt_cycles/,\
>> +uncore_dmc_0_3/cnt_cycles/,\
>> +uncore_dmc_0_4/cnt_cycles/,\
>> +uncore_dmc_0_5/cnt_cycles/,\
>> +uncore_dmc_0_6/cnt_cycles/,\
>> +uncore_dmc_0_7/cnt_cycles/ sleep 1
>> +
>> +perf stat -a -e \
>> +uncore_dmc_0_0/cancelled_read_txns/,\
>> +uncore_dmc_0_0/cnt_cycles/,\
>> +uncore_dmc_0_0/consumed_read_txns/,\
>> +uncore_dmc_0_0/data_transfers/ sleep 1
>> +
>> +perf stat -a -e \
>> +uncore_l3c_0_0/l3_retry/,\
>> +uncore_l3c_0_0/read_hit/,\
>> +uncore_l3c_0_0/read_request/,\
>> +uncore_l3c_0_0/inv_request/ sleep 1
>> +
>> +The driver does not support sampling, therefore "perf record" will
>> +not work. Per-task (without "-a") perf sessions are not supported.
>>
>
>
> --
> ~Randy

thanks
Ganapat

Re: [PATCH] arm64: dts: uniphier: stabilize ethernet of LD20 reference boar

[Masahiro Yamada]

2018-04-27 13:25 GMT+09:00 Masahiro Yamada :
> Currently, the ethernet RGMII mode on the LD20 reference board is
> unstable.
>
> The default drive-strength of ethernet TX pins is too strong because
> there is no dumping resistor on the TX lines on the board.
>
> Weaken the drive-strength to make the ethernet more stable.
>
> Signed-off-by: Masahiro Yamada 
> ---


To myself:

Fix the typo in the subject

  boar  ->  board




-- 
Best Regards
Masahiro Yamada

[PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on

[Joel Fernandes]

In recent tests with IRQ on/off tracepoints, a large performance
overhead ~10% is noticed when running hackbench. This is root caused to
calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the
tracepoint code. Following a long discussion on the list [1] about this,
we concluded that srcu is a better alternative for use during rcu idle.
Although it does involve extra barriers, its lighter than the sched-rcu
version which has to do additional RCU calls to notify RCU idle about
entry into RCU sections.

In this patch, we change the underlying implementation of the
trace_*_rcuidle API to use SRCU. This has shown to improve performance
alot for the high frequency irq enable/disable tracepoints.

In the future, we can add a new may_sleep API which can use this
infrastructure for callbacks that actually can sleep which will support
Mathieu's usecase of blocking probes.

Test: Tested idle and preempt/irq tracepoints.

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

Cc: Steven Rostedt 
Cc: Peter Zilstra 
Cc: Ingo Molnar 
Cc: Mathieu Desnoyers 
Cc: Tom Zanussi 
Cc: Namhyung Kim 
Cc: Thomas Glexiner 
Cc: Boqun Feng 
Cc: Paul McKenney 
Cc: Frederic Weisbecker 
Cc: Randy Dunlap 
Cc: Masami Hiramatsu 
Cc: Fenguang Wu 
Cc: Baohong Liu 
Cc: Vedang Patel 
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes 
---
 include/linux/tracepoint.h | 37 +
 kernel/tracepoint.c| 10 +-
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index c94f466d57ef..a1c1987de423 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,8 @@ struct trace_eval_map {
 
 #define TRACEPOINT_DEFAULT_PRIO10
 
+extern struct srcu_struct tracepoint_srcu;
+
 extern int
 tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
 extern int
@@ -77,6 +80,7 @@ int unregister_tracepoint_module_notifier(struct 
notifier_block *nb)
  */
 static inline void tracepoint_synchronize_unregister(void)
 {
+   synchronize_srcu(&tracepoint_srcu);
synchronize_sched();
 }
 
@@ -129,18 +133,26 @@ extern void syscall_unregfunc(void);
  * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
  * "void *data", where as the DECLARE_TRACE() will pass in "void *data, proto".
  */
-#define __DO_TRACE(tp, proto, args, cond, rcucheck)\
+#define __DO_TRACE(tp, proto, args, cond, preempt_on)  \
do {\
struct tracepoint_func *it_func_ptr;\
void *it_func;  \
void *__data;   \
+   int __maybe_unused idx = 0; \
\
if (!(cond))\
return; \
-   if (rcucheck)   \
-   rcu_irq_enter_irqson(); \
-   rcu_read_lock_sched_notrace();  \
-   it_func_ptr = rcu_dereference_sched((tp)->funcs);   \
+   if (preempt_on) {   \
+   WARN_ON_ONCE(in_nmi()); /* no srcu from nmi */  \
+   idx = srcu_read_lock(&tracepoint_srcu); \
+   it_func_ptr = srcu_dereference((tp)->funcs, \
+   &tracepoint_srcu);  \
+   } else {\
+   rcu_read_lock_sched_notrace();  \
+   it_func_ptr =   \
+   rcu_dereference_sched((tp)->funcs); \
+   }   \
+   \
if (it_func_ptr) {  \
do {\
it_func = (it_func_ptr)->func;  \
@@ -148,12 +160,21 @@ extern void syscall_unregfunc(void);
((void(*)(proto))(it_func))(args);  \
} while ((++it_func_ptr)->func);\
}   \
-   rcu_read_unlock_sched_notrace();\
-   if (rcucheck)   \
-   rcu_irq_exit_irqson();   

[PATCH] arm64: dts: uniphier: stabilize ethernet of LD20 reference boar

[Masahiro Yamada]

Currently, the ethernet RGMII mode on the LD20 reference board is
unstable.

The default drive-strength of ethernet TX pins is too strong because
there is no dumping resistor on the TX lines on the board.

Weaken the drive-strength to make the ethernet more stable.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 2c1a92f..440c2e6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -67,3 +67,11 @@
reg = <0>;
};
 };
+
+&pinctrl_ether_rgmii {
+   tx {
+   pins = "RGMII_TXCLK", "RGMII_TXD0", "RGMII_TXD1",
+  "RGMII_TXD2", "RGMII_TXD3", "RGMII_TXCTL";
+   drive-strength = <9>;
+   };
+};
-- 
2.7.4

Re: [RFC v3 0/5] virtio: support packed ring

[Michael S. Tsirkin]

On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote:
> 
> 
> On 2018年04月25日 13:15, Tiwei Bie wrote:
> > Hello everyone,
> > 
> > This RFC implements packed ring support in virtio driver.
> > 
> > Some simple functional tests have been done with Jason's
> > packed ring implementation in vhost:
> > 
> > https://lkml.org/lkml/2018/4/23/12
> > 
> > Both of ping and netperf worked as expected (with EVENT_IDX
> > disabled). But there are below known issues:
> > 
> > 1. Reloading the guest driver will break the Tx/Rx;
> 
> Will have a look at this issue.
> 
> > 2. Zeroing the flags when detaching a used desc will
> > break the guest -> host path.
> 
> I still think zeroing flags is unnecessary or even a bug. At host, I track
> last observed avail wrap counter and detect avail like (what is suggested in
> the example code in the spec):
> 
> static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
> {
>    bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);
> 
>    return avail == vq->avail_wrap_counter;
> }
> 
> So zeroing wrap can not work with this obviously.
> 
> Thanks

I agree. I think what one should do is flip the available bit.

> > 
> > Some simple functional tests have also been done with
> > Wei's packed ring implementation in QEMU:
> > 
> > http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00342.html
> > 
> > Both of ping and netperf worked as expected (with EVENT_IDX
> > disabled). Reloading the guest driver also worked as expected.
> > 
> > TODO:
> > - Refinements (for code and commit log) and bug fixes;
> > - Discuss/fix/test EVENT_IDX support;
> > - Test devices other than net;
> > 
> > RFC v2 -> RFC v3:
> > - Split into small patches (Jason);
> > - Add helper virtqueue_use_indirect() (Jason);
> > - Just set id for the last descriptor of a list (Jason);
> > - Calculate the prev in virtqueue_add_packed() (Jason);
> > - Fix/improve desc suppression code (Jason/MST);
> > - Refine the code layout for XXX_split/packed and wrappers (MST);
> > - Fix the comments and API in uapi (MST);
> > - Remove the BUG_ON() for indirect (Jason);
> > - Some other refinements and bug fixes;
> > 
> > RFC v1 -> RFC v2:
> > - Add indirect descriptor support - compile test only;
> > - Add event suppression supprt - compile test only;
> > - Move vring_packed_init() out of uapi (Jason, MST);
> > - Merge two loops into one in virtqueue_add_packed() (Jason);
> > - Split vring_unmap_one() for packed ring and split ring (Jason);
> > - Avoid using '%' operator (Jason);
> > - Rename free_head -> next_avail_idx (Jason);
> > - Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
> > - Some other refinements and bug fixes;
> > 
> > Thanks!
> > 
> > Tiwei Bie (5):
> >virtio: add packed ring definitions
> >virtio_ring: support creating packed ring
> >virtio_ring: add packed ring support
> >virtio_ring: add event idx support in packed ring
> >virtio_ring: enable packed ring
> > 
> >   drivers/virtio/virtio_ring.c   | 1271 
> > 
> >   include/linux/virtio_ring.h|8 +-
> >   include/uapi/linux/virtio_config.h |   12 +-
> >   include/uapi/linux/virtio_ring.h   |   36 +
> >   4 files changed, 1049 insertions(+), 278 deletions(-)
> > 

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

[Sean Wang]

On Thu, 2018-04-26 at 11:47 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> >>> This adds a driver for the MediaTek serial protocol based on H4 protocol,
> >>> which can enable the built-in Bluetooth device inside MT7622 SoC.
> >>> 
> >>> Signed-off-by: Sean Wang 
> >>> ---

[... snip ...]

> >>> +
> >>> + /* Start to build a WMT header and its actual payload. */
> >>> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> >>> + whdr->dir = 1;
> >>> + whdr->op = opcode;
> >>> + whdr->dlen = cpu_to_le16(plen + 1);
> >>> + whdr->flag = flag;
> >>> + skb_put_data(skb, param, plen);
> >>> +
> >>> + mtk_enqueue(hu, skb);
> >>> + hci_uart_tx_wakeup(hu);
> >>> +
> >>> + /*
> >>> +  * Waiting a WMT event response, while we must take care in case of
> >>> +  * failures for the wait.
> >>> +  */
> >>> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> >>> +
> >>> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> >>> +}
> >> 
> >> All in all I am not convinced that this is super clean. I get that we need 
> >> something special for having this in the ACL data packets, but for the 
> >> standard HCI command I prefer that __hci_cmd_sync is used. I addition, it 
> >> seems that patch download is the only special case and that happens before 
> >> at the setup stage. So we could make things special for that. I need to 
> >> understand this a bit better. Can I get a btmon -w trace.log file from the 
> >> whole init procedure.
> >> 
> >> 
> > 
> > I can try to use __hci_cmd_sync to send those chip-specific hci commands
> > which only can be recognized by the chip, but no meaningful to bluez
> > core.
> > 
> > Is btmon able to capture these cmd/evt between driver and device?
> > 
> > my question's caused by that mtk_wmt_cmd_sync and its events only happen
> > between driver and device,  it doesn't go to core.
> 
> for Intel, Broadcom, Qualcomm, Realtek etc. we use __hci_cmd_sync() in the 
> ->setup() callback and it will show up in btmon. For at least Intel and 
> Broadcom, btmon will decode them as well. You can hint the manufacturer id 
> out of band it will be told to btmon. And that is also how I want it. If it 
> is using HCI as transport, I want it to go through the Bluetooth core.
> 

understood. I will allow chip-specific HCI cmd/evt to go to bluetooth
core.

> >>> +
> >>> +static int mtk_setup_fw(struct hci_uart *hu)
> >>> +{
> >>> + struct mtk_bt_dev *btdev = hu->priv;
> >>> + const struct firmware *fw;
> >>> + struct device *dev;
> >>> + const char *fwname;
> >>> + const u8 *fw_ptr;
> >>> + size_t fw_size;
> >>> + int err, dlen;
> >>> + u8 flag;
> >>> +
> >>> + dev = &hu->serdev->dev;
> >>> + fwname = FIRMWARE_MT7622;
> >>> +
> >>> + init_completion(&btdev->wmt_cmd);
> >>> +
> >>> + err = request_firmware(&fw, fwname, dev);
> >>> + if (err < 0) {
> >>> + dev_err(dev, "%s: Failed to load firmware file (%d)",
> >>> + hu->hdev->name, err);
> >>> + return err;
> >>> + }
> >>> +
> >>> + fw_ptr = fw->data;
> >>> + fw_size = fw->size;
> >>> +
> >>> + /* The size of a patch header at least has 30 bytes. */
> >>> + if (fw_size < 30)
> >>> + return -EINVAL;
> >>> +
> >>> + while (fw_size > 0) {
> >>> + dlen = min_t(int, 1000, fw_size);
> >>> +
> >>> + /* Tell deivice the position in sequence. */
> >>> + flag = (fw_size - dlen <= 0) ? 3 :
> >>> +(fw_size < fw->size) ? 2 : 1;
> >>> +
> >>> + err = mtk_wmt_cmd_sync(hu, MTK_WMT_PATCH_DWNLD, flag,
> >>> +dlen, fw_ptr);
> >>> + if (err < 0)
> >>> + break;
> >>> +
> >>> + fw_size -= dlen;
> >>> + fw_ptr += dlen;
> >>> + }
> >>> +
> >>> + release_firmware(fw);
> >>> +
> >>> + return err;
> >>> +}
> >>> +
> >>> +static int mtk_open(struct hci_uart *hu)
> >>> +{
> >>> + struct mtk_bt_dev *btdev = hu->priv;
> >>> + struct device *dev;
> >>> + int err = 0;
> >>> +
> >>> + dev = &hu->serdev->dev;
> >>> +
> >>> + serdev_device_open(hu->serdev);
> >>> + skb_queue_head_init(&btdev->txq);
> >>> +
> >>> + /* Setup the usage of H4. */
> >>> + hu->alignment = 1;
> >>> + hu->padding = 0;
> >>> + mtk_stp_reset(btdev->sp);
> >>> +
> >>> + /* Enable the power domain and clock the device requires */
> >>> + pm_runtime_enable(dev);
> >>> + err = pm_runtime_get_sync(dev);
> >>> + if (err < 0) {
> >>> + pm_runtime_disable(dev);
> >>> + return err;
> >>> + }
> >>> +
> >>> + err = clk_prepare_enable(btdev->clk);
> >>> + if (err < 0) {
> >>> + pm_runtime_put_sync(dev);
> >>> + pm_runtime_disable(dev);
> >>> + }
> >>> +
> >>> + return err;
> >>> +}
> >>> +
> >>> +static int mtk_close(struct hci_uart *hu)
> >>> +{
> >>> + struct mtk_bt_dev *btdev = hu->priv;
> >>> + struct device *dev = &hu->serdev->dev;
> >>> + u8 param = 0x0;
> >>> +
> >>> + skb_queue_purge(&btdev->txq);
> >>> + kfree_skb(btdev->rx_skb);
> >>> +
> >>> + /* Disable the device. */
> >>> + mtk_wmt_cmd_sync(hu, MTK_WMT_FUNC_CTRL, 0x0, sizeo

Re: random: GFP_KERNEL from irq context

[Jens Axboe]

On 4/26/18 3:03 PM, Theodore Y. Ts'o wrote:
> On Thu, Apr 26, 2018 at 10:28:13AM -0600, Jens Axboe wrote:
>> during boot. We end up doing the numa_crng_init() from interrupt context, 
>> which
>> makes things unhappy since you do GFP_KERNEL | __GFP_NOFAIL allocations from
>> there.
> 
> I've already sent a pull request to Linux to fix this; see the
> random.git tree.
> 
> Apologies for not noticing this earlier.  My test environment had
> virtio-rng enabled by default, and while I did test the CONFIG_NUMA
> case, the call to add randomness doesn't happen from interrupt context
> with virtio-rng so I missed it in my testing.

OK, all good, just wanted to ensure it was known.

-- 
Jens Axboe

[PATCH] softirq: reorder trace_softirqs_on to prevent lockdep splat

[Joel Fernandes]

I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and
CONFIG_PREEMPTIRQ_EVENTS=y.

$ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable
---
[   26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled)
[   26.112636] WARNING: CPU: 0 PID: 118 at kernel/locking/lockdep.c:3854
[...]
[   26.144229] Call Trace:
[   26.144926]  
[   26.145506]  lock_acquire+0x55/0x1b0
[   26.146499]  ? __do_softirq+0x46f/0x4d9
[   26.147571]  ? __do_softirq+0x46f/0x4d9
[   26.148646]  trace_preempt_on+0x8f/0x240
[   26.149744]  ? trace_preempt_on+0x4d/0x240
[   26.150862]  ? __do_softirq+0x46f/0x4d9
[   26.151930]  preempt_count_sub+0x18a/0x1a0
[   26.152985]  __do_softirq+0x46f/0x4d9
[   26.153937]  irq_exit+0x68/0xe0
[   26.154755]  smp_apic_timer_interrupt+0x271/0x280
[   26.156056]  apic_timer_interrupt+0xf/0x20
[   26.157105]  

The problem is the softirqs annotation in lockdep goes out of sync with
the reality of the world that softirq is still off. This causes a
lockdep splat because the preempt_count_sub can call into a preemptoff
tracer or the trace events code, which inturn can call into lockdep
*before* softirqs are really turned back on, which can cause a softirqs
invalid annotation splat in lockdep.

The same issue was fixed in local_bh_disable_ip which has a comment so:
/*
 * The preempt tracer hooks into preempt_count_add and will break
 * lockdep because it calls back into lockdep after SOFTIRQ_OFFSET
 * is set and before current->softirq_enabled is cleared.
 * We must manually increment preempt_count here and manually
 * call the trace_preempt_off later.
 */

I have done a similar change to the local_bh_enable path to fix it.

Cc: Steven Rostedt 
Cc: Peter Zilstra 
Cc: Ingo Molnar 
Cc: Mathieu Desnoyers 
Cc: Tom Zanussi 
Cc: Namhyung Kim 
Cc: Thomas Glexiner 
Cc: Boqun Feng 
Cc: Paul McKenney 
Cc: Frederic Weisbecker 
Cc: Randy Dunlap 
Cc: Masami Hiramatsu 
Cc: Fenguang Wu 
Cc: Baohong Liu 
Cc: Vedang Patel 
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes 
---
 kernel/softirq.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 177de3640c78..8a040bcaa033 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -139,9 +139,13 @@ static void __local_bh_enable(unsigned int cnt)
 {
lockdep_assert_irqs_disabled();
 
+   if (preempt_count() == cnt)
+   trace_preempt_on(CALLER_ADDR0, get_lock_parent_ip());
+
if (softirq_count() == (cnt & SOFTIRQ_MASK))
trace_softirqs_on(_RET_IP_);
-   preempt_count_sub(cnt);
+
+   __preempt_count_sub(cnt);
 }
 
 /*
-- 
2.17.0.441.gb46fe60e1d-goog

Re: [RFC v3 0/5] virtio: support packed ring

[Jason Wang]

On 2018年04月25日 13:15, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support in virtio driver.

Some simple functional tests have been done with Jason's
packed ring implementation in vhost:

https://lkml.org/lkml/2018/4/23/12

Both of ping and netperf worked as expected (with EVENT_IDX
disabled). But there are below known issues:

1. Reloading the guest driver will break the Tx/Rx;


Will have a look at this issue.


2. Zeroing the flags when detaching a used desc will
break the guest -> host path.


I still think zeroing flags is unnecessary or even a bug. At host, I 
track last observed avail wrap counter and detect avail like (what is 
suggested in the example code in the spec):


static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
{
   bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);

   return avail == vq->avail_wrap_counter;
}

So zeroing wrap can not work with this obviously.

Thanks



Some simple functional tests have also been done with
Wei's packed ring implementation in QEMU:

http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00342.html

Both of ping and netperf worked as expected (with EVENT_IDX
disabled). Reloading the guest driver also worked as expected.

TODO:
- Refinements (for code and commit log) and bug fixes;
- Discuss/fix/test EVENT_IDX support;
- Test devices other than net;

RFC v2 -> RFC v3:
- Split into small patches (Jason);
- Add helper virtqueue_use_indirect() (Jason);
- Just set id for the last descriptor of a list (Jason);
- Calculate the prev in virtqueue_add_packed() (Jason);
- Fix/improve desc suppression code (Jason/MST);
- Refine the code layout for XXX_split/packed and wrappers (MST);
- Fix the comments and API in uapi (MST);
- Remove the BUG_ON() for indirect (Jason);
- Some other refinements and bug fixes;

RFC v1 -> RFC v2:
- Add indirect descriptor support - compile test only;
- Add event suppression supprt - compile test only;
- Move vring_packed_init() out of uapi (Jason, MST);
- Merge two loops into one in virtqueue_add_packed() (Jason);
- Split vring_unmap_one() for packed ring and split ring (Jason);
- Avoid using '%' operator (Jason);
- Rename free_head -> next_avail_idx (Jason);
- Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
- Some other refinements and bug fixes;

Thanks!

Tiwei Bie (5):
   virtio: add packed ring definitions
   virtio_ring: support creating packed ring
   virtio_ring: add packed ring support
   virtio_ring: add event idx support in packed ring
   virtio_ring: enable packed ring

  drivers/virtio/virtio_ring.c   | 1271 
  include/linux/virtio_ring.h|8 +-
  include/uapi/linux/virtio_config.h |   12 +-
  include/uapi/linux/virtio_ring.h   |   36 +
  4 files changed, 1049 insertions(+), 278 deletions(-)

Re: [PATCH] net: phy: marvell: clear wol event before setting it

[Bhadram Varka]

Hi Andrew/Jisheng,

On 4/26/2018 6:10 PM, Andrew Lunn wrote:

hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel
requires WOL should be "stick".

I see two different cases:

Suspend/resume: The WoL state in the kernel is probably kept across
such a cycle. If so, you would expect another suspend/resume to also
work, without needs to reconfigure it.
Trying this scenario (suspend/resume) from my side. In this case WoL 
should be enabled in the HW. For Marvell PHY to generate WoL interrupt 
we need to clear WoL status.
Above mentioned change required to make this happen. Please share your 
thoughts on this.


Boot from powered off: If the interrupt just enables the power supply,
it is possible to wake up after a shutdown. There is no state kept, so
WoL will be disabled in the kernel. So WoL should also be disabled in
the hardware.

 Andrew

Re: testing io.low limit for blk-throttle

[Joseph Qi]

Hi Paolo,

On 18/4/27 01:27, Paolo Valente wrote:
> 
> 
>> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi  ha 
>> scritto:
>>
>> Hi Paolo,
>>
> 
> Hi Joseph
> 
>> ...
>> Could you run blktrace as well when testing your case? There are several
>> throtl traces to help analyze whether it is caused by frequently
>> upgrade/downgrade.
> 
> Certainly.  You can find a trace attached.  Unfortunately, I'm not
> familiar with the internals of blk-throttle and low limit, so, if you
> want me to analyze the trace, give me some hints on what I have to
> look for.  Otherwise, I'll be happy to learn from your analysis.
> 

I've taken a glance at your blktrace attached. It is only upgrade at first and
then downgrade (just adjust limit, not to LIMIT_LOW) frequently.
But I don't know why it always thinks throttle group is not idle.

For example:
fio-2336  [004] d...   428.458249:   8,16   m   N throtl avg_idle=90, 
idle_threshold=1000, bad_bio=10, total_bio=84, is_idle=0, scale=9
fio-2336  [004] d...   428.458251:   8,16   m   N throtl downgrade, scale 4

In throtl_tg_is_idle():
is_idle = ... ||
(tg->latency_target && tg->bio_cnt &&
 tg->bad_bio_cnt * 5 < tg->bio_cnt);

It should be idle and allow run more bandwidth. But here the result shows not
idle (is_idle=0). I have to do more investigation to figure it out why. 

You can also filter these logs using:
grep throtl trace | grep -E 'upgrade|downgrade|is_idle'

Thanks,
Joseph

Re: [PATCH] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

[Rob Herring]

On Thu, Apr 19, 2018 at 04:00:32PM -0700, Stephen Boyd wrote:
> Add the compatibles and PMIC ids for the pm8005, pm8998, and pmi8998
> PMICS found on MSM8998 and SDM845 based platforms.
> 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 3 +++
>  drivers/mfd/qcom-spmi-pmic.c | 6 ++
>  2 files changed, 9 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH] reset: uniphier: add LD11/LD20 stream demux system reset control

[Masahiro Yamada]

2018-04-27 9:41 GMT+09:00 Katsuhiro Suzuki :
> Add reset lines for MPEG2 transport stream I/O and demux system (HSC)
> on UniPhier LD11/LD20 SoCs.
>
> Signed-off-by: Katsuhiro Suzuki 
> ---

Acked-by: Masahiro Yamada 




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] clk: uniphier: add LD11/LD20 stream demux system clock

[Masahiro Yamada]

2018-04-27 9:40 GMT+09:00 Katsuhiro Suzuki :
> Add clock for MPEG2 transport stream I/O and demux system (HSC) on
> UniPhier LD11/LD20 SoCs.
>
> Signed-off-by: Katsuhiro Suzuki 
> ---



Acked-by: Masahiro Yamada 




-- 
Best Regards
Masahiro Yamada

[PATCH 1/2] hwmon: (k10temp) Fix reading critical temperature register

[Guenter Roeck]

The HTC (Hardware Temperature Control) register has moved
for recent chips.

Signed-off-by: Guenter Roeck 
---
Compile tested only.

 drivers/hwmon/k10temp.c | 37 +
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index d2cc55e21374..b06bb1f90853 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -63,10 +63,12 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
 #define  NB_CAP_HTC0x0400
 
 /*
- * For F15h M60h, functionality of REG_REPORTED_TEMPERATURE
- * has been moved to D0F0xBC_xD820_0CA4 [Reported Temperature
- * Control]
+ * For F15h M60h and M70h, REG_HARDWARE_THERMAL_CONTROL
+ * and REG_REPORTED_TEMPERATURE have been moved to
+ * D0F0xBC_xD820_0C64 [Hardware Temperature Control]
+ * D0F0xBC_xD820_0CA4 [Reported Temperature Control]
  */
+#define F15H_M60H_HARDWARE_TEMP_CTRL_OFFSET0xd8200c64
 #define F15H_M60H_REPORTED_TEMP_CTRL_OFFSET0xd8200ca4
 
 /* F17h M01h Access througn SMN */
@@ -74,6 +76,7 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
 
 struct k10temp_data {
struct pci_dev *pdev;
+   void (*read_htcreg)(struct pci_dev *pdev, u32 *regval);
void (*read_tempreg)(struct pci_dev *pdev, u32 *regval);
int temp_offset;
u32 temp_adjust_mask;
@@ -98,6 +101,11 @@ static const struct tctl_offset tctl_offset_table[] = {
{ 0x17, "AMD Ryzen Threadripper 1910", 1 },
 };
 
+static void read_htcreg_pci(struct pci_dev *pdev, u32 *regval)
+{
+   pci_read_config_dword(pdev, REG_HARDWARE_THERMAL_CONTROL, regval);
+}
+
 static void read_tempreg_pci(struct pci_dev *pdev, u32 *regval)
 {
pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, regval);
@@ -114,6 +122,12 @@ static void amd_nb_index_read(struct pci_dev *pdev, 
unsigned int devfn,
mutex_unlock(&nb_smu_ind_mutex);
 }
 
+static void read_htcreg_nb_f15(struct pci_dev *pdev, u32 *regval)
+{
+   amd_nb_index_read(pdev, PCI_DEVFN(0, 0), 0xb8,
+ F15H_M60H_HARDWARE_TEMP_CTRL_OFFSET, regval);
+}
+
 static void read_tempreg_nb_f15(struct pci_dev *pdev, u32 *regval)
 {
amd_nb_index_read(pdev, PCI_DEVFN(0, 0), 0xb8,
@@ -181,13 +195,18 @@ static umode_t k10temp_is_visible(struct kobject *kobj,
struct pci_dev *pdev = data->pdev;
 
if (index >= 2) {
-   u32 reg_caps, reg_htc;
+   u32 reg;
+
+   if (!data->read_htcreg)
+   return 0;
 
pci_read_config_dword(pdev, REG_NORTHBRIDGE_CAPABILITIES,
- ®_caps);
-   pci_read_config_dword(pdev, REG_HARDWARE_THERMAL_CONTROL,
- ®_htc);
-   if (!(reg_caps & NB_CAP_HTC) || !(reg_htc & HTC_ENABLE))
+ ®);
+   if (!(reg & NB_CAP_HTC))
+   return 0;
+
+   data->read_htcreg(data->pdev, ®);
+   if (!(reg & HTC_ENABLE))
return 0;
}
return attr->mode;
@@ -268,11 +287,13 @@ static int k10temp_probe(struct pci_dev *pdev,
 
if (boot_cpu_data.x86 == 0x15 && (boot_cpu_data.x86_model == 0x60 ||
  boot_cpu_data.x86_model == 0x70)) {
+   data->read_htcreg = read_htcreg_nb_f15;
data->read_tempreg = read_tempreg_nb_f15;
} else if (boot_cpu_data.x86 == 0x17) {
data->temp_adjust_mask = 0x8;
data->read_tempreg = read_tempreg_nb_f17;
} else {
+   data->read_htcreg = read_htcreg_pci;
data->read_tempreg = read_tempreg_pci;
}
 
-- 
2.7.4

[PATCH 2/2] hwmon: (k10temp) Display both Tctl and Tdie

[Guenter Roeck]

On some AMD CPUs, there is a different between the die temperature
(Tdie) and the reported temperature (Tctl). Tdie is the real measured
temperature, and Tctl is used for fan control. Lets report both for
affected CPUs.

Signed-off-by: Guenter Roeck 
---
 drivers/hwmon/k10temp.c | 55 ++---
 1 file changed, 48 insertions(+), 7 deletions(-)

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index b06bb1f90853..1135b8f1ad0f 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -80,6 +80,7 @@ struct k10temp_data {
void (*read_tempreg)(struct pci_dev *pdev, u32 *regval);
int temp_offset;
u32 temp_adjust_mask;
+   bool show_tdie;
 };
 
 struct tctl_offset {
@@ -140,17 +141,24 @@ static void read_tempreg_nb_f17(struct pci_dev *pdev, u32 
*regval)
  F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, regval);
 }
 
-static ssize_t temp1_input_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+unsigned int get_raw_temp(struct k10temp_data *data)
 {
-   struct k10temp_data *data = dev_get_drvdata(dev);
-   u32 regval;
unsigned int temp;
+   u32 regval;
 
data->read_tempreg(data->pdev, ®val);
temp = (regval >> 21) * 125;
if (regval & data->temp_adjust_mask)
temp -= 49000;
+   return temp;
+}
+
+static ssize_t temp1_input_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct k10temp_data *data = dev_get_drvdata(dev);
+   unsigned int temp = get_raw_temp(data);
+
if (temp > data->temp_offset)
temp -= data->temp_offset;
else
@@ -159,6 +167,23 @@ static ssize_t temp1_input_show(struct device *dev,
return sprintf(buf, "%u\n", temp);
 }
 
+static ssize_t temp2_input_show(struct device *dev,
+   struct device_attribute *devattr, char *buf)
+{
+   struct k10temp_data *data = dev_get_drvdata(dev);
+   unsigned int temp = get_raw_temp(data);
+
+   return sprintf(buf, "%u\n", temp);
+}
+
+static ssize_t temp_label_show(struct device *dev,
+  struct device_attribute *devattr, char *buf)
+{
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+
+   return sprintf(buf, "%s\n", attr->index ? "Tctl" : "Tdie");
+}
+
 static ssize_t temp1_max_show(struct device *dev,
  struct device_attribute *attr, char *buf)
 {
@@ -187,16 +212,23 @@ static DEVICE_ATTR_RO(temp1_max);
 static SENSOR_DEVICE_ATTR(temp1_crit, S_IRUGO, show_temp_crit, NULL, 0);
 static SENSOR_DEVICE_ATTR(temp1_crit_hyst, S_IRUGO, show_temp_crit, NULL, 1);
 
+static SENSOR_DEVICE_ATTR(temp1_label, 0444, temp_label_show, NULL, 0);
+static DEVICE_ATTR_RO(temp2_input);
+static SENSOR_DEVICE_ATTR(temp2_label, 0444, temp_label_show, NULL, 1);
+
 static umode_t k10temp_is_visible(struct kobject *kobj,
  struct attribute *attr, int index)
 {
struct device *dev = container_of(kobj, struct device, kobj);
struct k10temp_data *data = dev_get_drvdata(dev);
struct pci_dev *pdev = data->pdev;
+   u32 reg;
 
-   if (index >= 2) {
-   u32 reg;
-
+   switch (index) {
+   case 0 ... 1:   /* temp1_input, temp1_max */
+   default:
+   break;
+   case 2 ... 3:   /* temp1_crit, temp1_crit_hyst */
if (!data->read_htcreg)
return 0;
 
@@ -208,6 +240,11 @@ static umode_t k10temp_is_visible(struct kobject *kobj,
data->read_htcreg(data->pdev, ®);
if (!(reg & HTC_ENABLE))
return 0;
+   break;
+   case 4 ... 6:   /* temp1_label, temp2_input, temp2_label */
+   if (!data->show_tdie)
+   return 0;
+   break;
}
return attr->mode;
 }
@@ -217,6 +254,9 @@ static struct attribute *k10temp_attrs[] = {
&dev_attr_temp1_max.attr,
&sensor_dev_attr_temp1_crit.dev_attr.attr,
&sensor_dev_attr_temp1_crit_hyst.dev_attr.attr,
+   &sensor_dev_attr_temp1_label.dev_attr.attr,
+   &dev_attr_temp2_input.attr,
+   &sensor_dev_attr_temp2_label.dev_attr.attr,
NULL
 };
 
@@ -292,6 +332,7 @@ static int k10temp_probe(struct pci_dev *pdev,
} else if (boot_cpu_data.x86 == 0x17) {
data->temp_adjust_mask = 0x8;
data->read_tempreg = read_tempreg_nb_f17;
+   data->show_tdie = true;
} else {
data->read_htcreg = read_htcreg_pci;
data->read_tempreg = read_tempreg_pci;
-- 
2.7.4

Re: [PATCH v2 1/2] pinctrl: uniphier: add LD20 MPEG2-TS I/O pin-mux settings

[Masahiro Yamada]

2018-04-27 10:49 GMT+09:00 Katsuhiro Suzuki :
> The MPEG2-TS input/output core both accepts serial TS and parallel TS.
>
> The serial TS interface uses following pins:
>   hscin0_s : HS0DOUT[0-3]
>   hscin1_s : HS0DOUT[4-7]
>   hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0
>   hscin3_s : HS1DIN[2-5]
>   hscout0_s: HS0DOUT[0-3]
>   hscout1_s: HS0DOUT[4-7]
>
> And the parallel TS interface uses following pins:
>   hscin0_p : HS0BCLKIN, HS0SYNCIN, HS0VALIN, HS0DIN[0-7]
>   hscin1_p : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN[0-7]
>   hscout0_p: HS0BCLKOUT, HS0SYNCOUT, HS0VALOUT, HS0DOUT[0-7]
>
> Signed-off-by: Katsuhiro Suzuki 
>
> ---
>
> Changes in v2:
>
>   - Fix indent
>   - Sort alphabetically
>   - Fix wrong grouping
> - Fix hsc'out'0_ci -> hsc'in'0_ci of hscin0 group
> - Fix hscin'0'_s -> hscin'1'_s of hscin1 group


This version looks good to me.

Acked-by: Masahiro Yamada 




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 2/2] pinctrl: uniphier: add LD11 MPEG2-TS I/O pin-mux settings

[Masahiro Yamada]

2018-04-27 10:49 GMT+09:00 Katsuhiro Suzuki :
> The MPEG2-TS input/output core both accepts serial TS and parallel TS.
>
> The serial TS interface uses following pins:
>   hscin0_s : HS0DOUT[0-3]
>   hscin1_s : HS0DOUT[4-7]
>   hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0
>   hscout0_s: HS0DOUT[0-3]
>   hscout1_s: HS0DOUT[4-7]
>
> And the parallel TS interface uses following pins:
>   hscin0_p : HS0BCLKIN, HS0SYNCIN, HS0VALIN, HS0DIN[0-7]
>   hscin1_p : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN[0-7]
>   hscout0_p: HS0BCLKOUT, HS0SYNCOUT, HS0VALOUT, HS0DOUT[0-7]
>
> Signed-off-by: Katsuhiro Suzuki 
>
> ---
>
> Changes in v2:
>
>   - Fix indent
>   - Sort alphabetically
>   - Fix wrong grouping
> - Fix hsc'out'0_ci -> hsc'in'0_ci of hscin0 group
> - Fix hscin'0'_s -> hscin'1'_s of hscin1 group


This version looks good to me.

Acked-by: Masahiro Yamada 



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/2] net: stmmac: dwmac-meson: extend phy mode setting

[Yixun Lan]

Hi Jerome
On 04/26/18 16:47, Jerome Brunet wrote:
> On Thu, 2018-04-26 at 16:05 +, Yixun Lan wrote:
>>   In the Meson-AXG SoC, the phy mode setting of PRG_ETH0 in the glue layer
>> is extended from bit[0] to bit[2:0].
>>   There is no problem if we configure it to the RGMII 1000M PHY mode,
>> since the register setting is coincidentally compatible with previous one,
>> but for the RMII 100M PHY mode, the configuration need to be changed to
>> value - b100.
>>   This patch was verified with a RTL8201F 100M ethernet PHY.
>>
>> Signed-off-by: Yixun Lan 
>> ---
>>  .../ethernet/stmicro/stmmac/dwmac-meson8b.c   | 95 ---
>>  1 file changed, 84 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c 
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> index 7cb794094a70..e3688b6dd87c 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -29,6 +30,10 @@
>>  
>>  #define PRG_ETH0_RGMII_MODE BIT(0)
>>  
>> +#define PRG_ETH0_EXT_PHY_MODE_MASK  GENMASK(2, 0)
>> +#define PRG_ETH0_EXT_RGMII_MODE 1
>> +#define PRG_ETH0_EXT_RMII_MODE  4
>> +
>>  /* mux to choose between fclk_div2 (bit unset) and mpll2 (bit set) */
>>  #define PRG_ETH0_CLK_M250_SEL_SHIFT 4
>>  #define PRG_ETH0_CLK_M250_SEL_MASK  GENMASK(4, 4)
>> @@ -46,10 +51,16 @@
>>  #define PRG_ETH0_TX_AND_PHY_REF_CLK BIT(12)
>>  
>>  #define MUX_CLK_NUM_PARENTS 2
>> +struct meson8b_dwmac_data {
>> +bool ext_phy_mode;
>> +};
>>  
>>  struct meson8b_dwmac {
>>  struct device   *dev;
>>  void __iomem*regs;
>> +
>> +const struct meson8b_dwmac_data *data;
>> +
>>  phy_interface_t phy_mode;
>>  struct clk  *rgmii_tx_clk;
>>  u32 tx_delay_ns;
>> @@ -171,6 +182,46 @@ static int meson8b_init_rgmii_tx_clk(struct 
>> meson8b_dwmac *dwmac)
>>  return 0;
>>  }
>>  
>> +static int meson8b_init_set_mode(struct meson8b_dwmac *dwmac)
>> +{
>> +bool ext_phy_mode = dwmac->data->ext_phy_mode;
>> +
>> +switch (dwmac->phy_mode) {
>> +case PHY_INTERFACE_MODE_RGMII:
>> +case PHY_INTERFACE_MODE_RGMII_RXID:
>> +case PHY_INTERFACE_MODE_RGMII_ID:
>> +case PHY_INTERFACE_MODE_RGMII_TXID:
>> +/* enable RGMII mode */
>> +if (ext_phy_mode)
> 
> Looks weird to have this if target at a specific SoC withing a function named
> after another SoC
> 
> Couldn't you make one function per soc type, and pass that function pointer in
> the match data ?
> 
sounds good, I can do this

>> +meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
>> +PRG_ETH0_EXT_PHY_MODE_MASK,
>> +PRG_ETH0_EXT_RGMII_MODE);
>> +else
>> +meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
>> +PRG_ETH0_RGMII_MODE,
>> +PRG_ETH0_RGMII_MODE);
>> +
>> +break;
>> +case PHY_INTERFACE_MODE_RMII:
>> +/* disable RGMII mode -> enables RMII mode */
>> +if (ext_phy_mode)
>> +meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
>> +PRG_ETH0_EXT_PHY_MODE_MASK,
>> +PRG_ETH0_EXT_RMII_MODE);
>> +else
>> +meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
>> +PRG_ETH0_RGMII_MODE, 0);
>> +
>> +break;
>> +default:
>> +dev_err(dwmac->dev, "fail to set phy-mode %s\n",
>> +phy_modes(dwmac->phy_mode));
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
>>  {
>>  int ret;
>> @@ -188,10 +239,6 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac 
>> *dwmac)
>>  
>>  case PHY_INTERFACE_MODE_RGMII_ID:
>>  case PHY_INTERFACE_MODE_RGMII_TXID:
>> -/* enable RGMII mode */
>> -meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_RGMII_MODE,
>> -PRG_ETH0_RGMII_MODE);
>> -
>>  /* only relevant for RMII mode -> disable in RGMII mode */
>>  meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
>>  PRG_ETH0_INVERTED_RMII_CLK, 0);
>> @@ -224,10 +271,6 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac 
>> *dwmac)
>>  break;
>>  
>>  case PHY_INTERFACE_MODE_RMII:
>> -/* disable RGMII mode -> enables RMII mode */
>> -meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_RGMII_MODE,
>> -0);
>> -
>>  

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

[Rich Felker]

On Thu, Apr 26, 2018 at 09:28:39PM -0500, David Lechner wrote:
> On 04/26/2018 12:31 PM, Rich Felker wrote:
> >On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote:
> >>From: Bartosz Golaszewski 
> >>
> >>This is a follow to my series[1] the aim of which was to introduce device 
> >>tree
> >>support for early platform devices.
> >>
> >>It was received rather negatively. Aside from using device tree to pass
> >>implementation specific details to the system, two important concerns were
> >>raised: no probe deferral support and the fact that currently the early 
> >>devices
> >>never get converted to actual platform drivers. This series is a
> >>proof-of-concept that's trying to address those issues.
> >>
> >>The only user of the current version of early platform drivers is the SuperH
> >>architecture. If this series eventually gets merged, we could simply replace
> >>the other solution.
> >
> >Looking at a quick output of:
> >
> > grep -r -A10 early_devices[[] arch/sh/kernel/
> >
> >it looks like all of the existing early platform devices are serial
> >ports, clocks, and clocksources. The switch to device tree should pick
> >them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and
> >EARLYCON_DECLARE. Until that's complete, the existing code works
> >as-is. I don't see what problem you're trying to solve.
> 
> The problem for us is that clk maintainers don't want new drivers to use
> CLK_OF_DECLARE and instead use platform devices. I have just written such
> a new driver that is shared by 6 different SoCs. For some combinations of
> SoCs and clocks, using a platform device is fine but on others we need to
> register early, so the drivers now have to handle both cases, which is
> kind of messy and fragile. If there is a generic way to register platform
> devices early, then the code is simplified because we only have to handle
> one method of registering the clocks instead of two.

Can you get them to explain why? This sounds wrong.

Rich

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

[Rob Herring]

On Thu, Apr 19, 2018 at 05:45:34PM +0200, Paul Kocialkowski wrote:
> This adds a device-tree binding document that specifies the properties
> used by the Sunxi-Cedurs VPU driver, as well as examples.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/media/sunxi-cedrus.txt | 50 
> ++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt

Other than the one nit about the node name,

Reviewed-by: Rob Herring 

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

[Rob Herring]

On Fri, Apr 20, 2018 at 09:22:20AM +0200, Paul Kocialkowski wrote:
> Hi and thanks for the review,
> 
> On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote:
> > Hi Paul, Philipp,
> > 
> > On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel 
> > wrote:
> > 
> > > Hi Paul,
> > > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > > > This adds a device-tree binding document that specifies the
> > > > properties
> > > > used by the Sunxi-Cedurs VPU driver, as well as examples.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
> > 
> > ++
> > > >  1 file changed, 50 insertions(+)
> > > >  create mode 100644
> > 
> > Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/media/sunxi-
> > > > cedrus.txt
> > 
> > b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > new file mode 100644
> > > > index ..71ad3f9c3352
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > @@ -0,0 +1,50 @@
> > > > +Device-tree bindings for the VPU found in Allwinner SoCs,
> > > > referred to
> > 
> > as the
> > > > +Video Engine (VE) in Allwinner literature.
> > > > +
> > > > +The VPU can only access the first 256 MiB of DRAM, that are DMA-
> > > > mapped
> > 
> > starting
> > > > +from the DRAM base. This requires specific memory allocation and
> > 
> > handling.
> > 
> > And no IOMMU? Brings back memories.
> 
> Exactly, no IOMMU so we don't have much choice but cope with that
> hardware limitation...
> 
> > > > +
> > > > +Required properties:
> > > > +- compatible : "allwinner,sun4i-a10-video-engine";
> > > > +- memory-region : DMA pool for buffers allocation;
> > > > +- clocks : list of clock specifiers, corresponding to
> > 
> > entries in
> > > > +  the clock-names property;
> > > > +- clock-names: should contain "ahb", "mod" and
> > > > "ram"
> > 
> > entries;
> > > > +- assigned-clocks   : list of clocks assigned to the VE;
> > > > +- assigned-clocks-rates : list of clock rates for the clocks
> > > > assigned
> > 
> > to the VE;
> > > > +- resets : phandle for reset;
> > > > +- interrupts : should contain VE interrupt number;
> > > > +- reg: should contain register base and
> > > > length
> > 
> > of VE.
> > > > +
> > > > +Example:
> > > > +
> > > > +reserved-memory {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + ranges;
> > > > +
> > > > + /* Address must be kept in the lower 256 MiBs of DRAM for
> > > > VE. */
> > > > + ve_memory: cma@4a00 {
> > > > + compatible = "shared-dma-pool";
> > > > + reg = <0x4a00 0x600>;
> > > > + no-map;
> > > > + linux,cma-default;
> > > > + };
> > > > +};
> > > > +
> > > > +video-engine@1c0e000 {
> > > This is not really required by any specification, and not as common
> > > as
> > > gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
> > > somewhat-common practice?
> > 
> > AFAIR the name is supposed to be somewhat readable for someone that
> > doesn't know the hardware. To me, "video-engine" sounds more obvious
> > than "vpu", but we actually use "codec" already, in case of MFC and
> > JPEG codec on Exynos. If encode/decode is the only functionality of
> > this block, I'd personally go with "codec". If it can do other things,
> > e.g. scaling/rotation without encode/decode, I'd probably call it
> > "video-processor".
> 
> I agree that the term VPU is more commonly associated with video
> decoding, while video engine could mean a number of things.
> 
> The reason I went with "video-engine" here (while still presenting the
> driver as a VPU driver) is that Video Engine is the term used in
> Allwinner's litterature. Other nodes in Allwinner device-trees generally
> stick to these terms (for instance, we have "display-engine" nodes).
> This also makes it easier to find the matching parts in the
> documentation.

'video-codec' is what is defined in the DT spec.

Rob

Re: [PATCH 2/3] dt-bindings: rtc: update stm32-rtc documentation for stm32mp1 rtc

[Rob Herring]

On Thu, Apr 19, 2018 at 03:34:04PM +0200, Amelie Delaunay wrote:
> RTC embedded in stm32mp1 SoC is slightly different from stm32h7 one, it
> doesn't require to disable backup domain write protection, and rtc_ck
> parent clock assignment isn't allowed.
> To sum up, stm32mp1 RTC requires 2 clocks, pclk and rtc_ck, and an RTC
> alarm interrupt.
> 
> Signed-off-by: Amelie Delaunay 
> ---
>  .../devicetree/bindings/rtc/st,stm32-rtc.txt   | 27 
> +-
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt 
> b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> index 00f8b5d..f1c2080 100644
> --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> @@ -1,25 +1,31 @@
>  STM32 Real Time Clock
>  
>  Required properties:
> -- compatible: can be either "st,stm32-rtc" or "st,stm32h7-rtc", depending on
> -  the device is compatible with stm32(f4/f7) or stm32h7.
> +- compatible: can be "st,stm32-rtc", "st,stm32h7-rtc" or "st,stm32mp1-rtc",
> +   depending on the device is compatible with stm32(f4/f7), stm32h7
> +   or stm32mp1.

One compatible per line please.

>  - reg: address range of rtc register set.
>  - clocks: can use up to two clocks, depending on part used:
>- "rtc_ck": RTC clock source.
> -It is required on stm32(f4/f7) and stm32h7.
> +It is required on stm32(f4/f7/h7/mp1).

IOW, required for all?

>- "pclk": RTC APB interface clock.
>  It is not present on stm32(f4/f7).
> -It is required on stm32h7.
> +It is required on stm32(h7/mp1).
>  - clock-names: must be "rtc_ck" and "pclk".
> -It is required only on stm32h7.
> +It is required on stm32(h7/mp1).
>  - interrupt-parent: phandle for the interrupt controller.
> +It is required on stm32(f4/f7/h7).
>  - interrupts: rtc alarm interrupt.
> +- interrupts-extended: replace interrupts property on stm32mp1, to specify 
> rtc
> +  alarm wakeup interrupt, which is on exti interrupt controller instead of 
> gic.
> +It is required on stm32mp1.

Just document 'interrupts'. interrupts-extended is implicitly supported 
and what the interrupts are connected to is outside the scope of this 
binding.

>  - st,syscfg: phandle/offset/mask triplet. The phandle to pwrcfg used to
>access control register at offset, and change the dbp (Disable Backup
>Protection) bit represented by the mask, mandatory to disable/enable backup
>domain (RTC registers) write protection.
> +It is required on stm32(f4/f7/h7).
>  
> -Optional properties (to override default rtc_ck parent clock):
> +Optional properties (to override default rtc_ck parent clock on 
> stm32(f4/f7/h7):
>  - assigned-clocks: reference to the rtc_ck clock entry.
>  - assigned-clock-parents: phandle of the new parent clock of rtc_ck.
>  
> @@ -48,3 +54,12 @@ Example:
>   interrupt-names = "alarm";
>   st,syscfg = <&pwrcfg 0x00 0x100>;
>   };
> +
> + rtc: rtc@5c004000 {
> + compatible = "st,stm32mp1-rtc";
> + reg = <0x5c004000 0x400>;
> + clocks = <&rcc RTCAPB>, <&rcc RTC>;
> + clock-names = "pclk", "rtc_ck";
> + interrupts-extended = <&intc GIC_SPI 3 IRQ_TYPE_NONE>,
> +   <&exti 19 1>;
> + };
> -- 
> 2.7.4
> 

Re: [PATCH 3/4] dt-bindings: rtc: update stm32-rtc documentation for st,syscfg property

[Rob Herring]

On Thu, Apr 19, 2018 at 03:21:42PM +0200, Amelie Delaunay wrote:
> RTC driver should not be aware of the PWR registers offset and bits
> position. Furthermore, we can imagine that Disable Backup Protection (DBP)
> relative register and bit mask could change depending on the SoC. So this
> patch moves st,syscfg property from single pwrcfg phandle to pwrcfg
> phandle/offset/mask triplet.
> 
> Signed-off-by: Amelie Delaunay 
> ---
>  Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt 
> b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> index a66692a..00f8b5d 100644
> --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> @@ -14,8 +14,10 @@ Required properties:
>  It is required only on stm32h7.
>  - interrupt-parent: phandle for the interrupt controller.
>  - interrupts: rtc alarm interrupt.
> -- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
> -  (RTC registers) write protection.
> +- st,syscfg: phandle/offset/mask triplet. The phandle to pwrcfg used to
> +  access control register at offset, and change the dbp (Disable Backup
> +  Protection) bit represented by the mask, mandatory to disable/enable backup
> +  domain (RTC registers) write protection.

It's fine to add this, but you are breaking compatibility in the driver 
with existing DTBs by requiring these new fields.

Rob

[PATCH] crypto: tcrypt: Remove VLA usage

[Kees Cook]

In the quest to remove all stack VLA usage from the kernel[1], this
allocates the return code buffers before starting jiffie timers, rather
than using stack space for the array. Additionally cleans up some exit
paths and make sure that the num_mb module_param() is used only once
per execution to avoid possible races in the value changing.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 crypto/tcrypt.c | 118 +---
 1 file changed, 79 insertions(+), 39 deletions(-)

diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 51fe7c8744ae..e721faab6fc8 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -158,9 +158,9 @@ struct test_mb_aead_data {
 };
 
 static int do_mult_aead_op(struct test_mb_aead_data *data, int enc,
-   u32 num_mb)
+   u32 num_mb, int *rc)
 {
-   int i, rc[num_mb], err = 0;
+   int i, err = 0;
 
/* Fire up a bunch of concurrent requests */
for (i = 0; i < num_mb; i++) {
@@ -188,18 +188,26 @@ static int test_mb_aead_jiffies(struct test_mb_aead_data 
*data, int enc,
 {
unsigned long start, end;
int bcount;
-   int ret;
+   int ret = 0;
+   int *rc;
+
+   rc = kcalloc(num_mb, sizeof(*rc), GFP_KERNEL);
+   if (!rc)
+   return -ENOMEM;
 
for (start = jiffies, end = start + secs * HZ, bcount = 0;
 time_before(jiffies, end); bcount++) {
-   ret = do_mult_aead_op(data, enc, num_mb);
+   ret = do_mult_aead_op(data, enc, num_mb, rc);
if (ret)
-   return ret;
+   goto out;
}
 
pr_cont("%d operations in %d seconds (%ld bytes)\n",
bcount * num_mb, secs, (long)bcount * blen * num_mb);
-   return 0;
+
+out:
+   kfree(rc);
+   return ret;
 }
 
 static int test_mb_aead_cycles(struct test_mb_aead_data *data, int enc,
@@ -208,10 +216,15 @@ static int test_mb_aead_cycles(struct test_mb_aead_data 
*data, int enc,
unsigned long cycles = 0;
int ret = 0;
int i;
+   int *rc;
+
+   rc = kcalloc(num_mb, sizeof(*rc), GFP_KERNEL);
+   if (!rc)
+   return -ENOMEM;
 
/* Warm-up run. */
for (i = 0; i < 4; i++) {
-   ret = do_mult_aead_op(data, enc, num_mb);
+   ret = do_mult_aead_op(data, enc, num_mb, rc);
if (ret)
goto out;
}
@@ -221,7 +234,7 @@ static int test_mb_aead_cycles(struct test_mb_aead_data 
*data, int enc,
cycles_t start, end;
 
start = get_cycles();
-   ret = do_mult_aead_op(data, enc, num_mb);
+   ret = do_mult_aead_op(data, enc, num_mb, rc);
end = get_cycles();
 
if (ret)
@@ -230,11 +243,11 @@ static int test_mb_aead_cycles(struct test_mb_aead_data 
*data, int enc,
cycles += end - start;
}
 
-out:
-   if (ret == 0)
-   pr_cont("1 operation in %lu cycles (%d bytes)\n",
-   (cycles + 4) / (8 * num_mb), blen);
+   pr_cont("1 operation in %lu cycles (%d bytes)\n",
+   (cycles + 4) / (8 * num_mb), blen);
 
+out:
+   kfree(rc);
return ret;
 }
 
@@ -705,9 +718,10 @@ struct test_mb_ahash_data {
char *xbuf[XBUFSIZE];
 };
 
-static inline int do_mult_ahash_op(struct test_mb_ahash_data *data, u32 num_mb)
+static inline int do_mult_ahash_op(struct test_mb_ahash_data *data, u32 num_mb,
+  int *rc)
 {
-   int i, rc[num_mb], err = 0;
+   int i, err = 0;
 
/* Fire up a bunch of concurrent requests */
for (i = 0; i < num_mb; i++)
@@ -731,18 +745,26 @@ static int test_mb_ahash_jiffies(struct 
test_mb_ahash_data *data, int blen,
 {
unsigned long start, end;
int bcount;
-   int ret;
+   int ret = 0;
+   int *rc;
+
+   rc = kcalloc(num_mb, sizeof(*rc), GFP_KERNEL);
+   if (!rc)
+   return -ENOMEM;
 
for (start = jiffies, end = start + secs * HZ, bcount = 0;
 time_before(jiffies, end); bcount++) {
-   ret = do_mult_ahash_op(data, num_mb);
+   ret = do_mult_ahash_op(data, num_mb, rc);
if (ret)
-   return ret;
+   goto out;
}
 
pr_cont("%d operations in %d seconds (%ld bytes)\n",
bcount * num_mb, secs, (long)bcount * blen * num_mb);
-   return 0;
+
+out:
+   kfree(rc);
+   return ret;
 }
 
 static int test_mb_ahash_cycles(struct test_mb_ahash_data *data, int blen,
@@ -751,10 +773,15 @@ static int test_mb_ahash_cycles(struct test_mb_ahash_data 
*data, int blen,
unsigned long cycles = 0;
int ret = 0;
int i;
+   int *rc;
+
+   rc = kcalloc(num_mb, si

Re: [PATCH 2/2] Revert "f2fs: add ovp valid_blocks check for bg gc victim to fg_gc"

[Chao Yu]

Hi Jaegeuk,

Missed this patch, or any problem in it?

Thanks,

On 2018/4/26 17:05, Chao Yu wrote:
> For extreme case:
> 10 section, op = 10%, no_fggc_threshold = 90%
> All section usage: 85% 85% 85% 85% 90% 90% 95% 95% 95% 95%
> 
> During foreground GC, if we skip select dirty section whose usage
> is larger than no_fggc_threshold, we can only recycle 80% invalid
> space from four 85% usage sections and two 90% usage sections,
> result in encountering out-of-space issue.
> 
> This reverts commit e93b9865251a0503d83fd570e7d5a7c8bc351715 to
> fix this issue, besides, we keep the logic that we scan all dirty
> section when searching a victim, so that GC can select victim with
> least valid blocks.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/f2fs.h|  3 ---
>  fs/f2fs/gc.c  | 16 
>  fs/f2fs/segment.h |  9 -
>  3 files changed, 28 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 64e3677998d8..9f8b327272df 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1192,9 +1192,6 @@ struct f2fs_sb_info {
>   struct f2fs_gc_kthread  *gc_thread; /* GC thread */
>   unsigned int cur_victim_sec;/* current victim section num */
>  
> - /* threshold for converting bg victims for fg */
> - u64 fggc_threshold;
> -
>   /* threshold for gc trials on pinned files */
>   u64 gc_pin_file_threshold;
>  
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 3134dd781252..62eba4a71123 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -263,10 +263,6 @@ static unsigned int check_bg_victims(struct f2fs_sb_info 
> *sbi)
>   for_each_set_bit(secno, dirty_i->victim_secmap, MAIN_SECS(sbi)) {
>   if (sec_usage_check(sbi, secno))
>   continue;
> -
> - if (no_fggc_candidate(sbi, secno))
> - continue;
> -
>   clear_bit(secno, dirty_i->victim_secmap);
>   return GET_SEG_FROM_SEC(sbi, secno);
>   }
> @@ -406,9 +402,6 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
>   goto next;
>   if (gc_type == BG_GC && test_bit(secno, dirty_i->victim_secmap))
>   goto next;
> - if (gc_type == FG_GC && p.alloc_mode == LFS &&
> - no_fggc_candidate(sbi, secno))
> - goto next;
>  
>   cost = get_gc_cost(sbi, segno, &p);
>  
> @@ -1152,17 +1145,8 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>  
>  void build_gc_manager(struct f2fs_sb_info *sbi)
>  {
> - u64 main_count, resv_count, ovp_count;
> -
>   DIRTY_I(sbi)->v_ops = &default_v_ops;
>  
> - /* threshold of # of valid blocks in a section for victims of FG_GC */
> - main_count = SM_I(sbi)->main_segments << sbi->log_blocks_per_seg;
> - resv_count = SM_I(sbi)->reserved_segments << sbi->log_blocks_per_seg;
> - ovp_count = SM_I(sbi)->ovp_segments << sbi->log_blocks_per_seg;
> -
> - sbi->fggc_threshold = div64_u64((main_count - ovp_count) *
> - BLKS_PER_SEC(sbi), (main_count - resv_count));
>   sbi->gc_pin_file_threshold = DEF_GC_FAILED_PINNED_FILES;
>  
>   /* give warm/cold data area from slower device */
> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
> index 7702b054689c..c385daabcb67 100644
> --- a/fs/f2fs/segment.h
> +++ b/fs/f2fs/segment.h
> @@ -774,15 +774,6 @@ static inline block_t sum_blk_addr(struct f2fs_sb_info 
> *sbi, int base, int type)
>   - (base + 1) + type;
>  }
>  
> -static inline bool no_fggc_candidate(struct f2fs_sb_info *sbi,
> - unsigned int secno)
> -{
> - if (get_valid_blocks(sbi, GET_SEG_FROM_SEC(sbi, secno), true) >
> - sbi->fggc_threshold)
> - return true;
> - return false;
> -}
> -
>  static inline bool sec_usage_check(struct f2fs_sb_info *sbi, unsigned int 
> secno)
>  {
>   if (IS_CURSEC(sbi, secno) || (sbi->cur_victim_sec == secno))
> 

[PATCH v2] clk: aspeed: Support second reset register

[Joel Stanley]

The ast2500 has an additional reset register that contains resets not
present in the ast2400. This enables support for this register, and adds
the one reset line that is controlled by it.

Reviewed-by: Andrew Jeffery 
Signed-off-by: Joel Stanley 
---
v2:
 This commit fixes a bug in aspeed_reset_assert() which determines
 the second reset register using condition.

 drivers/clk/clk-aspeed.c | 44 +++-
 include/dt-bindings/clock/aspeed-clock.h |  1 +
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index c7cb1f2b6f8a..1fbf45738535 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -16,6 +16,8 @@
 
 #define ASPEED_NUM_CLKS35
 
+#define ASPEED_RESET2_OFFSET   32
+
 #define ASPEED_RESET_CTRL  0x04
 #define ASPEED_CLK_SELECTION   0x08
 #define ASPEED_CLK_STOP_CTRL   0x0c
@@ -30,6 +32,7 @@
 #define  CLKIN_25MHZ_ENBIT(23)
 #define  AST2400_CLK_SOURCE_SELBIT(18)
 #define ASPEED_CLK_SELECTION_2 0xd8
+#define ASPEED_RESET_CTRL2 0xd4
 
 /* Globally visible clocks */
 static DEFINE_SPINLOCK(aspeed_clk_lock);
@@ -291,6 +294,7 @@ struct aspeed_reset {
 #define to_aspeed_reset(p) container_of((p), struct aspeed_reset, rcdev)
 
 static const u8 aspeed_resets[] = {
+   /* SCU04 resets */
[ASPEED_RESET_XDMA] = 25,
[ASPEED_RESET_MCTP] = 24,
[ASPEED_RESET_ADC]  = 23,
@@ -300,38 +304,62 @@ static const u8 aspeed_resets[] = {
[ASPEED_RESET_PCIVGA]   =  8,
[ASPEED_RESET_I2C]  =  2,
[ASPEED_RESET_AHB]  =  1,
+
+   /*
+* SCUD4 resets start at an offset to separate them from
+* the SCU04 resets.
+*/
+   [ASPEED_RESET_CRT1] = ASPEED_RESET2_OFFSET + 5,
 };
 
 static int aspeed_reset_deassert(struct reset_controller_dev *rcdev,
 unsigned long id)
 {
struct aspeed_reset *ar = to_aspeed_reset(rcdev);
-   u32 rst = BIT(aspeed_resets[id]);
+   u32 reg = ASPEED_RESET_CTRL;
+   u32 bit = aspeed_resets[id];
+
+   if (bit >= ASPEED_RESET2_OFFSET) {
+   bit -= ASPEED_RESET2_OFFSET;
+   reg = ASPEED_RESET_CTRL2;
+   }
 
-   return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, 0);
+   return regmap_update_bits(ar->map, reg, BIT(bit), 0);
 }
 
 static int aspeed_reset_assert(struct reset_controller_dev *rcdev,
   unsigned long id)
 {
struct aspeed_reset *ar = to_aspeed_reset(rcdev);
-   u32 rst = BIT(aspeed_resets[id]);
+   u32 reg = ASPEED_RESET_CTRL;
+   u32 bit = aspeed_resets[id];
 
-   return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, rst);
+   if (bit >= ASPEED_RESET2_OFFSET) {
+   bit -= ASPEED_RESET2_OFFSET;
+   reg = ASPEED_RESET_CTRL2;
+   }
+
+   return regmap_update_bits(ar->map, reg, BIT(bit), BIT(bit));
 }
 
 static int aspeed_reset_status(struct reset_controller_dev *rcdev,
   unsigned long id)
 {
struct aspeed_reset *ar = to_aspeed_reset(rcdev);
-   u32 val, rst = BIT(aspeed_resets[id]);
-   int ret;
+   u32 reg = ASPEED_RESET_CTRL;
+   u32 bit = aspeed_resets[id];
+   int ret, val;
+
+   if (bit >= ASPEED_RESET2_OFFSET) {
+   bit -= ASPEED_RESET2_OFFSET;
+   reg = ASPEED_RESET_CTRL2;
+   }
 
-   ret = regmap_read(ar->map, ASPEED_RESET_CTRL, &val);
+   ret = regmap_read(ar->map, reg, &val);
if (ret)
return ret;
 
-   return !!(val & rst);
+   return !!(val & BIT(bit));
 }
 
 static const struct reset_control_ops aspeed_reset_ops = {
diff --git a/include/dt-bindings/clock/aspeed-clock.h 
b/include/dt-bindings/clock/aspeed-clock.h
index d3558d897a4d..513c1b4af7a8 100644
--- a/include/dt-bindings/clock/aspeed-clock.h
+++ b/include/dt-bindings/clock/aspeed-clock.h
@@ -48,5 +48,6 @@
 #define ASPEED_RESET_PCIVGA6
 #define ASPEED_RESET_I2C   7
 #define ASPEED_RESET_AHB   8
+#define ASPEED_RESET_CRT1  9
 
 #endif
-- 
2.17.0

Re: [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

[zhoucm1]

On 2018年04月26日 23:06, Michel Dänzer wrote:

From: Michel Dänzer 

When it's set, TTM tries to allocate huge pages if possible.

Do you mean original driver doesn't do this?
From the code, driver always try huge pages if 
CONFIG_TRANSPARENT_HUGEPAGE is enabled.


Regards,
David Zhou

  Drivers
which can take advantage of huge pages should set it.

Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.

Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 ++
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  8 +---
  include/drm/ttm/ttm_tt.h |  1 +
  4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dfd22db13fb1..e03e9e361e2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -988,7 +988,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_buffer_object *bo,
return NULL;
}
gtt->ttm.ttm.func = &amdgpu_backend_func;
-   if (ttm_sg_tt_init(>t->ttm, bo, page_flags)) {
+   if (ttm_sg_tt_init(>t->ttm, bo, page_flags | 
TTM_PAGE_FLAG_TRANSHUGE)) {
kfree(gtt);
return NULL;
}
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index f0481b7b60c5..2ce91272b111 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -760,7 +760,7 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
  {
struct ttm_page_pool *pool = ttm_get_pool(flags, false, cstate);
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   struct ttm_page_pool *huge = ttm_get_pool(flags, true, cstate);
+   struct ttm_page_pool *huge = NULL;
  #endif
unsigned long irq_flags;
unsigned i;
@@ -780,7 +780,8 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
}
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

-   if (!(flags & TTM_PAGE_FLAG_DMA32)) {
+   if ((flags & (TTM_PAGE_FLAG_DMA32 | 
TTM_PAGE_FLAG_TRANSHUGE)) ==
+   TTM_PAGE_FLAG_TRANSHUGE) {
for (j = 0; j < HPAGE_PMD_NR; ++j)
if (p++ != pages[i + j])
break;
@@ -805,6 +806,8 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
  
  	i = 0;

  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   if (flags & TTM_PAGE_FLAG_TRANSHUGE)
+   huge = ttm_get_pool(flags, true, cstate);
if (huge) {
unsigned max_size, n2free;
  
@@ -877,7 +880,7 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,

  {
struct ttm_page_pool *pool = ttm_get_pool(flags, false, cstate);
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   struct ttm_page_pool *huge = ttm_get_pool(flags, true, cstate);
+   struct ttm_page_pool *huge = NULL;
  #endif
struct list_head plist;
struct page *p = NULL;
@@ -906,7 +909,8 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
  
  		i = 0;

  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   if (!(gfp_flags & GFP_DMA32)) {
+   if ((flags & (TTM_PAGE_FLAG_DMA32 | TTM_PAGE_FLAG_TRANSHUGE)) ==
+   TTM_PAGE_FLAG_TRANSHUGE) {
while (npages >= HPAGE_PMD_NR) {
gfp_t huge_flags = gfp_flags;
  
@@ -946,6 +950,8 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,

count = 0;
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

+   if (flags & TTM_PAGE_FLAG_TRANSHUGE)
+   huge = ttm_get_pool(flags, true, cstate);
if (huge && npages >= HPAGE_PMD_NR) {
INIT_LIST_HEAD(&plist);
ttm_page_pool_get_pages(huge, &plist, flags, cstate,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 8a25d1974385..291b04213ec5 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

-   if (ttm->page_flags & TTM_PAGE_FLAG_DMA32)
+   if ((ttm->page_flags & (TTM_PAGE_FLAG_DMA32 | TTM_PAGE_FLAG_TRANSHUGE))
+   != TTM_PAGE_FLAG_TRANSHUGE)
goto skip_huge;
  
  	pool = ttm_dma_find_pool(dev, type | IS_HUGE);

@@ -1035,7 +1036,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
  {
struct ttm_tt *ttm = &ttm_dma->ttm;
struct ttm_mem_global *mem_glo

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

[Steven Rostedt]

On Fri, 27 Apr 2018 11:39:51 +0900
Masami Hiramatsu  wrote:

> On Thu, 26 Apr 2018 21:13:51 -0400
> Steven Rostedt  wrote:
> 
> > On Thu, 26 Apr 2018 17:10:03 +0900
> > Masami Hiramatsu  wrote:
> >   
> > > Replace %p with appropriate pointer types (or just remove it)
> > >  - Use %pS if possible
> > >  - Use %px only for the function right before BUG().
> > >  - Remove unneeded error message.  
> > 
> > I'm not sure "right before BUG()" is legitimate for using %px. Why not
> > still use %pS?  
> 
> Since BUG() will dump all registers and stacks which includes
> raw address information and reboot the system (means reset the
> kaslr base offset), I thought it may not add additional damage.

BUG() has been changed to print out %pS and not the address while doing
the stack dump. It only prints the address if it doesn't find a
function name. For example:

CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc3-test+ #48
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
Call Trace:
 dump_stack+0x68/0x92
 lockdep_rcu_suspicious+0xf7/0x100
 rcu_read_lock+0x5f/0x61
 __is_insn_slot_addr+0x23/0x5c
 __kernel_text_address+0x4a/0x80
 show_trace_log_lvl+0x157/0x296
 ? module_assert_mutex_or_preempt+0x4f/0x51
 show_stack+0x3d/0x3f
 dump_stack+0x68/0x92
 __warn+0xc2/0xdd
 ? 0xa0026077
 warn_slowpath_null+0x1d/0x1f
 module_assert_mutex_or_preempt+0x4f/0x51
 __module_address+0x2a/0xac
 ? 0xa0026077
 __module_text_address+0x12/0x59
 ? 0xa0026077
 is_module_text_address+0xe/0x16
 __kernel_text_address+0x2b/0x80
 ? 0xa0026077
 unwind_get_return_address+0x50/0x5c


> 
> Anyway, for this patch we can use %pS. For the next [5/7] patch,
> I'm not sure %pS is good for dumping a stack address...

Although it now is.

-- Steve

Re: testing io.low limit for blk-throttle

[Joseph Qi]

Hi Jianchao,

On 18/4/27 10:09, jianchao.wang wrote:
> Hi Tejun and Joseph
> 
> On 04/27/2018 02:32 AM, Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote:
>>> +Tejun (I guess he might be interested in the results below)
>>
>> Our experiments didn't work out too well either.  At this point, it
>> isn't clear whether io.low will ever leave experimental state.  We're
>> trying to find a working solution.
> 
> Would you please take a look at the following two patches.
> 
> https://marc.info/?l=linux-block&m=152325456307423&w=2
> https://marc.info/?l=linux-block&m=152325457607425&w=2
> 
> In addition, when I tested blk-throtl io.low on NVMe card, I always got
> even if the iops has been lower than io.low limit for a while, but the
> due to group is not idle, the downgrade always fails.
> 
>tg->latency_target && tg->bio_cnt &&
>   tg->bad_bio_cnt * 5 < tg->bio_cn
> 

I'm afraid the latency check is a must for io.low. Because idle time
check can only apply to simple scenarios from my test.

Yes, in some cases last_low_overflow_time does have problems.
And for not downgrade properly, I've also posted two patches before,
waiting Shaohua's review. You can also have a try.

https://patchwork.kernel.org/patch/10177185/
https://patchwork.kernel.org/patch/10177187/

Thanks,
Joseph

> the latency always looks well even the sum of two groups's iops has reached 
> the top.
> so I disable this check on my test, plus the 2 patches above, the io.low
> could basically works.
> 
> My NVMe card's max bps is ~600M, and max iops is ~160k.
> Here is my config
> io.low riops=5 wiops=5 rbps=209715200 wbps=209715200 idle=200 
> latency=10
> io.max riops=15
> There are two cgroups in my test, both of them have same config.
> 
> In addition, saying "basically work" is due to the iops of the two cgroup 
> will jump up and down.
> such as, I launched one fio test per cgroup, the iops will wave as following:
> 
> group0   30k  50k   70k   60k  40k
> group1   120k 100k  80k   90k  110k
> 
> however, if I launched two fio tests only in one cgroup, the iops of two test 
> could stay 
> about 70k~80k.
> 
> Could help to explain this scenario ?
> 
> Thanks in advance
> Jianchao
> 

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

[Masami Hiramatsu]

On Thu, 26 Apr 2018 21:13:51 -0400
Steven Rostedt  wrote:

> On Thu, 26 Apr 2018 17:10:03 +0900
> Masami Hiramatsu  wrote:
> 
> > Replace %p with appropriate pointer types (or just remove it)
> >  - Use %pS if possible
> >  - Use %px only for the function right before BUG().
> >  - Remove unneeded error message.
> 
> I'm not sure "right before BUG()" is legitimate for using %px. Why not
> still use %pS?

Since BUG() will dump all registers and stacks which includes
raw address information and reboot the system (means reset the
kaslr base offset), I thought it may not add additional damage.

Anyway, for this patch we can use %pS. For the next [5/7] patch,
I'm not sure %pS is good for dumping a stack address...

Thank you,

> 
> -- Steve
> 


-- 
Masami Hiramatsu 

Re: [RFC PATCH 1/3] of: base: Introduce of_alias_check_id() to check alias IDs

[Rob Herring]

On Thu, Apr 26, 2018 at 9:08 AM, Michal Simek  wrote:
> The function travers the lookup table to check if the request alias
> id is compatible with the device driver match structure.
> This function will be used by serial drivers to check if requested alias
> is allocated or free to use.
>
> Signed-off-by: Michal Simek 
> ---
>
>  drivers/of/base.c  | 49 ++
>  include/linux/of.h |  2 ++
>  2 files changed, 51 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 848f549164cd..382de01acc72 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1892,6 +1892,55 @@ int of_alias_get_id(struct device_node *np, const char 
> *stem)
>  }
>  EXPORT_SYMBOL_GPL(of_alias_get_id);
>
> +/**
> + * of_alias_check_id - Check alias id for the give compatibility
> + * @matches:   Array of of device match structures to search in
> + * @stem:  Alias stem of the given device_node
> + * @id:Alias ID for checking
> + *
> + * The function travers the lookup table to check if the request alias id
> + * is compatible with the device driver match structure
> + *
> + * Return true if ID is allocated, return false if not
> + */
> +bool of_alias_check_id(const struct of_device_id *matches, const char *stem,
> +  int id)

Wouldn't it be simpler to just return a bitmap of all allocated ids
that match rather than trying to build that up 1 bit at a time?

Rob

Re: [PATCH] f2fs: fix to wait IO writeback in __revoke_inmem_pages()

[Chao Yu]

On 2018/4/27 0:36, Jaegeuk Kim wrote:
> On 04/26, Chao Yu wrote:
>> On 2018/4/26 23:48, Jaegeuk Kim wrote:
>>> On 04/26, Chao Yu wrote:
 Thread A   Thread B
 - f2fs_ioc_commit_atomic_write
  - commit_inmem_pages
   - f2fs_submit_merged_write_cond
   : write data
- write_checkpoint
 - do_checkpoint
 : commit all node within CP
 -> SPO
   - f2fs_do_sync_file
- file_write_and_wait_range
: wait data writeback

 In above race condition, data/node can be flushed in reversed order when
 coming a checkpoint before f2fs_do_sync_file, after SPOR, it results in
 atomic written data being corrupted.
>>>
>>> Wait, what is the problem here? Thread B could succeed checkpoint, there is
>>> no problem. If it fails, there is no fsync mark where we can recover it, so
>>
>> Node is flushed by checkpoint before data, with reversed order, that's the 
>> problem.
> 
> What do you mean? Data should be in disk, in order to proceed checkpoint.

1. thread A: commit_inmem_pages submit data into block layer, but haven't waited
it writeback.
2. thread A: commit_inmem_pages update related node.
3. thread B: do checkpoint, flush all nodes to disk
4. SPOR

Then, atomic file becomes corrupted since nodes is flushed before data.

Thanks,

> 
>>
>> Thanks,
>>
>>> we can just ignore the last written data as nothing.
>>>

 This patch adds f2fs_wait_on_page_writeback in __revoke_inmem_pages() to
 keep data and node of atomic file being flushed orderly.

 Signed-off-by: Chao Yu 
 ---
  fs/f2fs/file.c| 4 
  fs/f2fs/segment.c | 3 +++
  2 files changed, 7 insertions(+)

 diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
 index be7578774a47..a352804af244 100644
 --- a/fs/f2fs/file.c
 +++ b/fs/f2fs/file.c
 @@ -217,6 +217,9 @@ static int f2fs_do_sync_file(struct file *file, loff_t 
 start, loff_t end,
  
trace_f2fs_sync_file_enter(inode);
  
 +  if (atomic)
 +  goto write_done;
 +
/* if fdatasync is triggered, let's do in-place-update */
if (datasync || get_dirty_pages(inode) <= SM_I(sbi)->min_fsync_blocks)
set_inode_flag(inode, FI_NEED_IPU);
 @@ -228,6 +231,7 @@ static int f2fs_do_sync_file(struct file *file, loff_t 
 start, loff_t end,
return ret;
}
  
 +write_done:
/* if the inode is dirty, let's recover all the time */
if (!f2fs_skip_inode_update(inode, datasync)) {
f2fs_write_inode(inode, NULL);
 diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
 index 584483426584..9ca3d0a43d93 100644
 --- a/fs/f2fs/segment.c
 +++ b/fs/f2fs/segment.c
 @@ -230,6 +230,8 @@ static int __revoke_inmem_pages(struct inode *inode,
  
lock_page(page);
  
 +  f2fs_wait_on_page_writeback(page, DATA, true);
 +
if (recover) {
struct dnode_of_data dn;
struct node_info ni;
 @@ -415,6 +417,7 @@ static int __commit_inmem_pages(struct inode *inode)
/* drop all uncommitted pages */
__revoke_inmem_pages(inode, &fi->inmem_pages, true, false);
} else {
 +  /* wait all committed IOs writeback and release them from list 
 */
__revoke_inmem_pages(inode, &revoke_list, false, false);
}
  
 -- 
 2.15.0.55.gc2ece9dc4de6
> 
> .
> 

MHI initial design review

[Sujeev Dias]

Hi Greg Kroah-Hartman\All

This is the initial submit of Modem Host Interface (MHI) stack for upstream
consideration. MHI is a communication protocol to communicate with external
Qualcomm modems and Wi-Fi chipsets over high speed peripheral buses. Even
though MHI doesn’t dictate underlying physical layer, protocol and mhi stack
is structured for PCIe based devices.

For additional details related to MHI interface please see 
Documentation/mhi.txt.

MHI stack partitioned into three main components:
1. Core layer  handles all MHI protocol specific actions such as firmware 
download,
   and data transfer
   /drivers/bus/mhi/core/*
2. Control layer  bus master, manages power transitions of external modem.
  /drivers/bus/mhi/controllers/*
3. Device drivers  MHI channels (physical transport channels) exposed as mhi 
devices
   for clients to send and receive data.
  /drivers/bus/mhi/device/*

There are three ways which clients can interface with MHI framework to send and 
receive
data from external modem.

1. Register directly with mhi core layer as a mhi device driver
2. User space clients can interface via mhi_uci driver.
3. For net traffic, mhi_netdev can be used.

Can you please do a high-level design review of the MHI driver and let me know 
if I need to
make any design changes before the drivers can be considered for upstream.

Thanks
Sujeev

   

[PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

[Sujeev Dias]

QCOM PCIe based modems uses MHI as the communication protocol.
MHI control driver is the bus master for such modems. As the bus
master driver, it oversees power management operations
such as suspend, resume, powering on and off the device.

Signed-off-by: Sujeev Dias 
---
 Documentation/devicetree/bindings/bus/mhi_qcom.txt | 110 
 drivers/bus/Kconfig|   1 +
 drivers/bus/mhi/Makefile   |   2 +-
 drivers/bus/mhi/controllers/Kconfig|  10 +
 drivers/bus/mhi/controllers/Makefile   |   1 +
 drivers/bus/mhi/controllers/mhi_qcom.c | 686 +
 drivers/bus/mhi/controllers/mhi_qcom.h |  85 +++
 7 files changed, 894 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mhi_qcom.txt
 create mode 100644 drivers/bus/mhi/controllers/Kconfig
 create mode 100644 drivers/bus/mhi/controllers/Makefile
 create mode 100644 drivers/bus/mhi/controllers/mhi_qcom.c
 create mode 100644 drivers/bus/mhi/controllers/mhi_qcom.h

diff --git a/Documentation/devicetree/bindings/bus/mhi_qcom.txt 
b/Documentation/devicetree/bindings/bus/mhi_qcom.txt
new file mode 100644
index 000..c0f8d86
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mhi_qcom.txt
@@ -0,0 +1,110 @@
+Qualcomm Technologies Inc MHI Bus controller
+
+MHI control driver enables clients to communicate with external mode
+using MHI protocol.
+
+==
+Node Structure
+==
+
+Main node properties:
+
+- compatible
+  Usage: required
+  Value type: 
+  Definition: "qcom,mhi"
+
+- qcom,pci-dev-id
+  Usage: optional
+  Value type: 
+  Definition: PCIe device id of external modem to bind. If not set, any
+   device is compatible with this node.
+
+- qcom,pci-domain
+  Usage: required
+  Value type: 
+  Definition: PCIe root complex external modem connected to
+
+- qcom,pci-bus
+  Usage: required
+  Value type: 
+  Definition: PCIe bus external modem connected to
+
+- qcom,pci-slot
+  Usage: required
+  Value type: 
+  Definition: PCIe slot as assigned by pci framework to external modem
+
+- qcom,smmu-cfg
+  Usage: required
+  Value type: 
+  Definition: Required SMMU configuration bitmask for PCIe bus.
+   BIT mask:
+   BIT(0) : Attach address mapping to endpoint device
+   BIT(1) : Set attribute S1_BYPASS
+   BIT(2) : Set attribute FAST
+   BIT(3) : Set attribute ATOMIC
+   BIT(4) : Set attribute FORCE_COHERENT
+
+- qcom,addr-win
+  Usage: required if SMMU S1 translation is enabled
+  Value type: Array of 
+  Definition: Pair of values describing iova start and stop address
+
+- qcom,msm-bus,name
+  Usage: required
+  Value type: 
+  Definition: string representing the bus scale client name to register
+
+- qcom,msm-bus,num-cases
+  Usage: required
+  Value type: 
+  Definition: Must be set to two, MHI support two scales
+
+- qcom,msm-bus,num-paths
+  Usage: required
+  Value type: 
+  Definition: Total number of master-slave pairs MHI host will vote. Must be 
set
+   to one.
+
+- qcom,msm-bus,vectors-KBps
+  Usage: required
+  Value type: Array of 
+  Definition: Array of tuples which define the bus bandwidth requirements.
+   Each tuple is of length 4, values are master-id, slave-id,
+   arbitrated bandwidth in KBps, and instantaneous bandwidth in
+   KBps.
+
+- esoc-names
+  Usage: optional
+  Value type: 
+  Definition: if external modem managed by esoc framework, set string to "mdm"
+
+- esoc-0
+  Usage: required if device is managed by esoc framework
+  Value type: phandle
+  Definition: A esoc phandle pointing to external modem
+
+- MHI bus settings
+  Usage: required
+  Values: as defined by mhi.txt
+  Definition: Per definition of devicetree/bindings/bus/mhi.txt, define device
+   specific MHI configuration parameters.
+
+
+Example:
+
+qcom,mhi {
+   compatible = "qcom,mhi";
+   qcom,pci-domain = <0>;
+   qcom,pci-bus = <1>;
+   qcom,pci-slot = <0>;
+   qcom,smmu-cfg = <0x3d>;
+   qcom,addr-win = <0x0 0x2000 0x0 0x3fff>;
+   qcom,msm-bus,name = "mhi";
+   qcom,msm-bus,num-cases = <2>;
+   qcom,msm-bus,num-paths = <1>;
+   qcom,msm-bus,vectors-KBps = <45 512 0 0>,
+   <45 512 12 65000>;
+   
+};
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index e15d56d..fb28002 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -189,5 +189,6 @@ config MHI_DEBUG
   will be logged.
 
 source "drivers/bus/fsl-mc/Kconfig"
+source drivers/bus/mhi/controllers/Kconfig
 
 endmenu
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 9f8f3ac..c6a2a91 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -4,5 +4,5 @@
 
 # core layer
 obj-y += core/
-#obj-y += controllers/
+obj-y += controllers/
 #obj-y += devices/
diff --git a/drivers/bus/mhi/controllers/Kconfig 
b/drivers/bus/mhi/controllers/

[PATCH v1 3/4] mhi_bus: dev: netdev: add network interface driver

[Sujeev Dias]

MHI based net device driver is used for transferring IP
traffic between host and modem. Driver allows clients to
transfer data using standard network interface.

Signed-off-by: Sujeev Dias 
---
 Documentation/devicetree/bindings/bus/mhi.txt |  36 ++
 drivers/bus/Kconfig   |   1 +
 drivers/bus/mhi/Makefile  |   2 +-
 drivers/bus/mhi/devices/Kconfig   |  10 +
 drivers/bus/mhi/devices/Makefile  |   1 +
 drivers/bus/mhi/devices/mhi_netdev.c  | 893 ++
 6 files changed, 942 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bus/mhi/devices/Kconfig
 create mode 100644 drivers/bus/mhi/devices/Makefile
 create mode 100644 drivers/bus/mhi/devices/mhi_netdev.c

diff --git a/Documentation/devicetree/bindings/bus/mhi.txt 
b/Documentation/devicetree/bindings/bus/mhi.txt
index ea1b620..172ae7b 100644
--- a/Documentation/devicetree/bindings/bus/mhi.txt
+++ b/Documentation/devicetree/bindings/bus/mhi.txt
@@ -139,3 +139,39 @@ mhi_controller {

};
 };
+
+
+Children Devices
+
+
+MHI netdev properties
+
+- mhi,chan
+  Usage: required
+  Value type: 
+  Definition: Channel name MHI netdev support
+
+- mhi,mru
+  Usage: required
+  Value type: 
+  Definition: Largest packet size interface can receive in bytes.
+
+- mhi,interface-name
+  Usage: optional
+  Value type: 
+  Definition: Interface name to be given so clients can identify it
+
+- mhi,recycle-buf
+  Usage: optional
+  Value type: 
+  Definition: Set true if interface support recycling buffers.
+
+
+Example:
+
+
+mhi_rmnet@0 {
+   mhi,chan = "IP_HW0";
+   mhi,interface-name = "rmnet_mhi";
+   mhi,mru = <0x4000>;
+};
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index fb28002..cc03762 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -190,5 +190,6 @@ config MHI_DEBUG
 
 source "drivers/bus/fsl-mc/Kconfig"
 source drivers/bus/mhi/controllers/Kconfig
+source drivers/bus/mhi/devices/Kconfig
 
 endmenu
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index c6a2a91..2382e04 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -5,4 +5,4 @@
 # core layer
 obj-y += core/
 obj-y += controllers/
-#obj-y += devices/
+obj-y += devices/
diff --git a/drivers/bus/mhi/devices/Kconfig b/drivers/bus/mhi/devices/Kconfig
new file mode 100644
index 000..40f964d
--- /dev/null
+++ b/drivers/bus/mhi/devices/Kconfig
@@ -0,0 +1,10 @@
+menu "MHI device support"
+
+config MHI_NETDEV
+   tristate "MHI NETDEV"
+   depends on MHI_BUS
+   help
+ MHI based net device driver for transferring IP traffic
+ between host and modem. By enabling this driver, clients
+ can transfer data using standard network interface.
+endmenu
diff --git a/drivers/bus/mhi/devices/Makefile b/drivers/bus/mhi/devices/Makefile
new file mode 100644
index 000..ee12a64
--- /dev/null
+++ b/drivers/bus/mhi/devices/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MHI_NETDEV) +=mhi_netdev.o
diff --git a/drivers/bus/mhi/devices/mhi_netdev.c 
b/drivers/bus/mhi/devices/mhi_netdev.c
new file mode 100644
index 000..23881a9
--- /dev/null
+++ b/drivers/bus/mhi/devices/mhi_netdev.c
@@ -0,0 +1,893 @@
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MHI_NETDEV_DRIVER_NAME "mhi_netdev"
+#define WATCHDOG_TIMEOUT (30 * HZ)
+
+#ifdef CONFIG_MHI_DEBUG
+
+#define MHI_ASSERT(cond, msg) do { \
+   if (cond) \
+   panic(msg); \
+} while (0)
+
+#define MSG_VERB(fmt, ...) do { \
+   if (mhi_netdev->msg_lvl <= MHI_MSG_LVL_VERBOSE) \
+   pr_err("[D][%s] " fmt, __func__, ##__VA_ARGS__);\
+} while (0)
+
+#else
+
+#define MHI_ASSERT(cond, msg) do { \
+   if (cond) { \
+   MSG_ERR(msg); \
+   WARN_ON(cond); \
+   } \
+} while (0)
+
+#define MSG_VERB(fmt, ...)
+
+#endif
+
+#define MSG_LOG(fmt, ...) do { \
+   if (mhi_netdev->msg_lvl <= MHI_MSG_LVL_INFO) \
+   pr_err("[I][%s] " fmt, __func__, ##__VA_ARGS__);\
+} while (0)
+
+#define MSG_ERR(fmt, ...) do { \
+   if (mhi_netdev->msg_lvl <= MHI_MSG_LVL_ERROR) \
+   pr_err("[E][%s] " fmt, __func__, ##__VA_ARGS__); \
+} while (0)
+
+struct mhi_stats {
+   u32 rx_int;
+   u32 tx_full;
+   u32 tx_pkts;
+   u32 rx_

[PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

[Sujeev Dias]

This module allows user space clients to transfer data
between external modem and host using standard file
operations.

Signed-off-by: Sujeev Dias 
---
 drivers/bus/mhi/devices/Kconfig   |   9 +
 drivers/bus/mhi/devices/Makefile  |   1 +
 drivers/bus/mhi/devices/mhi_uci.c | 662 ++
 3 files changed, 672 insertions(+)
 create mode 100644 drivers/bus/mhi/devices/mhi_uci.c

diff --git a/drivers/bus/mhi/devices/Kconfig b/drivers/bus/mhi/devices/Kconfig
index 40f964d..83b9673 100644
--- a/drivers/bus/mhi/devices/Kconfig
+++ b/drivers/bus/mhi/devices/Kconfig
@@ -7,4 +7,13 @@ config MHI_NETDEV
  MHI based net device driver for transferring IP traffic
  between host and modem. By enabling this driver, clients
  can transfer data using standard network interface.
+
+config MHI_UCI
+   tristate "MHI UCI"
+   depends on MHI_BUS
+   help
+ MHI based uci driver is for transferring data between host and
+ modem using standard file operations from user space. Open, read,
+ write, ioctl, and close operations are supported by this driver.
+
 endmenu
diff --git a/drivers/bus/mhi/devices/Makefile b/drivers/bus/mhi/devices/Makefile
index ee12a64..300eed1 100644
--- a/drivers/bus/mhi/devices/Makefile
+++ b/drivers/bus/mhi/devices/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_MHI_NETDEV) +=mhi_netdev.o
+obj-$(CONFIG_MHI_UCI) +=mhi_uci.o
diff --git a/drivers/bus/mhi/devices/mhi_uci.c 
b/drivers/bus/mhi/devices/mhi_uci.c
new file mode 100644
index 000..11b7b1f
--- /dev/null
+++ b/drivers/bus/mhi/devices/mhi_uci.c
@@ -0,0 +1,662 @@
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+
+struct uci_chan {
+   wait_queue_head_t wq;
+   spinlock_t lock;
+   struct list_head pending; /* user space waiting to read */
+   struct uci_buf *cur_buf; /* current buffer user space reading */
+   size_t rx_size;
+};
+
+struct uci_buf {
+   void *data;
+   size_t len;
+   struct list_head node;
+};
+
+struct uci_dev {
+   struct list_head node;
+   dev_t devt;
+   struct device *dev;
+   struct mhi_device *mhi_dev;
+   const char *chan;
+   struct mutex mutex; /* sync open and close */
+   struct uci_chan ul_chan;
+   struct uci_chan dl_chan;
+   size_t mtu;
+   int ref_count;
+   bool enabled;
+};
+
+struct mhi_uci_drv {
+   struct list_head head;
+   struct mutex lock;
+   struct class *class;
+   int major;
+   dev_t dev_t;
+};
+
+enum MHI_DEBUG_LEVEL msg_lvl = MHI_MSG_LVL_ERROR;
+
+#ifdef CONFIG_MHI_DEBUG
+
+#define MSG_VERB(fmt, ...) do { \
+   if (msg_lvl <= MHI_MSG_LVL_VERBOSE) \
+   pr_err("[D][%s] " fmt, __func__, ##__VA_ARGS__); \
+   } while (0)
+
+#else
+
+#define MSG_VERB(fmt, ...)
+
+#endif
+
+#define MSG_LOG(fmt, ...) do { \
+   if (msg_lvl <= MHI_MSG_LVL_INFO) \
+   pr_err("[I][%s] " fmt, __func__, ##__VA_ARGS__); \
+   } while (0)
+
+#define MSG_ERR(fmt, ...) do { \
+   if (msg_lvl <= MHI_MSG_LVL_ERROR) \
+   pr_err("[E][%s] " fmt, __func__, ##__VA_ARGS__); \
+   } while (0)
+
+#define MAX_UCI_DEVICES (64)
+
+static DECLARE_BITMAP(uci_minors, MAX_UCI_DEVICES);
+static struct mhi_uci_drv mhi_uci_drv;
+
+static int mhi_queue_inbound(struct uci_dev *uci_dev)
+{
+   struct mhi_device *mhi_dev = uci_dev->mhi_dev;
+   int nr_trbs = mhi_get_no_free_descriptors(mhi_dev, DMA_FROM_DEVICE);
+   size_t mtu = uci_dev->mtu;
+   void *buf;
+   struct uci_buf *uci_buf;
+   int ret = -EIO, i;
+
+   for (i = 0; i < nr_trbs; i++) {
+   buf = kmalloc(mtu + sizeof(*uci_buf), GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   uci_buf = buf + mtu;
+   uci_buf->data = buf;
+
+   MSG_VERB("Allocated buf %d of %d size %ld\n", i, nr_trbs, mtu);
+
+   ret = mhi_queue_transfer(mhi_dev, DMA_FROM_DEVICE, buf, mtu,
+MHI_EOT);
+   if (ret) {
+   kfree(buf);
+   MSG_ERR("Failed to queue buffer %d\n", i);
+   return ret;
+   }
+   }

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

[David Lechner]

On 04/26/2018 12:31 PM, Rich Felker wrote:

On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote:

From: Bartosz Golaszewski 

This is a follow to my series[1] the aim of which was to introduce device tree
support for early platform devices.

It was received rather negatively. Aside from using device tree to pass
implementation specific details to the system, two important concerns were
raised: no probe deferral support and the fact that currently the early devices
never get converted to actual platform drivers. This series is a
proof-of-concept that's trying to address those issues.

The only user of the current version of early platform drivers is the SuperH
architecture. If this series eventually gets merged, we could simply replace
the other solution.


Looking at a quick output of:

grep -r -A10 early_devices[[] arch/sh/kernel/

it looks like all of the existing early platform devices are serial
ports, clocks, and clocksources. The switch to device tree should pick
them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and
EARLYCON_DECLARE. Until that's complete, the existing code works
as-is. I don't see what problem you're trying to solve.


The problem for us is that clk maintainers don't want new drivers to use
CLK_OF_DECLARE and instead use platform devices. I have just written such
a new driver that is shared by 6 different SoCs. For some combinations of
SoCs and clocks, using a platform device is fine but on others we need to
register early, so the drivers now have to handle both cases, which is
kind of messy and fragile. If there is a generic way to register platform
devices early, then the code is simplified because we only have to handle
one method of registering the clocks instead of two.



FYI I'm (sometimes-somewhat-absent) arch/sh co-maintainer.

Rich

RE: [PATCH] USB: serial: option: adding support for ublox R410M

[林上智]

> 
> Option is likely the right driver for this device.
> 
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as the 
> modem port
> and a secondary DIAG/DM port driven by qcaux.  The DM port doesn't have an 
> interrupt
> endpoint thus it's not a normal modem port requiring the larger buffers of 
> option and its
> control signaling.
> 
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with the 
> specific layouts
> and the firmware loading requirement where the 1K and 2K devices start in a 
> special
> 1-port mode waiting for firmware and then become 4-port devices on firmware 
> reboot.
> 
> Dan

Thank you all. I believe that many people are confused in selecting serial 
driver (option and qcserial) 
for QUALCOMM based module. This thread has provided clearly and properly 
presented the different
between them.

SZ

Re: [PATCH v2] of: overlay: Stop leaking resources on overlay removal

[Rob Herring]

On Thu, Apr 26, 2018 at 01:00:30PM +0200, Jan Kiszka wrote:
> Only the overlay notifier callbacks have a chance to potentially get
> hold of references to those two resources, but they are not supposed to
> store them beyond OF_OVERLAY_POST_REMOVE.
> 
> Document the overlay notifier API, its constraint regarding pointer
> lifetime, and then remove intentional leaks of ovcs->overlay_tree and
> ovcs->fdt from free_overlay_changeset.
> 
> See also https://lkml.org/lkml/2018/4/23/1063 and following.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  Documentation/devicetree/overlay-notes.txt |  8 
>  drivers/of/overlay.c   | 30 
> +-
>  2 files changed, 29 insertions(+), 9 deletions(-)

Applied, thanks.

Rob

Re: [PATCH 3/3] thermal: armada_thermal: Replace mdelay with usleep_range in armada380_init_sensor

[Eduardo Valentin]

On Tue, Apr 10, 2018 at 04:13:28PM +0800, Jia-Ju Bai wrote:
> armada380_init_sensor() is never called in atomic context.
> 
> armada380_init_sensor() is set as ".init_sensor" in
> struct armada_thermal_data.
> ".init_sensor" is called armada_thermal_probe().
> armada_thermal_probe() is set as ".probe" in struct platform_driver.
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, armada380_init_sensor()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/thermal/armada_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c 
> b/drivers/thermal/armada_thermal.c
> index ae75328..c289ae4 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device 
> *pdev,
>   if (!(reg & A380_HW_RESET)) {
>   reg |= A380_HW_RESET;
>   writel(reg, priv->control);
> - mdelay(10);
> + usleep_range(1, 11000);

This does not apply:
checking file drivers/thermal/armada_thermal.c
Hunk #1 FAILED at 143.
1 out of 1 hunk FAILED

That mdelay() is not existing anymore.

>   }
>  }
>  
> -- 
> 1.9.1
> 

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

[Rob Herring]

On Thu, Apr 26, 2018 at 2:42 PM, Thomas Petazzoni
 wrote:
> Hello,
>
> On Thu, 26 Apr 2018 11:02:55 +0530, Viresh Kumar wrote:
>> @Thomas: Do you guys use this ?
>>
>> On 25-04-18, 20:57, Rob Herring wrote:
>> > Remove LPC32xx and SPEAr ADC bindings in staging. They have not been
>> > touched since 2012.
>> >
>> > Cc: Roland Stigge 
>> > Cc: Stefan Roese 
>> > Cc: Jonathan Cameron 
>> > Cc: Viresh Kumar 
>> > Signed-off-by: Rob Herring 
>> > ---
>> > Move these out of staging please or they are going to be removed.
>> >
>> >  .../bindings/staging/iio/adc/lpc32xx-adc.txt   | 16 -
>> >  .../bindings/staging/iio/adc/spear-adc.txt | 26 
>> > --
>> >  2 files changed, 42 deletions(-)
>
> We are using the spear-adc driver, which is out of staging
> in ./drivers/iio/adc/spear_adc.c. So rather than removing its DT binding
> entirely, it should be moved out of staging.

Except I have comments on the spear binding and it's fair game to
change it being in staging, right?

Rob

RE: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support

[Anson Huang]

Anson Huang
Best Regards!


> -Original Message-
> From: Anson Huang
> Sent: Friday, April 27, 2018 9:37 AM
> To: 'Fabio Estevam' 
> Cc: Shawn Guo ; Sascha Hauer
> ; Fabio Estevam ; Rob
> Herring ; Mark Rutland ;
> dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; linux-kernel ;
> Andy Duan 
> Subject: RE: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support
> 
> 
> 
> Anson Huang
> Best Regards!
> 
> 
> > -Original Message-
> > From: Fabio Estevam [mailto:feste...@gmail.com]
> > Sent: Friday, April 27, 2018 1:29 AM
> > To: Anson Huang 
> > Cc: Shawn Guo ; Sascha Hauer
> > ; Fabio Estevam ; Rob
> > Herring ; Mark Rutland ;
> > dl-linux-imx ; moderated list:ARM/FREESCALE IMX /
> > MXC ARM ARCHITECTURE ; open
> > list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > ; linux-kernel
> > ; Andy Duan 
> > Subject: Re: [PATCH 4/5] ARM: dts: imx6sx-sabreauto: add fec support
> >
> > On Thu, Apr 26, 2018 at 3:57 AM, Anson Huang 
> > wrote:
> >
> > > The 'phy-supply' is for enabling/disabling phy regulator, but here
> > > the
> > > MAX7322 IO0 is NOT for enabling/disabling PHY regulator, it is for
> > > IO voltage switch between 1.5V and 1.8V, our ENET IO can work with
> > > both 1.5V
> > and 1.8V, so any config is OK for ENET function.
> >
> > Thanks for the clarification.
> >
> > > The 1.5V/1.8V selection is a one time setting thing, that means we
> > > only need to config it once during boot up, most of i.MX platforms
> > > does NOT provide such voltage switch function for ENET IO, on this
> > > 6SX sabre auto board, it is more like a backup or validation
> > > purpose. With default
> > settings, ENET's function is NOT impacted at all.
> > >
> > > I think we can add a gpio regulator for it and let the regulator
> > > initialization set the GPIO Level for fec, such below, with "
> > > enable-active-high " present, GPIO will be at LOW and voltage is
> > > 1.5V, without
> > this property, GPIO will be HIGH and voltage will be 1.8V.
> > > +   reg_fec: fec_io_supply {
> > > +   compatible = "regulator-gpio";
> > > +   regulator-name = "1.8V_1.5V_FEC";
> > > +   regulator-min-microvolt = <150>;
> > > +   regulator-max-microvolt = <180>;
> > > +   states = <150 0x0 180 0x1>;
> > > +   enable-gpio = <&max7322 0
> > GPIO_ACTIVE_HIGH>;
> > > +   vin-supply = <&sw2_reg>;
> > > +   enable-active-high;
> >
> > If there is no consumer for this regulator, the regulator API will disable 
> > it.
> >
> > It seems you need a 'regulator-always-on;'.
> 
> GPIO regulator is slight different when regulator framework try to disable 
> those
> unused regulator in late phase, in _regulator_do_disable, the GPIO regulator
> only got disabled when it is explicitly enabled before (ena_gpio_state is set 
> when
> regulator is enabled), but this reg_fec is NOT getting enabled, since it only 
> has
> voltage switch function. But I agree that we can anyway add
> 'regulator-always-on'
> to avoid any confusion, will send out new patch, thanks!
> 
>  if (rdev->ena_pin) {
>  if (rdev->ena_gpio_state) {
>  ret = regulator_ena_gpio_ctrl(rdev, false);
> 
> 
> Anson.

I found if I add ' regulator-always-on ', the regulator core will explicitly 
enable this GPIO
regulator and cause MAX7322 IO0 to be HIGH and the FEC IO will be 1.8V, since 
the GPIO regulator
state 1 means 1.8V, but what we want for now is 1.5V, so I think we should NOT 
add ' regulator-always-on ',
if anyone wants to use 1.8V IO voltage, they can enable this GPIO regulator to 
get 1.8V. So I think V5 patch set
is just what we want, we want to use the OFF state's voltage (1.5V) of this 
MAX7322 IO0 GPIO regulator. Thanks.

Anson.


> 
> >
> >
> > > +   };
> > > +
> > >
> > > Anson.
> > >

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Michael Schmitz]

Hi Geert,

test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
indicate the RDB parser bug is fixed by the patch given there, so if
Martin now submits the patch, all should be well?

(MSDOS partition support is not the only one with limitations - the
SGI partition parser also uses int types. Brings back memories of /me
hacking a large disk into many small partitions because Irix couldn't
digest it whole!)

Going to look into Atari partition format limitations now ...

Cheers,

  Michael


On Thu, Apr 26, 2018 at 11:08 PM, Geert Uytterhoeven
 wrote:
> Hi Martin,
>
> CC jdow
>
> On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
>  wrote:
>> You probably put your stick into a cave with ancient sleeping dragons :)
>>
>> Added in linux-m68k mailing list, as they likely have an opinion on how
>> to treat affs + RDB partition support. Also added in Jens Axboe about
>> patching that RDB support broken with 2 TB or larger harddisks issue
>> which had been in Linux kernel for 6 years while a patch exists that to
>> my testing back then solves the issue.
>
> While non-native Linux filesystem support (e.g. affs/isofs/...) could be
> handled by FUSE, moving RDB partition support to staging is not an option,
> as it is the only partitioning scheme that Amigas can boot from.
>
> If there are bugs in the RDB parser that people run into, they should
> be fixed.
> If there are limitations in the RDB format on large disks, that's still not
> a reason to move it to staging (hi msdos partitioning!).
>
>> Matthew Wilcox - 26.04.18, 04:57:
>>> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
>>> > I had similar toughts some time ago while browsing the fs/
>>> > directory.
>>> > Access to the filesystem images can be reimplemented in FUSE, but
>>> > other than that, I don't think the in-kernel code would be missed.
>>> >
>>> > It's hard to know how many users are there. I was curious eg. about
>>> > bfs, befs, coda or feevxfs, looked at the last commits and searched
>>> > around web if there are any mentions or user community. But as long
>>> > as there's somebody listed in MAINTAINERS, the above are not
>>> > candidates for moving to staging or deletion.
>>>
>>> Yeah, it's pretty sad how few commits some of these filesystems have
>>> had in recent years.  One can argue that they're stable and don't need
>>> to be fixed because they aren't broken, but I find it hard to believe
>>> that any of them were better-implemented than ext2 which still sees
>>> regular bugfixes.
>>
>> Regarding affs there is a severe issue which is not in affs itself but
>> in the handling of Rigid Disk Block (RDB) partitions, the Amiga
>> partitioning standard, which is far more advanced than MBR: It overruns
>> for 2 TB or larger drives and then wraps over to the beginning of the
>> drive – I bet you can imagine what happens if you write to an area
>> larger than 2 TB. I learned this with an external 2TB RDB partitioned
>> harddisk back then, which I used for Sam440ep (a kind of successor for
>> old, classic Amiga hardware) backup + some Linux related stuff in
>> another partition.
>>
>> Joanne Dow, a developer who developed hdwrench.library which HDToolBox
>> uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then,
>> but never officially put it officially through upstreaming as I offered
>> to make a good description and upstream it through Jens Axboe.
>>
>> I may take this as a reason to… actually follow through this time,
>> hopefully remembering all the details in order to provide a meaningful
>> patch description – but I think mostly I can do just careful copy and
>> paste. Even tough I believe Joanne Dow´s fix only fixed my bug report
>> 43511, but not 43511 which is more about a safeguarding issue in case of
>> future overflows, I still think it would be good to go in in case affs +
>> RDB stays in their current places.
>>
>> However, in case you move affs to staging, I may be less motivated to do
>> so, but then I suggest you also move RDB partitioning support to
>> staging, cause this is the one that is known to be dangerously badly for
>> 2 TB or larger disks. And yeah, I admit I did not follow through with
>> having that patch upstreamed. Probably I did not want to be responsible
>> in case my description would not have been absolutely accurate or the
>> patch breaks something else. I do not have that 2 TB drive anymore and
>> don´t feel like setting one up in a suitable way in order to go about
>> this patch, but my testing back then was quite elaborate and I still
>> feel pretty confident about it.
>>
>> I totally get your motivation, but I would find it somewhat sad to see
>> the filesystems you mentioned go into staging. However, as I just shown
>> clearly, for the user it may be better, cause there may be unfixed
>> dangerous bugs. FUSE might be an interesting approach, but I bet it will
>> not solve the maintenance issue. If there is no one maintaining it in
>> the kernel, I think its unlikely